Use Cases for an Interface to IGP Protocol
draft-wu-i2rs-igp-usecases-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Nan Wu , Zhenbin Li , Susan Hares | ||
| Last updated | 2014-07-04 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wu-i2rs-igp-usecases-00
Network Working Group N. Wu
Internet-Draft Z. Li
Intended status: Informational S. Hares
Expires: January 5, 2015 Huawei Technologies
July 4, 2014
Use Cases for an Interface to IGP Protocol
draft-wu-i2rs-igp-usecases-00
Abstract
A link-state routing protocol such as OSPF or IS-IS is an essential
component for a routing system. With substantial effort on the IGP
protocols, the infrastructure of the network has achieved high
reliability. During past years they have been operated and
maintained through typical CLI, SNMP and NETCONF. As modern networks
become larger and more complex, the IGP protocol may require a
programmatic interface which is able to facilitate additional control
and observation in such networks.
Interface to the Routing System's (I2RS) is a standards-based
interface which provides a programmatic way to control and observe
the IGP protocol. I2RS can be used to operate, maintain and monitor
the routing-related state. This document describes set of use cases
for which I2RS can be used for IGP protocol. It is intended to
provide a base for the solution draft describing information models
and a set of interfaces to the IGP protocol.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
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
Wu, et al. Expires January 5, 2015 [Page 1]
Internet-Draft Use Cases for an Interface to IGP July 2014
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 January 5, 2015.
Copyright Notice
Copyright (c) 2014 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
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. IGP Network Planning . . . . . . . . . . . . . . . . . . . . 3
2.1. Router Identification Allocation . . . . . . . . . . . . 3
2.2. Domain Partition . . . . . . . . . . . . . . . . . . . . 4
2.3. Route Manipulation . . . . . . . . . . . . . . . . . . . 4
3. IGP Path Engineering . . . . . . . . . . . . . . . . . . . . 4
3.1. LFA Pre-computation and Adjustment . . . . . . . . . . . 5
3.2. Capacity Planning . . . . . . . . . . . . . . . . . . . . 6
3.3. Virtualized Network . . . . . . . . . . . . . . . . . . . 7
4. IGP Events . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Topology Change Monitoring . . . . . . . . . . . . . . . 8
4.2. Performance Monitoring . . . . . . . . . . . . . . . . . 9
4.3. Protocol Statistics Monitoring . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
A link-state routing protocol such as OSPF[RFC2328] or IS-
IS[ISO.10589.1992] is an essential component for a routing system.
With substantial effort of IGP protocol, the infrastructure of
network has achieved high levels of reliability. During past years
Wu, et al. Expires January 5, 2015 [Page 2]
Internet-Draft Use Cases for an Interface to IGP July 2014
they have been operated and maintained through typical CLI, SNMP and
NETCONF. As modern networks become larger and more complex, the IGP
protocol may require a programmatic interface which is capable of
facilitating additional control and observation in such networks.
Interface to the Routing System's (I2RS) [I-D.ietf-i2rs-architecture]
architecture specifies common, standards-based programmatic
interfaces which is an elegant way to control and observe the IGP
protocol. The I2RS interface can be used to operate, maintain and
monitor the routing-related state. The I2RS described here is aimed
to co-exist with current control and diagnose mechanism such as CLI,
SNMP and NETCONF instead of obseleting them. Actually the I2RS can
enhance these existing mechanism by defining a standardized set of
programmatic interfaces to enable flexible manipulation, inquiry and
analysis of the IGP protocol. The use cases described in this
document cover the following aspects of IGP: network planning, path
engineering and tracking of protocol events. The purpose here is to
gain the rough consensus from the community that the I2RS IGP
extensions fit within the overall I2RS architecture. It is intended
to provide a base for the solution draft describing information
models and a set of interfaces to the IGP protocol.
2. IGP Network Planning
With the growing size of modern network, more and more nodes and
links in network are deployed with IGP protocol. A network
containing 1000 IGP-enable nodes is not rare nowadays. As the
consequence of this network inflation, some drawbacks can be easily
introduced into the network. For example, link-state protocols
depend on flooding mechanism to advertise link-state related
information and keep the database updated. Too many nodes can
periodically produce large amounts of link-state information which
can burden the forwarding plane and jeopardize the reliability of IGP
adjacencies. The number of adjacencies, links and routes involved
into IGP network consumes forwarding and storage resources of the
routing elements in the network. The I2RS Clients may be connected
to by applications wishing to use the I2RS Client-Agent protocol to
deploy IGP protocol in an efficient, scalable and interoperable
manner.
2.1. Router Identification Allocation
IGP routers are identified by one identification (router-id or
system-id) which MUST be unique for each router in the AS. It is
increasingly common to observe that many subtle issues are introduced
because of this identification conflict. Since this identification
is inherited from interface IP address or configured manually, it is
Wu, et al. Expires January 5, 2015 [Page 3]
Internet-Draft Use Cases for an Interface to IGP July 2014
prone to conflict with another router located in remote network
segment.
The I2RS MAY help to alleviate this situation by introducing certain
application which is responsible for allocating identification.
Though the mechanism used to allocate unique identification is out of
the scope of this document.
2.2. Domain Partition
As stated above, huge network is harder to operate and maintain, what
is more, is susceptible to topology turbulence which can degrade the
quality of service provided by IGP protocol. Link-state
protocols(OSPF or IS-IS) introduce routing hierarchy to solve this
kind of problems. Some devices have limited CPU or storage resources
and cannot hold all link-state information. These devices may need
to be transferred to a limited IGP domain which holds part of the
link-state information.
The I2RS may guide this partition process after considering different
conditions including the number of routers, adjacency, links and
routes, CPU and storage resource of corresponding routers and also
their geography location.
2.3. Route Manipulation
Searching entries in the Routing Information Base(RIB) is a
fundamental operation in routing system. In order to speed up the
searching process and saving storage resources, the RIB may contain
only part of the routing table entries provided the network
reachability is not compromised. The reduction of the routing table
is achieved via route manipulation. The interface addresses of a
router can be suppressed for sake of less entries or secure entries.
The policy SHOULD be deployed carefully to summarize and filter those
routing information crossing the domain border through the way of
generation or redistribution.
The I2RS SHOULD facilitate reduction by allowing offline calculation
to determine how to partition IGPs and where to place ABR and ASBRs.
The I2RS cycle of the query of IGP information (see above) followed
by downloading of a new temporary topologies.
3. IGP Path Engineering
Link-state protocol like IGP depend on Shortest Path First(SPF)
algorithm to calculate its path to destinations. These SPF paths can
dynamically adapt to the topology change from time to time without
external involvement. Though this traditional mechanism works just
Wu, et al. Expires January 5, 2015 [Page 4]
Internet-Draft Use Cases for an Interface to IGP July 2014
fine, there are scenarios in which external engagement needs to be
involved into the decision process to fulfill special purpose.
3.1. LFA Pre-computation and Adjustment
Loop-Free Alternates(LFA)[RFC5286] is deployed in pure IP and MPLS/
LDP networks to provide single-point-failure protection for unicast
traffic. The goal of this technology is to reduce the packet loss
that happens while routers converge after a topology change due to a
failure. [I-D.ietf-rtgwg-lfa-manageability] provides operational
feedback on LFA, highlights some limitations, and proposes a set of
refinements to address those limitations. It also proposes required
management specifications. In most of circumstances, operators will
not be satisfied to know only the protection for links and prefixes.
What they really hope is the overall protection for the whole
network, especially for those high-value-added business. If lack of
protection or protection coverage is not good enough, the operator
may hope there are some ways to identify those weak points and the
method to fix them up.
The I2RS MAY help to achieve the operator's hope by resorting to
certain allowing applications to pre-computes the LFA backup of all
links and prefixes in the network and calculating the protection
coverage and recognizing optimization. Then an I2RS Client can
deploy these new topology adjustments by sending the appropriate
changes to the I2RS Agent that it will install in the routing place.
The I2RS Agent can notify the I2RS Client (and the application) of
the results of operation to provide a real-time feedback.
As showed below, traffic from Node-S to Node-D needs to pass Node-E.
Under the circumstance of Link-SE's failure, the traffic can not be
protected by Node-N since the metrics do not meet the demand of
Inequality 1 from [RFC5286]. With the help from I2RS, the operator
can identify this weakness and may change the metric of Link-ND to
gain LFA backup.
Wu, et al. Expires January 5, 2015 [Page 5]
Internet-Draft Use Cases for an Interface to IGP July 2014
+----+ \
---| | E | \\
/ | ---+----+-- \|
// ---- ---- --|
/ ---- ----
---- 10 10 ----
+----+-- --+----+
| S | | D |
+----+-- --+----+
---- 50 ----
----10 ----
---- ----
---+----+--
| N |
+----+
Figure 1: LFA pre-computation and no backup available
3.2. Capacity Planning
It is increasingly common to see Equal-Cost-Multipath(ECMP) is used
the networks of SP, Enterprise and Data Center to make efficient use
the network bandwidth. The traffic is spread across as many ECMP
paths as possible allowing growth (or shrinkage) without a physical
capacity adjustment
The I2RS programmatic interface SHOULD allow the balancing of both
ECMP traffic flows and end-to-end traffic flows in the IGP. The I2RS
SHOULD support monitoring of the dynamic traffic flow in the network,
and the query of the maximum capacity of the network. After some
offline optimization occurs, the I2RS can be used to spread ECMP
paths through the topology or aggregate traffic onto a single path so
the rest of the devices may power off saving power (and money. One
important thing to note here, topology changes triggered by capacity
adjustment MAY cause transient forwarding loops of which MUST be
taken care. And the specific solution for this issue is out of the
scope of this document.
As pictured below, traffic from Node-A to Node-B is widely spread
among all links and nodes between them. This can increase the whole
capacity of this network. When the traffic decreased, the operator
can use I2RS to adjust the metric of Link-AB to less than the current
one then the traffic will be summarized on the Link-AB. As a result
of this change, Node-C, Node-D and their links can be power off or
used for other purpose.
Wu, et al. Expires January 5, 2015 [Page 6]
Internet-Draft Use Cases for an Interface to IGP July 2014
+----+
| D |
---+----+--
10 ---- ---- 10
---- ----
---- ----
+----+-- 20 --+----+
| A +---------------------------------------+ B |
+----+-- --+----+
---- ----
---- ----
---- ----
10 ---+----+-- 10
| C |
+----+
Figure 2: Capacity planning through topology adjustment
3.3. Virtualized Network
As the central controlled network introduced, there will propose the
partial deployment scenarios. That is, part of the existing network
will be converted to be controlled in the central control mode. The
application scenario is shown in the following figure:
+------------------------------+
| Central Control Domain |
| +----------+ |
| | | |
| | IGP | |
| |Controller| |
| | | |
| +----------+ |
| / \ |
| / \ |
| / \ |
+-----------+ | +--------+ +--------+ | +-----------+
|Traditional| | | NODE 1 | | NODE n | | |Traditional|
| | | | | ...... | | | | |
| NODE |----| IGP | | IGP |----| NODE |
| | | | CLIENT | | CLIENT | | | |
+-----------+ | +--------+ +--------+ | +-----------+
| |
+------------------------------+
Figure 3: Partial Deployment of Central Controlled Network
Wu, et al. Expires January 5, 2015 [Page 7]
Internet-Draft Use Cases for an Interface to IGP July 2014
In this scenario, it is not necessary for the traditional nodes to
learn the detailed topology information of the central control
domain. The information flooded between the central control domain
and the traditional nodes can be reduced. The central control domain
can only advertise virtual links which connect the edge nodes in the
domain that the traditional node can be aware of. The process can
change the route choice of the traditional nodes, reduce the pressure
of the traditional nodes for flooding and improve convergence
performance.
The I2RS programmatic interface MAY help implementation of the
virtualized network based on the possible policy. That is, the
controller can apply the policy defined by the applications to
determine whether the virtual link will be advertised to the outside
network nodes and what metric is advertised for the virtual link.
The I2RS Client can notify the I2RS Agent the determined result for
the virtualized link to be flooded.
4. IGP Events
As stated in [I-D.ietf-i2rs-architecture], it is practical for I2RS
Clients to register for a range of notifications, and for the I2RS
Agents to send notifications to a number of Clients. The I2RS
Clients SHOULD use publish/subscribe mechanism to filter those events
it is interested in. As regard for IGP protocol, these events MAY
include topology changes, performance status and protocol statistics
which are critical to operate and maintain IGP network with
efficiency and scalability.
4.1. Topology Change Monitoring
Network topology information is the basis for further operating and
maintaining. It is very important and can be used in many scenarios.
Link-state protocol such as IGP is the recommended way to collect
topology information.
Since many factors such as the status of interface, adjacency, node
and etc can trigger the change of topology, the topology notification
is reported to I2RS Clients at times. Considering lots of nodes and
links in the network, these topology events can be massive. The I2RS
SHOULD use the subscription mechanism to filter its interested events
and use the publish mechanism to control the pace these events are
notified. This precaution can protect the I2RS Client or even
applications who depend on topology data from being drowned by
massive duplicate events.
Wu, et al. Expires January 5, 2015 [Page 8]
Internet-Draft Use Cases for an Interface to IGP July 2014
4.2. Performance Monitoring
Since IGP protocol is essential to the whole network, the I2RS
Clients SHOULD monitor about the protocol's running status before
forwarding is impacted. Performance data can be collected through
collecting static configuration and observing dynamic status. Static
data includes the number of instances, interfaces, nodes in the
network and etc. Dynamic data includes adjacency status, the number
of entries in link-state database and in the routing table, the
calculation status, the overload status, the graceful switch status
and etc.
The I2RS Clients SHOULD subscribe to the I2RS Agent's notification of
critical node events. For example, link-state database or routing
table is under the status of overflow or the overflow status is
released, the calculation continues for a long time, the system is
under graceful reboot and etc.
4.3. Protocol Statistics Monitoring
IGP protocol contains many useful statistics which can help to do
trouble-shooting and maintain it. These statistics can be used by
I2RS Clients to support diagnosing or analyzing tasks. For example,
through subscribing packet dropped statistics, the I2RS Clients can
figure it out the reason why some adjacencies do not succeed in
connecting. Through subscribing the error statistics, the I2RS
Clients can find out some link-state updating because of
authentication or checksum failure, which can further help to
diagnose a configuration mistake or a subtle security attack
happened.
5. IANA Considerations
This document includes no request to IANA.
6. Security Considerations
This document does not introduce any further security issues other
than those discussed in [I-D.ietf-i2rs-architecture].
7. References
7.1. Normative References
Wu, et al. Expires January 5, 2015 [Page 9]
Internet-Draft Use Cases for an Interface to IGP July 2014
[I-D.ietf-i2rs-architecture]
Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing
System", draft-ietf-i2rs-architecture-04 (work in
progress), June 2014.
[ISO.10589.1992]
International Organization for Standardization,
"Intermediate system to intermediate system intra-domain-
routing routine information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473)", ISO
Standard 10589, 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
7.2. Informative References
[I-D.ietf-rtgwg-lfa-manageability]
Litkowski, S., Decraene, B., Filsfils, C., Raza, K.,
Horneffer, M., and p. psarkar@juniper.net, "Operational
management of Loop Free Alternates", draft-ietf-rtgwg-lfa-
manageability-03 (work in progress), February 2014.
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
Reroute: Loop-Free Alternates", RFC 5286, September 2008.
Authors' Addresses
Nan Wu
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: eric.wu@huawei.com
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Wu, et al. Expires January 5, 2015 [Page 10]
Internet-Draft Use Cases for an Interface to IGP July 2014
Susan Hares
Huawei Technologies
7453 Hickory Hill
Saline, CA 48176
USA
Email: shares@ndzh.com
Wu, et al. Expires January 5, 2015 [Page 11]