idnits 2.17.1 draft-xu-ospf-mpls-elc-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 (December 18, 2013) is 3754 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 137, but no explicit reference was found in the text == Unused Reference: 'I-D.filsfils-rtgwg-segment-routing' is defined on line 146, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-psenak-ospf-segment-routing-extensions-03 ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) 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: June 18, 2014 Ericsson 6 S. Sivabalan 7 C. Filsfils 8 Cisco 9 December 18, 2013 11 Signaling Entropy Label Capability Using OSPF 12 draft-xu-ospf-mpls-elc-00 14 Abstract 16 Multi Protocol Label Switching (MPLS) has defined a mechanism to load 17 balance traffic flows using Entropy Labels (EL). An ingress LSR 18 cannot insert ELs for packets going into a given tunnel unless an 19 egress LSR has indicated via signaling that it can process ELs on 20 that tunnel. This draft defines a mechanism to signal that 21 capability using OSPF. This mechanism is useful when the label 22 advertisement is also done via OSPF. 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 June 18, 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 3. Advertising ELC using OSPF . . . . . . . . . . . . . . . . . 2 62 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 3 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 3 67 7.2. Informative References . . . . . . . . . . . . . . . . . 4 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 70 1. Introduction 72 Multi Protocol Label Switching (MPLS) has defined a method in 73 [RFC6790] to load balance traffic flows using Entropy Labels (EL). 74 An ingress LSR cannot insert ELs for packets going into a given 75 tunnel unless an egress LSR has indicated via signaling that it can 76 process ELs on that tunnel. [RFC6790] defines the signaling of this 77 capability (a.k.a Entropy Label Capability - ELC) via signaling 78 protocols. Recently, mechanisms are being defined to signal labels 79 via link state Interior Gateway Protocols (IGP) such as OSPF 80 [I-D.psenak-ospf-segment-routing-extensions] . In such scenario the 81 signaling mechanisms defined in [RFC6790] are inadequate. This draft 82 defines a mechanism to signal the ELC using OSPF. This mechanism is 83 useful when the label advertisement is also done via OSPF. 85 1.1. Requirements Language 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 2. Terminology 93 This memo makes use of the terms defined in [RFC6790] and [RFC4970]. 95 3. Advertising ELC using OSPF 96 The OSPF Router Information (RI) Opaque LSA defined in [RFC4970] is 97 used by OSPF routers to announce their capabilities. A new TLV 98 within the body of this LSA, called ELC TLV is defined to advertise 99 the capability of the router to process the ELs. It is formatted as 100 described in sec 2.1 of [RFC4970]. This TLV is applicable to both 101 OSPFv2 and OSPFv3. The Type for the ELC TLV needs to be assigned by 102 IANA and it has a Length of zero. The scope of the advertisement 103 depends on the application but it is recommended that it SHOULD be 104 AS-scoped. 106 4. Acknowledgements 108 The authors would like to thank Yimin Shen and George Swallow for 109 their comments. 111 5. IANA Considerations 113 This memo includes a request to IANA to allocate a TLV type from the 114 OSPF RI TLVs registry. 116 6. Security Considerations 118 This document does not introduce any new security considerations. 120 7. References 122 7.1. Normative References 124 [I-D.psenak-ospf-segment-routing-extensions] 125 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 126 Shakir, R., and W. Henderickx, "OSPF Extensions for 127 Segment Routing", draft-psenak-ospf-segment-routing- 128 extensions-03 (work in progress), October 2013. 130 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 131 Requirement Levels", BCP 14, RFC 2119, March 1997. 133 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 134 Shaffer, "Extensions to OSPF for Advertising Optional 135 Router Capabilities", RFC 4970, July 2007. 137 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 138 Engineering", RFC 5305, October 2008. 140 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 141 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 142 RFC 6790, November 2012. 144 7.2. Informative References 146 [I-D.filsfils-rtgwg-segment-routing] 147 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 148 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 149 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 150 "Segment Routing Architecture", draft-filsfils-rtgwg- 151 segment-routing-01 (work in progress), October 2013. 153 Authors' Addresses 155 Xiaohu Xu 156 Huawei 158 Email: xuxiaohu@huawei.com 160 Sriganesh Kini 161 Ericsson 163 Email: sriganesh.kini@ericsson.com 165 Siva Sivabalan 166 Cisco 168 Email: msiva@cisco.com 170 Clarence Filsfils 171 Cisco 173 Email: cfilsfil@cisco.com