draft-ietf-i2rs-architecture-10.txt   draft-ietf-i2rs-architecture-11.txt 
Network Working Group A. Atlas Network Working Group A. Atlas
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Informational J. Halpern Intended status: Informational J. Halpern
Expires: June 2, 2016 Ericsson Expires: June 18, 2016 Ericsson
S. Hares S. Hares
Huawei Huawei
D. Ward D. Ward
Cisco Systems Cisco Systems
T. Nadeau T. Nadeau
Brocade Brocade
November 30, 2015 December 16, 2015
An Architecture for the Interface to the Routing System An Architecture for the Interface to the Routing System
draft-ietf-i2rs-architecture-10 draft-ietf-i2rs-architecture-11
Abstract Abstract
This document describes an architecture for a standard, programmatic This document describes the IETF architecture for a standard,
interface for state transfer in and out of the Internet routing programmatic interface for state transfer in and out of the Internet
system. It describes the basic architecture, the components, and routing system. It describes the basic architecture, the components,
their interfaces with particular focus on those to be standardized as and their interfaces with particular focus on those to be
part of the Interface to Routing System (I2RS). standardized as part of the Interface to Routing System (I2RS).
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 June 2, 2016. This Internet-Draft will expire on June 18, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Drivers for the I2RS Architecture . . . . . . . . . . . . 4 1.1. Drivers for the I2RS Architecture . . . . . . . . . . . . 4
1.2. Architectural Overview . . . . . . . . . . . . . . . . . 5 1.2. Architectural Overview . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Key Architectural Properties . . . . . . . . . . . . . . . . 10 3. Key Architectural Properties . . . . . . . . . . . . . . . . 11
3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 11 3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
4.1. Identity and Authentication . . . . . . . . . . . . . . . 14 4.1. Identity and Authentication . . . . . . . . . . . . . . . 14
4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 15
4.3. Client Redundancy . . . . . . . . . . . . . . . . . . . . 15 4.3. Client Redundancy . . . . . . . . . . . . . . . . . . . . 15
5. Network Applications and I2RS Client . . . . . . . . . . . . 15 5. Network Applications and I2RS Client . . . . . . . . . . . . 16
5.1. Example Network Application: Topology Manager . . . . . . 16 5.1. Example Network Application: Topology Manager . . . . . . 16
6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 16 6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 17
6.1. Relationship to its Routing Element . . . . . . . . . . . 16 6.1. Relationship to its Routing Element . . . . . . . . . . . 17
6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 17 6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 17
6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 17 6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 18
6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 18 6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 19
6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 18 6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Interactions with Local Config . . . . . . . . . . . . . 19 6.3. Interactions with Local Configuration . . . . . . . . . . 19
6.4. Routing Components and Associated I2RS Services . . . . . 19 6.4. Routing Components and Associated I2RS Services . . . . . 20
6.4.1. Routing and Label Information Bases . . . . . . . . . 20 6.4.1. Routing and Label Information Bases . . . . . . . . . 21
6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 21 6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 22
6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 21 6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 23
6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 22 6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 23
6.4.5. Information Modeling, Device Variation, and 6.4.5. Information Modeling, Device Variation, and
Information Relationships . . . . . . . . . . . . . . 22 Information Relationships . . . . . . . . . . . . . . 23
6.4.5.1. Managing Variation: Object Classes/Types and 6.4.5.1. Managing Variation: Object Classes/Types and
Inheritance . . . . . . . . . . . . . . . . . . . 22 Inheritance . . . . . . . . . . . . . . . . . . . 23
6.4.5.2. Managing Variation: Optionality . . . . . . . . . 23 6.4.5.2. Managing Variation: Optionality . . . . . . . . . 24
6.4.5.3. Managing Variation: Templating . . . . . . . . . 23 6.4.5.3. Managing Variation: Templating . . . . . . . . . 24
6.4.5.4. Object Relationships . . . . . . . . . . . . . . 24 6.4.5.4. Object Relationships . . . . . . . . . . . . . . 25
6.4.5.4.1. Initialization . . . . . . . . . . . . . . . 24 6.4.5.4.1. Initialization . . . . . . . . . . . . . . . 25
6.4.5.4.2. Correlation Identification . . . . . . . . . 24 6.4.5.4.2. Correlation Identification . . . . . . . . . 25
6.4.5.4.3. Object References . . . . . . . . . . . . . . 25 6.4.5.4.3. Object References . . . . . . . . . . . . . . 26
6.4.5.4.4. Active Reference . . . . . . . . . . . . . . 25 6.4.5.4.4. Active Reference . . . . . . . . . . . . . . 26
7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 25 7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 26
7.1. One Control and Data Exchange Protocol . . . . . . . . . 25 7.1. One Control and Data Exchange Protocol . . . . . . . . . 26
7.2. Communication Channels . . . . . . . . . . . . . . . . . 25 7.2. Communication Channels . . . . . . . . . . . . . . . . . 26
7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 26 7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 27
7.4. Scope Policy Specifications . . . . . . . . . . . . . . . 26 7.4. Scope Policy Specifications . . . . . . . . . . . . . . . 27
7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 27 7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 28
7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 27 7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 28
7.7. Information collection . . . . . . . . . . . . . . . . . 28 7.7. Information collection . . . . . . . . . . . . . . . . . 29
7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 28 7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 29
7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 29 7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 30
8. Operational and Manageability Considerations . . . . . . . . 29 8. Operational and Manageability Considerations . . . . . . . . 30
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
11. Informative References . . . . . . . . . . . . . . . . . . . 30 11. Informative References . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
Routers that form the internet routing infrastructure maintain state Routers that form the internet routing infrastructure maintain state
at various layers of detail and function. For example, a typical at various layers of detail and function. For example, a typical
router maintains a Routing Information Base (RIB), and implements router maintains a Routing Information Base (RIB), and implements
routing protocols such as OSPF, ISIS, and BGP to exchange routing protocols such as OSPF, IS-IS, and BGP to exchange
reachability information, topology information, protocol state, and reachability information, topology information, protocol state, and
other information about the state of the network with other routers. other information about the state of the network with other routers.
Routers convert all of this information into forwarding entries which Routers convert all of this information into forwarding entries which
are then used to forward packets and flows between network elements. are then used to forward packets and flows between network elements.
The forwarding plane and the specified forwarding entries then The forwarding plane and the specified forwarding entries then
contain active state information that describes the expected and contain active state information that describes the expected and
observed operational behavior of the router and which is also needed observed operational behavior of the router and which is also needed
by the network applications. Network-oriented applications require by the network applications. Network-oriented applications require
easy access to this information to learn the network topology, to easy access to this information to learn the network topology, to
skipping to change at page 3, line 49 skipping to change at page 3, line 49
This document sets out an architecture for a common, standards-based This document sets out an architecture for a common, standards-based
interface to this information. This Interface to the Routing System interface to this information. This Interface to the Routing System
(I2RS) facilitates control and observation of the routing-related (I2RS) facilitates control and observation of the routing-related
state (for example, a Routing Element RIB manager's state), as well state (for example, a Routing Element RIB manager's state), as well
as enabling network-oriented applications to be built on top of as enabling network-oriented applications to be built on top of
today's routed networks. The I2RS is a programmatic asynchronous today's routed networks. The I2RS is a programmatic asynchronous
interface for transferring state into and out of the internet routing interface for transferring state into and out of the internet routing
system. This I2RS architecture recognizes that the routing system system. This I2RS architecture recognizes that the routing system
and a router's OS provide useful mechanisms that applications could and a router's OS provide useful mechanisms that applications could
harness to accomplish application-level goals. harness to accomplish application-level goals. These network-
oriented applications can leverage the I2RS programmatic interface to
create new ways of combining retrieval of internet routing data,
analyzing this data, setting state within routers.
Fundamental to the I2RS are clear data models that define the Fundamental to the I2RS are clear data models that define the
semantics of the information that can be written and read. The I2RS semantics of the information that can be written and read. The I2RS
provides a framework for registering and for requesting the provides a framework for registering and for requesting the
appropriate information for each particular application. The I2RS appropriate information for each particular application. The I2RS
provides a way for applications to customize network behavior while provides a way for applications to customize network behavior while
leveraging the existing routing system as desired. leveraging the existing routing system as desired.
Although the I2RS architecture is general enough to support Although the I2RS architecture is general enough to support
information and data models for a variety of data, and aspects of the information and data models for a variety of data, and aspects of the
skipping to change at page 4, line 38 skipping to change at page 4, line 40
extensibility and provide standard data-models to be used by network extensibility and provide standard data-models to be used by network
applications. applications.
I2RS is described as an asynchronous programmatic interface, the key I2RS is described as an asynchronous programmatic interface, the key
properties of which are described in Section 5 of properties of which are described in Section 5 of
[I-D.ietf-i2rs-problem-statement]. [I-D.ietf-i2rs-problem-statement].
The I2RS architecture facilitates obtaining information from the The I2RS architecture facilitates obtaining information from the
router. The I2RS architecture provides the ability to not only read router. The I2RS architecture provides the ability to not only read
specific information, but also to subscribe to targeted information specific information, but also to subscribe to targeted information
streams and filtered and thresholded events. streams, filtered events, and thresholded events.
Such an interface also facilitates the injection of ephemeral state Such an interface also facilitates the injection of ephemeral state
into the routing system. A non-routing protocol or application could into the routing system. A non-routing protocol or application could
inject state into a routing element via the state-insertion inject state into a routing element via the state-insertion
functionality of the I2RS and that state could then be distributed in functionality of the I2RS and that state could then be distributed in
a routing or signaling protocol and/or be used locally (e.g. to a routing or signaling protocol and/or be used locally (e.g. to
program the co-located forwarding plane). I2RS will only permit program the co-located forwarding plane). I2RS will only permit
modification of state that would be safe, conceptually, to modify via modification of state that would be safe, conceptually, to modify via
local configuration; no direct manipulation of protocol-internal local configuration; no direct manipulation of protocol-internal
dynamically determined data is envisioned. dynamically determined data is envisioned.
1.2. Architectural Overview 1.2. Architectural Overview
Figure 1 shows the basic architecture for I2RS between applications Figure 1 shows the basic architecture for I2RS between applications
using I2RS, their associated I2RS Clients, and I2RS Agents. using I2RS, their associated I2RS Clients, and I2RS Agents.
Applications access I2RS services through I2RS clients. A single Applications access I2RS services through I2RS clients. A single
client can provide access to one or more applications. In the client can provide access to one or more applications. In the
figure, Clients A and B provide access to a single application, while figure, Clients A and B each provide access to a single application
Client P provides access to multiple applications. (application A and B respectively), while Client P provides access to
multiple applications.
Applications can access I2RS services through local or remote Applications can access I2RS services through local or remote
clients. In the figure, Applications A and B access I2RS services clients. In the figure, Applications A and B access I2RS services
through local clients, while Applications C, D and E access I2RS through local clients, while Applications C, D and E access I2RS
services through a remote client. The details of how applications services through a remote client. The details of how applications
communicate with a remote client is out of scope for I2RS. communicate with a remote client is out of scope for I2RS.
An I2RS Client can access one or more I2RS agents. In the figure, An I2RS Client can access one or more I2RS agents. In the figure 1,
Clients B and P access I2RS Agents 1 and 2. Likewise, an I2RS Agent Clients B and P access I2RS Agents 1 and 2. Likewise, an I2RS Agent
can provide service to one or more clients. In the figure, I2RS can provide service to one or more clients. In the figure, I2RS
Agent 1 provides services to Clients A, B and P while Agent 2 Agent 1 provides services to Clients A, B and P while Agent 2
provides services to only Clients B and P. provides services to only Clients B and P.
I2RS agents and clients communicate with one another using an I2RS agents and clients communicate with one another using an
asynchronous protocol. Therefore, a single client can post multiple asynchronous protocol. Therefore, a single client can post multiple
simultaneous requests, either to a single agent or to multiple simultaneous requests, either to a single agent or to multiple
agents. Furthermore, an agent can process multiple requests, either agents. Furthermore, an agent can process multiple requests, either
from a single client or from multiple clients, simultaneously. from a single client or from multiple clients, simultaneously.
The I2RS agent provides read and write access to selected data on the The I2RS agent provides read and write access to selected data on the
routing element that are organized into I2RS Services. Section 4 routing element that are organized into I2RS Services. Section 4
describes how access is mediated by authentication and access control describes how access is mediated by authentication and access control
mechanisms. In addition to read and write access, the I2RS agent mechanisms. Figure 1 shows I2RS agents being able to write ephemeral
allows clients to subscribe to different types of notifications about static state (e.g. RIB entries), and to read from dynamic static
events affecting different object instances. An example not related (e.g. MPLS LSP-ID or number of active BGP peers).
to the creation, modification or deletion of an object instance is
when a next-hop in the RIB is resolved enough to be used or when a In addition to read and write access, the I2RS agent allows clients
particular route is selected by the RIB Manager for installation into to subscribe to different types of notifications about events
the forwarding plane. Please see Section 7.6 and Section 7.7 for affecting different object instances. One example of a notification
details. of such an event (which is unrelated to an object creation,
modification or deletion) is when a next-hop in the RIB is resolved
enough to be used by a RIB manager for installation in the forwarding
plane as part of a particular route. Please see Section 7.6 and
Section 7.7 for details.
The scope of I2RS is to define the interactions between the I2RS The scope of I2RS is to define the interactions between the I2RS
agent and the I2RS client and the associated proper behavior of the agent and the I2RS client and the associated proper behavior of the
I2RS agent and I2RS client. I2RS agent and I2RS client.
****************** ***************** ***************** ****************** ***************** *****************
* Application C * * Application D * * Application E * * Application C * * Application D * * Application E *
****************** ***************** ***************** ****************** ***************** *****************
^ ^ ^ ^ ^ ^
| | | | | |
skipping to change at page 6, line 47 skipping to change at page 7, line 4
* | |----| | | * * | |----| | | * * | |----| | | * * | |----| | | *
* v | v v * * v | v v * * v | v v * * v | v v *
* +----------+ +------------+ * * +----------+ +------------+ * * +----------+ +------------+ * * +----------+ +------------+ *
* | Dynamic | | Static | * * | Dynamic | | Static | * * | Dynamic | | Static | * * | Dynamic | | Static | *
* | System | | System | * * | System | | System | * * | System | | System | * * | System | | System | *
* | State | | State | * * | State | | State | * * | State | | State | * * | State | | State | *
* +----------+ +------------+ * * +----------+ +------------+ * * +----------+ +------------+ * * +----------+ +------------+ *
* * * * * * * *
* Routing Element 1 * * Routing Element 2 * * Routing Element 1 * * Routing Element 2 *
******************************** ******************************** ******************************** ********************************
Figure 1: Architecture of I2RS clients and agents Figure 1: Architecture of I2RS clients and agents
Routing Element: A Routing Element implements some subset of the Routing Element: A Routing Element implements some subset of the
routing system. It does not need to have a forwarding plane routing system. It does not need to have a forwarding plane
associated with it. Examples of Routing Elements can include: associated with it. Examples of Routing Elements can include:
* A router with a forwarding plane and RIB Manager that runs * A router with a forwarding plane and RIB Manager that runs IS-
ISIS, OSPF, BGP, PIM, etc., IS, OSPF, BGP, PIM, etc.,
* A BGP speaker acting as a Route Reflector, * A BGP speaker acting as a Route Reflector,
* An LSR that implements RSVP-TE, OSPF-TE, and PCEP and has a * An LSR that implements RSVP-TE, OSPF-TE, and PCEP and has a
forwarding plane and associated RIB Manager, forwarding plane and associated RIB Manager,
* A server that runs ISIS, OSPF, BGP and uses ForCES to control a * A server that runs IS-IS, OSPF, BGP and uses ForCES to control
remote forwarding plane, a remote forwarding plane,
A Routing Element may be locally managed, whether via CLI, SNMP, A Routing Element may be locally managed, whether via CLI, SNMP,
or NETCONF. or NETCONF.
Routing and Signaling: This block represents that portion of the Routing and Signaling: This block represents that portion of the
Routing Element that implements part of the internet routing Routing Element that implements part of the internet routing
system. It includes not merely standardized protocols (i.e. IS- system. It includes not merely standardized protocols (i.e. IS-
IS, OSPF, BGP, PIM, RSVP-TE, LDP, etc.), but also the RIB Manager IS, OSPF, BGP, PIM, RSVP-TE, LDP, etc.), but also the RIB Manager
layer. layer.
Local Config: A Routing Element will provide the ability to Local Configuration: A Routing Element will provide the ability to
configure and manage it. The Local Config may be provided via a configure and manage it. The Local Configuration is defined in
combination of CLI, NETCONF, SNMP, etc. The black box behavior this architecture as the configuration parameters associated with
for interactions between the state that I2RS installs into the a routing system. The Local Configuration may be read, written,
routing element and the Local Config must be defined. or changed via a combination of CLI, NETCONF, SNMP and other
protocols. The black box behavior for interactions between the
ephemeral state that I2RS installs into the routing element and
the Local Configuration must be defined in I2RS data models.
Dynamic System State: An I2RS agent needs access to state on a Dynamic System State: An I2RS agent needs access to state on a
routing element beyond what is contained in the routing subsystem. routing element beyond what is contained in the routing subsystem.
Such state may include various counters, statistics, flow data, Such state may include various counters, statistics, flow data,
and local events. This is the subset of operational state that is and local events. This is the subset of operational state that is
needed by network applications based on I2RS that is not contained needed by network applications based on I2RS that is not contained
in the routing and signaling information. How this information is in the routing and signaling information. How this information is
provided to the I2RS agent is out of scope, but the standardized provided to the I2RS agent is out of scope, but the standardized
information and data models for what is exposed are part of I2RS. information and data models for what is exposed are part of I2RS.
skipping to change at page 9, line 34 skipping to change at page 9, line 41
An I2RS client can be seen as the part of an application that uses An I2RS client can be seen as the part of an application that uses
and supports I2RS and could be a software library. and supports I2RS and could be a software library.
service or I2RS Service: For the purposes of I2RS, a service refers service or I2RS Service: For the purposes of I2RS, a service refers
to a set of related state access functions together with the to a set of related state access functions together with the
policies that control their usage. The expectation is that a policies that control their usage. The expectation is that a
service will be represented by a data-model. For instance, 'RIB service will be represented by a data-model. For instance, 'RIB
service' could be an example of a service that gives access to service' could be an example of a service that gives access to
state held in a device's RIB. state held in a device's RIB.
read scope: The set of information which the I2RS client is read scope: The read scope of an I2RS client within an I2RS agent
authorized to read. The read scope specifies the access is the set of information which the I2RS client is authorized to
read within the I2RS agent. The read scope specifies the access
restrictions to both see the existence of data and read the value restrictions to both see the existence of data and read the value
of that data. of that data.
notification scope: The set of events and associated information notification scope: The set of events and associated information
that the I2RS Client can request be pushed by the I2RS Agent. that the I2RS Client can request be pushed by the I2RS Agent.
I2RS Clients have the ability to register for specific events and I2RS Clients have the ability to register for specific events and
information streams, but must be constrained by the access information streams, but must be constrained by the access
restrictions associated with their notification scope. restrictions associated with their notification scope.
write scope: The set of field values which the I2RS client is write scope: The set of field values which the I2RS client is
skipping to change at page 10, line 15 skipping to change at page 10, line 24
resources: A resource is an I2RS-specific use of memory, storage, resources: A resource is an I2RS-specific use of memory, storage,
or execution that a client may consume due to its I2RS operations. or execution that a client may consume due to its I2RS operations.
The amount of each such resource that a client may consume in the The amount of each such resource that a client may consume in the
context of a particular agent may be constrained based upon the context of a particular agent may be constrained based upon the
client's security role. An example of such a resource could client's security role. An example of such a resource could
include the number of notifications registered for. These are not include the number of notifications registered for. These are not
protocol-specific resources or network-specific resources. protocol-specific resources or network-specific resources.
role or security role: A security role specifies the scope, role or security role: A security role specifies the scope,
resources, priorities, etc. that a client or agent has. Multiple resources, priorities, etc. that a client or agent has. Multiple
identities may use the same security role. identities may use the same security role. A single identity may
have may have multiple roles.
identity: A client is associated with exactly one specific identity: A client is associated with exactly one specific
identity. State can be attributed to a particular identity. It identity. State can be attributed to a particular identity. It
is possible for multiple communication channels to use the same is possible for multiple communication channels to use the same
identity; in that case, the assumption is that the associated identity; in that case, the assumption is that the associated
client is coordinating such communication. client is coordinating such communication.
Identity and scope: A single identity can be associated with
multiple roles. Each role has its own scope and an identity
associated with multiple roles can use the combined scope of all
its roles. More formally, each identity has:
a read-scope that is the logical OR of the read-scopes
associated with its roles,
a write-scope that is the logical OR of the write-scopes
associated with its roles, and
a notification-scope that is the logical OR of the
notification-scopes associated with its roles.
secondary identity: An I2RS Client may supply a secondary opaque secondary identity: An I2RS Client may supply a secondary opaque
identity that is not interpreted by the I2RS Agent. An example identity that is not interpreted by the I2RS Agent. An example
use is when the I2RS Client is a go-between for multiple use is when the I2RS Client is a go-between for multiple
applications and it is necessary to track which application has applications and it is necessary to track which application has
requested a particular operation. requested a particular operation.
Groups: NETCONF Network Access [RFC6536] refers uses the term group Groups: NETCONF Network Access [RFC6536] refers uses the term group
in terms of an Administrative group which supports support the in terms of an Administrative group which supports support the
well-established distinction between a root account and other well-established distinction between a root account and other
types of less-privileged conceptual user accounts. Group still types of less-privileged conceptual user accounts. Group still
skipping to change at page 12, line 20 skipping to change at page 12, line 44
architecture and protocol(s). First, it allows for transferring architecture and protocol(s). First, it allows for transferring
data-models whose content is not explicitly implemented or data-models whose content is not explicitly implemented or
understood. Second, tools can automate checking and manipulating understood. Second, tools can automate checking and manipulating
data; this is particularly valuable for both extensibility and for data; this is particularly valuable for both extensibility and for
the ability to easily manipulate and check proprietary data-models. the ability to easily manipulate and check proprietary data-models.
The different services provided by I2RS can correspond to separate The different services provided by I2RS can correspond to separate
data-models. An I2RS agent may indicate which data-models are data-models. An I2RS agent may indicate which data-models are
supported. supported.
The purpose of the data model is to provide an definition of the
information regarding the routing system that can be used in
operational networks. In some cases, the I2RS Working group may
define an information model for a set of routing information in order
to define in general terms the information for a data model. If
routing information is being modeled for the first time, a logical
information model may be standardized prior to creating the data
model.
4. Security Considerations 4. Security Considerations
This I2RS architecture describes interfaces that clearly require This I2RS architecture describes interfaces that clearly require
serious consideration of security. As an architecture, I2RS has been serious consideration of security. As an architecture, I2RS has been
designed to re-utilize existing protocols that carry network designed to re-utilize existing protocols that carry network
management information. Two of existing protocol which the I2RS WG management information. Two of existing protocol which the I2RS WG
has selected to attempt to re-use are NETCONF [RFC6241] and RESTCONF has selected to attempt to re-use are NETCONF [RFC6241] and RESTCONF
[I-D.ietf-netconf-restconf]. The I2RS protocol design process is to [I-D.ietf-netconf-restconf]. The I2RS protocol design process is to
specify additional requirements which will include security for an specify additional requirements which will include security for an
existing protocol in order to support the I2RS architecture. After existing protocol in order to support the I2RS architecture. After
an existing protocol, e.g. NETCONF or RESTCONF, has been alter to an existing protocol, e.g. NETCONF or RESTCONF, has been alter to
fit the I2RS requirements, then this protocol will be reviewed to fit the I2RS requirements, then this protocol will be reviewed to
determine if it meets the I2RS security requirements. determine if it meets the I2RS security requirements.
Due to the re-use strategy of the I2RS architecture, this security Due to the re-use strategy of the I2RS architecture, this security
section describes the assumed security environment for I2RS with section describes the assumed security environment for I2RS with
additional detail on: a) identity and authentication, b) additional detail on: a) identity and authentication, b)
authorization, and c) client redundancy. Each protocol proposed for authorization, and c) client redundancy. Each protocol proposed for
inclusions as an I2RS protocol will need to be evaluated for the inclusions as an I2RS protocol will need to be evaluated for the
security constraints of the protocol. security constraints of the protocol. The detailed requirements for
the I2RS protocol and the I2RS security environment will be defined
within these gloal security environments.
First, here is a brief description of the assumed security First, here is a brief description of the assumed security
environment for I2RS. The I2RS Agent associated with a Routing environment for I2RS. The I2RS Agent associated with a Routing
Element is a trusted part of that Routing Element. For example, it Element is a trusted part of that Routing Element. For example, it
may be part of a vendor-distributed signed software image for the may be part of a vendor-distributed signed software image for the
entire Routing Element or it may be trusted signed application that entire Routing Element or it may be trusted signed application that
an operator has installed. The I2RS Agent is assumed to have a an operator has installed. The I2RS Agent is assumed to have a
separate authentication and authorization channel by which it can separate authentication and authorization channel by which it can
validate both the identity and permissions associated with an I2RS validate both the identity and permissions associated with an I2RS
Client. To support numerous and speedy interactions between the I2RS Client. To support numerous and speedy interactions between the I2RS
skipping to change at page 14, line 28 skipping to change at page 15, line 11
identifier that can be provided by the I2RS client to the I2RS agent identifier that can be provided by the I2RS client to the I2RS agent
for purposes of tracking attribution of operations to support for purposes of tracking attribution of operations to support
functionality such as troubleshooting and logging of network changes. functionality such as troubleshooting and logging of network changes.
4.2. Authorization 4.2. Authorization
All operations using I2RS, both observation and manipulation, should All operations using I2RS, both observation and manipulation, should
be subject to appropriate authorization controls. Such authorization be subject to appropriate authorization controls. Such authorization
is based on the identity and assigned role of the I2RS client is based on the identity and assigned role of the I2RS client
performing the operations and the I2RS agent in the network element. performing the operations and the I2RS agent in the network element.
(Multiple Identities may use the same role). Multiple Identities may use the same role. An identity may utilize
several roles. For example, an I2RS client identity may use an MPLS-
Monitor role to have a read-scope that includes created MPLS LSPs and
also use a Troubleshooting role to have write access to trigger
active OAM such as LSP-ping.
I2RS Agents, in performing information collection and manipulation, I2RS Agents, in performing information collection and manipulation,
will be acting on behalf of the I2RS clients. As such, each will be acting on behalf of the I2RS clients. As such, each
operation authorization will be based on the lower of the two operation authorization will be based on the lower of the two
permissions of the agent itself and of the authenticated client. The permissions of the agent itself and of the authenticated client. The
mechanism by which this authorization is applied within the device is mechanism by which this authorization is applied within the device is
outside of the scope of I2RS. outside of the scope of I2RS.
The appropriate or necessary level of granularity for scope can The appropriate or necessary level of granularity for scope can
depend upon the particular I2RS Service and the implementation's depend upon the particular I2RS Service and the implementation's
granularity. An approach to a similar access control problem is granularity. An approach to a similar access control problem is
defined in the NetConf Access Control Model (NACM) [RFC6536]; it defined in the NetConf Access Control Model (NACM) [RFC6536]; it
allows arbitrary access to be specified for a data node instance allows arbitrary access to be specified for a data node instance
identifier while defining meaningful manipulable defaults. The identifier while defining meaningful manipulable defaults. The
identity within NACM [RFC6536] can be specify as either a user name identity within NACM [RFC6536] can be specify as either a user name
or a group user name (e.g. Root), and this name is linked a scope or a group user name (e.g. Root), and this name is linked a scope
policy that contained in a a set of access control rules. Similarly, policy that contained in a set of access control rules. Similarly,
it is expected the I2RS identity links to one role which has a scope it is expected the I2RS identity links to one role which has a scope
policy specified by a set of access control rules. This scope policy policy specified by a set of access control rules. This scope policy
is can be provided via Local Config, exposed as an I2RS Service for is can be provided via Local Configuration, exposed as an I2RS
manipulation by authorized clients, or via some other method (e.g. Service for manipulation by authorized clients, or via some other
AAA service) method (e.g. AAA service)
When an I2RS client is authenticated, its identity is provided to the When an I2RS client is authenticated, its identity is provided to the
I2RS Agent, and this identity links to a role which links to the I2RS Agent, and this identity links to a role which links to the
scope policy. Multiple identities may link to the same role (e.g scope policy. Multiple identities may belong to the same role; for
ability to read I2RS RIB). example, such a role might be an Internal-Routes-Monitor that allows
reading of the portion of the I2RS RIB associated with IP prefixes
used for internal device addresses in the AS."
4.3. Client Redundancy 4.3. Client Redundancy
I2RS must support client redundancy. At the simplest, this can be I2RS must support client redundancy. At the simplest, this can be
handled by having a primary and a backup network application that handled by having a primary and a backup network application that
both use the same client identity and can successfully authenticate both use the same client identity and can successfully authenticate
as such. Since I2RS does not require a continuous transport as such. Since I2RS does not require a continuous transport
connection and supports multiple transport sessions, this can provide connection and supports multiple transport sessions, this can provide
some basic redundancy. However, it does not address the need for some basic redundancy. However, it does not address the need for
troubleshooting and logging of network changes to be informed about troubleshooting and logging of network changes to be informed about
skipping to change at page 17, line 6 skipping to change at page 17, line 40
collecting and delivering large amounts of data from various parts of collecting and delivering large amounts of data from various parts of
the routing element. Those parts may or may not actually be part of the routing element. Those parts may or may not actually be part of
a single physical device. Thus, for scalability and robustness, it a single physical device. Thus, for scalability and robustness, it
is important that the architecture allow for a distributed set of is important that the architecture allow for a distributed set of
reporting components providing collected data from the I2RS agent reporting components providing collected data from the I2RS agent
back to the relevant I2RS clients. There may be multiple I2RS Agents back to the relevant I2RS clients. There may be multiple I2RS Agents
within the same router. In such a case, they must have non- within the same router. In such a case, they must have non-
overlapping sets of information which they manipulate. overlapping sets of information which they manipulate.
To facilitate operations, deployment and troubleshooting, it is To facilitate operations, deployment and troubleshooting, it is
important that traceability of the I2RS Agent's requests and actions important that traceability of the requests received by I2RS Agent's
be supported via a common data model. and actions taken be supported via a common data model.
6.2. I2RS State Storage 6.2. I2RS State Storage
State modification requests are sent to the I2RS agent in a routing State modification requests are sent to the I2RS agent in a routing
element by I2RS clients. The I2RS agent is responsible for applying element by I2RS clients. The I2RS agent is responsible for applying
these changes to the system, subject to the authorization discussed these changes to the system, subject to the authorization discussed
above. The I2RS agent will retain knowledge of the changes it has above. The I2RS agent will retain knowledge of the changes it has
applied, and the client on whose behalf it applied the changes. The applied, and the client on whose behalf it applied the changes. The
I2RS agent will also store active subscriptions. These sets of data I2RS agent will also store active subscriptions. These sets of data
form the I2RS data store. This data is retained by the agent until form the I2RS data store. This data is retained by the agent until
skipping to change at page 19, line 5 skipping to change at page 19, line 36
will not store multiple alternative states, nor try to determine will not store multiple alternative states, nor try to determine
which one among such a plurality it should fall back to. Thus, the which one among such a plurality it should fall back to. Thus, the
model followed is not like the RIB, where multiple routes are stored model followed is not like the RIB, where multiple routes are stored
at different preferences. (For I2RS state in the presence of two at different preferences. (For I2RS state in the presence of two
I2RS clients, please see section 1.2 and section 7.8) I2RS clients, please see section 1.2 and section 7.8)
An I2RS Client may register for notifications, subject to its An I2RS Client may register for notifications, subject to its
notification scope, regarding state modification or removal by a notification scope, regarding state modification or removal by a
particular I2RS Client. particular I2RS Client.
6.3. Interactions with Local Config 6.3. Interactions with Local Configuration
Changes may originate from either Local Config or from I2RS. The Changes may originate from either Local Configuration or from I2RS.
modifications and data stored by I2RS are separate from the local The modifications and data stored by I2RS are separate from the local
device configuration, but conflicts between the two must be resolved device configuration, but conflicts between the two must be resolved
in a deterministic manner that respects operator-applied policy. in a deterministic manner that respects operator-applied policy.
That policy can determine whether Local Config overrides a particular That policy can determine whether Local Configuration overrides a
I2RS client's request or vice versa. To achieve this end, either by particular I2RS client's request or vice versa. To achieve this end,
default Local Config always wins or, optionally, a routing element either by default Local Configuration always wins or, optionally, a
may permit a priority to be configured on the device for the Local routing element may permit a priority to be configured on the device
Config mechanism. The policy mechanism in the later case is for the Local Configuration mechanism. The policy mechanism in the
comparing the I2RS client's priority with that priority assigned to later case is comparing the I2RS client's priority with that priority
the Local Config. assigned to the Local Configuration.
When the Local Config always wins, some communication between that When the Local Configuration always wins, some communication between
subsystem and the I2RS Agent is still necessary. That communication that subsystem and the I2RS Agent is still necessary. That
contains the details of each specific device configuration change communication contains the details of each specific device
that the I2RS Agent is permitted to modify. In addition, when the configuration change that the I2RS Agent is permitted to modify. In
system determines, that a client's I2RS state is preempted, the I2RS addition, when the system determines, that a client's I2RS state is
agent must notify the affected I2RS clients; how the system preempted, the I2RS agent must notify the affected I2RS clients; how
determines this is implementation-dependent. the system determines this is implementation-dependent.
It is critical that policy based upon the source is used because the It is critical that policy based upon the source is used because the
resolution cannot be time-based. Simply allowing the most recent resolution cannot be time-based. Simply allowing the most recent
state to prevail could cause race conditions where the final state is state to prevail could cause race conditions where the final state is
not repeatably deterministic. not repeatably deterministic.
6.4. Routing Components and Associated I2RS Services 6.4. Routing Components and Associated I2RS Services
For simplicity, each logical protocol or set of functionality that For simplicity, each logical protocol or set of functionality that
can be compactly described in a separable information and data model can be compactly described in a separable information and data model
skipping to change at page 20, line 22 skipping to change at page 21, line 22
*************************** * * * * *************************** * * * *
* Policy * * Base QoS * * Policy * * Base QoS *
******************** ******** * Templates * * Templates * ******************** ******** * Templates * * Templates *
* +--------+ * * * * * ************* * +--------+ * * * * * *************
* BGP | BGP-LS | * * PIM * ************** * BGP | BGP-LS | * * PIM * **************
* +--------+ * * * * +--------+ * * *
******************** ******** **************************** ******************** ******** ****************************
* MPLS +---------+ +-----+ * * MPLS +---------+ +-----+ *
********************************** * | RSVP-TE | | LDP | * ********************************** * | RSVP-TE | | LDP | *
* IGPs +------+ +------+ * * +---------+ +-----+ * * IGPs +------+ +------+ * * +---------+ +-----+ *
* +--------+ | OSPF | | ISIS | * * +--------+ * * +--------+ | OSPF | |IS-IS | * * +--------+ *
* | Common | +------+ +------+ * * | Common | * * | Common | +------+ +------+ * * | Common | *
* +--------+ * * +--------+ * * +--------+ * * +--------+ *
********************************** **************************** ********************************** ****************************
************************************************************** **************************************************************
* RIB Manager * * RIB Manager *
* +-------------------+ +---------------+ +------------+ * * +-------------------+ +---------------+ +------------+ *
* | Unicast/multicast | | Policy-Based | | RIB Policy | * * | Unicast/multicast | | Policy-Based | | RIB Policy | *
* | RIBs & LIBs | | Routing | | Controls | * * | RIBs & LIBs | | Routing | | Controls | *
* | route instances | | (ACLs, etc) | +------------+ * * | route instances | | (ACLs, etc) | +------------+ *
skipping to change at page 20, line 52 skipping to change at page 21, line 52
functionality (e.g. pre-defined templates to be applied to interfaces functionality (e.g. pre-defined templates to be applied to interfaces
or for QoS behaviors that traffic is direct into). Section 6.4.5 or for QoS behaviors that traffic is direct into). Section 6.4.5
discusses information modeling constructs and the range of discusses information modeling constructs and the range of
relationship types that are applicable. relationship types that are applicable.
6.4.1. Routing and Label Information Bases 6.4.1. Routing and Label Information Bases
Routing elements may maintain one or more Information Bases. Routing elements may maintain one or more Information Bases.
Examples include Routing Information Bases such as IPv4/IPv6 Unicast Examples include Routing Information Bases such as IPv4/IPv6 Unicast
or IPv4/IPv6 Multicast. Another such example includes the MPLS Label or IPv4/IPv6 Multicast. Another such example includes the MPLS Label
Information Bases, per-platform or per-interface. This Information Bases, per-platform or per-interface or per-context.
functionality, exposed via an I2RS Service, must interact smoothly
with the same mechanisms that the routing element already uses to This functionality, exposed via an I2RS Service, must interact
handle RIB input from multiple sources, so as to safely change the smoothly with the same mechanisms that the routing element already
system state. Conceptually, this can be handled by having the I2RS uses to handle RIB input from multiple sources, so as to safely
Agent communicate with a RIB Manager as a separate routing source. change the system state. Conceptually, this can be handled by having
the I2RS Agent communicate with a RIB Manager as a separate routing
source.
The point-to-multipoint state added to the RIB does not need to match The point-to-multipoint state added to the RIB does not need to match
to well-known multicast protocol installed state. The I2RS Agent can to well-known multicast protocol installed state. The I2RS Agent can
create arbitrary replication state in the RIB, subject to the create arbitrary replication state in the RIB, subject to the
advertised capabilities of the routing element. advertised capabilities of the routing element.
6.4.2. IGPs, BGP and Multicast Protocols 6.4.2. IGPs, BGP and Multicast Protocols
A separate I2RS Service can expose each routing protocol on the A separate I2RS Service can expose each routing protocol on the
device. Such I2RS services may include a number of different kinds device. Such I2RS services may include a number of different kinds
skipping to change at page 25, line 28 skipping to change at page 26, line 28
unit), and link MTU changes need to immediately propagate to the unit), and link MTU changes need to immediately propagate to the
Tunnel MTU, then the tunnel is actively coupled to the link Tunnel MTU, then the tunnel is actively coupled to the link
interface. This kind of active state coupling implies some sort of interface. This kind of active state coupling implies some sort of
internal bookkeeping to ensure consistency, often conceptualized as a internal bookkeeping to ensure consistency, often conceptualized as a
subscription model across objects. subscription model across objects.
7. I2RS Client Agent Interface 7. I2RS Client Agent Interface
7.1. One Control and Data Exchange Protocol 7.1. One Control and Data Exchange Protocol
As agreed by the I2RS working group, this I2RS architecture assumes This I2RS architecture assumes a data-model driven protocol where the
that there is a single I2RS protocol for control and data exchange; data-models are defined in Yang 1.1 ([RFC6020]), Yang 1.1
that protocol will be based on NETCONF[RFC6241] and RESTCONF ([I-D.ietf-netmod-rfc6020bis]), and associated Yang based model
[I-D.ietf-netconf-restconf]. This helps meet the goal of simplicity drafts ([RFC6991], [RFC7223], [RFC7224], [RFC7277], [RFC7317]). Two
and thereby enhances deployability. That protocol may need to use the protocols to be expanded to support the I2RS protocol are NETCONF
several underlying transports (TCP, SCTP (stream control transport [RFC6241] and RESTCONF [I-D.ietf-netconf-restconf]. This helps meet
protocol), DCCP (Datagram Congestion Control Protocol)), with the goal of simplicity and thereby enhances deployability. The I2RS
suitable authentication and integrity protection mechanisms. These protocol may need to use several underlying transports (TCP, SCTP
different transports can support different types of communication (stream control transport protocol), DCCP (Datagram Congestion
(e.g. control, reading, notifications, and information collection) Control Protocol)), with suitable authentication and integrity
and different sets of data. Whatever transport is used for the data protection mechanisms. These different transports can support
exchange, it must also support suitable congestion control different types of communication (e.g. control, reading,
mechanisms. The transports chosen should be operator and implementor notifications, and information collection) and different sets of
friendly to ease adoption. data. Whatever transport is used for the data exchange, it must also
support suitable congestion control mechanisms. The transports
chosen should be operator and implementor friendly to ease adoption.
7.2. Communication Channels 7.2. Communication Channels
Multiple communication channels and multiple types of communication Multiple communication channels and multiple types of communication
channels are required. There may be a range of requirements (e.g. channels are required. There may be a range of requirements (e.g.
confidentiality, reliability), and to support the scaling there may confidentiality, reliability), and to support the scaling there may
need to be channels originating from multiple sub-components of a need to be channels originating from multiple sub-components of a
routing element and/or to multiple parts of an I2RS client. All such routing element and/or to multiple parts of an I2RS client. All such
communication channels will use the same higher level protocol. Use communication channels will use the same higher level protocol. Use
of additional channels for communication will be coordinated between of additional channels for communication will be coordinated between
skipping to change at page 26, line 44 skipping to change at page 27, line 46
models can describe the various capability options. This can then models can describe the various capability options. This can then
represent and be used to communicate important information about the represent and be used to communicate important information about the
agent, and the capabilities thereof. agent, and the capabilities thereof.
7.4. Scope Policy Specifications 7.4. Scope Policy Specifications
As section 4.1 and 4.2 describe, each I2RS Client will have a unique As section 4.1 and 4.2 describe, each I2RS Client will have a unique
identity and it may have a secondary identity (see section 2) to aid identity and it may have a secondary identity (see section 2) to aid
in troubleshooting. As section 4 indicates, all authentication and in troubleshooting. As section 4 indicates, all authentication and
authorization mechanisms are based on the primary Identity which authorization mechanisms are based on the primary Identity which
links to a role with scope policy for for reading data, for writing links to a role with scope policy for reading data, for writing data,
data, and limitations on the resources that can be consumed. and limitations on the resources that can be consumed.
Specifications for scope policy need to specify the data and value Specifications for scope policy need to specify the data and value
ranges for portion of scope policy. ranges for portion of scope policy.
7.5. Connectivity 7.5. Connectivity
A client may or may not maintain an active communication channel with A client may or may not maintain an active communication channel with
an agent. Therefore, an agent may need to open a communication an agent. Therefore, an agent may need to open a communication
channel to the client to communicate previously requested channel to the client to communicate previously requested
information. The lack of an active communication channel does not information. The lack of an active communication channel does not
imply that the associated client is non-functional. When imply that the associated client is non-functional. When
skipping to change at page 30, line 25 skipping to change at page 31, line 25
resources, whether those be operations in a time-frame, entries in resources, whether those be operations in a time-frame, entries in
the RIB, stored operations to be triggered, etc. The ability to the RIB, stored operations to be triggered, etc. The ability to
set resource limits based upon authorization is important. set resource limits based upon authorization is important.
Configuration Interactions: The interaction of state installed via Configuration Interactions: The interaction of state installed via
the I2RS and via a router's configuration needs to be clearly the I2RS and via a router's configuration needs to be clearly
defined. As described in this architecture, a simple priority defined. As described in this architecture, a simple priority
that is configured is used to provide sufficient policy that is configured is used to provide sufficient policy
flexibility. flexibility.
Traceability of Interactions: The ability to trace the interactions
of the requests received by the I2RS Agent's and actions taken by
the I2RS agents is needed so that operations can monitor I2RS
Agents during deployment, and troubleshoot software or network
problems.
Notification Subscription Service: The ability for an I2RS Client to
subscribe to a notification stream pushed from the I2RS Agent
(rather than having I2RS client poll the I2RS agent) provides a
more scalable notification handling for the I2RS Agent-Client
interactions.
9. IANA Considerations 9. IANA Considerations
This document includes no request to IANA. This document includes no request to IANA.
10. Acknowledgements 10. Acknowledgements
Significant portions of this draft came from draft-ward-i2rs- Significant portions of this draft came from draft-ward-i2rs-
framework-00 and draft-atlas-i2rs-policy-framework-00. framework-00 and draft-atlas-i2rs-policy-framework-00.
The authors would like to thank Nitin Bahadur, Shane Amante, Ed The authors would like to thank Nitin Bahadur, Shane Amante, Ed
skipping to change at page 31, line 13 skipping to change at page 32, line 22
problem-statement-06 (work in progress), January 2015. problem-statement-06 (work in progress), January 2015.
[I-D.ietf-idr-ls-distribution] [I-D.ietf-idr-ls-distribution]
Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
Ray, "North-Bound Distribution of Link-State and TE Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", draft-ietf-idr-ls-distribution-13 Information using BGP", draft-ietf-idr-ls-distribution-13
(work in progress), October 2015. (work in progress), October 2015.
[I-D.ietf-netconf-restconf] [I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-08 (work in Protocol", draft-ietf-netconf-restconf-09 (work in
progress), October 2015. progress), December 2015.
[I-D.ietf-netmod-rfc6020bis]
Bjorklund, M., "The YANG 1.1 Data Modeling Language",
draft-ietf-netmod-rfc6020bis-09 (work in progress),
December 2015.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<http://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,
<http://www.rfc-editor.org/info/rfc6241>. <http://www.rfc-editor.org/info/rfc6241>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, Protocol (NETCONF) Access Control Model", RFC 6536,
DOI 10.17487/RFC6536, March 2012, DOI 10.17487/RFC6536, March 2012,
<http://www.rfc-editor.org/info/rfc6536>. <http://www.rfc-editor.org/info/rfc6536>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<http://www.rfc-editor.org/info/rfc6991>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<http://www.rfc-editor.org/info/rfc7223>.
[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module",
RFC 7224, DOI 10.17487/RFC7224, May 2014,
<http://www.rfc-editor.org/info/rfc7224>.
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 7277, DOI 10.17487/RFC7277, June 2014,
<http://www.rfc-editor.org/info/rfc7277>.
[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for
System Management", RFC 7317, DOI 10.17487/RFC7317, August
2014, <http://www.rfc-editor.org/info/rfc7317>.
Authors' Addresses Authors' Addresses
Alia Atlas Alia Atlas
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA USA
Email: akatlas@juniper.net Email: akatlas@juniper.net
 End of changes. 44 change blocks. 
129 lines changed or deleted 219 lines changed or added

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