--- 1/draft-ietf-i2rs-rib-data-model-09.txt 2018-02-15 18:13:12.557529433 -0800 +++ 2/draft-ietf-i2rs-rib-data-model-10.txt 2018-02-15 18:13:12.669532112 -0800 @@ -1,27 +1,27 @@ Network Working Group L. Wang Internet-Draft Individual -Intended status: Standards Track H. Ananthakrishnan -Expires: June 9, 2018 Packet Design - M. Chen - Huawei +Intended status: Standards Track M. Chen +Expires: August 15, 2018 Huawei A. Dass Ericsson + H. Ananthakrishnan + Packet Design S. Kini Individual N. Bahadur Bracket Computing - December 6, 2017 + February 11, 2018 A YANG Data Model for Routing Information Base (RIB) - draft-ietf-i2rs-rib-data-model-09 + draft-ietf-i2rs-rib-data-model-10 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 @@ -35,47 +35,47 @@ 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 https://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 June 9, 2018. + This Internet-Draft will expire on August 15, 2018. Copyright Notice - Copyright (c) 2017 IETF Trust and the persons identified as the + Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 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.2. Routing Instance and Rib . . . . . . . . . . . . . . . . 7 2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.5. RPC Operations . . . . . . . . . . . . . . . . . . . . . 14 2.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 18 3. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 20 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 64 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 66 8.2. Informative References . . . . . . . . . . . . . . . . . 67 @@ -99,58 +99,42 @@ 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. + YANG tree diagrams provide a concise representation of a YANG module, + and SHOULD be included to help readers understand YANG module + structure. Guidelines on tree diagrams can be found in Section 3 of + [I-D.ietf-netmod-yang-tree-diagrams]. 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 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 address-family rib-family-def + +--rw address-family rib-family-definition +--rw ip-rpf-check? boolean +--rw route-list* [route-index] | +--rw route-index uint64 | +--rw match | | +--rw (route-type)? | | +--:(ipv4) | | | ... | | +--:(ipv6) | | | ... | | +--:(mpls-route) @@ -177,21 +162,21 @@ | | ... | +--rw route-attributes | | ... | +--rw route-vendor-attributes +--rw nexthop-list* [nexthop-member-id] +--rw nexthop-member-id uint32 rpcs: +---x rib-add | +---w input | | +---w name string - | | +---w address-family rib-family-def + | | +---w address-family rib-family-definition | | +---w ip-rpf-check? boolean | +--ro output | +--ro result uint32 | +--ro reason? string +---x rib-delete | +---w input | | +---w name string | +--ro output | +--ro result uint32 | +--ro reason? string @@ -291,40 +277,40 @@ | | +--:(nexthop-base) | | | ... | | +--:(nexthop-chain) {nexthop-chain}? | | | ... | | +--:(nexthop-replicates) {nexthop-replicates}? | | | ... | | +--:(nexthop-protection) {nexthop-protection}? | | | ... | | +--:(nexthop-load-balance) {nexthop-load-balance}? | | ... - | +--ro nexthop-state nexthop-state-def + | +--ro nexthop-state nexthop-state-definition +---n route-change +--ro rib-name string - +--ro address-family rib-family-def + +--ro address-family rib-family-definition +--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 + +--ro route-installed-state route-installed-state-definition + +--ro route-state route-state-definition + +--ro route-change-reason route-reason-definition 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 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 @@ -356,21 +342,21 @@ 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 address-family rib-family-def + +--rw address-family rib-family-definition +--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, @@ -384,21 +370,21 @@ 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 be associated with one or more optional route attributes (e.g., route-vendor-attributes). 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. + 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) | | | ... @@ -447,23 +432,23 @@ * egress-interface * egress-interface with IPv4 address * egress-interface with IPv6 address * egress-interface with MAC address * logical-tunnel - * tunnel-encap + * tunnel-encapsulation - * tunnel-decap + * tunnel-decapsulation * rib-name o Chain: Provide a way to perform multiple operations on a packet by logically combining them. o Load-balance: Designed for load-balance case where it normally will have multiple weighted nexthops. o Protection: Designed for protection scenario where it normally @@ -484,37 +469,37 @@ | | +--rw nexthop-list* [nexthop-member-id] | | +--rw nexthop-member-id uint32 | +--:(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 + | | +--rw nexthop-preference nexthop-preference-definition | +--:(nexthop-load-balance) {nexthop-load-balance}? | +--rw nexthop-lb | +--rw nexthop-list* [nexthop-member-id] | +--rw nexthop-member-id uint32 - | +--rw nexthop-lb-weight nexthop-lb-weight-def + | +--rw nexthop-lb-weight nexthop-lb-weight-definition 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) | +--rw nexthop-base | +--rw (nexthop-base-type)? | +--:(special-nexthop) - | | +--rw special? special-nexthop-def +| | +--rw special? special-nexthop-definition | +--:(egress-interface-nexthop) | | +--rw outgoing-interface if:interface-ref | +--:(ipv4-address-nexthop) | | +--rw ipv4-address inet:ipv4-address | +--:(ipv6-address-nexthop) | | +--rw ipv6-address inet:ipv6-address | +--:(egress-interface-ipv4-nexthop) | | +--rw egress-interface-ipv4-address | | +--rw outgoing-interface if:interface-ref | | +--rw ipv4-address inet:ipv4-address @@ -552,21 +537,21 @@ | | | +--:(label-push) | | | | +--rw label-push | | | | +--rw label uint32 | | | | +--rw s-bit? boolean | | | | +--rw tc-value? uint8 | | | | +--rw ttl-value? uint8 | | | +--:(label-swap) | | | +--rw label-swap | | | +--rw in-label uint32 | | | +--rw out-label uint32 - | | | +--rw ttl-action? ttl-action-def +| | | +--rw ttl-action? ttl-action-definition | | +--:(gre) {gre-tunnel}? | | | +--rw gre-header | | | +--rw (dest-address-type)? | | | | +--:(ipv4) | | | | | +--rw ipv4-dest inet:ipv4-address | | | | +--:(ipv6) | | | | +--rw ipv6-dest inet:ipv6-address | | | +--rw protocol-type uint16 | | | +--rw key? uint64 | | +--:(nvgre) {nvgre-tunnel}? @@ -597,88 +582,90 @@ | | | | +--rw ttl? uint8 | | | | +--rw dscp? uint8 | | | +--:(ipv6) | | | +--rw src-ipv6-address inet:ipv6-address | | | +--rw dest-ipv6-address inet:ipv6-address | | | +--rw next-header uint8 | | | +--rw traffic-class? uint8 | | | +--rw flow-label? uint16 | | | +--rw hop-limit? uint8 | | +--rw vxlan-identifier uint32 - | +--:(tunnel-decap-nexthop) {nexthop-tunnel}? - | | +--rw tunnel-decap +| +--:(tunnel-decapsulation-nexthop) {nexthop-tunnel}? +| | +--rw tunnel-decapsulation | | +--rw (tunnel-type)? | | +--:(ipv4) {ipv4-tunnel}? - | | | +--rw ipv4-decap - | | | +--rw ipv4-decap tunnel-decap-action-def - | | | +--rw ttl-action? ttl-action-def +| | | +--rw ipv4-decapsulation +| | | +--rw ipv4-decapsulation tunnel-decapsulation-action-definition +| | | +--rw ttl-action? ttl-action-definition | | +--:(ipv6) {ipv6-tunnel}? - | | | +--rw ipv6-decap - | | | +--rw ipv6-decap tunnel-decap-action-def - | | | +--rw hop-limit-action? hop-limit-action-def +| | | +--rw ipv6-decapsulation +| | | +--rw ipv6-decapsulation tunnel-decapsulation-action-definition +| | | +--rw hop-limit-action? hop-limit-action-definition | | +--:(mpls) {mpls-tunnel}? | | +--rw label-pop - | | +--rw label-pop mpls-label-action-def - | | +--rw ttl-action? ttl-action-def +| | +--rw label-pop mpls-label-action-definition +| | +--rw ttl-action? ttl-action-definition | +--:(logical-tunnel-nexthop) {nexthop-tunnel}? | | +--rw logical-tunnel - | | +--rw tunnel-type tunnel-type-def +| | +--rw tunnel-type tunnel-type-definition | | +--rw tunnel-name string | +--:(rib-name-nexthop) | | +--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: Add a RIB to a routing instance. A name of the rib, + 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: 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: Add a route or a set of routes to a rib. A RIB name, + 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: + call the nh-add rpc to create and/or return the nexthop identifier + but during situations when the nexthop already exists and the + nexthop-id is known, this action is not expected.. The output is a + combination of the route operation states while querying the + appropriate node in the data tree that include: * success-count: the number of routes that were successfully added; * failed-count: the number of the routes that failed to be added; * failure-detail: shows the specific routes that failed to be added. - 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 + 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 number of routes that were successfully deleted; * failed-count: the number of the routes that failed to be deleted; * failure-detail: shows the specific routes that failed to be @@ -695,47 +682,47 @@ * success-count: the number of routes that were successfully updated; * failed-count: the number of the routes that failed to be updated; * failure-detail: shows the specific routes that failed to be updated. - o nh-add: Add a nexthop to a rib. A name of the RIB and a nexthop + 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: Delete a nexthop from a rib. A name of a RIB and a + 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 shown in following figure. rpcs: +---x rib-add | +---w input | | +---w rib-name string - | | +---w address-family rib-family-def + | | +---w address-family rib-family-definition | | +---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 @@ -868,101 +856,105 @@ | | +--:(nexthop-base) | | | ... | | +--:(nexthop-chain) {nexthop-chain}? | | | ... | | +--:(nexthop-replicates) {nexthop-replicates}? | | | ... | | +--:(nexthop-protection) {nexthop-protection}? | | | ... | | +--:(nexthop-load-balance) {nexthop-load-balance}? | | ... - | +--ro nexthop-state nexthop-state-def + | +--ro nexthop-state nexthop-state-definition +---n route-change +--ro rib-name string - +--ro address-family rib-family-def + +--ro address-family rib-family-definition +--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-change-reason-def + +--ro route-installed-state route-installed-state-definition + +--ro route-state route-state-definition + +--ro route-change-reason route-change-reason-definition Figure 7: Notifications Structure 3. YANG Modules file "ietf-i2rs-rib@2017-12-05.yang" module ietf-i2rs-rib { + yang-version 1.1; 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 + reference "RFC 6991"; } import ietf-interfaces { - prefix "if"; + prefix if; + reference "RFC 7223"; } import ietf-yang-types { prefix yang; + reference "RFC 6991"; } organization "IETF I2RS (Interface to Routing System) Working Group"; contact "WG Web: WG List: - WG Chair: Susan Hares - - - WG Chair: Russ White - - Editor: Lixing Wang - Editor: Hariharan Ananthakrishnan - - Editor: Mach(Guoyi) Chen Editor: Amit Dass + Editor: Hariharan Ananthakrishnan + + 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 "2017-12-05" { + with the I2RS RIB information model. + Copyright (c) <2018> IETF Trust and the persons + identified as authors of the code. All rights reserved."; + revision "2018-02-12" { description "initial revision"; - reference "draft-ietf-i2rs-data-model-09"; + reference "draft-ietf-i2rs-data-model-10"; + + // RFC Ed.: replace XXXX with actual RFC number and remove + // this note + } //Features feature nexthop-tunnel { description "This feature means that a node supports tunnel nexthop capability."; } feature nexthop-chain { @@ -1052,55 +1046,55 @@ description "MPLS label stack operation: pop."; } identity label-swap { base "mpls-label-action"; description "MPLS label stack operation: swap."; } - typedef mpls-label-action-def { + typedef mpls-label-action-definition { type identityref { base "mpls-label-action"; } description - "MPLS label action def."; + "MPLS label action definition."; } - identity tunnel-decap-action { + identity tunnel-decapsulation-action { description - "Base identity from which all tunnel decap + "Base identity from which all tunnel decapsulation actions are derived. - Tunnel decap actions include: - ipv4-decap - to decap an IPv4 tunnel, - ipv6-decap - to decap an IPv6 tunnel."; + Tunnel decapsulation actions include: + ipv4-decapsulation - to decapsulate an IPv4 tunnel, + ipv6-decapsulation - to decapsulate an IPv6 tunnel."; } - identity ipv4-decap { - base "tunnel-decap-action"; + identity ipv4-decapsulation { + base "tunnel-decapsulation-action"; description - "IPv4 tunnel decap."; + "IPv4 tunnel decapsulation."; } - identity ipv6-decap { - base "tunnel-decap-action"; + identity ipv6-decapsulation { + base "tunnel-decapsulation-action"; description - "IPv4 tunnel decap."; + "IPv4 tunnel decapsulation."; } - typedef tunnel-decap-action-def { + typedef tunnel-decapsulation-action-definition { type identityref { - base "tunnel-decap-action"; + base "tunnel-decapsulation-action"; } description - "Tunnel decap def."; + "Tunnel decapsulation definition."; } identity ttl-action { description "Base identity from which all TTL actions are derived."; } identity no-action { base "ttl-action"; @@ -1124,27 +1118,26 @@ 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 inner label and copy it to the outer label."; } - - typedef ttl-action-def { + typedef ttl-action-definition { type identityref { base "ttl-action"; } description - "TTL action def."; + "TTL action definition."; } identity hop-limit-action { description "Base identity from which all hop limit actions are derived."; } identity hop-limit-no-action { base "hop-limit-action"; @@ -1152,26 +1145,26 @@ "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 the inner header."; } - typedef hop-limit-action-def { + typedef hop-limit-action-definition { type identityref { base "hop-limit-action"; } description - "IPv6 hop limit action def."; + "IPv6 hop limit action definition."; } identity special-nexthop { description "Base identity from which all special nexthops are derived."; } identity discard { base "special-nexthop"; @@ -1204,26 +1196,26 @@ to indicate how to throttle traffic destined for the control plane."; } identity cos-value { base "special-nexthop"; description "Cos-value special nexthop."; } - typedef special-nexthop-def { + typedef special-nexthop-definition { type identityref { base "special-nexthop"; } description - "Special nexthop def."; + "Special nexthop definition."; } identity ip-route-match-type { description "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."; @@ -1239,26 +1229,26 @@ base "ip-route-match-type"; description "Destination route match type"; } identity match-ip-src-dest { base "ip-route-match-type"; description "Source and Destination route match type"; } - typedef ip-route-match-type-def { + typedef ip-route-match-type-definition { type identityref { base "ip-route-match-type"; } description - "IP route match type def."; + "IP route match type definition."; } identity rib-family { description "Base identity from which all RIB address families are derived."; } identity ipv4-rib-family { base "rib-family"; @@ -1270,34 +1260,32 @@ base "rib-family"; description "IPv6 RIB address family."; } identity mpls-rib-family { base "rib-family"; description "MPLS RIB address family."; } - identity ieee-mac-rib-family { base "rib-family"; description "MAC RIB address family."; - } - typedef rib-family-def { + typedef rib-family-definition { type identityref { base "rib-family"; } description - "Rib address family def."; + "RIB address family definition."; } identity route-type { description "Base identity from which all route types are derived."; } identity ipv4-route { base "route-type"; @@ -1320,28 +1308,29 @@ identity ieee-mac { base "route-type"; description "MAC route type."; } identity interface { base "route-type"; description "Interface route type."; + } - typedef route-type-def { + typedef route-type-definition { type identityref { base "route-type"; } description - "Route type def."; + "Route type definition."; } identity tunnel-type { description "Base identity from which all tunnel types are derived."; } identity ipv4-tunnel { base "tunnel-type"; @@ -1371,52 +1360,53 @@ base "tunnel-type"; description "VxLAN tunnel type"; } identity nvgre-tunnel { base "tunnel-type"; description "NVGRE tunnel type"; } - typedef tunnel-type-def { + + typedef tunnel-type-definition { type identityref { base "tunnel-type"; } description - "Tunnel type def."; + "Tunnel type definition."; } identity route-state { description "Base identity from which all route states are derived."; } identity active { base "route-state"; description "Active state."; } identity inactive { base "route-state"; description "Inactive state."; } - typedef route-state-def { + typedef route-state-definition { type identityref { base "route-state"; } description - "Route state def."; + "Route state definition."; } identity nexthop-state { description "Base identity from which all nexthop states are derived."; } identity resolved { base "nexthop-state"; @@ -1415,68 +1405,70 @@ identity nexthop-state { description "Base identity from which all nexthop states are derived."; } identity resolved { base "nexthop-state"; description "Reolved nexthop state."; + } identity unresolved { base "nexthop-state"; description "Unresolved nexthop state."; } - typedef nexthop-state-def { + typedef nexthop-state-definition { type identityref { base "nexthop-state"; } description - "Nexthop state def."; + "Nexthop state definition."; } identity route-installed-state { description "Base identity from which all route installed states are derived."; } identity uninstalled { base "route-installed-state"; description "Uninstalled state."; } identity installed { base "route-installed-state"; description "Installed state."; } - typedef route-installed-state-def { + typedef route-installed-state-definition { type identityref { base "route-installed-state"; } description - "Route installed state def."; + "Route installed state definition."; } //Route change reason identities identity route-change-reason { description "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 was more preferred) than the route it replaced."; } @@ -1495,44 +1487,44 @@ one of its nexthops was resolved."; } identity unresolved-nexthop { base "route-change-reason"; description "This route was made inactive because all of its nexthops are unresolved."; } - typedef route-change-reason-def { + typedef route-change-reason-definition { type identityref { base "route-change-reason"; } description - "Route change reason def."; + "Route change reason definition."; } - typedef nexthop-preference-def { + typedef nexthop-preference-definition { type uint8 { range "1..99"; } description "Nexthop-preference is used for protection schemes. 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. 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 { + typedef nexthop-lb-weight-definition { type uint8 { range "1..99"; } description "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 @@ -1715,34 +1708,34 @@ container nexthop { description "The nexthop of the route."; uses nexthop; } //In the information model, it is called route-statistic container route-status { description "The status information of the route."; leaf route-state { - type route-state-def; + type route-state-definition; config false; description "Indicate a route's state: Active or Inactive."; } leaf route-installed-state { - type route-installed-state-def; + type route-installed-state-definition; config false; description "Indicate that a route's installed states: Installed or uninstalled."; } leaf route-reason { - type route-change-reason-def; + type route-change-reason-definition; config false; description "Indicate the reason that causes the route change."; } } container route-attributes { description "Route attributes."; uses route-attributes; } @@ -1780,21 +1773,21 @@ "A list of nexthop."; 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."; } leaf nexthop-preference { - type nexthop-preference-def; + type nexthop-preference-definition; mandatory true; description "Nexthop-preference is used for protection schemes. 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 are most preferred are selected."; } } @@ -1809,21 +1802,21 @@ "A list of nexthop."; 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."; } leaf nexthop-lb-weight { - type nexthop-lb-weight-def; + type nexthop-lb-weight-definition; mandatory true; description "The weight of a nexthop of the load balance nexthops."; } } } grouping nexthop { description @@ -1889,21 +1882,21 @@ } grouping nexthop-base { description "The base nexthop."; choice nexthop-base-type { description "Nexthop base type options."; case special-nexthop { leaf special { - type special-nexthop-def; + type special-nexthop-definition; description "A special nexthop."; } } case egress-interface-nexthop { leaf outgoing-interface { type if:interface-ref; mandatory true; description "The nexthop is an outgoing interface."; @@ -1995,48 +1987,47 @@ uses tunnel-encap; description "This can be an encap representing an IP tunnel or MPLS tunnel or others as defined in info model. An optional egress interface can be chained to the tunnel encap to indicate which interface to send the packet out on. The egress interface is useful when the network device contains Ethernet interfaces and one needs to perform address resolution for the IP packet."; - } } - case tunnel-decap-nexthop { + case tunnel-decapsulation-nexthop { if-feature nexthop-tunnel; - container tunnel-decap { - uses tunnel-decap; + container tunnel-decapsulation { + uses tunnel-decapsulation; description - "This is to specify decapsulating a tunnel header."; + "This is to specify the decapsulation of 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 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 - rib. This is a way to perform chained lookups."; + 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."; } } @@ -2040,27 +2031,26 @@ "A nexthop reference that points to a nexthop."; } } } } grouping route-vendor-attributes { description "Route vendor attributes."; } - grouping logical-tunnel { description "A logical tunnel that is identified by a type and a tunnel name."; leaf tunnel-type { - type tunnel-type-def; + type tunnel-type-definition; mandatory true; description "A tunnel type."; } leaf tunnel-name { type string; mandatory true; description "A tunnel name that points to a logical tunnel."; } @@ -2274,30 +2268,29 @@ description "The label to be swapped."; } leaf out-label { type uint32; mandatory true; description "The out MPLS label."; } leaf ttl-action { - type ttl-action-def; + type ttl-action-definition; 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 information."; choice tunnel-type { description @@ -2346,77 +2339,77 @@ if-feature vxlan-tunnel; container vxlan-header { uses vxlan-header; description "VxLAN header."; } } } } - grouping tunnel-decap { + grouping tunnel-decapsulation { description "Tunnel decapsulation information."; choice tunnel-type { description "Nexthop tunnel type options."; case ipv4 { if-feature ipv4-tunnel; - container ipv4-decap { + container ipv4-decapsulation { description - "IPv4 decap."; - leaf ipv4-decap { - type tunnel-decap-action-def; + "IPv4 decapsulation."; + leaf ipv4-decapsulation { + type tunnel-decapsulation-action-definition; mandatory true; description - "IPv4 decap operations."; + "IPv4 decapsulation operations."; } leaf ttl-action { - type ttl-action-def; + type ttl-action-definition; description "The ttl actions: no-action or copy to inner header."; } } } case ipv6 { if-feature ipv6-tunnel; - container ipv6-decap { + container ipv6-decapsulation { description - "IPv6 decap."; - leaf ipv6-decap { - type tunnel-decap-action-def; + "IPv6 decapsulation."; + leaf ipv6-decapsulation { + type tunnel-decapsulation-action-definition; mandatory true; description - "IPv6 decap operations."; + "IPv6 decapsulation operations."; } leaf hop-limit-action { - type hop-limit-action-def; + type hop-limit-action-definition; description "The hop limit actions: no-action or copy to inner header."; } } } case mpls { if-feature mpls-tunnel; container label-pop { description - "MPLS decap."; + "MPLS decapsulation."; leaf label-pop { - type mpls-label-action-def; + type mpls-label-action-definition; mandatory true; description "Pop a label from the label stack."; } leaf ttl-action { - type ttl-action-def; + type ttl-action-definition; description "The label ttl action."; } } } } } grouping route-attributes { description @@ -2494,48 +2488,47 @@ } list rib-list { 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."; + "A reference to the name of each RIB."; } leaf address-family { - type rib-family-def; + type rib-family-definition; mandatory true; description - "The address family of a rib."; + "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."; + "A list of routes of a RIB."; uses route; } - // This is a list that maintains the nexthops added to the rib. + // This is a list that maintains the nexthops added to the RIB. uses nexthop-list; } } - //RPC Operations rpc rib-add { description "To add a RIB to a instance"; input { leaf name { type string; mandatory true; description "A reference to the name of the RIB @@ -2535,24 +2528,24 @@ "To add a RIB to a instance"; input { leaf name { type string; mandatory true; description "A reference to the name of the RIB that is to be added."; } leaf address-family { - type rib-family-def; + type rib-family-definition; mandatory true; description - "The address family of the rib."; + "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 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."; } @@ -2570,23 +2563,23 @@ type string; description "The specific reason that causes the failure."; } } } rpc rib-delete { description "To delete a RIB from a routing instance. - After deleting the rib, all routes installed - in the RIB will be deleted as well."; + After deleting the RIB, all routes installed + in the RIB will be deleted as well."; input { leaf name { type string; mandatory true; description "A reference to the name of the RIB that is to be deleted."; } } output { @@ -2642,40 +2634,40 @@ type uint32; description "The error code that reflects the failure reason."; } } } } rpc route-add { description - "To add a route or a list of route to a rib"; + "To add a route or a list of route to a RIB"; input { leaf return-failure-detail { type boolean; default false; description "Whether return the failure detail. true - return the failure detail; false - do not return the failure detail; the default is false."; } leaf rib-name { type string; mandatory true; description - "A reference to the name of a rib."; + "A reference to the name of a RIB."; } container routes { description - "The routes to be added to the rib."; + "The routes to be added to the RIB."; list route-list { key "route-index"; description "The list of routes to be added."; uses route-prefix; container route-attributes { uses route-attributes; description "The route attributes."; } @@ -2693,46 +2685,45 @@ } } } output { uses route-operation-state; } } rpc route-delete { description - "To delete a route or a list of route from a rib"; + "To delete a route or a list of route from a RIB"; input { leaf return-failure-detail { type boolean; default false; description "Whether return the failure detail. true - return the failure detail; false - do not return the failure detail; the default is false."; } leaf rib-name { type string; mandatory true; description - "A reference to the name of a rib."; + "A reference to the name of a RIB."; } container routes { description - "The routes to be added to the rib."; + "The routes to be added to the RIB."; list route-list{ key "route-index"; description "The list of routes to be deleted."; uses route-prefix; - } } } output { uses route-operation-state; } } grouping route-update-options { description @@ -2765,23 +2756,22 @@ uses route-vendor-attributes; description "The vendor route attributes used for updating."; } } } } rpc route-update { description - "To update a route or a list of route of a rib. + "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 @@ -2797,21 +2787,21 @@ description "Whether return the failure detail. true - return the failure detail; false - do not return the failure detail; the default is false."; } leaf rib-name { type string; mandatory true; description - "A reference to the name of a rib."; + "A reference to the name of a RIB."; } choice match-options { description "Match options."; case match-route-prefix { description "Update the routes that match route prefix(es) condition."; container input-routes { description @@ -2882,37 +2872,37 @@ } } } output { uses route-operation-state; } } rpc nh-add { description - "To add a nexthop to a rib. + "To add a nexthop to a RIB. Inputs parameters: 1. RIB name 2. nexthop; Actions: 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 - "A reference to the name of a rib."; + "A reference to the name of a RIB."; } uses nexthop; } output { leaf result { type boolean; mandatory true; description "Return the result of the rib-add operation. true - success; @@ -2926,27 +2916,27 @@ leaf nexthop-id { type uint32; description "A nexthop identifier that is allocated to the nexthop."; } } } rpc nh-delete { description - "To delete a nexthop from a rib"; + "To delete a nexthop from a RIB"; input { leaf rib-name { type string; mandatory true; description - "A reference to the name of a rib."; + "A reference to the name of a RIB."; } uses nexthop; } output { leaf result { type boolean; mandatory true; description "Return the result of the rib-add operation. true - success; @@ -2961,56 +2951,55 @@ } /*Notifications*/ notification nexthop-resolution-status-change { description "Nexthop resolution status (resolved/unresolved) notification."; container nexthop{ description "The nexthop."; - uses nexthop; } leaf nexthop-state { - type nexthop-state-def; + type nexthop-state-definition; mandatory true; description "Nexthop resolution status (resolved/unresolved) notification."; } } notification route-change { description "Route change notification."; leaf rib-name { type string; mandatory true; description - "A reference to the name of a rib."; + "A reference to the name of a RIB."; } leaf address-family { - type rib-family-def; + type rib-family-definition; mandatory true; description - "The address family of a rib."; + "The address family of a RIB."; } uses route-prefix; leaf route-installed-state { - type route-installed-state-def; + type route-installed-state-definition; mandatory true; description "Indicates whether the route got installed in the FIB."; } leaf route-state { - type route-state-def; + type route-state-definition; mandatory true; description "Indicates whether a route is active or inactive."; } list route-change-reasons { key "route-change-reason"; description "The reasons that cause the route change. A route change that may result from several reasons. For example, a nexthop becoming resolved will make a @@ -3010,102 +2999,101 @@ } list route-change-reasons { key "route-change-reason"; description "The reasons that cause the route change. A route change that may result from several reasons. For example, a nexthop becoming resolved will make a route A active which is of better preference than a currently active route B, which results in the route A being installed"; - leaf route-change-reason { - type route-change-reason-def; + type route-change-reason-definition; mandatory true; description "The reason that causes the route change."; } } } } 4. IANA Considerations - This document requests to register a URI in the "ns" registry with - the "IETF XML registry" [RFC3688]: + This document registers 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. -------------------------------------------------------------------- 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 - The YANG module defined in this document is designed to be accessed - via network management protocols such as NETCONF [RFC6241] or - RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport - layer, and the mandatory-to-implement secure transport is Secure - Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the - mandatory-to-implement secure transport is TLS [RFC5246]. + The YANG module specified in this document defines a schema for data + that is designed to be accessed via network management protocols such + as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer + is the secure transport layer, and the mandatory-to-implement secure + transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer + is HTTPS, and the mandatory-to-implement secure transport is TLS + [RFC5246]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. The YANG modules define information that can be configurable in - certain instances, for example, a rib, a route, a nexthop can be + certain instances, for example, a RIB, a route, a nexthop can be created or deleted by client applications, the YANG modules also define RPCs that can be used by client applications to add/delete - ribs, routes and nexthops. In such cases, a malicious client could - attempt to remove, add or update a rib, a route, a nexthop, by - creating or deleting corresponding elements in the rib, route and - nexthop lists, respectively. Removing a rib or a route could lead to + RIBs, routes and nexthops. In such cases, a malicious client could + attempt to remove, add or update a RIB, a route, a nexthop, by + creating or deleting corresponding elements in the RIB, route and + nexthop lists, respectively. Removing a RIB or a route could lead to disruption or impact in performance of a service, updating a route may lead to suboptimal path and degradation of service levels as well as possibly disruption of service. For those reasons, it is important that the NETCONF access control model is vigorously applied to prevent misconfiguration by unauthorized clients. - Specifically, there are a number of data nodes defined in the YANG - module that are writable/creatable/deletable (i.e., config true, - which is the default). These data nodes may be considered sensitive - or vulnerable in some network environments. Write operations (e.g., - edit-config) to these data nodes without proper protection can have a - negative effect on network operations. These are the subtrees and - data nodes and their sensitivity/vulnerability in the ietf-i2rs-rib - module: + There are a number of data nodes defined in this YANG module that are + writable/creatable/deletable (i.e., config true, which is the + default). These data nodes may be considered sensitive or vulnerable + in some network environments. Write operations (e.g., edit-config) + to these data nodes without proper protection can have a negative + effect on network operations. These are the subtrees and data nodes + and their sensitivity/vulnerability in the ietf-i2rs-rib module: - o rib: A malicious client could attempt to remove a rib from a + o RIB: A malicious client could attempt to remove a RIB from a routing instance, for example in order to sabotage the services - provided by the rib, or to add a rib to a routing instance, hence + provided by the RIB, or to add a RIB to a routing instance, hence to inject unauthorized traffic into the nexthop. o route:A malicious client could attempt to remove or add a route - from/to a rib, for example in order to sabotage the services - provided by the rib. + from/to a RIB, for example in order to sabotage the services + provided by the RIB. o nexthop: A malicious client could attempt to remove or add a - nexthop from/to rib, which may lead to suboptimal path and + nexthop from/to RIB, which may lead to suboptimal path and degradation of service levels as well as possibly disruption of service. 6. Contributors The following individuals also contribute to this document. o Zekun He, Tencent Holdings Ltd o Sujian Lu, Tencent Holdings Ltd @@ -3114,20 +3102,25 @@ 7. Acknowledgements 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 + [I-D.ietf-netmod-yang-tree-diagrams] + Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- + ietf-netmod-yang-tree-diagrams-04 (work in progress), + December 2017. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security @@ -3159,53 +3152,53 @@ . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . 8.2. Informative References [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-12 (work - in progress), November 2017. + Base Info Model", draft-ietf-i2rs-rib-info-model-13 (work + in progress), January 2018. [I-D.ietf-i2rs-usecase-reqs-summary] Hares, S. and M. Chen, "Summary of I2RS Use Case Requirements", draft-ietf-i2rs-usecase-reqs-summary-03 (work in progress), November 2016. [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", RFC 7921, DOI 10.17487/RFC7921, June 2016, . Authors' Addresses Lixing Wang Individual Email: wang_little_star@sina.com - Hariharan Ananthakrishnan - Packet Design - - Email: hari@packetdesign.com - Mach(Guoyi) Chen Huawei Email: mach.chen@huawei.com Amit Dass Ericsson Email: amit.dass@ericsson.com + Hariharan Ananthakrishnan + Packet Design + + Email: hari@packetdesign.com + Sriganesh Kini Individual Email: sriganeshkini@gmail.com Nitin Bahadur Bracket Computing Email: nitin_bahadur@yahoo.com