idnits 2.17.1 draft-ietf-isis-purge-tlv-04.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 (September 1, 2010) is 4958 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) == Outdated reference: A later version (-01) exists of draft-li-reg-purge-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.li-reg-purge' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 10589' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO TC1' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 8 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: March 5, 2011 Cisco Systems, Inc. 8 J. Dong 9 Huawei Technologies 10 September 1, 2010 12 Purge Originator Identification TLV for IS-IS 13 draft-ietf-isis-purge-tlv-04 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 March 5, 2011. 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 (POI) TLV . . . . . . . . . 3 63 4. Using the Dynamic Hostname TLV in Purges . . . . . . . . . . . 4 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 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 Field experience has observed several circumstances where an IS can 85 improperly generate a purge. These are all due to implementation 86 deficiencies or implementations that predate [ISO TC1] and generate a 87 purge when they receive a corrupted LSP. 89 2. Requirements Language 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 3. The Purge Originator Identification (POI) TLV 97 This document defines a TLV to be included in purges. If an IS 98 generates a purge, it SHOULD include this TLV in the purge with its 99 own system ID. If an IS receives a purge that does not include this 100 TLV, then it SHOULD add this TLV with both its own system ID and the 101 system ID of the IS that it received the purge from. This allows ISs 102 receiving purges to log the system ID of the originator, or the 103 upstream source of the purge. This makes it much easier for the 104 network administrator to locate the origin of the purge and thus the 105 cause of the purge. Similarly, this TLV is helpful to developers in 106 lab situations. 108 The POI TLV is defined as: 110 CODE - 13 112 LENGTH - total length of the value field. 114 VALUE - 115 Number of system IDs carried in this TLV (1 octet) -- Only the 116 values 1 and 2 are defined. 118 System ID of the Intermediate System that inserted this TLV. 120 System ID of the Intermediate System that the purge was received 121 from. (optional) 123 The POI TLV SHOULD be found in all purges and MUST NOT be found in 124 LSPs with a non-zero Remaining Lifetime. 126 4. Using the Dynamic Hostname TLV in Purges 128 This document also extends the use of the Dynamic hostname TLV (type 129 137) [RFC5301] to further aid in the rapid identification of the 130 system that generated the purge. This TLV MAY be included in purges. 131 Implementations SHOULD include the Dynamic hostname TLV if the POI 132 TLV is included. 134 5. Security Considerations 136 Use of the extensions defined here with authentication as defined in 137 [RFC5304] or [RFC5310] will result in the discarding of purges by 138 legacy systems which are in strict conformance with either of those 139 RFCs. This may compromise the correctness/consistency of the routing 140 database unless all ISs in the network support these extensions. NEW 141 TEXT: Therefore, all implementations in a domain implementing 142 authentication MUST be upgraded to receive the POI TLV before any IS 143 is allowed to generate a purge with the POI TLV. 145 More interactions between the POI TLV, the Dynamic hostname TLV, and 146 the Authentication TLV are described in [I-D.li-reg-purge]. 148 6. IANA Considerations 150 RFC EDITOR NOTE: This section to be removed upon publication. 152 This document requests that IANA assign code point 13 for the 'Purge 153 Originator Identification' TLV from the IS-IS 'TLV Codepoints 154 Registry'. The additional values for this TLV should be: IIH:n, 155 LSP:y, SNP:n, Purge:y. 157 7. Acknowledgments 159 Many thanks to Adrian Farrel and Daniel King for your comments to 160 improve this document and move it forward. 162 The first version of this document was mainly composed by Lianyuan 163 Li. 165 Acknowledgments to the discussion in the mailing list. Some 166 improvements of this document are based on the discussion. 168 8. Normative References 170 [I-D.li-reg-purge] 171 Li, T., "IS-IS Registry Extension for Purges", 172 draft-li-reg-purge-00 (work in progress), August 2010. 174 [ISO 10589] 175 ISO, "Intermediate system to Intermediate system routeing 176 information exchange protocol for use in conjunction with 177 the Protocol for providing the Connectionless-mode Network 178 Service (ISO 8473)", ISO/IEC 10589:2002. 180 [ISO TC1] ISO, "Intermediate system to Intermediate system intra- 181 domain routeing information exchange protocol for use in 182 conjunction with the protocol for providing the 183 connectionless-mode Network Service (ISO 8473) -- 184 Technical Corrigendum 1", ISO/IEC 10589:1992/ Cor.1:1993. 186 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 187 Requirement Levels", BCP 14, RFC 2119, March 1997. 189 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 190 Mechanism for IS-IS", RFC 5301, October 2008. 192 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 193 Authentication", RFC 5304, October 2008. 195 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 196 and M. Fanto, "IS-IS Generic Cryptographic 197 Authentication", RFC 5310, February 2009. 199 Authors' Addresses 201 Fang Wei 202 China Mobile 203 No. 29, Financial Street, Xicheng District 204 Beijing 100032 205 P.R. China 207 Email: weifang@chinamobile.com 209 Yue Qin 210 China Mobile 211 No. 29, Financial Street, Xicheng District 212 Beijing 100032 213 P.R. China 215 Email: qinyue@chinamobile.com 217 Zhenqiang Li 218 China Mobile 219 Unit2, Dacheng Plaza, No. 28 Xuanwumenxi Ave, Xuanwu District 220 Beijing 100053 221 P.R. China 223 Email: lizhenqiang@chinamobile.com 225 Tony Li 226 Cisco Systems, Inc. 227 170 W. Tasman Dr. 228 San Jose, CA 95134 229 USA 231 Email: tony.li@tony.li 233 Jie Dong 234 Huawei Technologies 235 KuiKe Building, No.9 Xinxi Rd., Haidian District 236 Beijing 100085 237 P.R. China 239 Email: dongjie_dj@huawei.com