idnits 2.17.1 draft-ietf-ospf-mpls-elc-10.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 4, 2019) is 1667 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-08 == Outdated reference: A later version (-13) exists of draft-ietf-isis-mpls-elc-08 ** 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 6, 2020 6 P. Psenak 7 C. Filsfils 8 S. Litkowski 9 Cisco 10 October 4, 2019 12 Signaling Entropy Label Capability and Entropy Readable Label-stack 13 Depth Using OSPF 14 draft-ietf-ospf-mpls-elc-10 16 Abstract 18 Multiprotocol Label Switching (MPLS) has defined a mechanism to load- 19 balance traffic flows using Entropy Labels (EL). An ingress Label 20 Switching Router (LSR) cannot insert ELs for packets going into a 21 given tunnel unless an egress LSR has indicated via signaling that it 22 has the capability to process ELs, referred to as Entropy Label 23 Capability (ELC), on that tunnel. In addition, it would be useful 24 for ingress LSRs to know each LSR's capability of reading the maximum 25 label stack depth and performing EL-based load-balancing, referred to 26 as Entropy Readable Label Depth (ERLD). This document defines a 27 mechanism to signal these two capabilities using OSPF and OSPFv3. 28 These mechanism is particularly useful in the environment where 29 Segment Routing (SR) is used, where label advertisements are done via 30 protocols like OSPF and OSPFv3. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 36 "OPTIONAL" in this document are to be interpreted as described in 37 [BCP14] [RFC2119] [RFC8174] when, and only when, they appear in all 38 capitals, as shown here. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on April 6, 2020. 57 Copyright Notice 59 Copyright (c) 2019 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 76 3. Advertising ELC Using OSPF . . . . . . . . . . . . . . . . . 3 77 3.1. Advertising ELC Using OSPFv2 . . . . . . . . . . . . . . 4 78 3.2. Advertising ELC Using OSPFv3 . . . . . . . . . . . . . . 4 79 4. Advertising ERLD Using OSPF . . . . . . . . . . . . . . . . . 4 80 5. Signaling ELC and ERLD in BGP-LS . . . . . . . . . . . . . . 4 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 86 9.2. Informative References . . . . . . . . . . . . . . . . . 7 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 89 1. Introduction 91 [RFC6790] describes a method to load-balance Multiprotocol Label 92 Switching (MPLS) traffic flows using Entropy Labels (EL). It also 93 introduces the concept of Entropy Label Capability (ELC) and defines 94 the signaling of this capability via MPLS signaling protocols. 95 Recently, mechanisms have been defined to signal labels via link- 96 state Interior Gateway Protocols (IGP) such as OSPF 97 [I-D.ietf-ospf-segment-routing-extensions]. In such scenarios, the 98 signaling mechanisms defined in [RFC6790] are inadequate. This draft 99 defines a mechanism to signal the ELC using OSPF. This mechanism is 100 useful when the label advertisement is also done via OSPF. 102 In addition, in the cases where stacked LSPs are used for whatever 103 reasons (e.g., SR-MPLS [I-D.ietf-spring-segment-routing-mpls]), it 104 would be useful for ingress LSRs to know each intermediate LSR's 105 capability of reading the maximum label stack depth and performing 106 EL-based load-balancing. This capability, referred to as Entropy 107 Readable Label Depth (ERLD) as defined in 108 [I-D.ietf-mpls-spring-entropy-label] may be used by ingress LSRs to 109 determine the position of the EL label in the stack, and whether it's 110 necessary to insert multiple ELs at different positions in the label 111 stack. 113 2. Terminology 115 This document makes use of the terms defined in [RFC6790], [RFC7770] 116 and [I-D.ietf-mpls-spring-entropy-label]. 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. References 228 9.1. Normative References 230 [BCP14] , . 232 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 233 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 234 and M. Chen, "BGP Link-State extensions for Segment 235 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 236 (work in progress), June 2019. 238 [I-D.ietf-idr-bgp-ls-segment-routing-msd] 239 Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., 240 and N. Triantafillis, "Signaling MSD (Maximum SID Depth) 241 using Border Gateway Protocol Link-State", draft-ietf-idr- 242 bgp-ls-segment-routing-msd-08 (work in progress), 243 September 2019. 245 [I-D.ietf-isis-mpls-elc] 246 Xu, X., Kini, S., Psenak, P., Filsfils, C., and S. 247 Litkowski, "Signaling Entropy Label Capability and Entropy 248 Readable Label Depth Using IS-IS", draft-ietf-isis-mpls- 249 elc-08 (work in progress), September 2019. 251 [I-D.ietf-mpls-spring-entropy-label] 252 Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 253 Shakir, R., and J. Tantsura, "Entropy label for SPRING 254 tunnels", draft-ietf-mpls-spring-entropy-label-12 (work in 255 progress), July 2018. 257 [I-D.ietf-spring-segment-routing-mpls] 258 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 259 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 260 data plane", draft-ietf-spring-segment-routing-mpls-22 261 (work in progress), May 2019. 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, 265 DOI 10.17487/RFC2119, March 1997, 266 . 268 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 269 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 270 . 272 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 273 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 274 RFC 6790, DOI 10.17487/RFC6790, November 2012, 275 . 277 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 278 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 279 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 280 2015, . 282 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 283 S. Ray, "North-Bound Distribution of Link-State and 284 Traffic Engineering (TE) Information Using BGP", RFC 7752, 285 DOI 10.17487/RFC7752, March 2016, 286 . 288 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 289 S. Shaffer, "Extensions to OSPF for Advertising Optional 290 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 291 February 2016, . 293 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 294 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 295 May 2017, . 297 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 298 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 299 DOI 10.17487/RFC8476, December 2018, 300 . 302 9.2. Informative References 304 [I-D.ietf-ospf-segment-routing-extensions] 305 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 306 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 307 Extensions for Segment Routing", draft-ietf-ospf-segment- 308 routing-extensions-27 (work in progress), December 2018. 310 Authors' Addresses 312 Xiaohu Xu 313 Alibaba Inc 315 Email: xiaohu.xxh@alibaba-inc.com 317 Sriganesh Kini 319 Email: sriganeshkini@gmail.com 321 Peter Psenak 322 Cisco 324 Email: ppsenak@cisco.com 325 Clarence Filsfils 326 Cisco 328 Email: cfilsfil@cisco.com 330 Stephane Litkowski 331 Cisco 333 Email: sslitkows@cisco.com