RFC 8695: A YANG Data Model for the Routing Information Protocol (RIP)
- X. Liu,
- P. Sarda,
- V. Choudhary
Abstract
This document describes a data model for the management of the Routing Information Protocol (RIP). Both RIP version 2 and RIPng are covered. The data model includes definitions for configuration, operational state, and Remote Procedure Calls (RPCs).¶
The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA).¶
Status of This Memo
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://
1. Introduction
This document introduces a YANG [RFC7950] data model for the Routing Information Protocol (RIP) [RFC2453][RFC2080]. RIP was designed to work as an Interior Gateway Protocol (IGP) in moderate-size Autonomous Systems (AS).¶
This YANG data model supports both RIP version 2 and RIPng. RIP version 2 (defined in [RFC2453]) supports IPv4. RIPng (defined in [RFC2080]) supports IPv6.¶
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The following terms are defined in [RFC7950] and are not redefined here:¶
1.2. Tree Diagrams
A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is defined in [RFC8340].¶
1.3. Prefixes in Data Node Names
In this document, names of data nodes, actions, and other data model objects are often used without a prefix, as long as it is clear from the context in which YANG module each name is defined. Otherwise, names are prefixed using the standard prefix associated with the corresponding YANG module, as shown in Table 1.¶
2. Design of the Data Model
2.1. Scope of the Data Model
The data model covers RIP version 2 [RFC2453] and RIPng [RFC2080] protocols. The model is designed to be implemented on a device where RIP version 2 or RIPng is implemented, and can be used to:¶
2.2. Relation to the Core Routing Framework
This data model augments the core routing data model "ietf-routing" specified in [RFC8349].¶
The "rip" container instantiates a RIP entity that supports RIP version 2 or RIPng. Depending on the implementation of "ietf-routing", a RIP instance MAY belong to a logical router or network instance.¶
2.3. Protocol Configuration
The data model structure for the protocol configuration is as shown below:¶
The data model allows the configuration of the following protocol entities:¶
2.4. Protocol States
The data model structure for the protocol states is as shown below:¶
This model conforms to the Network Management Datastore Architecture (NMDA) [RFC8342]. The operational state data is combined with the associated configuration data in the same hierarchy [RFC8407]. When protocol states are retrieved from the NMDA operational state datastore, the returned states cover all "config true" (rw) and "config false" (ro) nodes defined in the schema.¶
The model allows the retrieval of protocol states at the following levels:¶
2.5. RPC Operations
This model defines one RPC "clear
2.6. Notifications
This model does not define RIP-specific notifications. To enable notifications, the mechanisms defined in [RFC8639] and [RFC8641] can be used. This mechanism currently allows the user to do the following:¶
2.7. Optional Features
This model defines several features that are beyond the basic RIP configuration, and it is the responsibility of each vendor to decide whether to support a given feature on a device.¶
3. Tree Structure
This document defines the YANG module "ietf-rip", which has the following tree structure:¶
5. IANA Considerations
This document registers the following namespace URIs in the "IETF XML Registry" [RFC3688]:¶
- URI:
- urn
:ietf :params :xml :ns :yang :ietf -rip¶ - Registrant Contact:
- The IESG.¶
- XML:
- N/A; the requested URI is an XML namespace.¶
This document registers the following YANG modules in the "YANG Module Names" registry [RFC6020]:¶
6. Security Considerations
The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory
The NETCONF Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.¶
There are a number of data nodes defined in this YANG module that are
writable
Unauthorized access to any data node of these subtrees can adversely affect the routing subsystem of both the local device and the network. This may lead to network malfunctions, delivery of packets to inappropriate destinations, and other problems.¶
Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity
Unauthorized access to any data node of these subtrees can disclose the operational state information of RIP on this device.¶
Some of the RPC operations in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control access to these operations. These are the
operations and their sensitivity
RPC clear
Unauthorized access to the RPC above can adversely affect the routing subsystem of both the local device and the network. This may lead to network malfunctions, delivery of packets to inappropriate destinations, and other problems.¶
7. References
7.1. Normative References
- [RFC1724]
-
Malkin, G. and F. Baker, "RIP Version 2 MIB Extension", RFC 1724, DOI 10
.17487 , , <https:///RFC1724 www >..rfc -editor .org /info /rfc1724 - [RFC2119]
-
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10
.17487 , , <https:///RFC2119 www >..rfc -editor .org /info /rfc2119 - [RFC2453]
-
Malkin, G., "RIP Version 2", STD 56, RFC 2453, DOI 10
.17487 , , <https:///RFC2453 www >..rfc -editor .org /info /rfc2453 - [RFC2080]
-
Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, DOI 10
.17487 , , <https:///RFC2080 www >..rfc -editor .org /info /rfc2080 - [RFC3688]
-
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10
.17487 , , <https:///RFC3688 www >..rfc -editor .org /info /rfc3688 - [RFC6020]
-
Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10
.17487 , , <https:///RFC6020 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 , , <https:///RFC6241 www >..rfc -editor .org /info /rfc6241 - [RFC6242]
-
Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10
.17487 , , <https:///RFC6242 www >..rfc -editor .org /info /rfc6242 - [RFC6991]
-
Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10
.17487 , , <https:///RFC6991 www >..rfc -editor .org /info /rfc6991 - [RFC7950]
-
Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10
.17487 , , <https:///RFC7950 www >..rfc -editor .org /info /rfc7950 - [RFC8040]
-
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10
.17487 , , <https:///RFC8040 www >..rfc -editor .org /info /rfc8040 - [RFC8174]
-
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10
.17487 , , <https:///RFC8174 www >..rfc -editor .org /info /rfc8174 - [RFC8177]
-
Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. Zhang, "YANG Data Model for Key Chains", RFC 8177, DOI 10
.17487 , , <https:///RFC8177 www >..rfc -editor .org /info /rfc8177 - [RFC8341]
-
Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10
.17487 , , <https:///RFC8341 www >..rfc -editor .org /info /rfc8341 - [RFC8342]
-
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10
.17487 , , <https:///RFC8342 www >..rfc -editor .org /info /rfc8342 - [RFC8343]
-
Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10
.17487 , , <https:///RFC8343 www >..rfc -editor .org /info /rfc8343 - [RFC8344]
-
Bjorklund, M., "A YANG Data Model for IP Management", RFC 8344, DOI 10
.17487 , , <https:///RFC8344 www >..rfc -editor .org /info /rfc8344 - [RFC8349]
-
Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10
.17487 , , <https:///RFC8349 www >..rfc -editor .org /info /rfc8349 - [RFC8446]
-
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10
.17487 , , <https:///RFC8446 www >..rfc -editor .org /info /rfc8446
7.2. Informative References
- [RFC7951]
-
Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10
.17487 , , <https:///RFC7951 www >..rfc -editor .org /info /rfc7951 - [RFC8340]
-
Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10
.17487 , , <https:///RFC8340 www >..rfc -editor .org /info /rfc8340 - [RFC8407]
-
Bierman, A., "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", BCP 216, RFC 8407, DOI 10
.17487 , , <https:///RFC8407 www >..rfc -editor .org /info /rfc8407 - [RFC8639]
-
Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Subscription to YANG Notifications", RFC 8639, DOI 10
.17487 , , <https:///RFC8639 www >..rfc -editor .org /info /rfc8639 - [RFC8641]
-
Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10
.17487 , , <https:///RFC8641 www >..rfc -editor .org /info /rfc8641 - [YANG-BFD]
-
Rahman, R., Zheng, L., Jethanandani, M., Pallagatti, S., and G. Mirsky, "YANG Data Model for Bidirectional Forwarding Detection (BFD)", Work in Progress, Internet-Draft, draft
-ietf , , <https://-bfd -yang -17 tools >..ietf .org /html /draft -ietf -bfd -yang -17 - [YANG-ISIS]
-
Litkowski, S., Yeung, D., Lindem, A., Zhang, Z., and L. Lhotka, "YANG Data Model for IS-IS Protocol", Work in Progress, Internet-Draft, draft
-ietf , , <https://-isis -yang -isis -cfg -42 tools >..ietf .org /html /draft -ietf -isis -yang -isis -cfg -42 - [YANG-OSPF]
-
Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, "YANG Data Model for OSPF Protocol", Work in Progress, Internet-Draft, draft
-ietf , , <https://-ospf -yang -29 tools >..ietf .org /html /draft -ietf -ospf -yang -29
Appendix A. Data Tree Example
This section contains an example of an instance data tree in the JSON encoding [RFC7951], containing both configuration and state data.¶
The configuration instance data tree for Router 203.0.113.1 in Figure 1 could be as follows:¶
The corresponding operational state data for Router 203.0.113.1 could be as follows:¶