draft-ietf-i2rs-architecture-12.txt   draft-ietf-i2rs-architecture-13.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 25, 2016 Ericsson Expires: August 23, 2016 Ericsson
S. Hares S. Hares
Huawei Huawei
D. Ward D. Ward
Cisco Systems Cisco Systems
T. Nadeau T. Nadeau
Brocade Brocade
December 23, 2015 February 20, 2016
An Architecture for the Interface to the Routing System An Architecture for the Interface to the Routing System
draft-ietf-i2rs-architecture-12 draft-ietf-i2rs-architecture-13
Abstract Abstract
This document describes the IETF architecture for a standard, This document describes the IETF architecture for a standard,
programmatic interface for state transfer in and out of the Internet programmatic interface for state transfer in and out of the Internet
routing system. It describes the basic architecture, the components, routing system. It describes the basic architecture, the components,
and their interfaces with particular focus on those to be and their interfaces with particular focus on those to be
standardized as 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
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 25, 2016. This Internet-Draft will expire on August 23, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 35 skipping to change at page 2, line 35
4.3. Client Redundancy . . . . . . . . . . . . . . . . . . . . 16 4.3. Client Redundancy . . . . . . . . . . . . . . . . . . . . 16
5. Network Applications and I2RS Client . . . . . . . . . . . . 16 5. Network Applications and I2RS Client . . . . . . . . . . . . 16
5.1. Example Network Application: Topology Manager . . . . . . 17 5.1. Example Network Application: Topology Manager . . . . . . 17
6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 17 6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 17
6.1. Relationship to its Routing Element . . . . . . . . . . . 17 6.1. Relationship to its Routing Element . . . . . . . . . . . 17
6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 18 6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 18
6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 18 6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 18
6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 19 6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 19
6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 19 6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Interactions with Local Configuration . . . . . . . . . . 20 6.3. Interactions with Local Configuration . . . . . . . . . . 20
6.4. Routing Components and Associated I2RS Services . . . . . 20 6.4. Routing Components and Associated I2RS Services . . . . . 21
6.4.1. Routing and Label Information Bases . . . . . . . . . 21 6.4.1. Routing and Label Information Bases . . . . . . . . . 22
6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 22 6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 22
6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 23 6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 23
6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . 23 Information Relationships . . . . . . . . . . . . . . 23
6.4.5.1. Managing Variation: Object Classes/Types and 6.4.5.1. Managing Variation: Object Classes/Types and
Inheritance . . . . . . . . . . . . . . . . . . . 23 Inheritance . . . . . . . . . . . . . . . . . . . 24
6.4.5.2. Managing Variation: Optionality . . . . . . . . . 24 6.4.5.2. Managing Variation: Optionality . . . . . . . . . 24
6.4.5.3. Managing Variation: Templating . . . . . . . . . 24 6.4.5.3. Managing Variation: Templating . . . . . . . . . 25
6.4.5.4. Object Relationships . . . . . . . . . . . . . . 25 6.4.5.4. Object Relationships . . . . . . . . . . . . . . 25
6.4.5.4.1. Initialization . . . . . . . . . . . . . . . 25 6.4.5.4.1. Initialization . . . . . . . . . . . . . . . 25
6.4.5.4.2. Correlation Identification . . . . . . . . . 25 6.4.5.4.2. Correlation Identification . . . . . . . . . 26
6.4.5.4.3. Object References . . . . . . . . . . . . . . 26 6.4.5.4.3. Object References . . . . . . . . . . . . . . 26
6.4.5.4.4. Active Reference . . . . . . . . . . . . . . 26 6.4.5.4.4. Active Reference . . . . . . . . . . . . . . 26
7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 26 7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 26
7.1. One Control and Data Exchange Protocol . . . . . . . . . 26 7.1. One Control and Data Exchange Protocol . . . . . . . . . 26
7.2. Communication Channels . . . . . . . . . . . . . . . . . 26 7.2. Communication Channels . . . . . . . . . . . . . . . . . 27
7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 27 7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 27
7.4. Scope Policy Specifications . . . . . . . . . . . . . . . 27 7.4. Scope Policy Specifications . . . . . . . . . . . . . . . 28
7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 28 7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 28
7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 28 7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 29
7.7. Information collection . . . . . . . . . . . . . . . . . 29 7.7. Information collection . . . . . . . . . . . . . . . . . 29
7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 29 7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 30
7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 30 7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 30
8. Operational and Manageability Considerations . . . . . . . . 30 8. Operational and Manageability Considerations . . . . . . . . 31
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
11. Informative References . . . . . . . . . . . . . . . . . . . 32 11. Informative References . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 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, IS-IS, 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
skipping to change at page 3, line 38 skipping to change at page 3, line 38
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
verify that programmed state is installed in the forwarding plane, to verify that programmed state is installed in the forwarding plane, to
measure the behavior of various flows, routes or forwarding entries, measure the behavior of various flows, routes or forwarding entries,
as well as to understand the configured and active states of the as well as to understand the configured and active states of the
router. router. Network-oriented applications also require easy access to an
interface which will allow them to program and control state related
to forwarding.
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 Operating System (OS) provide useful mechanisms that and a router's Operating System (OS) provide useful mechanisms that
skipping to change at page 3, line 50 skipping to change at page 4, line 4
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 Operating System (OS) provide useful mechanisms that and a router's Operating System (OS) provide useful mechanisms that
applications could harness to accomplish application-level goals. applications could harness to accomplish application-level goals.
These network-oriented applications can leverage the I2RS These network-oriented applications can leverage the I2RS
programmatic interface to create new ways of combining retrieval of programmatic interface to create new ways of combining retrieval of
internet routing data, analyzing this data, setting state within internet routing data, analyzing this data, setting state within
routers. 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
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. The I2RS provides
a framework for applications (including controller applications) to
register and to request the appropriate information for each
particular application.
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
I2RS solution may be useful in domains other than routing, I2RS and I2RS solution may be useful in domains other than routing, I2RS and
this document are specifically focused on an interface for routing this document are specifically focused on an interface for routing
data. data.
1.1. Drivers for the I2RS Architecture 1.1. Drivers for the I2RS Architecture
There are four key drivers that shape the I2RS architecture. First There are four key drivers that shape the I2RS architecture. First
skipping to change at page 6, line 13 skipping to change at page 6, line 17
describes how access is mediated by authentication and access control describes how access is mediated by authentication and access control
mechanisms. Figure 1 shows I2RS agents being able to write ephemeral mechanisms. Figure 1 shows I2RS agents being able to write ephemeral
static state (e.g. RIB entries), and to read from dynamic static static state (e.g. RIB entries), and to read from dynamic static
(e.g. MPLS LSP-ID or number of active BGP peers). In addition, the (e.g. MPLS LSP-ID or number of active BGP peers). In addition, the
In addition to read and write access, the I2RS agent allows clients In addition to read and write access, the I2RS agent allows clients
to subscribe to different types of notifications about events to subscribe to different types of notifications about events
affecting different object instances. One example of a notification affecting different object instances. One example of a notification
of such an event (which is unrelated to an object creation, of such an event (which is unrelated to an object creation,
modification or deletion) is when a next-hop in the RIB is resolved 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 in a way that allows it to be used by a RIB manager for installation
plane as part of a particular route. Please see Section 7.6 and in the forwarding plane as part of a particular route. Please see
Section 7.7 for details. 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 12, line 12 skipping to change at page 12, line 12
Adding complexity beyond what is needed to satisfy well known and Adding complexity beyond what is needed to satisfy well known and
understood requirements would hinder the ease of implementation, the understood requirements would hinder the ease of implementation, the
robustness of the protocol, and the deployability of the protocol. robustness of the protocol, and the deployability of the protocol.
Overly complex data models tend to ossify information sets by Overly complex data models tend to ossify information sets by
attempting to describe and close off every possible option, attempting to describe and close off every possible option,
complicating extensibility. complicating extensibility.
Thus, one of the key aims for I2RS is the keep the protocol and Thus, one of the key aims for I2RS is the keep the protocol and
modeling architecture simple. So for each architectural component or modeling architecture simple. So for each architectural component or
aspect, we ask ourselves "do we need this complexity, or is the aspect, we ask ourselves "do we need this complexity, or is the
behavior merely nice to have?" Protocol parsimony is clearly a goal. behavior merely nice to have?"
3.2. Extensibility 3.2. Extensibility
Extensibility of the protocol and data model is very important. In Extensibility of the protocol and data model is very important. In
particular, given the necessary scope limitations of the initial particular, given the necessary scope limitations of the initial
work, it is critical that the initial design include strong support work, it is critical that the initial design include strong support
for extensibility. for extensibility.
The scope of the I2RS work is being restricted in the interests of The scope of the I2RS work is being restricted in the interests of
achieving a deliverable and deployable result. The I2RS Working achieving a deliverable and deployable result. The I2RS Working
skipping to change at page 18, line 42 skipping to change at page 18, line 42
It is expected that an I2RS Agent may fail independently of the It is expected that an I2RS Agent may fail independently of the
associated routing element. This could happen because I2RS is associated routing element. This could happen because I2RS is
disabled on the routing element or because the I2RS Agent, a separate disabled on the routing element or because the I2RS Agent, a separate
process or even running on a separate processor, experiences an process or even running on a separate processor, experiences an
unexpected failure. Just as routing state learned from a failed unexpected failure. Just as routing state learned from a failed
source is removed, the ephemeral I2RS state will usually be removed source is removed, the ephemeral I2RS state will usually be removed
shortly after the failure is detected or as part of a graceful shortly after the failure is detected or as part of a graceful
shutdown process. To handle I2RS Agent failure, the I2RS Agent must shutdown process. To handle I2RS Agent failure, the I2RS Agent must
use two different notifications. use two different notifications.
NOTIFICATION_I2RS_AGENT_STARTING: This notification identifies that NOTIFICATION_I2RS_AGENT_STARTING: This notification signals to the
the associated I2RS Agent has started. It includes an agent-boot- I2RS Client(s) that the associated I2RS Agent has started. It
count that indicates how many times the I2RS Agent has restarted includes an agent-boot-count that indicates how many times the
since the associated routing element restarted. The agent-boot- I2RS Agent has restarted since the associated routing element
count allows an I2RS Client to determine if the I2RS Agent has restarted. The agent-boot-count allows an I2RS Client to
restarted. determine if the I2RS Agent has restarted. (Note: This
notification will be only transmitted to I2RS clients which are
know in some way after a reboot.)
NOTIFICATION_I2RS_AGENT_TERMINATING: This notification reports that NOTIFICATION_I2RS_AGENT_TERMINATING: This notification reports that
the associated I2RS Agent is shutting down gracefully. Ephemeral the associated I2RS Agent is shutting down gracefully, and that
state will be removed. It can optionally include a timestamp I2RS ephemeral state will be removed. It can optionally include a
indicating when the I2RS Agent will shutdown. Use of this timestamp indicating when the I2RS Agent will shutdown. Use of
timestamp assumes that time synchronization has been done and the this timestamp assumes that time synchronization has been done and
timestamp should not have granularity finer than one second the timestamp should not have granularity finer than one second
because better accuracy of shutdown time is not guaranteed. because better accuracy of shutdown time is not guaranteed.
There are two different failure types that are possible and each has There are two different failure types that are possible and each has
different behavior. different behavior.
Unexpected failure: In this case, the I2RS Agent has unexpectedly Unexpected failure: In this case, the I2RS Agent has unexpectedly
crashed and thus cannot notify its clients of anything. Since crashed and thus cannot notify its clients of anything. Since
I2RS does not require a persistent connection between the I2RS I2RS does not require a persistent connection between the I2RS
Client and I2RS Agent, it is necessary to have a mechanism for the Client and I2RS Agent, it is necessary to have a mechanism for the
I2RS Agent to notify I2RS Clients that had subscriptions or I2RS Agent to notify I2RS Clients that had subscriptions or
skipping to change at page 19, line 48 skipping to change at page 20, line 4
An I2RS Agent may decide that some state should no longer be applied. An I2RS Agent may decide that some state should no longer be applied.
An I2RS Client may instruct an Agent to remove state it has applied. An I2RS Client may instruct an Agent to remove state it has applied.
In all such cases, the state will revert to what it would have been In all such cases, the state will revert to what it would have been
without the I2RS client-agent interaction; that state is generally without the I2RS client-agent interaction; that state is generally
whatever was specified via the CLI, NETCONF, SNMP, etc. I2RS Agents whatever was specified via the CLI, NETCONF, SNMP, etc. I2RS Agents
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 Configuration 6.3. Interactions with Local Configuration
Changes may originate from either Local Configuration or from I2RS. Changes may originate from either Local Configuration or from I2RS.
The 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. The
That policy can determine whether Local Configuration overrides a deterministic model is the result of general I2RS rules, system
particular I2RS client's request or vice versa. To achieve this end, rules, knobs adjust by operator-applied policy, and the rules
either by default Local Configuration always wins or, optionally, a associated with the yang data model (often in MUST and WHEN clauses
routing element may permit a priority to be configured on the device for dependencies).
for the Local Configuration mechanism. The policy mechanism in the
later case is comparing the I2RS client's priority with that priority This operator-applied policy can determine whether Local
assigned to the Local Configuration. Configuration overrides a particular I2RS client's request or vice
versa. To achieve this end, the I2RS data modules have a general
rule that by default the Local Configuration always wins.
Optionally, a routing element may permit a priority to be to be
configured on the device for the Local Configuration mechanism
interaction with the I2RS model. The policy mechanism would compare
the I2RS client's priority with that priority assigned to the Local
Configuration in order to determine whether Local Configuration or
I2RS wins.
For the case when the I2RS ephemeral state always wins for a data
model, if there is an I2RS ephemeral state value it is installed
instead of the local configuration state. The local configuration
information is stored so that if/when I2RS client removes I2RS
ephemeral state the local configuration state can be restored.
When the Local Configuration always wins, some communication between When the Local Configuration always wins, some communication between
that subsystem and the I2RS Agent is still necessary. That that subsystem and the I2RS Agent is still necessary. As an I2RS
communication contains the details of each specific device Agent connects to the routing sub-system, the I2RS Agent must also
configuration change that the I2RS Agent is permitted to modify. In communicate with the Local Configuration to exchange model
addition, when the system determines, that a client's I2RS state is information so the I2RS agent knows the details of each specific
preempted, the I2RS agent must notify the affected I2RS clients; how device configuration change that the I2RS Agent is permitted to
the system determines this is implementation-dependent. modify. In addition, when the system determines, that a client's
I2RS state is preempted, the I2RS agent must notify the affected I2RS
clients; how 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 26, line 52 skipping to change at page 27, line 18
support suitable congestion control mechanisms. The transports support suitable congestion control mechanisms. The transports
chosen should be operator and implementor friendly to ease adoption. 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 I2RS protocol. communication channels will use the same higher-layer I2RS protocol
(which combines secure transport and I2RS contextual information).
The use of additional channels for communication will be coordinated The use of additional channels for communication will be coordinated
between the I2RS client and the I2RS agent using this protocol. between the I2RS client and the I2RS agent using this protocol.
I2RS protocol communication may be delivered in-band via the routing I2RS protocol communication may be delivered in-band via the routing
system's data plane. I2RS protocol communication might be delivered system's data plane. I2RS protocol communication might be delivered
out-of-band via a management interface. Depending on what operations out-of-band via a management interface. Depending on what operations
are requested, it is possible for the I2RS protocol communication to are requested, it is possible for the I2RS protocol communication to
cause the in-band communication channels to stop working; this could cause the in-band communication channels to stop working; this could
cause the I2RS agent to become unreachable across that communication cause the I2RS agent to become unreachable across that communication
channel. channel.
skipping to change at page 32, line 12 skipping to change at page 32, line 33
Brim, Thomas Narten, Dean Bogdanovic, Tom Petch, Robert Raszuk, Brim, Thomas Narten, Dean Bogdanovic, Tom Petch, Robert Raszuk,
Sriganesh Kini, John Mattsson, Nancy Cam-Winget, DaCheng Zhang, Qin Sriganesh Kini, John Mattsson, Nancy Cam-Winget, DaCheng Zhang, Qin
Wu, Ahmed Abro, Salman Asadullah, Eric Yu, and Deborah Brungard for Wu, Ahmed Abro, Salman Asadullah, Eric Yu, and Deborah Brungard for
their suggestions and review. their suggestions and review.
11. Informative References 11. Informative References
[I-D.ietf-i2rs-problem-statement] [I-D.ietf-i2rs-problem-statement]
Atlas, A., Nadeau, T., and D. Ward, "Interface to the Atlas, A., Nadeau, T., and D. Ward, "Interface to the
Routing System Problem Statement", draft-ietf-i2rs- Routing System Problem Statement", draft-ietf-i2rs-
problem-statement-08 (work in progress), December 2015. problem-statement-10 (work in progress), February 2016.
[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-09 (work in Protocol", draft-ietf-netconf-restconf-09 (work in
progress), December 2015. progress), December 2015.
[I-D.ietf-netmod-rfc6020bis] [I-D.ietf-netmod-rfc6020bis]
Bjorklund, M., "The YANG 1.1 Data Modeling Language", Bjorklund, M., "The YANG 1.1 Data Modeling Language",
draft-ietf-netmod-rfc6020bis-09 (work in progress), draft-ietf-netmod-rfc6020bis-11 (work in progress),
December 2015. February 2016.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>. <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>.
 End of changes. 28 change blocks. 
56 lines changed or deleted 77 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/