IS-IS Working Group Z. Li Internet Draft L. Li Intended status: BEST CURRENT PRACTICE X. Duan Expires: April 24, 2010 Y. Qin F. Wei Z. Huang China Mobile October 25, 2009 Recommendations for Checksum Error LSP Processing in IS-IS draft-li-isis-error-lsp-processing-02.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 This Internet-Draft will expire on April 24, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Li January 11, 2010 [Page 1] Internet-Draft draft-li-isis-error-lsp-processing October 2009 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract RFC3719 discusses a number of differences between the IS-IS protocol as described in ISO 10589 and the protocol as it is deployed today. This document discusses some other differences found in the China Mobile's backbone network which is constructed with routers from several manufacturers. The differences include LSP checksum calculation, zero checksum LSP processing, zero remaining lifetime LSP processing, and corrupt LSP processing. 1. Introduction Intermediate System to Intermediate System (IS-IS) Protocol [1] is one of the Interior Gateway Protocols. It is widely deployed in the carrier backbone networks. RFC3719 [2] discusses a number of differences between the IS-IS protocol as described in ISO 10589 and the protocol as it is deployed today. In the China Mobile's backbone network, which is constructed with a few hundreds of routers from several manufacturers, some other differences were found. These differences contributed to a severe network flapping across the whole network. The differences discussed in this document include LSP checksum calculation, zero checksum LSP processing, zero remaining lifetime LSP processing, and corrupt LSP processing. 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 [3]. 2. Checksum calculation Note 36, section 7.3.16.4, ISO 10589 prescribes that examining the checksum of a zero Remaining Lifetime LSP is always successful. Thus, some implementations fill in the checksum field with zero in the zero Remaining Lifetime LSP. To insure the interoperability and maintain network stability, it is RECOMMENDED to calculate the checksum of all LSPs correctly, Li April 24, 2010 [Page 2] Internet-Draft draft-li-isis-error-lsp-processing October 2009 including zero Remaining Lifetime LSP. The calculation method is presented in Section 7.3.11, ISO 10589. 3. Zero Checksum LSP Processing RFC 3719 [2], section 7, suggests an implementation SHOULD treat all LSPs with a zero checksum and a non-zero remaining lifetime as if they had as checksum error. ISO 10589, section 7.3.16.4, note 36, states: A check of the checksum of a zero Remaining Lifetime LSP succeeds even though the data portion is not present. Therefore, the LSP with a zero checksum and a zero remaining lifetime SHOULD be treated as the LSP with correct checksum. Consider the above two conditions together, the implementation SHOULD check the remaining lifetime first, then check the checksum. In practice, some implementation does the check in the reverse way. Take the on-off switch into account, equipments with on-off switch SHOULD treat LSPs with a zero checksum and a non-zero remaining lifetime in accordance with the processing mechanism mentioned in the previous section 2. As for the LSPs with a zero checksum and a zero remaining lifetime, the processing mechanism SHOULD NOT be affected by the switch state. 4. Zero Remaining Lifetime LSP Processing ISO 10589, section 7.3.16.4, note 36, states: A check of the checksum of a zero Remaining Lifetime LSP succeeds even though the data portion is not present. Therefore, a zero Remaining Lifetime LSP SHOULD be treated as correct LSP, no matter whether its checksum is correct or not. Some implementations, however, still check the checksum of a zero Remaining Lifetime LSP. The processing mechanism SHOULD NOT be affected by the on-off switch and the details can be seen in section 7.3.16.4. 5. Corrupt LSP Processing Section 7.3.14.2 e) of [1] states: An Intermediate system receiving a Link State PDU (LSP) with an incorrect LSP Checksum or with an invalid PDU syntax shall 1) generate a corruptedLSPReceived circuit event, 2) discard the PDU. Li April 24, 2010 [Page 3] Internet-Draft draft-li-isis-error-lsp-processing October 2009 In order to control the processing mechanism of Checksum error LSP, some equipment manufacturers provide an on-off configuration switch, such as Cisco's IGNORE-LSP-ERRORS switch and Huawei's IGNORE-LSP- CHECKSUM-ERROR switch. However, the default state of the switch is different, thus the processing mechanism of checksum error LSP is not the same. From the carrier's perspective, such on-off configuration switch is welcome, because the carrier can determine the processing mechanism through the switch. But the behavior of the switch SHOULD be the same, as follows. When the on-off switch is on, the processing mechanism for the checksum error LSP SHOULD be accordant with what is stated in Section 7.3.14.2 e) of [1]. When the on-off switch is off, the equipment SHOULD treat the received checksum error LSP in the same way as the LSP whose remaining lifetime equals 0. The processing mechanism is specified in Section 7.3.16.4 of [1]. It is RECOMMENDED that the default state of the on-off switch be on. In this way, the default processing mechanism is in accordance with Section 7.3.14.2 e) of [1]. 6. Security Considerations The suggestions and clarifications in this document will not cause extra new security concerns. 7. References [1] ISO 10589 V2 Telecommunications and information exchange between systems-Intermediate System to Intermediate System [2] J. Parker, Ed., "Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS- IS)", RFC 3719, February 2004. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Li April 24, 2010 [Page 4] Internet-Draft draft-li-isis-error-lsp-processing October 2009 Author's 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 Yue Qin China Mobile Communications Corporation No. 29, Financial Street, Xicheng District, Beijing, 100032 China Email: qinyue@chinamobile.com Li April 24, 2010 [Page 5] Internet-Draft draft-li-isis-error-lsp-processing October 2009 Fang Wei China Mobile Communications Corporation No. 29, Financial Street, Xicheng District, Beijing, 100032 China Email: weifang@chinamobile.com Zhaorui Huang China Mobile Communications Corporation No. 29, Financial Street, Xicheng District, Beijing, 100032 China Email: huangzhaorui@chinamobile.com Li April 24, 2010 [Page 6]