idnits 2.17.1 draft-bhat-l3vpn-per-vpn-routing-00.txt: -(292): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(298): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 1 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (August 2004) is 7194 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) -- Looks like a reference, but probably isn't: '1' on line 15 -- Looks like a reference, but probably isn't: '2' on line 47 == Unused Reference: 'L3VPN-framework' is defined on line 297, but no explicit reference was found in the text -- No information found for draft-ietf-l3vpn-VPN-2547bis - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'VPN-2547bis' == Outdated reference: A later version (-15) exists of draft-rosen-vpn-mcast-07 ** Downref: Normative reference to an Historic draft: draft-rosen-vpn-mcast (ref. 'MCAST-VPN') Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 Internet Draft G Bhat 4 Expires: January 2005 Cosine 5 Communications 6 August 2004 8 Per VPN Routing for Layer 3 PPVPNs 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 [1]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes a method to do Per VPN routing for L3 PPVPNs. 35 The solution uses BGP for auto-discovery of VPN membership, but uses 36 Per VPN RIP instances and dynamic MPLS tunnel interfaces to exchange 37 customer routes. The document proposes modifications to the RIP 38 protocol to the make the solution scalable. The framework presented 39 also supports deployment of multicast routing and forwarding for L3 40 PPVPNs without enabling multicast in the core. 42 Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC-2119 [2]. 48 Table of Contents 50 draft-bhat-l3vpn-per-vpn-routing-00.txt August 2004 52 1. Introduction...................................................2 53 2. Per VPN Routing Solution.......................................3 54 2.1 MPLS Tunnel Interface......................................3 55 2.2 Routing over Tunnel Interfaces.............................4 56 2.3 Data Forwarding............................................4 57 2.4 Multicast over Tunnel Interfaces...........................4 58 3. Addressing Scalability.........................................5 59 Security Considerations...........................................6 60 Normative References..............................................6 61 Author's Addresses................................................7 62 Intellectual Property Notice......................................7 63 Full Copyright Statement..........................................7 65 1. Introduction 67 [VPN-2547bis] provides a framework to implement network-based layer 3 68 VPNs using BGP as the aggregated routing protocol. The framework 69 however has several drawbacks that are listed below. 71 - Typical BGP deployments use route-reflectors. Aggregated 72 routing using BGP means that the route-reflectors need to store 73 all customer routes. This leads to scalability issues when 74 there are a large number of VPNs. 76 - Route-reflectors and PE routers also need to carry Internet 77 routes. With the Internet routing tables still growing, storing 78 both Internet and VPN routes on one router again leads to 79 scalability issues. An additional concern is that disturbances 80 in VPN routing may affect Internet routing and vice-versa. One 81 could potentially get around these problems by using a network 82 design that separates Internet routing from VPN routing, but 83 that will likely result in a significant increase in complexity 84 as well as cost of deployment. 86 - BGP is designed for scalability and stability, but not for fast 87 convergence. Changes are not propagated by BGP routers 88 immediately, but are batched and sent together. Some BGP 89 implementations use the BGP scanner processes for next-hop 90 validation and for importing routes to VRFs. All these features 91 have an adverse impact on the convergence of VPN routing. BGP 92 scan interval can be reduced to improve convergence, but that 93 increases the load on the CPU. 95 - Multicast routing does not fit easily into this framework. The 96 method proposed in [MCAST-VPN] restricts the protocol used in 97 the customer network to PIM and requires significant changes to 98 PIM implementation on the PE. In addition, it requires 99 deployment of multicast and storing Per VPN state in the core 100 routers. There is also an extra-overhead in the forwarding 102 draft-bhat-l3vpn-per-vpn-routing-00.txt August 2004 104 plane because of the GRE encapsulation of data packets in the 105 core. 107 MPLS-based L2 VPN solutions can be used to address some of the issues 108 listed above. But the benefits of using a network-based L3 VPN 109 solution, namely deployment of network-based services like firewalls, 110 stateful packet filters and NAT, are lost using the L2 VPN approach. 112 This document presents a PPVPN solution that addresses all the above 113 issues. The solution presented builds on the framework provided in 114 [VPN-2547bis]. It uses the mechanisms provided in [VPN-2547bis] for 115 auto-discovery of all the VRFs belong a VPN and to setup LSPs 116 connecting VRFs. But instead of aggregate routing based on BGP to 117 exchange customer routes, this solution employs Per VPN routing. In a 118 Per VPN routing approach, routing protocols are run over the MPLS 119 LSPs to exchange customer routes. To facilitate running of routing 120 protocols over LSPs, the solution relies on creating MPLS tunnel 121 interfaces at the PE routers. To make the solution scalable, a 122 modified version of RIP is recommended as the routing protocol. 123 Details of the approach are presented below. 125 2. Per VPN Routing Solution 127 It is assumed that the provider network is configured to exchange 128 routes and data using [VPN-2547bis]. Per VPN routing (PVR) is enabled 129 on a VRF through configuration. Each PVR enabled VRF must be 130 configured with an MPLS tunnel endpoint address. It is preferable to 131 use the address of a loopback interface associated with the VRF for 132 this purpose. Each PVR enabled VRF must announce only the MPLS tunnel 133 endpoint address using [VPN-2547bis] (no customer routes must be 134 announced). Note that for this solution to work, all VRFs belonging 135 to the VPN must have Per VPN routing enabled. 137 2.1 MPLS Tunnel Interface 139 Assume VRF x and VRF y are two PVR enabled VRFs that belong to the 140 same VPN in PE routers A and B respectively. Let X and Y be the 141 respective MPLS tunnel endpoint addresses on the two VRFs. When PE 142 router A receives VPN route Y from PE router B, it creates a dynamic 143 unnumbered MPLS tunnel interface Ty with destination Y and associates 144 it with VRF x. Similarly, router B creates a dynamic tunnel interface 145 Tx associated with VRF y when it receives VPN route X. The tunnel 146 interface uses the label-stack associated with tunnel destination 147 route to send packets. So any packet sent out of tunnel interface Ty 148 on PE router A is sent to VRF y exactly the same way as any data 149 packet would be sent to VRF y using [VPN-2547bis]. 151 draft-bhat-l3vpn-per-vpn-routing-00.txt August 2004 153 PE router A treats any labeled packet destined to VRF x with a source 154 IP address that matches the tunnel destination (Y in this case) as 155 having arrived on the tunnel interface Ty. To ensure that routing 156 control packets sent over the tunnel interface at a PE router are 157 received on the corresponding tunnel interface at the remote PE 158 router, the sender must set the source IP address on the routing 159 protocol control packets to the MPLS tunnel endpoint address 160 configured on the VRF. In the earlier example, whenever VRF y sends 161 routing control packets to VRF x over tunnel Tx, it sets the source 162 of the packets to Y. 164 2.2 Routing over Tunnel Interfaces 166 After the MPLS tunnel interface is setup, routing information can be 167 exchanged over the tunnel using the method described in the previous 168 section. As far as the routing protocol is concerned the tunnel 169 interface appears as any other unnumbered point-to-point link. 170 Adjacencies can thus be formed and routes exchanged over the tunnel 171 interface. 173 Scalability issues arising from having a large number of protocol 174 instances on the PE-router dictate the choice of routing protocol 175 used. The RIP protocol with some simple modifications happens to be 176 ideally suited for this purpose. Section 3 discusses this in more 177 detail. 179 2.3 Data Forwarding 181 The routes learnt through the routing protocols over the tunnel 182 interface have the outgoing interface set to the tunnel interface. 183 Packets sent to these destinations are sent out with a 2-label stack 184 exactly as in [VPN-2547bis]. However, when VPN data traffic is 185 received on the PE router, the router needs to do two lookups for 186 each packet to determine how to forward the packet. The first lookup 187 is on the MPLS label, the second is on the destination IP address. It 188 is required that the receiving router support two-stage lookup in 189 hardware for this solution to be practical. Several vendor 190 implementations of [VPN-2547bis] already use two-stage lookups to 191 support distribution of one label per VRF (instead of one label per 192 route). 194 2.4 Multicast over Tunnel Interfaces 196 Just like unicast routing protocols, any multicast protocol (PIM-SM, 197 PIM-DM, DVMRP or MOSPF) can be enabled on the MPLS tunnel interfaces. 198 Multicast routing information can thus be exchanged across the core 199 without multicast being enabled on any of the P-routers. When 200 compared with the solution in [MCAST-VPN] there may some extra 201 overhead in the forwarding plane due to the overlay approach. But 203 draft-bhat-l3vpn-per-vpn-routing-00.txt August 2004 205 this lack of optimality is offset by the simplicity of the model and 206 by the use of MPLS encapsulation instead of GRE encapsulation for 207 multicast data traffic. 209 3. Addressing Scalability 211 As mentioned earlier, the biggest concern with using a Per VPN 212 routing solution is the large number of instances of the routing 213 protocol on the PE-router. With a link-state protocol like OSPF, the 214 large number of decision processes on the PE router along with the 215 large number of different link-state databases makes the solution 216 impractical. 218 Compared to OSPF, RIP is much simpler and consumes very little 219 resources on the router. But RIP has a few problems of its own which 220 are listed below. 222 1. RIP requires that the entire routing table be sent to all 223 neighbors every 30 seconds. This is a big overhead on the core 224 network when compared with aggregate routing using BGP where 225 updates are sent only when there are changes in the routing 226 table. 228 2. Routing updates received on one tunnel are propagated across all 229 the other tunnel interfaces. When compared with aggregate 230 routing using BGP, this again is extra control traffic going 231 across the core (By design BGP routers do not propagate routes 232 learnt over one IBGP session to another IBGP session). This also 233 can lead to count-to-infinity problems and slow convergence when 234 PE-routers crash. 236 However, both problems can be solved with some modifications to RIP. 237 Problem 2 can be solved by simply making RIP emulate BGP. In other 238 words, RIP can be modified so that routing updates received over a 239 MPLS tunnel interface are propagated to non-tunnel interfaces only. 240 Problem 1 however requires a more careful consideration. In normal 241 RIP processing, periodic updates are used to detect whether the 242 neighbor or the link to the neighbor is down. Since RIP runs over UDP 243 and does not use acknowledgements, periodic updates are the only 244 mechanism to handle lost updates. In the PPVPN scenario, neighbor 245 liveness can be detected from the status of the route to the tunnel 246 destination. If the remote PE router crashes for any reason, the 247 route to the MPLS tunnel destination will be deleted and tunnel will 248 be brought down. Periodic updates are therefore not required to 249 detect neighbor liveness. They can be eliminated altogether if some 250 mechanism can be devised to deliver routing updates reliably. 251 [RFC1582] describes exactly such a mechanism. This RFC, originally 252 proposed for running RIP over demand circuits, actually describes all 253 the extensions to RIP required to make it work without periodic 255 draft-bhat-l3vpn-per-vpn-routing-00.txt August 2004 257 updates. Implementing this RFC should therefore directly address 258 problem 1 (some vendor implementations of RIP already support this 259 RFC). 261 Some routing implementations may have RIP as a separate process. For 262 these implementations, there is no way to know that the neighbor is 263 down if the remote RIP process crashes. In these cases, the MPLS 264 tunnel endpoints from a VRF must be announced using [VPN-2547bis] 265 only if the corresponding RIP instance is alive. If the RIP instance 266 crashes, the tunnel endpoint route must be withdrawn. 268 It is clear that with the above modifications, the amount of 269 processing at the PE router using Per VPN RIP routing will be 270 comparable to that with BGP aggregate routing. RIP by design uses 271 minimal data structures, so impact on the PE router in terms of 272 memory usage should be minimal. Routing convergence also should be 273 significantly faster with this approach. 275 Security Considerations 277 De-multiplexing packets based on the source address could be a 278 security concern. In our earlier example, a customer attached to VRX 279 y could spoof RIP packets to VRF x by sending RIP packets with 280 destination set to X and source set to Y. One way to get around this 281 is to enable authentication for the RIP instances on the two VRFs. 282 Another approach would be to do unicast RPF (Reverse Path Forwarding) 283 check on all packets coming from the CE routers. 285 Normative References 287 [VPN-2547bis] "BGP/MPLS VPNs", draft-ietf-l3vpn-VPN-2547bis-01.txt, 288 Rosen, Rekhter, et. al. September 2003 290 [RFC1582] Meyer, G.,�RIP over Demand Circuits�, RFC 1582, 1994. 292 [MCAST-VPN] �Multicast in MPLS/BGP IP VPNs�, draft-rosen-vpn-mcast- 293 07.txt, Rosen, Cai, et. al. May 2004 295 Informative References 297 [L3VPN-framework] �A Framework for Layer 3 Provider Provisioned 298 Virtual Private Networks�, draft-ietf-l3vpn-framework-00.txt, Callon 299 R., Suzuki M., March 2003 301 draft-bhat-l3vpn-per-vpn-routing-00.txt August 2004 303 Author's Addresses 305 Girish S. Bhat 306 Cosine Communications 307 1200 Bridge Parkway 308 Redwood City, CA 94065 309 Email: gbhat@cosinecom.com 311 Intellectual Property Notice 313 The IETF takes no position regarding the validity or scope of any 314 intellectual property or other rights that might be claimed to 315 pertain to the implementation or use of the technology described in 316 this document or the extent to which any license under such rights 317 might or might not be available; neither does it represent that it 318 has made any effort to identify any such rights. Information on the 319 IETF's procedures with respect to rights in standards-track and 320 standards-related documentation can be found in BCP-11. Copies of 321 claims of rights made available for publication and any assurances of 322 licenses to be made available, or the result of an attempt made to 323 obtain a general license or permission for the use of such 324 proprietary rights by implementors or users of this specification can 325 be obtained from the IETF Secretariat. 327 The IETF invites any interested party to bring to its attention any 328 copyrights, patents or patent applications, or other proprietary 329 rights which may cover technology that may be required to practice 330 this standard. Please address the information to the IETF Executive 331 Director. 333 Full Copyright Statement 335 "Copyright (C) The Internet Society (2004). All Rights Reserved. 336 This document and translations of it may be copied and furnished to 337 others, and derivative works that comment on or otherwise explain it 338 or assist in its implementation may be prepared, copied, published 339 and distributed, in whole or in part, without restriction of any 340 kind, provided that the above copyright notice and this paragraph are 341 included on all such copies and derivative works. However, this 342 document itself may not be modified in any way, such as by removing 343 the copyright notice or references to the Internet Society or other 344 Internet organizations, except as needed for the purpose of 345 developing Internet standards in which case the procedures for 346 copyrights defined in the Internet Standards process must be 347 followed, or as required to translate it into languages other than 348 English. 350 draft-bhat-l3vpn-per-vpn-routing-00.txt August 2004 352 The limited permissions granted above are perpetual and will not be 353 revoked by the Internet Society or its successors or assigns. 355 This document and the information contained herein is provided on an 356 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 357 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 358 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 359 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 360 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."