idnits 2.17.1 draft-ketant-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 (June 30, 2020) is 1395 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: January 1, 2021 June 30, 2020 7 Advertising L2 Bundle Member Link Attributes in OSPF 8 draft-ketant-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 January 1, 2021. 39 Copyright Notice 41 Copyright (c) 2020 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 which 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. In order to do 77 so link attribute information about individual bundle members is 78 required. The protocol extensions defined in this document provide 79 the means to 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 OSPF route computation process. 98 The following items are intentionally not defined and/or are outside 99 the scope of this document: 101 o What link attributes will be advertised. This is determined by 102 the needs of the external entities. 104 o A minimum or default set of link attributes. 106 o How these attributes are configured 108 o How the advertisements are used 110 o What impact the use of these advertisements may have on traffic 111 flow in the network 113 o How the advertisements are passed to external entities 115 1.1. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 2. L2 Bundle Member Attributes 125 A new L2 Bundle Member Attributes sub-TLV is introduced to advertise 126 L2 Bundle member attributes in both OSPFv2 and OSPFv3. In case of 127 OSPFv2, this sub-TLV is an optional sub-TLV of the OSPFv2 Extended 128 Link TLV that is used to describe link attributes via the OSPFv2 129 Extended Link Opaque LSA [RFC7684]. In case of OSPFv3, this sub-TLV 130 is an optional sub-TLV of the Router Link TLV of the OSPFv3 E-Router- 131 LSA [RFC8362]. 133 When the OSPF adjacency is associated with L2 Bundle interface, this 134 sub-TLV is used to advertise the underlying L2 Bundle member links 135 along with their individual link attributes. Inclusion of this 136 information implies that the identified link is a member of the L2 137 bundle associated with OSPF L3 link and that the member link is 138 operationally up. Therefore advertisements of member links MUST NOT 139 be done when the member link becomes operationally down or it is no 140 longer a member of the identified L2 Bundle. 142 The L2 Bundle Member Attributes sub-TLV has the following format: 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Type | Length | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | L2 Bundle Member Descriptor | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Member Link attribute sub-TLVs (variable) // 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 Figure 1: L2 Bundle Member Attributes sub-TLV Format 156 Where: 158 Type: TBD1 for OSPFv2 and TBD2 for OSPFv3 160 Length: Variable. 162 L2 Bundle Member Descriptor: A 4 octet Link Local Identifier as 163 described in [RFC4202] and used in [RFC8510] for the member link. 165 Link attributes for L2 Bundle Member Links are advertised as sub-TLVs 166 of the L2 Bundle Member Attribute sub-TLV. 168 In the case of OSPFv2, the L2 Bundle Member Attributes sub-TLV shares 169 the sub-TLV space of the Extended Link TLV and the sub-TLVs of the 170 Extended Link TLV MAY be used to describe the attributes of the 171 member link. The Figure 2 below lists sub-TLVs and their 172 applicability for L2 Bundle member links. The sub-TLVs that are not 173 applicable MUST NOT be used as sub-TLVs for the L2 Bundle Member 174 Attributes sub-TLV. Specifications that introduce new sub-TLVs of 175 the Extended Link TLV MUST indicate their applicability for the L2 176 Bundle Member Attributes sub-TLV. An implementation MUST ignore any 177 sub-TLVs received that are not applicable in the context of the L2 178 Bundle Member Attribute sub-TLV. 180 Y - applicable 181 N - not-applicable 183 1 SID/Label (N) 184 2 Adj-SID (Y) 185 3 LAN Adj-SID/Label (Y) 186 4 Network-to-Router Metric (N) 187 5 RTM Capability (N) 188 6 OSPFv2 Link MSD (N) 189 7 Graceful-Link-Shutdown (N) 190 8 Remote IPv4 Address (N) 191 9 Local/Remote Interface ID (N) 192 10 Application Specific Link Attributes (Y) 193 11 Shared Risk Link Group (Y) 194 12 Unidirectional Link Delay (Y) 195 13 Min/Max Unidirectional Link Delay (Y) 196 14 Unidirectional Delay Variation (Y) 197 15 Unidirectional Link Loss (Y) 198 16 Unidirectional Residual Bandwidth (Y) 199 17 Unidirectional Available Bandwidth (Y) 200 18 Unidirectional Utilized Bandwidth (Y) 201 19 Administrative Group (Y) 202 20 Extended Administrative Group (Y) 203 21 Maximum Link Bandwidth (Y) 204 22 Traffic Engineering Metric (Y) 205 TBD1 L2 Bundle Member Attributes (N) 207 Figure 2: Applicability of OSPFv2 Link Attribute sub-TLVs for L2 208 Bundle Members 210 In the case of OSPFv3, the L2 Bundle Member Attributes sub-TLV shares 211 the sub-TLV space of the Router Link TLV and the sub-TLVs of the 212 Router Link TLV MAY be used to describe the attributes of the member 213 link. The Figure 3 below lists sub-TLVs that are applicable for 214 Router Link TLV and their applicability for L2 Bundle member links. 215 The sub-TLVs that are not applicable MUST NOT be used as sub-TLVs for 216 the L2 Bundle Member Attributes sub-TLV. Specifications that 217 introduce new sub-TLVs of the Router Link TLV MUST indicate their 218 applicability for the L2 Bundle Member Attributes sub-TLV. An 219 implementation MUST ignore any sub-TLVs received that are not 220 applicable in the context of the L2 Bundle Member Attribute sub-TLV. 222 Y - applicable 223 N - not-applicable 225 5 Adj-SID (Y) 226 6 LAN Adj-SID (Y) 227 7 SID/Label (N) 228 8 Graceful-Link-Shutdown (N) 229 9 OSPFv3 Link MSD (N) 230 10 Application Specific Link Attributes (Y) 231 11 Shared Risk Link Group (Y) 232 12 Unidirectional Link Delay (Y) 233 13 Min/Max Unidirectional Link Delay (Y) 234 14 Unidirectional Delay Variation (Y) 235 15 Unidirectional Link Loss (Y) 236 16 Unidirectional Residual Bandwidth (Y) 237 17 Unidirectional Available Bandwidth (Y) 238 18 Unidirectional Utilized Bandwidth (Y) 239 19 Administrative Group (Y) 240 20 Extended Administrative Group (Y) 241 21 Traffic Engineering Metric (Y) 242 22 Maximum Link Bandwidth (Y) 243 23 Local Interface IPv6 Address (N) 244 24 Remote Interface IPv6 Address (N) 245 TBD2 L2 Bundle Member Attributes (N) 247 Figure 3: Applicability of OSPFv3 Link Attribute sub-TLVs for L2 248 Bundle Members 250 3. IANA Considerations 252 This document adds new sub-TLVs to the OSPFv2 and OSPFv3 registry. 254 The following sub-TLV is added to the OSPFv2 Extended Link TLV sub- 255 TLVs registry under the OSPFv2 Parameters IANA registry: 257 Value: TBD1 259 Name: L2 Bundle Member Attributes 261 The following sub-TLV is added to the OSPFv3 Extended LSA sub-TLVs 262 registry under the OSPFv3 Parameters IANA registry: 264 Value: TBD2 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 to prevent 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 contributrions 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@cisco.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