draft-ietf-i2rs-rib-data-model-04.txt   draft-ietf-i2rs-rib-data-model-05.txt 
Network Working Group L. Wang Network Working Group L. Wang
Internet-Draft Individual Internet-Draft Individual
Intended status: Standards Track H. Ananthakrishnan Intended status: Standards Track H. Ananthakrishnan
Expires: May 25, 2016 Packet Design Expires: September 18, 2016 Packet Design
M. Chen M. Chen
Huawei Huawei
A. Dass A. Dass
S. Kini S. Kini
Ericsson Ericsson
N. Bahadur N. Bahadur
Bracket Computing Bracket Computing
November 22, 2015 March 17, 2016
A YANG Data Model for Routing Information Base (RIB) A YANG Data Model for Routing Information Base (RIB)
draft-ietf-i2rs-rib-data-model-04 draft-ietf-i2rs-rib-data-model-05
Abstract Abstract
This document defines a YANG data model for Routing Information Base This document defines a YANG data model for Routing Information Base
(RIB) that aligns with the I2RS RIB information model. (RIB) that aligns with the I2RS RIB information model.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 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. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 3 1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 3
1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3
2. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 3 2. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. RIB Capability . . . . . . . . . . . . . . . . . . . . . 7 2.1. RIB Capability . . . . . . . . . . . . . . . . . . . . . 7
2.2. Routing Instance and Rib . . . . . . . . . . . . . . . . 8 2.2. Routing Instance and Rib . . . . . . . . . . . . . . . . 8
2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5. RPC Operations . . . . . . . . . . . . . . . . . . . . . 14 2.5. RPC Operations . . . . . . . . . . . . . . . . . . . . . 14
2.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 18 2.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 18
3. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 19 3. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 20
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63
5. Security Considerations . . . . . . . . . . . . . . . . . . . 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 64
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 63 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 64
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 64
7.1. Normative References . . . . . . . . . . . . . . . . . . 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.2. Informative References . . . . . . . . . . . . . . . . . 64 8.1. Normative References . . . . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 8.2. Informative References . . . . . . . . . . . . . . . . . 65
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65
1. Introduction 1. Introduction
The Interface to the Routing System (I2RS) The Interface to the Routing System (I2RS)
[I-D.ietf-i2rs-architecture] provides read and write access to the [I-D.ietf-i2rs-architecture] provides read and write access to the
information and state within the routing process that exists inside information and state within the routing process that exists inside
the routing elements, this is achieved via the protocol message the routing elements, this is achieved via the protocol message
exchange between I2RS clients and I2RS agents associated with the exchange between I2RS clients and I2RS agents associated with the
routing system. One of the functions of I2RS is to read and write routing system. One of the functions of I2RS is to read and write
data of Routing Information Base (RIB). data of Routing Information Base (RIB).
skipping to change at page 8, line 50 skipping to change at page 9, line 5
A route is essentially a match condition and an action following that A route is essentially a match condition and an action following that
match. The match condition specifies the kind of route (e.g., IPv4, match. The match condition specifies the kind of route (e.g., IPv4,
MPLS, MAC, Interface etc.) and the set of fields to match on. 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 According to the definition in [I-D.ietf-i2rs-rib-info-model], a
route MUST associate with the following attributes: route MUST associate with the following attributes:
o ROUTE_PREFERENCE: See Section 2.3 of o ROUTE_PREFERENCE: See Section 2.3 of
[I-D.ietf-i2rs-rib-info-model]. [I-D.ietf-i2rs-rib-info-model].
o ACTIVE: Indicates whether a route is fully resolved and is a o ACTIVE: Indicates whether a route has at least one fully resolved
candidate for selection. nexthop and is therefore eligible for installation in the FIB.
o INSTALLED: Indicates whether the route got installed 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 In addition, a route can associate with one or more optional route
attributes(e.g., route-vendor-attributes). attributes(e.g., route-vendor-attributes).
For a RIB, there will have a number of routes, so the routes are 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 expressed as a list under a specific rib. Each rib has its own route
list. list.
skipping to change at page 18, line 17 skipping to change at page 18, line 17
Asynchronous notifications are sent by the RIB manager of a network Asynchronous notifications are sent by the RIB manager of a network
device to an external entity when some event triggers on the 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 device. A RIB data-model MUST support sending 2 kind of asynchronous
notifications. notifications.
1. Route change notification: 1. Route change notification:
o Installed (Indicates whether the route got installed in the FIB) ; o Installed (Indicates whether the route got installed in the FIB) ;
o Active (Indicates whether a route is fully resolved and is a o Active (Indicates whether a route has at least one fully resolved
candidate for selection) ; nexthop and is therefore eligible for installation in the FIB) ;
o Reason - E.g. Not authorized o Reason - E.g. Not authorized
2. Nexthop resolution status notification 2. Nexthop resolution status notification
Nexthops can be fully resolved nexthops or an unresolved nexthop. Nexthops can be fully resolved nexthops or an unresolved nexthop.
A resolved nexthop has adequate level of information to send the A resolved nexthop has adequate level of information to send the
outgoing packet towards the destination by forwarding it on an outgoing packet towards the destination by forwarding it on an
interface of a directly connected neighbor. interface of a directly connected neighbor.
An unresolved nexthop is something that requires the RIB manager to An unresolved nexthop is something that requires the RIB manager to
determine the final resolved nexthop. For example, in a case when a 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 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 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 address reachable by regular IP forwarding or by a MPLS tunnel or by
both. If the RIB manager cannot resolve the nexthop, then the both. If the RIB manager cannot resolve the nexthop, then the
nexthop remains in an unresolved state and is NOT a suitable nexthop remains in an unresolved state and is NOT a suitable
candidate for installation in the FIB. 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. The structure tree of notifications is shown in the following figure.
notifications: notifications:
+---n nexthop-resolution-status-change +---n nexthop-resolution-status-change
| +--ro nexthop | +--ro nexthop
| | +--ro nexthop-id uint32 | | +--ro nexthop-id uint32
| | +--ro sharing-flag boolean | | +--ro sharing-flag boolean
| | +--ro (nexthop-type)? | | +--ro (nexthop-type)?
| | +--:(nexthop-base) | | +--:(nexthop-base)
| | | ... | | | ...
skipping to change at page 19, line 40 skipping to change at page 19, line 44
| +--:(ipv6) | +--:(ipv6)
| | ... | | ...
| +--:(mpls-route) | +--:(mpls-route)
| | ... | | ...
| +--:(mac-route) | +--:(mac-route)
| | ... | | ...
| +--:(interface-route) | +--:(interface-route)
| ... | ...
+--ro route-installed-state route-installed-state-def +--ro route-installed-state route-installed-state-def
+--ro route-state route-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 Figure 7: Notifications Structure
3. YANG Modules 3. YANG Modules
<CODE BEGINS> file "ietf-i2rs-rib@2015-11-20.yang" <CODE BEGINS> file "ietf-i2rs-rib@2016-03-17.yang"
module ietf-i2rs-rib { module ietf-i2rs-rib {
namespace "urn:ietf:params:xml:ns:yang:ietf-i2rs-rib"; namespace "urn:ietf:params:xml:ns:yang:ietf-i2rs-rib";
// replace with iana namespace when assigned // replace with iana namespace when assigned
prefix "iir"; prefix "iir";
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
//rfc6991 //rfc6991
} }
import ietf-interfaces { import ietf-interfaces {
prefix "if"; prefix "if";
} }
import ietf-yang-types { import ietf-yang-types {
skipping to change at page 20, line 50 skipping to change at page 21, line 11
Editor: Sriganesh Kini Editor: Sriganesh Kini
<mailto:sriganesh.kini@ericsson.com> <mailto:sriganesh.kini@ericsson.com>
Editor: Nitin Bahadur Editor: Nitin Bahadur
<mailto:nitin_bahadur@yahoo.com>"; <mailto:nitin_bahadur@yahoo.com>";
description description
"This module defines a YANG data model for "This module defines a YANG data model for
Routing Information Base (RIB) that aligns Routing Information Base (RIB) that aligns
with the I2RS RIB information model."; with the I2RS RIB information model.";
revision "2015-11-20" { revision "2016-03-17" {
description "initial revision"; description "initial revision";
reference "draft-ietf-i2rs-data-model-04"; reference "draft-ietf-i2rs-data-model-05";
} }
//Features //Features
feature nexthop-tunnel { feature nexthop-tunnel {
description description
"This feature means that a node support "This feature means that a node support
tunnel nexthop capability."; tunnel nexthop capability.";
} }
feature nexthop-chain { feature nexthop-chain {
skipping to change at page 31, line 33 skipping to change at page 31, line 42
} }
typedef route-installed-state-def { typedef route-installed-state-def {
type identityref { type identityref {
base "route-installed-state"; base "route-installed-state";
} }
description description
"Route installed state def."; "Route installed state def.";
} }
identity route-reason { //Route change reason identities
identity route-change-reason {
description description
"Base identify from which all route "Base identify from which all route change
reasons are derived."; reasons are derived.";
} }
identity low-preference { identity lower-route-preference {
base "route-reason"; base "route-change-reason";
description 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 { identity higher-route-preference {
base "route-reason"; base "route-change-reason";
description 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 { identity resolved-nexthop {
base "route-reason"; base "route-change-reason";
description 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 { type identityref {
base "route-reason"; base "route-change-reason";
} }
description description
"Route reason def."; "Route change reason def.";
} }
typedef nexthop-preference-def { typedef nexthop-preference-def {
type uint8 { type uint8 {
range "1..99"; range "1..99";
} }
description description
"Nexthop-preference is used for protection schemes. "Nexthop-preference is used for protection schemes.
It is an integer value between 1 and 99. A lower It is an integer value between 1 and 99. A lower
value indicates higher preference. To download N value indicates higher preference. To download N
skipping to change at page 36, line 36 skipping to change at page 37, line 11
"Indicate a route's state: Active or Inactive."; "Indicate a route's state: Active or Inactive.";
} }
leaf route-installed-state { leaf route-installed-state {
type route-installed-state-def; type route-installed-state-def;
config false; config false;
description description
"Indicate that a route's installed states: "Indicate that a route's installed states:
Installed or uninstalled."; Installed or uninstalled.";
} }
leaf route-reason { leaf route-reason {
type route-reason-def; type route-change-reason-def;
config false; config false;
description description
"Indicate the route reason."; "Indicate the route reason.";
} }
} }
container route-attributes { container route-attributes {
description description
"Route attributes."; "Route attributes.";
uses route-attributes; uses route-attributes;
} }
skipping to change at page 50, line 36 skipping to change at page 51, line 11
"MPLS decap."; "MPLS decap.";
leaf label-pop { leaf label-pop {
type mpls-label-action-def; type mpls-label-action-def;
mandatory true; mandatory true;
description description
"Pop a label from the label stack."; "Pop a label from the label stack.";
} }
leaf ttl-action { leaf ttl-action {
type ttl-action-def; type ttl-action-def;
description description
"The label ttl actions: "The label ttl action.";
no-action or copy to inner label";
} }
} }
} }
} }
} }
grouping route-attributes { grouping route-attributes {
description description
"Route attributes."; "Route attributes.";
leaf route-preference { leaf route-preference {
skipping to change at page 62, line 49 skipping to change at page 63, line 23
leaf route-installed-state { leaf route-installed-state {
type route-installed-state-def; type route-installed-state-def;
mandatory true; mandatory true;
description description
"Indicates whether the route got installed in the FIB."; "Indicates whether the route got installed in the FIB.";
} }
leaf route-state { leaf route-state {
type route-state-def; type route-state-def;
mandatory true; mandatory true;
description description
"Indicates whether a route is fully resolved and "Indicates whether a route is active or inactive.";
is a candidate for selection.";
} }
leaf route-change-reason { list route-change-reasons {
type route-reason-def; key "route-change-reason";
mandatory true;
description description
"Return the reason that causes the route change."; "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;
mandatory true;
description
"The reason that causes the route change.";
}
} }
} }
} }
<CODE ENDS> <CODE ENDS>
4. IANA Considerations 4. IANA Considerations
This document requests to register a URI in the "IETF XML registry" This document requests to register a URI in the "IETF XML registry"
[RFC3688]: [RFC3688]:
skipping to change at page 64, line 5 skipping to change at page 64, line 37
6. Contributors 6. Contributors
The following individuals also contribute to this document. The following individuals also contribute to this document.
o Zekun He, Tencent Holdings Ltd o Zekun He, Tencent Holdings Ltd
o Sujian Lu, Tencent Holdings Ltd o Sujian Lu, Tencent Holdings Ltd
o Jeffery Zhang, Juniper Networks 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <http://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>. <http://www.rfc-editor.org/info/rfc6020>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<http://www.rfc-editor.org/info/rfc6991>. <http://www.rfc-editor.org/info/rfc6991>.
7.2. Informative References 8.2. Informative References
[I-D.ietf-i2rs-architecture] [I-D.ietf-i2rs-architecture]
Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing Nadeau, "An Architecture for the Interface to the Routing
System", draft-ietf-i2rs-architecture-09 (work in System", draft-ietf-i2rs-architecture-13 (work in
progress), March 2015. progress), February 2016.
[I-D.ietf-i2rs-rib-info-model] [I-D.ietf-i2rs-rib-info-model]
Bahadur, N., Kini, S., and J. Medved, "Routing Information Bahadur, N., Kini, S., and J. Medved, "Routing Information
Base Info Model", draft-ietf-i2rs-rib-info-model-08 (work Base Info Model", draft-ietf-i2rs-rib-info-model-08 (work
in progress), October 2015. in progress), October 2015.
[I-D.ietf-i2rs-usecase-reqs-summary] [I-D.ietf-i2rs-usecase-reqs-summary]
Hares, S. and M. Chen, "Summary of I2RS Use Case Hares, S. and M. Chen, "Summary of I2RS Use Case
Requirements", draft-ietf-i2rs-usecase-reqs-summary-01 Requirements", draft-ietf-i2rs-usecase-reqs-summary-02
(work in progress), May 2015. (work in progress), March 2016.
Authors' Addresses Authors' Addresses
Lixing Wang Lixing Wang
Individual Individual
Email: wang_little_star@sina.com Email: wang_little_star@sina.com
Hariharan Ananthakrishnan Hariharan Ananthakrishnan
Packet Design Packet Design
Email: hari@packetdesign.com Email: hari@packetdesign.com
Mach(Guoyi) Chen Mach(Guoyi) Chen
Huawei Huawei
Email: mach.chen@huawei.com Email: mach.chen@huawei.com
Amit Dass Amit Dass
Ericsson Ericsson
Torshamnsgatan 48. Torshamnsgatan 48.
Stockholm 16480 Stockholm 16480
Sweden Sweden
 End of changes. 39 change blocks. 
52 lines changed or deleted 95 lines changed or added

This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/