idnits 2.17.1 draft-xu-bess-virtual-subnet-rib-reduction-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 : ---------------------------------------------------------------------------- ** There are 13 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 5 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 7, 2015) is 3184 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-bess-virtual-subnet-00 == Outdated reference: A later version (-04) exists of draft-ietf-bess-virtual-subnet-fib-reduction-01 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: Informational S. Hares 5 Expires: February 8, 2016 Individual 6 Y. Fan 7 China Telecom 8 C. Jacquenet 9 Orange 10 T. Boyes 11 Bloomberg LP 12 B. Fee 13 Extreme Networks 14 August 7, 2015 16 RIB Reduction in Virtual Subnet 17 draft-xu-bess-virtual-subnet-rib-reduction-01 19 Abstract 21 Virtual Subnet is a BGP/MPLS IP VPN-based subnet extension solution 22 which is intended for building Layer3 network virtualization overlays 23 within and/or across data centers. This document describes a 24 mechanism for reducing the RIB size of PE routers in the Virtual 25 Subnet context. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on February 8, 2016. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Solution Description . . . . . . . . . . . . . . . . . . . . 3 65 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 70 7.2. Informative References . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 Virtual Subnet [I-D.ietf-bess-virtual-subnet] is a BGP/MPLS IP VPN 76 [RFC4364] -based subnet extension solution which is intended for 77 building Layer3 network virtualization overlays within and/or across 78 data centers. In the Virtual Subnet context, since CE host routes of 79 a given VPN instance need to be exchanged among PE routers 80 participating in that VPN instance, the resulting routing table size 81 of PE routers may become a big concern, especially in large-scale 82 data center environment where they may need to install a huge amount 83 of host routes into their routing tables. 85 [I-D.ietf-bess-virtual-subnet-fib-reduction] describes a method to 86 reduce the FIB size of PE routers without any change to the RIB and 87 the routing table. This FIB reduction approach is applicable in the 88 case where the control plane of PE routers still needs to maintain 89 all host routes of the attached VPN instances for some reason (e.g., 90 to support multicast VPN service). In the case where the control 91 plane of PE routers doesn't need to maintain all host routes of the 92 attached VPN instances, the RIB size of PE routers can be reduced as 93 well which would be beneficial for CPU and memory resource saving 94 purpose. This document proposes a very simple RIB reduction 95 mechanism. The basic idea of this mechanism is: remote host routes 96 are learnt by PE routers on demand by using the L3VPN Address Prefix 97 ORF as described in [I-D.xu-bess-l3vpn-prefix-orf]. 99 1.1. Requirements Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 2. Terminology 107 This memo makes use of the terms defined in [RFC4364]. 109 3. Solution Description 111 +------+ 112 +------+ RR +------+ 113 +-----------------+ | +------+ | +-----------------+ 114 |VPN_A:10.1.1.1/24| | | |VPN_A:10.1.1.1/24| 115 | \ | | | | / | 116 | +------+ \++---+-+ +-+---++/ +------+ | 117 | |Host A+------+ PE-1 | | PE-2 +------+Host B| | 118 | +------+\ ++-+-+-+ +-+-+-++ /+------+ | 119 | 10.1.1.2/24 | | | | | | 10.1.1.3/24 | 120 | | | | | | | | 121 | DC West | | | IP/MPLS Backbone | | | DC East | 122 +-----------------+ | | | | +-----------------+ 123 | +--------------------+ | 124 | | 125 VRF_A : V VRF_A : V 126 +-------------+---------+--------+ +-------------+---------+--------+ 127 | Prefix | Nexthop |Protocol| | Prefix | Nexthop |Protocol| 128 +-------------+---------+--------+ +-------------+---------+--------+ 129 |10.1.1.1/32 |127.0.0.1| Direct | |10.1.1.1/32 |127.0.0.1| Direct | 130 +-------------+---------+--------+ +-------------+---------+--------+ 131 |10.1.1.2/32 |10.1.1.2 | Direct | |10.1.1.3/32 |10.1.1.3 | Direct | 132 +-------------+---------+--------+ +-------------+---------+--------+ 133 |10.1.1.0/25 | RR | IBGP | |10.1.1.0/25 | RR | IBGP | 134 +-------------+---------+--------+ +-------------+---------+--------+ 135 |10.1.1.128/25| RR | IBGP | |10.1.1.128/25| RR | IBGP | 136 +-------------+---------+--------+ +-------------+---------+--------+ 137 |10.1.1.0/24 |10.1.1.1 | Direct | |10.1.1.0/24 |10.1.1.1 | Direct | 138 +-------------+---------+--------+ +-------------+---------+--------+ 140 Figure 1: RIB Reduction Example 142 To reduce the RIB size of PE routers in the Virtual Subnet context, 143 the L3VPN Address Prefix ORF mechanism is used to realize on-demand 144 route announcement. Take the VPN instance as shown in Figure 1 as an 145 example, the RIB reduction procedures are described as follows: 147 1. PE routers as RR clients advertise host routes for their local CE 148 hosts to the RR by using Rout Target (RT) ORF [RFC4364] (i.e., 149 the RR is configured to advertise route refresh messages 150 containing a RT-ORF entry corresponding to that VPN instance) or 151 Route Target (RT) Constrain [RFC4684] (i.e., the RR is configured 152 to advertise update messages containing RT membership information 153 corresponding to that VPN instance). Those PE routers belonging 154 to that VPN instance which don't want to receive remote CE host 155 routes of that VPN instance would notify the RR not to advertise 156 any host route to them by using the L3VPN Address Prefix ORF 157 mechanism (i.e., only requesting L3VPN routes with prefix length 158 less than 32 (in the VPNv4 case) or 128 (in the VPNv6 case)). 160 2. Meanwhile, the RR is configured with static routes for more 161 specific subnets (e.g., 10.1.1.0/25 and 10.1.1.128/25) 162 corresponding to the extended subnet (e.g., 10.1.1.0/24) with 163 next-hop being pointed to Null0 and then redistributes these 164 routes to BGP. In the case where the RR is not available for 165 transferring L3VPN traffic between PE routers for some reason 166 (e.g., the RR is running on a server), a particular PE router 167 other than the RR could be selected to advertise the above more 168 specific subnet routes as long as that PE router has learnt all 169 remote host routes belonging to that VPN instance. 171 3. Upon receiving a packet destined for a remote CE host from a 172 local CE host, if there is no host route for that remote CE host 173 in the FIB, the ingress PE router will forward the packet to the 174 RR according to the longest-matching subnet routes learnt from 175 the RR, which in turn forwards the packet to the relevant egress 176 PE router according to the host route learnt from that egress PE 177 router. As such, the RIB size of PE routers can be greatly 178 reduced at the cost of path stretch. 180 4. In order to forward packets destined for that remote CE host 181 directly to the corresponding egress PE router without any 182 potential path stretch penalty, ingress PE routers could perform 183 on-demand route learning of remote host routes by using one of 184 the following options: 186 A. Upon receiving an ARP request or Neighbor Solicitation (NS) 187 message from a local CE host, if there is no CE host route 188 for that target host in its RIB yetthe ingress PE router 189 would request the corresponding CE host route for the target 190 host from its RR by using the L3VPN Address Prefix ORF 191 mechanism. 193 B. Upon receiving a packet whose longest-matching FIB entry is a 194 particular more specific subnet routes (e.g., 10.1.1.0/25 and 195 10.1.1.128/25) learnt from the RR, a copy of this packet 196 would be sent to the control plane while this original packet 197 is forwarded as normal. The above copy sent to the control 198 plane would trigger a route pull for that destination CE 199 host. To provide robust protection against DoS attacks on 200 the control plane, rate-limiting of the above packets sent to 201 the control plane MUST be enabled. 203 5. RIB entries of remote CE host routes would expire if they have 204 not been used for forwarding for a certain period of time. Once 205 the expiration time for a given RIB entry is approaching, the PE 206 router would notify its RR to remove the corresponding L3VPN 207 Address Prefix ORF entry for that CE host route by using the 208 L3VPN Address Prefix ORF mechanism. 210 4. Acknowledgements 212 TBD. 214 5. IANA Considerations 216 There is no requirement for any IANA action. 218 6. Security Considerations 220 This document doesn't introduce additional security risk to BGP/MPLS 221 IP VPN, nor does it provide any additional security feature for BGP/ 222 MPLS IP VPN. 224 7. References 226 7.1. Normative References 228 [I-D.ietf-bess-virtual-subnet] 229 Xu, X., Raszuk, R., Jacquenet, C., Boyes, T., and B. Fee, 230 "Virtual Subnet: A BGP/MPLS IP VPN-based Subnet Extension 231 Solution", draft-ietf-bess-virtual-subnet-00 (work in 232 progress), June 2015. 234 [I-D.xu-bess-l3vpn-prefix-orf] 235 Xu, X., Jacquenet, C., and L. Fang, "L3VPN Address Prefix 236 Based Outbound Route Filter for BGP-4", draft-xu-bess- 237 l3vpn-prefix-orf-02 (work in progress), April 2015. 239 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 240 Requirement Levels", BCP 14, RFC 2119, 241 DOI 10.17487/RFC2119, March 1997, 242 . 244 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 245 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 246 2006, . 248 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 249 R., Patel, K., and J. Guichard, "Constrained Route 250 Distribution for Border Gateway Protocol/MultiProtocol 251 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 252 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 253 November 2006, . 255 7.2. Informative References 257 [I-D.ietf-bess-virtual-subnet-fib-reduction] 258 Xu, X., Jacquenet, C., Boyes, T., Fee, B., and W. 259 Henderickx, "FIB Reduction in Virtual Subnet", draft-ietf- 260 bess-virtual-subnet-fib-reduction-01 (work in progress), 261 July 2015. 263 Authors' Addresses 265 Xiaohu Xu 266 Huawei 268 Email: xuxiaohu@huawei.com 270 Susan Hares 271 Individual 273 Email: shares@ndzh.com 275 Yongbing Fan 276 China Telecom 278 Email: fanyb@gsta.com 280 Christian Jacquenet 281 Orange 283 Email: christian.jacquenet@orange.com 284 Truman Boyes 285 Bloomberg LP 287 Email: tboyes@bloomberg.net 289 Brendan Fee 290 Extreme Networks 292 Email: bfee@enterasys.com