idnits 2.17.1 draft-xu-idr-tunnel-address-prefix-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 (July 16, 2012) is 4295 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) == Missing Reference: 'RFC4798' is mentioned on line 256, but not defined == Unused Reference: 'RFC4360' is defined on line 293, but no explicit reference was found in the text == Unused Reference: 'RFC5701' is defined on line 296, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5512 (Obsoleted by RFC 9012) == Outdated reference: A later version (-06) exists of draft-ietf-mpls-entropy-label-01 == Outdated reference: A later version (-11) exists of draft-ietf-l2vpn-evpn-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network working group X. Xu 2 Internet Draft Huawei 3 Category: Standard Track K. Lee 4 China Telecom 5 Expires: January 2013 July 16, 2012 7 BGP Tunnel Address Prefix Attribute and Tunnel Address Prefix 8 Extended Community 10 draft-xu-idr-tunnel-address-prefix-01 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with 15 the provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 16, 2013. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. 47 Abstract 49 This document describes a new BGP attribute referred to as Tunnel 50 Address Prefix Attribute and a new BGP address specific extended 51 community referred to as Tunnel Address Prefix Extended Community, 52 both of which are intended for facilitating the load-balancing of 53 IP/GRE tunneled traffic (e.g., L3VPN-over-GRE traffic) in the core 54 of IP-enabled Packet Switch Networks (PSN). 56 Conventions used in this document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC-2119 [RFC2119]. 62 Table of Contents 64 1. Introduction ................................................ 3 65 2. Terminology ................................................. 4 66 3. Tunnel Address Prefix Attribute ............................. 4 67 4. Tunnel Address Prefix Extended Community .................... 5 68 5. Functionality Description ................................... 6 69 5.1. Egress Routers ......................................... 6 70 5.2. Ingress Routers......................................... 6 71 5.3. Intermediate Routers ................................... 6 72 6. Applicability ............................................... 6 73 7. Security Considerations ..................................... 7 74 8. IANA Considerations ......................................... 7 75 9. Acknowledgements ............................................ 7 76 10. References ................................................. 7 77 10.1. Normative References .................................. 7 78 10.2. Informative References ................................ 7 79 Authors' Addresses ............................................. 8 81 1. Introduction 83 Equal Cost Multi-Path (ECMP) and Link Aggregation Group (LAG) are 84 widely used in the core of IP-enabled Packet Switch Networks (PSN) 85 for load-balancing purposes. Most core routers in the IP-enabled PSN 86 are capable of load-balancing IP traffic flows across ECMP paths 87 and/or LAG based on the hash of the five-tuple of UDP/TCP packets 88 (i.e., source IP address, destination IP address, source port, 89 destination port, and protocol) or some fields in the IP header of 90 non-UDP/TCP packets (e.g., source IP address, destination IP 91 address). However, in the L3VPN [RFC4364], L2VPN and Softwire mesh 92 [RFC5565] scenarios, distinct customer traffic flows between a given 93 tunnel endpoint pair (e.g., the PE pair in the L3VPN context) would 94 be encapsulated with the same IP/GRE tunnel header prior to 95 traversing the core of IP PSN. In addition, since the IP/GRE 96 encapsulated traffic is neither TCP nor UDP, core routers therefore 97 could only perform hash calculation on the fields in the IP header 98 of IP/GRE tunnels. As a result, core routers could not achieve an 99 effective load-balancing for these IP/GRE tunneled traffic flows in 100 the core network due to the lack of adequate entropy information. 102 [RFC5640] describes a method for improving the load-balancing in 103 Softwire mesh networks [RFC5565]. However, this method requires core 104 routers to be able to perform hash calculation on the fields 105 including the specific "load-balancing" field contained in the 106 L2TPv3 or GRE tunnel header. [Entropy-Label] proposes to use the 107 "entropy labels" for achieving a better load-balancing for MPLS 108 traffic flows in the core of MPLS-enabled PSN. Although the entropy 109 label could be inserted in the "Key" field of the GRE header by 110 ingress PE routers in the case where the PSN is IP enabled rather 111 than MPLS enabled, it still requires core routers to be capable of 112 performing hash calculation on the "entropy label" contained in the 113 GRE tunnel header. Any of the above two load-balancing methods 114 requires a change to the date plane of core routers. 116 This document describes an alternative load-balancing method 117 suitable for the above scenarios, which is backwards compatible to 118 those already-deployed core routers that could only perform hash 119 calculation on the fields in the IP header in the case of IP/GRE 120 tunneled traffic flows. The basic idea of this method is: a given 121 (tunnel) egress router signals to (tunnel) ingress routers a special 122 prefix called "tunnel address prefix" via BGP and any addresses 123 beginning with that prefix would be used by those ingress routers as 124 tunnel destination addresses when tunneling traffic towards that 125 egress router. Therefore distinct traffic flows between that tunnel 126 endpoint pair could be encapsulated with as many different tunnel 127 destination addresses as possible. In this way, core routers could 128 achieve a better load-balancing for those IP/GRE tunneled traffic 129 through performing hash calculation just on the fields in the IP 130 header. 132 2. Terminology 134 This memo makes use of the terms defined in [RFC4364] and [RFC5565]. 136 3. Tunnel Address Prefix Attribute 138 For a given BGP router to tell remote BGP routers what tunnel 139 destination addresses could be used when tunneling traffic flows to 140 it, a new BGP attribute contained in the Encapsulation SAFI 141 [RFC5512], referred to as "Tunnel Address Prefix Attribute", could 142 be used to indicate the available tunnel destination addresses to be 143 used. 145 The Tunnel Address Prefix attribute is an optional transitive 146 attribute. The TLV is structured as follows: 148 0 1 2 3 149 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Tunnel Address Prefix Type | Length | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | | 154 | Value | 155 | | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 - Tunnel Address Prefix Type (2 octets): indicates the Value 159 field of such TLV contains the tunnel address prefix information 160 in the form of IP address and subnet mask pair. 162 - Length (2 octets): indicates the total number of octets of the 163 value field. If the AFI of the Encapsulation SAFI is IPv4, the 164 length value is set to 64; otherwise if the AFI is IPv6, the 165 length value is set to 256. 167 - Value (variable): contains the tunnel address prefix 168 information in the form of IP address and subnet mask pair. 170 4. Tunnel Address Prefix Extended Community 172 Here, we also define an address specific extended community referred 173 to as Tunnel Address Prefix extended community that can be attached 174 to BGP UPDATE messages to indicate the available tunnel destination 175 addresses to be used when tunneling traffic flows from an ingress 176 router to an egress router. This extended community is useful in the 177 case where the Encapsulation SAFI capability is not supported 178 between BGP routers or one really wants to specify different tunnel 179 destination address prefixes for distinct sets of traffic flows. For 180 example, one wants to assign two different tunnel address prefixes 181 for traffic flows destined for prefix X and Y respectively. 183 IPv4 Tunnel Address Prefix extended community is as follows: 185 0 1 2 3 186 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | 0x01 | Sub-Type | Global Administrator | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Global Administrator (cont.) | Local Administrator | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 The value of the high-order octet of the extended type field is 194 0x01, which indicates it is transitive across ASes. The value of 195 the low-order octet of the extended type field is to be defined. 196 The Global Administrator sub-field contains an IPv4 unicast 197 address while the Local Administrator sub-field contains the 198 corresponding Prefix Length. 200 IPv6 Tunnel Address Prefix extended community is as follows: 202 0 1 2 3 203 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | 0x00 | Sub-Type | Global Administrator | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Global Administrator (cont.) | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Global Administrator (cont.) | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Global Administrator (cont.) | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Global Administrator (cont.) | Local Administrator | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 The value of the high-order octet of the extended type field is 216 0x00, which indicates it is transitive across ASes. The value of 217 the low-order octet of the extended type field is to be defined. 218 The Global Administrator sub-field contains an IPv6 unicast 219 address while the Local Administrator sub-field contains the 220 corresponding Prefix Length. 222 5. Functionality Description 224 5.1. Egress Routers 226 An egress router could attach the above BGP Tunnel Address Prefix 227 attribute or extended community to BGP UPDATE messages in order to 228 indicate the available tunnel destination addresses to be used by 229 any ingress routers when tunneling traffic flows to it. In addition, 230 it SHOULD create the corresponding loopback interface for each IP 231 address within that prefix and accordingly advertise a route for 232 that prefix via IGP. As such, it could receive and process those 233 IP/GRE tunneled traffic flows destined for any of those addresses 234 beginning with that prefix. 236 5.2. Ingress Routers 238 For an ingress router receiving the above BGP Tunnel Address Prefix 239 attribute or extended community announced by a given egress router, 240 it could use any addresses beginning with the tunnel address prefix, 241 in addition to the BGP next-hop address contained in the 242 MP_REACH_NLRI attribute, as tunnel destination addresses when 243 tunneling traffic flows towards that egress router. 245 5.3. Intermediate Routers 247 There is no special requirement on Intermediate Routers (i.e., core 248 routers). In other words, they could perform load-balancing of the 249 IP/GRE tunneled traffic on basis of the hash of the fields in the IP 250 headers as normal. 252 6. Applicability 254 The load-balancing approach described in this document is suitable 255 for many scenarios including but not limited to L3VPN [RFC4364], 6PE 256 [RFC4798], Softwire mesh [RFC5565], BGP free core and L2VPN 257 including VPLS [RFC4761, RFC4762] and E-VPN [E-VPN]. In the existing 258 VPLS case where BGP is used for auto-discovery, the above BGP Tunnel 259 Address Prefix attribute or extended community would be attached to 260 the BGP update messages as well. Once a customer MAC address is 261 learnt against a given BGP next-hop address, any addresses beginning 262 with the Tunnel Address Prefix which is associated with that BGP 263 next-hop address could be used as tunnel destination addresses when 264 tunneling MAC frames destined for that MAC address. 266 7. Security Considerations 268 TBD. 270 8. IANA Considerations 272 The type code of the Tunnel Address Prefix Attribute needs to be 273 allocated by IANA. Meanwhile, a new Sub-Type of the Address Specific 274 BGP Extended Communities of IPv4 and IPv6 respectively SHOULD also 275 be assigned by IANA. 277 9. Acknowledgements 279 Thanks to Robert Raszuk for his valuable comments on this document. 281 10. References 283 10.1. Normative References 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, March 1997. 288 10.2. Informative References 290 [RFC5640] Filsfils, C., Mohapatra, P and C. Pignataro, "Load- 291 Balancing for Mesh Softwires", RFC 5640, August 2009. 293 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 294 Communities Attribute", RFC 4360, February 2006. 296 [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended 297 Communities Attribute", RFC5701, November 2009. 299 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 300 Subsequent Address Family Identifier (SAFI) and the 301 BGP Tunnel Encapsulation Attribute", RFC 5512, April 302 2009. 304 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 305 Framework", RFC 5565, June 2009. 307 [RFC4364] "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al., February 2006 309 [Entropy-Label] Kompella, K., Drake, J., Amante, S., Henderickx, W., 310 and L. Yong, "The Use of Entropy Labels in MPLS 311 Forwarding", draft-ietf-mpls-entropy-label-01, work in 312 progress, October, 2011. 314 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 315 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 316 4761, January 2007. 318 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 319 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 320 RFC 4762, January 2007. 322 [E-VPN] Aggarwal et al., "BGP MPLS Based Ethernet VPN", draft-ietf- 323 l2vpn-evpn-00.txt, work in progress, February, 2012. 325 Authors' Addresses 327 Xiaohu Xu 328 Huawei Technologies, 329 Beijing, China 331 Phone: +86-10-60610041 332 Email: xuxiaohu@huawei.com 334 Kai Lee 335 China Telecom, 336 Beijing, China. 338 Email: Leekai@ctbri.com.cn