draft-ietf-i2rs-rib-info-model-13.txt   draft-ietf-i2rs-rib-info-model-14.txt 
Network Working Group N. Bahadur, Ed. Network Working Group N. Bahadur, Ed.
Internet-Draft Uber Internet-Draft Uber
Intended status: Informational S. Kini, Ed. Intended status: Informational S. Kini, Ed.
Expires: July 27, 2018 Expires: August 17, 2018
J. Medved J. Medved
Cisco Cisco
January 23, 2018 February 13, 2018
Routing Information Base Info Model Routing Information Base Info Model
draft-ietf-i2rs-rib-info-model-13 draft-ietf-i2rs-rib-info-model-14
Abstract Abstract
Routing and routing functions in enterprise and carrier networks are Routing and routing functions in enterprise and carrier networks are
typically performed by network devices (routers and switches) using a typically performed by network devices (routers and switches) using a
routing information base (RIB). Protocols and configuration push routing information base (RIB). Protocols and configuration push
data into the RIB and the RIB manager installs state into the data into the RIB and the RIB manager installs state into the
hardware; for packet forwarding. This draft specifies a information hardware; for packet forwarding. This draft specifies an information
model for the RIB to enable defining a standardized data model. Such model for the RIB to enable defining a standardized data model, and
a data model can be used to define an interface to the RIB from an it was used by the IETF's I2RS WG to design the I2RS RIB data model.
entity that may even be external to the network device. This It is being published to record the higher level informational model
interface can be used to support new use-cases being defined by the decisions for RIBs so that other developers of RIBs may benefit from
IETF I2RS WG. the design concepts.
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 http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 27, 2018. This Internet-Draft will expire on August 17, 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 49 skipping to change at page 2, line 49
7.3. Performing multicast . . . . . . . . . . . . . . . . . . . 22 7.3. Performing multicast . . . . . . . . . . . . . . . . . . . 22
8. RIB operations at scale . . . . . . . . . . . . . . . . . . . 23 8. RIB operations at scale . . . . . . . . . . . . . . . . . . . 23
8.1. RIB reads . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1. RIB reads . . . . . . . . . . . . . . . . . . . . . . . . 23
8.2. RIB writes . . . . . . . . . . . . . . . . . . . . . . . . 23 8.2. RIB writes . . . . . . . . . . . . . . . . . . . . . . . . 23
8.3. RIB events and notifications . . . . . . . . . . . . . . . 23 8.3. RIB events and notifications . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
Routing and routing functions in enterprise and carrier networks are Routing and routing functions in enterprise and carrier networks are
traditionally performed in network devices. Traditionally routers traditionally performed in network devices. Traditionally routers
run routing protocols and the routing protocols (along with static run routing protocols and the routing protocols (along with static
config) populate the Routing information base (RIB) of the router. config) populate the Routing information base (RIB) of the router.
The RIB is managed by the RIB manager and the RIB manager provides a The RIB is managed by the RIB manager and the RIB manager provides a
north-bound interface to its clients i.e. the routing protocols to north-bound interface to its clients i.e. the routing protocols to
insert routes into the RIB. The RIB manager consults the RIB and insert routes into the RIB. The RIB manager consults the RIB and
skipping to change at page 4, line 7 skipping to change at page 4, line 7
Routing protocols are inherently distributed in nature and each Routing protocols are inherently distributed in nature and each
router makes an independent decision based on the routing data router makes an independent decision based on the routing data
received from its peers. With the advent of newer deployment received from its peers. With the advent of newer deployment
paradigms and the need for specialized applications, there is an paradigms and the need for specialized applications, there is an
emerging need to guide the router's routing function [RFC7920]. emerging need to guide the router's routing function [RFC7920].
Traditional network-device protocol-based RIB population suffices for Traditional network-device protocol-based RIB population suffices for
most use cases where distributed network control is used. However most use cases where distributed network control is used. However
there are use cases which the network operators currently address by there are use cases which the network operators currently address by
configuring static routes, policies and RIB import/export rules on configuring static routes, policies and RIB import/export rules on
the routers. There is also a growing list of use cases the routers. There is also a growing list of use cases in which a
[I-D.white-i2rs-use-case], [I-D.hares-i2rs-use-case-vn-vc] in which a
network operator might want to program the RIB based on data network operator might want to program the RIB based on data
unrelated to just routing (within that network's domain). unrelated to just routing (within that network's domain).
Programming the RIB could be based on other information such as Programming the RIB could be based on other information such as
routing data in the adjacent domain or the load on storage and routing data in the adjacent domain or the load on storage and
compute in the given domain. Or it could simply be a programmatic compute in the given domain. Or it could simply be a programmatic
way of creating on-demand dynamic overlays (e.g. GRE tunnels) way of creating on-demand dynamic overlays (e.g. GRE tunnels)
between compute hosts (without requiring the hosts to run traditional between compute hosts (without requiring the hosts to run traditional
routing protocols). If there was a standardized publicly documented routing protocols). If there was a standardized publicly documented
programmatic interface to a RIB, it would enable further networking programmatic interface to a RIB, it would enable further networking
applications that address a variety of use-cases [RFC7920]. applications that address a variety of use-cases [RFC7920].
A programmatic interface to the RIB involves 2 types of operations - A programmatic interface to the RIB involves 2 types of operations -
reading from the RIB and writing (adding/modifying/deleting) to the reading from the RIB and writing (adding/modifying/deleting) to the
RIB. [I-D.white-i2rs-use-case] lists various use-cases which require RIB.
read and/or write manipulation of the RIB.
In order to understand what is in a router's RIB, methods like per- In order to understand what is in a router's RIB, methods like per-
protocol SNMP MIBs and show output screen scraping are used. These protocol SNMP MIBs and show output screen scraping are used. These
methods are not scalable, since they are client pull mechanisms and methods are not scalable, since they are client pull mechanisms and
not proactive push (from the router) mechanisms. Screen scraping is not proactive push (from the router) mechanisms. Screen scraping is
error prone (since the output format can change) and is vendor error prone (since the output format can change) and is vendor
dependent. Building a RIB from per-protocol MIBs is error prone dependent. Building a RIB from per-protocol MIBs is error prone
since the MIB data represent protocol data and not the exact since the MIB data represent protocol data and not the exact
information that went into the RIB. Thus, just getting read-only RIB information that went into the RIB. Thus, just getting read-only RIB
information from a router is a hard task. information from a router is a hard task.
skipping to change at page 5, line 19 skipping to change at page 5, line 17
1.1. Conventions used in this document 1.1. Conventions used in this document
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
2. RIB data 2. RIB data
This section describes the details of a RIB. It makes forward This section describes the details of a RIB. It makes forward
references to objects in the RIB grammar (Section 6). A high-level references to objects in the RIB grammar (Section 6). A high-level
description of the RIB contents is as shown below. description of the RIB contents is as shown in Figure 2. Please note
that for ease of ASCII art representation this drawing shows a single
routing-instance, a single, RIB, and a single route. Sub-sections of
this Section describe the logical data nodes that should be contained
within a RIB. Section 3 and Section 4 describe the high level read
and write operations.
network-device network-device
| |
| 0..N | 0..N
| |
routing-instance (s) routing-instance (s)
| | | |
| | | |
0..N | | 0..N 0..N | | 0..N
| | | |
skipping to change at page 5, line 43 skipping to change at page 5, line 46
| 0..N | 0..N
| |
route(s) route(s)
Figure 2: RIB model Figure 2: RIB model
2.1. RIB definition 2.1. RIB definition
A RIB is an entity that contains routes. A RIB is identified by its A RIB is an entity that contains routes. A RIB is identified by its
name and a RIB is contained within a routing instance (Section 2.2). name and a RIB is contained within a routing instance (Section 2.2).
There can be many routing instances and each routing intance can There MAY be many routing instances and each routing intance MAY
contain 1 or more RIBs. The name MUST be unique within a routing contain 1 or more RIBs. The name MUST be unique within a routing
instance. All routes in a given RIB MUST be of the same rib family instance. All routes in a given RIB MUST be of the same rib family
(e.g. IPv4). Each RIB MUST belong to a routing instance. (e.g. IPv4). Each RIB MUST belong to a routing instance.
A routing instance can have multiple RIBs. A routing instance can A routing instance MAY have multiple RIBs. A routing instance MAY
even have two or more RIBs of the same rib family (e.g. IPv6). A even have two or more RIBs of the same rib family (e.g. IPv6). A
typical case where this can be used is for multi-topology routing typical case where this can be used is for multi-topology routing
([RFC4915], [RFC5120]). ([RFC4915], [RFC5120]).
Each RIB can be optionally associated with a ENABLE_IP_RPF_CHECK Each RIB MAY be optionally associated with a ENABLE_IP_RPF_CHECK
attribute that enables Reverse path forwarding (RPF) checks on all IP attribute that enables Reverse path forwarding (RPF) checks on all IP
routes in that RIB. Reverse path forwarding (RPF) check is used to routes in that RIB. Reverse path forwarding (RPF) check is used to
prevent spoofing and limit malicious traffic. For IP packets, the IP prevent spoofing and limit malicious traffic. For IP packets, the IP
source address is looked up and the rpf interface(s) associated with source address is looked up and the rpf interface(s) associated with
the route for that IP source address is found. If the incoming IP the route for that IP source address is found. If the incoming IP
packet's interface matches one of the rpf interface(s), then the IP packet's interface matches one of the rpf interface(s), then the IP
packet is forwarded based on its IP destination address; otherwise, packet is forwarded based on its IP destination address; otherwise,
the IP packet is discarded. the IP packet is discarded.
2.2. Routing instance 2.2. Routing instance
skipping to change at page 7, line 25 skipping to change at page 7, line 27
nexthop might be routing instance C. Thus, routing instance B is not nexthop might be routing instance C. Thus, routing instance B is not
associated with any interface. And given that this routing instance associated with any interface. And given that this routing instance
does not do any control plane interaction with other network devices, does not do any control plane interaction with other network devices,
a ROUTER_ID is also not needed. a ROUTER_ID is also not needed.
2.3. Route 2.3. Route
A route is essentially a match condition and an action following the A route is essentially a match condition and an action following the
match. The match condition specifies the kind of route (IPv4, MPLS, match. The match condition specifies the kind of route (IPv4, MPLS,
etc.) and the set of fields to match on. Figure 3 represents the etc.) and the set of fields to match on. Figure 3 represents the
overall contents of a route. overall contents of a route. Please note that for ease of depiction
in ASCII art only a single instance of the route attribute, match
flags, or nexthop is depicted.
route route
| | | | | |
+---------+ | +----------+ +---------+ | +----------+
| | | | | |
0..N | | | 0..N | | |
route-attribute match nexthop route-attribute match nexthop
| |
| |
skipping to change at page 8, line 4 skipping to change at page 8, line 8
| | | | | | | | | |
| | | | | | | | | |
IPv4 IPv6 MPLS MAC Interface IPv4 IPv6 MPLS MAC Interface
Figure 3: Route model Figure 3: Route model
This document specifies the following match types: This document specifies the following match types:
o IPv4: Match on destination and/or source IP address in the IPv4 o IPv4: Match on destination and/or source IP address in the IPv4
header header
o IPv6: Match on destination and/or source IP address in the IPv6 o IPv6: Match on destination and/or source IP address in the IPv6
header header
o MPLS: Match on a MPLS label at the top of the MPLS label stack o MPLS: Match on a MPLS label at the top of the MPLS label stack
o MAC: Match on MAC destination addresses in the ethernet header o MAC: Match on MAC destination addresses in the ethernet header
o Interface: Match on incoming interface of the packet o Interface: Match on incoming interface of the packet
A route MAY be matched on one or more these match types by policy as
either an "AND" (to restrict the number of routes) or an "OR" (to
combine two filters).
Each route MUST have associated with it the following mandatory route Each route MUST have associated with it the following mandatory route
attributes. attributes.
o ROUTE_PREFERENCE: This is a numerical value that allows for o ROUTE_PREFERENCE: This is a numerical value that allows for
comparing routes from different protocols. Static configuration comparing routes from different protocols. Static configuration
is also considered a protocol for the purpose of this field. It is also considered a protocol for the purpose of this field. It
is also known as administrative-distance. The lower the value, is also known as administrative-distance. The lower the value,
the higher the preference. For example there can be an OSPF route the higher the preference. For example there can be an OSPF route
for 192.0.2.1/32 (or IPv6 2001:DB8::1/32) with a preference of 5. for 192.0.2.1/32 (or IPv6 2001:DB8::1/32) with a preference of 5.
If a controller programs a route for 192.0.2.1/32 (or IPv6 2001: If a controller programs a route for 192.0.2.1/32 (or IPv6 2001:
DB8::1/32) with a preference of 2, then the controller's route DB8::1/32) with a preference of 2, then the controller's route
skipping to change at page 8, line 32 skipping to change at page 8, line 39
to dictate behavior. For more examples of preference, see to dictate behavior. For more examples of preference, see
Section 7.1. Section 7.1.
Each route can have associated with it one or more optional route Each route can have associated with it one or more optional route
attributes. attributes.
o route-vendor-attributes: Vendors can specify vendor-specific o route-vendor-attributes: Vendors can specify vendor-specific
attributes using this. The details of this attribute is outside attributes using this. The details of this attribute is outside
the scope of this document. the scope of this document.
Each route has associated with it a Nexthop. Nexthop is described in Each route has associated with it a Nexthop. Nexthop is described in
the next section Section 2.4.
Additional features to match multicast packets were considered (E.g.
TTL of the packet to limit the range of a multicast group), but these
were not added to this information model. Future RIB information
models should investigate these multicast features.
2.4. Nexthop 2.4. Nexthop
A nexthop represents an object resulting from a route lookup. For A nexthop represents an object resulting from a route lookup. For
example, if a route lookup results in sending the packet out a given example, if a route lookup results in sending the packet out a given
interface, then the nexthop represents that interface. interface, then the nexthop represents that interface.
Nexthops can be fully resolved nexthops or unresolved nexthop. A Nexthops can be fully resolved nexthops or unresolved nexthop. A
resolved nexthop has adequate information to send the outgoing packet resolved nexthop has adequate information to send the outgoing packet
to the destination by forwarding it on an interface to a directly to the destination by forwarding it on an interface to a directly
skipping to change at page 9, line 22 skipping to change at page 9, line 34
eligible route. Conversely, when all the nexthops of a route are eligible route. Conversely, when all the nexthops of a route are
unresolved that route can no longer be used to forward packets. Such unresolved that route can no longer be used to forward packets. Such
a route is considered ineligible to be installed in the FIB and is a route is considered ineligible to be installed in the FIB and is
henceforth referred to as a FIB-ineligible route. The RIB henceforth referred to as a FIB-ineligible route. The RIB
information model allows an external entity to program routes whose information model allows an external entity to program routes whose
nexthops may be unresolved initially. Whenever an unresolved nexthop nexthops may be unresolved initially. Whenever an unresolved nexthop
gets resolved, the RIB manager will send a notification of the same gets resolved, the RIB manager will send a notification of the same
(see Section 5 ). (see Section 5 ).
The overall structure and usage of a nexthop is as shown in the The overall structure and usage of a nexthop is as shown in the
figure below. figure below. For ease of ASCII art depiction, only a single
instance of any component of the nexthop is shown in Figure 4.
route route
| |
| 0..N | 0..N
| |
nexthop <-------------------------------+ nexthop <-------------------------------+
| | | |
+-------+----------------------------+-------------+ | +-------+----------------------------+-------------+ |
| | | | | | | | | | | |
| | | | | | | | | | | |
skipping to change at page 23, line 50 skipping to change at page 23, line 50
There can be cases where a single network event results in multiple There can be cases where a single network event results in multiple
events and/or notifications from the network device to an external events and/or notifications from the network device to an external
entity. On the other hand, due to timing of multiple things entity. On the other hand, due to timing of multiple things
happening at the same time, a network device might have to send happening at the same time, a network device might have to send
multiple events and/or notifications to an external entity. The multiple events and/or notifications to an external entity. The
network device originated event/notification message MUST support network device originated event/notification message MUST support
bulking of multiple events and notifications in a single message. bulking of multiple events and notifications in a single message.
9. Security Considerations 9. Security Considerations
All interactions between a RIB manager and an external entity MUST be The Informational module specified in this document defines a schema
authenticated and authorized. The RIB manager MUST protect itself for data models that are designed to be accessed via network
against a denial of service attack by a rogue external entity, by management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040].
throttling request processing. A RIB manager MUST enforce limits on The lowest NETCONF layer is the secure transport layer, and the
how much data can be programmed by an external entity and return mandatory-to-implement secure transport is Secure Shell (SSH)
error when such a limit is reached. [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-
implement secure transport is TLS [RFC5246].
The RIB manager MUST expose a data-model that it implements. An The NETCONF access control model [RFC6536] provides the means to
external agent MUST send requests to the RIB manager that comply with restrict access for particular NETCONF or RESTCONF users to a
the supported data-model. The data-model MUST specify the behavior preconfigured subset of all available NETCONF or RESTCONF protocol
of the RIB manager on handling of unsupported data requests. operations and content.
The RIB info model specifies read and write operations to network
devices. These network devices might be considered sensitive or
vulnerable in some network environments. Write operations to these
network devices without proper protection can have a negative effect
on network operations. Due to this factor, it is recommended that
data models also consider the following in their design:
o Require utilization of the authentication and authorization
features of the NETCONF or RESTCONF suite of protocols.
o Augment the limits on how much data can be written or updated by a
remote entity built to include enough protection for a RIB model.
o Expose the specific RIB model implemented via NETCONF/RESTCONF
data models.
10. IANA Considerations 10. IANA Considerations
This document does not generate any considerations for IANA. This document does not generate any considerations for IANA.
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Ron Folkes, Jeffrey Zhang, the The authors would like to thank Ron Folkes, Jeffrey Zhang, the
working group co-chairs and reviewers on their comments and working group co-chairs and reviewers on their comments and
suggestions on this draft. The following people contributed to the suggestions on this draft. The following people contributed to the
skipping to change at page 24, line 39 skipping to change at page 25, line 9
12.1. Normative References 12.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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
12.2. Informative References 12.2. Informative References
[I-D.hares-i2rs-use-case-vn-vc]
Hares, S. and M. Chen, "Use Cases for Virtual Connections
on Demand (VCoD) and Virtual Network on Demand (VNoD)
using Interface to Routing System",
draft-hares-i2rs-use-case-vn-vc-03 (work in progress),
July 2014.
[I-D.white-i2rs-use-case]
White, R., Hares, S., and A. Retana, "Protocol Independent
Use Cases for an Interface to the Routing System",
draft-white-i2rs-use-case-06 (work in progress),
July 2014.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007, RFC 4915, DOI 10.17487/RFC4915, June 2007,
<https://www.rfc-editor.org/info/rfc4915>. <https://www.rfc-editor.org/info/rfc4915>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/ Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/
RFC5120, February 2008, RFC5120, February 2008,
<https://www.rfc-editor.org/info/rfc5120>. <https://www.rfc-editor.org/info/rfc5120>.
[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>.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, DOI 10.17487/RFC5511, Specifications", RFC 5511, DOI 10.17487/RFC5511,
April 2009, <https://www.rfc-editor.org/info/rfc5511>. April 2009, <https://www.rfc-editor.org/info/rfc5511>.
[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>.
[RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem [RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem
Statement for the Interface to the Routing System", Statement for the Interface to the Routing System",
RFC 7920, DOI 10.17487/RFC7920, June 2016, RFC 7920, DOI 10.17487/RFC7920, June 2016,
<https://www.rfc-editor.org/info/rfc7920>. <https://www.rfc-editor.org/info/rfc7920>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
Authors' Addresses Authors' Addresses
Nitin Bahadur (editor) Nitin Bahadur (editor)
Uber Uber
900 Arastradero Rd 900 Arastradero Rd
Palo Alto, CA 94304 Palo Alto, CA 94304
US US
Email: nitin_bahadur@yahoo.com Email: nitin_bahadur@yahoo.com
 End of changes. 23 change blocks. 
47 lines changed or deleted 86 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/