draft-ietf-i2rs-architecture-08.txt   draft-ietf-i2rs-architecture-09.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: July 11, 2015 Ericsson Expires: September 7, 2015 Ericsson
S. Hares S. Hares
Huawei Huawei
D. Ward D. Ward
Cisco Systems Cisco Systems
T. Nadeau T. Nadeau
Brocade Brocade
January 7, 2015 March 6, 2015
An Architecture for the Interface to the Routing System An Architecture for the Interface to the Routing System
draft-ietf-i2rs-architecture-08 draft-ietf-i2rs-architecture-09
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 the Interface to Routing System (I2RS). 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 July 11, 2015. This Internet-Draft will expire on September 7, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Drivers for the I2RS Architecture . . . . . . . . . . . . 4 1.1. Drivers for the I2RS Architecture . . . . . . . . . . . . 4
1.2. Architectural Overview . . . . . . . . . . . . . . . . . 5 1.2. Architectural Overview . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Key Architectural Properties . . . . . . . . . . . . . . . . 10 3. Key Architectural Properties . . . . . . . . . . . . . . . . 10
3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 11 3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
4.1. Identity and Authentication . . . . . . . . . . . . . . . 13 4.1. Identity and Authentication . . . . . . . . . . . . . . . 14
4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 14
4.3. Client Redundancy . . . . . . . . . . . . . . . . . . . . 14 4.3. Client Redundancy . . . . . . . . . . . . . . . . . . . . 15
5. Network Applications and I2RS Client . . . . . . . . . . . . 15 5. Network Applications and I2RS Client . . . . . . . . . . . . 15
5.1. Example Network Application: Topology Manager . . . . . . 15 5.1. Example Network Application: Topology Manager . . . . . . 16
6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 16 6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 16
6.1. Relationship to its Routing Element . . . . . . . . . . . 16 6.1. Relationship to its Routing Element . . . . . . . . . . . 16
6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 16 6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 17
6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 17 6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 17
6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 18 6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 18
6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 18 6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 18
6.3. Interactions with Local Config . . . . . . . . . . . . . 18 6.3. Interactions with Local Config . . . . . . . . . . . . . 19
6.4. Routing Components and Associated I2RS Services . . . . . 19 6.4. Routing Components and Associated I2RS Services . . . . . 19
6.4.1. Routing and Label Information Bases . . . . . . . . . 20 6.4.1. Routing and Label Information Bases . . . . . . . . . 20
6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 21 6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 21
6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 21 6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 21
6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 22 6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 22
6.4.5. Information Modeling, Device Variation, and 6.4.5. Information Modeling, Device Variation, and
Information Relationships . . . . . . . . . . . . . . 22 Information Relationships . . . . . . . . . . . . . . 22
6.4.5.1. Managing Variation: Object Classes/Types and 6.4.5.1. Managing Variation: Object Classes/Types and
Inheritance . . . . . . . . . . . . . . . . . . . 22 Inheritance . . . . . . . . . . . . . . . . . . . 22
6.4.5.2. Managing Variation: Optionality . . . . . . . . . 23 6.4.5.2. Managing Variation: Optionality . . . . . . . . . 23
skipping to change at page 12, line 23 skipping to change at page 12, line 23
data; this is particularly valuable for both extensibility and for data; this is particularly valuable for both extensibility and for
the ability to easily manipulate and check proprietary data-models. the ability to easily manipulate and check proprietary data-models.
The different services provided by I2RS can correspond to separate The different services provided by I2RS can correspond to separate
data-models. An I2RS agent may indicate which data-models are data-models. An I2RS agent may indicate which data-models are
supported. supported.
4. Security Considerations 4. Security Considerations
This I2RS architecture describes interfaces that clearly require This I2RS architecture describes interfaces that clearly require
serious consideration of security. First, here is a brief serious consideration of security. As an architecture, I2RS has been
description of the assumed security environment for I2RS. The I2RS designed to re-utilize existing protocols that carry network
Agent associated with a Routing Element is a trusted part of that management information. Two of existing protocol which the I2RS WG
Routing Element. For example, it may be part of a vendor-distributed has selected to attempt to re-use are NETCONF [RFC6241] and RESTCONF
signed software image for the entire Routing Element or it may be [I-D.ietf-netconf-restconf]. The I2RS protocol design process is to
trusted signed application that an operator has installed. The I2RS specify additional requirements which will include security for an
Agent is assumed to have a separate authentication and authorization existing protocol in order to support the I2RS architecture. After
channel by which it can validate both the identity and permissions an existing protocol, e.g. NETCONF or RESTCONF, has been alter to
associated with an I2RS Client. To support numerous and speedy fit the I2RS requirements, then this protocol will be reviewed to
interactions between the I2RS Agent and I2RS Client, it is assumed determine if it meets the I2RS security requirements.
that the I2RS Agent can also cache that particular I2RS Clients are
trusted and their associated authorized scope. This implies that the Due to the re-use strategy of the I2RS architecture, this security
permission information may be old either in a pull model until the section describes the assumed security environment for I2RS with
I2RS Agent re-requests it, or in a push model until the additional detail on: a) identity and authentication, b)
authentication and authorization channel can notify the I2RS Agent of authorization, and c) client redundancy. Each protocol proposed for
changes. inclusions as an I2RS protocol will need to be evaluated for the
security constraints of the protocol.
First, here is a brief description of the assumed security
environment for I2RS. The I2RS Agent associated with a Routing
Element is a trusted part of that Routing Element. For example, it
may be part of a vendor-distributed signed software image for the
entire Routing Element or it may be trusted signed application that
an operator has installed. The I2RS Agent is assumed to have a
separate authentication and authorization channel by which it can
validate both the identity and permissions associated with an I2RS
Client. To support numerous and speedy interactions between the I2RS
Agent and I2RS Client, it is assumed that the I2RS Agent can also
cache that particular I2RS Clients are trusted and their associated
authorized scope. This implies that the permission information may
be old either in a pull model until the I2RS Agent re-requests it, or
in a push model until the authentication and authorization channel
can notify the I2RS Agent of changes.
Mutual authentication between the I2RS Client and I2RS Agent is Mutual authentication between the I2RS Client and I2RS Agent is
required. An I2RS Client must be able to trust that the I2RS Agent required. An I2RS Client must be able to trust that the I2RS Agent
is attached to the relevant Routing Element so that write/modify is attached to the relevant Routing Element so that write/modify
operations are correctly applied and so that information received operations are correctly applied and so that information received
from the I2RS Agent can be trusted by the I2RS Client. from the I2RS Agent can be trusted by the I2RS Client.
An I2RS Client is not automatically trustworthy. It has identity An I2RS Client is not automatically trustworthy. It has identity
information and applications using that I2RS Client should be aware information and applications using that I2RS Client should be aware
of the scope limitations of that I2RS Client. If the I2RS Client is of the scope limitations of that I2RS Client. If the I2RS Client is
skipping to change at page 30, line 47 skipping to change at page 30, line 47
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 Yu. 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-06 (work in progress), January 2015.
[I-D.ietf-idr-ls-distribution] [I-D.ietf-idr-ls-distribution]
Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
Ray, "North-Bound Distribution of Link-State and TE Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", draft-ietf-idr-ls-distribution-07 Information using BGP", draft-ietf-idr-ls-distribution-10
(work in progress), November 2014. (work in progress), January 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-03 (work in Protocol", draft-ietf-netconf-restconf-04 (work in
progress), October 2014. progress), January 2015.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011. 6241, June 2011.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, March Protocol (NETCONF) Access Control Model", RFC 6536, March
2012. 2012.
Authors' Addresses Authors' Addresses
 End of changes. 13 change blocks. 
30 lines changed or deleted 47 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/