idnits 2.17.1 draft-ietf-isis-link-attr-02.txt: 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 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 200. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 129. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 136. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 142. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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. -- 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 (October 2006) is 6403 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. 'IS-IS' ** Obsolete normative reference: RFC 3784 (ref. 'IS-IS-TE') (Obsoleted by RFC 5305) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 draft-ietf-isis-link-attr-02.txt October 2006 2 ISIS WG 3 Internet Draft Jean-Philippe Vasseur 4 Stefano Previdi 5 Cisco Systems 6 Document: draft-ietf-isis-link-attr-02.txt 7 Expires: April 2007 October 2006 9 Definition of an IS-IS Link Attribute sub-TLV 11 draft-ietf-isis-link-attr-02.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document defines a sub-TLV called "Link-attributes" carried 40 within the TLV 22 and used to flood some link characteristics. 42 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 [RFC]. 48 Table of contents 50 1. Introduction ..................................................2 51 2. Link-attributes sub-TLV format ................................2 52 3. Interoperability with routers non supporting this capability ..3 53 4. Security considerations .......................................3 54 5. IANA considerations ...........................................3 55 6. Intellectual Property Considerations ..........................3 56 7. Acknowledgments ...............................................4 57 8. References ....................................................4 58 8.1 Normative references .........................................4 59 8.2 Informative references .......................................4 60 9. Authors' Addresses ............................................4 61 Full Copyright Statement .........................................5 63 1. Introduction 65 [IS-IS] specifies the IS-IS protocol (ISO 10589) with extensions to 66 support IPv4 in [IS-IS-IP]. A router advertises one or several Link 67 State Protocol data units which are composed of variable length 68 tuples called TLVs (Type-Length-Value). 70 [IS-IS-TE] defines a set of new TLVs whose aims are to add more 71 information about links characteristics, increase the range of IS-IS 72 metrics and optimize the encoding of IS-IS prefixes. 74 This document defines a new sub-TLV named "Link-attributes" carried 75 within the extended IS reachability TLV (type 22) specified in 76 [IS-IS-TE]. 78 2. Link-attributes sub-TLV format 80 The link-attribute sub-TLV is carried within the TLV 22 and has a 81 format identical to the sub-TLV format used by the Traffic 82 Engineering Extensions for IS-IS [IS-IS-TE]: 1 octet of sub-type, 1 83 octet of length of the value field of the sub-TLV followed by the 84 value field, in this case, a 16 bit flags field. 86 The Link-attribute sub-type is 19 (to be assigned by IANA) and has a 87 length of 2 octets. 89 This sub-TLV is OPTIONAL and MAY appear at most once for a single IS 90 neighbor. If a received LSP contains more than one Link-Attribute 91 Sub-TLV, an implementation MAY decide to consider only the first 92 encountered instance. 94 The following bits are defined: 96 Local Protection Available (0x01). When set, this indicates that the 97 link is protected by means of some local protection mechanism (e.g 98 [FRR]). 100 Link excluded from local protection path (0x02). When set, this link 101 SHOULD not be included in any computation of a repair path by any 102 other router in the routing area. The triggers for setting up this 103 bit are out of the scope of this document. 105 3. Interoperability with routers non supporting this capability 107 A router not supporting the link-attribute sub-TLV MUST just 108 silently ignore this sub-TLV. 110 4. Security considerations 112 No new security issues are raised in this document. 114 5. IANA considerations 116 IANA will assign a new codepoint for the link-attribute sub-TLV 117 defined in this document and carried within TLV 22. Suggested value 118 is 19 (to be assigned by IANA). 120 6. Intellectual Property Considerations 122 The IETF takes no position regarding the validity or scope of any 123 Intellectual Property Rights or other rights that might be claimed 124 to pertain to the implementation or use of the technology described 125 in this document or the extent to which any license under such 126 rights might or might not be available; nor does it represent that 127 it has made any independent effort to identify any such rights. 128 Information on the procedures with respect to rights in RFC 129 documents can be found in BCP 78 and BCP 79. 131 Copies of IPR disclosures made to the IETF Secretariat and any 132 assurances of licenses to be made available, or the result of an 133 attempt made to obtain a general license or permission for the use 134 of such proprietary rights by implementers or users of this 135 specification can be obtained from the IETF on-line IPR repository 136 at http://www.ietf.org/ipr. 138 The IETF invites any interested party to bring to its attention any 139 copyrights, patents or patent applications, or other proprietary 140 rights that may cover technology that may be required to implement 141 this standard. Please address the information to the IETF at 142 ietf-ipr@ietf.org. 144 7. Acknowledgments 146 The authors would like to thank Mike Shand and Les Ginsberg for 147 their useful comments. 149 8. References 151 8.1 Normative references 153 [RFC] Bradner, S., "Key words for use in RFCs to Indicate 154 Requirement Levels," RFC 2119. 156 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 157 Routeing Exchange Protocol for use in Conjunction with the Protocol 158 for Providing the Connectionless-mode Network Service (ISO 8473)", 159 ISO 10589. 161 [IS-IS-IP] Callon, R., RFC 1195, "Use of OSI IS-IS for routing in 162 TCP/IP and dual environments", RFC 1195, December 1990. 164 [IS-IS-TE] H. Smit, T. Li, "IS-IS extensions for traffic 165 engineering", RFC 3784. 167 8.2 Informative references 169 [FRR] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for LSP 170 Tunnels", RFC 4090, May 2005. 172 9. Authors' Addresses 174 Jean-Philippe Vasseur 175 Cisco Systems, Inc. 176 1414 Massachusetts Avenue 177 Boxborough, MA 01719 178 USA 179 Email: jpv@cisco.com 181 Stefano Previdi 182 Cisco Systems, Inc. 183 Via Del Serafico 200 184 00142 - Roma 185 ITALY 186 Email: sprevidi@cisco.com 188 Full Copyright Statement 190 Copyright (C) The Internet Society (2006). This document is subject 191 to the rights, licenses and restrictions contained in BCP 78, and 192 except as set forth therein, the authors retain all their rights. 194 This document and the information contained herein are provided on 195 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 196 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 197 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 198 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 199 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 200 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.