idnits 2.17.1 draft-ietf-ospf-mpls-elc-09.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 (September 3, 2019) is 1697 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 == Outdated reference: A later version (-13) exists of draft-ietf-isis-mpls-elc-07 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: March 6, 2020 6 P. Psenak 7 C. Filsfils 8 Cisco 9 S. Litkowski 10 Orange 11 September 3, 2019 13 Signaling Entropy Label Capability and Entropy Readable Label-stack 14 Depth Using OSPF 15 draft-ietf-ospf-mpls-elc-09 17 Abstract 19 Multiprotocol Label Switching (MPLS) has defined a mechanism to load- 20 balance traffic flows using Entropy Labels (EL). An ingress Label 21 Switching Router (LSR) cannot insert ELs for packets going into a 22 given tunnel unless an egress LSR has indicated via signaling that it 23 has the capability to process ELs, referred to as Entropy Label 24 Capability (ELC), on that tunnel. In addition, it would be useful 25 for ingress LSRs to know each LSR's capability of reading the maximum 26 label stack depth and performing EL-based load-balancing, referred to 27 as Entropy Readable Label Depth (ERLD). This document defines a 28 mechanism to signal these two capabilities using OSPF and OSPFv3. 29 These mechanism is particularly useful in the environment where 30 Segment Routing (SR) is used, where label advertisements are done via 31 protocols like OSPF and OSPFv3. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in RFC 2119 [RFC2119]. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on March 6, 2020. 56 Copyright Notice 58 Copyright (c) 2019 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 3. Advertising ELC Using OSPF . . . . . . . . . . . . . . . . . 3 76 3.1. Advertising ELC Using OSPFv2 . . . . . . . . . . . . . . 4 77 3.2. Advertising ELC Using OSPFv3 . . . . . . . . . . . . . . 4 78 4. Advertising ERLD Using OSPF . . . . . . . . . . . . . . . . . 4 79 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 80 6. BGP-LS Extension . . . . . . . . . . . . . . . . . . . . . . 4 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 85 9.2. Informative References . . . . . . . . . . . . . . . . . 7 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 88 1. Introduction 90 [RFC6790] describes a method to load-balance Multiprotocol Label 91 Switching (MPLS) traffic flows using Entropy Labels (EL). It also 92 introduces the concept of Entropy Label Capability (ELC) and defines 93 the signaling of this capability via MPLS signaling protocols. 94 Recently, mechanisms have been defined to signal labels via link- 95 state Interior Gateway Protocols (IGP) such as OSPF 96 [I-D.ietf-ospf-segment-routing-extensions]. In such scenarios, the 97 signaling mechanisms defined in [RFC6790] are inadequate. This draft 98 defines a mechanism to signal the ELC using OSPF. This mechanism is 99 useful when the label advertisement is also done via OSPF. 101 In addition, in the cases where stacked LSPs are used for whatever 102 reasons (e.g., SR-MPLS [I-D.ietf-spring-segment-routing-mpls]), it 103 would be useful for ingress LSRs to know each intermediate LSR's 104 capability of reading the maximum label stack depth and performing 105 EL-based load-balancing. This capability, referred to as Entropy 106 Readable Label Depth (ERLD) as defined in 107 [I-D.ietf-mpls-spring-entropy-label] may be used by ingress LSRs to 108 determine the position of the EL label in the stack, and whether it's 109 necessary to insert multiple ELs at different positions in the label 110 stack. 112 2. Terminology 114 This document makes use of the terms defined in [RFC6790] and 115 [RFC7770]. 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 the 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 line cards, the router MUST NOT announce ELC 128 unless all of its line-cards are capable of processing ELs. 130 If the router supports ELs on all of its line cards, it SHOULD 131 advertise the ELC with every local host prefix it advertises in OSPF. 133 When an OSPF Area Border Router (ABR) advertises the prefix to the 134 connected area based on the intra-area or inter-area prefix that is 135 reachable in some other area, it MUST preserve the ELC signalling for 136 such prefix. 138 When an OSPF Autonomous System Boundary Router (ASBR) redistributes 139 the prefix from another instance of the OSPF or from some other 140 protocol, it SHOULD preserve the ELC signaling for the prefix. The 141 exact mechanism used to exchange ELC between protocol instances on 142 the ASBR is outside of the scope of this document and is 143 implementation specific. 145 3.1. Advertising ELC Using OSPFv2 147 [RFC7684] defines the OSPFv2 Extended Prefix TLV to advertise 148 additional attributes associated with a prefix. The OSPFv2 Extended 149 Prefix TLV includes a one octet Flags field. A new flag in the Flags 150 field is used to signal the ELC for the prefix: 152 0x20 - E-Flag (ELC Flag): Set by the advertising router to 153 indicate that the prefix originator is capable of processing ELs. 155 3.2. Advertising ELC Using OSPFv3 157 [RFC5340] defines the OSPFv3 PrefixOptions that are advertised along 158 with the prefix. A new bit in the OSPFV3 PrefixOptions is used to 159 signal the ELC for the prefix: 161 0x04 - E-Flag (ELC Flag): Set by the advertising router to 162 indicate that the prefix originator is capable of processing ELs. 164 4. Advertising ERLD Using OSPF 166 A new MSD-type of the Node MSD sub-TLV 167 [I-D.ietf-isis-segment-routing-msd], called ERLD is defined to 168 advertise the ERLD of a given router. The scope of the advertisement 169 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 5. Acknowledgements 180 The authors would like to thank Yimin Shen, George Swallow, Acee 181 Lindem, Les Ginsberg, Ketan Talaulikar, Jeff Tantsura , Bruno 182 Decraene and Carlos Pignataro for their valuable comments. 184 6. BGP-LS Extension 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-ext]. 199 7. IANA Considerations 201 This document requests IANA to allocate one flag from the OSPFv2 202 Extended Prefix TLV Flags registry: 204 0x20 - E-Flag (ELC Flag) 206 This document requests IANA to allocate one flag from the OSPFv3 207 Prefix Options registry: 209 0x04 - E-Flag (ELC Flag) 211 8. Security Considerations 213 The security considerations as described in [RFC7770] and 214 [I-D.ietf-mpls-spring-entropy-label] are applicable to this document. 216 Incorrectly setting the E flag (ELC capable) (during origination, 217 inter-area advertisement or redistribution) may lead to black-holing 218 of the traffic on the egress node. 220 9. References 222 9.1. Normative References 224 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 225 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 226 and M. Chen, "BGP Link-State extensions for Segment 227 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 228 (work in progress), June 2019. 230 [I-D.ietf-isis-mpls-elc] 231 Xu, X., Kini, S., Psenak, P., Filsfils, C., and S. 232 Litkowski, "Signaling Entropy Label Capability and Entropy 233 Readable Label Depth Using IS-IS", draft-ietf-isis-mpls- 234 elc-07 (work in progress), May 2019. 236 [I-D.ietf-isis-segment-routing-msd] 237 Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 238 "Signaling MSD (Maximum SID Depth) using IS-IS", draft- 239 ietf-isis-segment-routing-msd-19 (work in progress), 240 October 2018. 242 [I-D.ietf-ospf-segment-routing-extensions] 243 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 244 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 245 Extensions for Segment Routing", draft-ietf-ospf-segment- 246 routing-extensions-27 (work in progress), December 2018. 248 [I-D.ietf-spring-segment-routing-mpls] 249 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 250 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 251 data plane", draft-ietf-spring-segment-routing-mpls-22 252 (work in progress), May 2019. 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, 256 DOI 10.17487/RFC2119, March 1997, 257 . 259 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 260 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 261 . 263 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 264 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 265 RFC 6790, DOI 10.17487/RFC6790, November 2012, 266 . 268 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 269 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 270 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 271 2015, . 273 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 274 S. Ray, "North-Bound Distribution of Link-State and 275 Traffic Engineering (TE) Information Using BGP", RFC 7752, 276 DOI 10.17487/RFC7752, March 2016, 277 . 279 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 280 S. Shaffer, "Extensions to OSPF for Advertising Optional 281 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 282 February 2016, . 284 9.2. Informative References 286 [I-D.ietf-mpls-spring-entropy-label] 287 Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 288 Shakir, R., and J. Tantsura, "Entropy label for SPRING 289 tunnels", draft-ietf-mpls-spring-entropy-label-12 (work in 290 progress), July 2018. 292 Authors' Addresses 294 Xiaohu Xu 295 Alibaba Inc 297 Email: xiaohu.xxh@alibaba-inc.com 299 Sriganesh Kini 301 Email: sriganeshkini@gmail.com 303 Peter Psenak 304 Cisco 306 Email: ppsenak@cisco.com 308 Clarence Filsfils 309 Cisco 311 Email: cfilsfil@cisco.com 313 Stephane Litkowski 314 Orange 316 Email: stephane.litkowski@orange.com