--- 1/draft-ietf-i2rs-architecture-07.txt 2015-01-07 14:14:52.656987223 -0800 +++ 2/draft-ietf-i2rs-architecture-08.txt 2015-01-07 14:14:52.724988892 -0800 @@ -1,54 +1,54 @@ Network Working Group A. Atlas Internet-Draft Juniper Networks Intended status: Informational J. Halpern -Expires: June 14, 2015 Ericsson +Expires: July 11, 2015 Ericsson S. Hares Huawei D. Ward Cisco Systems T. Nadeau Brocade - December 11, 2014 + January 7, 2015 An Architecture for the Interface to the Routing System - draft-ietf-i2rs-architecture-07 + draft-ietf-i2rs-architecture-08 Abstract 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 their interfaces with particular focus on those to be standardized as - part of I2RS. + part of the Interface to Routing System (I2RS). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on June 14, 2015. + This Internet-Draft will expire on July 11, 2015. Copyright Notice - Copyright (c) 2014 IETF Trust and the persons identified as the + Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -59,71 +59,71 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Drivers for the I2RS Architecture . . . . . . . . . . . . 4 1.2. Architectural Overview . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Key Architectural Properties . . . . . . . . . . . . . . . . 10 3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4.1. Identity and Authentication . . . . . . . . . . . . . . . 13 - 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 13 - 5. Network Applications and I2RS Client . . . . . . . . . . . . 14 + 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 14 + 4.3. Client Redundancy . . . . . . . . . . . . . . . . . . . . 14 + 5. Network Applications and I2RS Client . . . . . . . . . . . . 15 5.1. Example Network Application: Topology Manager . . . . . . 15 - 6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 15 - 6.1. Relationship to its Routing Element . . . . . . . . . . . 15 + 6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 16 + 6.1. Relationship to its Routing Element . . . . . . . . . . . 16 6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 16 - 6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 16 - 6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 17 - 6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 17 + 6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 17 + 6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 18 + 6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 18 6.3. Interactions with Local Config . . . . . . . . . . . . . 18 - 6.4. Routing Components and Associated I2RS Services . . . . . 18 - 6.4.1. Routing and Label Information Bases . . . . . . . . . 19 - 6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 20 - 6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 20 - 6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 21 + 6.4. Routing Components and Associated I2RS Services . . . . . 19 + 6.4.1. Routing and Label Information Bases . . . . . . . . . 20 + 6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 21 + 6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 21 + 6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 22 6.4.5. Information Modeling, Device Variation, and - Information Relationships . . . . . . . . . . . . . . 21 + Information Relationships . . . . . . . . . . . . . . 22 6.4.5.1. Managing Variation: Object Classes/Types and - Inheritance . . . . . . . . . . . . . . . . . . . 21 - 6.4.5.2. Managing Variation: Optionality . . . . . . . . . 22 - 6.4.5.3. Managing Variation: Templating . . . . . . . . . 22 - 6.4.5.4. Object Relationships . . . . . . . . . . . . . . 23 - 6.4.5.4.1. Initialization . . . . . . . . . . . . . . . 23 - 6.4.5.4.2. Correlation Identification . . . . . . . . . 23 - 6.4.5.4.3. Object References . . . . . . . . . . . . . . 24 - 6.4.5.4.4. Active Reference . . . . . . . . . . . . . . 24 - 7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 24 - 7.1. One Control and Data Exchange Protocol . . . . . . . . . 24 - 7.2. Communication Channels . . . . . . . . . . . . . . . . . 24 - 7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 25 - 7.4. Identity and Security Role . . . . . . . . . . . . . . . 25 - 7.4.1. Client Redundancy . . . . . . . . . . . . . . . . . . 26 - 7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 26 + Inheritance . . . . . . . . . . . . . . . . . . . 22 + 6.4.5.2. Managing Variation: Optionality . . . . . . . . . 23 + 6.4.5.3. Managing Variation: Templating . . . . . . . . . 23 + 6.4.5.4. Object Relationships . . . . . . . . . . . . . . 24 + 6.4.5.4.1. Initialization . . . . . . . . . . . . . . . 24 + 6.4.5.4.2. Correlation Identification . . . . . . . . . 24 + 6.4.5.4.3. Object References . . . . . . . . . . . . . . 25 + 6.4.5.4.4. Active Reference . . . . . . . . . . . . . . 25 + 7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 25 + 7.1. One Control and Data Exchange Protocol . . . . . . . . . 25 + 7.2. Communication Channels . . . . . . . . . . . . . . . . . 25 + 7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 26 + 7.4. Scope Policy Specifications . . . . . . . . . . . . . . . 26 + 7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 27 7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 27 - 7.7. Information collection . . . . . . . . . . . . . . . . . 27 + 7.7. Information collection . . . . . . . . . . . . . . . . . 28 7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 28 - 7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 28 + 7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 29 8. Operational and Manageability Considerations . . . . . . . . 29 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 11. Informative References . . . . . . . . . . . . . . . . . . . 30 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction Routers that form the internet routing infrastructure maintain state at various layers of detail and function. For example, a typical router maintains a Routing Information Base (RIB), and implements - routing protocols such as OSPF, ISIS, and BGP to exchange protocol - state and other information about the state of the network with other - routers. + routing protocols such as OSPF, ISIS, and BGP to exchange + reachability information, topology information, protocol state, and + other information about the state of the network with other routers. Routers convert all of this information into forwarding entries which are then used to forward packets and flows between network elements. The forwarding plane and the specified forwarding entries then contain active state information that describes the expected and observed operational behavior of the router and which is also needed by the network applications. Network-oriented applications require easy access to this information to learn the network topology, to verify that programmed state is installed in the forwarding plane, to measure the behavior of various flows, routes or forwarding entries, @@ -136,28 +136,28 @@ state (for example, a Routing Element RIB manager's state), as well as enabling network-oriented applications to be built on top of today's routed networks. The I2RS is a programmatic asynchronous interface for transferring state into and out of the internet routing system. This I2RS architecture recognizes that the routing system and a router's OS provide useful mechanisms that applications could harness to accomplish application-level goals. Fundamental to the I2RS are clear data models that define the semantics of the information that can be written and read. The I2RS - provides a framework for registering for and requesting the + 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 leveraging the existing routing system as desired. Although the I2RS architecture is general enough to support information and data models for a variety of data, and aspects of the - I2RS solution may be useful in domain 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 data. 1.1. Drivers for the I2RS Architecture There are four key drivers that shape the I2RS architecture. First is the need for an interface that is programmatic, asynchronous, and offers fast, interactive access for atomic operations. Second is the access to structured information and state that is frequently not directly configurable or modeled in existing implementations or @@ -427,34 +427,42 @@ resources: A resource is an I2RS-specific use of memory, storage, 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 context of a particular agent may be constrained based upon the client's security role. An example of such a resource could include the number of notifications registered for. These are not protocol-specific resources or network-specific resources. role or security role: A security role specifies the scope, - resources, priorities, etc. that a client or agent has. + resources, priorities, etc. that a client or agent has. Multiple + identities may use the same security role. identity: A client is associated with exactly one specific identity. State can be attributed to a particular identity. It is possible for multiple communication channels to use the same identity; in that case, the assumption is that the associated client is coordinating such communication. secondary identity: An I2RS Client may supply a secondary opaque identity that is not interpreted by the I2RS Agent. An example use is when the I2RS Client is a go-between for multiple applications and it is necessary to track which application has requested a particular operation. + Groups: NETCONF Network Access [RFC6536] refers uses the term group + in terms of an Administrative group which supports support the + well-established distinction between a root account and other + types of less-privileged conceptual user accounts. Group still + refers to a single identity (e.g. root) which is shared by a group + of users. + 3. Key Architectural Properties Several key architectural properties for the I2RS protocol are elucidated below (simplicity, extensibility, and model-driven programmatic interfaces). However, some architecture principles such as performance and scaling are not described below because they are discussed in [I-D.ietf-i2rs-problem-statement] and because the performance and scaling requires varies based on the particular use- cases. @@ -562,22 +570,22 @@ authentication and authorization for that communication is out of scope; nothing prevents I2RS and a separate authentication and authorization channel from being used. Regardless of mechanism, an I2RS Client that is acting as a broker is responsible for determining that applications using it are trusted and permitted to make the particular requests. Different levels of integrity, confidentiality, and replay protection are relevant for different aspects of I2RS. The primary communication channel that is used for client authentication and then - used by the client to write data requires integrity, privacy and - replay protection. Appropriate selection of a default required + used by the client to write data requires integrity, confidentiality + and replay protection. Appropriate selection of a default required transport protocol is the preferred way of meeting these requirements. Other communications via I2RS may not require integrity, confidentiality, and replay protection. For instance, if an I2RS Client subscribes to an information stream of prefix announcements from OSPF, those may require integrity but probably not confidentiality or replay protection. Similarly, an information stream of interface statistics may not even require guaranteed delivery. In Section 7.2, more reasoning for multiple communication @@ -598,61 +606,81 @@ of the system must be accurately attributable. In an ideal architecture, even information collection and notification should be protected; this may be subject to engineering tradeoffs during the design. I2RS clients may be operating on behalf of other applications. While those applications' identities are not needed for authentication or authorization, each application should have a unique opaque identifier that can be provided by the I2RS client to the I2RS agent for purposes of tracking attribution of operations to support - functionality such as accounting and troubleshooting. + functionality such as troubleshooting and logging of network changes. 4.2. Authorization All operations using I2RS, both observation and manipulation, should be subject to appropriate authorization controls. Such authorization is based on the identity and assigned role of the I2RS client performing the operations and the I2RS agent in the network element. + (Multiple Identities may use the same role). I2RS Agents, in performing information collection and manipulation, will be acting on behalf of the I2RS clients. As such, each operation authorization will be based on the lower of the two permissions of the agent itself and of the authenticated client. The mechanism by which this authorization is applied within the device is outside of the scope of I2RS. The appropriate or necessary level of granularity for scope can depend upon the particular I2RS Service and the implementation's granularity. An approach to a similar access control problem is - defined in the NetConf Access Control Model[RFC6536]; it allows - arbitrary access to be specified for a data node instance identifier - while defining meaningful manipulable defaults. The ability to - specify one or more groups or roles that a particular I2RS Client - belongs and then define access controls in terms of those groups or - roles is expected. When a client is authenticated, its group or role - membership should be provided to the I2RS Agent. The set of access - control rules that an I2RS Agent uses would need to be either - provided via Local Config, exposed as an I2RS Service for - manipulation by authorized clients, or via some other method. + defined in the NetConf Access Control Model (NACM) [RFC6536]; it + allows arbitrary access to be specified for a data node instance + identifier while defining meaningful manipulable defaults. The + 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 + policy that contained in a a set of access control rules. Similarly, + 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 + is can be provided via Local Config, exposed as an I2RS Service for + manipulation by authorized clients, or via some other method (e.g. + AAA service) + + 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 + scope policy. Multiple identities may link to the same role (e.g + ability to read I2RS RIB). + +4.3. Client Redundancy + + I2RS must support client redundancy. At the simplest, this can be + handled by having a primary and a backup network application that + both use the same client identity and can successfully authenticate + as such. Since I2RS does not require a continuous transport + connection and supports multiple transport sessions, this can provide + some basic redundancy. However, it does not address the need for + troubleshooting and logging of network changes to be informed about + which network application is actually active. At a minimum, basic + transport information about each connection and time can be logged + with the identity. 5. Network Applications and I2RS Client I2RS is expected to be used by network-oriented applications in different architectures. While the interface between a network- oriented application and the I2RS client is outside the scope of I2RS, considering the different architectures is important to sufficiently specify I2RS. - In the simplest architecture, a network-oriented application has an - I2RS client as a library or driver for communication with routing - elements. + In the simplest architecture of direct access, a network-oriented + application has an I2RS client as a library or driver for + communication with routing elements. In the broker architecture, multiple network-oriented applications communicate in an unspecified fashion to a broker application that contains an I2RS Client. That broker application requires additional functionality for authentication and authorization of the network- oriented applications; such functionality is out of scope for I2RS but similar considerations to those described in Section 4.2 do apply. As discussed in Section 4.1, the broker I2RS Client should determine distinct opaque identifiers for each network-oriented application that is using it. The broker I2RS Client can pass along @@ -830,26 +858,26 @@ resolution cannot be time-based. Simply allowing the most recent state to prevail could cause race conditions where the final state is not repeatably deterministic. 6.4. Routing Components and Associated I2RS Services For simplicity, each logical protocol or set of functionality that can be compactly described in a separable information and data model is considered as a separate I2RS Service. A routing element need not implement all routing components described nor provide the associated - I2RS services. When a full implementation is not mandatory, an I2RS - Service should include a capability model so that implementations can - indicate which parts of the service are supported. Each I2RS Service - requires an information model that describes at least the following: - data that can be read, data that can be written, notifications that - can be subscribed to, and the capability model mentioned above. + I2RS services. I2RS Services should include a capability model so + that peers can determine which parts of the service are supported. + Each I2RS Service requires an information model that describes at + least the following: data that can be read, data that can be written, + notifications that can be subscribed to, and the capability model + mentioned above. The initial services included in the I2RS architecture are as follows. *************************** ************** ***************** * I2RS Protocol * * * * Dynamic * * * * Interfaces * * Data & * * +--------+ +-------+ * * * * Statistics * * | Client | | Agent | * ************** ***************** * +--------+ +-------+ * @@ -1010,21 +1038,21 @@ Information model should provide information that: o Is X required for the data field to be accepted and applied? o If X is optional, then how does "X" as an optional portion of data field interact with the required aspects of the data field? o Does the data field have defaults for the mandatory portion of the field and the optional portions of the field - o Is X required to be within a particular set of values (E.g. range, + o Is X required to be within a particular set of values (e.g. range, length of strings)? The information model needs to be clear about what read or write values are set by client and what responses or actions are required by the agent. It is important to indicate what is required or optional in client values and agent responses/actions. 6.4.5.3. Managing Variation: Templating A template is a collection of information to address a problem; it @@ -1158,43 +1186,30 @@ The protocol capability negotiation can be segmented into the basic version negotiation (required to ensure basic communication), and the more complex capability exchange which can take place within the base protocol mechanisms. In particular, the more complex protocol and mechanism negotiation can be addressed by defining information models for both the I2RS Agent and the I2RS Client. These information models can describe the various capability options. This can then represent and be used to communicate important information about the agent, and the capabilities thereof. -7.4. Identity and Security Role - - Each I2RS Client will have a unique identity; it can also have - secondary identities to be used for troubleshooting. A secondary - identity is merely a unique, opaque identifier that may be helpful in - troubleshooting. Via authentication and authorization mechanisms - based on the primary unique identity, the I2RS Client will have a - specific scope for reading data, for writing data, and limitations on - the resources that can be consumed. The scopes need to specify both - the data and the value ranges. - -7.4.1. Client Redundancy +7.4. Scope Policy Specifications - I2RS must support client redundancy. At the simplest, this can be - handled by having a primary and a backup network application that - both use the same client identity and can successfully authenticate - as such. Since I2RS does not require a continuous transport - connection and supports multiple transport sessions, this can provide - some basic redundancy. However, it does not address concerns for - troubleshooting and accountability about knowing which network - application is actually active. At a minimum, basic transport - information about each connection and time can be logged with the - identity. + 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 + in troubleshooting. As section 4 indicates, all authentication and + authorization mechanisms are based on the primary Identity which + links to a role with scope policy for for reading data, for writing + data, and limitations on the resources that can be consumed. + Specifications for scope policy need to specify the data and value + ranges for portion of scope policy. 7.5. Connectivity A client may or may not maintain an active communication channel with an agent. Therefore, an agent may need to open a communication channel to the client to communicate previously requested information. The lack of an active communication channel does not imply that the associated client is non-functional. When communication is required, the agent or client can open a new communication channel. @@ -1242,25 +1257,25 @@ specific types of events and filtering operations can vary by information model and need to be specified as part of the information model. The I2RS information model needs to include representation of these events. As discussed earlier, the capability information in the model will allow I2RS clients to understand which events a given I2RS Agent is capable of generating. For performance and scaling by the I2RS client and general - information privacy, an I2RS Client needs to be able to register for - just the events it is interested in. It is also possible that I2RS - might might provide a stream of notifications via a publish/subscribe - mechanism that is not amenable to having the I2RS agent do the - filtering. + information confidentiality, an I2RS Client needs to be able to + register for just the events it is interested in. It is also + possible that I2RS might provide a stream of notifications via a + publish/subscribe mechanism that is not amenable to having the I2RS + agent do the filtering. 7.7. Information collection One of the other important aspects of the I2RS is that it is intended to simplify collecting information about the state of network elements. This includes both getting a snapshot of a large amount of data about the current state of the network element, and subscribing to a feed of the ongoing changes to the set of data or a subset thereof. This is considered architecturally separate from notifications due to the differences in information rate and total