idnits 2.17.1 draft-ietf-lsr-ospf-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 (October 22, 2021) is 888 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' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Link State Routing K. Talaulikar 3 Internet-Draft P. Psenak 4 Intended status: Standards Track Cisco Systems 5 Expires: April 25, 2022 October 22, 2021 7 Advertising L2 Bundle Member Link Attributes in OSPF 8 draft-ietf-lsr-ospf-l2bundles-02 10 Abstract 12 There are deployments where the Layer 3 interface on which OSPF 13 operates is a Layer 2 interface bundle. Existing OSPF advertisements 14 only support advertising link attributes of the Layer 3 interface. 15 If entities external to OSPF wish to control traffic flows on the 16 individual physical links which comprise the Layer 2 interface bundle 17 link attribute information about the bundle members is required. 19 This document introduces the ability for OSPF to advertise the link 20 attributes of layer 2 (L2) Bundle members. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 25, 2022. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. L2 Bundle Member Attributes . . . . . . . . . . . . . . . . . 3 59 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 64 6.2. Informational References . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 67 1. Introduction 69 There are deployments where the Layer 3 interface on which an OSPF 70 adjacency is established is a Layer 2 interface bundle, for instance 71 a Link Aggregation Group (LAG) [IEEE802.1AX]. This reduces the 72 number of adjacencies that need to be maintained by the routing 73 protocol in cases where there are parallel links between the 74 neighbors. Entities external to OSPF such as Path Computation 75 Elements (PCE) [RFC4655] may wish to control traffic flows on 76 individual members of the underlying Layer 2 bundle. To do so, link 77 attribute information about individual bundle members is required. 78 The protocol extensions defined in this document provide the means to 79 advertise this information. 81 This document introduces new sub-TLVs to advertise link attribute 82 information for each of the L2 Bundle members which comprise the 83 Layer 3 interface on which OSPF operates. Similar capabilities were 84 introduced in IS-IS via [RFC8668]. 86 [RFC8665] and [RFC8666] introduced the adjacency segment identifier 87 (Adj-SID) link attribute for OSPFv2 and OSPFv3 respectively which can 88 be used as an instruction to forwarding to send traffic over a 89 specific link [RFC8402]. This document enables the advertisement of 90 the Adj-SIDs using the same Adjacency SID sub-TLV at the granularity 91 level of each L2 Bundle member link so that traffic may be steered 92 over that specific member link. 94 Note that the new advertisements at the L2 Bundle member link level 95 in this document are intended to be provided to external (to OSPF) 96 entities and does not alter or change the OSPF route computation 97 process. The following items are intentionally not defined and/or 98 are outside the scope of this document: 100 o What link attributes will be advertised. This is determined by 101 the needs of the external entities. 103 o A minimum or default set of link attributes. 105 o How these attributes are configured 107 o How the advertisements are used 109 o What impact the use of these advertisements may have on traffic 110 flow in the network 112 o How the advertisements are passed to external entities 114 1.1. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in BCP 119 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 2. L2 Bundle Member Attributes 124 A new L2 Bundle Member Attributes sub-TLV is introduced to advertise 125 L2 Bundle member attributes in both OSPFv2 and OSPFv3. In the case 126 of OSPFv2, this sub-TLV is an optional sub-TLV of the OSPFv2 Extended 127 Link TLV that is used to describe link attributes via the OSPFv2 128 Extended Link Opaque LSA [RFC7684]. In case of OSPFv3, this sub-TLV 129 is an optional sub-TLV of the Router Link TLV of the OSPFv3 E-Router- 130 LSA [RFC8362]. 132 When the OSPF adjacency is associated with an L2 Bundle interface, 133 this sub-TLV is used to advertise the underlying L2 Bundle member 134 links along with their respective link attributes. Inclusion of this 135 information implies that the identified link is a member of the L2 136 bundle associated with an OSPF L3 link and that the member link is 137 operationally up. Therefore advertisements of member links MUST NOT 138 be done when the member link becomes operationally down or it is no 139 longer a member of the identified L2 Bundle. 141 The L2 Bundle Member Attributes sub-TLV has the following format: 143 0 1 2 3 144 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Type | Length | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | L2 Bundle Member Descriptor | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Member Link attribute sub-TLVs (variable) // 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 Figure 1: L2 Bundle Member Attributes sub-TLV Format 155 Where: 157 Type: 24 for OSPFv2 and 29 for OSPFv3 159 Length: Variable. 161 L2 Bundle Member Descriptor: A 4 octet Link Local Identifier as 162 described in [RFC4202] and used in [RFC8510] for the member link. 164 Link attributes for L2 Bundle Member Links are advertised as sub-TLVs 165 of the L2 Bundle Member Attribute sub-TLV. 167 In the case of OSPFv2, the L2 Bundle Member Attributes sub-TLV shares 168 the sub-TLV space of the Extended Link TLV and the sub-TLVs of the 169 Extended Link TLV MAY be used to describe the attributes of the 170 member link. Figure 2 below lists sub-TLVs and their applicability 171 for L2 Bundle member links. The sub-TLVs that are not applicable 172 MUST NOT be used as sub-TLVs for the L2 Bundle Member Attributes sub- 173 TLV. Specifications that introduce new sub-TLVs of the Extended Link 174 TLV MUST indicate their applicability for the L2 Bundle Member 175 Attributes sub-TLV. An implementation MUST ignore any sub-TLVs 176 received that are not applicable in the context of the L2 Bundle 177 Member Attribute sub-TLV. 179 Y - applicable 180 N - not-applicable 182 1 SID/Label (N) 183 2 Adj-SID (Y) 184 3 LAN Adj-SID/Label (Y) 185 4 Network-to-Router Metric (N) 186 5 RTM Capability (N) 187 6 OSPFv2 Link MSD (N) 188 7 Graceful-Link-Shutdown (N) 189 8 Remote IPv4 Address (N) 190 9 Local/Remote Interface ID (N) 191 10 Application Specific Link Attributes (Y) 192 11 Shared Risk Link Group (Y) 193 12 Unidirectional Link Delay (Y) 194 13 Min/Max Unidirectional Link Delay (Y) 195 14 Unidirectional Delay Variation (Y) 196 15 Unidirectional Link Loss (Y) 197 16 Unidirectional Residual Bandwidth (Y) 198 17 Unidirectional Available Bandwidth (Y) 199 18 Unidirectional Utilized Bandwidth (Y) 200 19 Administrative Group (Y) 201 20 Extended Administrative Group (Y) 202 21 Maximum Link Bandwidth (Y) 203 22 Traffic Engineering Metric (Y) 204 24 L2 Bundle Member Attributes (N) 206 Figure 2: Applicability of OSPFv2 Link Attribute sub-TLVs for L2 207 Bundle Members 209 In the case of OSPFv3, the L2 Bundle Member Attributes sub-TLV shares 210 the sub-TLV space of the Router Link TLV and the sub-TLVs of the 211 Router Link TLV MAY be used to describe the attributes of the member 212 link. Figure 3 below lists sub-TLVs that are applicable for Router 213 Link TLV and their applicability for L2 Bundle member links. The 214 sub-TLVs that are not applicable MUST NOT be used as sub-TLVs for the 215 L2 Bundle Member Attributes sub-TLV. Specifications that introduce 216 new sub-TLVs of the Router Link TLV MUST indicate their applicability 217 for the L2 Bundle Member Attributes sub-TLV. An implementation MUST 218 ignore any sub-TLVs received that are not applicable in the context 219 of the L2 Bundle Member Attribute sub-TLV. 221 Y - applicable 222 N - not-applicable 224 5 Adj-SID (Y) 225 6 LAN Adj-SID (Y) 226 7 SID/Label (N) 227 8 Graceful-Link-Shutdown (N) 228 9 OSPFv3 Link MSD (N) 229 10 Application Specific Link Attributes (Y) 230 11 Shared Risk Link Group (Y) 231 12 Unidirectional Link Delay (Y) 232 13 Min/Max Unidirectional Link Delay (Y) 233 14 Unidirectional Delay Variation (Y) 234 15 Unidirectional Link Loss (Y) 235 16 Unidirectional Residual Bandwidth (Y) 236 17 Unidirectional Available Bandwidth (Y) 237 18 Unidirectional Utilized Bandwidth (Y) 238 19 Administrative Group (Y) 239 20 Extended Administrative Group (Y) 240 21 Traffic Engineering Metric (Y) 241 22 Maximum Link Bandwidth (Y) 242 23 Local Interface IPv6 Address (N) 243 24 Remote Interface IPv6 Address (N) 244 29 L2 Bundle Member Attributes (N) 246 Figure 3: Applicability of OSPFv3 Link Attribute sub-TLVs for L2 247 Bundle Members 249 3. IANA Considerations 251 This document adds new sub-TLVs to the OSPFv2 and OSPFv3 registry. 253 The following code-point has been assigned via early allocation in 254 the OSPFv2 Extended Link TLV sub-TLVs registry under the OSPFv2 255 Parameters IANA registry: 257 Value: 24 259 Name: L2 Bundle Member Attributes 261 The following code-point has been assigned via early allocation in 262 the OSPFv3 Extended LSA sub-TLVs registry under the OSPFv3 Parameters 263 IANA registry: 265 Value: 29 266 Name: L2 Bundle Member Attributes 268 4. Security Considerations 270 The OSPF protocol has supported the advertisement of link attribute 271 information, including link identifiers, for many years. The 272 advertisements defined in this document are identical to existing 273 advertisements defined in [RFC3630], [RFC4203], [RFC5329], [RFC7471], 274 [RFC8665] and [RFC8666] - but are associated with L2 links which are 275 part of a bundle interface on which the OSPF protocol operates. 276 There are therefore no new security issues introduced by the 277 extensions in this document. 279 As always, if the protocol is used in an environment where 280 unauthorized access to the physical links on which OSPF packets are 281 sent occurs then attacks are possible. The use of authentication as 282 defined in [RFC5709], [RFC7474], [RFC4552] and [RFC7166] is 283 recommended for preventing such attacks. 285 5. Acknowledgements 287 This document leverages the similar work done for IS-IS and the 288 authors of this document would like to acknowledge the contributions 289 of the authors of [RFC8668]. 291 6. References 293 6.1. Normative References 295 [IEEE802.1AX] 296 Institute of Electrical and Electronics Engineers, "IEEE 297 Standard for Local and Metropolitan Area Networks - Link 298 Aggregation.", Nov 2008. 300 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 301 Requirement Levels", BCP 14, RFC 2119, 302 DOI 10.17487/RFC2119, March 1997, 303 . 305 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 306 in Support of Generalized Multi-Protocol Label Switching 307 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 308 . 310 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 311 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 312 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 313 2015, . 315 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 316 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 317 May 2017, . 319 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 320 F. Baker, "OSPFv3 Link State Advertisement (LSA) 321 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 322 2018, . 324 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 325 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 326 Extensions for Segment Routing", RFC 8665, 327 DOI 10.17487/RFC8665, December 2019, 328 . 330 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions 331 for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, 332 December 2019, . 334 6.2. Informational References 336 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 337 (TE) Extensions to OSPF Version 2", RFC 3630, 338 DOI 10.17487/RFC3630, September 2003, 339 . 341 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 342 Support of Generalized Multi-Protocol Label Switching 343 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 344 . 346 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 347 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 348 . 350 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 351 Element (PCE)-Based Architecture", RFC 4655, 352 DOI 10.17487/RFC4655, August 2006, 353 . 355 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 356 "Traffic Engineering Extensions to OSPF Version 3", 357 RFC 5329, DOI 10.17487/RFC5329, September 2008, 358 . 360 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 361 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 362 Authentication", RFC 5709, DOI 10.17487/RFC5709, October 363 2009, . 365 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 366 Authentication Trailer for OSPFv3", RFC 7166, 367 DOI 10.17487/RFC7166, March 2014, 368 . 370 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 371 Previdi, "OSPF Traffic Engineering (TE) Metric 372 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 373 . 375 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 376 "Security Extension for OSPFv2 When Using Manual Key 377 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 378 . 380 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 381 Decraene, B., Litkowski, S., and R. Shakir, "Segment 382 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 383 July 2018, . 385 [RFC8510] Psenak, P., Ed., Talaulikar, K., Henderickx, W., and P. 386 Pillay-Esnault, "OSPF Link-Local Signaling (LLS) 387 Extensions for Local Interface ID Advertisement", 388 RFC 8510, DOI 10.17487/RFC8510, January 2019, 389 . 391 [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, 392 M., and E. Aries, "Advertising Layer 2 Bundle Member Link 393 Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, 394 December 2019, . 396 Authors' Addresses 398 Ketan Talaulikar 399 Cisco Systems 400 India 402 Email: ketant.ietf@gmail.com 403 Peter Psenak 404 Cisco Systems 405 Apollo Business Center 406 Mlynske nivy 43 407 Bratislava 821 09 408 Slovakia 410 Email: ppsenak@cisco.com