IS-IS Working Group Zhenqiang Li,
Internet-Draft Lianyuan Li,
Intended status: Informational Xiaodong Duan,
Expires: January 6, 2009 China Mobile
July 7, 2008
Problem Statement: Link Degradation Isolation in Interoperable Networks
using Intermediate System to Intermediate System (IS-IS)
draft-li-isis-degradation-isolation-problem-00
Status of this memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
IS-IS protocol specifies a procedure that if a Link State Protocol
Data Unit (LSP) with an incorrect LSP Checksum is received, the
corruptedLSPReceived circuit event will be generated and the
corrupted LSP will be discarded. This document aims to emphasize that
although this procedure can maintain the network stability, it can
not diagnose and isolate the source of the network problem. In some
cases this procedure will create bad effect on the services carried
by the network. This document suggests that IS-IS protocol introduce
the mechanism for link degradation detection and isolation, which
should be triggered when corrupted LSP is received.
Zhenqiang Li, et al. [Page 1]
INTERNET-DRAFT Link Degradation Isolation in IS-IS July, 2008
1. Introduction
IS-IS Protocol [1], one of the widely deployed Interior Gateway
Protocols (IGP), has proved to be quite durable, which, to some
extent, is attributed to the success in handling LSP with an
incorrect LSP Checksum.
Section 7.3.14.2 e) of [1] states: An Intermediate System receiving
a LSP with an incorrect LSP Checksum or with an invalid PDU syntax
shall
1) generate a corruptedLSPReceived circuit event,
2) discard the PDU.
This method contributes good network stability in the case that the
network errors occur once in a while. However, if the cause of
checksum error belongs to the network error, such as the
deterioration of transmission quality, the error in the network
devices, etc., and the error stays for a long time, in such cases,
the network error can not be isolated automatically. In practice, the
implementation of certain vendor does not generate the
corruptedLSPReceived circuit event when it receives the corrupted LSP,
or the corruptedLSPReceived circuit event is not reported to the
network management system. It is this ??silent discard?? method that
makes the network error can not be detected in time and exerts bad
effect on the services carried by the network.
This document presents the problems that exist in the IS-IS protocol
and solicits link degradation detection and isolation mechanism to be
introduced in IS-IS protocol.
2. Definitions
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 [2].
3. Implementation Suggestion
All the implementation of IS-IS protocol SHOULD firmly comply with
the ISO 10589 Recommendation. A corruptedLSPReceived circuit event
MUST be generated and SHOULD be reported to the network management
system, when network device receives a LSP with an incorrect LSP
checksum.
When network device discards the corrupted LSP, it SHOULD inform the
corresponding router(s) in its neighbor by some specific way and the
Zhenqiang Li, et al. [Page 2]
INTERNET-DRAFT Link Degradation Isolation in IS-IS July, 2008
neighbor router(s) can check the state of the corresponding link. If
the quality of the link degrades, such as increased bit error rate,
and/or increased delay time, some methods SHOULD be specified for
the router to react to the abnormality, and the router SHOULD inform
other routers in the network about the abnormality, so as to isolate
the problem. The available methods include but not limited to the
followings: to increase the Metric of the link, to disconnect the
links, etc.
4. BFD Considerations
Bidirectional Forwarding Detection (BFD) [3] provides short-duration
detection of failures in the path between adjacent forwarding
engines, including the interfaces, data link(s), and to the extent
possible the forwarding engines themselves. However??BFD can not
work effectively to detect the link degradation. So, it can not be
directly used to handle the problem in IS-IS protocol depicted in
this document.
5. Security Considerations
Given that the mechanism of link degradation detection and isolation
is introduced to IS-IS protocol, malicious guy can bring extra burden
to the network just by forging checksum error LSP to network, since
routers will trigger the mechanism of link state detection and
isolation.
However, IS-IS protocol comprises encrpytion techniques to avoid
malicious guy to forge LSPs, including both correct and checksum
error LSPs.
6. References
[1] 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.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] D. Katz, and D. Ward, ??Bidirectional Forwarding Detection??,
draft-ietf-bfd-base-08 (work in progress), March 2008.
Zhenqiang Li, et al. [Page 3]
INTERNET-DRAFT Link Degradation Isolation in IS-IS July, 2008
Authors' Addresses
Zhenqiang Li (editor)
China Mobile Research Institute
Gate 2 Dacheng Plaza
No. 28 Xuanwumen West Street
Xuanwu District, Beijing 100053
China
Phone: +86 1391 163 5816
Email: lizhenqiang@chinamobile.com
Lianyuan Li
China Mobile Research Institute
Gate 2 Dacheng Plaza
No. 28 Xuanwumen West Street
Xuanwu District, Beijing 100053
China
Phone: +86 1391 178 9703
Email: lilianyuan@chinamobile.com
Xiaodong Duan
China Mobile Research Institute
Gate 2 Dacheng Plaza
No. 28 Xuanwumen West Street
Xuanwu District, Beijing 100053
China
Phone: +86 1391 019 1797
Email: duanxiaodong@chinamobile.com
Zhenqiang Li, et al. [Page 4]
INTERNET-DRAFT Link Degradation Isolation in IS-IS July, 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Zhenqiang Li, et al. [Page 5]