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