idnits 2.17.1 draft-ietf-isis-experimental-tlv-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (May 2004) is 7286 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. '1' ** Downref: Normative reference to an Informational RFC: RFC 3563 (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 3567 (ref. '5') (Obsoleted by RFC 5304) -- Duplicate reference: RFC3563, mentioned in '7', was also mentioned in '3'. ** Downref: Normative reference to an Informational RFC: RFC 3563 (ref. '7') Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Christian 3 INTERNET DRAFT Christian Tena LTD 4 May 2004 6 TLV for Experimental Use 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its Areas, and its Working Groups. Note that 16 other groups may also distribute working documents as Internet 17 Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet 22 Drafts as reference material or to cite them other than as a 23 "working draft" or "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This memo provides information for the Internet community. This memo 32 does not specify an Internet standard of any kind. 34 Distribution of this draft is unlimited. 36 1. Abstract 38 This document defines a TLV that may be used by any individual, 39 company or other organisation for experimental extensions to the 40 IS-IS routing protocol, and defines the format of the TLV. 42 2. Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 46 this document are to be interpreted as described in RFC 2119. 48 Christian Expires November 2004 1 49 TLV for Experimental Use 51 3. Introduction 53 IS-IS as defined in [1] has always been an extensible routing 54 protocol. Extensions to IS-IS are encoded as a TLV. Critically [1] 55 has always defined that when an IS-IS router receives an LSP, that 56 it SHALL process the parts of the LSP that it understands, and SHALL 57 flood the entire LSP, including all TLVs whether they are understood 58 or not, on to other routers in the network. 60 Thus information that is encoded into a TLV and placed in an LSP by 61 a router will be propagated to every other router in an IS-IS level- 62 1 area or level-2 subdomain, even by implementations that were never 63 designed with that particular TLV in mind. 65 The basic function of an IS-IS TLV is identified by the first byte 66 of the TLV (the code). Thus there are only 256 possible TLV codes. 67 Certain TLVs have been defined to include sub-TLVs so that a single 68 TLV code can be used for multiple functions. 70 During 2003 an agreement was reached between ISOC/IETF and ISO/IEC 71 JTC1/SC6 on how enhancements to IS-IS would be developed and 72 documented. This agreement is documented in [7]. Before this 73 agreement it was not clear which authorities could or could not 74 assign TLV codes. Also no TLV was defined for experimental 75 purposes. The extensible nature of IS-IS has made the use of TLVs 76 for non-standard purposes so useful that vendors have occasionally 77 simply chosen a number and hoped for the best. The risk is that 78 such a TLV code may then be chosen by another organization at a 79 later time for a different function, thus creating an 80 interoperability problem. Also this accelerates the depletion of 81 the 256 possible TLV codes. [3] lists TLV codes that are known to 82 have been used. 84 This document specifies a TLV that may be used for experimental 85 purposes, and a mechanism that insures that different 86 implementations using this TLV can exist in the same network without 87 creating interoperability problems. 89 By using this new TLV, companies, individuals or institutions may 90 use extensions to IS-IS without fear of interoperability problems 91 with other organizations in the future, and the available pool of 92 TLV codes will no longer be diminished by experimental use. 94 4. TLV code for experimental use 96 The code for this TLV SHALL be 250. 98 TLVs that use 250 for the code field MUST include a valid IEEE 99 assigned OUI as the first three bytes of the value of the TLV. 101 Christian Expires November 2004 2 102 TLV for Experimental Use 104 The structure of the TLV is shown in the diagram below. 106 No. of Octets 107 +---------------------------+ 108 | CODE =250 | 1 109 +---------------------------+ 110 | LENGTH =n+3 | 1 111 +---------------------------+ 112 | OUI | 3 113 +---------------------------+ 114 | DATA | n 115 +---------------------------+ 117 Structure of the Experimental TLV 119 The three octet OUI plus the data octets together constitute a 120 normal IS-IS variable length value field. The length field MUST be 121 set to the number of octets of data plus three. 123 For more information about OUIs refer to [4]. 125 The Experimental TLV MAY be used in LSPs, IIHs and/or SNPs. 127 On receipt of an LSP a router MAY ignore TLVs of type 250 that 128 include an OUI from a different organization, but MUST flood the LSP 129 onwards as per [1]. IIHs and SNPs that contain TLVs of type 250 MUST 130 also be handled as per [1]. 132 After the first three bytes of the value field of the TLV subsequent 133 bytes MAY be used freely for any purpose (within the limitations set 134 out in this document) provided that the resultant TLV is conformant 135 with [1]. 137 Many organizations will have access to only one or a few OUIs. 138 Implementers are free to format the value field after their OUI into 139 sub-TLVs so that the TLV may be used for multiple purposes, and would 140 be well advised to do so. 142 5. Using experimental information to modify SPF 144 All routers in an IS-IS routed network need to calculate routes 145 such that they all arrive at the same shortest path for a given 146 destination. If this does not happen then routing loops and 147 blackholes are likely to occur. 149 Therefore a router MUST NOT calculate a route differently due to 150 information that it receives in an experimental TLV. Shortest paths 151 MUST continue to be calculated as per [1] and [2]. 153 Christian Expires November 2004 3 154 TLV for Experimental Use 156 6. Correct use of Experimental TLV in LSPs 158 Some implementations recalculate SPF each time that they receive a 159 new LSP. In the least case an implementation needs to decide 160 whether a new LSP is significant or not. If one router constantly 161 transmits LSPs into the network then others may not perform well. 163 Additionally LSPs are flooded to every router in a level-1 area or 164 level-2 subdomain, and are therefore not a particularly efficient 165 way of carrying a piece of information simply from router A to 166 router B. 168 Consequently the experimental TLV SHOULD NOT be used within LSPs as 169 any kind of general transport mechanism, and the experimental TLV 170 SHOULD NOT cause frequent transmission of LSPs into the network. 172 In general it would be preferable to transmit information in an 173 experimental TLV at such time as an LSP would be normally be 174 transmitted anyway, if this is possible. 176 These particular restrictions do not apply to use of the 177 experimental TLV in IIHs and SNPs. 179 7. Authentication of PDUs 181 If HMAC authentication of IS-IS PDUs that contain an experimental 182 TLV is used then the experimental TLV MUST be included in the HMAC 183 calculation. 185 8. Documenting an Experimental TLV 187 Without an understanding of what an experimental TLV has been used 188 for an operator is not able to make an informed decision as to 189 whether or not to deploy it in their network. 191 Implementors SHOULD document the use of an Experimental TLV in an 192 experimental status RFC. Experimental RFCs MAY be submitted 193 directly to the RFC editor and do not necessarily need to discussed 194 by the workgroup. Details may be found in section 4.2.3 of RFC 195 2026 [6]. 197 If such documentation is not available then an operator SHOULD 198 consider the interoperability and security of an implementation 199 to be unknown. 201 Christian Expires November 2004 4 202 TLV for Experimental Use 204 9. Security Considerations 206 The contents of IS-IS PDUs are not protected by encryption, 207 so the contents of TLVs in LSPs are visible throughout the 208 routing area or domain, while the contents of Hello Packets, 209 CSNPs, and PSNPs are visible to observers on the link they 210 are sent to. The addition of MD5 authentication, as described 211 in [5] can increase the integrity of TLVs, while encryption could 212 increase their confidentiality. 214 The general extensibility of the TLV mechanism has always allowed 215 the addition of new information, and the possibility of conflicting 216 interpretations of such information by different implementations. 217 This proposal does not introduce a new quality of information; it 218 simply allows an increase in the quantity of such additions. As 219 such, it represents no new security issues for IS-IS. 221 10. IANA Considerations 223 [3] currently lists TLV 250 as refering to an IETF draft. At such 224 time that this document becomes an RFC then the entry for TLV 250 in 225 [3] will need to refer to the RFC number of this document. 227 11. References 229 [1] ISO, "Intermediate system to Intermediate system routeing 230 information exchange protocol for use in conjunction with the 231 Protocol for providing the Connectionless-mode Network Service 232 (ISO 8473)", ISO/IEC 10589:1992. 234 [2] RFC 1195, Use of OSI IS-IS for Routing in TCP/IP and Dual 235 Environments, R Callon, December 1990 237 [3] IS-IS TLV Codepoints per [RFC3563] 238 IANA, http://www.iana.org/assignments/isis-tlv-codepoints 240 [4] IEEE OUI and Company_id Assignments 241 http://standards.ieee.org/regauth/oui/index.shtml 243 [5] RFC 3567, Intermediate System to Intermediate System (IS-IS) 244 Cryptographic Authentication 245 Tony Li, RJ Atkinson, July 2003 247 [6] RFC 2026, The Internet Standards Process -- Revision 3 248 Scott O. Bradner, October 1996 250 Christian Expires November 2004 5 251 TLV for Experimental Use 253 [7] RFC 3563, Cooperative Agreement Between the ISOC/IETF and 254 ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) 255 on IS-IS Routing Protocol Development, A. Zinin, July 2003 257 12. Author's Addresses 259 Philip Christian 260 Christian Tena LTD 262 Email: philip.christian@christiantena.co.uk 264 Christian Expires November 2004 6