idnits 2.17.1 draft-ietf-isis-purge-tlv-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5310, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5304, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. (Using the creation date from RFC5304, updated by this document, for RFC5378 checks: 2008-01-17) (Using the creation date from RFC5310, updated by this document, for RFC5378 checks: 2006-07-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 19, 2010) is 5121 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 10589' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IS-IS Working Group F. Wei 3 Internet-Draft Y. Qin 4 Updates: 5304, 5310 Z. Li 5 (if approved) China Mobile 6 Intended status: Standards Track T. Li 7 Expires: October 21, 2010 Cisco Systems, Inc. 8 J. Dong 9 Huawei Technologies 10 April 19, 2010 12 Purge Originator Identification TLV for IS-IS 13 draft-ietf-isis-purge-tlv-00 15 Abstract 17 At present an IS-IS purge does not contain any information 18 identifying the Intermediate System (IS) that generates the purge. 19 This makes it difficult to locate the source IS. 21 To address this issue, this document defines a TLV to be added to 22 purges to record the system ID of the IS generating it. Since normal 23 LSP flooding does not change LSP contents, this TLV should propagate 24 with the purge. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 21, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 62 3. Cases to Generate Purge Packet . . . . . . . . . . . . . . . . 3 63 4. The Purge Originator Identification TLV . . . . . . . . . . . . 4 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 67 8. Normative References . . . . . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 The IS-IS [ISO 10589] routing protocol has been widely used in large- 73 scale IP networks because of its strong scalability and fast 74 convergence. 76 The IS-IS protocol floods purges throughout an area, regardless of 77 which IS initiated the purge. If a network operator would like to 78 investigate the cause of the purge, it is difficult to determine the 79 origin of the purge. At present the IS-IS protocol has no mechanism 80 to locate the originator of a purge. To address this problem, this 81 document defines a TLV to be added to purges to record the system ID 82 of the IS generating the purge. 84 2. Requirements Language 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 3. Cases to Generate Purge Packet 92 In IS-IS there are three legitimate reasons for an IS to generate a 93 purge: 95 1. An IS purges its own LSP. 97 2. A LSP owned by another IS ages out. 99 3. A new DIS is elected. 101 Field experience has observed serveral other circumstances where an 102 IS can improperly generate a purge: 104 1. An implementation misunderstanding [ISO 10589] or predating TC1 105 generates a purge when it receives a corrupted LSP. 107 2. An implementation with bugs tries to purge one of its LSPs and 108 makes a truly egregious mistake. 110 3. An implementation fails to retain the LSP header after purging 111 while flooding is still in progress. 113 4. The Purge Originator Identification TLV 115 This document defines a TLV to be included in purges. This TLV 116 carries the system ID of the IS generating the purge. 118 This allows ISs receiving purges to log the system ID of the 119 originator. This makes it much easier for the network administrator 120 to locate the origin of the purge and thus the cause of the purge. 121 Similarly, this TLV is helpful to developers in lab situations. 123 The Purge Originator Identification TLV is defined as: 125 CODE - XX (to be assigned) 127 LENGTH - total length of the value field. 129 VALUE - System ID of the Intermediate System that initiated the 130 purge. 132 5. Security Considerations 134 If the proposed TLV is used in conjunction with IS-IS authentication 135 mechanisms [RFC5304][RFC5310], the purge LSP is constructed by 136 removing the original contents of the LSP, leaving only the LSP 137 header, adding the Purge Originator Identification TLV and then 138 adding the IS-IS authentication TLV. This document amends the 139 behavior specified in [RFC5304] and [RFC5310]. 141 6. IANA Considerations 143 RFC EDITOR NOTE: This section to be removed upon publication. 145 This document requests that IANA assign a code point for this TLV 146 from the IS-IS 'TLV Codepoints Registry'. 148 7. Acknowledgments 150 Many thanks to Adrian Farrel and Daniel King for your comments to 151 improve this document and move it forward. 153 The first version of this document was mainly composed by Lianyuan 154 Li. 156 Acknowledgments to the discussion in the mailing list. Some 157 impovements of this document are based on the discussion. 159 8. Normative References 161 [ISO 10589] 162 ISO, "Intermediate system to Intermediate system routeing 163 information exchange protocol for use in conjunction with 164 the Protocol for providing the Connectionless-mode Network 165 Service (ISO 8473)", ISO/IEC 10589:2002. 167 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 168 Requirement Levels", BCP 14, RFC 2119, March 1997. 170 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 171 Authentication", RFC 5304, October 2008. 173 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 174 and M. Fanto, "IS-IS Generic Cryptographic 175 Authentication", RFC 5310, February 2009. 177 Authors' Addresses 179 Fang Wei 180 China Mobile 181 No. 29, Financial Street, Xicheng District 182 Beijing 100032 183 P.R. China 185 Email: weifang@chinamobile.com 187 Yue Qin 188 China Mobile 189 No. 29, Financial Street, Xicheng District 190 Beijing 100032 191 P.R. China 193 Email: qinyue@chinamobile.com 195 Zhenqiang Li 196 China Mobile 197 Unit2, Dacheng Plaza, No. 28 Xuanwumenxi Ave, Xuanwu District 198 Beijing 100053 199 P.R. China 201 Email: lizhenqiang@chinamobile.com 202 Tony Li 203 Cisco Systems, Inc. 204 170 W. Tasman Dr. 205 San Jose, CA 95134 206 USA 208 Email: tony.li@tony.li 210 Jie Dong 211 Huawei Technologies 212 KuiKe Building, No.9 Xinxi Rd., Haidian District 213 Beijing 100085 214 P.R. China 216 Email: dongjie_dj@huawei.com