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]