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