idnits 2.17.1 draft-ietf-isis-purge-tlv-02.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 7, 2010) is 5072 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 9, 2010 Cisco Systems, Inc. 8 J. Dong 9 Huawei Technologies 10 June 7, 2010 12 Purge Originator Identification TLV for IS-IS 13 draft-ietf-isis-purge-tlv-02 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 9, 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. This TLV 99 carries the system ID of the IS generating the purge, or, in a proxy 100 mode, carries the system ID of the IS that first saw the purge and 101 inserted this TLV, as well as the system ID of the system that it 102 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 The system ID of the Intermediate System that the purge was 123 received 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 proposed TLV or the Dynamic hostname TLV is used in 138 conjunction with IS-IS authentication mechanisms [RFC5304][RFC5310], 139 the purge LSP is constructed as follows. First, the original 140 contents of the LSP are removed, leaving only the LSP header, then 141 the Purge Originator Identification TLV and/or the Dynamic hostname 142 TLV are added, and then the IS-IS authentication TLV is added. 144 Legacy systems that implement [RFC5304] or [RFC5310] MUST discard 145 purges with these additional TLVs. This is not thought to be a 146 significant operational issue as the loss of purges is typically not 147 critical. 149 6. Functional Changes 151 This document amends the behavior specified in [RFC5301], [RFC5304] 152 and [RFC5310]. ISs that receive purges with the Purge Originator 153 Identification TLV or the Dynamic hostname TLV with valid 154 authentication MUST NOT discard the PDU and SHOULD process it 155 normally. ISs that receive purges with the Purge Originator 156 Identification TLV or the Dynamic hostname TLV MUST be accepted and 157 processed as a normal purge. The Purge Originator Identification TLV 158 or Dynamic hostname TLV MUST NOT be removed from the purge prior to 159 propagation. If multiple purges are received for the same LSP 160 fragment, then the implementation MAY propagate any one of the 161 purges. 163 7. IANA Considerations 165 RFC EDITOR NOTE: This section to be removed upon publication. 167 This document requests that IANA assign a code point for this TLV 168 from the IS-IS 'TLV Codepoints Registry'. 170 8. Acknowledgments 172 Many thanks to Adrian Farrel and Daniel King for your comments to 173 improve this document and move it forward. 175 The first version of this document was mainly composed by Lianyuan 176 Li. 178 Acknowledgments to the discussion in the mailing list. Some 179 improvements of this document are based on the discussion. 181 9. Normative References 183 [ISO 10589] 184 ISO, "Intermediate system to Intermediate system routeing 185 information exchange protocol for use in conjunction with 186 the Protocol for providing the Connectionless-mode Network 187 Service (ISO 8473)", ISO/IEC 10589:2002. 189 [ISO TC1] ISO, "Intermediate system to Intermediate system intra- 190 domain routeing information exchange protocol for use in 191 conjunction with the protocol for providing the 192 connectionless-mode Network Service (ISO 8473) -- 193 Technical Corrigendum 1", ISO/IEC 10589:1992/ Cor.1:1993. 195 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 196 Requirement Levels", BCP 14, RFC 2119, March 1997. 198 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 199 Mechanism for IS-IS", RFC 5301, October 2008. 201 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 202 Authentication", RFC 5304, October 2008. 204 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 205 and M. Fanto, "IS-IS Generic Cryptographic 206 Authentication", RFC 5310, February 2009. 208 Authors' Addresses 210 Fang Wei 211 China Mobile 212 No. 29, Financial Street, Xicheng District 213 Beijing 100032 214 P.R. China 216 Email: weifang@chinamobile.com 218 Yue Qin 219 China Mobile 220 No. 29, Financial Street, Xicheng District 221 Beijing 100032 222 P.R. China 224 Email: qinyue@chinamobile.com 226 Zhenqiang Li 227 China Mobile 228 Unit2, Dacheng Plaza, No. 28 Xuanwumenxi Ave, Xuanwu District 229 Beijing 100053 230 P.R. China 232 Email: lizhenqiang@chinamobile.com 234 Tony Li 235 Cisco Systems, Inc. 236 170 W. Tasman Dr. 237 San Jose, CA 95134 238 USA 240 Email: tony.li@tony.li 242 Jie Dong 243 Huawei Technologies 244 KuiKe Building, No.9 Xinxi Rd., Haidian District 245 Beijing 100085 246 P.R. China 248 Email: dongjie_dj@huawei.com