idnits 2.17.1 draft-ietf-isis-caps-03.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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 276. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 282. ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 110 lines == 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 : ---------------------------------------------------------------------------- No issues found here. 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 (May 2005) is 6914 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 288, but no explicit reference was found in the text == Unused Reference: 'IS-IS' is defined on line 291, but no explicit reference was found in the text == Unused Reference: 'IS-IS-IP' is defined on line 296, but no explicit reference was found in the text == Unused Reference: 'ISIS-TE' is defined on line 299, 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 (-02) exists of draft-vasseur-ccamp-automesh-00 == Outdated reference: A later version (-01) exists of draft-vasseur-ccamp-te-node-cap-00 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-te-p2mp-01 == Outdated reference: A later version (-04) exists of draft-ietf-mpls-p2mp-sig-requirement-01 Summary: 4 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ISIS WG 3 Internet Draft Jean-Philippe Vasseur(Ed) 4 Naiming Shen (Ed) 5 Cisco Systems, Inc. 6 Rahul Aggarwal(Ed) 7 Juniper Networks 9 Proposed status: Standard 10 Expires: November 2005 May 2005 12 IS-IS extensions for advertising router information 14 draft-ietf-isis-caps-03.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 This document defines a new optional IS-IS TLV named CAPABILITY, 41 formed of multiple sub-TLVs, which allows a router to announce its 42 capabilities within an IS-IS level or the entire routing domain. 44 Conventions used in this document 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC-2119 [i]. 50 Table of Contents 52 1. Introduction...................................................2 53 2. IS-IS Router CAPABILITY TLV....................................3 54 3. Element of procedure...........................................3 55 4. Interoperability with routers not supporting the capability TLV.5 56 5. Security considerations........................................5 57 6. Acknowledgment.................................................6 58 7. Intellectual Property Considerations...........................6 59 8. References.....................................................6 60 Normative references..............................................6 61 Informative references............................................7 62 9. Author's Addresses.............................................7 64 1. Introduction 66 There are several situations where it is useful for the IS-IS 67 routers to learn the capabilities of the other routers of their IS- 68 IS level, area or routing domain. For the sake of illustration, two 69 examples related to MPLS Traffic Engineering are described here: 71 1. Mesh-group: the setting up of a mesh of TE LSPs requires some 72 significant configuration effort. [AUTOMESH] proposes an auto- 73 discovery mechanism whereby every LSR of a mesh advertises its 74 mesh-group membership by means of IS-IS extensions. 76 2. Point to Multi-point TE LSP (P2MP LSP). A specific sub-TLV ([TE- 77 NODE-CAP]) allows an LSR to advertise its Point To Multipoint 78 capabilities ([P2MP] and [P2MP-REQS]). 80 The use of IS-IS for Path Computation Element (PCE) discovery may 81 also be considered and will be discussed in the PCE WG. 83 The capabilities mentioned above require the specification of new 84 sub-TLVs carried within the CAPABILITY TLV defined in this document. 86 Note that the examples above are provided for the sake of 87 illustration. This document proposes a generic capability advertising 88 mechanism not limited to MPLS Traffic Engineering. 90 This document defines a new optional IS-IS TLV named CAPABILITY, 91 formed of multiple sub-TLVs, which allows a router to announce its 92 capabilities within an IS-IS level or the entire routing domain. The 93 applications mentioned above require the specification of new sub- 94 TLVs carried within the CAPABILITY TLV defined in this document. 96 Definition of these sub-TLVs is outside the scope of this document. 98 2. IS-IS Router CAPABILITY TLV 100 The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type, 101 1 octet specifying the number of bytes in the value field, and a 102 variable length value field, starting with 4 octets of Router ID, 103 indicating the source of the TLV, and followed by 1 octet of flags. 105 A set of optional sub-TLVs may follow the flag field. 107 TYPE: 242 (To be assigned by IANA) 108 LENGTH: from 5 to 255 109 VALUE: 110 Router ID (4 octets) 111 Flags (1 octet) 112 Set of optional sub-TLVs (0-250 octets) 114 Flags 116 0 1 2 3 4 5 6 7 117 +-+-+-+-+-+-+-+-+ 118 | Reserved |D|S| 119 +-+-+-+-+-+-+-+-+ 121 Currently two bit flags are defined. 123 S bit (0x01): If the S bit is set(1), the IS-IS Router CAPABILITY TLV 124 MUST be flooded across the entire routing domain. If the S bit is not 125 set(0), the TLV MUST NOT be leaked between levels. This bit MUST NOT 126 be altered during the TLV leaking. 128 D bit (0x02): When the IS-IS Router CAPABILITY TLV is leaked from 129 level-2 to level-1, the D bit MUST be set. Otherwise this bit MUST be 130 clear. IS-IS Router capability TLVs with the D bit set MUST NOT be 131 leaked from level-1 to level-2. This is to prevent TLV looping. 133 The Router CAPABILITY TLV is OPTIONAL. As specified in section 3, 134 more than one Router CAPABILITY TLVs from the same source MAY be 135 present. 137 This document does not specify how an application may use the Router 138 Capability TLV and such specification is outside the scope of this 139 document. 141 3. Elements of procedure 143 A router which generates a capability TLV MUST also generate a 144 Traffic Engineering Router ID TLV (134) at each level for which it 145 generates a router capability TLV. 147 When advertising capabilities with different flooding scopes, a 148 router MUST originate a minimum of two Router CAPABILITY TLVs, each 149 TLV carrying the set of sub-TLVs with the same flooding scope. For 150 instance, if a router advertises two sets of capabilities C1 and C2 151 with an area/level scope and routing domain scope respectively, C1 152 and C2 being specified by their respective sub-TLV(s), the router 153 MUST originate two Router CAPABILITY TLVs: 155 - One Router CAPABILITY TLV with the S flag cleared, carrying the 156 sub-TLV(s) relative to C1. This Router CAPABILITY TLV MUST NOT be 157 leaked into another level. 159 - One Router CAPABILITY TLV with the S flag set, carrying the sub- 160 TLV(s) relative to C2. This Router CAPABILITY TLV MUST be leaked 161 into other IS-IS levels. When the TLV is leaked from level-2 to 162 level-1, the D bit MUST be set in the level-1 LSP advertisement. 164 When leaking Capability TLVs downward from Level-2 into Level-1, if 165 the originator of the TLV is a Level-1 router in another area, it is 166 possible that multiple copies of the same TLV may be received from 167 multiple L2 routers in the originating area. To prevent a router from 168 leaking multiple copies of the same TLV, the router performing the 169 downward leaking MUST check for such duplication by comparing the 170 contents of the TLVs. 172 In order to prevent the use of stale capabilities information A 173 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 Example: If Level-1 router A generates a Capability TLV and floods 182 it to two L1/L2 routers S and T, they will flood it into the Level-2 183 domain. Now suppose the Level-1 area partitions, such that A and S 184 are in one partition and T is in another. IP routing will still 185 continue to work, but if A now issues a revised version of the CAP 186 TLV, or decides to stop advertising it, S will follow suit, but T 187 will continue to advertise the old version until the LSP times out. 189 Routers in other areas have to choose whether to trust T's copy of 190 A's capabilities or S's copy of A's information and they have no 191 reliable way to choose. By making sure that T stops leaking A's 192 information, this removes the possibility that other routers will 193 use stale information from A. 195 In IS-IS, the atomic unit of the update process is a TLV - or more 196 precisely in the case of TLVs which allow multiple entries to appear 197 in the value field (e.g. IS-neighbors) - an entry in the value field 198 of a TLV. If an update to an entry in a TLV is advertised in an LSP 199 fragment different from the LSP fragment associated with the old 200 advertisement, the possibility exists that other systems can 201 temporarily have either 0 copies of a particular advertisement or 2 202 copies of a particular advertisement, depending on the order in which 203 new copies of the LSP fragment which had the old advertisement and 204 the fragment which has the new advertisement arrive at other systems. 206 Wherever possible, an implementation SHOULD advertise the update to a 207 capabilities TLV in the same LSP fragment as the advertisement which 208 it replaces. Where this is not possible, the two affected LSP 209 fragments should be flooded as an atomic action. 211 Systems which receive an update to an existing capability TLV can 212 minimize the potential disruption associated with the update by 213 employing a holddown time prior to processing the update so as to 214 allow for the receipt of multiple LSP fragments associated with the 215 same update prior to beginning processing. 217 Where a receiving system has two copies of a capabilities TLV from 218 the same system which have different settings for a given attribute, 219 the procedure used to choose which copy shall be used is undefined. 221 4. Interoperability with routers not supporting the capability TLV. 223 Routers which do not support the Router CAPABILITY TLV MUST silently 224 ignore the TLV(s) and continue processing other TLVs in the same LSP. 225 Routers which do not support specific sub-TLVs carried within a 226 Router CAPABILITY TLV MUST silently ignore the unsupported sub-TLVs 227 and continue processing those sub-TLVs in the Router CAPABILITY TLV 228 which are supported. How partial support may impact the operation of 229 the capabilities advertised within the Router CAPABILITY TLV is 230 outside the scope of this document. 232 In order for Router CAPABILITY TLVs with domain-wide scope originated 233 by L1 Routers to be flooded across the entire domain at least one 234 L1/L2 Router in every area of the domain MUST support the Router 235 CAPABILITY TLV. 237 If leaking of the CAP TLV is required, the entire CAP TLV MUST be 238 leaked into another level even though it may contain some of the 239 unsupported sub-TLVs. 241 5. Security considerations 243 Any new security issues raised by the procedures in this document 244 depend upon the opportunity for LSPs to be snooped, the 245 ease/difficulty of which has not been altered. As the LSPs may now 246 contain additional information regarding router capabilities, this 247 new information would also become available. 249 6. IANA considerations 251 IANA will assign a new IS-IS TLV code-point for the newly defined IS- 252 IS TLV type named the IS-IS Router CAPABILITY TLV and defined in this 253 document. Suggested value is 242 (to be assigned by IANA). 255 7. Acknowledgment 257 The authors would like to thank Jean-Louis Le Roux, Paul Mabey, 258 Andrew Partan and Adrian Farrel for their useful comments. 260 8. Intellectual Property Considerations 262 The IETF takes no position regarding the validity or scope of any 263 Intellectual Property Rights or other rights that might be claimed to 264 pertain to the implementation or use of the technology described in 265 this document or the extent to which any license under such rights 266 might or might not be available; nor does it represent that it has 267 made any independent effort to identify any such rights. Information 268 on the procedures with respect to rights in RFC documents can be 269 found in BCP 78 and BCP 79. 271 Copies of IPR disclosures made to the IETF Secretariat and any 272 assurances of licenses to be made available, or the result of an 273 attempt made to obtain a general license or permission for the use of 274 such proprietary rights by implementers or users of this 275 specification can be obtained from the IETF on-line IPR repository at 276 http://www.ietf.org/ipr. 278 The IETF invites any interested party to bring to its attention any 279 copyrights, patents or patent applications, or other proprietary 280 rights that may cover technology that may be required to implement 281 this standard. Please address the information to the IETF at ietf- 282 ipr@ietf.org. 284 9. References 286 9.1 Normative references 288 [RFC] Bradner, S., "Key words for use in RFCs to Indicate Requirement 289 Levels," RFC 2119. 291 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 292 Routeing Exchange Protocol for use in Conjunction with the Protocol 293 for Providing the Connectionless-mode Network Service (ISO 8473)", 294 ISO 10589. 296 [IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 297 dual environments", RFC 1195, December 1990. 299 [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 300 Engineering", RFC 3784, June 2004. 302 9.2 Informative references 304 [AUTOMESH] JP Vasseur, JL. Le Roux et al, "Routing extensions for 305 discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic 306 Engineering (TE) mesh membership", draft-vasseur-ccamp-automesh- 307 00.txt, Work in progress. 309 [TE-NODE-CAP] JP Vasseur, JL. Le Roux et al, "Routing extensions for 310 discovery of Traffic Engineering Node Capabilities", draft-vasseur- 311 ccamp-te-node-cap-00.txt, Work in progress. 313 [P2MP] R. Aggarwal,D. Papadimitriou,S. Yasukawa, et. al. "Extensions 314 to RSVP-TE for Point To Multipoint TE LSPs", draft-ietf-mpls-rsvp-te- 315 p2mp-01.txt, work in progress. 317 [P2MP-REQS] S. Yasukawa et al. "Requirements for point to multipoint 318 extension to RSVP", draft-ietf-mpls-p2mp-sig-requirement-01.txt, work 319 in progress. 321 10. Authors' Addresses 323 Jean-Philippe Vasseur 324 CISCO Systems, Inc. 325 300 Beaver Brook 326 Boxborough, MA 01719 327 USA 328 Email: jpv@cisco.com 330 Stefano Previdi 331 CISCO Systems, Inc. 332 Via Del Serafico 200 333 00142 - Roma 334 ITALY 335 Email: sprevidi@cisco.com 337 Mike Shand 338 Cisco Systems 339 250 Longwater Avenue, 340 Reading, 341 Berkshire, 342 RG2 6GB 343 UK 344 Email: mshand@cisco.com 345 Les Ginsberg 346 Cisco Systems 347 510 McCarthy Blvd. 348 Milpitas, Ca. 95035 USA 349 Email: ginsberg@cisco.com 351 Acee Lindem 352 Cisco Systems 353 7025 Kit Creek Road 354 Research Triangle Park, NC 27709 355 USA 356 e-mail: acee@cisco.com 358 Naiming Shen 359 Cisco Systems 360 225 West Tasman Drive 361 San Jose, CA 95134 362 USA 363 e-mail: naiming@cisco.com 365 Rahul Aggarwal 366 Juniper Networks 367 1194 N. Mathilda Avenue 368 San Jose, CA 94089 369 USA 370 e-mail: rahul@juniper.net 372 Scott Shaffer 373 e-mail: sshaffer@bridgeport-networks.com 375 Full Copyright Statement 377 Copyright (C) The Internet Society (2005). This document is subject 378 to the rights, licenses and restrictions contained in BCP 78, and 379 except as set forth therein, the authors retain all their rights. 381 This document and the information contained herein are provided on an 382 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 383 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 384 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 385 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 386 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 387 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.