idnits 2.17.1 draft-ietf-ospf-mpls-elc-08.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 (May 13, 2019) is 1810 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) == Unused Reference: 'RFC5305' is defined on line 234, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-isis-mpls-elc-06 Summary: 0 errors (**), 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: November 14, 2019 6 P. Psenak 7 C. Filsfils 8 Cisco 9 S. Litkowski 10 Orange 11 May 13, 2019 13 Signaling Entropy Label Capability and Entropy Readable Label-stack 14 Depth Using OSPF 15 draft-ietf-ospf-mpls-elc-08 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 of processing 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), in the cases where stacked 28 LSPs are used. This document defines a mechanisms to signal these 29 two capabilities using OSPF and OSPFv3. These mechanisms are 30 particularly useful in the environment where Segment Routing (SR) is 31 used, where label advertisements are done via protocols like OSPF and 32 OSPFv3. 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 November 14, 2019. 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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 84 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 85 8.2. Informative References . . . . . . . . . . . . . . . . . 6 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 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 signalings of this capability via MPLS signaling protocols. 94 Recently, mechanisms are being 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 scenario, 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 whether it's necessary to insert an EL for a given LSP of 109 the stacked LSP tunnel in the case where there has already been at 110 least one EL in the label stack [I-D.ietf-mpls-spring-entropy-label]. 112 2. Terminology 114 This memo makes use of the terms defined in [RFC6790] and [RFC7770]. 116 3. Advertising ELC Using OSPF 118 Even though ELC is a property of the node, in some cases it is 119 advantageous to associate and advertise the ELC with the prefix. In 120 multi-area network, routers may not know the identity of the prefix 121 originator in the remote area, or may not know the capabilities of 122 such originator. Similarly in the multi domain network, the identity 123 of the prefix originator and its capabilities may not be known to the 124 ingress LSR. 126 If a router has multiple line cards, the router MUST NOT announce ELC 127 unless all of its linecards are capable of processing ELs. 129 If the router support ELs on all of its line cards, it SHOULD 130 advertise the ELC with every local host prefix it advertises in OSPF. 132 When an OSPF Area Border Router (ABR) advertises the prefix to the 133 connected area based on the intra-area or inter-area prefix that is 134 reachable in some other area, it MUST preserve the ELC signalling for 135 such prefix. 137 When an OSPF Autonomous System Boundary Router (ASBR) redistributes 138 the prefix from other instance of the OSPF or from some other 139 protocol, it SHOULD preserve the ELC signalling for the prefix. 140 Exact mechanism on how to exchange ELC between protocol instances on 141 the ASBR is outside of the scope of this document and is 142 implementation specific. 144 3.1. Advertising ELC Using OSPFv2 146 [RFC7684] defines the OSPFv2 Extended Prefix TLV to advertise 147 additional attributes associated with the prefix. The OSPFv2 148 Extended Prefix TLV includes a one octet Flags field. A new bit in 149 the Flags field is used to signal the ELC for the prefix: 151 0x20 - E-Flag (ELC Flag): Set by the advertising router to 152 indicate that the prefix originator is capable of processing ELs 154 3.2. Advertising ELC Using OSPFv3 156 [RFC5340] defines the OSPFv3 PrefixOptions that is advertised along 157 with the prefix. A new bit in the OSPFV3 PrefixOptions is used to 158 signal the ELC for the prefix: 160 0x04 - E-Flag (ELC Flag): Set by the advertising router to 161 indicate that the prefix originator is capable of processing ELs 163 4. Advertising ERLD Using OSPF 165 A new MSD-type of the Node MSD sub-TLV 166 [I-D.ietf-isis-segment-routing-msd], called ERLD is defined to 167 advertise the ERLD of a given router. The scope of the advertisement 168 depends on the application. 170 Assignment of a MSD-Type for ERLD is defined in 171 [I-D.ietf-isis-mpls-elc]. 173 If a router has multiple linecards with different capabilities of 174 reading the maximum label stack deepth, the router MUST advertise the 175 smallest one. 177 5. Acknowledgements 179 The authors would like to thank Yimin Shen, George Swallow, Acee 180 Lindem, Les Ginsberg, Ketan Talaulikar, Jeff Tantsura , Bruno 181 Decraene and Carlos Pignataro for their valuable comments. 183 6. IANA Considerations 185 This document requests IANA to allocate one bit from the OSPFv2 186 Extended Prefix TLV Flags registry: 188 0x20 - E-Flag (ELC Flag) 190 This document requests IANA to allocate one bit from the OSPFv3 191 Prefix Options registry: 193 0x04 - E-Flag (ELC Flag) 195 7. Security Considerations 197 The security considerations as described in [RFC7770] is applicable 198 to this document. This document does not introduce any new security 199 risk. 201 8. References 203 8.1. Normative References 205 [I-D.ietf-isis-mpls-elc] 206 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 207 Litkowski, "Signaling Entropy Label Capability and Entropy 208 Readable Label Depth Using IS-IS", draft-ietf-isis-mpls- 209 elc-06 (work in progress), September 2018. 211 [I-D.ietf-isis-segment-routing-msd] 212 Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 213 "Signaling MSD (Maximum SID Depth) using IS-IS", draft- 214 ietf-isis-segment-routing-msd-19 (work in progress), 215 October 2018. 217 [I-D.ietf-ospf-segment-routing-extensions] 218 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 219 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 220 Extensions for Segment Routing", draft-ietf-ospf-segment- 221 routing-extensions-27 (work in progress), December 2018. 223 [I-D.ietf-spring-segment-routing-mpls] 224 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 225 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 226 data plane", draft-ietf-spring-segment-routing-mpls-22 227 (work in progress), May 2019. 229 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 230 Requirement Levels", BCP 14, RFC 2119, 231 DOI 10.17487/RFC2119, March 1997, 232 . 234 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 235 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 236 2008, . 238 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 239 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 240 . 242 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 243 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 244 RFC 6790, DOI 10.17487/RFC6790, November 2012, 245 . 247 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 248 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 249 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 250 2015, . 252 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 253 S. Shaffer, "Extensions to OSPF for Advertising Optional 254 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 255 February 2016, . 257 8.2. Informative References 259 [I-D.ietf-mpls-spring-entropy-label] 260 Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 261 Shakir, R., and J. Tantsura, "Entropy label for SPRING 262 tunnels", draft-ietf-mpls-spring-entropy-label-12 (work in 263 progress), July 2018. 265 Authors' Addresses 267 Xiaohu Xu 268 Alibaba Inc 270 Email: xiaohu.xxh@alibaba-inc.com 272 Sriganesh Kini 274 Email: sriganeshkini@gmail.com 276 Peter Psenak 277 Cisco 279 Email: ppsenak@cisco.com 281 Clarence Filsfils 282 Cisco 284 Email: cfilsfil@cisco.com 285 Stephane Litkowski 286 Orange 288 Email: stephane.litkowski@orange.com