idnits 2.17.1 draft-xu-mpls-el-capability-signaling-igp-00.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 06, 2013) is 3882 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: 'I-D.filsfils-rtgwg-segment-routing' is defined on line 172, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-previdi-isis-segment-routing-extensions-02 == Outdated reference: A later version (-05) exists of draft-psenak-ospf-segment-routing-extensions-02 ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) == Outdated reference: A later version (-01) exists of draft-filsfils-rtgwg-segment-routing-00 Summary: 2 errors (**), 0 flaws (~~), 5 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: March 10, 2014 Ericsson 6 S. Sivabalan 7 C. Filsfils 8 Cisco 9 September 06, 2013 11 Signaling Entropy Label Capability Using Interior Gateway Protocols 12 draft-xu-mpls-el-capability-signaling-igp-00 14 Abstract 16 Multi Protocol Label Switching (MPLS) has defined a mechanism to load 17 balance traffic flows using Entropy Labels (EL). An LSR inserts the 18 EL Indicator and the EL label only if the LSR that pops them has the 19 capability of processing them. This draft defines a mechanism to 20 signal that capability using link state Interior Gateway Protocols 21 (IGP). This mechanism is useful when the label advertisement is also 22 done via that IGP. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 10, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 60 2. Abbreviations and Terminology . . . . . . . . . . . . . . . . 3 61 3. Advertising ELC using OSPF . . . . . . . . . . . . . . . . . 3 62 4. Advertising ELC using ISIS . . . . . . . . . . . . . . . . . 3 63 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 3 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 68 8.2. Informative References . . . . . . . . . . . . . . . . . 4 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 71 1. Introduction 73 Multi Protocol Label Switching (MPLS) has defined a method in 74 [RFC6790] to load balance traffic flows using Entropy Labels (EL). 75 An LSR inserts the EL Indicator and the EL only if the LSR that pops 76 those labels has the capability of recognizing and processing them. 77 [RFC6790] defines the signaling of this capability (a.k.a Entropy 78 Label Capability - ELC) via signaling protocols. Recently, 79 mechanisms are being defined to signal labels via link state Interior 80 Gateway Protocols (IGP) such as OSPF 81 [I-D.psenak-ospf-segment-routing-extensions] and ISIS 82 [I-D.previdi-isis-segment-routing-extensions]. In such scenarios the 83 signaling mechanisms defined in [RFC6790] are inadequate. This draft 84 defines mechanisms to signal the ELC using the link state 85 advertisements (LSA) of the IGPs OSPF and ISIS. These capabilities 86 are advertised for the entire router and not just a single prefix. 87 This mechanism is useful when the label advertisement is also done 88 via that IGP. 90 1.1. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119]. 96 2. Abbreviations and Terminology 98 This memo makes use of the terms defined in [RFC6790], [RFC4970] and 99 [RFC4971]. 101 3. Advertising ELC using OSPF 103 The OSPF Router Information (RI) Opaque LSA defined in [RFC4970] is 104 used by OSPF routers to announce their capabilities. A new TLV 105 within the body of this LSA, called ELC TLV is defined to advertise 106 the capability of the router to process the ELI and EL. Its 107 formatting follows that described in sec 2.1 of [RFC4970]. This TLV 108 is applicable to both OSPFv2 and OSPFv3. The Type for the ELC TLV 109 needs to be assigned by IANA and it has a Length of zero. The scope 110 of the advertisement depends on the application but it is recommended 111 that it SHOULD be AS-scoped. 113 4. Advertising ELC using ISIS 115 The IS-IS Router CAPABILITY TLV defined in [RFC4971] is used by IS-IS 116 routers to announce their capabilities. A new sub-TLV of this TLV, 117 called ELC sub-TLV is defined to advertise the capability of the 118 router to process the ELI and EL. It is formatted as described in 119 [RFC5305] with a Type code to be assigned by IANA and a Length of 120 zero. The scope of the advertisement depends on the application but 121 it is recommended that it SHOULD be domain-wide. 123 5. Acknowledgements 125 The authors would like to thank TBD for their comments. 127 6. IANA Considerations 129 This memo includes requests to IANA to allocate a TLV type from the 130 OSPF RI TLVs registry and a sub-TLV type within the IS-IS Router 131 Capability TLV. 133 7. Security Considerations 135 This document does not introduce any new security considerations. 137 8. References 138 8.1. Normative References 140 [I-D.previdi-isis-segment-routing-extensions] 141 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., and 142 S. Litkowski, "IS-IS Extensions for Segment Routing", 143 draft-previdi-isis-segment-routing-extensions-02 (work in 144 progress), July 2013. 146 [I-D.psenak-ospf-segment-routing-extensions] 147 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., and R. 148 Shakir, "OSPF Extensions for Segment Routing", draft- 149 psenak-ospf-segment-routing-extensions-02 (work in 150 progress), July 2013. 152 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 153 Requirement Levels", BCP 14, RFC 2119, March 1997. 155 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 156 Shaffer, "Extensions to OSPF for Advertising Optional 157 Router Capabilities", RFC 4970, July 2007. 159 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 160 System to Intermediate System (IS-IS) Extensions for 161 Advertising Router Information", RFC 4971, July 2007. 163 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 164 Engineering", RFC 5305, October 2008. 166 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 167 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 168 RFC 6790, November 2012. 170 8.2. Informative References 172 [I-D.filsfils-rtgwg-segment-routing] 173 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 174 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 175 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 176 "Segment Routing Architecture", draft-filsfils-rtgwg- 177 segment-routing-00 (work in progress), June 2013. 179 Authors' Addresses 181 Xiaohu Xu 182 Huawei 184 Email: xuxiaohu@huawei.com 185 Sriganesh Kini 186 Ericsson 188 Email: sriganesh.kini@ericsson.com 190 Siva Sivabalan 191 Cisco 193 Email: msiva@cisco.com 195 Clarence Filsfils 196 Cisco 198 Email: cfilsfil@cisco.com