draft-ietf-i2rs-architecture-14.txt   draft-ietf-i2rs-architecture-15.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: October 23, 2016 Ericsson Expires: October 24, 2016 Ericsson
S. Hares S. Hares
Huawei Huawei
D. Ward D. Ward
Cisco Systems Cisco Systems
T. Nadeau T. Nadeau
Brocade Brocade
April 21, 2016 April 22, 2016
An Architecture for the Interface to the Routing System An Architecture for the Interface to the Routing System
draft-ietf-i2rs-architecture-14 draft-ietf-i2rs-architecture-15
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 high-level architecture, the routing system. It describes the high-level architecture, the
building blocks of this high-level architecture, and their interfaces building blocks of this high-level architecture, and their interfaces
with particular focus on those to be standardized as part of the with particular focus on those to be standardized as part of the
Interface to Routing System (I2RS). Interface to Routing System (I2RS).
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 October 23, 2016. This Internet-Draft will expire on October 24, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
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 . . . . . . . . . . . . . . . . 12 3. Key Architectural Properties . . . . . . . . . . . . . . . . 12
3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 12 3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 12
3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 13 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12
3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 13 3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
4.1. Identity and Authentication . . . . . . . . . . . . . . . 16 4.1. Identity and Authentication . . . . . . . . . . . . . . . 16
4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Client Redundancy . . . . . . . . . . . . . . . . . . . . 17 4.3. Client Redundancy . . . . . . . . . . . . . . . . . . . . 17
4.4. I2RS in Personal Devices . . . . . . . . . . . . . . . . 18 4.4. I2RS in Personal Devices . . . . . . . . . . . . . . . . 17
5. Network Applications and I2RS Client . . . . . . . . . . . . 18 5. Network Applications and I2RS Client . . . . . . . . . . . . 18
5.1. Example Network Application: Topology Manager . . . . . . 19 5.1. Example Network Application: Topology Manager . . . . . . 18
6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 19 6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 19
6.1. Relationship to its Routing Element . . . . . . . . . . . 19 6.1. Relationship to its Routing Element . . . . . . . . . . . 19
6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 20 6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 19
6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 20 6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 20
6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 21 6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 21
6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 21 6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 21
6.3. Interactions with Local Configuration . . . . . . . . . . 22 6.3. Interactions with Local Configuration . . . . . . . . . . 21
6.3.1. Examples of Local Configuration vs. I2RS Ephemeral 6.3.1. Examples of Local Configuration vs. I2RS Ephemeral
Configuration . . . . . . . . . . . . . . . . . . . . 23 Configuration . . . . . . . . . . . . . . . . . . . . 23
6.4. Routing Components and Associated I2RS Services . . . . . 25 6.4. Routing Components and Associated I2RS Services . . . . . 24
6.4.1. Routing and Label Information Bases . . . . . . . . . 26 6.4.1. Routing and Label Information Bases . . . . . . . . . 25
6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 27 6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 26
6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 28 6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 26
6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 28 6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 27
6.4.5. Information Modeling, Device Variation, and 6.4.5. Information Modeling, Device Variation, and
Information Relationships . . . . . . . . . . . . . . 28 Information Relationships . . . . . . . . . . . . . . 27
6.4.5.1. Managing Variation: Object Classes/Types and 6.4.5.1. Managing Variation: Object Classes/Types and
Inheritance . . . . . . . . . . . . . . . . . . . 28 Inheritance . . . . . . . . . . . . . . . . . . . 27
6.4.5.2. Managing Variation: Optionality . . . . . . . . . 29 6.4.5.2. Managing Variation: Optionality . . . . . . . . . 28
6.4.5.3. Managing Variation: Templating . . . . . . . . . 29 6.4.5.3. Managing Variation: Templating . . . . . . . . . 28
6.4.5.4. Object Relationships . . . . . . . . . . . . . . 30 6.4.5.4. Object Relationships . . . . . . . . . . . . . . 29
6.4.5.4.1. Initialization . . . . . . . . . . . . . . . 30 6.4.5.4.1. Initialization . . . . . . . . . . . . . . . 29
6.4.5.4.2. Correlation Identification . . . . . . . . . 30 6.4.5.4.2. Correlation Identification . . . . . . . . . 29
6.4.5.4.3. Object References . . . . . . . . . . . . . . 31 6.4.5.4.3. Object References . . . . . . . . . . . . . . 30
6.4.5.4.4. Active Reference . . . . . . . . . . . . . . 31 6.4.5.4.4. Active Reference . . . . . . . . . . . . . . 30
7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 31 7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 30
7.1. One Control and Data Exchange Protocol . . . . . . . . . 31 7.1. One Control and Data Exchange Protocol . . . . . . . . . 30
7.2. Communication Channels . . . . . . . . . . . . . . . . . 32 7.2. Communication Channels . . . . . . . . . . . . . . . . . 31
7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 32 7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 31
7.4. Scope Policy Specifications . . . . . . . . . . . . . . . 33 7.4. Scope Policy Specifications . . . . . . . . . . . . . . . 32
7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 33 7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 32
7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 34 7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 33
7.7. Information collection . . . . . . . . . . . . . . . . . 34 7.7. Information collection . . . . . . . . . . . . . . . . . 33
7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 35 7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 34
7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 35 7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 34
8. Operational and Manageability Considerations . . . . . . . . 36 8. Operational and Manageability Considerations . . . . . . . . 35
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.1. Normative References . . . . . . . . . . . . . . . . . . 37 11.1. Normative References . . . . . . . . . . . . . . . . . . 36
11.2. Informative References . . . . . . . . . . . . . . . . . 37 11.2. Informative References . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
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
other information about the state of the network with other routers. other information about the state of the network with other routers.
skipping to change at page 5, line 23 skipping to change at page 5, line 23
Such an interface also facilitates the injection of ephemeral state Such an interface also facilitates the injection of ephemeral state
into the routing system. Ephemeral state on a router is the state into the routing system. Ephemeral state on a router is the state
which does not survive a the reboot of a routing device or the reboot which does not survive a the reboot of a routing device or the reboot
of the software handling the I2RS software on a routing device. A of the software handling the I2RS software on a routing device. A
non-routing protocol or application could inject state into a routing non-routing protocol or application could inject state into a routing
element via the state-insertion functionality of the I2RS and that element via the state-insertion functionality of the I2RS and that
state could then be distributed in a routing or signaling protocol state could then be distributed in a routing or signaling protocol
and/or be used locally (e.g. to program the co-located forwarding and/or be used locally (e.g. to program the co-located forwarding
plane). I2RS will only permit modification of state that would be plane). I2RS will only permit modification of state that would be
safe, conceptually, to modify via local configuration; no direct possible to modify via local configuration; no direct manipulation of
manipulation of protocol-internal dynamically determined data is protocol-internal dynamically determined data is envisioned.
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
I2RS client can provide access to one or more applications. This I2RS client can provide access to one or more applications. This
figure also shows the types of data models associated with the figure also shows the types of data models associated with the
routing system (dynamic configuration, static configuration, local routing system (dynamic configuration, static configuration, local
configuration, and routing and signaling configuration) which the configuration, and routing and signaling configuration) which the
skipping to change at page 11, line 45 skipping to change at page 11, line 45
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.
ephemeral data: is data which does not persist across a reboot ephemeral data: is data which does not persist across a reboot
(software or hardware) or a power on/off condition. Ephemeral (software or hardware) or a power on/off condition. Ephemeral
data can be configured data or data recorded from operations of data can be configured data or data recorded from operations of
the router. Ephemeral configuration data also has the property the router. Ephemeral configuration data also has the property
that a system cannot roll back to a previous ephemeral that a system cannot roll back to a previous ephemeral
configuration state. configuration state.
safe modification of routing state via I2RS: are I2RS ephemeral
configuration changes which which modify local configuration
rather than the direct modification of protocol-internal state.
Direct modifications to protocol-internal state may have unsafe
consequences.
groups: NETCONF Network Access [RFC6536] uses the term group in groups: NETCONF Network Access [RFC6536] uses the term group in
terms of an Administrative group which supports the well- terms of an Administrative group which supports the well-
established distinction between a root account and other types of established distinction between a root account and other types of
less-privileged conceptual user accounts. Group still refers to a less-privileged conceptual user accounts. Group still refers to a
single identity (e.g. root) which is shared by a group of users. single identity (e.g. root) which is shared by a group of users.
routing system/subsystem: is a set of software and hardware that routing system/subsystem: is a set of software and hardware that
handles determining where packets are forwarded to which the I2RS handles determining where packets are forwarded to which the I2RS
system connects. The term "packets" may be qualified to be layer system connects. The term "packets" may be qualified to be layer
1 frames, layer 2 frames or layer 3 packets. The phrase "Internet 1 frames, layer 2 frames or layer 3 packets. The phrase "Internet
skipping to change at page 27, line 7 skipping to change at page 26, line 7
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 or per-context. Information Bases, per-platform or per-interface or per-context.
This functionality, exposed via an I2RS Service, must interact This functionality, exposed via an I2RS Service, must interact
smoothly with the same mechanisms that the routing element already smoothly with the same mechanisms that the routing element already
uses to handle RIB input from multiple sources, so as to safely uses to handle RIB input from multiple sources. Conceptually, this
change the system state. Conceptually, this can be handled by having can be handled by having the I2RS agent communicate with a RIB
the I2RS agent communicate with a RIB Manager as a separate routing Manager as a separate routing source.
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
 End of changes. 15 change blocks. 
53 lines changed or deleted 45 lines changed or added

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