idnits 2.17.1 draft-ginsberg-isis-l2bundles-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 (February 16, 2016) is 2991 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. 'IEEE802.1AX' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-06 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-07 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group L. Ginsberg 3 Internet-Draft A. Bashandy 4 Intended status: Standards Track C. Filsfils 5 Expires: August 19, 2016 S. Previdi 6 Cisco Systems 7 M. Nanduri 8 Microsoft 9 E. Aries 10 Private Contributer 11 February 16, 2016 13 Advertising L2 Bundle Member Link Attributes in IS-IS 14 draft-ginsberg-isis-l2bundles-02.txt 16 Abstract 18 There are deployments where the Layer 3 interface on which IS-IS 19 operates is a Layer 2 interface bundle. Existing IS-IS 20 advertisements only support advertising link attributes of the Layer 21 3 interface. If entities external to IS-IS wish to control traffic 22 flows on the individual physical links which comprise the Layer 2 23 interface bundle link attribute information about the bundle members 24 is required. 26 This document introduces the ability for IS-IS to advertise the link 27 attributes of layer 2 (L2) bundle members. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on August 19, 2016. 51 Copyright Notice 53 Copyright (c) 2016 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. L2 Bundle Member Attributes TLV . . . . . . . . . . . . . . . 3 70 2.1. Parallel L3 Adjacencies . . . . . . . . . . . . . . . . . 5 71 2.2. Shared Attribute sub-TLVs . . . . . . . . . . . . . . . . 5 72 3. Advertising L2 Bundle Member Adj-SIDs . . . . . . . . . . . . 5 73 3.1. L2 Bundle Member Adjacency Segment Identifier sub-TLV . . 6 74 3.2. L2 Bundle Member LAN Adjacency Segment Identifier sub-TLV 7 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 7.2. Informational References . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 There are deployments where the Layer 3 interface on which an IS-IS 86 adjacency is established is a Layer 2 interface bundle, for instance 87 a Link Aggregation Group (LAG) [IEEE802.1AX]. This reduces the 88 number of adjacencies which need to be maintained by the routing 89 protocol in cases where there are parallel links between the 90 neighbors. Entities external to IS-IS such as Path Computation 91 Elements (PCE) [RFC4655] may wish to control traffic flows on 92 individual members of the underlying Layer 2 bundle. In order to do 93 so link attribute information about individual bundle members is 94 required - but currently IS-IS only supports advertising link 95 attributes for the Layer 3 interfaces on which it operates. 97 This document introduces a new TLV to advertise link attribute 98 information for each of the L2 bundle members which comprise the 99 Layer 3 interface on which IS-IS operates. 101 [SR] introduces a new link attribute - adjacency segment identifier 102 (Adj-SID) - which can be used as an instruction to forwarding to send 103 traffic over a specific link. This document introduces additional 104 sub-TLVs to advertise Adj-SIDs for L2 Bundle members. 106 Note that the new advertisements defined in this document are 107 intended to be provided to external entities. 109 2. L2 Bundle Member Attributes TLV 111 A new TLV is introduced to advertise L2 Bundle member attributes. 112 Although much of the information is identical to and uses the same 113 sub-TLVs included in Extended IS-Neighbor advertisements (TLVs 22 and 114 222), a new TLV is used so that changes to the advertisement of the 115 L2 Bundle member link attributes does not trigger unnecessary action 116 by the [ISO10589] Decision process. 118 This new TLV utilizes the sub-TLV space defined for TLVs 22, 23, 141, 119 222, and 223. 121 The following new TLV is introduced: 123 L2 Bundle Member Attributes 124 Type: 25 (suggested - to be assigned by IANA) 125 Length: Number of octets to follow 127 Parent L3 Neighbor Descriptor 128 L3 Neighbor System ID + pseudonode ID (7 octets) 129 Flags: 1 octet field of following flags: 131 0 1 2 3 4 5 6 7 132 +-+-+-+-+-+-+-+-+ 133 |P| | 134 +-+-+-+-+-+-+-+-+ 136 where: 138 P-flag: When set to 1 one of the sub-TLVs described 139 in Section 2.1 immediately follows the flags field. 140 If the P-flag is set to 0, then none of the sub-TLVs 141 described in Section 2.1 are present. 143 Other bits: MUST be zero when originated and ignored when 144 received. 146 One or more of the following: 147 L2 Bundle Attribute Descriptors 148 Length of L2 Bundle Attribute Descriptor (1 octet) 149 NOTE: This includes all fields described below. 151 Number of L2 Bundle Member Descriptors (1 octet) 152 L2 Bundle Member Link Local Identifiers 153 (4 * Number of L2 Bundle Member Descriptors octets) 155 NOTE: An L2 Bundle Member Descriptor is a Link Local 156 Identifier as defined in [RFC5307]. 158 sub-TLV(s) 160 A sub-TLV may define an attribute common to all of 161 the bundle members listed or a sub-TLV may define an 162 attribute unique to each bundle member. Use of these 163 two classes of sub-TLVs is described in the following 164 sections. 166 NOTE: Only one Parent L3 Neighbor Descriptor is present in a given 167 TLV. Multiple L2 Bundle Attribute Descriptors may be present in a 168 single TLV. 170 2.1. Parallel L3 Adjacencies 172 When there exist multiple L3 adjacencies to the same neighbor 173 additional information is required to uniquely identify the L3 174 Neighbor. One and only one of the following three sub-TLVs is used 175 to uniquely identify the L3 adjacency: 177 o IPv4 Interface Address (sub-TLV 6 defined in [RFC5305]) 179 o IPv6 Interface Address (sub-TLV 12 defined in [RFC6119]) 181 o Link Local/Remote Identifiers (sub-TLV 4 defined in [RFC5307]) 183 When the P-bit is set in the flags field in the Parent L3 Neighbor 184 Descriptor one and only one of the above sub-TLVs MUST be present. 185 The chosen sub-TLV MUST immediately follow the flags field described 186 in Section 2. 188 These sub-TLVs MAY be omitted if no parallel adjacencies to the 189 neighbor exist. 191 2.2. Shared Attribute sub-TLVs 193 These sub-TLVs advertise a single copy of an attribute (e.g. link 194 bandwidth). The attribute applies to all of the L2 Bundle Members in 195 the set advertised under the preceding L2 Bundle Member Attribute 196 Descriptor. No more than one copy of a given sub-TLV in this 197 category may appear in the set of sub-TLVs under the preceding L2 198 Bundle Member Attribute Descriptor. If multiple copies of a given 199 sub-TLV are present both MUST be ignored. 201 The set of L2 Bundle Member Descriptors which may be advertised under 202 a single L2 Bundle Member Attribute Descriptor is therefore limited 203 to bundle members which share the set of attributes advertised in the 204 shared attribute sub-TLVs. 206 All existing sub-TLVs defined in the IANA Sub-TLVs for TLVs 22, 23, 207 141, 222, and 223 registry are in the category of shared attribute 208 sub-TLVs unless otherwise specified in this document. 210 3. Advertising L2 Bundle Member Adj-SIDs 212 [SR] defines sub-TLVs to advertise Adj-SIDs for L3 adjacencies. 213 However these sub-TLVs only support a advertisement of a single Adj- 214 SID. As it is expected that each L2 Bundle member will have unique 215 Adj-SIDs in many deployments it is desirable to define a new sub-TLV 216 which allows more efficient encoding of a set of Adj-SIDs in a single 217 sub-TLV. Two new sub-TLVs are therefore introduced to support 218 advertising Adj-SIDs for L2 Bundle members. The format of the new 219 sub-TLVs is similar to that used for L3 adjacencies, but is optimized 220 to allow advertisement of a set of Adj-SIDs (one per L2 Bundle 221 Member) in a single sub-TLV. 223 The two new sub-TLVs defined in the following sections do not fall 224 into the category of shared attribute sub-TLVs. 226 3.1. L2 Bundle Member Adjacency Segment Identifier sub-TLV 228 This sub-TLV is used to advertise Adj-SIDs for L2 Bundle Members 229 associated with a parent L3 adjacency which is Point-to-Point. The 230 following format is defined for this sub-TLV: 232 Type: 41 (suggested value to be assigned by IANA) (1 octet) 233 Length: variable (1 octet) 235 Flags: 1 octet field of following flags: 237 0 1 2 3 4 5 6 7 238 +-+-+-+-+-+-+-+-+ 239 |F|*|V|L|S| | 240 +-+-+-+-+-+-+-+-+ 242 where: 244 * - Is a flag used in the L3 Adj-SID sub-TLV but which is NOT 245 used in this sub-TLV. These bits SHOULD be sent as 0 and MUST 246 be ignored on receipt 248 F-Flag: Address-Family flag. If unset, then the Adj-SID refers 249 to an L2 Bundle Member with outgoing IPv4 encapsulation. If set 250 then the Adj-SID refers to an L2 Bundle Member with outgoing 251 IPv6 encapsulation. 253 V-Flag: Value flag. If set, then the Adj-SID carries a value. 254 By default the flag is SET. 256 L-Flag: Local Flag. If set, then the value/index carried by 257 the Adj-SID has local significance. By default the flag is 258 SET. 260 S-Flag. Set Flag. When set, the S-Flag indicates that the 261 Adj-SID refers to a set of L2 Bundle Members (and therefore 262 MAY be assigned to other L2 Bundle Members as well). 264 Other bits: MUST be zero when originated and ignored when 265 received. 267 Weight: 1 octet. The value represents the weight of the Adj-SID 268 for the purpose of load balancing. The use of the weight is 269 defined in [SR-ARCH]. 271 NOTE: Flags and weight are shared by all L2 Bundle Members 272 listed in the L2 Bundle Attribute Descriptor. 274 L2 Bundle Member Adj-SID Descriptors. There MUST be one descriptor 275 for each of the L2 Bundle Members advertised under the preceding 276 L2 Bundle Member Attribute Descriptor. Each descriptor consists 277 of one of the following fields: 279 SID/Index/Label: according to the V and L flags, it contains 280 either: 282 * A 3 octet local label where the 20 rightmost bits are used 283 for encoding the label value. In this case the V and L 284 flags MUST be set. 286 * A 4 octet index defining the offset in the SID/Label space 287 advertised by this router. See [SR]. 288 In this case V and L flags MUST be unset. 290 * A 16 octet IPv6 address. In this case the V flag MUST be 291 set. The L flag MUST be unset if the IPv6 address is 292 globally unique. 294 3.2. L2 Bundle Member LAN Adjacency Segment Identifier sub-TLV 296 This sub-TLV is used to advertise Adj-SIDs for L2 Bundle Members 297 associated with a parent L3 adjacency which is a LAN adjacency. In 298 LAN subnetworks, the Designated Intermediate System (DIS) is elected 299 and originates the Pseudonode-LSP (PN-LSP) including all neighbors of 300 the DIS. When Segment Routing is used, each router in the LAN MAY 301 advertise the Adj-SID of each of its neighbors on the LAN. 302 Similarly, for each L2 Bundle Member a router MAY advertise an Adj- 303 SID to each neighbor on the LAN. 305 The following format is defined for this sub-TLV: 307 Type: 42 (suggested value to be assigned by IANA) (1 octet) 308 Length: variable (1 octet) 309 Neighbor System ID: 6 octets 310 Flags: 1 octet field of following flags: 312 0 1 2 3 4 5 6 7 313 +-+-+-+-+-+-+-+-+ 314 |F|*|V|L|S| | 315 +-+-+-+-+-+-+-+-+ 317 where: 319 * - Is a flag used in the L3 Adj-SID sub-TLV but which is NOT 320 used in this sub-TLV. These bits SHOULD be sent as 0 and MUST 321 be ignored on receipt 323 F-Flag: Address-Family flag. If unset, then the Adj-SID refers 324 to an L2 Bundle Member with outgoing IPv4 encapsulation. If set 325 then the Adj-SID refers to an L2 Bundle Member with outgoing 326 IPv6 encapsulation. 328 V-Flag: Value flag. If set, then the Adj-SID carries a value. 329 By default the flag is SET. 331 L-Flag: Local Flag. If set, then the value/index carried by 332 the Adj-SID has local significance. By default the flag is 333 SET. 335 S-Flag. Set Flag. When set, the S-Flag indicates that the 336 Adj-SID refers to a set of L2 Bundle Members (and therefore 337 MAY be assigned to other L2 Bundle Members as well). 339 Other bits: MUST be zero when originated and ignored when 340 received. 342 Weight: 1 octet. The value represents the weight of the Adj-SID 343 for the purpose of load balancing. The use of the weight is 344 defined in [SR-ARCH]. 346 NOTE: Flags and weight are shared by all L2 Bundle Members 347 listed in the L2 Bundle Attribute Descriptor. 349 L2 Bundle Member LAN Adj-SID Descriptors. There MUST be one 350 descriptor for each of the L2 Bundle Members advertised 351 under the preceding L2 Bundle Member Attribute Descriptor. 352 Each descriptor consists of one of the following fields: 354 SID/Index/Label: according to the V and L flags, it contains 355 either: 357 * A 3 octet local label where the 20 rightmost bits are used 358 for encoding the label value. In this case the V and L 359 flags MUST be set. 361 * A 4 octet index defining the offset in the SID/Label space 362 advertised by this router. See [SR]. 363 In this case V and L flags MUST be unset. 365 * A 16 octet IPv6 address. In this case the V flag MUST be 366 set. The L flag MUST be unset if the IPv6 address is 367 globally unique. 369 4. IANA Considerations 371 This document adds the following new TLV to the IS-IS TLV Codepoints 372 registry. 374 Value: 25 (suggested - to be assigned by IANA) 376 Name: L2 Bundle Member Attributes 378 The name of the Sub-TLVs for TLVs 22, 23, 141, 222, and 223 registry 379 needs to be changed to Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 380 223 registry. An additional column needs to be added to the registry 381 to indicate which sub-TLVs may appear in the new L2 Bundle Member 382 Attributes TLV. The following table indicates the appropriate 383 settings for all currently defined sub-TLVs as regards their use in 384 the new L2 Bundle Member Attributes TLV. 386 3 Administrative group (color) y 387 4 Link Local/Remote Identifiers y 388 6 IPv4 interface address y 389 8 IPv4 neighbor address y 390 9 Maximum link bandwidth y 391 10 Maximum reservable link bandwidth y 392 11 Unreserved bandwidth y 393 12 IPv6 Interface Address y 394 13 IPv6 Neighbor Address y 395 14 Extended Administrative Group y 396 18 TE Default metric y 397 19 Link-attributes y 398 20 Link Protection Type y 399 21 Interface Switching Capability Descriptor y 400 22 Bandwidth Constraints y 401 23 Unconstrained TE LSP Count y 402 24 Remote AS number n 403 25 IPv4 remote ASBR Identifier n 404 26 IPv6 remote ASBR Identifier n 405 27 Interface Adjustment Capability Descriptor (IACD) y 406 28 MTU n 407 29 SPB-Metric y 408 30 SPB-A-OALG y 410 This document adds the following new sub-TLVs to the sub-TLVs for 411 TLVs 22, 23, 25, 141, 222, and 223 registry. 413 Value: 41 (suggested - to be assigned by IANA) 415 Name: L2 Bundle Member Adj-SID 417 This sub-TLV is allowed in the following TLVs: 419 22 23 25 141 222 223 420 n n y n n n 422 Value: 42 (suggested to be assigned by IANA) 424 Name: L2 Bundle Member LAN Adj-SID 426 This sub-TLV is allowed in the following TLVs: 428 22 23 25 141 222 223 429 n n y n n n 431 5. Security Considerations 433 None. 435 6. Acknowledgements 437 The authors would like to thank Jon MItchell for his careful review. 439 7. References 441 7.1. Normative References 443 [IEEE802.1AX] 444 Institute of Electrical and Electronics Engineers, "IEEE 445 Standard for Local and Metropolitan Area Networks - Link 446 Aggregation.", ISO/IEC 10589:2002, Second Edition, Nov 447 2008. 449 [ISO10589] 450 International Organization for Standardization, 451 "Intermediate system to Intermediate system intra-domain 452 routeing information exchange protocol for use in 453 conjunction with the protocol for providing the 454 connectionless-mode Network Service (ISO 8473)", ISO/ 455 IEC 10589:2002, Second Edition, Nov 2002. 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", BCP 14, RFC 2119, 459 DOI 10.17487/RFC2119, March 1997, 460 . 462 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 463 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 464 2008, . 466 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 467 in Support of Generalized Multi-Protocol Label Switching 468 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 469 . 471 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 472 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 473 February 2011, . 475 7.2. Informational References 477 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 478 Element (PCE)-Based Architecture", RFC 4655, 479 DOI 10.17487/RFC4655, August 2006, 480 . 482 [SR] "IS-IS Extensions for Segment Routing, draft-ietf-isis- 483 segment-routing-extensions-06(work in progress)", December 484 2015. 486 [SR-ARCH] "Segment Routing Architecture, draft-ietf-spring-segment- 487 routing-07(work in progress)", December 2015. 489 Authors' Addresses 491 Les Ginsberg 492 Cisco Systems 493 510 McCarthy Blvd. 494 Milpitas, CA 95035 495 USA 497 Email: ginsberg@cisco.com 499 Ahmed Bashandy 500 Cisco Systems 501 170 West Tasman Drive 502 San Jose, Ca 95134 503 US 505 Clarence Filsfils 506 Cisco Systems 508 Email: cf@cisco.com 510 Stefano Previdi 511 Cisco Systems 512 Via Del Serafico 200 513 Rome 0144 514 Italy 516 Email: sprevidi@cisco.com 517 Mohan Nanduri 518 Microsoft 520 Email: mnanduri@microsft.com 522 Ebben Aries 523 Private Contributer 525 Email: exa@dscp.org