idnits 2.17.1 draft-ietf-isis-caps-00.txt: -(281): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(288): 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 3978, Section 5.5 on line 359. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 245. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 252. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 258. ** 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? ** 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 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: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 2005) is 7040 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: 'IS-IS-TE' is mentioned on line 82, but not defined == Unused Reference: 'RFC' is defined on line 264, but no explicit reference was found in the text == Unused Reference: 'IS-IS' is defined on line 267, but no explicit reference was found in the text == Unused Reference: 'IS-IS-IP' is defined on line 272, but no explicit reference was found in the text == Unused Reference: 'ISIS-TE' is defined on line 275, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 3784 (ref. 'ISIS-TE') (Obsoleted by RFC 5305) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-te-p2mp-00 == Outdated reference: A later version (-04) exists of draft-ietf-mpls-p2mp-sig-requirement-00 Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 draft-ietf-isis-caps-00.txt January 2005 3 ISIS WG 4 Internet Draft Jean-Philippe Vasseur(Ed) 5 Cisco Systems, Inc. 6 Rahul Aggarwal(Ed) 7 Juniper Networks 8 Naiming Shen(Ed) 9 Redback Networks 11 Expires: July 2005 January 2005 13 IS-IS extensions for advertising router information 15 draft-ietf-isis-caps-00.txt 17 Status of this Memo 19 By submitting this Internet-Draft, I certify that any applicable 20 patent or IPR claims of which I am aware have been disclosed, and any 21 of which I become aware will be disclosed, in accordance with RFC 22 3668. 24 This document is an Internet-Draft and is in full conformance with 25 all provisions of Section 10 of RFC2026 [i]. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Abstract 44 This document defines a new optional IS-IS TLV named CAPABILITY, 45 formed of multiple sub-TLVs, which allows a router to announce its 46 capabilities within an IS-IS level or the entire routing domain. 48 Conventions used in this document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC-2119 [ii]. 54 Table of Contents 56 1. Introduction............................................2 57 2. IS-IS Router CAPABILITY TLV.............................3 58 3. Element of procedure....................................4 59 4. Interoperability with routers not supporting the 60 capability TLV..........................................5 61 5. Security considerations.................................5 62 6. Acknowledgment..........................................5 63 7. Intellectual Property Considerations....................5 64 8. References..............................................6 65 Normative references.......................................6 66 Informative references.....................................6 67 9. Author's Addresses......................................7 69 1. Introduction 71 There are several situations where it is useful for the IS-IS 72 routers to learn the capabilities of the other routers of their IS- 73 IS level, area or routing domain. Some applications are described 74 in [IS-IS-TE-CAP]. For the sake of illustration, two examples 75 related to MPLS Traffic Engineering are described here: 77 1. Mesh-group: the setting up of a mesh of TE LSPs requires some 78 significant configuration effort. [IS-IS-TE-CAP] proposes an auto- 79 discovery mechanism whereby every LSR of a mesh advertises its 80 mesh-group membership by means of IS-IS extensions. 82 2. Point to Multi-point TE LSP (P2MP LSP). A specific sub-TLV ([IS- 83 IS-TE]) allows an LSR to advertise its Point To Multipoint 84 capabilities ([P2MP] and [P2MP-REQS]). 86 The use of ISIS for Path Computation Element (PCE) discovery may also 87 be considered and will be discussed in the PCE WG. 89 The capabilities mentioned above require the specification of new 90 sub-TLVs carried within the CAPABILITY TLV defined in this document. 92 Note that the examples above are provided for the sake of 93 illustration. This document proposes a generic capability advertising 94 mechanism not limited to MPLS Traffic Engineering. 96 This document defines a new optional IS-IS TLV named CAPABILITY, 97 formed of multiple sub-TLVs, which allows a router to announce its 98 capabilities within an IS-IS level or the entire routing domain. The 99 applications mentioned above require the specification of new sub- 100 TLVs carried within the CAPABILITY TLV defined in this document. 102 Definition of these sub-TLVs is outside the scope of this document. 104 2. IS-IS Router CAPABILITY TLV 106 The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type, 107 1 octet specifying the TLV length, 1 octet of bit flags and a 108 variable length value field, starting with 4 octets of Router ID, 109 indicating the source of the TLV, and followed by 1 octet of flags. A 110 set of optional sub-TLVs may follow the flag field. 112 TYPE: 242 (To be assigned by IANA) 113 LENGTH: from 5 to 255 114 VALUE: 115 Router ID (4 octets) 116 Flags (1 octet) 117 Set of optional sub-TLVs (0-250 octets) 119 Flags 121 0 1 2 3 4 5 6 7 122 +-+-+-+-+-+-+-+-+ 123 | Reserved |D|S| 124 +-+-+-+-+-+-+-+-+ 126 Currently two bit flags are defined. 128 S bit (0x01): If the S bit is set(1), the IS-IS Router CAPABILITY TLV 129 MUST be flooded across the entire routing domain. If the S bit is not 130 set(0), the TLV MUST NOT be leaked between levels. This bit MUST NOT 131 be altered during the TLV leaking. 133 D bit (0x02): When the IS-IS Router CAPABILITY TLV is leaked from 134 level-2 to level-1, the D bit MUST be set. Otherwise this bit MUST be 135 clear. IS-IS Router capability TLVs with the D bit set MUST NOT be 136 leaked from level-1 to level-2. This is to prevent TLV looping. 138 The Router CAPABILITY TLV is OPTIONAL. As specified in section 3, 139 more than one Router CAPABILITY TLVs from the same source MAY be 140 present. 142 This document does not specify how an application may use the Router 143 Capability TLV and such specification is outside the scope of this 144 document. 146 3. Elements of procedure 148 When advertising capabilities with different flooding scopes, a 149 router MUST originate a minimum of two Router CAPABILITY TLVs, each 150 TLV carrying the set of sub-TLVs with the same flooding scope. For 151 instance, if a router advertises two sets of capabilities C1 and C2 152 with an area/level scope and routing domain scope respectively, C1 153 and C2 being specified by their respective sub-TLV(s), the router 154 MUST originate two Router CAPABILITY TLVs: 156 - One Router CAPABILITY TLV with the S flag cleared, carrying the 157 sub-TLV(s) relative to C1. This Router CAPABILITY TLV MUST NOT be 158 leaked into another level. 160 - One Router CAPABILITY TLV with the S flag set, carrying the sub- 161 TLV(s) relative to C2. This Router CAPABILITY TLV MUST be leaked 162 into other IS-IS levels. When the TLV is leaked from level-2 to 163 level-1, the D bit MUST be set in the level-1 LSP advertisement. 165 When leaking Capability TLVs downward from Level-2 into Level-1, if 166 the originator of the TLV is a Level-1 router in another area, it is 167 possible that multiple copies of the same TLV may be received from 168 multiple L2 routers in the originating area. To prevent a router from 169 leaking multiple copies of the same TLV, the router performing the 170 downward leaking MUST check for such duplication by comparing the 171 contents of the TLVs. 173 A system MUST NOT use a Capability TLV present in an LSP of a system 174 which is not currently reachable via Level-x paths, where "x" is the 175 level (1 or 2) in which the sending system advertised the TLV. This 176 requirement applies regardless of whether the sending system is the 177 originator of the Capabilities TLV or not. Note that leaking a 178 Capabilities TLV is one of the uses which is prohibited under these 179 conditions. 181 In IS-IS, the atomic unit of the update process is a TLV - or more 182 precisely in the case of TLVs which allow multiple entries to appear 183 in the value field (e.g. IS-neighbors) - an entry in the value field 184 of a TLV. If an update to an entry in a TLV is advertised in an LSP 185 fragment different from the LSP fragment associated with the old 186 advertisement, the possibility exists that other systems can 187 temporarily have either 0 copies of a particular advertisement or 2 188 copies of a particular advertisement, depending on the order in which 189 new copies of the LSP fragment which had the old advertisement and 190 the fragment which has the new advertisement arrive at other systems. 192 Wherever possible, an implementation SHOULD advertise the update to a 193 capabilities TLV in the same LSP fragment as the advertisement which 194 it replaces. Where this is not possible, the two affected LSP 195 fragments should be flooded as an atomic action. 197 Systems which receive an update to an existing capability TLV can 198 minimize the potential disruption associated with the update by 199 employing a holddown time prior to processing the update so as to 200 allow for the receipt of multiple LSP fragments associated with the 201 same update prior to beginning processing. 203 Where a receiving system has two copies of a capabilities TLV from 204 the same system which have different settings for a given attribute, 205 the procedure used to choose which copy shall be used is undefined. 207 4. Interoperability with routers not supporting the capability TLV. 209 Routers which do not support the Router CAPABILITY TLV MUST silently 210 ignore the TLV(s) and continue processing other TLVs in the same LSP. 211 Routers which do not support specific sub-TLVs carried within a 212 Router CAPABILITY TLV MUST silently ignore the unsupported sub-TLVs 213 and continue processing those sub-TLVs in the Router CAPABILITY TLV 214 which are supported. How partial support may impact the operation of 215 the capabilities advertised within the Router CAPABILITY TLV is 216 outside the scope of this document. 218 In order for Router CAPABILITY TLVs with domain-wide scope originated 219 by L1 Routers to be flooded across the entire domain at least one 220 L1/L2 Router in every area of the domain MUST support the Router 221 CAPABILITY TLV. 223 If leaking of the CAP TLV is required, the entire CAP TLV MUST be 224 leaked into another level even though it may contain some of the 225 unsupported sub-TLVs. 227 5. Security considerations 229 No new security issues are raised in this document. 231 6. Acknowledgments 233 The authors would like to thank Jean-Louis Le Roux, Paul Mabey and 234 Andrew Partan for their useful comments. 236 7. Intellectual Property Considerations 238 The IETF takes no position regarding the validity or scope of any 239 Intellectual Property Rights or other rights that might be claimed to 240 pertain to the implementation or use of the technology described in 241 this document or the extent to which any license under such rights 242 might or might not be available; nor does it represent that it has 243 made any independent effort to identify any such rights. Information 244 on the procedures with respect to rights in RFC documents can be 245 found in BCP 78 and BCP 79. 247 Copies of IPR disclosures made to the IETF Secretariat and any 248 assurances of licenses to be made available, or the result of an 249 attempt made to obtain a general license or permission for the use of 250 such proprietary rights by implementers or users of this 251 specification can be obtained from the IETF on-line IPR repository at 252 http://www.ietf.org/ipr. 254 The IETF invites any interested party to bring to its attention any 255 copyrights, patents or patent applications, or other proprietary 256 rights that may cover technology that may be required to implement 257 this standard. Please address the information to the IETF at ietf- 258 ipr@ietf.org. 260 8. References 262 Normative references 264 [RFC] Bradner, S., "Key words for use in RFCs to Indicate Requirement 265 Levels," RFC 2119. 267 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 268 Routeing Exchange Protocol for use in Conjunction with the Protocol 269 for Providing the Connectionless-mode Network Service (ISO 8473)", 270 ISO 10589. 272 [IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 273 dual environments", RFC 1195, December 1990. 275 [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 276 Engineering", RFC 3784, June 2004. 278 Informative references 280 [IS-IS-TE-CAP] JP Vasseur, S. Previdi, Paul Mabey and JL. Le Roux, 281 �IS-IS MPLS Traffic Engineering capabilities�, draft-vasseur-isis-te- 282 caps-00.txt, work in progress. 284 [P2MP] R. Aggarwal,D. Papadimitriou,S. Yasukawa, et. al. "Extensions 285 to RSVP-TE for Point To Multipoint TE LSPs", draft-ietf-mpls-rsvp-te- 286 p2mp-00.txt, work in progress. 288 [P2MP-REQS] S. Yasukawa et al. � Requirements for point to multipoint 289 extension to RSVP �, draft-ietf-mpls-p2mp-sig-requirement-00.txt, 290 work in progress. 292 9. Author's Addresses 294 Jean-Philippe Vasseur 295 CISCO Systems, Inc. 296 300 Beaver Brook 297 Boxborough, MA 01719 298 USA 299 Email: jpv@cisco.com 301 Stefano Previdi 302 CISCO Systems, Inc. 303 Via Del Serafico 200 304 00142 - Roma 305 ITALY 306 Email: sprevidi@cisco.com 308 Mike Shand 309 Cisco Systems 310 250 Longwater Avenue, 311 Reading, 312 Berkshire, 313 RG2 6GB 314 UK 315 Email: mshand@cisco.com 317 Les Ginsberg 318 Cisco Systems 319 510 McCarthy Blvd. 320 Milpitas, Ca. 95035 USA 321 Email: ginsberg@cisco.com 323 Acee Lindem 324 Cisco Systems 325 7025 Kit Creek Road 326 Research Triangle Park, NC 27709 327 USA 328 e-mail: acee@cisco.com 330 Naiming Shen 331 Cisco Systems 332 225 West Tasman Drive 333 San Jose, CA 95134 334 USA 335 e-mail: naiming@cisco.com 337 Rahul Aggarwal 338 Juniper Networks 339 1194 N. Mathilda Avenue 340 San Jose, CA 94089 341 USA 342 e-mail: rahul@juniper.net 344 Scott Shaffer 345 e-mail: sshaffer@bridgeport-networks.com 347 Full Copyright Statement 349 Copyright (C) The Internet Society (2005). This document is subject 350 to the rights, licenses and restrictions contained in BCP 78, and 351 except as set forth therein, the authors retain all their rights. 353 This document and the information contained herein are provided on an 354 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 355 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 356 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 357 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 358 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 359 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.