idnits 2.17.1 draft-ietf-isis-reg-purge-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. -- The draft header indicates that this document updates RFC3563, 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 RFC3563, updated by this document, for RFC5378 checks: 2002-10-24) -- 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 24, 2010) is 4935 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 (-05) exists of draft-ietf-isis-purge-tlv-04 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 10589' ** Downref: Normative reference to an Informational RFC: RFC 3563 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IS-IS Working Group T. Li 3 Internet-Draft L. Ginsberg 4 Updates: 3563 5304 5310 Cisco Systems, Inc. 5 (if approved) September 24, 2010 6 Intended status: Standards Track 7 Expires: March 28, 2011 9 IS-IS Registry Extension for Purges 10 draft-ietf-isis-reg-purge-00 12 Abstract 14 IANA maintains the IS-IS TLV Codepoint Registry. This registry 15 documents which TLVs can appear in different types of IS-IS PDUs, but 16 does not document which TLVs can be found in zero Remaining Lifetime 17 LSP (a.k.a., purges). This document extends the existing registry to 18 record the set of TLVs that are permissible in purges. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 28, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 56 2. Registry Changes . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Purges and Authentication . . . . . . . . . . . . . . . . . . . 3 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 60 6. Normative References . . . . . . . . . . . . . . . . . . . . . 4 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1. Introduction 65 The IS-IS [ISO 10589] routing protocol maintains a link state 66 database of the topology of its routing domain by flooding a set of 67 Link State Protocol Data Units (LSPs). When the protocol no longer 68 needs the information stored in an LSP, it uses the purge mechanism 69 to cause the Intermediate Systems (ISs) in its domain to discard the 70 information contained in the LSP. The process for generating purges 71 can be found in Section 7.3.16.4 of [ISO 10589]. This process 72 retains only the LSP header, discarding any TLVs that had been 73 carried within the LSP. 75 Subsequent enhancements to IS-IS, such as [RFC5304] [RFC5310], amend 76 the process of generating a purge and allow the inclusion of certain 77 TLVs in purges. 79 1.1. Requirements Language 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 2. Registry Changes 87 This document extends the current IS-IS TLV Codepoint Registry, 88 defined in [RFC3563], to record the set of TLVs that MAY be found in 89 purges. All other TLVs MUST NOT appear in purges. This will serve 90 as an aid to subsequent documents, which can then refer to the 91 registry as the definitive list of the TLVs allowed in purges. This 92 will also act as an aid to implementers, providing them with an 93 easily accessible compendium of allowable TLVs. 95 The purge status defined for a given TLV applies to all sub-TLVs 96 defined for that TLV. 98 3. Purges and Authentication 100 Previous documents on Authentication [RFC5304] [RFC5310] required 101 that an IS only accept a purge if it only contained the 102 Authentication TLV. 104 This document updates and generalizes that behavior as follows: an 105 implementation that implements Authentication MUST NOT accept a purge 106 that contains any TLV listed in the registry that is not acceptable 107 in a purge. An implementation MUST NOT accept a purge that contains 108 a TLV not listed in the registry unless the purge also contains the 109 Purge Originator Identification (POI) TLV [I-D.ietf-isis-purge-tlv]. 110 Purges that are accepted MUST be propagated without removal of TLVs. 111 If multiple purges are received for the same LSP, then the 112 implementation MAY propagate any one of the purges. 114 If an implementation that implements Authentication accepts a purge 115 that does not include the POI TLV and it chooses to insert the POI 116 TLV, it MUST also recompute Authentication. 118 ISs MUST NOT accept LSPs with a non-zero Remaining Lifetime that 119 contain the POI TLV. 121 Purge generation is updated as follows: an implementation that 122 implements Authentication generates a purge by first removing any 123 TLVs that are not listed in the registry as being acceptable in 124 purges. The POI TLV MUST be added. Then any other TLVs that MAY be 125 in purges, as shown by the registry, MAY be added. Finally, 126 Authentication, if any, is added. 128 4. IANA Considerations 130 This document requests that IANA modify the IS-IS 'TLV Codepoints 131 Registry' by adding a column in the registry for 'Purge'. A 'y' in 132 this column indicates that the TLV for this row MAY be found in a 133 purge. A 'n' in this column indicates that the TLV for this row MUST 134 NOT be found in a purge. 136 The 'Purge' column should initially contain a 'y' for TLV type 10 137 (Authentication) and for TLV type 137 (Dynamic hostname). All other 138 entries in this column should have an 'n'. Other additions to this 139 registry should explicitly specify their value for this column. 141 5. Security Considerations 143 This document introduces no new security issues. 145 6. Normative References 147 [I-D.ietf-isis-purge-tlv] 148 Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge 149 Originator Identification TLV for IS-IS", 150 draft-ietf-isis-purge-tlv-04 (work in progress), 151 September 2010. 153 [ISO 10589] 154 ISO, "Intermediate system to Intermediate system routeing 155 information exchange protocol for use in conjunction with 156 the Protocol for providing the Connectionless-mode Network 157 Service (ISO 8473)", ISO/IEC 10589:2002. 159 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 160 Requirement Levels", BCP 14, RFC 2119, March 1997. 162 [RFC3563] Zinin, A., "Cooperative Agreement Between the ISOC/IETF 163 and ISO/IEC Joint Technical Committee 1/Sub Committee 6 164 (JTC1/SC6) on IS-IS Routing Protocol Development", 165 RFC 3563, July 2003. 167 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 168 Authentication", RFC 5304, October 2008. 170 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 171 and M. Fanto, "IS-IS Generic Cryptographic 172 Authentication", RFC 5310, February 2009. 174 Authors' Addresses 176 Tony Li 177 Cisco Systems, Inc. 178 170 W. Tasman Dr. 179 San Jose, CA 95134 180 USA 182 Email: tony.li@tony.li 184 Les Ginsberg 185 Cisco Systems, Inc. 186 170 W. Tasman Dr. 187 San Jose, CA 95134 188 USA 190 Email: ginsberg@cisco.com