idnits 2.17.1 draft-ietf-isis-caps-02.txt: -(303): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(311): 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.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 382. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 276. ** 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: ---------------------------------------------------------------------------- == 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 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 : ---------------------------------------------------------------------------- ** 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 (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 282, but no explicit reference was found in the text == Unused Reference: 'IS-IS' is defined on line 285, but no explicit reference was found in the text == Unused Reference: 'IS-IS-IP' is defined on line 290, but no explicit reference was found in the text == Unused Reference: 'ISIS-TE' is defined on line 293, 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: 5 errors (**), 0 flaws (~~), 13 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-02.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. Acknowledgment 251 The authors would like to thank Jean-Louis Le Roux, Paul Mabey, 252 Andrew Partan and Adrian Farrel for their useful comments. 254 7. Intellectual Property Considerations 256 The IETF takes no position regarding the validity or scope of any 257 Intellectual Property Rights or other rights that might be claimed to 258 pertain to the implementation or use of the technology described in 259 this document or the extent to which any license under such rights 260 might or might not be available; nor does it represent that it has 261 made any independent effort to identify any such rights. Information 262 on the procedures with respect to rights in RFC documents can be 263 found in BCP 78 and BCP 79. 265 Copies of IPR disclosures made to the IETF Secretariat and any 266 assurances of licenses to be made available, or the result of an 267 attempt made to obtain a general license or permission for the use of 268 such proprietary rights by implementers or users of this 269 specification can be obtained from the IETF on-line IPR repository at 270 http://www.ietf.org/ipr. 272 The IETF invites any interested party to bring to its attention any 273 copyrights, patents or patent applications, or other proprietary 274 rights that may cover technology that may be required to implement 275 this standard. Please address the information to the IETF at ietf- 276 ipr@ietf.org. 278 8. References 280 8.1 Normative references 282 [RFC] Bradner, S., "Key words for use in RFCs to Indicate Requirement 283 Levels," RFC 2119. 285 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 286 Routeing Exchange Protocol for use in Conjunction with the Protocol 287 for Providing the Connectionless-mode Network Service (ISO 8473)", 288 ISO 10589. 290 [IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 291 dual environments", RFC 1195, December 1990. 293 [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 294 Engineering", RFC 3784, June 2004. 296 8.2 Informative references 298 [AUTOMESH] JP Vasseur, JL. Le Roux et al, �Routing extensions for 299 discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic 300 Engineering (TE) mesh membership�, draft-vasseur-ccamp-automesh- 301 00.txt, Work in progress. 303 [TE-NODE-CAP] JP Vasseur, JL. Le Roux et al, �Routing extensions for 304 discovery of Traffic Engineering Node Capabilities�, draft-vasseur- 305 ccamp-te-node-cap-00.txt, Work in progress. 307 [P2MP] R. Aggarwal,D. Papadimitriou,S. Yasukawa, et. al. "Extensions 308 to RSVP-TE for Point To Multipoint TE LSPs", draft-ietf-mpls-rsvp-te- 309 p2mp-01.txt, work in progress. 311 [P2MP-REQS] S. Yasukawa et al. � Requirements for point to multipoint 312 extension to RSVP �, draft-ietf-mpls-p2mp-sig-requirement-01.txt, 313 work in progress. 315 9. Author's Addresses 317 Jean-Philippe Vasseur 318 CISCO Systems, Inc. 319 300 Beaver Brook 320 Boxborough, MA 01719 321 USA 322 Email: jpv@cisco.com 324 Stefano Previdi 325 CISCO Systems, Inc. 326 Via Del Serafico 200 327 00142 - Roma 328 ITALY 329 Email: sprevidi@cisco.com 331 Mike Shand 332 Cisco Systems 333 250 Longwater Avenue, 334 Reading, 335 Berkshire, 336 RG2 6GB 337 UK 338 Email: mshand@cisco.com 340 Les Ginsberg 341 Cisco Systems 342 510 McCarthy Blvd. 343 Milpitas, Ca. 95035 USA 344 Email: ginsberg@cisco.com 346 Acee Lindem 347 Cisco Systems 348 7025 Kit Creek Road 349 Research Triangle Park, NC 27709 350 USA 351 e-mail: acee@cisco.com 353 Naiming Shen 354 Cisco Systems 355 225 West Tasman Drive 356 San Jose, CA 95134 357 USA 358 e-mail: naiming@cisco.com 360 Rahul Aggarwal 361 Juniper Networks 362 1194 N. Mathilda Avenue 363 San Jose, CA 94089 364 USA 365 e-mail: rahul@juniper.net 367 Scott Shaffer 368 e-mail: sshaffer@bridgeport-networks.com 370 Full Copyright Statement 372 Copyright (C) The Internet Society (2005). This document is subject 373 to the rights, licenses and restrictions contained in BCP 78, and 374 except as set forth therein, the authors retain all their rights. 376 This document and the information contained herein are provided on an 377 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 378 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 379 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 380 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 381 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 382 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.