idnits 2.17.1 draft-ietf-isis-caps-01.txt: -(299): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(307): 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 378. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 259. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 266. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 272. ** 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: ---------------------------------------------------------------------------- == 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 109 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 (April 2005) is 6951 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 278, but no explicit reference was found in the text == Unused Reference: 'IS-IS' is defined on line 281, but no explicit reference was found in the text == Unused Reference: 'IS-IS-IP' is defined on line 286, but no explicit reference was found in the text == Unused Reference: 'ISIS-TE' is defined on line 289, 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: 7 errors (**), 0 flaws (~~), 13 warnings (==), 7 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: July 2005 April 2005 12 IS-IS extensions for advertising router information 14 draft-ietf-isis-caps-01.txt 16 Status of this Memo 18 By submitting this Internet-Draft, I certify that any applicable 19 patent or IPR claims of which I am aware have been disclosed, and any 20 of which I become aware will be disclosed, in accordance with RFC 21 3668. 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026 [i]. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Abstract 43 This document defines a new optional IS-IS TLV named CAPABILITY, 44 formed of multiple sub-TLVs, which allows a router to announce its 45 capabilities within an IS-IS level or the entire routing domain. 47 Conventions used in this document 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC-2119 [ii]. 52 Table of Contents 54 1. Introduction....................................................2 55 2. IS-IS Router CAPABILITY TLV.....................................3 56 3. Element of procedure............................................3 57 4. Interoperability with routers not supporting the capability TLV.5 58 5. Security considerations.........................................6 59 6. Acknowledgment..................................................6 60 7. Intellectual Property Considerations............................6 61 8. References......................................................6 62 8.1 Normative references...........................................6 63 8.2 Informative references.........................................7 64 9. Author's Addresses..............................................7 66 1. Introduction 68 There are several situations where it is useful for the IS-IS 69 routers to learn the capabilities of the other routers of their IS- 70 IS level, area or routing domain. For the sake of illustration, two 71 examples related to MPLS Traffic Engineering are described here: 73 1. Mesh-group: the setting up of a mesh of TE LSPs requires some 74 significant configuration effort. [AUTOMESH] proposes an auto- 75 discovery mechanism whereby every LSR of a mesh advertises its 76 mesh-group membership by means of IS-IS extensions. 78 2. Point to Multi-point TE LSP (P2MP LSP). A specific sub-TLV ([TE- 79 NODE-CAP]) allows an LSR to advertise its Point To Multipoint 80 capabilities ([P2MP] and [P2MP-REQS]). 82 The use of IS-IS for Path Computation Element (PCE) discovery may 83 also be considered and will be discussed in the PCE WG. 85 The capabilities mentioned above require the specification of new 86 sub-TLVs carried within the CAPABILITY TLV defined in this document. 88 Note that the examples above are provided for the sake of 89 illustration. This document proposes a generic capability advertising 90 mechanism not limited to MPLS Traffic Engineering. 92 This document defines a new optional IS-IS TLV named CAPABILITY, 93 formed of multiple sub-TLVs, which allows a router to announce its 94 capabilities within an IS-IS level or the entire routing domain. The 95 applications mentioned above require the specification of new sub- 96 TLVs carried within the CAPABILITY TLV defined in this document. 98 Definition of these sub-TLVs is outside the scope of this document. 100 2. IS-IS Router CAPABILITY TLV 102 The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type, 103 1 octet specifying the TLV length, 1 octet of bit flags and a 104 variable length value field, starting with 4 octets of Router ID, 105 indicating the source of the TLV, and followed by 1 octet of flags. A 106 set of optional sub-TLVs may follow the flag field. 108 TYPE: 242 (To be assigned by IANA) 109 LENGTH: from 5 to 255 110 VALUE: 111 Router ID (4 octets) 112 Flags (1 octet) 113 Set of optional sub-TLVs (0-250 octets) 115 Flags 117 0 1 2 3 4 5 6 7 118 +-+-+-+-+-+-+-+-+ 119 | Reserved |D|S| 120 +-+-+-+-+-+-+-+-+ 122 Currently two bit flags are defined. 124 S bit (0x01): If the S bit is set(1), the IS-IS Router CAPABILITY TLV 125 MUST be flooded across the entire routing domain. If the S bit is not 126 set(0), the TLV MUST NOT be leaked between levels. This bit MUST NOT 127 be altered during the TLV leaking. 129 D bit (0x02): When the IS-IS Router CAPABILITY TLV is leaked from 130 level-2 to level-1, the D bit MUST be set. Otherwise this bit MUST be 131 clear. IS-IS Router capability TLVs with the D bit set MUST NOT be 132 leaked from level-1 to level-2. This is to prevent TLV looping. 134 The Router CAPABILITY TLV is OPTIONAL. As specified in section 3, 135 more than one Router CAPABILITY TLVs from the same source MAY be 136 present. 138 This document does not specify how an application may use the Router 139 Capability TLV and such specification is outside the scope of this 140 document. 142 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 (more on that below). By making sure that T 192 stops leaking A's information, this removes the possibility that 193 other routers will 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 No new security issues are raised in this document. 245 6. Acknowledgment 247 The authors would like to thank Jean-Louis Le Roux, Paul Mabey and 248 Andrew Partan for their useful comments. 250 7. Intellectual Property Considerations 252 The IETF takes no position regarding the validity or scope of any 253 Intellectual Property Rights or other rights that might be claimed to 254 pertain to the implementation or use of the technology described in 255 this document or the extent to which any license under such rights 256 might or might not be available; nor does it represent that it has 257 made any independent effort to identify any such rights. Information 258 on the procedures with respect to rights in RFC documents can be 259 found in BCP 78 and BCP 79. 261 Copies of IPR disclosures made to the IETF Secretariat and any 262 assurances of licenses to be made available, or the result of an 263 attempt made to obtain a general license or permission for the use of 264 such proprietary rights by implementers or users of this 265 specification can be obtained from the IETF on-line IPR repository at 266 http://www.ietf.org/ipr. 268 The IETF invites any interested party to bring to its attention any 269 copyrights, patents or patent applications, or other proprietary 270 rights that may cover technology that may be required to implement 271 this standard. Please address the information to the IETF at ietf- 272 ipr@ietf.org. 274 8. References 276 8.1 Normative references 278 [RFC] Bradner, S., "Key words for use in RFCs to Indicate Requirement 279 Levels," RFC 2119. 281 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 282 Routeing Exchange Protocol for use in Conjunction with the Protocol 283 for Providing the Connectionless-mode Network Service (ISO 8473)", 284 ISO 10589. 286 [IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 287 dual environments", RFC 1195, December 1990. 289 [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 290 Engineering", RFC 3784, June 2004. 292 8.2 Informative references 294 [AUTOMESH] JP Vasseur, JL. Le Roux et al, �Routing extensions for 295 discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic 296 Engineering (TE) mesh membership�, draft-vasseur-ccamp-automesh- 297 00.txt, Work in progress. 299 [TE-NODE-CAP] JP Vasseur, JL. Le Roux et al, �Routing extensions for 300 discovery of Traffic Engineering Node Capabilities�, draft-vasseur- 301 ccamp-te-node-cap-00.txt, Work in progress. 303 [P2MP] R. Aggarwal,D. Papadimitriou,S. Yasukawa, et. al. "Extensions 304 to RSVP-TE for Point To Multipoint TE LSPs", draft-ietf-mpls-rsvp-te- 305 p2mp-01.txt, work in progress. 307 [P2MP-REQS] S. Yasukawa et al. � Requirements for point to multipoint 308 extension to RSVP �, draft-ietf-mpls-p2mp-sig-requirement-01.txt, 309 work in progress. 311 9. Author's Addresses 313 Jean-Philippe Vasseur 314 CISCO Systems, Inc. 315 300 Beaver Brook 316 Boxborough, MA 01719 317 USA 318 Email: jpv@cisco.com 320 Stefano Previdi 321 CISCO Systems, Inc. 322 Via Del Serafico 200 323 00142 - Roma 324 ITALY 325 Email: sprevidi@cisco.com 327 Mike Shand 328 Cisco Systems 329 250 Longwater Avenue, 330 Reading, 331 Berkshire, 332 RG2 6GB 333 UK 334 Email: mshand@cisco.com 336 Les Ginsberg 337 Cisco Systems 338 510 McCarthy Blvd. 339 Milpitas, Ca. 95035 USA 340 Email: ginsberg@cisco.com 342 Acee Lindem 343 Cisco Systems 344 7025 Kit Creek Road 345 Research Triangle Park, NC 27709 346 USA 347 e-mail: acee@cisco.com 349 Naiming Shen 350 Cisco Systems 351 225 West Tasman Drive 352 San Jose, CA 95134 353 USA 354 e-mail: naiming@cisco.com 356 Rahul Aggarwal 357 Juniper Networks 358 1194 N. Mathilda Avenue 359 San Jose, CA 94089 360 USA 361 e-mail: rahul@juniper.net 363 Scott Shaffer 364 e-mail: sshaffer@bridgeport-networks.com 366 Full Copyright Statement 368 Copyright (C) The Internet Society (2005). This document is subject 369 to the rights, licenses and restrictions contained in BCP 78, and 370 except as set forth therein, the authors retain all their rights. 372 This document and the information contained herein are provided on an 373 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 374 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 375 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 376 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 377 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 378 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.