idnits 2.17.1 draft-ginsberg-isis-l2bundles-01.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 (January 04, 2016) is 3006 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: July 7, 2016 S. Previdi 6 Cisco Systems 7 M. Nanduri 8 Microsoft 9 E. Aries 10 Facebook 11 January 04, 2016 13 Advertising L2 Bundle Member Link Attributes in IS-IS 14 draft-ginsberg-isis-l2bundles-01.txt 16 Abstract 18 This document introduces the ability for IS-IS to advertise the link 19 attributes of layer 2 (L2) bundle members. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on July 7, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. L2 Bundle Member Attributes TLV . . . . . . . . . . . . . . . 3 63 2.1. Parallel L3 Adjacencies . . . . . . . . . . . . . . . . . 5 64 2.2. Shared Attribute sub-TLVs . . . . . . . . . . . . . . . . 5 65 3. Advertising L2 Bundle Member Adj-SIDs . . . . . . . . . . . . 5 66 3.1. L2 Bundle Member Adjacency Segment Identifier sub-TLV . . 6 67 3.2. L2 Bundle Member LAN Adjacency Segment Identifier sub-TLV 7 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 73 7.2. Informational References . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 There are deployments where the Layer 3 interface on which an IS-IS 79 adjacency is established is a Layer 2 interface bundle, for instance 80 a Link Aggregation Group (LAG) [IEEE802.1AX]. This reduces the 81 number of adjacencies which need to be maintained by the routing 82 protocol in cases where there are parallel links between the 83 neighbors. However, if there is still a desire to control traffic 84 flows on individual physical links, information about each of the L2 85 bundle members is required. This document introduces a new TLV to 86 advertise link attribute information for each of the L2 bundle 87 members. 89 [SR] introduces a new link attribute - adjacency segment identifier 90 (Adj-SID) - which can be used as an instruction to forwarding to send 91 traffic over a specific link. This document introduces additional 92 sub-TLVs to advertise Adj-SIDs for L2 Bundle members. 94 2. L2 Bundle Member Attributes TLV 96 A new TLV is introduced to advertise L2 Bundle member attributes. 97 Although much of the information is identical to and uses the same 98 sub-TLVs included in Extended IS-Neighbor advertisements (TLVs 22 and 99 222), a new TLV is used so that changes to the advertisement of the 100 L2 Bundle member link attributes does not trigger unnecessary action 101 by the [ISO10589] Decision process. 103 This new TLV utilizes the sub-TLV space defined for TLVs 22, 23, 141, 104 222, and 223. 106 The following new TLV is introduced: 108 L2 Bundle Member Attributes 109 Type: 25 (suggested - to be assigned by IANA) 110 Length: Number of octets to follow 112 Parent L3 Neighbor Descriptor 113 L3 Neighbor System ID + pseudonode ID (7 octets) 114 Flags: 1 octet field of following flags: 116 0 1 2 3 4 5 6 7 117 +-+-+-+-+-+-+-+-+ 118 |P| | 119 +-+-+-+-+-+-+-+-+ 121 where: 123 P-flag: When set to 1 one of the sub-TLVs described 124 in Section 2.1 immediately follows the flags field. 125 If the P-flag is set to 0, then none of the sub-TLVs 126 described in Section 2.1 are present. 128 Other bits: MUST be zero when originated and ignored when 129 received. 131 One or more of the following: 132 L2 Bundle Attribute Descriptors 133 Length of L2 Bundle Attribute Descriptor (1 octet) 134 NOTE: This includes all fields described below. 136 Number of L2 Bundle Member Descriptors (1 octet) 137 L2 Bundle Member Link Local Identifiers 138 (4 * Number of L2 Bundle Member Descriptors octets) 140 NOTE: An L2 Bundle Member Descriptor is a Link Local 141 Identifier as defined in [RFC5307]. 143 sub-TLV(s) 145 A sub-TLV may define an attribute common to all of 146 the bundle members listed or a sub-TLV may define an 147 attribute unique to each bundle member. Use of these 148 two classes of sub-TLVs is described in the following 149 sections. 151 NOTE: Only one Parent L3 Neighbor Descriptor is present in a given 152 TLV. Multiple L2 Bundle Attribute Descriptors may be present in a 153 single TLV. 155 2.1. Parallel L3 Adjacencies 157 When there exist multiple L3 adjacencies to the same neighbor 158 additional information is required to uniquely identify the L3 159 Neighbor. One and only one of the following three sub-TLVs is used 160 to uniquely identify the L3 adjacency: 162 o IPv4 Interface Address (sub-TLV 6 defined in [RFC5305]) 164 o IPv6 Interface Address (sub-TLV 12 defined in [RFC6119]) 166 o Link Local/Remote Identifiers (sub-TLV 4 defined in [RFC5307]) 168 When the P-bit is set in the flags field in the Parent L3 Neighbor 169 Descriptor one and only one of the above sub-TLVs MUST be present. 170 The chosen sub-TLV MUST immediately follow the flags field described 171 in Section 2. 173 These sub-TLVs MAY be omitted if no parallel adjacencies to the 174 neighbor exist. 176 2.2. Shared Attribute sub-TLVs 178 These sub-TLVs advertise a single copy of an attribute (e.g. link 179 bandwidth). The attribute applies to all of the L2 Bundle Members in 180 the set advertised under the preceding L2 Bundle Member Attribute 181 Descriptor. No more than one copy of a given sub-TLV in this 182 category may appear in the set of sub-TLVs under the preceding L2 183 Bundle Member Attribute Descriptor. If multiple copies of a given 184 sub-TLV are present both MUST be ignored. 186 The set of L2 Bundle Member Descriptors which may be advertised under 187 a single L2 Bundle Member Attribute Descriptor is therefore limited 188 to bundle members which share the set of attributes advertised in the 189 shared attribute sub-TLVs. 191 All existing sub-TLVs defined in the IANA Sub-TLVs for TLVs 22, 23, 192 141, 222, and 223 registry are in the category of shared attribute 193 sub-TLVs unless otherwise specified in this document. 195 3. Advertising L2 Bundle Member Adj-SIDs 197 [SR] defines sub-TLVs to advertise Adj-SIDs for L3 adjacencies. 198 However these sub-TLVs only support a advertisement of a single Adj- 199 SID. As it is expected that each L2 Bundle member will have unique 200 Adj-SIDs in many deployments it is desirable to define a new sub-TLV 201 which allows more efficient encoding of a set of Adj-SIDs in a single 202 sub-TLV. Two new sub-TLVs are therefore introduced to support 203 advertising Adj-SIDs for L2 Bundle members. The format of the new 204 sub-TLVs is similar to that used for L3 adjacencies, but is optimized 205 to allow advertisement of a set of Adj-SIDs (one per L2 Bundle 206 Member) in a single sub-TLV. 208 The two new sub-TLVs defined in the following sections do not fall 209 into the category of shared attribute sub-TLVs. 211 3.1. L2 Bundle Member Adjacency Segment Identifier sub-TLV 213 This sub-TLV is used to advertise Adj-SIDs for L2 Bundle Members 214 associated with a parent L3 adjacency which is Point-to-Point. The 215 following format is defined for this sub-TLV: 217 Type: 41 (suggested value to be assigned by IANA) (1 octet) 218 Length: variable (1 octet) 220 Flags: 1 octet field of following flags: 222 0 1 2 3 4 5 6 7 223 +-+-+-+-+-+-+-+-+ 224 |F|*|V|L|S| | 225 +-+-+-+-+-+-+-+-+ 227 where: 229 * - Is a flag used in the L3 Adj-SID sub-TLV but which is NOT 230 used in this sub-TLV. These bits SHOULD be sent as 0 and MUST 231 be ignored on receipt 233 F-Flag: Address-Family flag. If unset, then the Adj-SID refers 234 to an L2 Bundle Member with outgoing IPv4 encapsulation. If set 235 then the Adj-SID refers to an L2 Bundle Member with outgoing 236 IPv6 encapsulation. 238 V-Flag: Value flag. If set, then the Adj-SID carries a value. 239 By default the flag is SET. 241 L-Flag: Local Flag. If set, then the value/index carried by 242 the Adj-SID has local significance. By default the flag is 243 SET. 245 S-Flag. Set Flag. When set, the S-Flag indicates that the 246 Adj-SID refers to a set of L2 Bundle Members (and therefore 247 MAY be assigned to other L2 Bundle Members as well). 249 Other bits: MUST be zero when originated and ignored when 250 received. 252 Weight: 1 octet. The value represents the weight of the Adj-SID 253 for the purpose of load balancing. The use of the weight is 254 defined in [SR-ARCH]. 256 NOTE: Flags and weight are shared by all L2 Bundle Members 257 listed in the L2 Bundle Attribute Descriptor. 259 L2 Bundle Member Adj-SID Descriptors. There MUST be one descriptor 260 for each of the L2 Bundle Members advertised under the preceding 261 L2 Bundle Member Attribute Descriptor. Each descriptor consists 262 of one of the following fields: 264 SID/Index/Label: according to the V and L flags, it contains 265 either: 267 * A 3 octet local label where the 20 rightmost bits are used 268 for encoding the label value. In this case the V and L 269 flags MUST be set. 271 * A 4 octet index defining the offset in the SID/Label space 272 advertised by this router. See [SR]. 273 In this case V and L flags MUST be unset. 275 * A 16 octet IPv6 address. In this case the V flag MUST be 276 set. The L flag MUST be unset if the IPv6 address is 277 globally unique. 279 3.2. L2 Bundle Member LAN Adjacency Segment Identifier sub-TLV 281 This sub-TLV is used to advertise Adj-SIDs for L2 Bundle Members 282 associated with a parent L3 adjacency which is a LAN adjacency. In 283 LAN subnetworks, the Designated Intermediate System (DIS) is elected 284 and originates the Pseudonode-LSP (PN-LSP) including all neighbors of 285 the DIS. When Segment Routing is used, each router in the LAN MAY 286 advertise the Adj-SID of each of its neighbors on the LAN. 287 Similarly, for each L2 Bundle Member a router MAY advertise an Adj- 288 SID to each neighbor on the LAN. 290 The following format is defined for this sub-TLV: 292 Type: 42 (suggested value to be assigned by IANA) (1 octet) 293 Length: variable (1 octet) 294 Neighbor System ID: 6 octets 295 Flags: 1 octet field of following flags: 297 0 1 2 3 4 5 6 7 298 +-+-+-+-+-+-+-+-+ 299 |F|*|V|L|S| | 300 +-+-+-+-+-+-+-+-+ 302 where: 304 * - Is a flag used in the L3 Adj-SID sub-TLV but which is NOT 305 used in this sub-TLV. These bits SHOULD be sent as 0 and MUST 306 be ignored on receipt 308 F-Flag: Address-Family flag. If unset, then the Adj-SID refers 309 to an L2 Bundle Member with outgoing IPv4 encapsulation. If set 310 then the Adj-SID refers to an L2 Bundle Member with outgoing 311 IPv6 encapsulation. 313 V-Flag: Value flag. If set, then the Adj-SID carries a value. 314 By default the flag is SET. 316 L-Flag: Local Flag. If set, then the value/index carried by 317 the Adj-SID has local significance. By default the flag is 318 SET. 320 S-Flag. Set Flag. When set, the S-Flag indicates that the 321 Adj-SID refers to a set of L2 Bundle Members (and therefore 322 MAY be assigned to other L2 Bundle Members as well). 324 Other bits: MUST be zero when originated and ignored when 325 received. 327 Weight: 1 octet. The value represents the weight of the Adj-SID 328 for the purpose of load balancing. The use of the weight is 329 defined in [SR-ARCH]. 331 NOTE: Flags and weight are shared by all L2 Bundle Members 332 listed in the L2 Bundle Attribute Descriptor. 334 L2 Bundle Member LAN Adj-SID Descriptors. There MUST be one 335 descriptor for each of the L2 Bundle Members advertised 336 under the preceding L2 Bundle Member Attribute Descriptor. 337 Each descriptor consists of one of the following fields: 339 SID/Index/Label: according to the V and L flags, it contains 340 either: 342 * A 3 octet local label where the 20 rightmost bits are used 343 for encoding the label value. In this case the V and L 344 flags MUST be set. 346 * A 4 octet index defining the offset in the SID/Label space 347 advertised by this router. See [SR]. 348 In this case V and L flags MUST be unset. 350 * A 16 octet IPv6 address. In this case the V flag MUST be 351 set. The L flag MUST be unset if the IPv6 address is 352 globally unique. 354 4. IANA Considerations 356 This document adds the following new TLV to the IS-IS TLV Codepoints 357 registry. 359 Value: 25 (suggested - to be assigned by IANA) 361 Name: L2 Bundle Member Attributes 363 The name of the Sub-TLVs for TLVs 22, 23, 141, 222, and 223 registry 364 needs to be changed to Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 365 223 registry. An additional column needs to be added to the registry 366 to indicate which sub-TLVs may appear in the new L2 Bundle Member 367 Attributes TLV. The following table indicates the appropriate 368 settings for all currently defined sub-TLVs as regards their use in 369 the new L2 Bundle Member Attributes TLV. 371 3 Administrative group (color) y 372 4 Link Local/Remote Identifiers y 373 6 IPv4 interface address y 374 8 IPv4 neighbor address y 375 9 Maximum link bandwidth y 376 10 Maximum reservable link bandwidth y 377 11 Unreserved bandwidth y 378 12 IPv6 Interface Address y 379 13 IPv6 Neighbor Address y 380 14 Extended Administrative Group y 381 18 TE Default metric y 382 19 Link-attributes y 383 20 Link Protection Type y 384 21 Interface Switching Capability Descriptor y 385 22 Bandwidth Constraints y 386 23 Unconstrained TE LSP Count y 387 24 Remote AS number n 388 25 IPv4 remote ASBR Identifier n 389 26 IPv6 remote ASBR Identifier n 390 27 Interface Adjustment Capability Descriptor (IACD) y 391 28 MTU n 392 29 SPB-Metric y 393 30 SPB-A-OALG y 395 This document adds the following new sub-TLVs to the sub-TLVs for 396 TLVs 22, 23, 25, 141, 222, and 223 registry. 398 Value: 41 (suggested - to be assigned by IANA) 400 Name: L2 Bundle Member Adj-SID 402 This sub-TLV is allowed in the following TLVs: 404 22 23 25 141 222 223 405 n n y n n n 407 Value: 42 (suggested to be assigned by IANA) 409 Name: L2 Bundle Member LAN Adj-SID 411 This sub-TLV is allowed in the following TLVs: 413 22 23 25 141 222 223 414 n n y n n n 416 5. Security Considerations 418 None. 420 6. Acknowledgements 422 The authors would like to thank Jon MItchell for his careful review. 424 7. References 426 7.1. Normative References 428 [IEEE802.1AX] 429 Institute of Electrical and Electronics Engineers, "IEEE 430 Standard for Local and Metropolitan Area Networks - Link 431 Aggregation.", ISO/IEC 10589:2002, Second Edition, Nov 432 2008. 434 [ISO10589] 435 International Organization for Standardization, 436 "Intermediate system to Intermediate system intra-domain 437 routeing information exchange protocol for use in 438 conjunction with the protocol for providing the 439 connectionless-mode Network Service (ISO 8473)", ISO/ 440 IEC 10589:2002, Second Edition, Nov 2002. 442 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 443 Requirement Levels", BCP 14, RFC 2119, 444 DOI 10.17487/RFC2119, March 1997, 445 . 447 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 448 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 449 2008, . 451 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 452 in Support of Generalized Multi-Protocol Label Switching 453 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 454 . 456 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 457 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 458 February 2011, . 460 7.2. Informational References 462 [SR] "IS-IS Extensions for Segment Routing, draft-ietf-isis- 463 segment-routing-extensions-06(work in progress)", December 464 2015. 466 [SR-ARCH] "Segment Routing Architecture, draft-ietf-spring-segment- 467 routing-07(work in progress)", December 2015. 469 Authors' Addresses 471 Les Ginsberg 472 Cisco Systems 473 510 McCarthy Blvd. 474 Milpitas, CA 95035 475 USA 477 Email: ginsberg@cisco.com 479 Ahmed Bashandy 480 Cisco Systems 481 170 West Tasman Drive 482 San Jose, Ca 95134 483 US 485 Clarence Filsfils 486 Cisco Systems 488 Email: cf@cisco.com 490 Stefano Previdi 491 Cisco Systems 492 Via Del Serafico 200 493 Rome 0144 494 Italy 496 Email: sprevidi@cisco.com 498 Mohan Nanduri 499 Microsoft 501 Email: mnanduri@microsft.com 502 Ebben Aries 503 Facebook 505 Email: exa@fb.com