Internet DRAFT - draft-wu-i2rs-igp-usecases
draft-wu-i2rs-igp-usecases
Network Working Group N. Wu
Internet-Draft Z. Li
Intended status: Informational Huawei
Expires: April 27, 2015 S. Hares
Hickory Hill Consulting
October 24, 2014
Use Cases for an Interface to IGP Protocol
draft-wu-i2rs-igp-usecases-01
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 April 23, 2015 [Page 1]
Internet-Draft Use Cases for an Interface to IGP October 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 April 23, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IGP Network Planning . . . . . . . . . . . . . . . . . . . . 3
2.1. Identification Allocation . . . . . . . . . . . . . . . . 4
2.2. Domain Partition . . . . . . . . . . . . . . . . . . . . 4
2.3. Route Manipulation . . . . . . . . . . . . . . . . . . . 4
3. IGP Path Engineering . . . . . . . . . . . . . . . . . . . . 5
3.1. LFA Precomputation and Adjustment . . . . . . . . . . . . 5
3.2. Transient loop avoidance . . . . . . . . . . . . . . . . 6
3.3. Capacity Planning . . . . . . . . . . . . . . . . . . . . 6
3.4. Traffic blackhole prevention . . . . . . . . . . . . . . 7
4. IGP Events . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Topology Change Monitoring . . . . . . . . . . . . . . . 8
4.1.1. Router-ID conflict recovery . . . . . . . . . . . . . 8
4.2. Performance Monitoring . . . . . . . . . . . . . . . . . 9
4.2.1. Router number monitoring . . . . . . . . . . . . . . 9
4.3. Protocol Statistics Monitoring . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
Wu, et al. Expires April 23, 2015 [Page 2]
Internet-Draft Use Cases for an Interface to IGP October 2014
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
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 decribed here is aimed
to co-exist with current control and diagnose mechanism such as CLI,
SNMP and NETCONF instead of obseleting them. Acutally 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.
Wu, et al. Expires April 23, 2015 [Page 3]
Internet-Draft Use Cases for an Interface to IGP October 2014
2.1. 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
prone to conflict with another router located in remote network
segment.
In the routing domain of "Bit Index Explicit Replication"
(BIER)[I-D.wijnands-bier-architecture], it is essential for each Bit-
Forwarding-Router(BFR) to have an unique BFR-id that MUST be in one
specific numeric range. It is very likely that confliction can be
observed quite often when those IDs are allocated in a distributed
manner.
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 degrage 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 resouce 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
Wu, et al. Expires April 23, 2015 [Page 4]
Internet-Draft Use Cases for an Interface to IGP October 2014
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
fine, there are scenarioes in which external engagement needs to be
involved into the decision process to fulfill special purpose.
3.1. LFA Precomputation 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
Wu, et al. Expires April 23, 2015 [Page 5]
Internet-Draft Use Cases for an Interface to IGP October 2014
can identify this weakness and may change the metric of Link-ND to
gain LFA backup.
+----+ \
---| | E | \\
/ | ---+----+-- \|
// ---- ---- --|
/ ---- ----
---- 10 10 ----
+----+-- --+----+
| S | | D |
+----+-- --+----+
---- 50 ----
----10 ----
---- ----
---+----+--
| N |
+----+
Figure 1: LFA precomputation and no backup available
3.2. Transient loop avoidance
Link-state protocols may need to reconverge when the network topology
changes. During this phase packet loss and transient loops are
frequently observed since inconsistent RIBs exist, even the
reachability of the destinations is not compromised after the
topology change. Drafts have been proposed to delay the
reconvergence and update RIBs in a ordered manner among distributed
routers. These methods may help to alleviate packet loss caused by
transient loops while they are unable to help the packet loss during
the delay.
Since the transient loops are introduced by inconsistent RIBs, the
I2RS may help to avoid those loops by direct access to next hop
information of route entries through pragmatic interfaces. By
changing the next hops to be what they should be after reconvergence,
transient loops can be avoided and no disturbance introduced when
reconvergence happens.
3.3. Capacity Planning
It is increasingly common to see Equal-Cost-Multipath(ECMP) is used
the networks of SP, Enterprise and DataCenter 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
Wu, et al. Expires April 23, 2015 [Page 6]
Internet-Draft Use Cases for an Interface to IGP October 2014
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.
+----+
| D |
---+----+--
10 ---- ---- 10
---- ----
---- ----
+----+-- 20 --+----+
| A +---------------------------------------+ B |
+----+-- --+----+
---- ----
---- ----
---- ----
10 ---+----+-- 10
| C |
+----+
Figure 2: Capacity planning through topology adjustment
3.4. Traffic blackhole prevention
IGP hello packet is used to discover and maintain adjacencies among
different devices. Without the deployment of fast detection
techniques, one device has to wait for dozens of seconds before it
realized the adjacency had broken. This kind of issue can cause one
device is cut off from its network and lose connectivity completely.
No matter planned or accidentally it may cause traffic blackhole
before damage can be controlled.
Wu, et al. Expires April 23, 2015 [Page 7]
Internet-Draft Use Cases for an Interface to IGP October 2014
Under the scenario of I2RS deployed, it is RECOMMENDED that the
adjacency data of the other end side can be removed simultaneously or
LSP can be updated directly by I2RS Agent when IGP is disabled or
detached on one side. As a result traffic blackhole caused by silent
broken adjacencies can be prevented.
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 futher operating and
maintaining. It is very important and can be used in many
scenarioes. 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.
4.1.1. Router-ID conflict recovery
It is not rare to observe router-ID conflict in networks both intra
and inter area, especially when different area merged. It is time-
consuming and troublesome to detect and locate the place where this
trouble happened. The frequently used solution is to rename one of
the conflicted router-ID to a new one then reboot the involved IGP
instance to force all adjacencies to rebuild and re-synchronize the
Link-State-Database.
It MAY be possible to alleviate this issue with the help of
programmatic I2RS interfaces. With the help of router information
statistics, this conflict can be detected automatically. When one
substantial conflict is on the horizon, no need to wait for mutual
Wu, et al. Expires April 23, 2015 [Page 8]
Internet-Draft Use Cases for an Interface to IGP October 2014
re-origination happened, ID conflict can be found in collection of
router information , no matter the conflict routers come from the
same area or not. What is more, through I2RS interfaces and Agent,
it is possible to rewrite one of the conflicted router-ID into a new
one then reboot the routing- protocol instance.
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.
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.2.1. Router number monitoring
Complaint can be heard frequently from clients about how many routers
should be deployed in one area. The answer for this question is not
very clear in vendor's guide since the product specification is only
for reference and what's worse, those words like "usually", "roughly"
or "most of the time" are often used from field engineers. As the
consequence, it is always convenient for clients to deploy all the
routers in one area, which may introduce scaling issue in future.
With the help of I2RS, it is possible to give out deployment
suggestion or warning dynamically in the real-time manner. Based on
the statistics of router number and system resource consuming, plus
the ratio relationship between them, one notification or warning can
be sent to I2RS Client. From there decision can be made to expand
safely or have to shrink for precaution.
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
Wu, et al. Expires April 23, 2015 [Page 9]
Internet-Draft Use Cases for an Interface to IGP October 2014
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
[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-05 (work in
progress), July 2014.
[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-04 (work in progress), August 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.
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
Reroute: Loop-Free Alternates", RFC 5286, September 2008.
Wu, et al. Expires April 23, 2015 [Page 10]
Internet-Draft Use Cases for an Interface to IGP October 2014
7.2. Informative References
[I-D.filsfils-spring-segment-routing-use-cases]
Filsfils, C., Francois, P., Previdi, S., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E.
Crabbe, "Segment Routing Use Cases", draft-filsfils-
spring-segment-routing-use-cases-01 (work in progress),
October 2014.
[I-D.ietf-isis-oper-enhance]
Shen, N., Li, T., Amante, S., and M. Abrahamsson, "IS-IS
Operational Enhancements for Network Maintenance Events",
draft-ietf-isis-oper-enhance-03 (work in progress),
February 2013.
[I-D.li-ospf-ext-green-te]
Yan, G., Yang, J., and Z. Li, "OSPF Extensions for MPLS
Green Traffic Engineering", draft-li-ospf-ext-green-te-01
(work in progress), October 2013.
[I-D.wijnands-bier-architecture]
Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
S. Aldrin, "Multicast using Bit Index Explicit
Replication", draft-wijnands-bier-architecture-01 (work in
progress), October 2014.
Authors' Addresses
Nan Wu
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: eric.wu@huawei.com
Zhenbin Li
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Wu, et al. Expires April 23, 2015 [Page 11]
Internet-Draft Use Cases for an Interface to IGP October 2014
Susan Hares
Hickory Hill Consulting
7453 Hickory Hill
Saline, CA 48176
USA
Email: shares@ndzh.com
Wu, et al. Expires April 23, 2015 [Page 12]
