idnits 2.17.1 draft-pmohapat-softwire-lb-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 256. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 267. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 274. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 280. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1, 2008) is 5779 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 (-05) exists of draft-ietf-softwire-encaps-safi-03 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Filsfils 3 Internet-Draft P. Mohapatra 4 Intended status: Standards Track C. Pignataro 5 Expires: January 2, 2009 Cisco Systems 6 July 1, 2008 8 Load Balancing for Mesh Softwires 9 draft-pmohapat-softwire-lb-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 2, 2009. 36 Abstract 38 Payloads carried over a Softwire mesh service as defined by BGP 39 Encapsulation Subsequent Address Family Identifier (SAFI) information 40 exchange often carry a number of identifiable, distinct flows. It 41 can in some circumstances be desirable to distribute these flows over 42 the equal cost multiple paths (ECMPs) that exist in the packet 43 switched network. Currently, the payload of a packet entering the 44 Softwire can only be interpreted by the ingress and egress routers. 45 Thus the load balancing decision of a core router is only based on 46 the encapsulating header, presenting much less entropy than available 47 in the payload or the encapsulated header since the Softwire 48 encapsulation acts in a tunneling fashion. This document describes a 49 method for achieving comparable load balancing efficiency in a 50 network carrying Softwire mesh service over Layer Two Tunneling 51 Protocol - Version 3 (L2TPv3) over IP or Generic Routing 52 Encapsulation (GRE) encapsulation to what would be achieved without 53 such encapsulation. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 59 2. Load Balancing Block sub-TLV . . . . . . . . . . . . . . . . . 3 60 2.1. Applicability to Tunnel Types . . . . . . . . . . . . . . . 4 61 2.2. Encapsulation Considerations . . . . . . . . . . . . . . . 5 62 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 64 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 65 6. Normative References . . . . . . . . . . . . . . . . . . . . . 5 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 67 Intellectual Property and Copyright Statements . . . . . . . . . . 7 69 1. Introduction 71 Consider the case of a router R1 which encapsulates a packet P into a 72 Softwire bound to router R3. R2 is a router on the shortest path 73 from R1 to R3. R2's shortest path to R3 involves equal cost multiple 74 paths (ECMPs). The goal is for R2 to be able to choose which path to 75 use on the basis of the full entropy of packet P. 77 This is achieved by carrying in the encapsulation header a signature 78 of the inner header, hence enhancing the entropy of the flows as seen 79 by the core routers. The signature is carried as part of one of the 80 fields of the encapsulation header. To aid with better description 81 in the document, we define the generic term "load balancing field" to 82 mean such a value that is specific to an encapsulation type. For 83 example, for L2TPv3-over-IP [RFC3931] encapsulation, the load 84 balancing field is the Session Identifier (Session ID). For GRE 85 [RFC2784] encapsulation, the key field [RFC2890], if present, 86 represents the load balancing field. This mechanism assumes that 87 core routers base their load-balancing decisions on a flow definition 88 that includes the load balancing field. This is an obvious and 89 generic functionality as, for example, for L2TPv3-over-IP tunnels, 90 the Session ID is at the same well-known constant offset as the TCP/ 91 UDP ports in the encapsulating header. 93 The "Encapsulation SAFI" [I-D.ietf-softwire-encaps-safi] is extended 94 such that a contiguous block of the load balancing field is bound to 95 the Softwire advertised by a BGP next-hop. On a per-inner flow 96 basis, the ingress PE selects one value of the load balancing field 97 from the block to preserve per-flow ordering, and at the same time to 98 enhance the entropy across flows. 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. Load Balancing Block sub-TLV 108 This document defines a new sub-TLV for use with the Tunnel 109 Encapsulation Attribute defined in [I-D.ietf-softwire-encaps-safi]. 110 The new sub-TLV is referred to as the "Load Balancing Block sub-TLV" 111 and MAY be included in any Encapsulation SAFI UPDATE message where 112 load balancing is desired. 114 The sub-TLV type of the Load Balancing Block sub-TLV is 5. The sub- 115 TLV length is 2 octets. The value represents the length of the block 116 in bits and it MUST NOT exceed the size of the load balancing field. 117 This format is very similar to the variable-length subnet masking 118 (VLSM) used in IP addresses to allow arbitrary length prefixes. The 119 block is determined by extracting the initial sequence of 'block 120 size' bits from the load balancing field. 122 As an example, Assume that there is a Softwire set up between R1 and 123 R3 with L2TPv3-over-IP tunnel type. Assume that R3 encodes the 124 Session ID with value 0x1234ABCD in the encapsulation sub-TLV. It 125 also includes the load balancing block sub-TLV and encodes the value 126 24. This should be interpreted as follows: 128 o If an ingress router does not understand Load Balancing block sub- 129 TLV, it continues to use the Session ID 0x1234ABCD and 130 encapsulates all packets with that Session ID, 132 o If an ingress router understands Load Balancing Block sub-TLV, it 133 picks the first 24 bits out of the Session ID (0x1234AB) to be 134 used as the block and fills in the lower-order 8 bits with a per- 135 flow identifier (e.g. it can be determined based on the inner 136 packet's source, destination addresses and TCP/UDP ports). This 137 selection preserves per-flow ordering of packets. 139 This requirement and solution applies equally to GRE where the key 140 plays the same role as the Session ID in L2TPv3. 142 Needless to say, if an egress router does not support load balancing 143 block sub-TLV, the Softwire continues to operate with a single load 144 balancing field that all ingress routers encapsulate with. 146 2.1. Applicability to Tunnel Types 148 The load balancing block sub-TLV is applicable to Tunnel types that 149 define a load balancing field. This document defines load balancing 150 fields for tunnel types 1 (L2TPv3 over IP) and 2 (GRE) as follows: 152 o L2TPv3 over IP - Session ID. Special care needs to be taken to 153 always create a non-zero Session ID. When an egress router 154 includes a load balancing sub-TLV, it MUST encode the Session ID 155 field of the Encapsulation sub-TLV in a way that ensures that the 156 most significant bits of the Session ID after extracting the block 157 are non-zero. 159 o GRE - GRE key 161 Future tunnel types that desire to use the load balancing sub-TLV 162 MUST define a load balancing field that is part of the encapsulating 163 header. 165 2.2. Encapsulation Considerations 167 Fields included in the encapsulation header besides the load 168 balancing field are not affected by the load balancing block sub-TLV. 169 All other encapsulation fields are shared between variations of the 170 load balancing field. For example, for L2TPv3-over-IP tunnel type, 171 if the optional cookie is included in the Encapsulation sub-TLV by 172 the egress router during Softwire signaling, it applies to all the 173 "Session ID" values derived at the ingress router after applying the 174 load balancing block as described in this document. 176 3. IANA Considerations 178 IANA is requested to assign the type of 5 for the Load Balancing 179 Block sub-TLV, in the tunnel sub-TLV types of the Tunnel 180 Encapsulation attribute registry (number space created as part of the 181 publication of [I-D.ietf-softwire-encaps-safi]): 183 Sub-TLV name Type 184 ------------- ----- 185 Load Balancing Block 5 187 4. Security Considerations 189 There are no additional security risks introduced by this design. 191 5. Acknowledgements 193 The authors would like to thank Stewart Bryant and Mark Townsley for 194 their review and comments. 196 6. Normative References 198 [I-D.ietf-softwire-encaps-safi] 199 Mohapatra, P. and E. Rosen, "BGP Encapsulation SAFI and 200 BGP Tunnel Encapsulation Attribute", 201 draft-ietf-softwire-encaps-safi-03 (work in progress), 202 June 2008. 204 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 205 Requirement Levels", BCP 14, RFC 2119, March 1997. 207 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 208 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 209 March 2000. 211 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 212 RFC 2890, September 2000. 214 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 215 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 217 Authors' Addresses 219 Clarence Filsfils 220 Cisco Systems 221 Brussels, 222 Belgium 224 Email: cfilsfil@cisco.com 226 Pradosh Mohapatra 227 Cisco Systems 228 170 W. Tasman Drive 229 San Jose, CA 95134 230 USA 232 Email: pmohapat@cisco.com 234 Carlos Pignataro 235 Cisco Systems 236 7200 Kit Creek Road, PO Box 14987 237 Research Triangle Park, NC 27709 238 USA 240 Email: cpignata@cisco.com 242 Full Copyright Statement 244 Copyright (C) The IETF Trust (2008). 246 This document is subject to the rights, licenses and restrictions 247 contained in BCP 78, and except as set forth therein, the authors 248 retain all their rights. 250 This document and the information contained herein are provided on an 251 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 252 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 253 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 254 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 255 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 256 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 258 Intellectual Property 260 The IETF takes no position regarding the validity or scope of any 261 Intellectual Property Rights or other rights that might be claimed to 262 pertain to the implementation or use of the technology described in 263 this document or the extent to which any license under such rights 264 might or might not be available; nor does it represent that it has 265 made any independent effort to identify any such rights. Information 266 on the procedures with respect to rights in RFC documents can be 267 found in BCP 78 and BCP 79. 269 Copies of IPR disclosures made to the IETF Secretariat and any 270 assurances of licenses to be made available, or the result of an 271 attempt made to obtain a general license or permission for the use of 272 such proprietary rights by implementers or users of this 273 specification can be obtained from the IETF on-line IPR repository at 274 http://www.ietf.org/ipr. 276 The IETF invites any interested party to bring to its attention any 277 copyrights, patents or patent applications, or other proprietary 278 rights that may cover technology that may be required to implement 279 this standard. Please address the information to the IETF at 280 ietf-ipr@ietf.org.