idnits 2.17.1 draft-ietf-isis-caps-07.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 273. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 280. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 286. 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 IETF Trust 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 (February 2007) is 6280 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: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jean-Philippe Vasseur(Ed) 3 Internet Draft Naiming Shen (Ed) 4 Proposed status: Standard Cisco Systems, Inc. 5 Expires: August 2007 Rahul Aggarwal(Ed) 6 Juniper Networks 8 February 2007 10 IS-IS Extensions for Advertising Router Information 12 draft-ietf-isis-caps-07.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 15, 2007. 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 [RFC-2119]. 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............................................6 62 9. Author's Addresses.............................................7 64 1. Introduction 66 There are several situations where it is useful for the IS-IS 67 [IS-IS, IS-IS-IP] routers to learn the capabilities of the other 68 routers of their IS-IS level, area or routing domain. For the sake 69 of illustration, two examples related to MPLS Traffic Engineering 70 are described here: 72 1. Mesh-group: the setting up of a mesh of TE LSPs [IS-IS-TE] 73 requires some significant configuration effort. [AUTOMESH] 74 proposes an auto-discovery mechanism whereby every LSR of a mesh 75 advertises its mesh-group membership by means of IS-IS extensions. 77 2. Point to Multi-point TE LSP (P2MP LSP). A specific sub-TLV ([TE- 78 NODE-CAP]) allows an LSR to advertise its Point To Multipoint 79 capabilities ([P2MP] and [P2MP-REQS]). 81 3. Inter-area traffic engineering: Advertisement of the IPv4 82 and/or the IPv6 Traffic Engineering Router IDs. 84 The use of IS-IS for Path Computation Element (PCE) discovery may 85 also be considered and will be discussed in the PCE WG. 87 The capabilities mentioned above require the specification of new 88 sub-TLVs carried within the CAPABILITY TLV defined in this document. 90 Note that the examples above are provided for the sake of 91 illustration. This document proposes a generic capability advertising 92 mechanism not limited to MPLS Traffic Engineering. 94 This document defines a new optional IS-IS TLV named CAPABILITY, 95 formed of multiple sub-TLVs, which allows a router to announce its 96 capabilities within an IS-IS level or the entire routing domain. The 97 applications mentioned above require the specification of new sub- 98 TLVs carried within the CAPABILITY TLV defined in this document. 100 Definition of these sub-TLVs is outside the scope of this document. 102 2. IS-IS Router CAPABILITY TLV 104 The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type, 105 1 octet specifying the number of bytes in the value field, and a 106 variable length value field, starting with 4 octets of Router ID, 107 indicating the source of the TLV, and followed by 1 octet of flags. 109 A set of optional sub-TLVs may follow the flag field. Sub-TLVs are 110 formatted as described in RFC 3784 [IS-IS-TE]. 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 A router which generates a CAPABILITY TLV MUST have a Router ID 149 which is a 32 bit number. The ID MUST be unique within the IS-IS 150 area. If the router generates any capability TLVs with domain 151 flooding scope then the ID MUST also be unique within the IS-IS 152 routing domain. 154 When advertising capabilities with different flooding scopes, a 155 router MUST originate a minimum of two Router CAPABILITY TLVs, each 156 TLV carrying the set of sub-TLVs with the same flooding scope. For 157 instance, if a router advertises two sets of capabilities C1 and C2 158 with an area/level scope and routing domain scope respectively, C1 159 and C2 being specified by their respective sub-TLV(s), the router 160 will originate two Router CAPABILITY TLVs: 162 - One Router CAPABILITY TLV with the S flag cleared, carrying the 163 sub-TLV(s) relative to C1. This Router CAPABILITY TLV will not be 164 leaked into another level. 166 - One Router CAPABILITY TLV with the S flag set, carrying the sub- 167 TLV(s) relative to C2. This Router CAPABILITY TLV will be leaked 168 into other IS-IS levels. When the TLV is leaked from level-2 to 169 level-1, the D bit will be set in the level-1 LSP advertisement. 171 In order to prevent the use of stale capabilities information A 172 system MUST NOT use a Capability TLV present in an LSP of a system 173 which is not currently reachable via Level-x paths, where "x" is the 174 level (1 or 2) in which the sending system advertised the TLV. This 175 requirement applies regardless of whether the sending system is the 176 originator of the Capabilities TLV or not. Note that leaking a 177 Capabilities TLV is one of the uses which is prohibited under these 178 conditions. 180 Example: If Level-1 router A generates a Capability TLV and floods 181 it to two L1/L2 routers S and T, they will flood it into the Level-2 182 domain. Now suppose the Level-1 area partitions, such that A and S 183 are in one partition and T is in another. IP routing will still 184 continue to work, but if A now issues a revised version of the CAP 185 TLV, or decides to stop advertising it, S will follow suit, but T 186 will continue to advertise the old version until the LSP times out. 188 Routers in other areas have to choose whether to trust T's copy of 189 A's capabilities or S's copy of A's information and they have no 190 reliable way to choose. By making sure that T stops leaking A's 191 information, this removes the possibility that other routers will 192 use stale information from A. 194 In IS-IS, the atomic unit of the update process is a TLV - or more 195 precisely in the case of TLVs which allow multiple entries to appear 196 in the value field (e.g. IS-neighbors) - an entry in the value field 197 of a TLV. If an update to an entry in a TLV is advertised in an LSP 198 fragment different from the LSP fragment associated with the old 199 advertisement, the possibility exists that other systems can 200 temporarily have either 0 copies of a particular advertisement or 2 201 copies of a particular advertisement, depending on the order in which 202 new copies of the LSP fragment which had the old advertisement and 203 the fragment which has the new advertisement arrive at other systems. 205 Wherever possible, an implementation SHOULD advertise the update to a 206 capabilities TLV in the same LSP fragment as the advertisement which 207 it replaces. Where this is not possible, the two affected LSP 208 fragments should be flooded as an atomic action. 210 Systems which receive an update to an existing capability TLV can 211 minimize the potential disruption associated with the update by 212 employing a holddown time prior to processing the update so as to 213 allow for the receipt of multiple LSP fragments associated with the 214 same update prior to beginning processing. 216 Where a receiving system has two copies of a capabilities TLV from 217 the same system which have different settings for a given attribute, 218 the procedure used to choose which copy shall be used is undefined. 220 4. Interoperability with routers not supporting the capability TLV. 222 Routers which do not support the Router CAPABILITY TLV MUST silently 223 ignore the TLV(s) and continue processing other TLVs in the same LSP. 224 Routers which do not support specific sub-TLVs carried within a 225 Router CAPABILITY TLV MUST silently ignore the unsupported sub-TLVs 226 and continue processing those sub-TLVs in the Router CAPABILITY TLV 227 which are supported. How partial support may impact the operation of 228 the capabilities advertised within the Router CAPABILITY TLV is 229 outside the scope of this document. 231 In order for Router CAPABILITY TLVs with domain-wide scope originated 232 by L1 Routers to be flooded across the entire domain at least one 233 L1/L2 Router in every area of the domain MUST support the Router 234 CAPABILITY TLV. 236 If leaking of the CAP TLV is required, the entire CAP TLV MUST be 237 leaked into another level even though it may contain some of the 238 unsupported sub-TLVs. 240 5. Security considerations 242 Any new security issues raised by the procedures in this document 243 depend upon the opportunity for LSPs to be snooped and modified, 244 the ease/difficulty of which has not been altered. As the LSPs may 245 now contain additional information regarding router capabilities, 246 this new information would also become available to an attacker. 247 Specifications based on this mechanism need to describe the 248 security considerations around the disclosure and modification 249 of their information. Note that an integrity mechanism, such as 250 one defined in RFC3567 or draft-ietf-isis-hmac-sha, should be 251 applied if there is high risk resulting from modification of 252 capability information. 254 6. IANA considerations 255 IANA will assign a new IS-IS TLV code-point for the newly defined IS- 256 IS TLV type named the IS-IS Router CAPABILITY TLV and defined in this 257 document. Suggested value is 242 (to be assigned by IANA). 259 7. Acknowledgment 261 The authors would like to thank Jean-Louis Le Roux, Paul Mabey, 262 Andrew Partan and Adrian Farrel for their useful comments. 264 8. Intellectual Property Considerations 266 The IETF takes no position regarding the validity or scope of any 267 Intellectual Property Rights or other rights that might be claimed to 268 pertain to the implementation or use of the technology described in 269 this document or the extent to which any license under such rights 270 might or might not be available; nor does it represent that it has 271 made any independent effort to identify any such rights. Information 272 on the procedures with respect to rights in RFC documents can be 273 found in BCP 78 and BCP 79. 275 Copies of IPR disclosures made to the IETF Secretariat and any 276 assurances of licenses to be made available, or the result of an 277 attempt made to obtain a general license or permission for the use of 278 such proprietary rights by implementers or users of this 279 specification can be obtained from the IETF on-line IPR repository at 280 http://www.ietf.org/ipr. 282 The IETF invites any interested party to bring to its attention any 283 copyrights, patents or patent applications, or other proprietary 284 rights that may cover technology that may be required to implement 285 this standard. Please address the information to the IETF at ietf- 286 ipr@ietf.org. 288 9. References 290 9.1 Normative references 292 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels," RFC 2119. 295 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 296 Routeing Exchange Protocol for use in Conjunction with the 297 Protocol for Providing the Connectionless-mode Network Service 298 (ISO 8473)", ISO 10589. 300 [IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 301 dual environments", RFC 1195, December 1990. 303 [IS-IS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 304 Engineering", RFC 3784, June 2004. 306 9.2 Informative references 308 [AUTOMESH] JP Vasseur, JL. Le Roux et al, "Routing extensions for 309 discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic 310 Engineering (TE) mesh membership", draft-ietf-ccamp-automesh, work in 311 progress. 313 [TE-NODE-CAP] JP Vasseur, JL. Le Roux et al, "Routing extensions for 314 discovery of Traffic Engineering Node Capabilities", draft-ietf- 315 ccamp-te-node-cap, work in progress. 317 [P2MP] R. Aggarwal,D. Papadimitriou,S. Yasukawa, et. al. "Extensions 318 to RSVP-TE for Point To Multipoint TE LSPs", draft-ietf-mpls-rsvp-te- 319 p2mp, work in progress. 321 [P2MP-REQS] S. Yasukawa et al. "Requirements for point to multipoint 322 extension to RSVP", draft-ietf-mpls-p2mp-sig-requirement, work in 323 progress. 325 10. Authors' Addresses 327 Jean-Philippe Vasseur 328 CISCO Systems, Inc. 329 1414 Massachusetts Avenue 330 Boxborough, MA 01719 331 USA 332 Email: jpv@cisco.com 334 Stefano Previdi 335 CISCO Systems, Inc. 336 Via Del Serafico 200 337 00142 - Roma 338 ITALY 339 Email: sprevidi@cisco.com 341 Mike Shand 342 Cisco Systems 343 250 Longwater Avenue, 344 Reading, 345 Berkshire, 346 RG2 6GB 347 UK 348 Email: mshand@cisco.com 350 Les Ginsberg 351 Cisco Systems 352 510 McCarthy Blvd. 353 Milpitas, Ca. 95035 USA 354 Email: ginsberg@cisco.com 355 Acee Lindem 356 Redback Networks 357 102 Carric Bend Court 358 Cary, NC 27519 359 USA 360 e-mail: acee@redback.com 362 Naiming Shen 363 Cisco Systems 364 225 West Tasman Drive 365 San Jose, CA 95134 366 USA 367 e-mail: naiming@cisco.com 369 Rahul Aggarwal 370 Juniper Networks 371 1194 N. Mathilda Avenue 372 San Jose, CA 94089 373 USA 374 e-mail: rahul@juniper.net 376 Scott Shaffer 377 e-mail: sshaffer@bridgeport-networks.com 379 Full Copyright Statement 381 Copyright (C) The IETF Trust (2007). This document is subject to the 382 rights, licenses and restrictions contained in BCP 78, and except as 383 set forth therein, the authors retain all their rights. 385 This document and the information contained herein are provided 386 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 387 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 388 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 389 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 390 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 391 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 392 FOR A PARTICULAR PURPOSE.