draft-ietf-i2rs-architecture-06.txt   draft-ietf-i2rs-architecture-07.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 5, 2015 Ericsson Expires: June 14, 2015 Ericsson
S. Hares S. Hares
Huawei Huawei
D. Ward D. Ward
Cisco Systems Cisco Systems
T. Nadeau T. Nadeau
Brocade Brocade
December 2, 2014 December 11, 2014
An Architecture for the Interface to the Routing System An Architecture for the Interface to the Routing System
draft-ietf-i2rs-architecture-06 draft-ietf-i2rs-architecture-07
Abstract Abstract
This document describes an architecture for a standard, programmatic This document describes an architecture for a standard, programmatic
interface for state transfer in and out of the internet routing interface for state transfer in and out of the internet routing
system. It describes the basic architecture, the components, and system. It describes the basic architecture, the components, and
their interfaces with particular focus on those to be standardized as their interfaces with particular focus on those to be standardized as
part of I2RS. part of 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 5, 2015. This Internet-Draft will expire on June 14, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 33 skipping to change at page 2, line 33
4.1. Identity and Authentication . . . . . . . . . . . . . . . 13 4.1. Identity and Authentication . . . . . . . . . . . . . . . 13
4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 13
5. Network Applications and I2RS Client . . . . . . . . . . . . 14 5. Network Applications and I2RS Client . . . . . . . . . . . . 14
5.1. Example Network Application: Topology Manager . . . . . . 15 5.1. Example Network Application: Topology Manager . . . . . . 15
6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 15 6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 15
6.1. Relationship to its Routing Element . . . . . . . . . . . 15 6.1. Relationship to its Routing Element . . . . . . . . . . . 15
6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 16 6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 16
6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 16 6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 16
6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 17 6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 17
6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 17 6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 17
6.3. Interactions with Local Config . . . . . . . . . . . . . 17 6.3. Interactions with Local Config . . . . . . . . . . . . . 18
6.4. Routing Components and Associated I2RS Services . . . . . 18 6.4. Routing Components and Associated I2RS Services . . . . . 18
6.4.1. Routing and Label Information Bases . . . . . . . . . 19 6.4.1. Routing and Label Information Bases . . . . . . . . . 19
6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 20 6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 20
6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 20 6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 20
6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 21 6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 21
6.4.5. Information Modeling, Device Variation, and 6.4.5. Information Modeling, Device Variation, and
Information Relationships . . . . . . . . . . . . . . 21 Information Relationships . . . . . . . . . . . . . . 21
6.4.5.1. Managing Variation: Object Classes/Types and 6.4.5.1. Managing Variation: Object Classes/Types and
Inheritance . . . . . . . . . . . . . . . . . . . 21 Inheritance . . . . . . . . . . . . . . . . . . . 21
6.4.5.2. Managing Variation: Optionality . . . . . . . . . 22 6.4.5.2. Managing Variation: Optionality . . . . . . . . . 22
skipping to change at page 5, line 15 skipping to change at page 5, line 15
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 provide access to a single application, while
Client P provides access to multiple applications. 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, Applicatons 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,
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.
skipping to change at page 8, line 31 skipping to change at page 8, line 31
operations. In order to keep the protocol simple, two clients should operations. In order to keep the protocol simple, two clients should
not attempt to write (modify) the same piece of information on an not attempt to write (modify) the same piece of information on an
I2RS Agent. This is considered an error. However, such collisions I2RS Agent. This is considered an error. However, such collisions
may happen and section 7.8 (multi-headed control) describes how the may happen and section 7.8 (multi-headed control) describes how the
I2RS agent resolves collision by first utilizing priority to resolve I2RS agent resolves collision by first utilizing priority to resolve
collisions, and second by servicing the requests in a first in, first collisions, and second by servicing the requests in a first in, first
served basis. The i2rs architecture includes this definition of served basis. The i2rs architecture includes this definition of
behavior for this case simply for predictability not because this is behavior for this case simply for predictability not because this is
an intended result. This predictability will simplify the error an intended result. This predictability will simplify the error
handling and suppress oscillations. If additional error cases beyond handling and suppress oscillations. If additional error cases beyond
this simple treatment are required, these these error cases should be this simple treatment are required, these error cases should be
resolved by the network applications and management systems. resolved by the network applications and management systems.
In contrast, although multiple I2RS clients may need to supply data In contrast, although multiple I2RS clients may need to supply data
into the same list (e.g. a prefix or filter list), this is not into the same list (e.g. a prefix or filter list), this is not
considered an error and must be correctly handled. The nuances so considered an error and must be correctly handled. The nuances so
that writers do not normally collide should be handled in the that writers do not normally collide should be handled in the
information models. information models.
The architectural goal for the I2RS is that such errors should The architectural goal for the I2RS is that such errors should
produce predictable behaviors, and be reportable to interested produce predictable behaviors, and be reportable to interested
skipping to change at page 17, line 20 skipping to change at page 17, line 20
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
written ephemeral state; such I2RS Clients should be cached by the written ephemeral state; such I2RS Clients should be cached by the
I2RS Agent's system in persistent storage. When the I2RS Agent I2RS Agent's system in persistent storage. When the I2RS Agent
starts, it should send a NOTIFICATION_I2RS_AGENT_STARTING to each starts, it should send a NOTIFICATION_I2RS_AGENT_STARTING to each
cached I2RS Client. cached I2RS Client.
Graceful failure: In this case, the I2RS Agent can do specific Graceful failure: In this case, the I2RS Agent can do specific
limited work as part of the process of being disabled. The I2RS limited work as part of the process of being disabled. The I2RS
Agent Agent must send a NOTIFICATION_I2RS_AGENT_TERMINATING to all Agent must send a NOTIFICATION_I2RS_AGENT_TERMINATING to all its
its cached I2RS Clients. cached I2RS Clients.
6.2.2. Starting and Ending 6.2.2. Starting and Ending
When an I2RS client applies changes via the I2RS protocol, those When an I2RS client applies changes via the I2RS protocol, those
changes are applied and left until removed or the routing element changes are applied and left until removed or the routing element
reboots. The network application may make decisions about what to reboots. The network application may make decisions about what to
request via I2RS based upon a variety of conditions that imply request via I2RS based upon a variety of conditions that imply
different start times and stop times. That complexity is managed by different start times and stop times. That complexity is managed by
the network application and is not handled by I2RS. the network application and is not handled by I2RS.
6.2.3. Reversion 6.2.3. Reversion
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; that state is generally whatever was specified via without the I2RS client-agent interaction; that state is generally
the CLI, NETCONF, SNMP, etc. I2RS Agents will not store multiple whatever was specified via the CLI, NETCONF, SNMP, etc. I2RS Agents
alternative states, nor try to determine which one among such a will not store multiple alternative states, nor try to determine
plurality it should fall back to. Thus, the model followed is not which one among such a plurality it should fall back to. Thus, the
like the RIB, where multiple routes are stored at different model followed is not like the RIB, where multiple routes are stored
preferences. at different preferences. (For I2RS state in the presence of two
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 Config
Changes may originate from either Local Config or from I2RS. The Changes may originate from either Local Config or from I2RS. The
modifications and data stored by I2RS are separate from the local 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
skipping to change at page 19, line 52 skipping to change at page 19, 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. This
functionality, exposed via an I2RS Service, must interact smoothly functionality, exposed via an I2RS Service, must interact smoothly
with the same mechanisms that the routing element already uses to with the same mechanisms that the routing element already uses to
handle RIB input from multiple sources, so as to safely change the handle RIB input from multiple sources, so as to safely change the
system state. Conceptually, this can be handled by having the I2RS system state. Conceptually, this can be handled by having the I2RS
Agent communicate with a RIB Manager as a separate routing source. 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.
skipping to change at page 20, line 44 skipping to change at page 20, line 44
o joining/removing interfaces from the multicast trees o joining/removing interfaces from the multicast trees
o subscribing to an information stream of route changes o subscribing to an information stream of route changes
o receiving notifications about peers coming up or going down o receiving notifications about peers coming up or going down
For example, the interaction with OSPF might include modifying the For example, the interaction with OSPF might include modifying the
local routing element's link metrics, announcing a locally-attached local routing element's link metrics, announcing a locally-attached
prefix, or reading some of the OSPF link-state database. However, prefix, or reading some of the OSPF link-state database. However,
direct modification of the link-state database MUST NOT be allowed in direct modification of the link-state database must not be allowed in
order to preserve network state consistency. order to preserve network state consistency.
6.4.3. MPLS 6.4.3. MPLS
I2RS Services will be needed to expose the protocols that create I2RS Services will be needed to expose the protocols that create
transport LSPs (e.g. LDP and RSVP-TE) as well as protocols (e.g. transport LSPs (e.g. LDP and RSVP-TE) as well as protocols (e.g.
BGP, LDP) that provide MPLS-based services (e.g. pseudowires, L3VPNs, BGP, LDP) that provide MPLS-based services (e.g. pseudowires, L3VPNs,
L2VPNs, etc). This should include all local information about LSPs L2VPNs, etc). This should include all local information about LSPs
originating in, transiting, or terminating in this Routing Element. originating in, transiting, or terminating in this Routing Element.
skipping to change at page 23, line 25 skipping to change at page 23, line 25
is a topic for further discussion. is a topic for further discussion.
6.4.5.4. Object Relationships 6.4.5.4. Object Relationships
Objects (in a Routing Element or otherwise) do not exist in Objects (in a Routing Element or otherwise) do not exist in
isolation. They are related to each other. One of the important isolation. They are related to each other. One of the important
things a class definition does is represent the relationships between things a class definition does is represent the relationships between
instances of different classes. These relationships can be very instances of different classes. These relationships can be very
simple, or quite complicated. The following lists the information simple, or quite complicated. The following lists the information
relationships that the information models need to support. relationships that the information models need to support.
[[Editors' note: All of these are for discussion, and it is expected
that the list may be changed during WG discussion.]]
6.4.5.4.1. Initialization 6.4.5.4.1. Initialization
The simplest relationship is that one object instance is initialized The simplest relationship is that one object instance is initialized
by copying another. For example, one may have an object instance by copying another. For example, one may have an object instance
that represents the default setup for a tunnel, and all new tunnels that represents the default setup for a tunnel, and all new tunnels
have fields copied from there if they are not set as part of have fields copied from there if they are not set as part of
establishment. This is closely related to the templates discussed establishment. This is closely related to the templates discussed
above, but not identical. Since the relationship is only momentary above, but not identical. Since the relationship is only momentary
it is often not formally represented in modeling, but only captured it is often not formally represented in modeling, but only captured
skipping to change at page 24, line 17 skipping to change at page 24, line 17
Sometimes the relationship between objects is stronger. A valid ARP Sometimes the relationship between objects is stronger. A valid ARP
entry has to point to the active interface over which it was derived. entry has to point to the active interface over which it was derived.
This is the classic meaning of an object reference in programming. This is the classic meaning of an object reference in programming.
It can be used for relationships like containment or dependence. It can be used for relationships like containment or dependence.
This is usually represented by an explicit modeling link. This is usually represented by an explicit modeling link.
6.4.5.4.4. Active Reference 6.4.5.4.4. Active Reference
There is an even stronger form of coupling between objects if changes There is an even stronger form of coupling between objects if changes
in one of the two objects are always to be reflected in the state of in one of the two objects are always to be reflected in the state of
the other. For example, if a Tunnel has an MTU, and link MTU changes the other. For example, if a Tunnel has an MTU (maximum transmit
need to immediately propagate to the Tunnel MTU, then the tunnel is unit), and link MTU changes need to immediately propagate to the
actively coupled to the link interface. This kind of active state Tunnel MTU, then the tunnel is actively coupled to the link
coupling implies some sort of internal bookkeeping to ensure interface. This kind of active state coupling implies some sort of
consistency, often conceptualized as a subscription model across internal bookkeeping to ensure consistency, often conceptualized as a
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 As agreed by the I2RS working group, this I2RS architecture assumes
that there is a single I2RS protocol for control and data exchange; that there is a single I2RS protocol for control and data exchange;
that protocol will be based on NETCONF[RFC6241] and RESTCONF that protocol will be based on NETCONF[RFC6241] and RESTCONF
[I-D.ietf-netconf-restconf]. This helps meet the goal of simplicity [I-D.ietf-netconf-restconf]. This helps meet the goal of simplicity
and thereby enhances deployability. That protocol may need to use and thereby enhances deployability. That protocol may need to use
several underlying transports (TCP, SCTP, DCCP), with suitable several underlying transports (TCP, SCTP (stream control transport
authentication and integrity protection mechanisms. These different protocol), DCCP (Datagram Congestion Control Protocol)), with
transports can support different types of communication (e.g. suitable authentication and integrity protection mechanisms. These
control, reading, notifications, and information collection) and different transports can support different types of communication
different sets of data. Whatever transport is used for the data (e.g. control, reading, notifications, and information collection)
and different sets of data. Whatever transport is used for the data
exchange, it must also support suitable congestion control exchange, it must also support suitable congestion control
mechanisms. The transports chosen should be operator and implementor mechanisms. The transports chosen should be operator and implementor
friendly to ease adoption. 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
skipping to change at page 28, line 26 skipping to change at page 28, line 26
considered an error case. This architecture does not attempt to considered an error case. This architecture does not attempt to
determine what the right state of data should be when such a determine what the right state of data should be when such a
collision happens. Rather, the architecture mandates that there be collision happens. Rather, the architecture mandates that there be
decidable means by which I2RS Agents handle the collisions. The decidable means by which I2RS Agents handle the collisions. The
mechanism for ensuring predictability is to have a simple priority mechanism for ensuring predictability is to have a simple priority
associated with each I2RS clients, and the highest priority change associated with each I2RS clients, and the highest priority change
remains in effect. In the case of priority ties, the first client remains in effect. In the case of priority ties, the first client
whose attribution is associated with the data will keep control. whose attribution is associated with the data will keep control.
In order for this approach to multi-headed control to be useful for In order for this approach to multi-headed control to be useful for
I2RS Clients, it is important that it be possible for an I2RS Client I2RS Clients, it is important that it is possible for an I2RS Client
to register for changes to any changes made by I2RS to data that it to register for changes to any changes made by I2RS to data that it
may care about. This is included in the I2RS event mechanisms. This may care about. This is included in the I2RS event mechanisms. This
also needs to apply to changes made by CLI/NETCONF/SNMP within the also needs to apply to changes made by CLI/NETCONF/SNMP within the
write-scope of the I2RS Agent, as the same priority mechanism (even write-scope of the I2RS Agent, as the same priority mechanism (even
if it is "CLI always wins") applies there. The I2RS client may then if it is "CLI always wins") applies there. The I2RS client may then
respond to the situation as it sees fit. respond to the situation as it sees fit.
7.9. Transactions 7.9. Transactions
In the interest of simplicity, the I2RS architecture does not include In the interest of simplicity, the I2RS architecture does not include
skipping to change at page 30, line 15 skipping to change at page 30, line 15
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
Crabbe, Ken Gray, Carlos Pignataro, Wes George, Ron Bonica, Joe Crabbe, Ken Gray, Carlos Pignataro, Wes George, Ron Bonica, Joe
Clarke, Juergen Schoenwalder, Jeff Haas, Jamal Hadi Salim, Scott Clarke, Juergen Schoenwalder, Jeff Haas, Jamal Hadi Salim, Scott
Brim, Thomas Narten, Dean Bogdanovi, Tom Petch, Robert Raszuk, Brim, Thomas Narten, Dean Bogdanovi, 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, and Eric Wu for their suggestions Wu, Ahmed Abro, Salman Asadullah, and Eric Yu. for their suggestions
and review. 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-04 (work in progress), June 2014. problem-statement-04 (work in progress), June 2014.
[I-D.ietf-idr-ls-distribution] [I-D.ietf-idr-ls-distribution]
 End of changes. 16 change blocks. 
32 lines changed or deleted 32 lines changed or added

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