draft-ietf-i2rs-rib-data-model-10.txt   draft-ietf-i2rs-rib-data-model-11.txt 
Network Working Group L. Wang Network Working Group L. Wang
Internet-Draft Individual Internet-Draft Individual
Intended status: Standards Track M. Chen Intended status: Standards Track M. Chen
Expires: August 15, 2018 Huawei Expires: October 23, 2018 Huawei
A. Dass A. Dass
Ericsson Ericsson
H. Ananthakrishnan H. Ananthakrishnan
Packet Design Packet Design
S. Kini S. Kini
Individual Individual
N. Bahadur N. Bahadur
Bracket Computing Bracket Computing
February 11, 2018 April 21, 2018
A YANG Data Model for Routing Information Base (RIB) A YANG Data Model for Routing Information Base (RIB)
draft-ietf-i2rs-rib-data-model-10 draft-ietf-i2rs-rib-data-model-11
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 46 skipping to change at page 1, line 46
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 August 15, 2018. This Internet-Draft will expire on October 23, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
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 . . . . . . . . . . . . . . . . 7 2.2. Routing Instance and Rib . . . . . . . . . . . . . . . . 7
2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5. RPC Operations . . . . . . . . . . . . . . . . . . . . . 14 2.5. RPC Operations . . . . . . . . . . . . . . . . . . . . . 14
2.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 18 2.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 18
3. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 20 3. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 20
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64
5. Security Considerations . . . . . . . . . . . . . . . . . . . 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 65
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 65 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 66
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 66
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.1. Normative References . . . . . . . . . . . . . . . . . . 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 66
8.2. Informative References . . . . . . . . . . . . . . . . . 67 8.2. Informative References . . . . . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68
1. Introduction 1. Introduction
The Interface to the Routing System (I2RS) [RFC7921] provides read The Interface to the Routing System (I2RS) [RFC7921] provides read
and write access to the information and state within the routing and write access to the information and state within the routing
process that exists inside the routing elements, this is achieved via process that exists inside the routing elements, this is achieved via
protocol message exchange between I2RS clients and I2RS agents protocol message exchange between I2RS clients and I2RS agents
associated with the routing system. One of the functions of I2RS is associated with the routing system. One of the functions of I2RS is
to read and write data of Routing Information Base (RIB). to read and write data of Routing Information Base (RIB).
[I-D.ietf-i2rs-usecase-reqs-summary] introduces a set of RIB use [I-D.ietf-i2rs-usecase-reqs-summary] introduces a set of RIB use
cases. The RIB information model is defined in cases. The RIB information model is defined in
[I-D.ietf-i2rs-rib-info-model]. [I-D.ietf-i2rs-rib-info-model].
This document defines a YANG [RFC6020][RFC6991] data model for the This document defines a YANG [RFC7950][RFC6991] data model for the
RIB that satisfies the RIB use cases and aligns with the RIB RIB that satisfies the RIB use cases and aligns with the RIB
information model. information model.
1.1. Definitions and Acronyms 1.1. Definitions and Acronyms
RIB: Routing Information Base RIB: Routing Information Base
FIB: Forwarding Information Base
RPC: Remote Procedure Call
Information Model (IM): An abstract model of a conceptual domain, Information Model (IM): An abstract model of a conceptual domain,
independent of a specific implementation or data representation. independent of a specific implementation or data representation.
1.2. Tree Diagrams 1.2. Tree Diagrams
YANG tree diagrams provide a concise representation of a YANG module, Tree diagrams used in this document follow the notation defined in
and SHOULD be included to help readers understand YANG module [RFC8340].
structure. Guidelines on tree diagrams can be found in Section 3 of
[I-D.ietf-netmod-yang-tree-diagrams].
2. Model Structure 2. Model Structure
The following figure shows an overview of structure tree of the ietf- 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 i2rs-rib module. To give a whole view of the structure tree, some
details of the tree are omitted. The relevant details are introduced details of the tree are omitted. The relevant details are introduced
in the subsequent sub-sections. in the subsequent sub-sections.
module: ietf-i2rs-rib module: ietf-i2rs-rib
+--rw routing-instance +--rw routing-instance
skipping to change at page 7, line 20 skipping to change at page 7, line 22
| +--:(ipv6) | +--:(ipv6)
| | ... | | ...
| +--:(mpls-route) | +--:(mpls-route)
| | ... | | ...
| +--:(mac-route) | +--:(mac-route)
| | ... | | ...
| +--:(interface-route) | +--:(interface-route)
| ... | ...
+--ro route-installed-state route-installed-state-definition +--ro route-installed-state route-installed-state-definition
+--ro route-state route-state-definition +--ro route-state route-state-definition
+--ro route-change-reason route-reason-definition +--ro route-change-reason route-change-reason-definition
Figure 1: Overview of I2RS RIB Module Structure Figure 1: Overview of I2RS RIB Module Structure
2.1. RIB Capability 2.1. RIB Capability
RIB capability negotiation is very important because not all of the RIB capability negotiation is very important because not all of the
hardware will be able to support all kinds of nexthops and there 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 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 performed. Therefore, a RIB data model needs to specify a way for an
external entity to learn about the functional capabilities of a external entity to learn about the functional capabilities of a
network device. network device.
At the same time, nexthop chains can be used to specify multiple At the same time, nexthop chains can be used to specify multiple
headers over a packet, before that particular packet is forwarded. headers over a packet, before that particular packet is forwarded.
Not every network device will be able to support all kinds of nexthop Not every network device will be able to support all kinds of nexthop
chains along with the arbitrary number of headers which are chained chains along with the arbitrary number of headers which are chained
together. The RIB data model MUST provide a way to expose the together. The RIB data model needs a way to expose the nexthop
nexthop chaining capability supported by a given network device. chaining capability supported by a given network device.
This module uses the feature and if-feature statements to achieve This module uses the feature and if-feature statements to achieve
above capability advertisement. above capability advertisement.
2.2. Routing Instance and Rib 2.2. Routing Instance and Rib
A routing instance, in the context of the RIB information model, is a A routing instance, in the context of the RIB information model, is a
collection of RIBs, interfaces, and routing protocol parameters. A collection of RIBs, interfaces, and routing protocol parameters. A
routing instance creates a logical slice of the router and can allow routing instance creates a logical slice of the router and can allow
multiple different logical slices, across a set of routers, to multiple different logical slices, across a set of routers, to
communicate with each other. The routing protocol parameters control communicate with each other. The routing protocol parameters control
the information available in the RIBs. More detail about routing the information available in the RIBs. More details about routing
instance can be found in Section 2.2 of instance can be found in Section 2.2 of
[I-D.ietf-i2rs-rib-info-model]. [I-D.ietf-i2rs-rib-info-model].
For a routing instance, there can 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 model uses "list" to express the RIBs. The structure tree is shown
below: below:
+--rw routing-instance +--rw routing-instance
+--rw name string +--rw name string
+--rw interface-list* [name] +--rw interface-list* [name]
skipping to change at page 8, line 43 skipping to change at page 8, line 44
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 has at least one fully resolved o ACTIVE: Indicates whether a route has at least one fully resolved
nexthop and is therefore eligible for installation in the FIB. 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.
o REASON - Indicates the specific reason that caused the failure,
E.g. Not authorized.
In addition, a route can be associated with one or more optional In addition, a route can be associated with one or more optional
route attributes (e.g., route-vendor-attributes). route attributes (e.g., route-vendor-attributes).
A RIB will have a number of routes, so the routes are expressed as a 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-list* [route-index]
+--rw route-index uint64 +--rw route-index uint64
+--rw match +--rw match
| +--rw (route-type)? | +--rw (route-type)?
skipping to change at page 9, line 42 skipping to change at page 9, line 42
| +--rw interface-identifier if:interface-ref | +--rw interface-identifier if:interface-ref
+--rw nexthop +--rw nexthop
| ...(refer to Section 2.4) | ...(refer to Section 2.4)
Figure 3: Routes Structure Figure 3: Routes Structure
2.4. Nexthop 2.4. Nexthop
A nexthop represents an object resulting from a route lookup. As 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 illustrated in Section 2.4 of [I-D.ietf-i2rs-rib-info-model], to
support various use cases (e.g., load balance, protection, multicast support various use cases (e.g., load balancing, protection,
or a combination of them), the nexthop is modeled as a multi-level multicast or a combination of them), the nexthop is modeled as a
structure and supports recursion. The first level of the nexthop multi-level structure and supports recursion. The first level of the
includes the following four types: nexthop includes the following four types:
o Base: The "base" nexthop is the foundation of all other nexthop o Base: The "base" nexthop is the foundation of all other nexthop
types. It includes the follow basic nexthops: types. It includes the follow basic nexthops:
* nexthop-id * nexthop-id
* IPv4 address * IPv4 address
* IPv6 address * IPv6 address
* egress-interface * egress-interface
skipping to change at page 11, line 32 skipping to change at page 11, line 32
| | +--rw nexthop-member-id uint32 | | +--rw nexthop-member-id uint32
| | +--rw nexthop-preference nexthop-preference-definition | | +--rw nexthop-preference nexthop-preference-definition
| +--:(nexthop-load-balance) {nexthop-load-balance}? | +--:(nexthop-load-balance) {nexthop-load-balance}?
| +--rw nexthop-lb | +--rw nexthop-lb
| +--rw nexthop-list* [nexthop-member-id] | +--rw nexthop-list* [nexthop-member-id]
| +--rw nexthop-member-id uint32 | +--rw nexthop-member-id uint32
| +--rw nexthop-lb-weight nexthop-lb-weight-definition | +--rw nexthop-lb-weight nexthop-lb-weight-definition
Figure 4: Nexthop Structure Figure 4: Nexthop Structure
Figure 5 (as shown blow) is a sub-tree of nexthop, it's under the Figure 5 (as shown below) is a sub-tree of nexthop, it's under the
nexthop base node and shows that structure of the "base" nexthop. nexthop base node and shows that structure of the "base" nexthop.
+--:(nexthop-base) +--:(nexthop-base)
| +--rw nexthop-base | +--rw nexthop-base
| +--rw (nexthop-base-type)? | +--rw (nexthop-base-type)?
| +--:(special-nexthop) | +--:(special-nexthop)
| | +--rw special? special-nexthop-definition | | +--rw special? special-nexthop-definition
| +--:(egress-interface-nexthop) | +--:(egress-interface-nexthop)
| | +--rw outgoing-interface if:interface-ref | | +--rw outgoing-interface if:interface-ref
| +--:(ipv4-address-nexthop) | +--:(ipv4-address-nexthop)
skipping to change at page 12, line 40 skipping to change at page 12, line 40
| | | +--rw label-oper-id uint32 | | | +--rw label-oper-id uint32
| | | +--rw (label-actions)? | | | +--rw (label-actions)?
| | | +--:(label-push) | | | +--:(label-push)
| | | | +--rw label-push | | | | +--rw label-push
| | | | +--rw label uint32 | | | | +--rw label uint32
| | | | +--rw s-bit? boolean | | | | +--rw s-bit? boolean
| | | | +--rw tc-value? uint8 | | | | +--rw tc-value? uint8
| | | | +--rw ttl-value? uint8 | | | | +--rw ttl-value? uint8
| | | +--:(label-swap) | | | +--:(label-swap)
| | | +--rw label-swap | | | +--rw label-swap
| | | +--rw in-label uint32
| | | +--rw out-label uint32 | | | +--rw out-label uint32
| | | +--rw ttl-action? ttl-action-definition | | | +--rw ttl-action? ttl-action-definition
| | +--:(gre) {gre-tunnel}? | | +--:(gre) {gre-tunnel}?
| | | +--rw gre-header | | | +--rw gre-header
| | | +--rw (dest-address-type)? | | | +--rw (dest-address-type)?
| | | | +--:(ipv4) | | | | +--:(ipv4)
| | | | | +--rw ipv4-dest inet:ipv4-address | | | | | +--rw ipv4-dest inet:ipv4-address
| | | | +--:(ipv6) | | | | +--:(ipv6)
| | | | +--rw ipv6-dest inet:ipv6-address | | | | +--rw ipv6-dest inet:ipv6-address
| | | +--rw protocol-type uint16 | | | +--rw protocol-type uint16
skipping to change at page 14, line 29 skipping to change at page 14, line 28
This module defines the following 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 address family of the RIB and (optionally) whether the RPF check
is enabled are passed as the input parameters. The output is the is enabled are passed as the input parameters. The output is the
result of the add operation: result of the add operation:
* true - success; * true - success;
* false - failed; when failed, the i2rs agent may return the * false - failed; when failed, the i2rs agent may return the
specific reason that causes the failure. specific reason that caused the failure.
o rib-delete: Delete a RIB from a routing instance. When a RIB is 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 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 of the RIB is passed as the input parameter. The output is the
result of the delete operation: result of the delete operation:
* true - success; * true - success;
* false - failed; when failed, the i2rs agent may return the * false - failed; when failed, the i2rs agent may return the
specific reason that causes the failure. specific reason that caused 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, the route prefix(es), route attributes, route vendor attributes,
nexthop and whether return failure detail are passed as the input nexthop and whether return failure details are passed as the input
parameters. Before calling the route-add rpc, it is required to parameters. Before calling the route-add rpc, it is required to
call the nh-add rpc to create and/or return the nexthop identifier call the nh-add rpc to create and/or return the nexthop
but during situations when the nexthop already exists and the identifier. However, in situations when the nexthop already
nexthop-id is known, this action is not expected.. The output is a exists and the nexthop-id is known, this action is not expected.
combination of the route operation states while querying the The output is a combination of the route operation states while
appropriate node in the data tree that include: querying the appropriate node in the data tree that include:
* success-count: the number of routes that were successfully * success-count: the number of routes that were successfully
added; added;
* failed-count: the number of the routes that failed to be added; * failed-count: the number of the routes that failed to be added;
* failure-detail: shows the specific routes that failed to be * failure-detail: shows the specific routes that failed to be
added. added.
o route-delete: Delete a route or a set of routes from a RIB. A 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 name of the RIB, the route prefix(es) and whether to return
failure detail are passed as the input parameters. The output is failure details are passed as the input parameters. The output is
a combination of route operation states that include: a combination of route operation states that include:
* success-count: the number of routes that were successfully * success-count: the number of routes that were successfully
deleted; deleted;
* failed-count: the number of the routes that failed to be * failed-count: the number of the routes that failed to be
deleted; deleted;
* failure-detail: shows the specific routes that failed to be * failure-detail: shows the specific routes that failed to be
deleted. deleted.
skipping to change at page 16, line 6 skipping to change at page 15, line 51
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 are passed as the input parameters. The network node is required
to allocate a nexthop identifier to the nexthop. The outputs to allocate a nexthop identifier to the nexthop. The outputs
include the result of the nexthop add operation. include the result of the nexthop add operation.
* true - success; when success, a nexthop identifier will be * true - success; when success, a nexthop identifier will be
returned to the i2rs client. returned to the i2rs client.
* false - failed; when failed, the i2rs agent may return the * false - failed; when failed, the i2rs agent may return the
specific reason that causes the failure. specific reason that caused 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. nexthop or nexthop identifier are passed as the input parameters.
The output is the result of the delete operation: The output is the result of the delete operation:
* true - success; * true - success;
* false - failed; when failed, the i2rs agent may return the * false - failed; when failed, the i2rs agent may return the
specific reason that causes the failure. specific reason that caused the failure.
The structure tree of rpcs is shown in following figure. The structure tree of rpcs is shown in following figure.
rpcs: rpcs:
+---x rib-add +---x rib-add
| +---w input | +---w input
| | +---w rib-name string | | +---w rib-name string
| | +---w address-family rib-family-definition | | +---w address-family rib-family-definition
| | +---w ip-rpf-check? boolean | | +---w ip-rpf-check? boolean
| +--ro output | +--ro output
skipping to change at page 19, line 4 skipping to change at page 18, line 48
An implementation of this RIB data model MUST support sending route- An implementation of this RIB data model MUST support sending route-
change notifications whenever a route transitions between the change notifications whenever a route transitions between the
following states: following states:
o from the active state to the inactive state o from the active state to the inactive state
o from the inactive state to the active state o from the inactive state to the active state
o from the installed state to the uninstalled state o from the installed state to the uninstalled state
o from the uninstalled state to the installed state
o from the uninstalled state to the installed state
A single notification MAY be used when a route transitions from A single notification MAY be used when a route transitions from
inactive/uninstalled to active/installed or in the other direction. 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)
| | | ... | | | ...
| | +--:(nexthop-chain) {nexthop-chain}? | | +--:(nexthop-chain) {nexthop-chain}?
| | | ... | | | ...
| | +--:(nexthop-replicates) {nexthop-replicates}? | | +--:(nexthop-replicate) {nexthop-replicate}?
| | | ... | | | ...
| | +--:(nexthop-protection) {nexthop-protection}? | | +--:(nexthop-protection) {nexthop-protection}?
| | | ... | | | ...
| | +--:(nexthop-load-balance) {nexthop-load-balance}? | | +--:(nexthop-load-balance) {nexthop-load-balance}?
| | ... | | ...
| +--ro nexthop-state nexthop-state-definition | +--ro nexthop-state nexthop-state-definition
+---n route-change +---n route-change
+--ro rib-name string +--ro rib-name string
+--ro address-family rib-family-definition +--ro address-family rib-family-definition
+--ro route-index uint64 +--ro route-index uint64
skipping to change at page 20, line 7 skipping to change at page 20, line 7
| +--:(interface-route) | +--:(interface-route)
| ... | ...
+--ro route-installed-state route-installed-state-definition +--ro route-installed-state route-installed-state-definition
+--ro route-state route-state-definition +--ro route-state route-state-definition
+--ro route-change-reason route-change-reason-definition +--ro route-change-reason route-change-reason-definition
Figure 7: Notifications Structure Figure 7: Notifications Structure
3. YANG Modules 3. YANG Modules
<CODE BEGINS> file "ietf-i2rs-rib@2017-12-05.yang" <CODE BEGINS> file "ietf-i2rs-rib@2018-04-21.yang"
module ietf-i2rs-rib { module ietf-i2rs-rib {
yang-version 1.1; yang-version 1.1;
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
prefix "iir"; prefix "iir";
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference "RFC 6991"; reference "RFC 6991";
} }
import ietf-interfaces { import ietf-interfaces {
prefix if; prefix if;
reference "RFC 7223"; reference "RFC 8344";
} }
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference "RFC 6991"; reference "RFC 6991";
} }
organization organization
"IETF I2RS (Interface to Routing System) Working Group"; "IETF I2RS (Interface to Routing System) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/i2rs/> "WG Web: <http://tools.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org> WG List: <mailto:i2rs@ietf.org>
Editor: Lixing Wang Editor: Lixing Wang
<mailto:wang_little_star@sina.com> <mailto:wang_little_star@sina.com>
skipping to change at page 21, line 4 skipping to change at page 20, line 52
<mailto:amit.dass@ericsson.com> <mailto:amit.dass@ericsson.com>
Editor: Hariharan Ananthakrishnan Editor: Hariharan Ananthakrishnan
<mailto:hari@packetdesign.com> <mailto:hari@packetdesign.com>
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.
Copyright (c) <2018> IETF Trust and the persons Copyright (c) <2018> IETF Trust and the persons
identified as authors of the code. All rights reserved."; identified as authors of the code. All rights reserved.";
revision "2018-02-12" { revision "2018-02-21" {
description "initial revision"; description "initial revision";
reference "draft-ietf-i2rs-data-model-10"; reference "RFC XXXX: draft-ietf-i2rs-data-model-10";
// RFC Ed.: replace XXXX with actual RFC number and remove
// RFC Ed.: replace XXXX with actual RFC number and remove // this note
// this note
} }
//Features //Features
feature nexthop-tunnel { feature nexthop-tunnel {
description description
"This feature means that a node supports "This feature means that a node supports
tunnel nexthop capability."; tunnel nexthop capability.";
} }
feature nexthop-chain { feature nexthop-chain {
skipping to change at page 21, line 39 skipping to change at page 21, line 35
"This feature means that a node supports "This feature means that a node supports
chain nexthop capability."; chain nexthop capability.";
} }
feature nexthop-protection { feature nexthop-protection {
description description
"This feature means that a node supports "This feature means that a node supports
protection nexthop capability."; protection nexthop capability.";
} }
feature nexthop-replicates { feature nexthop-replicate {
description description
"This feature means that a node supports "This feature means that a node supports
replicates nexthop capability."; replicates nexthop capability.";
} }
feature nexthop-load-balance { feature nexthop-load-balance {
description description
"This feature means that a node supports "This feature means that a node supports
load balance nexthop capability."; load balance nexthop capability.";
} }
skipping to change at page 22, line 25 skipping to change at page 22, line 19
feature mpls-tunnel { feature mpls-tunnel {
description description
"This feature means that a node supports "This feature means that a node supports
MPLS tunnel encapsulation capability."; MPLS tunnel encapsulation capability.";
} }
feature vxlan-tunnel { feature vxlan-tunnel {
description description
"This feature means that a node supports "This feature means that a node supports
VxLAN tunnel encapsulation capability."; VXLAN tunnel encapsulation capability.";
reference "RFC7348";
} }
feature gre-tunnel { feature gre-tunnel {
description description
"This feature means that a node supports "This feature means that a node supports
GRE tunnel encapsulation capability."; GRE tunnel encapsulation capability.";
reference "RFC2784";
} }
feature nvgre-tunnel { feature nvgre-tunnel {
description description
"This feature means that a node supports "This feature means that a node supports
NvGRE tunnel encapsulation capability."; NvGRE tunnel encapsulation capability.";
reference "RFC7637";
} }
feature route-vendor-attributes { feature route-vendor-attributes {
description description
"This feature means that a node supports "This feature means that a node supports
route vendor attributes."; route vendor attributes.";
} }
//Identities and Type Definitions //Identities and Type Definitions
identity mpls-label-action { identity mpls-label-action {
skipping to change at page 24, line 6 skipping to change at page 23, line 51
identity ipv4-decapsulation { identity ipv4-decapsulation {
base "tunnel-decapsulation-action"; base "tunnel-decapsulation-action";
description description
"IPv4 tunnel decapsulation."; "IPv4 tunnel decapsulation.";
} }
identity ipv6-decapsulation { identity ipv6-decapsulation {
base "tunnel-decapsulation-action"; base "tunnel-decapsulation-action";
description description
"IPv4 tunnel decapsulation."; "IPv6 tunnel decapsulation.";
} }
typedef tunnel-decapsulation-action-definition { typedef tunnel-decapsulation-action-definition {
type identityref { type identityref {
base "tunnel-decapsulation-action"; base "tunnel-decapsulation-action";
} }
description description
"Tunnel decapsulation definition."; "Tunnel decapsulation definition.";
} }
skipping to change at page 24, line 49 skipping to change at page 24, line 47
"Decrease TTL by one and copy the TTL "Decrease TTL by one and copy the TTL
to the inner header."; to the inner header.";
} }
identity decrease-and-copy-to-next { identity decrease-and-copy-to-next {
base "ttl-action"; base "ttl-action";
description description
"Decrease TTL by one and copy the TTL "Decrease TTL by one and copy the TTL
to the next header.For example: when to the next header.For example: when
MPLS label swapping, decrease the TTL MPLS label swapping, decrease the TTL
of the inner label and copy it to the of the in_label and copy it to the
outer label."; out_label.";
} }
typedef ttl-action-definition { typedef ttl-action-definition {
type identityref { type identityref {
base "ttl-action"; base "ttl-action";
} }
description description
"TTL action definition."; "TTL action definition.";
} }
identity hop-limit-action { identity hop-limit-action {
description description
skipping to change at page 29, line 48 skipping to change at page 29, line 45
identity gre-tunnel { identity gre-tunnel {
base "tunnel-type"; base "tunnel-type";
description description
"GRE tunnel type"; "GRE tunnel type";
} }
identity vxlan-tunnel { identity vxlan-tunnel {
base "tunnel-type"; base "tunnel-type";
description description
"VxLAN tunnel type"; "VXLAN tunnel type";
} }
identity nvgre-tunnel { identity nvgre-tunnel {
base "tunnel-type"; base "tunnel-type";
description description
"NVGRE tunnel type"; "NVGRE tunnel type";
} }
typedef tunnel-type-definition { typedef tunnel-type-definition {
type identityref { type identityref {
base "tunnel-type"; base "tunnel-type";
} }
description description
"Tunnel type definition."; "Tunnel type definition.";
} }
skipping to change at page 30, line 51 skipping to change at page 30, line 50
identity nexthop-state { identity nexthop-state {
description description
"Base identity from which all nexthop "Base identity from which all nexthop
states are derived."; states are derived.";
} }
identity resolved { identity resolved {
base "nexthop-state"; base "nexthop-state";
description description
"Reolved nexthop state."; "Resolved nexthop state.";
} }
identity unresolved { identity unresolved {
base "nexthop-state"; base "nexthop-state";
description description
"Unresolved nexthop state."; "Unresolved nexthop state.";
} }
typedef nexthop-state-definition { typedef nexthop-state-definition {
type identityref { type identityref {
base "nexthop-state"; base "nexthop-state";
} }
skipping to change at page 33, line 21 skipping to change at page 33, line 20
typedef nexthop-lb-weight-definition { typedef nexthop-lb-weight-definition {
type uint8 { type uint8 {
range "1..99"; range "1..99";
} }
description description
"Nexthop-lb-weight is used for load-balancing. "Nexthop-lb-weight is used for load-balancing.
Each list member MUST be assigned a weight Each list member MUST be assigned a weight
between 1 and 99. The weight determines the between 1 and 99. The weight determines the
proportion of traffic to be sent over a nexthop proportion of traffic to be sent over a nexthop
used for forwarding as a ratio of the weight of used for forwarding as a ratio of the weight of
this nexthop divided by the weights of all the this nexthop divided by the sum of the weights
nexthops of this route that are used for forwarding. of all the nexthops of this route that are used
To perform equal load-balancing, one MAY specify for forwarding.To perform equal load-balancing,
a weight of 0 for all the member nexthops. The one MAY specify a weight of 0 for all the member
value 0 is reserved for equal load-balancing nexthops. The value 0 is reserved for equal
and if applied, MUST be applied to all member nexthops."; load-balancing and if applied, MUST be applied
to all member nexthops.
Note: The weight of 0 is specially because of
historical reasons. It's typically used in
hardware devices to signify ECMP";
} }
typedef nexthop-ref { typedef nexthop-ref {
type leafref { type leafref {
path "/iir:routing-instance" + path "/iir:routing-instance" +
"/iir:rib-list" + "/iir:rib-list" +
"/iir:route-list" + "/iir:route-list" +
"/iir:nexthop" + "/iir:nexthop" +
"/iir:nexthop-id"; "/iir:nexthop-id";
} }
skipping to change at page 36, line 31 skipping to change at page 36, line 34
type uint32 ; type uint32 ;
mandatory true; mandatory true;
description description
"The label used for matching."; "The label used for matching.";
} }
} }
case mac-route { case mac-route {
description description
"MAC route case."; "MAC route case.";
leaf mac-address { leaf mac-address {
type uint32 ; type yang:mac-address;
mandatory true; mandatory true;
description description
"The MAC address used for matching."; "The MAC address used for matching.";
} }
} }
case interface-route { case interface-route {
description description
"Interface route case."; "Interface route case.";
leaf interface-identifier { leaf interface-identifier {
type if:interface-ref; type if:interface-ref;
skipping to change at page 37, line 33 skipping to change at page 37, line 37
type route-installed-state-definition; type route-installed-state-definition;
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-change-reason-definition; type route-change-reason-definition;
config false; config false;
description description
"Indicate the reason that causes the route change."; "Indicate the reason that caused the route change.";
} }
} }
container route-attributes { container route-attributes {
description description
"Route attributes."; "Route attributes.";
uses route-attributes; uses route-attributes;
} }
container route-vendor-attributes { container route-vendor-attributes {
description description
"Route vendor attributes."; "Route vendor attributes.";
skipping to change at page 40, line 12 skipping to change at page 40, line 16
} }
} }
case nexthop-chain { case nexthop-chain {
if-feature nexthop-chain; if-feature nexthop-chain;
container nexthop-chain { container nexthop-chain {
description description
"A chain nexthop."; "A chain nexthop.";
uses nexthop-list; uses nexthop-list;
} }
} }
case nexthop-replicates { case nexthop-replicate {
if-feature nexthop-replicates; if-feature nexthop-replicate;
container nexthop-replicates { container nexthop-replicate {
description description
"A replicates nexthop."; "A replicates nexthop.";
uses nexthop-list; uses nexthop-list;
} }
} }
case nexthop-protection { case nexthop-protection {
if-feature nexthop-protection; if-feature nexthop-protection;
container nexthop-protection { container nexthop-protection {
description description
"A protection nexthop."; "A protection nexthop.";
skipping to change at page 42, line 31 skipping to change at page 42, line 34
} }
case egress-interface-mac-nexthop { case egress-interface-mac-nexthop {
container egress-interface-mac-address { container egress-interface-mac-address {
leaf outgoing-interface { leaf outgoing-interface {
type if:interface-ref; type if:interface-ref;
mandatory true; mandatory true;
description description
"Name of the outgoing interface."; "Name of the outgoing interface.";
} }
leaf ieee-mac-address { leaf ieee-mac-address {
type uint32; type yang:mac-address;
mandatory true; mandatory true;
description description
"The nexthop points to an interface with "The nexthop points to an interface with
a specific mac-address."; a specific mac-address.";
} }
description description
"The egress interface must be an Ethernet "The egress interface must be an Ethernet
interface. Address resolution is not required interface. Address resolution is not required
for this nexthop."; for this nexthop.";
} }
} }
case tunnel-encap-nexthop { case tunnel-encap-nexthop {
if-feature nexthop-tunnel; if-feature nexthop-tunnel;
container tunnel-encap { container tunnel-encap {
uses tunnel-encap; uses tunnel-encap;
description description
"This can be an encap representing an IP tunnel or "This can be an encapsulation representing an IP
MPLS tunnel or others as defined in info model. tunnel or MPLS tunnel or others as defined in info
An optional egress interface can be chained to the model. An optional egress interface can be chained
tunnel encap to indicate which interface to send to the tunnel encapsulation to indicate which
the packet out on. The egress interface is useful interface to send the packet out on. The egress
when the network device contains Ethernet interfaces interface is useful when the network device
and one needs to perform address resolution for the contains Ethernet interfaces and one needs to
IP packet."; perform address resolution for the IP packet.";
} }
} }
case tunnel-decapsulation-nexthop { case tunnel-decapsulation-nexthop {
if-feature nexthop-tunnel; if-feature nexthop-tunnel;
container tunnel-decapsulation { container tunnel-decapsulation {
uses tunnel-decapsulation; uses tunnel-decapsulation;
description description
"This is to specify the decapsulation of a tunnel header."; "This is to specify the decapsulation of a tunnel header.";
} }
} }
skipping to change at page 45, line 35 skipping to change at page 45, line 38
mandatory true; mandatory true;
description description
"The next header of the IPv6 header."; "The next header of the IPv6 header.";
} }
leaf traffic-class { leaf traffic-class {
type uint8; type uint8;
description description
"The traffic class value of the header."; "The traffic class value of the header.";
} }
leaf flow-label { leaf flow-label {
type uint16; type inet:ipv6-flow-label;
description description
"The flow label of the header."; "The flow label of the header.";
} }
leaf hop-limit { leaf hop-limit {
type uint8; type uint8 {
range "1..255";
}
description description
"The hop limit the header."; "The hop limit of the header.";
} }
} }
grouping nvgre-header { grouping nvgre-header {
description description
"The NvGRE header encapsulation information."; "The NvGRE header encapsulation information.";
choice nvgre-type { choice nvgre-type {
description description
"NvGRE can use eigher IPv4 "NvGRE can use either IPv4
or IPv6 header for encapsulation."; or IPv6 header for encapsulation.";
case ipv4 { case ipv4 {
uses ipv4-header; uses ipv4-header;
} }
case ipv6 { case ipv6 {
uses ipv6-header; uses ipv6-header;
} }
} }
leaf virtual-subnet-id { leaf virtual-subnet-id {
type uint32; type uint32;
mandatory true; mandatory true;
skipping to change at page 46, line 27 skipping to change at page 46, line 32
} }
leaf flow-id { leaf flow-id {
type uint16; type uint16;
description description
"The flow identifier of the NvGRE header."; "The flow identifier of the NvGRE header.";
} }
} }
grouping vxlan-header { grouping vxlan-header {
description description
"The VxLAN encapsulation header information."; "The VXLAN encapsulation header information.";
choice vxlan-type { choice vxlan-type {
description description
"NvGRE can use either IPv4 "NvGRE can use either IPv4
or IPv6 header for encapsulation."; or IPv6 header for encapsulation.";
case ipv4 { case ipv4 {
uses ipv4-header; uses ipv4-header;
} }
case ipv6 { case ipv6 {
uses ipv6-header; uses ipv6-header;
} }
} }
leaf vxlan-identifier { leaf vxlan-identifier {
type uint32; type uint32;
mandatory true; mandatory true;
description description
"The VxLAN identifier of the VxLAN header."; "The VXLAN identifier of the VXLAN header.";
} }
} }
grouping gre-header { grouping gre-header {
description description
"The GRE encapsulation header information."; "The GRE encapsulation header information.";
choice dest-address-type { choice dest-address-type {
description description
"GRE options: IPv4 and IPv6"; "GRE options: IPv4 and IPv6";
case ipv4 { case ipv4 {
leaf ipv4-dest { leaf ipv4-dest {
type inet:ipv4-address; type inet:ipv4-address;
mandatory true; mandatory true;
description description
"The destination IP address of the GRE header."; "The destination IP address of the GRE header.";
} }
} }
case ipv6 { case ipv6 {
leaf ipv6-dest { leaf ipv6-dest {
skipping to change at page 48, line 51 skipping to change at page 49, line 9
mandatory true; mandatory true;
description description
"The out MPLS label."; "The out MPLS label.";
} }
leaf ttl-action { leaf ttl-action {
type ttl-action-definition; type ttl-action-definition;
description description
"The label ttl actions: "The label ttl actions:
- No-action, or - No-action, or
- Copy to inner label,or - Copy to inner label,or
- Decrease (the in label) by 1 and - Decrease (the in-label) by 1 and
copy to the out label."; copy to the out-label.";
} }
} }
} }
} }
} }
} }
grouping tunnel-encap{ grouping tunnel-encap{
description description
"Tunnel encapsulation information."; "Tunnel encapsulation information.";
skipping to change at page 50, line 15 skipping to change at page 50, line 21
uses nvgre-header; uses nvgre-header;
description description
"NvGRE header."; "NvGRE header.";
} }
} }
case vxlan { case vxlan {
if-feature vxlan-tunnel; if-feature vxlan-tunnel;
container vxlan-header { container vxlan-header {
uses vxlan-header; uses vxlan-header;
description description
"VxLAN header."; "VXLAN header.";
} }
} }
} }
} }
grouping tunnel-decapsulation { grouping tunnel-decapsulation {
description description
"Tunnel decapsulation information."; "Tunnel decapsulation information.";
choice tunnel-type { choice tunnel-type {
description description
skipping to change at page 54, line 44 skipping to change at page 54, line 52
type boolean; type boolean;
mandatory true; mandatory true;
description description
"Return the result of the rib-add operation. "Return the result of the rib-add operation.
true - success; true - success;
false - failed"; false - failed";
} }
leaf reason { leaf reason {
type string; type string;
description description
"The specific reason that causes the failure."; "The specific reason that caused the failure.";
} }
} }
} }
rpc rib-delete { rpc rib-delete {
description description
"To delete a RIB from a routing instance. "To delete a RIB from a routing instance.
After deleting the RIB, all routes installed After deleting the RIB, all routes installed
in the RIB will be deleted as well."; in the RIB will be deleted as well.";
input { input {
leaf name { leaf name {
type string; type string;
mandatory true; mandatory true;
description description
"A reference to the name of the RIB "A reference to the name of the RIB
that is to be deleted."; that is to be deleted.";
} }
skipping to change at page 55, line 28 skipping to change at page 55, line 35
type boolean; type boolean;
mandatory true; mandatory true;
description description
"Return the result of the rib-delete operation. "Return the result of the rib-delete operation.
true - success; true - success;
false - failed"; false - failed";
} }
leaf reason { leaf reason {
type string; type string;
description description
"The specific reason that causes failure."; "The specific reason that caused failure.";
} }
} }
} }
grouping route-operation-state { grouping route-operation-state {
description description
"Route operation state."; "Route operation state.";
leaf success-count { leaf success-count {
type uint32; type uint32;
mandatory true; mandatory true;
skipping to change at page 56, line 18 skipping to change at page 56, line 25
description description
"The list of failed routes."; "The list of failed routes.";
leaf route-index { leaf route-index {
type uint32; type uint32;
description description
"The route index of the failed route."; "The route index of the failed route.";
} }
leaf error-code { leaf error-code {
type uint32; type uint32;
description description
"The error code that reflects the failure reason."; "The error code that reflects the failure reason.
0 - Reserved.
1 - Trying to add a repeat route;
2 - Trying to delete or update a route that is not exist;
3 - Malformed route attribute;
";
} }
} }
} }
} }
rpc route-add { rpc route-add {
description 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 { input {
leaf return-failure-detail { leaf return-failure-detail {
skipping to change at page 62, line 7 skipping to change at page 62, line 20
type boolean; type boolean;
mandatory true; mandatory true;
description description
"Return the result of the rib-add operation. "Return the result of the rib-add operation.
true - success; true - success;
false - failed;"; false - failed;";
} }
leaf reason { leaf reason {
type string; type string;
description description
"The specific reason that causes the failure."; "The specific reason that caused the failure.";
} }
leaf nexthop-id { leaf nexthop-id {
type uint32; type uint32;
description description
"A nexthop identifier that is allocated to the nexthop."; "A nexthop identifier that is allocated to the nexthop.";
} }
} }
} }
rpc nh-delete { rpc nh-delete {
skipping to change at page 62, line 41 skipping to change at page 63, line 5
type boolean; type boolean;
mandatory true; mandatory true;
description description
"Return the result of the rib-add operation. "Return the result of the rib-add operation.
true - success; true - success;
false - failed."; false - failed.";
} }
leaf reason { leaf reason {
type string; type string;
description description
"The specific reason that causes the failure."; "The specific reason that caused the failure.";
} }
} }
} }
/*Notifications*/ /*Notifications*/
notification nexthop-resolution-status-change { notification nexthop-resolution-status-change {
description description
"Nexthop resolution status (resolved/unresolved) "Nexthop resolution status (resolved/unresolved)
notification."; notification.";
container nexthop{ container nexthop{
skipping to change at page 64, line 10 skipping to change at page 64, line 22
"The reasons that cause the route change. A route "The reasons that cause the route change. A route
change that may result from several reasons. For change that may result from several reasons. For
example, a nexthop becoming resolved will make a example, a nexthop becoming resolved will make a
route A active which is of better preference than route A active which is of better preference than
a currently active route B, which results in the a currently active route B, which results in the
route A being installed"; route A being installed";
leaf route-change-reason { leaf route-change-reason {
type route-change-reason-definition; type route-change-reason-definition;
mandatory true; mandatory true;
description description
"The reason that causes the route change."; "The reason that caused the route change.";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
4. IANA Considerations 4. IANA Considerations
This document registers a URI in the "ns" registry with the "IETF XML This document registers a URI in the "ns" registry with the "IETF XML
registry" [RFC3688]: registry" [RFC3688]:
-------------------------------------------------------------------- --------------------------------------------------------------------
URI: urn:ietf:params:xml:ns:yang:ietf-i2rs-rib URI: urn:ietf:params:xml:ns:yang:ietf-i2rs-rib
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
-------------------------------------------------------------------- --------------------------------------------------------------------
This document requests to register a YANG module in the "YANG Module This document requests to register a YANG module in the "YANG Module
Names registry" [RFC6020]: Names registry" [RFC7950]:
-------------------------------------------------------------------- --------------------------------------------------------------------
name: ietf-i2rs-rib name: ietf-i2rs-rib
namespace: urn:ietf:params:xml:ns:yang:ietf-i2rs-rib namespace: urn:ietf:params:xml:ns:yang:ietf-i2rs-rib
prefix: iir prefix: iir
reference: RFC XXXX reference: RFC XXXX
-------------------------------------------------------------------- --------------------------------------------------------------------
5. Security Considerations 5. Security Considerations
The YANG module specified in this document defines a schema for data The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC5246]. [RFC5246].
The NETCONF access control model [RFC6536] provides the means to The NETCONF access control model [RFC8341] provides the means to
restrict access for particular NETCONF or RESTCONF users to a restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content. operations and content.
The YANG modules define information that can be configurable in 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 created or deleted by client applications, the YANG modules also
define RPCs that can be used by client applications to add/delete define RPCs that can be used by client applications to add/delete
RIBs, routes and nexthops. In such cases, a malicious client could RIBs, routes and nexthops. In such cases, a malicious client could
attempt to remove, add or update a RIB, a route, a nexthop, by attempt to remove, add or update a RIB, a route, a nexthop, by
skipping to change at page 66, line 7 skipping to change at page 66, line 19
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. Acknowledgements 7. Acknowledgements
The authors would like to thank Chris Bowers and John Scudder for his The authors would like to thank Chris Bowers, John Scudder, Tom
review, suggestion and comments to this document. Petch, Mike McBride and Ebben Aries for his review, suggestion and
comments to this document.
8. References 8. References
8.1. Normative 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 [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,
<https://www.rfc-editor.org/info/rfc2119>. <https://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,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>. <https://www.rfc-editor.org/info/rfc6242>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536,
DOI 10.17487/RFC6536, March 2012,
<https://www.rfc-editor.org/info/rfc6536>.
[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,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 8344, DOI 10.17487/RFC8344, March 2018,
<https://www.rfc-editor.org/info/rfc8344>.
8.2. Informative References 8.2. Informative References
[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-13 (work Base Info Model", draft-ietf-i2rs-rib-info-model-15 (work
in progress), January 2018. in progress), March 2018.
[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-03 Requirements", draft-ietf-i2rs-usecase-reqs-summary-03
(work in progress), November 2016. (work in progress), November 2016.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015,
<https://www.rfc-editor.org/info/rfc7637>.
[RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. [RFC7921] 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", RFC 7921, DOI 10.17487/RFC7921, June 2016, System", RFC 7921, DOI 10.17487/RFC7921, June 2016,
<https://www.rfc-editor.org/info/rfc7921>. <https://www.rfc-editor.org/info/rfc7921>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
Authors' Addresses Authors' Addresses
Lixing Wang Lixing Wang
Individual Individual
Email: wang_little_star@sina.com Email: wang_little_star@sina.com
Mach(Guoyi) Chen Mach(Guoyi) Chen
Huawei Huawei
 End of changes. 81 change blocks. 
117 lines changed or deleted 149 lines changed or added

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