idnits 2.17.00 (12 Aug 2021) /tmp/idnits12276/draft-ietf-ospf-mpls-elc-12.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 contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [BCP14], but that reference does not seem to mention RFC 2119 either. -- The document date (October 25, 2019) is 939 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. 'BCP14' == Outdated reference: draft-ietf-idr-bgp-ls-segment-routing-ext has been published as RFC 9085 == Outdated reference: draft-ietf-idr-bgp-ls-segment-routing-msd has been published as RFC 8814 == Outdated reference: draft-ietf-isis-mpls-elc has been published as RFC 9088 == Outdated reference: draft-ietf-mpls-spring-entropy-label has been published as RFC 8662 == Outdated reference: draft-ietf-spring-segment-routing-mpls has been published as RFC 8660 == Outdated reference: draft-ietf-ospf-segment-routing-extensions has been published as RFC 8665 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OSPF Working Group X. Xu 3 Internet-Draft Alibaba Inc 4 Intended status: Standards Track S. Kini 5 Expires: April 27, 2020 6 P. Psenak 7 C. Filsfils 8 S. Litkowski 9 Cisco Systems, Inc. 10 M. Bocci 11 Nokia 12 October 25, 2019 14 Signaling Entropy Label Capability and Entropy Readable Label-stack 15 Depth Using OSPF 16 draft-ietf-ospf-mpls-elc-12 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 tunnel unless an egress LSR has indicated via signaling that it 24 has the capability to process ELs, referred to as Entropy Label 25 Capability (ELC), on that tunnel. In addition, it would be useful 26 for ingress LSRs to know each LSR's capability of reading the maximum 27 label stack depth and performing EL-based load-balancing, referred to 28 as Entropy Readable Label Depth (ERLD). This document defines a 29 mechanism to signal these two capabilities using OSPF and OSPFv3. 30 These mechanism is particularly useful in the environment where 31 Segment Routing (SR) is used, where label advertisements are done via 32 protocols like OSPF and OSPFv3. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 27, 2020. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Advertising ELC Using OSPF . . . . . . . . . . . . . . . . . 3 70 3.1. Advertising ELC Using OSPFv2 . . . . . . . . . . . . . . 4 71 3.2. Advertising ELC Using OSPFv3 . . . . . . . . . . . . . . 4 72 4. Advertising ERLD Using OSPF . . . . . . . . . . . . . . . . . 4 73 5. Signaling ELC and ERLD in BGP-LS . . . . . . . . . . . . . . 4 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 77 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 80 10.2. Informative References . . . . . . . . . . . . . . . . . 8 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 83 1. Introduction 85 [RFC6790] describes a method to load-balance Multiprotocol Label 86 Switching (MPLS) traffic flows using Entropy Labels (EL). It also 87 introduces the concept of Entropy Label Capability (ELC) and defines 88 the signaling of this capability via MPLS signaling protocols. 89 Recently, mechanisms have been defined to signal labels via link- 90 state Interior Gateway Protocols (IGP) such as OSPF 91 [I-D.ietf-ospf-segment-routing-extensions]. In such scenarios, the 92 signaling mechanisms defined in [RFC6790] are inadequate. This draft 93 defines a mechanism to signal the ELC using OSPF. This mechanism is 94 useful when the label advertisement is also done via OSPF. 96 In addition, in the cases where stacked LSPs are used for whatever 97 reasons (e.g., SR-MPLS [I-D.ietf-spring-segment-routing-mpls]), it 98 would be useful for ingress LSRs to know each intermediate LSR's 99 capability of reading the maximum label stack depth and performing 100 EL-based load-balancing. This capability, referred to as Entropy 101 Readable Label Depth (ERLD) as defined in 102 [I-D.ietf-mpls-spring-entropy-label] may be used by ingress LSRs to 103 determine the position of the EL label in the stack, and whether it's 104 necessary to insert multiple ELs at different positions in the label 105 stack. 107 2. Terminology 109 This document makes use of the terms defined in [RFC6790], [RFC7770] 110 and [I-D.ietf-mpls-spring-entropy-label]. 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in 115 [BCP14] [RFC2119] [RFC8174] when, and only when, they appear in all 116 capitals, as shown here. 118 3. Advertising ELC Using OSPF 120 Even though ELC is a property of the node, in some cases it is 121 advantageous to associate and advertise the ELC with the prefix. In 122 multi-area networks, routers may not know the identity of the prefix 123 originator in a remote area, or may not know the capabilities of such 124 originator. Similarly, in a multi domain network, the identity of 125 the prefix originator and its capabilities may not be known to the 126 ingress LSR. 128 If a router has multiple line cards, the router MUST NOT announce ELC 129 unless all of its line-cards are capable of processing ELs. 131 If the router supports ELs on all of its line cards, it SHOULD 132 advertise the ELC with every local host prefix it advertises in OSPF. 134 When an OSPF Area Border Router (ABR) advertises the prefix to the 135 connected area based on the intra-area or inter-area prefix that is 136 reachable in some other area, it MUST preserve the ELC signalling for 137 such prefix. 139 When an OSPF Autonomous System Boundary Router (ASBR) redistributes 140 the prefix from another instance of the OSPF or from some other 141 protocol, it SHOULD preserve the ELC signaling for the prefix. The 142 exact mechanism used to exchange ELC between protocol instances on 143 the ASBR is outside of the scope of this document and is 144 implementation specific. 146 3.1. Advertising ELC Using OSPFv2 148 [RFC7684] defines the OSPFv2 Extended Prefix TLV to advertise 149 additional attributes associated with a prefix. The OSPFv2 Extended 150 Prefix TLV includes a one octet Flags field. A new flag in the Flags 151 field is used to signal the ELC for the prefix: 153 0x20 - E-Flag (ELC Flag): Set by the advertising router to 154 indicate that the prefix originator is capable of processing ELs. 156 3.2. Advertising ELC Using OSPFv3 158 [RFC5340] defines the OSPFv3 PrefixOptions that are advertised along 159 with the prefix. A new bit in the OSPFV3 PrefixOptions is used to 160 signal the ELC for the prefix: 162 0x04 - E-Flag (ELC Flag): Set by the advertising router to 163 indicate that the prefix originator is capable of processing ELs. 165 4. Advertising ERLD Using OSPF 167 A new MSD (Maximum SID Depth) type of the Node MSD sub-TLV [RFC8476], 168 called ERLD is defined to advertise the ERLD of a given router. The 169 scope of the advertisement depends on the application. 171 Assignment of a MSD-Type for ERLD is defined in 172 [I-D.ietf-isis-mpls-elc]. 174 If a router has multiple line-cards with different capabilities for 175 reading the maximum label stack depth, the router MUST advertise the 176 smallest one. 178 When the ERLD MSD-Type is received in the OSPFv2 or OSPFv3 Link MSD 179 Sub-TLV, it MUST be ignored. 181 5. Signaling ELC and ERLD in BGP-LS 183 The OSPF extensions defined in this document can be advertised via 184 BGP-LS [RFC7752] using existing BGP-LS TLVs. 186 The ELC Flag included in the OSPFv2 Extended Prefix TLV and the 187 OSPFv3 PrefixOptions, as defined in Section 3, is advertised using 188 the Prefix Attribute Flags TLV (TLV 1170) of the BGP-LS IPv4/IPv6 189 Prefix NLRI Attribute as defined in section 2.3.2 of 190 [I-D.ietf-idr-bgp-ls-segment-routing-ext]. 192 The ERLD MSD-type introduced for OSPF in Section 4 is advertised 193 using the Node MSD TLV (TLV 266) of the BGP-LS Node NLRI Attribute as 194 defined in section 3 of [I-D.ietf-idr-bgp-ls-segment-routing-msd]. 196 6. Acknowledgements 198 The authors would like to thank Yimin Shen, George Swallow, Acee 199 Lindem, Les Ginsberg, Ketan Talaulikar, Jeff Tantsura , Bruno 200 Decraene and Carlos Pignataro for their valuable comments. 202 7. IANA Considerations 204 This document requests IANA to allocate one flag from the OSPFv2 205 Extended Prefix TLV Flags registry: 207 0x20 - E-Flag (ELC Flag) 209 This document requests IANA to allocate one flag from the OSPFv3 210 Prefix Options registry: 212 0x04 - E-Flag (ELC Flag) 214 8. Security Considerations 216 The security considerations as described in [RFC7770] and 217 [I-D.ietf-mpls-spring-entropy-label] are applicable to this document. 219 Incorrectly setting the E flag (ELC capable) (during origination, 220 inter-area advertisement or redistribution) may lead to black-holing 221 of the traffic on the egress node. 223 Incorrectly setting of the ERLD value may lead to poor load-balancing 224 of the traffic. 226 9. Contributors 228 The following people contributed to the content of this document and 229 should be considered as co-authors: 231 Gunter Van de Velde (editor) 232 Nokia 233 Antwerp 234 BE 236 Email: gunter.van_de_velde@nokia.com 238 Wim Henderickx 239 Nokia 240 Belgium 242 Email: wim.henderickx@nokia.com 244 Keyur Patel 245 Arrcus 246 USA 248 Email: keyur@arrcus.com 250 10. References 252 10.1. Normative References 254 [BCP14] , . 256 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 257 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 258 and M. Chen, "BGP Link-State extensions for Segment 259 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 260 (work in progress), June 2019. 262 [I-D.ietf-idr-bgp-ls-segment-routing-msd] 263 Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., 264 and N. Triantafillis, "Signaling MSD (Maximum SID Depth) 265 using Border Gateway Protocol Link-State", draft-ietf-idr- 266 bgp-ls-segment-routing-msd-09 (work in progress), October 267 2019. 269 [I-D.ietf-isis-mpls-elc] 270 Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., 271 and M. Bocci, "Signaling Entropy Label Capability and 272 Entropy Readable Label Depth Using IS-IS", draft-ietf- 273 isis-mpls-elc-10 (work in progress), October 2019. 275 [I-D.ietf-mpls-spring-entropy-label] 276 Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 277 Shakir, R., and J. Tantsura, "Entropy label for SPRING 278 tunnels", draft-ietf-mpls-spring-entropy-label-12 (work in 279 progress), July 2018. 281 [I-D.ietf-spring-segment-routing-mpls] 282 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 283 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 284 data plane", draft-ietf-spring-segment-routing-mpls-22 285 (work in progress), May 2019. 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, 289 DOI 10.17487/RFC2119, March 1997, 290 . 292 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 293 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 294 . 296 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 297 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 298 RFC 6790, DOI 10.17487/RFC6790, November 2012, 299 . 301 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 302 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 303 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 304 2015, . 306 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 307 S. Ray, "North-Bound Distribution of Link-State and 308 Traffic Engineering (TE) Information Using BGP", RFC 7752, 309 DOI 10.17487/RFC7752, March 2016, 310 . 312 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 313 S. Shaffer, "Extensions to OSPF for Advertising Optional 314 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 315 February 2016, . 317 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 318 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 319 May 2017, . 321 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 322 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 323 DOI 10.17487/RFC8476, December 2018, 324 . 326 10.2. Informative References 328 [I-D.ietf-ospf-segment-routing-extensions] 329 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 330 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 331 Extensions for Segment Routing", draft-ietf-ospf-segment- 332 routing-extensions-27 (work in progress), December 2018. 334 Authors' Addresses 336 Xiaohu Xu 337 Alibaba Inc 339 Email: xiaohu.xxh@alibaba-inc.com 341 Sriganesh Kini 343 Email: sriganeshkini@gmail.com 345 Peter Psenak 346 Cisco Systems, Inc. 347 Eurovea Centre, Central 3 348 Pribinova Street 10 349 Bratislava 81109 350 Slovakia 352 Email: ppsenak@cisco.com 354 Clarence Filsfils 355 Cisco Systems, Inc. 356 Brussels 357 Belgium 359 Email: cfilsfil@cisco.com 360 Stephane Litkowski 361 Cisco Systems, Inc. 362 La Rigourdiere 363 Cesson Sevigne 364 France 366 Email: slitkows@cisco.com 368 Matthew Bocci 369 Nokia 370 Shoppenhangers Road 371 Maidenhead, Berks 372 UK 374 Email: matthew.bocci@nokia.com