idnits 2.17.1 draft-wei-isis-tlv-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (March 8, 2010) is 5162 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: 1 error (**), 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: September 9, 2010 Cisco Systems, Inc. 8 J. Dong 9 Huawei Technologies 10 March 8, 2010 12 Purge Originator Identification TLV for IS-IS 13 draft-wei-isis-tlv-03 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 to IETF 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), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 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 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on September 9, 2010. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 68 3. Cases to Generate Purge Packet . . . . . . . . . . . . . . . . 3 69 4. The Purge Originator Identification TLV . . . . . . . . . . . . 4 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 73 8. Normative References . . . . . . . . . . . . . . . . . . . . . 5 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 76 1. Introduction 78 The IS-IS [ISO 10589] routing protocol has been widely used in large- 79 scale IP networks because of its strong scalability and fast 80 convergence. 82 The IS-IS protocol floods purges throughout an area, regardless of 83 which IS initiated the purge. If a network operator would like to 84 investigate the cause of the purge, it is difficult to determine the 85 origin of the purge. At present the IS-IS protocol has no mechanism 86 to locate the originator of a purge. To address this problem, this 87 document defines a TLV to be added to purges to record the system ID 88 of the IS generating the purge. 90 2. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 3. Cases to Generate Purge Packet 98 In IS-IS there are three legitimate reasons for an IS to generate a 99 purge: 101 1. An IS purges its own LSP. 103 2. A LSP owned by another IS ages out. 105 3. A new DIS is elected. 107 Field experience has observed serveral other circumstances where an 108 IS can improperly generate a purge: 110 1. An implementation misunderstanding [ISO 10589] or predating TC1 111 generates a purge when it receives a corrupted LSP. 113 2. An implementation with bugs tries to purge one of its LSPs and 114 makes a truly egregious mistake. 116 3. An implementation fails to retain the LSP header after purging 117 while flooding is still in progress. 119 4. The Purge Originator Identification TLV 121 This document defines a TLV to be included in purges. This TLV 122 carries the system ID of the IS generating the purge. 124 This allows ISs receiving purges to log the system ID of the 125 originator. This makes it much easier for the network adminstrator 126 to locate the origin of the purge and thus the cause of the purge. 127 Similarly, this TLV is helpful to develpers in lab situations. 129 The Purge Originator Identification TLV is defined as: 131 CODE - XX (to be assigned) 133 LENGTH - total length of the value field. 135 VALUE - System ID of the Intermediate System that initiated the 136 purge. 138 5. Security Considerations 140 If the proposed TLV is used in conjunction with IS-IS authentication 141 mechanisms [RFC5304][RFC5310], the purge LSP is constructed by 142 removing the original contents of the LSP, leaving only the LSP 143 header, adding the Purge Originator Identification TLV and then 144 adding the IS-IS authentication TLV. This document amends the 145 behavior specified in [RFC5304] and [RFC5310]. 147 6. IANA Considerations 149 RFC EDITOR NOTE: This section to be removed upon publication. 151 This document requests that IANA assign a code point for this TLV 152 from the IS-IS 'TLV Codepoints Registry'. 154 7. Acknowledgments 156 Many thanks to Adrian Farrel and Daniel King for your comments to 157 improve this document and move it forward. 159 The first version of this document was mainly composed by Lianyuan 160 Li. 162 Acknowledgments to the discussion in the mailing list. Some 163 impovements of this document are based on the discussion. 165 8. Normative References 167 [ISO 10589] 168 ISO, "Intermediate system to Intermediate system routeing 169 information exchange protocol for use in conjunction with 170 the Protocol for providing the Connectionless-mode Network 171 Service (ISO 8473)", ISO/IEC 10589:2002. 173 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 174 Requirement Levels", BCP 14, RFC 2119, March 1997. 176 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 177 Authentication", RFC 5304, October 2008. 179 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 180 and M. Fanto, "IS-IS Generic Cryptographic 181 Authentication", RFC 5310, February 2009. 183 Authors' Addresses 185 Fang Wei 186 China Mobile 187 No. 29, Financial Street, Xicheng District 188 Beijing 100032 189 P.R. China 191 Email: weifang@chinamobile.com 193 Yue Qin 194 China Mobile 195 No. 29, Financial Street, Xicheng District 196 Beijing 100032 197 P.R. China 199 Email: qinyue@chinamobile.com 201 Zhenqiang Li 202 China Mobile 203 Unit2, Dacheng Plaza, No. 28 Xuanwumenxi Ave, Xuanwu District 204 Beijing 100053 205 P.R. China 207 Email: lizhenqiang@chinamobile.com 208 Tony Li 209 Cisco Systems, Inc. 210 170 W. Tasman Dr. 211 San Jose, CA 95134 212 USA 214 Email: tony.li@tony.li 216 Jie Dong 217 Huawei Technologies 218 KuiKe Building, No.9 Xinxi Rd., Haidian District 219 Beijing 100085 220 P.R. China 222 Email: dongjie_dj@huawei.com