draft-ietf-i2rs-problem-statement-09.txt   draft-ietf-i2rs-problem-statement-10.txt 
Network Working Group A. Atlas, Ed. Network Working Group A. Atlas, Ed.
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Informational T. Nadeau, Ed. Intended status: Informational T. Nadeau, Ed.
Expires: July 18, 2016 Brocade Expires: August 15, 2016 Brocade
D. Ward D. Ward
Cisco Systems Cisco Systems
January 15, 2016 February 12, 2016
Interface to the Routing System Problem Statement Interface to the Routing System Problem Statement
draft-ietf-i2rs-problem-statement-09 draft-ietf-i2rs-problem-statement-10
Abstract Abstract
Traditionally, routing systems have implemented routing and signaling Traditionally, routing systems have implemented routing and signaling
(e.g. MPLS) to control traffic forwarding in a network. Route (e.g. MPLS) to control traffic forwarding in a network. Route
computation has been controlled by relatively static policies that computation has been controlled by relatively static policies that
define link cost, route cost, or import and export routing policies. define link cost, route cost, or import and export routing policies.
With the advent of highly dynamic data center networking, on-demand With the advent of highly dynamic data center networking, on-demand
WAN services, dynamic policy-driven traffic steering and service WAN services, dynamic policy-driven traffic steering and service
chaining, the need for real-time security threat responsiveness via chaining, the need for real-time security threat responsiveness via
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 18, 2016. This Internet-Draft will expire on August 15, 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 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. I2RS Model and Problem Area for the IETF . . . . . . . . . . 3 2. I2RS Model and Problem Area for the IETF . . . . . . . . . . 3
3. Standard Data-Models of Routing State for Installation . . . 6 3. Standard Data-Models of Routing State for Installation . . . 6
4. Learning Router Information . . . . . . . . . . . . . . . . . 6 4. Learning Router Information . . . . . . . . . . . . . . . . . 6
5. Aspects to be Considered for an I2RS Protocol . . . . . . . . 7 5. Aspects to be Considered for an I2RS Protocol . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Informative References . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Existing Management Interfaces . . . . . . . . . . . 10 Appendix A. Existing Management Interfaces . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Traditionally, routing systems have implemented routing and signaling Traditionally, routing systems have implemented routing and signaling
(e.g. MPLS) to control traffic forwarding in a network. Route (e.g. MPLS) to control traffic forwarding in a network. Route
computation has been controlled by relatively static policies that computation has been controlled by relatively static policies that
define link cost, route cost, or import and export routing policies. define link cost, route cost, or import and export routing policies.
With the advent of highly dynamic data center networking, on-demand With the advent of highly dynamic data center networking, on-demand
skipping to change at page 4, line 24 skipping to change at page 4, line 28
routing element, which may or may not be co-located with a data- routing element, which may or may not be co-located with a data-
plane. The I2RS Client could be integrated in a network application plane. The I2RS Client could be integrated in a network application
or controlled and used by one or more separate network applications. or controlled and used by one or more separate network applications.
For instance, an I2RS Client could be provided by a network For instance, an I2RS Client could be provided by a network
controller or a network orchestration system that provides a non-I2RS controller or a network orchestration system that provides a non-I2RS
interface to network applications and an I2RS interface to I2RS interface to network applications and an I2RS interface to I2RS
Agents on the systems being managed. The scope of the data-models Agents on the systems being managed. The scope of the data-models
used by I2RS extends across the entire routing system and the used by I2RS extends across the entire routing system and the
selected protocol(s) for I2RS. selected protocol(s) for I2RS.
As depicted in Figure 1, the I2RS Client and I2RS agent in a routing As depicted in Figure 1, the I2RS Client and I2RS Agent in a routing
system are objects with in the I2RS scope. The selected protocol(s) system are objects with in the I2RS scope. The selected protocol(s)
for I2RS extend between the I2RS client and I2RS Agent. All other for I2RS extend between the I2RS client and I2RS Agent. All other
objects and interfaces in Figure 1 are outside the I2RS scope for objects and interfaces in Figure 1 are outside the I2RS scope for
standardization. standardization.
+***************+ +***************+ +***************+ +***************+ +***************+ +***************+
* Application * * Application * * Application * * Application * * Application * * Application *
+***************+ +***************+ +***************+ +***************+ +***************+ +***************+
| I2RS Client | ^ ^ | I2RS Client | ^ ^
+---------------+ * * +---------------+ * *
skipping to change at page 5, line 41 skipping to change at page 5, line 44
would be used would be used
.... boundary of a router supporting I2RS .... boundary of a router supporting I2RS
Figure 1: I2RS model and Problem Area Figure 1: I2RS model and Problem Area
The I2RS Working Group must select the suitable protocol(s) to carry The I2RS Working Group must select the suitable protocol(s) to carry
messages between the I2RS Clients and I2RS Agent. The protocol messages between the I2RS Clients and I2RS Agent. The protocol
should provide the key features specified in Section 5. should provide the key features specified in Section 5.
The I2RS Working Group must identify or define is a set of meaningful The I2RS Working Group must identify or define a set of meaningful
data-models for information in the routing system and in a topology data-models for information in the routing system and in a topology
database. The data-model should describe the meaning and database. The data-model should describe the meaning and
relationships of the modeled items. The data-models should be relationships of the modeled items. The data-models should be
separable across different features of the managed components, separable across different features of the managed components,
versioned, and extendable. As shown in Figure 1, I2RS needs to versioned, and extendable. As shown in Figure 1, I2RS needs to
interact with several logical components of the routing element: interact with several logical components of the routing element:
policy database, topology database, subscription and configuration policy database, topology database, subscription and configuration
for dynamic measurements/events, routing signaling protocols, and its for dynamic measurements/events, routing signaling protocols, and its
RIB manager. This interaction is both for writing (e.g. to policy RIB manager. This interaction is both for writing (e.g. to policy
databases or RIB manager) as well as for reading (e.g. dynamic databases or RIB manager) as well as for reading (e.g. dynamic
measurement or topology database). An application should be able to measurement or topology database). An application should be able to
combine data from individual routing elements to provide network-wide combine data from individual routing elements to provide network-wide
data-model(s). data-model(s).
The data models should translate into a concise transfer syntax, sent The data models should translate into a concise transfer syntax, sent
via the I2RS protocol, that is straightforward for applications to via the I2RS protocol, that is straightforward for applications to
skipping to change at page 6, line 40 skipping to change at page 6, line 44
standardizing data models that describe the forwarding plane (e.g. standardizing data models that describe the forwarding plane (e.g.
ForCES [RFC3746]). I2RS recognizes that the routing system and a ForCES [RFC3746]). I2RS recognizes that the routing system and a
router's OS provide useful mechanisms that applications could router's OS provide useful mechanisms that applications could
usefully harness to accomplish application-level goals. Using usefully harness to accomplish application-level goals. Using
routing indirection, recursion and common routing abstractions (e.g. routing indirection, recursion and common routing abstractions (e.g.
tunnels, LSPs, etc.) provides significant flexibility and tunnels, LSPs, etc.) provides significant flexibility and
functionality over collapsing the state to individual routes in the functionality over collapsing the state to individual routes in the
FIB that need to be individually modified when a change occurs. FIB that need to be individually modified when a change occurs.
In addition to interfaces to control the RIB layer, there is a need In addition to interfaces to control the RIB layer, there is a need
to dynamically configure policies and values for parameters for the to dynamically configure policies and parameter values for the
various routing and signaling protocols based upon application-level various routing and signaling protocols based upon application-level
policy decisions. policy decisions.
4. Learning Router Information 4. Learning Router Information
A router has information that applications may require so that they A router has information that applications may require so that they
can understand the network, verify that programmed state is can understand the network, verify that programmed state is
installed, measure the behavior of various flows, and understand the installed, measure the behavior of various flows, and understand the
existing configuration and state of the router. I2RS should provide existing configuration and state of the router. I2RS should provide
a framework so that applications can register for asynchronous a framework so that applications can register for asynchronous
notifications and can make specific requests for information. notifications and can make specific requests for information.
Although there are efforts to extend the topological information Although there are efforts to extend the topological information
available, even the best of these (e.g., BGP-LS available, even the best of these (e.g., BGP-LS
[I-D.ietf-idr-ls-distribution]) still provide only the current active [I-D.ietf-idr-ls-distribution]) still only provide the current active
state as seen at the IGP and BGP layers. Detailed topological state state as seen at the IGP and BGP layers. Detailed topological state
that provides more information than the current functional status that provides more information than the current functional status
(e.g. active paths and links) is needed by applications. Examples of (e.g. active paths and links) is needed by applications. Examples of
missing information include paths or link that are potentially missing information include paths or link that are potentially
available (e.g. administratively down) or unknown (e.g. to peers or available (e.g. administratively down) or unknown (e.g. to peers or
customers) to the routing topology. customers) to the routing topology.
For applications to have a feedback loop that includes awareness of For applications to have a feedback loop that includes awareness of
the relevant traffic, an application must be able to request the the relevant traffic, an application must be able to request the
measurement and timely, scalable reporting of data. While a measurement and timely, scalable reporting of data. While a
skipping to change at page 8, line 6 skipping to change at page 8, line 8
sending the next. sending the next.
Very Fine Granularity of Data Locking for Writing: When an I2RS Very Fine Granularity of Data Locking for Writing: When an I2RS
operation is processed, it is required that the data locked for operation is processed, it is required that the data locked for
writing is very granular (e.g. a particular prefix and route) writing is very granular (e.g. a particular prefix and route)
rather than extremely coarse, as is done for writing rather than extremely coarse, as is done for writing
configuration. This should improve the number of concurrent I2RS configuration. This should improve the number of concurrent I2RS
operations that are feasible and reduce blocking delays. operations that are feasible and reduce blocking delays.
Multi-Headed Control: Multiple applications may communicate to the Multi-Headed Control: Multiple applications may communicate to the
same I2RS agent in a minimally coordinated fashion. It is same I2RS Agent in a minimally coordinated fashion. It is
necessary that the I2RS agent can handle multiple requests in a necessary that the I2RS Agent can handle multiple requests in a
well-known policy-based fashion. Data written can be owned by well-known policy-based fashion. Data written can be owned by
different I2RS clients at different times; data may even be different I2RS Clients at different times; data may even be
overwritten by a different I2RS client. The details of how this overwritten by a different I2RS Client. The details of how this
should be handled are described in [I-D.ietf-i2rs-architecture]. should be handled are described in [I-D.ietf-i2rs-architecture].
Duplex: Communications can be established by either the I2RS client Duplex: Communications can be established by either the I2RS Client
(i.e., that resides within the application or is used by it to (i.e., that resides within the application or is used by it to
communicate with the I2RS agent), or the I2RS agent. Similarly, communicate with the I2RS Agent), or the I2RS Agent. Similarly,
events, acknowledgements, failures, operations, etc. can be sent events, acknowledgements, failures, operations, etc. can be sent
at any time by both the router and the application. The I2RS is at any time by both the router and the application. The I2RS is
not a pure pull-model where only the application queries to pull not a pure pull-model where only the application queries to pull
responses. responses.
High-Throughput: At a minimum, within the I2RS scope, the I2RS High-Throughput: At a minimum, within the I2RS scope, the I2RS
Agent and associated router should be able to handle a Agent and associated router should be able to handle a
considerable number of operations per second (for example 10,000 considerable number of operations per second (for example 10,000
per second to handle many individual subscriber routes changing per second to handle many individual subscriber routes changing
simultaneously). simultaneously).
Low-Latency: Within a sub-second time-scale, it should be possible Low-Latency: Within a sub-second time-scale, it should be possible
to complete simple operations (e.g. reading or writing a single to complete simple operations (e.g. reading or writing a single
prefix route). prefix route).
Multi-Channel: It should be possible for information to be Multi-Channel: It should be possible for information to be
communicated via the interface from different components in the communicated via the interface from different components in the
router without requiring going through a single channel. For router without requiring going through a single channel. For
example, for scaling, some exported data or events may be better example, for scaling, some exported data or events may be better
sent directly from the forwarding plane, while other interactions sent directly from the forwarding plane, while other interactions
may come from the control-plane. may come from the control-plane. One channel, with authorization
and authentication, may be considered primary; only an authorized
client can then request that information be delivered on a
different channel. Writes from a client are only expected on
channels that provide authorization and authentication.
Scalable, Filterable Information Access: To extract information in a Scalable, Filterable Information Access: To extract information in a
scalable fashion that is more easily used by applications, the scalable fashion that is more easily used by applications, the
ability to specify filtering constructs in an operation requesting ability to specify filtering constructs in an operation requesting
data or requesting an asynchronous notification is very valuable. data or requesting an asynchronous notification is very valuable.
Secure Control and Access: Any ability to manipulate routing state Secure Control and Access: Any ability to manipulate routing state
must be subject to authentication and authorization. Sensitive must be subject to authentication and authorization. Sensitive
routing information may also need to be provided via secure access routing information may also need to be provided via secure access
back to the I2RS client. Such communications must be integrity back to the I2RS Client. Such communications must be integrity
protected. Some communications will also require confidentiality. protected. Some communications will also require confidentiality.
Extensible and Interoperability: Both the I2RS protocol and models Extensible and Interoperability: Both the I2RS protocol and models
must be extensible and interoperate between different versions of must be extensible and interoperate between different versions of
protocols and models. protocols and models.
6. Acknowledgements 6. Acknowledgements
The authors would like to thank Ken Gray, Ed Crabbe, Nic Leymann, The authors would like to thank Ken Gray, Ed Crabbe, Nic Leymann,
Carlos Pignataro, Kwang-koog Lee, Linda Dunbar, Sue Hares, Russ Carlos Pignataro, Kwang-koog Lee, Linda Dunbar, Sue Hares, Russ
skipping to change at page 9, line 29 skipping to change at page 9, line 35
installation and extracting of detailed router state. The need for installation and extracting of detailed router state. The need for
secure control and access is mentioned in Section 5. More secure control and access is mentioned in Section 5. More
architectural security considerations are discussed in architectural security considerations are discussed in
[I-D.ietf-i2rs-architecture]. Briefly, the I2RS Agent is assumed to [I-D.ietf-i2rs-architecture]. Briefly, the I2RS Agent is assumed to
have a separate authentication and authorization channel by which it have a separate authentication and authorization channel by which it
can validate both the identity and the permissions associated with an can validate both the identity and the permissions associated with an
I2RS Client. Mutual authentication between the I2RS Agent and I2RS I2RS Client. Mutual authentication between the I2RS Agent and I2RS
Client is required. Different levels of integrity, confidentiality, Client is required. Different levels of integrity, confidentiality,
and replay protection are relevant for different aspects of I2RS. and replay protection are relevant for different aspects of I2RS.
9. Informative References 9. References
9.1. Normative References
[I-D.ietf-i2rs-architecture] [I-D.ietf-i2rs-architecture]
Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing Nadeau, "An Architecture for the Interface to the Routing
System", draft-ietf-i2rs-architecture-12 (work in System", draft-ietf-i2rs-architecture-12 (work in
progress), December 2015. progress), December 2015.
9.2. Informative References
[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.
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
"Forwarding and Control Element Separation (ForCES) "Forwarding and Control Element Separation (ForCES)
Framework", RFC 3746, DOI 10.17487/RFC3746, April 2004, Framework", RFC 3746, DOI 10.17487/RFC3746, April 2004,
<http://www.rfc-editor.org/info/rfc3746>. <http://www.rfc-editor.org/info/rfc3746>.
 End of changes. 18 change blocks. 
18 lines changed or deleted 29 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/