draft-ietf-i2rs-rib-data-model-08.txt   draft-ietf-i2rs-rib-data-model-09.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: January 4, 2018 Packet Design Expires: June 9, 2018 Packet Design
M. Chen M. Chen
Huawei Huawei
A. Dass A. Dass
S. Kini
Ericsson Ericsson
S. Kini
Individual
N. Bahadur N. Bahadur
Bracket Computing Bracket Computing
July 3, 2017 December 6, 2017
A YANG Data Model for Routing Information Base (RIB) A YANG Data Model for Routing Information Base (RIB)
draft-ietf-i2rs-rib-data-model-08 draft-ietf-i2rs-rib-data-model-09
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
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 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 January 4, 2018. This Internet-Draft will expire on June 9, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 (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
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
skipping to change at page 2, line 36 skipping to change at page 2, line 36
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 . . . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . . 20 3. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 20
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64
5. Security Considerations . . . . . . . . . . . . . . . . . . . 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 64
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 65 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 65
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 66
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.1. Normative References . . . . . . . . . . . . . . . . . . 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 66
8.2. Informative References . . . . . . . . . . . . . . . . . 65 8.2. Informative References . . . . . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67
1. Introduction 1. Introduction
The Interface to the Routing System (I2RS) The Interface to the Routing System (I2RS) [RFC7921] provides read
[I-D.ietf-i2rs-architecture] provides read and write access to the and write access to the information and state within the routing
information and state within the routing process that exists inside process that exists inside the routing elements, this is achieved via
the routing elements, this is achieved via protocol message exchange protocol message exchange between I2RS clients and I2RS agents
between I2RS clients and I2RS agents associated with the routing associated with the routing system. One of the functions of I2RS is
system. One of the functions of I2RS is to read and write data of to read and write data of Routing Information Base (RIB).
Routing Information Base (RIB). [I-D.ietf-i2rs-usecase-reqs-summary] [I-D.ietf-i2rs-usecase-reqs-summary] introduces a set of RIB use
introduces a set of RIB use cases. The RIB information model is cases. The RIB information model is defined in
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 [RFC6020][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
Information Model (IM): An abstract model of a conceptual domain, Information Model (IM): An abstract model of a conceptual domain,
skipping to change at page 3, line 50 skipping to change at page 3, line 50
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
+--rw name string +--rw name string
+--rw interface-list* [name] +--rw interface-list* [name]
| +--rw name if:interface-ref | +--rw name if:interface-ref
+--rw router-id? yang:dotted-quad +--rw router-id? yang:dotted-quad
+--rw lookup-limit? uint8 +--rw lookup-limit? uint8
+--rw rib-list* [name] +--rw rib-list* [name]
+--rw name string +--rw name string
+--rw address-family rib-family-def +--rw address-family rib-family-def
+--rw ip-rpf-check? boolean +--rw ip-rpf-check? boolean
+--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)?
| | +--:(ipv4) | | +--:(ipv4)
| | | ... | | | ...
| | +--:(ipv6) | | +--:(ipv6)
| | | ... | | | ...
| | +--:(mpls-route) | | +--:(mpls-route)
skipping to change at page 4, line 42 skipping to change at page 4, line 42
| | +--:(nexthop-protection) {nexthop-protection}? | | +--:(nexthop-protection) {nexthop-protection}?
| | | ... | | | ...
| | +--:(nexthop-load-balance) {nexthop-load-balance}? | | +--:(nexthop-load-balance) {nexthop-load-balance}?
| | ... | | ...
| +--rw route-status | +--rw route-status
| | ... | | ...
| +--rw route-attributes | +--rw route-attributes
| | ... | | ...
| +--rw route-vendor-attributes | +--rw route-vendor-attributes
+--rw nexthop-list* [nexthop-member-id] +--rw nexthop-list* [nexthop-member-id]
+--rw nexthop-member-id uint32 +--rw nexthop-member-id uint32
rpcs: rpcs:
+---x rib-add +---x rib-add
| +---w input | +---w input
| | +---w name string | | +---w name string
| | +---w address-family rib-family-def | | +---w address-family rib-family-def
| | +---w ip-rpf-check? boolean | | +---w ip-rpf-check? boolean
| +--ro output | +--ro output
| +--ro result uint32 | +--ro result uint32
| +--ro reason? string | +--ro reason? string
+---x rib-delete +---x rib-delete
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-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-change-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@2016-07-04.yang" <CODE BEGINS> file "ietf-i2rs-rib@2017-12-05.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
} }
skipping to change at page 21, line 11 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 "2016-07-04" { revision "2017-12-05" {
description "initial revision"; description "initial revision";
reference "draft-ietf-i2rs-data-model-06"; reference "draft-ietf-i2rs-data-model-09";
} }
//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 64, line 40 skipping to change at page 64, line 40
-------------------------------------------------------------------- --------------------------------------------------------------------
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
I2RS protocol provides read and write access to the information and The YANG module defined in this document is designed to be accessed
state (e.g., RIB) within the routing process that exists inside the via network management protocols such as NETCONF [RFC6241] or
routing elements. These information and state are normally RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport
considered sensitive or vulnerable. Improper write operations to layer, and the mandatory-to-implement secure transport is Secure
these information and state can have negative effects on the network. Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the
mandatory-to-implement secure transport is TLS [RFC5246].
The I2RS protocol will provide security mechanisms as required in The NETCONF access control model [RFC6536] provides the means to
[I-D.ietf-i2rs-security-environment-reqs] and restrict access for particular NETCONF or RESTCONF users to a
[I-D.ietf-i2rs-protocol-security-requirements]. preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
The YANG data model defined in this document itself does not The YANG modules define information that can be configurable in
introduce extra security issues. certain instances, for example, a rib, a route, a nexthop can be
created or deleted by client applications, the YANG modules also
define RPCs that can be used by client applications to add/delete
ribs, routes and nexthops. In such cases, a malicious client could
attempt to remove, add or update a rib, a route, a nexthop, by
creating or deleting corresponding elements in the rib, route and
nexthop lists, respectively. Removing a rib or a route could lead to
disruption or impact in performance of a service, updating a route
may lead to suboptimal path and degradation of service levels as well
as possibly disruption of service. For those reasons, it is
important that the NETCONF access control model is vigorously applied
to prevent misconfiguration by unauthorized clients.
Specifically, there are a number of data nodes defined in the YANG
module that are writable/creatable/deletable (i.e., config true,
which is the default). These data nodes may be considered sensitive
or vulnerable in some network environments. Write operations (e.g.,
edit-config) to these data nodes without proper protection can have a
negative effect on network operations. These are the subtrees and
data nodes and their sensitivity/vulnerability in the ietf-i2rs-rib
module:
o rib: A malicious client could attempt to remove a rib from a
routing instance, for example in order to sabotage the services
provided by the rib, or to add a rib to a routing instance, hence
to inject unauthorized traffic into the nexthop.
o route:A malicious client could attempt to remove or add a route
from/to a rib, for example in order to sabotage the services
provided by the rib.
o nexthop: A malicious client could attempt to remove or add a
nexthop from/to rib, which may lead to suboptimal path and
degradation of service levels as well as possibly disruption of
service.
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
skipping to change at page 65, line 27 skipping to change at page 66, line 17
The authors would like to thank Chris Bowers and John Scudder for his The authors would like to thank Chris Bowers and John Scudder for his
review, suggestion and comments to this document. review, suggestion and comments to this document.
8. References 8. References
8.1. Normative 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>. <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,
<http://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[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>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<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,
<http://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
8.2. Informative References
[I-D.ietf-i2rs-architecture] [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
Nadeau, "An Architecture for the Interface to the Routing <https://www.rfc-editor.org/info/rfc8040>.
System", draft-ietf-i2rs-architecture-15 (work in
progress), April 2016.
[I-D.ietf-i2rs-protocol-security-requirements] 8.2. Informative References
Hares, S., Migault, D., and J. Halpern, "I2RS Security
Related Requirements", draft-ietf-i2rs-protocol-security-
requirements-17 (work in progress), September 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-11 (work Base Info Model", draft-ietf-i2rs-rib-info-model-12 (work
in progress), June 2017. in progress), November 2017.
[I-D.ietf-i2rs-security-environment-reqs]
Migault, D., Halpern, J., and S. Hares, "I2RS Environment
Security Requirements", draft-ietf-i2rs-security-
environment-reqs-05 (work in progress), March 2017.
[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.
[RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing
System", RFC 7921, DOI 10.17487/RFC7921, June 2016,
<https://www.rfc-editor.org/info/rfc7921>.
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.
Stockholm 16480
Sweden
Email: amit.dass@ericsson.com Email: amit.dass@ericsson.com
Sriganesh Kini Sriganesh Kini
Ericsson Individual
Email: sriganesh.kini@ericsson.com Email: sriganeshkini@gmail.com
Nitin Bahadur Nitin Bahadur
Bracket Computing Bracket Computing
Email: nitin_bahadur@yahoo.com Email: nitin_bahadur@yahoo.com
 End of changes. 30 change blocks. 
64 lines changed or deleted 110 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/