idnits 2.17.1 draft-bowers-isis-te-attribute-set-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 196: '...tribute Set sub-TLV MUST be ignored if...' RFC 2119 keyword, line 290: '... Scoped SRLG TLV MUST be ignored if th...' RFC 2119 keyword, line 316: '...fiers (IPv4, IPv6, or unnumbered) MUST...' RFC 2119 keyword, line 317: '...meet this requirement MUST be ignored....' RFC 2119 keyword, line 319: '...s for the same link MAY be advertised....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 416 has weird spacing: '... Scoped n n...' -- The document date (July 3, 2017) is 2487 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7810 (Obsoleted by RFC 8570) == Outdated reference: A later version (-03) exists of draft-ginsberg-isis-te-app-00 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ISIS Working Group C. Bowers 3 Internet-Draft S. Hegde 4 Intended status: Standards Track Juniper Networks 5 Expires: January 4, 2018 July 3, 2017 7 Extensions to IS-IS to Associate TE Attributes with TE Attribute Sets 8 and SRLGs with SRLG Sets 9 draft-bowers-isis-te-attribute-set-00 11 Abstract 13 This document specifies encodings that allow traffic engineering 14 attributes to be associated with different TE attribute set 15 identifiers and SRLGs to be associated with SRLG set identifiers. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on January 4, 2018. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Basic assumptions . . . . . . . . . . . . . . . . . . . . . . 2 53 2.1. Minimize disruption . . . . . . . . . . . . . . . . . . . 2 54 2.2. Maximize flexibilty . . . . . . . . . . . . . . . . . . . 3 55 3. TE Link Attributes that would benefit from this new 56 functionality . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Link Attribute Set sub-TLV . . . . . . . . . . . . . . . . . 4 58 5. TE Attribute Set usage . . . . . . . . . . . . . . . . . . . 5 59 6. SRLG Set Scoped SRLG TLV . . . . . . . . . . . . . . . . . . 6 60 7. SRLG Set usage . . . . . . . . . . . . . . . . . . . . . . . 7 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 9. Management Considerations . . . . . . . . . . . . . . . . . . 9 63 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 65 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 67 12.2. Informative References . . . . . . . . . . . . . . . . . 10 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 IS-IS encodings allow traffic engineering (TE) attributes, such as 73 bandwidth-related parameters and administrative groups, as well as 74 shared risk link groups (SRLGs) to be associated with different links 75 in the network topology. Different applications use these attributes 76 to decide how traffic should be directed across the network. 78 It can be useful for different applications to use different sets of 79 TE attributes and SRLGs to decide how traffic is directed across the 80 network. Existing IS-IS encodings only allow for one set of TE 81 attributes and SRLGs to be associated with a given link. This 82 document specifies encodings that allow different sets of TE 83 attributes and SRLGs to be associated with a given link. 85 2. Basic assumptions 87 There are several different approaches that one could take to enable 88 this functionality. The approach taken by this document is based on 89 the following assumptions about the use of this encoding. 91 2.1. Minimize disruption 93 The requirements of many current and future deployments of SR and 94 RSVP can be satisfied using the existing encodings that support a 95 single set of TE attributes and SRLGs. The encodings described here 96 allow the advertisement of multiple sets of TE attributes and SRLGs. 98 They do so in a way that minimizes the disruption and burden, in 99 terms of interoperability testing, software upgrades, and overall 100 complexity, on deployments that do not need this more complex 101 fucntionality. 103 2.2. Maximize flexibilty 105 Future applications are difficult to predict, especially as network 106 operators deploy their own customized, centralized controllers. The 107 encodings described here does not try to associate TE attributes and 108 SRLGs with particular applications. Instead, they allow TE 109 attributes and SRLGs to be organized into sets, using groupings that 110 make most sense for the network operator's particular use case. The 111 network advertises these TE attributes and SRLGs with their 112 associated TE attribute and SRLG set identifiers, and different 113 applications use this information as they see fit. The authors 114 believe that this approach provides the greatest flexibility for 115 those networks that are likely to require these more complex 116 capabilities. 118 3. TE Link Attributes that would benefit from this new functionality 120 There are currently 36 sub-TLVs defined for TLV#22 (as well as TLVs 121 #23, #141, #222, and #223.) We draw a distinction between two types 122 of sub-TLVs in TLV#22. Some sub-TLVs (such as the IPv4 interface 123 address and neighbor address sub-TLVs) are used to identify a link. 124 In this document, we refer to these as TE link identifier sub-TLVs. 125 Below is a complete list of the sub-TLVs in TLV#22 that we classify 126 as TE link identifier sub-TLVs. 128 Type Description 129 ------- ----------------------------- 130 4 Link Local/Remote Identifiers 131 6 IPv4 interface address 132 8 IPv4 neighbor address 133 12 IPv6 Interface Address 134 13 IPv6 Neighbor Address 136 sub-TLVs of TLV#22 classified as TE link identifier sub-TLVs 138 Since TE link identifier sub-TLVs are used to identify links, it does 139 not make sense to allow these sub-TLVs to be advertised more than 140 once with different values for a given link. 142 In principle, the remaining 31 sub-TLVs currently defined for TLV#22 143 are candidates for enabling the advertisment of different values 144 scoped by a TE attribute set identifier. However, for this document 145 we only specify this new functionality for the following subset of TE 146 link attributes. 148 Type Description 149 ------- ----------------------------- 150 3 Administrative group (color) 151 9 Maximum link bandwidth 152 10 Maximum reservable link bandwidth 153 11 Unreserved bandwidth 154 14 Extended Administrative Group 155 18 TE Default metric 156 33 Unidirectional Link Delay 157 34 Min/Max Unidirectional Link Delay 158 35 Unidirectional Delay Variation 159 36 Unidirectional Link Loss 160 37 Unidirectional Residual Bandwidth 161 38 Unidirectional Available Bandwidth 162 39 Unidirectional Utilized Bandwidth 164 Figure 1: TE link attributes sub-TLVs given the ability to be 165 advertised with different values scoped by TE attribute set 166 identifier 168 The new TE Attribute Set Identifier is a 32-bit value that identifies 169 a set of attributes. The TE Attribute Set Identifier with a value of 170 zero is special. Existing encodings for advertising attributes that 171 do not explicitly support the inclusion of the TE Attribute Set 172 Identifier are now understood to implicitly advertise attributes with 173 the TE Attribute Set Identifier set to zero. In this framework, 174 existing implementations using the existing encodings already support 175 the advertisement of attributes with the TE attibute set id = 0. 177 In order to ensure a consistent view of the attribute set scoped 178 attributes, for encodings that explicitly support the TE Attribute 179 Set Identifier, advertising an attribute with TE Attribute Set 180 Identifier set to zero is not allowed. 182 4. Link Attribute Set sub-TLV 184 The Link Attribute Set sub-TLV is a new sub-TLV for TLVs 22, 23, 141, 185 222, and 223. It allows multiple values of a given TE link attribute 186 to be advertised for the same link, scoped by the TE Attribute Set 187 ID. 189 Type: To be assigned by IANA (suggested value 101) 191 Length: Number of octets in the value field (1 octet) 192 Value: 194 TE Attribute Set Identifier: A 32-bit value containing the non- 195 zero TE Attribute Set Identifier that identifies a set of 196 attributes. The Link Attribute Set sub-TLV MUST be ignored if 197 the TE Attribute Set Identifier is zero. This ensures a 198 consistent view of the attribute set scoped link attributes, 199 where the Link Attribute sub-TLVs advertised directly in TLV#22 200 are now understood to be implicitly advertised with the TE 201 Attribute Set Identifier equal to zero. 203 Link Attribute sub-sub-TLVs: The format of these Link Attribute 204 sub-sub-TLVs matches the existing formats for the Link 205 Attribute sub-TLVs defined in [RFC5305] and [RFC7810]. Each 206 Link Attribute sub-sub-TLV advertised in a given Link Attribute 207 Set sub-TLV is associated with the TE Attribute Set Identifier 208 in the Link Attribute Set sub-TLV. Figure 1 shows the subset 209 of existing Link Attributes sub-TLVs that we are specifying in 210 this document. 212 5. TE Attribute Set usage 214 The TE attribute set uses a simple substitution semantics. We 215 consider the TE attribute set with identifier=0 to be the default TE 216 attribute set. An application receiving attributes in the default TE 217 attribute set will use those default TE attributes, unless it 218 receives attributes in the one non-default TE attribute set that it 219 has been configured or programmed to consider. 221 In many network scenarios, all of the applications will only need to 222 use a single common set of TE attributes advertised with their 223 existing encodings. In this framework, these applications will all 224 be using TE attribute set = 0, the default TE attribute set. 226 Application Atribute set id 227 ----------- --------------- 228 A 0 (implicit) 229 B 0 (implicit) 230 C 0 (implicit) 232 Scenario where all applications use a single common set of TE 233 attributes 235 In some scenarios, a network operator will need to advertise 236 different values of a given attribute for a given link. Consider a 237 scenario where applications D, E, and F need common values for all TE 238 link attributes, except for sub-TLV#9 (Maximum link bandwidth). 239 Applications D and E use a common value for sub-TLV#9, while 240 application F needs a different value for sub-TLV#9. This scenario 241 is supported by having each link advertise all sub-TLVs in TLV#22 as 242 they are advertised today. These advertisements are understood to be 243 advertised with the TE attribute set id = 0. Applications D and E 244 only need to use these advertisements. Links also advertise sub-sub- 245 TLV#9 in the TE Atribute Set sub-TLV with TE attribute set id = 1. 246 Application F is configured to use attribute set id = 1. This means 247 that application F first looks for the value of each attribute scoped 248 for TE attribute set = 1. If it is present, application F uses that 249 attribute set scoped value. If it is not present, application F uses 250 the value in the default TE attribute set (id=0). 252 Application Atribute set id 253 ----------- --------------- 254 D 0 (implicit) 255 E 0 (implicit) 256 F 1 258 Scenario where applications need different values for some attributes 260 From a standardization perspective, there is not intended to be any 261 fixed mapping between a given TE Attribute Set Identifier and a given 262 application. A network operator wishing to advertise different 263 attribute sets could configure the network equipment to advertise 264 attributes with different values of the TE Attribute Set Identifier 265 based on their objectives. The different applications (be they 266 controller-based applications or distributed applications) would make 267 use of the different attribute sets based on convention within that 268 network. 270 6. SRLG Set Scoped SRLG TLV 272 A new TLV is defined to allow SRLGs to be advertised for a given link 273 and associated with a specific SRLG set identifier. Although similar 274 in functionality to TLV 138 (defined by [RFC5307]) and TLV 139 275 (defined by [RFC6119]), a single TLV provides support for IPv4, IPv6, 276 and unnumbered identifiers for a link. Unlike TLVs 138/139 it 277 utilizes sub-TLVs to encode the link identifiers in order to provide 278 the flexible formatting required to support multiple link identifier 279 types. 281 Type: To be assigned by IANA (suggested value 238) 283 Length: Number of octets in the value field (1 octet) 285 Value: 287 Neighbor System-ID + pseudo-node ID (7 octets) 288 SRLG Set Identifier: A 32-bit value containing the non-zero SRLG 289 Set Identifier that identifies a set of SRLGs. The SRLG Set 290 Scoped SRLG TLV MUST be ignored if the SRLG Set Identifier is 291 zero. This ensures a consistent view of the SRLG set scoped 292 link attributes, where the SRLGs advertised directly in TLV#138 293 and TLV#139 are now understood to be implicitly advertised with 294 the TE Attribute Set Identifier equal to zero. 296 Length of sub-TLVs in octets (1 octet) 298 Link Identifier sub-TLVs (variable) 300 0 or more SRLG Values (Each value is 4 octets) 302 The following Link Identifier sub-TLVs are defined. The type 303 values are only suggested values. The actual values will be 304 assigned by IANA. However, as the formats are identical to 305 existing sub-TLVs defined for TLVs 22, 23, 141, 222, and 223 the 306 assignment of the suggested sub-TLV types is strongly encouraged. 308 Type Description 309 ------- ----------------------------- 310 4 Link Local/Remote Identifiers 311 6 IPv4 interface address 312 8 IPv4 neighbor address 313 12 IPv6 Interface Address 314 13 IPv6 Neighbor Address 316 At least one set of link identifiers (IPv4, IPv6, or unnumbered) MUST 317 be present. TLVs which do not meet this requirement MUST be ignored. 319 Multiple TLVs for the same link MAY be advertised. 321 7. SRLG Set usage 323 The new SRLG Set Identifier is a 32-bit value that identifies a set 324 of SRLGs. The SRLG Set Identifier with a value of zero is special. 325 Existing encodings for advertising SRLGs that do not explicitly 326 support the inclusion of the SRLG Set Identifier are now understood 327 to implicitly advertise SRLGs with the SRLG Set Identifier set to 328 zero. In this framework, existing implementations using the existing 329 encodings already support the advertisement of SRLGs with the SRLG 330 set id = 0. 332 In order to ensure a consistent view of the SRLG set scoped SRLGs, 333 for encodings that explicitly support the SRLG Set Identifier, 334 advertising an attribute with SRLG Set Identifier set to zero is not 335 allowed. 337 The SRLG set uses additive semantics. An application receiving SRLGs 338 scoped with different SRLG set identifiers will take the union of the 339 SRLGs in each SRLG set that the application is programmed to take 340 into consideration. Given the additive semantics of SRLG sets, we do 341 not use the SRLGs with SRLG set identifier = 0 as a default value in 342 the absence of other SRLGs with non-zero SRLG set identifier. 344 The following example illustrates the expected use of the advertising 345 SRLGs scoped with SRLG set identifiers. SRLGs in networks often 346 follow a natural grouping into sets. As a concrete example, assume 347 that one set of SRLGs corresponds to links within a metro area 348 (intra-city SRLGs). A second set of SRLGs corresponds to links 349 between metro area (inter-city SRLGs). A third set of SRLGs 350 corresponds to links between continents on undersea cables (inter- 351 continental SRLGs). A reasonable mapping of these natural SRLG 352 groupings to SRLG set identifier is shown below in Figure 2. The 353 network would be configured to advertise SRLGs scoped with these SRLG 354 set identifiers. 356 Natural SRLG groupings SRLG set id 357 ----------------------- ----------- 358 intra-city SRLGs 1 359 inter-city SRLGs 2 360 inter-continental SRLGs 3 362 Figure 2: Example mapping of natural SRLG groupings to SRLG set 363 identifier 365 Assume that the network operator starts out with two applications. 366 Application G should take into account all three groups of SRLGs as 367 path constraints: intra-city, inter-city, and inter-continental 368 SRLGs. Instead, application H should only take into account inter- 369 city and inter-continental SRLGs. This can be accomplished by having 370 application G use union of SRLG sets 1, 2, and 3, while application H 371 uses the union of SRLG sets 2 and 3, as shown in Figure 3. 373 Application SRLG set ids 374 ----------------------- ------------ 375 G 1+2+3 376 H 2+3 378 Figure 3: Example usage of SRLG sets by applications 380 This accomplishes the goals of the network operator in a very natural 381 way. 383 Now suppose that the network operator introduces a third application, 384 application J, that should only take into account intra-city and 385 inter-city SRLGs. This can be accomplished without modifying any of 386 the SRLG advertisements. The new application J need only be 387 programmed or configured to take use the union of SRLG sets 1 and 2, 388 as as shown in Figure 4. 390 Application SRLG set ids 391 ----------------------- ------------ 392 G 1+2+3 393 H 2+3 394 J 1+2 396 Figure 4: The simplicity of adding a new application 398 If application J is a centralized controller-based application, the 399 new application can be introduced with even touching the network 400 itself. 402 8. IANA Considerations 404 IANA is requested to create a new sub-TLV, the Link Attribute Set 405 sub-TLV for TLVs 22, 23, 141, 222, and 223. 407 Type Description 22 23 141 222 223 Ref. 408 ------- --------------------------- -- -- --- --- --- ------- 409 TBA1 Link Attribute Set sub-TLV y y y y y [This 410 draft] 412 IANA is requested to create a new TLV, the SRLG Set Scoped SRLG TLV. 414 Type Description IIH SNP LSP Purge Ref. 415 ------- ----------------------- --- --- --- ----- ------ 416 TBA2 TE Attribute Set Scoped n n y n [This 417 SRLG TLV draft] 419 9. Management Considerations 421 TBD 423 10. Security Considerations 425 TBD 427 11. Acknowledgements 429 The basic format for the encoding of the Link Attribute Set sub-TLV 430 and the TE Attribute Set Scoped SRLG TLV follows the basic format of 431 the encodings in [I-D.ginsberg-isis-te-app]. 433 12. References 435 12.1. Normative References 437 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 438 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 439 2008, . 441 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 442 in Support of Generalized Multi-Protocol Label Switching 443 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 444 . 446 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 447 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 448 February 2011, . 450 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 451 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 452 RFC 7810, DOI 10.17487/RFC7810, May 2016, 453 . 455 12.2. Informative References 457 [I-D.ginsberg-isis-te-app] 458 Ginsberg, L., Psenak, P., Previdi, S., and W. Henderickx, 459 "IS-IS TE Attributes per application", draft-ginsberg- 460 isis-te-app-00 (work in progress), February 2017. 462 Authors' Addresses 464 Chris Bowers 465 Juniper Networks 466 1194 N. Mathilda Ave. 467 Sunnyvale, CA 94089 468 US 470 Email: cbowers@juniper.net 472 Shraddha Hegde 473 Juniper Networks 474 Embassy Business Park 475 Bangalore, KA 560093 476 India 478 Email: shraddha@juniper.net