idnits 2.17.1 draft-vasseur-isis-caps-02.txt: -(263): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(267): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(274): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(275): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(282): 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 3667, Section 5.1 on line 240. -- Found old boilerplate from RFC 3978, Section 5.5 on line 349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 222. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 229. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 235. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 7 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 (July 2004) is 7218 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: 'INTER-AREA-AS' is mentioned on line 80, but not defined == Missing Reference: 'IS-IS-TE' is mentioned on line 90, but not defined == Unused Reference: 'RFC' is defined on line 246, but no explicit reference was found in the text == Unused Reference: 'IS-IS' is defined on line 249, but no explicit reference was found in the text == Unused Reference: 'IS-IS-IP' is defined on line 254, but no explicit reference was found in the text == Unused Reference: 'ISIS-TE' is defined on line 257, but no explicit reference was found in the text == Unused Reference: 'TE-CAP' is defined on line 262, but no explicit reference was found in the text == Unused Reference: 'INT-DOMAIN-FRWK' is defined on line 278, 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 (-01) exists of draft-raggarwa-mpls-rsvp-te-p2mp-00 == Outdated reference: A later version (-04) exists of draft-ietf-mpls-p2mp-requirement-01 -- No information found for draft-vasseur-inter-domain-path-comp - is the name correct? Summary: 8 errors (**), 0 flaws (~~), 14 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ISIS WG 2 Internet Draft Jean-Philippe Vasseur(Ed) 3 Cisco Systems, Inc. 4 Rahul Aggarwal(Ed) 5 Juniper Networks 6 Naiming Shen(Ed) 7 Redback Networks 9 Document: draft-vasseur-isis-caps-02.txt 10 Expires: January 2005 July 2004 12 IS-IS extensions for advertising router information 14 draft-vasseur-isis-caps-02.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 TLVs 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 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in RFC-2119 [ii]. 53 Table of Contents 55 1. Introduction...................................................2 56 2. IS-IS Router CAPABILITY TLV....................................3 57 3. Element of procedure...........................................4 58 4. Interoperability with routers not supporting the capability TLV.4 59 5. Security considerations........................................5 60 6. Acknowledgment.................................................5 61 7. Intellectual Property Considerations...........................5 62 8. References.....................................................6 63 Normative references..............................................6 64 Informative references............................................6 65 9. Author's Addresses.............................................6 67 1. Introduction 69 There are several situations where it is useful for the IS-IS routers 70 to learn the capabilities of the other routers of their IS-IS level, 71 area or routing domain. Some applications are described in [IS-IS-TE- 72 CAP]. For the sake of illustration, three examples related to MPLS 73 Traffic Engineering are described here: 75 1. Path Computation Element (PCE) discovery ([INTER-DOMAIN-PATH- 76 COMP]): in several situations, the Traffic Engineering Label 77 Switched (TE LSP) path is computed by a Label Switch Router (LSR) 78 which is not the head-end for that LSP (e.g an ABR or an ASBR 79 respectively in the context of inter-area and inter-AS MPLS TE 80 ([INTER-AREA-AS]). In such a case, having the ability to discover 81 the capability of a router to act as a PCE is extremely useful in 82 term of ease of operation, capacity to react to PCE failure, load 83 sharing between a set of PCEs and so on. 85 2. Mesh-group: the setting up of a mesh of TE LSPs requires some 86 significant configuration effort. [IS-IS-TE-CAP] proposes an auto- 87 discovery mechanism whereby every LSR of a mesh advertises its 88 mesh-group membership by means of IS-IS extensions. 90 3. Point to Multi-point TE LSP (P2MP LSP). A specific sub-TLV ([IS- 91 IS-TE]) allows an LSR to advertise its Point To Multipoint 92 capabilities ([P2MP] and [P2MP-REQS]). 94 The capabilities mentioned above require the specification of new 95 sub-TLVs carried within the CAPABILITY TLV defined in this document. 97 Note that the examples above are provided for the sake of 98 illustration. This document proposes a generic capability advertising 99 mechanism not limited to MPLS Traffic Engineering. 101 This document defines a new optional IS-IS TLVs named CAPABILITY, 102 formed of multiple sub-TLVs, which allows a router to announce its 103 capabilities within an IS-IS level or the entire routing domain. The 104 applications mentioned above require the specification of new sub- 105 TLVs carried within the CAPABILITY TLV defined in this document. 107 Definition of these sub-TLVs is outside the scope of this document. 109 2. IS-IS Router CAPABILITY TLV 111 The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type, 112 1 octet specifying the TLV length, 1 octet of bit flags and a 113 variable length value field, starting with 4 octets of Router ID, 114 indicating the source of the TLV, and followed by 1 octet of flags. A 115 set of optional sub-TLVs may follow the flag field. 117 TYPE: 242 (To be assigned by IANA) 118 LENGTH: from 5 to 255 119 VALUE: 120 Router ID (4 octets) 121 Flags (1 octet) 122 Set of optional sub-TLVs (0-250 octets) 124 Flags 126 0 1 2 3 4 5 6 7 127 +-+-+-+-+-+-+-+-+ 128 | Reserved |D|S| 129 +-+-+-+-+-+-+-+-+ 131 Currently two bit flags are defined. 133 S bit (0x01): If the S bit is set(1), the IS-IS Router CAPABILITY TLV 134 MUST be flooded across the entire routing domain. If the S bit is not 135 set(0), the TLV MUST NOT be leaked between levels. This bit MUST NOT 136 be altered during the TLV leaking. 138 D bit (0x02): When the IS-IS Router CAPABILITY TLV is leaked from 139 level-2 to level-1, the D bit MUST be set. Otherwise this bit MUST be 140 clear. IS-IS Router capability TLVs with the D bit set MUST NOT be 141 leaked from level-1 to level-2. This is to prevent TLV looping. 143 The Router CAPABILITY TLV is OPTIONAL. As specified in section 3, 144 more than one Router CAPABILITY TLVs from the same source MAY be 145 present. 147 This document does not specify how an application may use the Router 148 Capability TLV and such specification is outside the scope of this 149 document. 151 3. Element of procedure 153 In case of advertising capabilities with different flooding scopes, a 154 router MUST originate a minimum of two Router CAPABILITY TLVs, each 155 TLV carrying the set of sub-TLVs with the same flooding scope. For 156 instance, if a router advertises two sets of capabilities C1 and C2 157 with an area/level scope and routing domain scope respectively, C1 158 and C2 being specified by their respective sub-TLV(s), the router 159 MUST originate two Router CAPABILITY TLVs: 161 - One Router CAPABILITY TLV with the S flag cleared carrying the 162 sub-TLV(s) relative to C1. This Router CAPABILITY TLV MUST NOT be 163 leaked into another level. 165 - One Router CAPABILITY TLV with the S flag set carrying the sub- 166 TLV(s) relative to C2. This Router CAPABILITY TLV MUST be leaked 167 into other IS-IS levels. When the TLV is leaked from level-2 to 168 level-1, the D bit MUST be set in the level-1 LSP advertisement. 170 When leaking Capability TLVs downward from Level-2 into Level-1, if 171 the originator of the TLV is a Level-1 router in another area, it is 172 possible that multiple copies of the same TLV may be received from 173 multiple L2 routers in the originating area. To prevent a router from 174 leaking multiple copies of the same TLV, the router performing the 175 downward leaking MUST check for such duplication by comparing the 176 contents of the TLVs. 178 When leaking Capability TLVs received from other systems, the router 179 performing the leaking MUST only leak a TLV if the system advertising 180 the TLV (which may or may not be the system which originated the TLV) 181 is reachable via Level-x paths, where "x" is the level (1 or 2) in 182 which the sending system advertised the TLV. 184 4. Interoperability with routers not supporting the capability TLV. 186 Routers which do not support the Router CAPABILITY TLV MUST silently 187 ignore the TLV(s) and continue processing other TLVs in the same LSP. 188 Routers which do not support specific sub-TLVs carried within a 189 Router CAPABILITY TLV MUST silently ignore the unsupported sub-TLVs 190 and continue processing those sub-TLVs in the Router CAPABILITY TLV 191 which are supported. How partial support may impact the operation of 192 the capabilities advertised within the Router CAPABILITY TLV is 193 outside the scope of this document. 195 In order for Router CAPABILITY TLVs with domain-wide scope originated 196 by L1 Routers to be flooded across the entire domain at least one 197 L1/L2 Router in every area of the domain SHOULD support the Router 198 CAPABILITY TLV. 200 If leaking of the CAP TLV is required, the entire CAP TLV MUST be 201 leaked into another level even though it may contain some of the 202 unsupported sub-TLVs. 204 5. Security considerations 206 No new security issues are raised in this document. 208 6. Acknowledgment 210 The authors would like to thank Dave Ward, Jean-Louis Le Roux, 211 Paul Mabey and Andrew Partan for their useful comments. 213 7. Intellectual Property Considerations 215 The IETF takes no position regarding the validity or scope of any 216 Intellectual Property Rights or other rights that might be claimed to 217 pertain to the implementation or use of the technology described in 218 this document or the extent to which any license under such rights 219 might or might not be available; nor does it represent that it has 220 made any independent effort to identify any such rights. Information 221 on the procedures with respect to rights in RFC documents can be 222 found in BCP 78 and BCP 79. 224 Copies of IPR disclosures made to the IETF Secretariat and any 225 assurances of licenses to be made available, or the result of an 226 attempt made to obtain a general license or permission for the use of 227 such proprietary rights by implementers or users of this 228 specification can be obtained from the IETF on-line IPR repository at 229 http://www.ietf.org/ipr. 231 The IETF invites any interested party to bring to its attention any 232 copyrights, patents or patent applications, or other proprietary 233 rights that may cover technology that may be required to implement 234 this standard. Please address the information to the IETF at ietf- 235 ipr@ietf.org. 237 By submitting this Internet-Draft, I certify that any applicable 238 patent or other IPR claims of which I am aware have been disclosed, 239 and any of which I become aware will be disclosed, in accordance with 240 RFC 3668. 242 8. References 244 Normative references 246 [RFC] Bradner, S., "Key words for use in RFCs to Indicate Requirement 247 Levels," RFC 2119. 249 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 250 Routeing Exchange Protocol for use in Conjunction with the Protocol 251 for Providing the Connectionless-mode Network Service (ISO 8473)", 252 ISO 10589. 254 [IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 255 dual environments", RFC 1195, December 1990. 257 [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 258 Engineering", RFC 3784, June 2004. 260 Informative references 262 [TE-CAP], JP Vasseur, JL. Le Roux et al. ��Routing extensions for 263 discovery of TE router information��, draft-vasseur-ccamp-te-router- 264 info-00.txt, work in progress. 266 [IS-IS-TE-CAP] JP Vasseur, S. Previdi, Paul Mabey and JL. Le Roux, 267 ��IS-IS MPLS Traffic Engineering capabilities��, draft-vasseur-isis-te- 268 caps-00.txt, work in progress. 270 [P2MP] R. Aggarwal,D. Papadimitriou,S. Yasukawa, et. al. "Extensions 271 to RSVP-TE for point-to-multipoint TE LSPs", draft-raggarwa-mpls- 272 rsvp-te-p2mp-00.txt, work in progress. 274 [P2MP-REQS] S. Yasukawa et al. � Requirements for point to multipoint 275 extension to RSVP �, draft-ietf-mpls-p2mp-requirement-01.txt, work in 276 progress. 278 [INT-DOMAIN-FRWK] Farrel, A., Vasseur, J.P., Ayyangar, A., "A 279 Framework for Inter-Domain MPLS Traffic Engineering", draft-farrel- 280 ccamp-inter-domain-framework-01.txt, work in progress. 282 [INTER-DOMAIN-PATH-COMP] Vasseur and Ayyangar, ��Inter-domain Traffic 283 Engineering LSP path computation methods��, draft-vasseur-inter- 284 domain-path-comp-00.txt, work in progress. 286 9. Author's Addresses 288 Jean-Philippe Vasseur 289 CISCO Systems, Inc. 290 300 Beaver Brook 291 Boxborough, MA 01719 292 USA 293 Email: jpv@cisco.com 295 Stefano Previdi 296 CISCO Systems, Inc. 297 Via Del Serafico 200 298 00142 - Roma 299 ITALY 300 Email: sprevidi@cisco.com 302 Mike Shand 303 Cisco Systems 304 250 Longwater Avenue, 305 Reading, 306 Berkshire, 307 RG2 6GB 308 UK 309 Email: mshand@cisco.com 311 Les Ginsberg 312 Cisco Systems 313 510 McCarthy Blvd. 314 Milpitas, Ca. 95035 USA 315 Email: ginsberg@cisco.com 317 Acee Lindem 318 Redback Networks 319 350 Holger Way 320 San Jose, CA 95134 321 e-mail: acee@redback.com 323 Naiming Shen 324 Redback Networks 325 350 Holger Way 326 San Jose, CA 95134 327 e-mail: naiming@redback.com 329 Rahul Aggarwal 330 Juniper Networks 331 1194 N. Mathilda Avenue 332 San Jose, CA 94089 333 e-mail: rahul@juniper.net 335 Scott Shaffer 336 e-mail: sshaffer@bridgeport-networks.com 337 Full Copyright Statement 339 Copyright (C) The Internet Society (2004). This document is subject 340 to the rights, licenses and restrictions contained in BCP 78, and 341 except as set forth therein, the authors retain all their rights. 343 This document and the information contained herein are provided on an 344 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 345 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 346 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 347 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 348 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 349 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.