idnits 2.17.1 draft-ietf-isis-experimental-tlv-02.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(4): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(7): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(8): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding ** The Abstract section seems to be numbered -(47): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(48): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(55): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(60): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(61): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(66): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(67): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(68): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(71): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(72): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(73): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(80): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(82): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(83): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(86): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(110): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(134): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(135): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(138): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(139): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(144): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(145): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(162): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(211): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(224): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(225): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(227): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(235): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(257): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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. == There are 104 instances of lines with non-ascii characters in the document. == 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 62: '... it SHALL process the parts of the L...' RFC 2119 keyword, line 102: '... The code for this TLV SHALL be 250....' RFC 2119 keyword, line 104: '...r the code field MUST include a valid ...' RFC 2119 keyword, line 126: '...value field. The length field MUST be...' RFC 2119 keyword, line 131: '...Experimental TLV MAY be used in LSPs, ...' (12 more instances...) 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 (January 2004) is 7378 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) == Missing Reference: '1' is mentioned on line 233, but not defined == Missing Reference: '3' is mentioned on line 241, but not defined -- Looks like a reference, but probably isn't: 'RFC3563' on line 241 -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 3567 (ref. '5') (Obsoleted by RFC 5304) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 4 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 ������������������������������������������������������ ���January 2004 5 � 6 � 7 ������������������������ TLV for Experimental Use 8 ����������������� 9 � 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its Areas, and its Working Groups. Note that 17 other groups may also distribute working documents as Internet 18 Drafts. 20 Internet Drafts are draft documents valid for a maximum of six 21 months. Internet Drafts may be updated, replaced, or obsoleted by 22 other documents at any time. It is not appropriate to use Internet 23 Drafts as reference material or to cite them other than as a 24 "working draft" or "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This memo provides information for the Internet community. This memo 33 does not specify an Internet standard of any kind. 35 Distribution of this draft is unlimited. 36 ��� 37 ��� 38 1. Abstract 39 ��� 40 �� This document defines a TLV that may be used by any individual, 41 �� company or other organisation for experimental extensions to the 42 IS-IS routing protocol, and defines the format of the TLV. 43 ��� 44 ��� 45 2. Conventions used in this document 46 ��� 47 �� The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 �� "SHOULD", "SHOULD NOT", "RECOMMENDED",� "MAY", and "OPTIONAL" in 49 �� this document are to be interpreted as described in RFC 2119. 50 ��� 51 ��� 52 � 54 Christian Expires July 2004 1 55 ���������������������� TLV for Experimental Use 56 � 57 3. Introduction 58 ��� 59 �� IS-IS as defined in [1] has always been an extensible routing 60 �� protocol.� Extensions to IS-IS are encoded as a TLV.� Critically [1] 61 �� has always defined that when an IS-IS router receives an LSP, that 62 it SHALL process the parts of the LSP that it understands, and SHALL 63 flood the entire LSP, including all TLVs whether they are understood 64 or not, on to other routers in the network. 65 ��� 66 �� Thus information that is encoded into a TLV and placed in an LSP by 67 �� a router will be propagated to every other router in an IS-IS level- 68 �� 1 area or level-2 subdomain, even by implementations that were never 69 designed with that particular TLV in mind. 70 ��� 71 �� The basic function of an IS-IS TLV is identified by the first byte 72 �� of the TLV (the code).� Thus there are only 256 possible TLV codes.� 73 �� Certain TLVs have been defined to include sub-TLVs so that a single 74 �� TLV code can be used for multiple functions. 75 ��� 76 �� No single authority assigns TLV codes, [3] lists most known TLV 77 �� codes at this time.� Also no TLV code was ever defined for 78 experimental use. 79 ��� 80 �� The extensible nature of IS-IS has made the use of TLVs in LSPs for 81 �� non-standard purposes so useful that in the absence of a central 82 �� authority for assigning TLV type numbers vendors have occasionally 83 �� simply chosen a number and hoped for the best.� The risk is that 84 �� such a TLV code may then be chosen by another organization at a 85 �� later time for a different function, thus creating an 86 �� interoperability problem. Also this accelerates the depletion of the 87 �� 256 possible TLV codes. 88 ��� 89 �� This document specifies a TLV that may be used for experimental 90 purposes, and a mechanism that insures that different 91 implementations using this TLV can exist in the same network without 92 creating interoperability problems. 93 ��� 94 �� By using this new TLV, companies, individuals or institutions may 95 �� use extensions to IS-IS without fear of interoperability problems 96 �� with other organizations in the future, and the available pool of 97 �� TLV codes will no longer be diminished by experimental use. 98 ��� 99 � 100 4. TLV code for experimental use 101 ��� 102 �� The code for this TLV SHALL be 250. 103 ��� 104 �� TLVs that use 250 for the code field MUST include a valid IEEE 105 �� assigned OUI as the first three bytes of the value of the TLV. 107 The structure of the TLV is shown in the diagram below. 109 Christian Expires July 2004 2 110 ���������������������� TLV for Experimental Use 112 No. of Octets 113 +---------------------------+ 114 | CODE =250 | 1 115 +---------------------------+ 116 | LENGTH =n+3 | 1 117 +---------------------------+ 118 | OUI | 3 119 +---------------------------+ 120 | DATA | n 121 +---------------------------+ 123 Structure of the Experimental TLV 125 The three octet OUI plus the data octets together constitute a 126 normal IS-IS variable length value field. The length field MUST be 127 set to the number of octets of data plus three. 129 For more information about OUIs refer to [4]. 131 The Experimental TLV MAY be used in LSPs, IIHs and/or SNPs. 133 �� On receipt of an LSP a router MAY ignore TLVs of type 250 that 134 �� include an OUI from a different organization, but MUST flood the LSP 135 �� onwards as per [1]. IIHs and SNPs that contain TLVs of type 250 MUST 136 also be handled as per [1]. 137 ��� �� 138 �� After the first three bytes of the value field of the TLV subsequent 139 �� bytes MAY be used freely for any purpose (within the limitations set 140 out in this document) provided that the resultant TLV is conformant 141 with [1]. 142 ��� 143 �� Many organizations will have access to only one or a few OUIs.� 144 �� Implementers are free to format the value field after their OUI into 145 �� sub-TLVs so that the TLV may be used for multiple purposes, and would 146 be well advised to do so. 148 5. Using experimental information to modify SPF 150 All routers in an IS-IS routed network need to calculate routes 151 such that they all arrive at the same shortest path for a given 152 destination. 154 If this does not happen then routing loops and blackholes are likely 155 to occur. 157 Therefore a router MUST NOT calculate a route differently due to 158 information that it receives in an experimental TLV. Shortest paths 159 MUST continue to be calculated as per [1] and [2]. 161 Christian Expires July 2004 3 162 ���������������������� TLV for Experimental Use 164 6. Correct use of Experimental TLV in LSPs 166 Some implementations recalculate SPF each time that they receive a 167 new LSP. In the least case an implementation needs to decide 168 whether a new LSP is significant or not. If one router constantly 169 transmits LSPs into the network then others may not perform well. 171 Additionally LSPs are flooded to every router in a level-1 area or 172 level-2 subdomain, and are therefore not a particularly efficient 173 way of carrying a piece of information simply from router A to 174 router B. 176 Consequently the experimental TLV SHOULD NOT be used within LSPs as 177 any kind of general transport mechanism, and the experimental TLV 178 SHOULD NOT cause frequent transmission of LSPs into the network. 180 In general it would be preferable to transmit information in an 181 experimental TLV at such time as an LSP would be normally be 182 transmitted anyway, if this is possible. 184 These particular restrictions do not apply to use of the 185 experimental TLV in IIHs and SNPs. 187 7. Authentication of PDUs 189 If HMAC authentication of IS-IS PDUs that contain an experimental 190 TLV is used then the experimental TLV MUST be included in the HMAC 191 calculation. 193 ��� 194 8. Documenting an Experimental TLV 196 Without an understanding of what an experimental TLV has been used 197 for an operator is not able to make an informed decision as to 198 whether or not to deploy it in their network. 200 Implementors SHOULD document the use of an Experimental TLV in an 201 experimental status RFC. Experimental RFCs MAY be submitted 202 directly to the RFC editor and do not necessarily need to discussed 203 by the workgroup. Details may be found in section 4.2.3 of RFC 204 2026 [6]. 206 If such documentation is not available then an operator SHOULD 207 consider the interoperability and security of an implementation 208 to be unknown. 210 Christian Expires July 2004 4 211 ���������������������� TLV for Experimental Use 213 9. Security Considerations 215 �� The contents of IS-IS PDUs are not protected by encryption, 216 �� so the contents of TLVs in LSPs are visible throughout the 217 �� routing area or domain, while the contents of Hello Packets, 218 �� CSNPs, and PSNPs are visible to observers on the link they 219 �� are sent to.� The addition of MD5 authentication, as described 220 �� in [5] can increase the integrity of TLVs, while encryption could 221 increase their confidentiality.� 223 �� The general extensibility of the TLV mechanism has always allowed 224 �� the addition of new information, and the possibility of conflicting 225 �� interpretations of such information by different implementations.� 226 �� This proposal does not introduce a new quality of information; it 227 �� simply allows an increase in the quantity of such additions.� As 228 �� such, it represents no new security issues for IS-IS. 230 �� 231 10. References 232 ��� 233 �� [1] ISO, "Intermediate system to Intermediate system routeing 234 �� information exchange protocol for use in conjunction with the 235 �� Protocol for providing the Connectionless-mode Network Service 236 (ISO 8473)", ISO/IEC 10589:1992. 238 [2] RFC 1195, Use of OSI IS-IS for Routing in TCP/IP and Dual 239 Environments, R Callon, December 1990 240 ��� 241 �� [3] IS-IS TLV Codepoints per [RFC3563] 242 IANA, http://www.iana.org/assignments/isis-tlv-codepoints 244 [4] IEEE OUI and Company_id Assignments 245 http://standards.ieee.org/regauth/oui/index.shtml 247 [5] RFC 3567, Intermediate System to Intermediate System (IS-IS) 248 Cryptographic Authentication 249 Tony Li, RJ Atkinson, July 2003 251 [6] RFC 2026, The Internet Standards Process -- Revision 3 252 Scott O. Bradner, October 1996 254 ��� 256 Christian Expires July 2004 5 257 ���������������������� TLV for Experimental Use 259 11. Author's Addresses 260 ��� 261 �� Philip Christian 262 �� Christian Tena LTD 263 ��� 264 �� Email: philip.christian@christiantena.co.uk 266 Christian Expires July 2004 6