idnits 2.17.1 draft-ietf-isis-rfc4971bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 18, 2016) is 2805 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. 'ISO10589' ** Obsolete normative reference: RFC 5316 (Obsoleted by RFC 9346) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group L. Ginsberg 3 Internet-Draft S. Previdi 4 Obsoletes: 4971 (if approved) Cisco Systems 5 Intended status: Standards Track M. Chen 6 Expires: February 19, 2017 Huawei Technologies Co., Ltd 7 August 18, 2016 9 IS-IS Extensions for Advertising Router Info 10 draft-ietf-isis-rfc4971bis-04.txt 12 Abstract 14 This document defines a new optional Intermediate System to 15 Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple 16 sub-TLVs, which allows a router to announce its capabilities within 17 an IS-IS level or the entire routing domain. This document obsoletes 18 RFC 4971. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 19, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. IS-IS Router CAPABILITY TLV . . . . . . . . . . . . . . . . . 3 62 3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 4 63 4. Interoperability with Routers Not Supporting the Capability 64 TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 8.2. Informational References . . . . . . . . . . . . . . . . 8 71 Appendix A. Changes to RFC 4971 . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 There are several situations where it is useful for the IS-IS 77 [ISO10589] [RFC1195] routers to learn the capabilities of the other 78 routers of their IS-IS level, area, or routing domain. For the sake 79 of illustration, three examples related to MPLS Traffic Engineering 80 (TE) are described here: 82 1. Mesh-group: the setting up of a mesh of TE Label Switched Paths 83 (LSPs) [RFC5305] requires some significant configuration effort. 84 [RFC4972] proposes an auto-discovery mechanism whereby every 85 Label Switching Router (LSR) of a mesh advertises its mesh-group 86 membership by means of IS-IS extensions. 88 2. Point to Multipoint TE LSP (RFC4875). A specific sub-TLV 89 [RFC5073] allows an LSR to advertise its Point To Multipoint 90 capabilities ([RFC4875] and [RFC4461]). 92 3. Inter-area traffic engineering: Advertisement of the IPv4 and/or 93 the IPv6 Traffic Engineering Router IDs. 95 The use of IS-IS for Path Computation Element (PCE) discovery may 96 also be considered and will be discussed in the PCE WG. 98 The capabilities mentioned above require the specification of new 99 sub-TLVs carried within the CAPABILITY TLV defined in this document. 101 Note that the examples above are provided for the sake of 102 illustration. This document proposes a generic capability 103 advertising mechanism that is not limited to MPLS Traffic 104 Engineering. 106 This document defines a new optional IS-IS TLV named CAPABILITY, 107 formed of multiple sub-TLVs, which allows a router to announce its 108 capabilities within an IS-IS level or the entire routing domain. The 109 applications mentioned above require the specification of new sub- 110 TLVs carried within the CAPABILITY TLV defined in this document. 112 Definition of these sub-TLVs is outside the scope of this document. 114 2. IS-IS Router CAPABILITY TLV 116 The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type, 117 1 octet that specifies the number of bytes in the value field, and a 118 variable length value field that starts with 4 octets of Router ID, 119 indicating the source of the TLV, followed by 1 octet of flags. 121 A set of optional sub-TLVs may follow the flag field. Sub-TLVs are 122 formatted as described in [RFC5305]. 124 TYPE: 242 125 LENGTH: from 5 to 255 126 VALUE: 127 Router ID (4 octets) 128 Flags (1 octet) 129 Set of optional sub-TLVs (0-250 octets) 131 Flags 133 0 1 2 3 4 5 6 7 134 +-+-+-+-+-+-+-+-+ 135 | Reserved |D|S| 136 +-+-+-+-+-+-+-+-+ 138 Currently two bit flags are defined. 140 S bit (0x01): If the S bit is set(1), the IS-IS Router CAPABILITY TLV 141 MUST be flooded across the entire routing domain. If the S bit is 142 not set(0), the TLV MUST NOT be leaked between levels. This bit MUST 143 NOT be altered during the TLV leaking. 145 D bit (0x02): When the IS-IS Router CAPABILITY TLV is leaked from 146 level-2 to level-1, the D bit MUST be set. Otherwise, this bit MUST 147 be clear. IS-IS Router CAPABILITY TLVs with the D bit set MUST NOT 148 be leaked from level-1 to level-2. This is to prevent TLV looping. 150 The Router CAPABILITY TLV is OPTIONAL. As specified in Section 3, 151 more than one Router CAPABILITY TLV from the same source MAY be 152 present. 154 This document does not specify how an application may use the Router 155 CAPABILITY TLV and such specification is outside the scope of this 156 document. 158 3. Elements of Procedure 160 The Router ID SHOULD be identical to the value advertised in the 161 Traffic Engineering Router ID TLV [RFC5305]. If no Traffic 162 Engineering Router ID is assigned the Router ID SHOULD be identical 163 to an IP Interface Address [RFC1195] advertised by the originating 164 IS. If the originating node does not support IPv4, then the reserved 165 value 0.0.0.0 MUST be used in the Router ID field and the IPv6 TE 166 Router ID sub-TLV [RFC5316] MUST be present in the TLV. Router 167 CAPABILITY TLVs which have a Router ID of 0.0.0.0 and do NOT have the 168 IPv6 TE Router ID sub-TLV present MUST NOT be used. 170 When advertising capabilities with different flooding scopes, a 171 router MUST originate a minimum of two Router CAPABILITY TLVs, each 172 TLV carrying the set of sub-TLVs with the same flooding scope. For 173 instance, if a router advertises two sets of capabilities, C1 and C2, 174 with an area/level scope and routing domain scope respectively, C1 175 and C2 being specified by their respective sub-TLV(s), the router 176 will originate two Router CAPABILITY TLVs: 178 - One Router CAPABILITY TLV with the S flag cleared, carrying the 179 sub-TLV(s) relative to C1. This Router CAPABILITY TLV will not be 180 leaked into another level. 182 - One Router CAPABILITY TLV with the S flag set, carrying the sub- 183 TLV(s) relative to C2. This Router CAPABILITY TLV will be leaked 184 into other IS-IS levels. When the TLV is leaked from level-2 to 185 level-1, the D bit will be set in the level-1 LSP advertisement. 187 In order to prevent the use of stale CAPABILITY TLVs, a system MUST 188 NOT use a CAPABILITY TLV present in an LSP of a system that is not 189 currently reachable via Level-x paths, where "x" is the level (1 or 190 2) in which the sending system advertised the TLV. This requirement 191 applies regardless of whether or not the sending system is the 192 originator of the CAPABILITY TLV. 194 When a CAPABILITY TLV is not used, either due to lack of reachability 195 to the originating router or due to unusable Router ID, note that 196 leaking the CAPABILITY TLV is one of the uses that is prohibited 197 under these conditions. 199 Example: If Level-1 router A generates a CAPABILITY TLV and floods 200 it to two L1/L2 routers, S and T, they will flood it into the 201 Level-2 domain. Now suppose the Level-1 area partitions, such 202 that A and S are in one partition and T is in another. IP routing 203 will still continue to work, but if A now issues a revised version 204 of the CAP TLV, or decides to stop advertising it, S will follow 205 suit, but without the above prohibition T will continue to 206 advertise the old version until the LSP times out. 208 Routers in other areas have to choose whether to trust T's copy of 209 A's CAPABIITY TLV or S's copy of A's CAPABILITY TLV and they have 210 no reliable way to choose. By making sure that T stops leaking A's 211 information, the possibility that other routers will use stale 212 information from A is eliminated. 214 In IS-IS, the atomic unit of the update process is a TLV - or more 215 precisely, in the case of TLVs that allow multiple entries to appear 216 in the value field (e.g., IS-neighbors), the atomic unit is an entry 217 in the value field of a TLV. If an update to an entry in a TLV is 218 advertised in an LSP fragment different from the LSP fragment 219 associated with the old advertisement, the possibility exists that 220 other systems can temporarily have either 0 copies of a particular 221 advertisement or 2 copies of a particular advertisement, depending on 222 the order in which new copies of the LSP fragment that had the old 223 advertisement and the fragment that has the new advertisement arrive 224 at other systems. 226 Wherever possible, an implementation SHOULD advertise the update to a 227 CAPABILITY TLV in the same LSP fragment as the advertisement that it 228 replaces. Where this is not possible, the two affected LSP fragments 229 should be flooded as an atomic action. 231 Systems that receive an update to an existing CAPABILITY TLV can 232 minimize the potential disruption associated with the update by 233 employing a holddown time prior to processing the update so as to 234 allow for the receipt of multiple LSP fragments associated with the 235 same update prior to beginning processing. 237 Where a receiving system has two copies of a CAPABILITY TLV from the 238 same system that have conflicting information for a given sub-TLV, 239 the procedure used to choose which copy shall be used is undefined. 241 4. Interoperability with Routers Not Supporting the Capability TLV 243 Routers that do not support the Router CAPABILITY TLV MUST silently 244 ignore the TLV(s) and continue processing other TLVs in the same LSP. 245 Routers that do not support specific sub-TLVs carried within a Router 246 CAPABILITY TLV MUST silently ignore the unsupported sub-TLVs and 247 continue processing those sub-TLVs that are supported in the Router 248 CAPABILITY TLV. How partial support may impact the operation of the 249 capabilities advertised within the Router CAPABILITY TLV is outside 250 the scope of this document. 252 In order for Router CAPABILITY TLVs with domain-wide scope originated 253 by L1 Routers to be flooded across the entire domain, at least one 254 L1/L2 Router in every area of the domain MUST support the Router 255 CAPABILITY TLV. 257 If leaking of the CAPABILITY TLV is required, the entire CAPABILITY 258 TLV MUST be leaked into another level without change (except for 259 changes to the TLV flags as noted in Section 2) even though it may 260 contain some sub-TLVs which are unsupported by the Router doing the 261 leaking. 263 5. Security Considerations 265 Any new security issues raised by the procedures in this document 266 depend upon the opportunity for LSPs to be snooped and modified, the 267 ease/difficulty of which has not been altered. As the LSPs may now 268 contain additional information regarding router capabilities, this 269 new information would also become available to an attacker. 270 Specifications based on this mechanism need to describe the security 271 considerations around the disclosure and modification of their 272 information. Note that an integrity mechanism, such as the one 273 defined in [RFC5304] or [RFC5310], should be applied if there is high 274 risk resulting from modification of capability information. 276 6. IANA Considerations 278 IANA assigned a new IS-IS TLV code-point for the newly defined IS-IS 279 TLV type named the IS-IS Router CAPABILITY TLV and defined in this 280 document. The assigned value is 242. 282 7. Acknowledgements 284 For the original version of this document (RFC 4971) the authors 285 thanked Jean-Louis Le Roux, Paul Mabey, Andrew Partan, and Adrian 286 Farrel for their useful comments. 288 For this new version the authors would like to thank Kris Michielsen 289 for calling attention to the problem associated with an IPv6 only 290 router. 292 8. References 294 8.1. Normative References 296 [ISO10589] 297 International Organization for Standardization, 298 "Intermediate system to Intermediate system intra-domain 299 routeing information exchange protocol for use in 300 conjunction with the protocol for providing the 301 connectionless-mode Network Service (ISO 8473)", ISO/ 302 IEC 10589:2002, Second Edition, Nov 2002. 304 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 305 dual environments", RFC 1195, DOI 10.17487/RFC1195, 306 December 1990, . 308 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 309 Requirement Levels", BCP 14, RFC 2119, 310 DOI 10.17487/RFC2119, March 1997, 311 . 313 [RFC5073] Vasseur, J., Ed. and J. Le Roux, Ed., "IGP Routing 314 Protocol Extensions for Discovery of Traffic Engineering 315 Node Capabilities", RFC 5073, DOI 10.17487/RFC5073, 316 December 2007, . 318 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 319 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 320 2008, . 322 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 323 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 324 2008, . 326 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 327 and M. Fanto, "IS-IS Generic Cryptographic 328 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 329 2009, . 331 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 332 Support of Inter-Autonomous System (AS) MPLS and GMPLS 333 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 334 December 2008, . 336 8.2. Informational References 338 [RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to- 339 Multipoint Traffic-Engineered MPLS Label Switched Paths 340 (LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006, 341 . 343 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 344 Yasukawa, Ed., "Extensions to Resource Reservation 345 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 346 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 347 DOI 10.17487/RFC4875, May 2007, 348 . 350 [RFC4972] Vasseur, JP., Ed., Leroux, JL., Ed., Yasukawa, S., 351 Previdi, S., Psenak, P., and P. Mabbey, "Routing 352 Extensions for Discovery of Multiprotocol (MPLS) Label 353 Switch Router (LSR) Traffic Engineering (TE) Mesh 354 Membership", RFC 4972, DOI 10.17487/RFC4972, July 2007, 355 . 357 Appendix A. Changes to RFC 4971 359 This document makes the following changes to RFC 4971. 361 RFC 4971 only allowed a 32 bit Router ID in the fixed header of TLV 362 242. This is problematic in an IPv6-only deployment where an IPv4 363 address may not be available. This document specifies: 365 1. The Router ID SHOULD be identical to the value advertised in the 366 Traffic Engineering Router ID TLV (134) if available. 368 2. If no Traffic Engineering Router ID is assigned the Router ID 369 SHOULD be identical to an IP Interface Address [RFC1195] 370 advertised by the originating IS. 372 3. If the originating node does not support IPv4, then the reserved 373 value 0.0.0.0 MUST be used in the Router ID field and the IPv6 TE 374 Router ID sub-TLV [RFC5316] MUST be present in the TLV. 376 In addition, some clarifying editorial changes have been made. 378 Authors' Addresses 380 Les Ginsberg 381 Cisco Systems 382 510 McCarthy Blvd. 383 Milpitas, CA 95035 384 USA 386 Email: ginsberg@cisco.com 388 Stefano Previdi 389 Cisco Systems 390 Via Del Serafico 200 391 Rome 0144 392 Italy 394 Email: sprevidi@cisco.com 396 Mach (Guoyi) Chen 397 Huawei Technologies Co., Ltd 398 KuiKe Building, No. 9 Xinxi Rd. Hai-Dian District 399 Beijing 100085 400 P.R. China 402 Email: mach.chen@huawei.com