idnits 2.17.1 draft-ietf-ospf-mpls-elc-01.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 (November 9, 2015) is 3084 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) ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) == Outdated reference: A later version (-12) exists of draft-ietf-mpls-spring-entropy-label-01 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-05 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Xu 3 Internet-Draft Huawei 4 Intended status: Standards Track S. Kini 5 Expires: May 12, 2016 Ericsson 6 S. Sivabalan 7 C. Filsfils 8 Cisco 9 S. Litkowski 10 Orange 11 November 9, 2015 13 Signaling Entropy Label Capability Using OSPF 14 draft-ietf-ospf-mpls-elc-01 16 Abstract 18 Multi Protocol Label Switching (MPLS) has defined a mechanism to load 19 balance traffic flows using Entropy Labels (EL). An ingress LSR 20 cannot insert ELs for packets going into a given tunnel unless an 21 egress LSR has indicated via signaling that it can process ELs on 22 that tunnel. This draft defines a mechanism to signal that 23 capability using OSPF. This mechanism is useful when the label 24 advertisement is also done via OSPF. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 12, 2016. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Advertising ELC Using OSPF . . . . . . . . . . . . . . . . . 3 64 4. Advertising RLDC Using OSPF . . . . . . . . . . . . . . . . . 3 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 70 8.2. Informative References . . . . . . . . . . . . . . . . . 4 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 73 1. Introduction 75 Multi Protocol Label Switching (MPLS) has defined a method in 76 [RFC6790] to load balance traffic flows using Entropy Labels (EL). 77 An ingress LSR cannot insert ELs for packets going into a given 78 tunnel unless an egress LSR has indicated that it can process ELs on 79 that tunnel. [RFC6790] defines the signaling of this capability 80 (a.k.a Entropy Label Capability - ELC) via signaling protocols. 81 Recently, mechanisms are being defined to signal labels via link 82 state Interior Gateway Protocols (IGP) such as OSPF 83 [I-D.ietf-ospf-segment-routing-extensions] . In such scenario the 84 signaling mechanisms defined in [RFC6790] are inadequate. This draft 85 defines a mechanism to signal the ELC using OSPF. This mechanism is 86 useful when the label advertisement is also done via OSPF. In 87 addition, in the cases where stacked LSPs are used for whatever 88 reasons (e.g., SPRING-MPLS [I-D.ietf-spring-segment-routing-mpls]), 89 it would be useful for ingress LSRs to know each LSR's capability of 90 reading the maximum label stack deepth. This capability, referred to 91 as Readable Label Deepth Capability (RLDC) can be used by ingress 92 LSRs to determine whether it's necessary to insert an EL for a given 93 LSP tunnel in the case where there has already been at least one EL 94 in the label stack [I-D.ietf-mpls-spring-entropy-label] . Of course, 95 even it has been determined that it's neccessary to insert an EL for 96 a given LSP tunnel, if the egress LSR of that LSP tunnel has not yet 97 indicated that it can process ELs for that tunnel, the ingress LSR 98 MUST NOT include an entropy label for that tunnel as well. 100 1.1. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 106 2. Terminology 108 This memo makes use of the terms defined in [RFC6790] and [RFC4970]. 110 3. Advertising ELC Using OSPF 112 The OSPF Router Information (RI) Opaque LSA defined in [RFC4970] is 113 used by OSPF routers to announce their capabilities. A new TLV 114 within the body of this LSA, called ELC TLV is defined to advertise 115 the capability of the router to process the ELs. It is formatted as 116 described in Section 2.1 of [RFC4970]. This TLV is applicable to 117 both OSPFv2 and OSPFv3. The Type for the ELC TLV needs to be 118 assigned by IANA and it has a Length of zero. The scope of the 119 advertisement depends on the application but it is recommended that 120 it SHOULD be AS-scoped. 122 4. Advertising RLDC Using OSPF 124 A new TLV within the body of the OSPF RI LSA, called RLDC TLV is 125 defined to advertise the capability of the router to read the maximum 126 label stack depth. It is formatted as described in Section 2.1 of 127 [RFC4970] with a Type code to be assigned by IANA and a Length of 128 one. The Value field is set to the maximum readable label stack 129 deepth in the range between 1 to 255. The scope of the advertisement 130 depends on the application but it is RECOMMENDED that it SHOULD be 131 domain-wide. If a router has multiple linecards with different 132 capabilities of reading the maximum label stack deepth, the router 133 MUST advertise the smallest one in the RLDC TLV. This TLV is 134 applicable to both OSPFv2 and OSPFv3. 136 5. Acknowledgements 138 The authors would like to thank Yimin Shen and George Swallow for 139 their comments. 141 6. IANA Considerations 143 This memo includes a request to IANA to allocate two TLV types from 144 the OSPF RI TLVs registry. 146 7. Security Considerations 148 This document does not introduce any new security risk. 150 8. References 152 8.1. Normative References 154 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 155 Requirement Levels", BCP 14, RFC 2119, 156 DOI 10.17487/RFC2119, March 1997, 157 . 159 [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 160 S. Shaffer, "Extensions to OSPF for Advertising Optional 161 Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July 162 2007, . 164 8.2. Informative References 166 [I-D.ietf-mpls-spring-entropy-label] 167 Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 168 rjs@rob.sh, r., Xu, X., Henderickx, W., and J. Tantsura, 169 "Entropy labels for source routed stacked tunnels", draft- 170 ietf-mpls-spring-entropy-label-01 (work in progress), 171 September 2015. 173 [I-D.ietf-ospf-segment-routing-extensions] 174 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 175 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 176 Extensions for Segment Routing", draft-ietf-ospf-segment- 177 routing-extensions-05 (work in progress), June 2015. 179 [I-D.ietf-spring-segment-routing-mpls] 180 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 181 Litkowski, S., Horneffer, M., rjs@rob.sh, r., Tantsura, 182 J., and E. Crabbe, "Segment Routing with MPLS data plane", 183 draft-ietf-spring-segment-routing-mpls-02 (work in 184 progress), October 2015. 186 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 187 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 188 RFC 6790, DOI 10.17487/RFC6790, November 2012, 189 . 191 Authors' Addresses 193 Xiaohu Xu 194 Huawei 196 Email: xuxiaohu@huawei.com 198 Sriganesh Kini 199 Ericsson 201 Email: sriganesh.kini@ericsson.com 203 Siva Sivabalan 204 Cisco 206 Email: msiva@cisco.com 208 Clarence Filsfils 209 Cisco 211 Email: cfilsfil@cisco.com 213 Stephane Litkowski 214 Orange 216 Email: stephane.litkowski@orange.com