idnits 2.17.1 draft-ietf-isis-purge-tlv-03.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 RFC5301, 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 (Using the creation date from RFC5301, updated by this document, for RFC5378 checks: 2007-09-30) (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 (June 15, 2010) is 5058 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO TC1' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 7 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: 5301, 5304, 5310 Z. Li 5 (if approved) China Mobile 6 Intended status: Standards Track T. Li 7 Expires: December 17, 2010 Cisco Systems, Inc. 8 J. Dong 9 Huawei Technologies 10 June 15, 2010 12 Purge Originator Identification TLV for IS-IS 13 draft-ietf-isis-purge-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 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 December 17, 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. The Purge Originator Identification TLV . . . . . . . . . . . . 3 63 4. Using the Dynamic Hostname TLV in Purges . . . . . . . . . . . 4 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 65 6. Functional Changes . . . . . . . . . . . . . . . . . . . . . . 4 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 67 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 68 9. Normative References . . . . . . . . . . . . . . . . . . . . . 5 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 The IS-IS [ISO 10589] routing protocol has been widely used in large- 74 scale IP networks because of its strong scalability and fast 75 convergence. 77 The IS-IS protocol floods purges throughout an area, regardless of 78 which IS initiated the purge. If a network operator would like to 79 investigate the cause of the purge, it is difficult to determine the 80 origin of the purge. At present the IS-IS protocol has no mechanism 81 to locate the originator of a purge. To address this problem, this 82 document defines a TLV to be added to purges to record the system ID 83 of the IS generating the purge. 85 Field experience has observed several circumstances where an IS can 86 improperly generate a purge. These are all due to implementation 87 deficiencies or implementations that predate [ISO TC1] and generate a 88 purge when they receive a corrupted LSP. 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. The Purge Originator Identification TLV 98 This document defines a TLV to be included in purges. If an IS 99 generates a purge, it SHOULD include this TLV in the purge with its 100 own system ID. If an IS receives a purge that does not include this 101 TLV, then it SHOULD add this TLV with both its own system ID and the 102 system ID of the IS that it received the purge from. 104 This allows ISs receiving purges to log the system ID of the 105 originator, or the upstream source of the purge. This makes it much 106 easier for the network administrator to locate the origin of the 107 purge and thus the cause of the purge. Similarly, this TLV is 108 helpful to developers in lab situations. 110 The Purge Originator Identification TLV is defined as: 112 CODE - 13 114 LENGTH - total length of the value field. 116 VALUE - 117 Number of system IDs carried in this TLV (1 octet) -- Only the 118 values 1 and 2 are defined. 120 System ID of the Intermediate System that inserted this TLV. 122 System ID of the Intermediate System that the purge was received 123 from. (optional) 125 4. Using the Dynamic Hostname TLV in Purges 127 This document also extends the use of the Dynamic hostname TLV (type 128 137) [RFC5301]. This TLV MAY also be included in purges. This will 129 further aid in the rapid identification of the system that generated 130 the purge. 132 Implementations SHOULD include the Purge Originator Identification 133 TLV in addition to the Dynamic hostname TLV. 135 5. Security Considerations 137 If the Purge Originator Identification TLV or the Dynamic hostname 138 TLV is used in conjunction with IS-IS authentication mechanisms 139 [RFC5304][RFC5310], the purge LSP is constructed or modified as 140 follows. First, the original contents of the LSP are removed, 141 leaving only the LSP header, then the Purge Originator Identification 142 TLV and/or the Dynamic hostname TLV are added, and then the IS-IS 143 authentication TLV is added. 145 Legacy systems that implement [RFC5304] or [RFC5310] MUST discard 146 purges with these additional TLVs. This is not thought to be a 147 significant operational issue as the loss of purges is typically not 148 critical. 150 6. Functional Changes 152 This document amends the behavior specified in [RFC5301], [RFC5304] 153 and [RFC5310]. ISs that receive purges with the Purge Originator 154 Identification TLV or the Dynamic hostname TLV with valid 155 authentication MUST NOT discard the PDU and SHOULD process it 156 normally. The Purge Originator Identification TLV or Dynamic 157 hostname TLV MUST NOT be removed from the purge prior to propagation. 158 If multiple purges are received for the same LSP fragment, then the 159 implementation MAY propagate any one of the purges. 161 7. IANA Considerations 163 RFC EDITOR NOTE: This section to be removed upon publication. 165 This document requests that IANA assign a code point for this TLV 166 from the IS-IS 'TLV Codepoints Registry'. 168 8. Acknowledgments 170 Many thanks to Adrian Farrel and Daniel King for your comments to 171 improve this document and move it forward. 173 The first version of this document was mainly composed by Lianyuan 174 Li. 176 Acknowledgments to the discussion in the mailing list. Some 177 improvements of this document are based on the discussion. 179 9. Normative References 181 [ISO 10589] 182 ISO, "Intermediate system to Intermediate system routeing 183 information exchange protocol for use in conjunction with 184 the Protocol for providing the Connectionless-mode Network 185 Service (ISO 8473)", ISO/IEC 10589:2002. 187 [ISO TC1] ISO, "Intermediate system to Intermediate system intra- 188 domain routeing information exchange protocol for use in 189 conjunction with the protocol for providing the 190 connectionless-mode Network Service (ISO 8473) -- 191 Technical Corrigendum 1", ISO/IEC 10589:1992/ Cor.1:1993. 193 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 194 Requirement Levels", BCP 14, RFC 2119, March 1997. 196 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 197 Mechanism for IS-IS", RFC 5301, October 2008. 199 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 200 Authentication", RFC 5304, October 2008. 202 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 203 and M. Fanto, "IS-IS Generic Cryptographic 204 Authentication", RFC 5310, February 2009. 206 Authors' Addresses 208 Fang Wei 209 China Mobile 210 No. 29, Financial Street, Xicheng District 211 Beijing 100032 212 P.R. China 214 Email: weifang@chinamobile.com 216 Yue Qin 217 China Mobile 218 No. 29, Financial Street, Xicheng District 219 Beijing 100032 220 P.R. China 222 Email: qinyue@chinamobile.com 224 Zhenqiang Li 225 China Mobile 226 Unit2, Dacheng Plaza, No. 28 Xuanwumenxi Ave, Xuanwu District 227 Beijing 100053 228 P.R. China 230 Email: lizhenqiang@chinamobile.com 232 Tony Li 233 Cisco Systems, Inc. 234 170 W. Tasman Dr. 235 San Jose, CA 95134 236 USA 238 Email: tony.li@tony.li 240 Jie Dong 241 Huawei Technologies 242 KuiKe Building, No.9 Xinxi Rd., Haidian District 243 Beijing 100085 244 P.R. China 246 Email: dongjie_dj@huawei.com