idnits 2.17.1 draft-vasseur-isis-link-attr-01.txt: -(42): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(79): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(231): 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): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 204. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 183. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 190. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 196. ** Found boilerplate matching RFC 3979, Section 5, paragraph 3 (on line 196), which is fine, but *also* found old RFC 2026, Section 10.4B text on line 160. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-vasseur-isis-link-attr-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-vasseur-isis-link-attr-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-vasseur-isis-link-attr-', but the file name used is 'draft-vasseur-isis-link-attr-01' == There are 6 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 3 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3979, Section 5, paragraph 1 boilerplate, a section with a similar start was also found: The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it == In addition to RFC 3979, Section 5, paragraph 3 boilerplate, a section with a similar start was also found: The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Link excluded from local protection path (0x02). When set, this link SHOULD not be included in any computation of a repair path by any other router in the routing area. The triggers for setting up this bit are out of the scope of this document. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (July 2004) is 7224 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) == Unused Reference: 'RFC' is defined on line 211, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 3784 (ref. 'IS-IS-TE') (Obsoleted by RFC 5305) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-lsp-fastreroute-03 -- No information found for draft-ali-mpls-graceful-shutdown - is the name correct? Summary: 11 errors (**), 1 flaw (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ISIS WG 3 Internet Draft Jean-Philippe Vasseur 4 Stefano Previdi 5 Cisco Systems 7 Document: draft-vasseur-isis-link-attr- 8 01.txt 9 Expires: January 2005 July 2004 11 Definition of an IS-IS Link Attribute sub-TLV 13 draft-vasseur-isis-link-attr-01.txt 15 Status of this Memo 17 By submitting this Internet-Draft, I certify that any applicable 18 patent or IPR claims of which I am aware have been disclosed, and any 19 of which I become aware will be disclosed, in accordance with RFC 20 3668. 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC2026 [i]. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 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 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 This document defines a sub-TLV called ��Link-attributes�� carried 43 within the TLV 22 and used to flood some link characteristics. 45 Conventions used in this document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC-2119 [ii]. 51 Table of contents 53 1. Introduction...................................................2 54 2. Link-attributes sub-TLV format.................................2 55 3. Interoperability with routers non supporting this capability...3 56 4. Security considerations........................................3 57 5. Intellectual Property Considerations...........................3 58 6. Acknowledgments................................................4 59 7. Intellectual property considerations...........................4 60 7.1 IPR Disclosure Acknowledgement.............................5 61 8. References.....................................................5 62 Normative references..............................................5 63 Informative references............................................5 64 9. Author's Addresses.............................................5 65 10. Full Copyright Statement......................................6 67 1. 68 Introduction 70 [IS-IS] specifies the IS-IS protocol (ISO 10589) with extensions to 71 support IPv4 in [IS-IS-IP]. A router advertises one or several Link 72 State Protocol data units which are composed of variable length 73 tuples called TLVs (Type-Length-Value). 75 [IS-IS-TE] defines a set of new TLVs whose aims are to add more 76 information about links characteristics, increase the range of IS-IS 77 metrics and optimize the encoding of IS-IS prefixes. 79 This document defines a new sub-TLV named ��Link-attributes�� carried 80 within the extended IS reachability TLV (type 22) specified in [IS- 81 IS-TE]. 83 2. 84 Link-attributes sub-TLV format 86 The link-attribute sub-TLV is carried within the TLV 22 and has a 87 format identical to the sub-TLV format used by the Traffic 88 Engineering Extensions for IS-IS [IS-IS-TE]: 1 octet of sub-type, 1 89 octet of length of the value field of the sub-TLV followed by the 90 value field - 91 - in this case, a 16 bit flags field. 93 The Link-attribute sub-type is 19 (to be assigned by IANA) and has a 94 length of 2 octets. 96 This sub-TLV is OPTIONAL and MAY appear at most once for a single IS 97 neighbor. 99 The following bits are defined (values to be confirmed by IANA): 101 Local Protection Available (0x01). When set, this indicates that the 102 link is protected by means of some local protection mechanism (e.g 103 [FRR]). 105 Link excluded from local protection path (0x02). When set, this link 106 SHOULD not be included in any computation of a repair path by any 107 other router in the routing area. The triggers for setting up this 108 bit are out of the scope of this document. 110 Such link characteristics has several applications such as 111 constrained shortest path computation for a Traffic Engineering Label 112 Switched (TE LSP) path or the triggering of specific actions in the 113 context of IS-IS SPF computation. 115 Local maintenance required (0x04). When set, this indicates that the 116 link will be put out of service and will consequently be shortly 117 unavailable. The set of actions triggered by other nodes is out of 118 the scope of this document. An example of the usage of this bit is 119 provided in [GR-SHUT]. 121 3. 122 Interoperability with routers non supporting this capability 124 A router not supporting the link-attribute sub-TLV MUST just silently 125 ignore this sub-TLV. 127 Where the information in the link attributes sub-TLV is used to 128 affect the IS-IS SPF calculation, additional information indicating 129 which routers are using this information is required to insure such 130 usage does not result in loops or black holes. How this additional 131 information is conveyed is outside the scope of this document. 133 4. 134 Security considerations 136 No new security issues are raised in this document. 138 5. 139 Intellectual Property Considerations 141 The IETF takes no position regarding the validity or scope of any 142 intellectual property or other rights that might be claimed to 143 pertain to the implementation or use of the technology described in 144 this document or the extent to which any license under such rights 145 might or might not be available; neither does it represent that it 147 has made any effort to identify any such rights. Information on the 148 IETF's procedures with respect to rights in standards-track and 149 standards-related documentation can be found in BCP-11. Copies of 150 claims of rights made available for publication and any assurances of 151 licenses to be made available, or the result of an attempt made to 152 obtain a general license or permission for the use of such 153 proprietary rights by implementors or users of this specification can 154 be obtained from the IETF Secretariat. 156 The IETF invites any interested party to bring to its attention any 157 copyrights, patents or patent applications, or other proprietary 158 rights which may cover technology that may be required to practice 159 this standard. Please address the information to the IETF Executive 160 Director. 162 The IETF has been notified of intellectual property rights claimed in 163 regard to some or all of the specification contained in this 164 document. For more information consult the online list of claimed 165 rights. 167 6. 168 Acknowledgments 170 The authors would like to thank Mike Shand and Les Ginsberg for their 171 useful comments. 173 7. 174 Intellectual property considerations 176 The IETF takes no position regarding the validity or scope of any 177 Intellectual Property Rights or other rights that might be claimed to 178 pertain to the implementation or use of the technology described in 179 this document or the extent to which any license under such rights 180 might or might not be available; nor does it represent that it has 181 made any independent effort to identify any such rights. Information 182 on the procedures with respect to rights in RFC documents can be 183 found in BCP 78 and BCP 79. 185 Copies of IPR disclosures made to the IETF Secretariat and any 186 assurances of licenses to be made available, or the result of an 187 attempt made to obtain a general license or permission for the use of 188 such proprietary rights by implementers or users of this 189 specification can be obtained from the IETF on-line IPR repository at 190 http://www.ietf.org/ipr. 192 The IETF invites any interested party to bring to its attention any 193 copyrights, patents or patent applications, or other proprietary 194 rights that may cover technology that may be required to implement 195 this standard. Please address the information to the IETF at ietf- 196 ipr@ietf.org. 198 7.1 199 IPR Disclosure Acknowledgement 201 By submitting this Internet-Draft, I certify that any applicable 202 patent or other IPR claims of which I am aware have been disclosed, 203 and any of which I become aware will be disclosed, in accordance with 204 RFC 3668. 206 8. 207 References 209 Normative references 211 [RFC] Bradner, S., "Key words for use in RFCs to Indicate Requirement 212 Levels," RFC 2119. 214 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 215 Routeing Exchange Protocol for use in Conjunction with the Protocol 216 for Providing the Connectionless-mode Network Service (ISO 8473)", 217 ISO 10589. 219 [IS-IS-IP] Callon, R., RFC 1195, "Use of OSI IS-IS for routing in 220 TCP/IP and dual environments", RFC 1195, December 1990. 222 [IS-IS-TE] H. Smit, T. Li, ��IS-IS extensions for traffic 223 engineering��, RFC 3784. 225 Informative references 227 [FRR] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for LSP 228 Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, December 2003. 230 [GR-SHUT], Z. Ali et al, ��Graceful Shutdown in MPLS Traffic 231 Engineering Networks��, draft-ali-mpls-graceful-shutdown-00.txt, July 232 2005, work in progress. 234 9. 235 Author's Addresses 237 Jean-Philippe Vasseur 238 CISCO Systems, Inc. 239 300 Beaver Brook 240 Boxborough, MA 01719 241 USA 242 Email: jpv@cisco.com 244 Stefano Previdi 245 CISCO Systems, Inc. 246 Via Del Serafico 200 247 00142 - Roma 248 ITALY 249 Email: sprevidi@cisco.com 251 10. 252 Full Copyright Statement 254 "Copyright (C) The Internet Society (year). This document is subject 255 to the rights, licenses and restrictions contained in BCP 78, and 256 except as set forth therein, the authors retain all their rights." 258 "This document and the information contained herein are provided on 259 an 260 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 261 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 262 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 263 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 264 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 265 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."