idnits 2.17.1 draft-ietf-ospf-mpls-elc-15.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 1, 2020) is 1418 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) == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-16 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR Working Group X. Xu 3 Internet-Draft Alibaba Inc 4 Intended status: Standards Track S. Kini 5 Expires: December 3, 2020 6 P. Psenak 7 C. Filsfils 8 S. Litkowski 9 Cisco Systems, Inc. 10 M. Bocci 11 Nokia 12 June 1, 2020 14 Signaling Entropy Label Capability and Entropy Readable Label Depth 15 Using OSPF 16 draft-ietf-ospf-mpls-elc-15 18 Abstract 20 Multiprotocol Label Switching (MPLS) has defined a mechanism to load- 21 balance traffic flows using Entropy Labels (EL). An ingress Label 22 Switching Router (LSR) cannot insert ELs for packets going into a 23 given Label Switched Path (LSP) unless an egress LSR has indicated 24 via signaling that it has the capability to process ELs, referred to 25 as the Entropy Label Capability (ELC), on that LSP. In addition, it 26 would be useful for ingress LSRs to know each LSR's capability for 27 reading the maximum label stack depth and performing EL-based load- 28 balancing, referred to as Entropy Readable Label Depth (ERLD). This 29 document defines a mechanism to signal these two capabilities using 30 OSPFv2 and OSPFv3 and BGP-LS. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on December 3, 2020. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Advertising ELC Using OSPF . . . . . . . . . . . . . . . . . 3 69 3.1. Advertising ELC Using OSPFv2 . . . . . . . . . . . . . . 3 70 3.2. Advertising ELC Using OSPFv3 . . . . . . . . . . . . . . 4 71 4. Advertising ERLD Using OSPF . . . . . . . . . . . . . . . . . 4 72 5. Signaling ELC and ERLD in BGP-LS . . . . . . . . . . . . . . 5 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 75 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 79 10.2. Informative References . . . . . . . . . . . . . . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 82 1. Introduction 84 [RFC6790] describes a method to load-balance Multiprotocol Label 85 Switching (MPLS) traffic flows using Entropy Labels (EL). It also 86 introduces the concept of Entropy Label Capability (ELC) and defines 87 the signaling of this capability via MPLS signaling protocols. 88 Recently, mechanisms have been defined to signal labels via link- 89 state Interior Gateway Protocols (IGP) such as OSPFv2 [RFC8665] and 90 OSPFv3 [RFC8666]. This draft defines a mechanism to signal the ELC 91 using OSPFv2 and OSPFv3. 93 In cases where Segment Routing (SR) is used with the MPLS Data Plane 94 (e.g., SR-MPLS [RFC8660]), it would be useful for ingress LSRs to 95 know each intermediate LSR's capability of reading the maximum label 96 stack depth and performing EL-based load-balancing. This capability, 97 referred to as Entropy Readable Label Depth (ERLD) as defined in 98 [RFC8662], may be used by ingress LSRs to determine the position of 99 the EL label in the stack, and whether it is necessary to insert 100 multiple ELs at different positions in the label stack. This 101 document defines a mechanism to signal the ERLD using OSPFv2 and 102 OSPFv3. 104 2. Terminology 106 This memo makes use of the terms defined in [RFC6790], and [RFC8662]. 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 The key word OSPF is used throughout the document to refer to both 115 OSPFv2 and OSPFv3. 117 3. Advertising ELC Using OSPF 119 Even though ELC is a property of the node, in some cases it is 120 advantageous to associate and advertise the ELC with a prefix. In 121 multi-area networks, routers may not know the identity of the prefix 122 originator in a remote area, or may not know the capabilities of such 123 originator. Similarly, in a multi domain network, the identity of 124 the prefix originator and its capabilities may not be known to the 125 ingress LSR. 127 If a router has multiple interfaces, the router MUST NOT announce ELC 128 unless all of its interfaces are capable of processing ELs. 130 If the router supports ELs on all of its interfaces, it SHOULD 131 advertise the ELC with every local host prefix it advertises in OSPF. 133 3.1. Advertising ELC Using OSPFv2 135 [RFC7684] defines the OSPFv2 Extended Prefix TLV to advertise 136 additional attributes associated with a prefix. The OSPFv2 Extended 137 Prefix TLV includes a one-octet Flags field. A new flag in the Flags 138 field is used to signal the ELC for the prefix: 140 0x20 - E-Flag (ELC Flag): Set by the advertising router to 141 indicate that the prefix originator is capable of processing ELs. 143 The ELC signaling MUST be preserved when an OSPF Area Border Router 144 (ABR) distributes information between areas. To do so, an ABR MUST 145 originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] including 146 the received ELC setting. 148 When an OSPF Autonomous System Boundary Router (ASBR) redistributes a 149 prefix from another instance of OSPF or from some other protocol, it 150 SHOULD preserve the ELC signaling for the prefix if it exists. To do 151 so, an ASBR SHOULD originate an Extended Prefix Opaque LSA [RFC7684] 152 including the ELC setting of the redistributed prefix. The flooding 153 scope of the Extended Prefix Opaque LSA MUST match the flooding scope 154 of the LSA that an ASBR originates as a result of the redistribution. 155 The exact mechanism used to exchange ELC between protocol instances 156 on an ASBR is outside of the scope of this document. 158 3.2. Advertising ELC Using OSPFv3 160 [RFC5340] defines the OSPFv3 PrefixOptions field to indicate 161 capabilities associated with a prefix. A new bit in the OSPFv3 162 PrefixOptions is used to signal the ELC for the prefix: 164 0x40 - E-Flag (ELC Flag): Set by the advertising router to 165 indicate that the prefix originator is capable of processing ELs. 167 The ELC signaling MUST be preserved when an OSPFv3 Area Border 168 Router (ABR) distributes information between areas. The setting 169 of the ELC Flag in the Inter-Area-Prefix-LSA [RFC5340] or in the 170 Inter-Area-Prefix TLV [RFC8362], generated by an ABR, MUST be the 171 same as the value the ELC Flag associated with the prefix in the 172 source area. 174 When an OSPFv3 Autonomous System Boundary Router (ASBR) 175 redistributes a prefix from another instance of OSPFv3 or from 176 some other protocol, it SHOULD preserve the ELC signaling for the 177 prefix if it exists. The setting of the ELC Flag in the AS- 178 External-LSA, NSSA-LSA [RFC5340] or in the External-Prefix TLV 179 [RFC8362], generated by an ASBR, MUST be the same as the value of 180 the ELC Flag associated with the prefix in the source domain. The 181 exact mechanism used to exchange ELC between protocol instances on 182 the ASBR is outside of the scope of this document. 184 4. Advertising ERLD Using OSPF 186 The ERLD is advertised in a Node MSD TLV [RFC8476] using the ERLD-MSD 187 type defined in [I-D.ietf-isis-mpls-elc]. 189 If a router has multiple interfaces with different capabilities of 190 reading the maximum label stack depth, the router MUST advertise the 191 smallest value found across all of its interfaces. 193 The absence of ERLD-MSD advertisements indicates only that the 194 advertising node does not support advertisement of this capability. 196 When the ERLD-MSD type is received in the OSPFv2 or OSPFv3 Link MSD 197 Sub-TLV [RFC8476], it MUST be ignored. 199 The considerations for advertising the ERLD are specified in 200 [RFC8662]. 202 5. Signaling ELC and ERLD in BGP-LS 204 The OSPF extensions defined in this document can be advertised via 205 BGP-LS (Distribution of Link-State and TE Information Using BGP) 206 [RFC7752] using existing BGP-LS TLVs. 208 The ELC is advertised using the Prefix Attribute Flags TLV as defined 209 in [I-D.ietf-idr-bgp-ls-segment-routing-ext]. 211 The ERLD-MSD is advertised using the Node MSD TLV as defined in 212 [I-D.ietf-idr-bgp-ls-segment-routing-msd]. 214 6. IANA Considerations 216 Early allocation has been done by IANA for this document as follows: 218 - Flag 0x20 in the OSPFv2 Extended Prefix TLV Flags registry has 219 been allocated by IANA to the E-Flag (ELC Flag). 221 - Bit 0x40 in the "OSPFv3 Prefix Options (8 bits)" registry has 222 been allocated by IANA to the E-Flag (ELC Flag). 224 7. Security Considerations 226 This document specifies the ability to advertise additional node 227 capabilities using OSPF and BGP-LS. As such, the security 228 considerations as described in [RFC5340], [RFC7770], [RFC7752], 229 [RFC7684], [RFC8476], [RFC8662], 230 [I-D.ietf-idr-bgp-ls-segment-routing-ext] and 231 [I-D.ietf-idr-bgp-ls-segment-routing-msd] are applicable to this 232 document. 234 Incorrectly setting the E flag during origination, propagation or 235 redistribution may lead to poor or no load-balancing of the MPLS 236 traffic or black-holing of the MPLS traffic on the egress node. 238 Incorrectly setting of the ERLD value may lead to poor or no load- 239 balancing of the MPLS traffic. 241 8. Contributors 243 The following people contributed to the content of this document and 244 should be considered as co-authors: 246 Gunter Van de Velde (editor) 247 Nokia 248 Antwerp 249 BE 251 Email: gunter.van_de_velde@nokia.com 253 Wim Henderickx 254 Nokia 255 Belgium 257 Email: wim.henderickx@nokia.com 259 Keyur Patel 260 Arrcus 261 USA 263 Email: keyur@arrcus.com 265 9. Acknowledgements 267 The authors would like to thank Yimin Shen, George Swallow, Acee 268 Lindem, Les Ginsberg, Ketan Talaulikar, Jeff Tantsura , Bruno 269 Decraene and Carlos Pignataro for their valuable comments. 271 10. References 273 10.1. Normative References 275 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 276 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 277 and M. Chen, "BGP Link-State extensions for Segment 278 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 279 (work in progress), June 2019. 281 [I-D.ietf-idr-bgp-ls-segment-routing-msd] 282 Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., 283 and N. Triantafillis, "Signaling MSD (Maximum SID Depth) 284 using Border Gateway Protocol - Link State", draft-ietf- 285 idr-bgp-ls-segment-routing-msd-18 (work in progress), May 286 2020. 288 [I-D.ietf-isis-mpls-elc] 289 Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., 290 and M. Bocci, "Signaling Entropy Label Capability and 291 Entropy Readable Label Depth Using IS-IS", draft-ietf- 292 isis-mpls-elc-13 (work in progress), May 2020. 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, 296 DOI 10.17487/RFC2119, March 1997, 297 . 299 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 300 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 301 . 303 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 304 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 305 RFC 6790, DOI 10.17487/RFC6790, November 2012, 306 . 308 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 309 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 310 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 311 2015, . 313 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 314 S. Ray, "North-Bound Distribution of Link-State and 315 Traffic Engineering (TE) Information Using BGP", RFC 7752, 316 DOI 10.17487/RFC7752, March 2016, 317 . 319 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 320 S. Shaffer, "Extensions to OSPF for Advertising Optional 321 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 322 February 2016, . 324 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 325 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 326 May 2017, . 328 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 329 F. Baker, "OSPFv3 Link State Advertisement (LSA) 330 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 331 2018, . 333 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 334 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 335 DOI 10.17487/RFC8476, December 2018, 336 . 338 [RFC8662] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 339 Shakir, R., and J. Tantsura, "Entropy Label for Source 340 Packet Routing in Networking (SPRING) Tunnels", RFC 8662, 341 DOI 10.17487/RFC8662, December 2019, 342 . 344 10.2. Informative References 346 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 347 Decraene, B., Litkowski, S., and R. Shakir, "Segment 348 Routing with the MPLS Data Plane", RFC 8660, 349 DOI 10.17487/RFC8660, December 2019, 350 . 352 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 353 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 354 Extensions for Segment Routing", RFC 8665, 355 DOI 10.17487/RFC8665, December 2019, 356 . 358 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions 359 for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, 360 December 2019, . 362 Authors' Addresses 364 Xiaohu Xu 365 Alibaba Inc 367 Email: xiaohu.xxh@alibaba-inc.com 369 Sriganesh Kini 371 Email: sriganeshkini@gmail.com 372 Peter Psenak 373 Cisco Systems, Inc. 374 Eurovea Centre, Central 3 375 Pribinova Street 10 376 Bratislava 81109 377 Slovakia 379 Email: ppsenak@cisco.com 381 Clarence Filsfils 382 Cisco Systems, Inc. 383 Brussels 384 Belgium 386 Email: cfilsfil@cisco.com 388 Stephane Litkowski 389 Cisco Systems, Inc. 390 La Rigourdiere 391 Cesson Sevigne 392 France 394 Email: slitkows@cisco.com 396 Matthew Bocci 397 Nokia 398 Shoppenhangers Road 399 Maidenhead, Berks 400 UK 402 Email: matthew.bocci@nokia.com