Internet DRAFT - draft-ietf-isis-oper-enhance
draft-ietf-isis-oper-enhance
IS-IS Working Group N. Shen
Internet-Draft T. Li
Intended status: Informational Cisco Systems, Inc.
Expires: August 18, 2013 S. Amante
Level 3 Communications
M. Abrahamsson
Tele2
February 14, 2013
IS-IS Operational Enhancements for Network Maintenance Events
draft-ietf-isis-oper-enhance-03
Abstract
This document describes an improved IS-IS neighbor management scheme
which can be used to enhance operational experience in terms of
convergence speed and finer control of neighbor cost over a LAN.
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 August 18, 2013.
Copyright Notice
Copyright (c) 2013 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
Shen, et al. Expires August 18, 2013 [Page 1]
Internet-Draft IS-IS Operational Enhancements February 2013
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Interface Shutdown Black Hole . . . . . . . . . . . . . . 2
1.2. LAN of Last Resort . . . . . . . . . . . . . . . . . . . 2
1.3. Specification of Requirements . . . . . . . . . . . . . . 3
2. Sending Hellos with Fast Exit Notification . . . . . . . . . 3
3. Pseudonodes with Non-zero Metrics . . . . . . . . . . . . . . 3
3.1. Alternative Approaches . . . . . . . . . . . . . . . . . 4
4. Operational Considerations . . . . . . . . . . . . . . . . . 4
4.1. Operational Considerations: Fast Exit Notification . . . 4
4.2. Operational Considerations: Pseudonodes with Non-zero
Metrics . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
The IS-IS [ISO10589] routing protocol has been widely used in
Internet Service Provider IP/MPLS networks. Operational experience
with the protocol, combined with ever increasing requirements for
lossless operations have demonstrated some operational issues. This
document describes those issues and some mechanisms for dealing with
those issues. These mechanisms do involve implementation support,
but do not require protocol changes.
1.1. Interface Shutdown Black Hole
One of these operationally problematic issues occurs when IS-IS is
disabled on only one side of a link. This can result in a
significant delay before neighbor(s) on the other end of the same
link notice this change. In turn, this can result in several seconds
during which traffic is blackholed, until the IS-IS neighbor(s) time
out the adjacency and IS-IS reconverges.
1.2. LAN of Last Resort
Another issue stems from a situation when operators want to
temporarily make an interface a "last resort" link for transit
traffic. This is a straightforward, though cumbersome, operation to
perform on a point-to-point link. Each device on the link is
reconfigured to use very high metric. This causes traffic to divert
to other links in the network. This same operation is more difficult
Shen, et al. Expires August 18, 2013 [Page 2]
Internet-Draft IS-IS Operational Enhancements February 2013
on a multi-access LAN. There, the operator would have to increase
the metric on each and every interface attached to the LAN, requiring
the reconfiguration of a number of systems.
1.3. Specification of Requirements
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 [RFC2119].
2. Sending Hellos with Fast Exit Notification
When an operator shuts down IS-IS on an interface, as described in
Section 1.1, there is a significant interval before the change is
noticed by all adjacencies and traffic is subsequently re-routed
around this link. This delay is unnecessary, as neighbors should not
have to wait for the adjacency to timeout, particularly when there
exist alternate, viable, paths to downstream neighbors. This delay
can be eliminated by carefully removing the adjacency between
neighbors prior to actually disabling IS-IS on the interface.
An IS-IS adjacency uses the 3-way handshake protocol as defined in
[ISO10589] for multi-access LANs and [RFC3373] for point-to-point
links. In both cases, the IS to IS Hello (IIH) message is used to
establish and maintain the adjacency carries the system identifier of
the adjacent systems. The receiving system expects to see its own
system identifier listed. If not, then it must drop the adjacency.
An implementation that wishes to avoid the issue in Section 1.1 can
do so by sending out a final IIH that includes no neighboring system
IDs. When this is received, it should cause all neighbors to drop
their adjacencies with the router that sent the IIH. This will also
cause the systems to update their Link State Protocol Data Units
(LSPs), flood them and reconverge to new paths. The technique is
known as Fast Exit Notification.
3. Pseudonodes with Non-zero Metrics
If an operator wishes to reconfigure a multi-access LAN so that it is
only used as a resource of the last resort, then with current
mechanisms, the operator must reconfigure each node on the LAN to
give the LAN a high metric, as described in Section 1.2. It would be
much easier for the operator if they could make a single
configuration change that would cause IS-IS to treat the multi-access
LAN as a link of last resort.
[ISO10589] defines the pseudonode LSP as having a metric of zero.
This implies that during the Shortest Path First (SPF) calculation,
Shen, et al. Expires August 18, 2013 [Page 3]
Internet-Draft IS-IS Operational Enhancements February 2013
the metric for traversing the LAN is solely based on the metric set
by the IS used to access the LAN. Thereby, the pseudonode does not
contribute to the cost of traversing the LAN.
However, from the point of view of the SPF calculation, the metric in
the pseudonode LSP does not have to be zero. Instead, the metric in
a pseudonode LSP could be treated just like a normal LSP and have
non-zero metrics to some or all of the systems on the LAN. This can
then be used to simplify the operation for turning an entire LAN into
a link of last resort. This could be done by having the Designated
Intermediate System (DIS) change all of the metrics within the
pseudonode LSP to a high value. This would effectively make the
entire LAN look very 'expensive' and cause SPF calculations to
converge to alternate links, if at all possible.
This technique can also be used to divert traffic away from a subset
of the nodes on the LAN. If the DIS increases the metric from the
pseudonode to a subset of the systems on the LAN, then traffic will
avoid exiting the LAN via that subset of systems.
3.1. Alternative Approaches
An alternative is to allow any system to temporarily become the DIS,
when it is directed to, and set a non-zero metric in the pseudonode
LSP(s). This is beneficial because the operator would otherwise
first have to determine the current DIS, access that system and
reconfigure it. If an implementation wishes to support this, it can
provide an operation that both changes its priority on the LAN, so
that a node first becomes DIS, and then generates a new pseudonode
LSP with the non-zero metric.
If there is a concern that the DIS may change, it is prudent to
define another node on the same LAN with the second highest priority
for becoming DIS. This node can be configured to also set the metric
in its pseudonode LSP appropriately if it becomes the new DIS.
4. Operational Considerations
4.1. Operational Considerations: Fast Exit Notification
The approach described in Section 2 is not guaranteed. If the final
IIH is lost on the link, then the neighboring systems will have to
wait to time out the adjacency. Since this is unlikely, it is still
a useful optimization. Implementations that require an even higher
degree of assurance can retransmit the final IIH, possibly multiple
times.
Shen, et al. Expires August 18, 2013 [Page 4]
Internet-Draft IS-IS Operational Enhancements February 2013
4.2. Operational Considerations: Pseudonodes with Non-zero Metrics
Because the change to the usage of the pseudonode LSP, as described
in Section 3, is in direct contradiction to the existing IS-IS
specification, extreme caution is necessary. Implementations that
would not interpret a non-zero pseudonode metric correctly might
cause forwarding loops. Operators should perform Lab testing and
take caution when deploying this feature to ensure that nodes that
receive a non-zero pseudonode metric will interpret it correctly.
5. Security Considerations
This document raises no new security issues for IS-IS.
6. Acknowledgements
The authors would like to thank Mike Shand, Dave Katz, Guan Deng,
Ilya Varlashkin, Jay Chen, Peter Ashwood-Smith, Les Ginsberg, Danny
McPherson, Ed Crabbe, Russ White and Robert Raszuk for their reviews
and contributions.
7. Normative References
[ISO10589]
ISO, "Intermediate system to Intermediate system routeing
information exchange protocol for use in conjunction with
the Protocol for providing the Connectionless-mode Network
Service (ISO 8473) ", ISO/IEC 10589:2002, .
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3373] Katz, D. and R. Saluja, "Three-Way Handshake for
Intermediate System to Intermediate System (IS-IS) Point-
to-Point Adjacencies", RFC 3373, September 2002.
Authors' Addresses
Naiming Shen
Cisco Systems, Inc.
225 West Tasman Drive
San Jose, CA 95134
USA
Email: naiming@cisco.com
Shen, et al. Expires August 18, 2013 [Page 5]
Internet-Draft IS-IS Operational Enhancements February 2013
Tony Li
Cisco Systems, Inc.
225 West Tasman Drive
San Jose, CA 95134
USA
Email: tony.li@tony.li
Shane Amante
Level 3 Communications
1025 Eldorado Blvd
Broomfield, CO 80021
USA
Email: shane@level3.net
Mikael Abrahamsson
Tele2
Email: swmike@swm.pp.se
Shen, et al. Expires August 18, 2013 [Page 6]
