--- 1/draft-ietf-i2rs-rib-data-model-04.txt 2016-03-17 01:17:03.297900897 -0700 +++ 2/draft-ietf-i2rs-rib-data-model-05.txt 2016-03-17 01:17:03.409903689 -0700 @@ -1,26 +1,26 @@ Network Working Group L. Wang Internet-Draft Individual Intended status: Standards Track H. Ananthakrishnan -Expires: May 25, 2016 Packet Design +Expires: September 18, 2016 Packet Design M. Chen Huawei A. Dass S. Kini Ericsson N. Bahadur Bracket Computing - November 22, 2015 + March 17, 2016 A YANG Data Model for Routing Information Base (RIB) - draft-ietf-i2rs-rib-data-model-04 + draft-ietf-i2rs-rib-data-model-05 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,25 +34,25 @@ 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 May 25, 2016. + This Internet-Draft will expire on September 18, 2016. Copyright Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -60,31 +60,32 @@ 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.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.5. RPC Operations . . . . . . . . . . . . . . . . . . . . . 14 2.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 18 - 3. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 19 + 3. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 20 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 63 - 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 63 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 64 - 7.1. Normative References . . . . . . . . . . . . . . . . . . 64 - 7.2. Informative References . . . . . . . . . . . . . . . . . 64 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 64 + 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 64 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 64 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 64 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 64 + 8.2. Informative References . . . . . . . . . . . . . . . . . 65 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65 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). @@ -370,22 +370,22 @@ A route is essentially a match condition and an action following that match. The match condition specifies the kind of route (e.g., IPv4, MPLS, MAC, Interface etc.) and the set of fields to match on. According to the definition in [I-D.ietf-i2rs-rib-info-model], a 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 is fully resolved and is a - candidate for selection. + 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). 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. @@ -813,42 +813,56 @@ 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. 1. Route change notification: o Installed (Indicates whether the route got installed in the FIB) ; - o Active (Indicates whether a route is fully resolved and is a - candidate for selection) ; + 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. A resolved nexthop has adequate level of information to send the outgoing packet towards the destination by forwarding it on an interface of 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. + 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 + 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)? | | +--:(nexthop-base) | | | ... @@ -872,32 +886,33 @@ | +--:(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-change-reason route-change-reason-def Figure 7: Notifications Structure 3. YANG Modules - file "ietf-i2rs-rib@2015-11-20.yang" + file "ietf-i2rs-rib@2016-03-17.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 } import ietf-interfaces { prefix "if"; } import ietf-yang-types { @@ -930,23 +945,23 @@ 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 "2015-11-20" { + revision "2016-03-17" { description "initial revision"; - reference "draft-ietf-i2rs-data-model-04"; + reference "draft-ietf-i2rs-data-model-05"; } //Features feature nexthop-tunnel { description "This feature means that a node support tunnel nexthop capability."; } feature nexthop-chain { @@ -1442,50 +1456,64 @@ } typedef route-installed-state-def { type identityref { base "route-installed-state"; } description "Route installed state def."; } - identity route-reason { + //Route change reason identities + + identity route-change-reason { description - "Base identify from which all route + "Base identify from which all route change reasons are derived."; } - identity low-preference { - base "route-reason"; + identity lower-route-preference { + base "route-change-reason"; description - "Low preference"; + "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."; } - identity unresolved-nexthop { - base "route-reason"; + identity higher-route-preference { + base "route-change-reason"; description - "Unresolved nexthop"; + "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."; } - identity higher-metric { - base "route-reason"; + identity resolved-nexthop { + base "route-change-reason"; description - "Higher metric"; + "This route was made active because at least + one of its nexthops was resolved."; } - typedef route-reason-def { + 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 { type identityref { - base "route-reason"; + base "route-change-reason"; } description - "Route reason def."; + "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 @@ -1686,21 +1713,21 @@ "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-reason-def; + type route-change-reason-def; config false; description "Indicate the route reason."; } } container route-attributes { description "Route attributes."; uses route-attributes; } @@ -2360,22 +2387,21 @@ "MPLS decap."; leaf label-pop { type mpls-label-action-def; mandatory true; description "Pop a label from the label stack."; } leaf ttl-action { type ttl-action-def; description - "The label ttl actions: - no-action or copy to inner label"; + "The label ttl action."; } } } } } grouping route-attributes { description "Route attributes."; leaf route-preference { @@ -2951,28 +2978,37 @@ 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; mandatory true; description - "Indicates whether a route is fully resolved and - is a candidate for selection."; + "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 + 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-reason-def; + type route-change-reason-def; mandatory true; description - "Return the reason that causes the route change."; + "The reason that causes the route change."; + } } } } 4. IANA Considerations This document requests to register a URI in the "IETF XML registry" [RFC3688]: @@ -3002,71 +3038,76 @@ 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. References +7. Acknowledgements -7.1. Normative References + The authors would like to thank Chris Bowers 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, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . -7.2. Informative References +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-09 (work in - progress), March 2015. + System", draft-ietf-i2rs-architecture-13 (work in + progress), February 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-usecase-reqs-summary] Hares, S. and M. Chen, "Summary of I2RS Use Case - Requirements", draft-ietf-i2rs-usecase-reqs-summary-01 - (work in progress), May 2015. + Requirements", draft-ietf-i2rs-usecase-reqs-summary-02 + (work in progress), March 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 Torshamnsgatan 48. Stockholm 16480 Sweden