Internet Engineering Task Force D. Freedman Internet-Draft Claranet Intended status: Standards Track July 15, 2012 Expires: January 16, 2013 OSPF Version 2 as the Customer Edge/Customer Protocol for BGP/MPLS IP VPNs draft-freedman-l3vpn-ospf2-4364-ce-01 Abstract RFC4577 (OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP VPNs) proposes a mechanism for the use of the Open Shortest Path First V2 ("OSPF", RFC2328) protocol between the Provider Edge ("PE") and Customer Edge ("CE") routers within a BGP/MPLS IP Virtual Private Network ("IPVPN", RFC4364). The standard provides for use of such a provider VPN to join discontiguous locations together, preserving the OSPF area and domain behaviour. This document describes a technique for utilising the same, IPVPN network infrastructure without the requirement to enable the OSPF protocol on the PE/CE interface and thus relieve the PE router of OSPF duties. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 16, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Freedman Expires January 16, 2013 [Page 1] Internet-Draft draft-freedman-l3vpn-ospf2-4364-ce-01 July 2012 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 3. Solution Statement . . . . . . . . . . . . . . . . . . . . . . 6 4. Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Sham Links . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Behavioral Considerations . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Freedman Expires January 16, 2013 [Page 2] Internet-Draft draft-freedman-l3vpn-ospf2-4364-ce-01 July 2012 1. Introduction [RFC4577] describes a mechanism whereby discontiguous locations belonging to the same OSPF area and domain are connected by use of an [RFC4364] IPVPN network. The premise (see Figure 1) is that OSPF [RFC2328] routing information from a site is learned by the attached PE router through an OSPF adjacency with the site's CE router. This OSPF routing information is learned in the context of a Virtual Routing and Forwarding ("VRF") instance intended to trigger redistribution into the provider BGP as a VPN-IPv4 route through the addition of various Extended Communities [RFC4360] such as "Route Target" (to select the desired destination VRFs when imported by other PE routers), "OSPF Domain Identifier" (to determine if the route should be treated as internal or external to the CE OSPF domain) and "OSPF Route Type" (to encode the LSA type as it was received from the OSPF neighbor). When a remote PE router, importing such routes into a VRF (due to a matching Route-Target in a VRF import policy), locates the OSPF extended communities, it uses them to originate OSPF LSAs to its attached CE. Providing the OSPF domain ID is the same, BGP routes can be redistributed back into the CE-attached OSPF area using the information encoded in the BGP update, fooling the attached site into thinking that there is a contiguous OSPF domain. "Sham Links" may then be created between VPN residing endpoints on all involved PE routers, to provide simulated intra-area links, ensuring that any "Backdoor" links between C routers are not automatically selected by OSPF in preference to the provider network links (which would normally be treated as inter-area had the Sham Link not been present). Freedman Expires January 16, 2013 [Page 3] Internet-Draft draft-freedman-l3vpn-ospf2-4364-ce-01 July 2012 Sham Link _____________ / \ / ,-----. \ [PE1]; IPVPN +[PE2] | : BGP + | OSPF | `-----' | OSPF | | Site A [CE1] [CE2] Site B | Area 0 | OSPF | | OSPF [ C1] [C3 ] OSPF ,-' `. OSPF [ C2] [C4 ] \__________________/ Backdoor Link Figure 1 Freedman Expires January 16, 2013 [Page 4] Internet-Draft draft-freedman-l3vpn-ospf2-4364-ce-01 July 2012 2. Problem Statement The author infers from the title and language in RFC4577 that the original intention of the document was to provide OSPF functionality over an IPVPN network through use of the Provider's PE routers. Since the Provider may use the PE router for multiple customers, and OSPF is based on repeated execution of the Shortest Path First ("SPF") algorithm, this approach may create computation scaling considerations for the PE as the number or complexity of customer topologies using this technology on the PE increases. Freedman Expires January 16, 2013 [Page 5] Internet-Draft draft-freedman-l3vpn-ospf2-4364-ce-01 July 2012 3. Solution Statement This document proposes a mechanism for providing this OSPF functionality over IPVPN networks, using only CE routers in a single OSPF domain. A CE router that performs this function is to be known as an O-CE router. Only IP and BGP are therefore required between the O-CE and PE, this is illustrated below in Figure 2 ,-----. [PE1]; IPVPN +[PE2] | : + | BGP | `-----' | BGP | Sham | Site A [O-CE1]--------- [O-CE2] Site B | Link | OSPF | Area 0 | OSPF [ C1] [C3 ] OSPF ,-' `. OSPF [ C2] [C4 ] \__________________/ Backdoor Link Figure 2 By removing the OSPF from the PE router and placing the responsibility on the O-CE, the provider's existing IPVPN PE routers are no longer forced to run the SPF algorithm since this task can be delegated to the O-CE which does not have the same scaling concerns (it does not share this task with multiple customer domains). Freedman Expires January 16, 2013 [Page 6] Internet-Draft draft-freedman-l3vpn-ospf2-4364-ce-01 July 2012 4. Domains An O-CE is intended to only operate in one OSPF domain, known as the O-CD (O-CE Domain). Though the O-CD is intended to be operator configured on the O-CE, it may instead be automatically discovered (but such mechanisms are outside the scope of this document). It is assumed that the reachability signalled in the O-CD reflects the reachability inside the corresponding attached provider VRF. An O-CE receiving reachability information via BGP from the IPVPN network from the provider VRF should interact with the C router domain with respect to the O-CD in line with [RFC4577] Section 4.1. In these cases, the O-CE MAY choose to accept reachability concerning a domain other than the O-CD, in such case the O-CE must flood this information as extra-area (type 5/7). Freedman Expires January 16, 2013 [Page 7] Internet-Draft draft-freedman-l3vpn-ospf2-4364-ce-01 July 2012 5. Sham Links RFC4577 makes the following requirement of creating Sham Links (Sec 4.2.7.3): An OSPF protocol packet is regarded as having been received on a particular Sham Link if and only if the following three conditions hold: - The packet arrives as an MPLS packet, and its MPLS label stack causes it to be "delivered" to the local Sham Link endpoint address. - The packet's IP destination address is the local Sham Link endpoint address. - The packet's IP source address is the remote Sham Link endpoint address. Although RFC4577 marks the use of Sham Links as "OPTIONAL", creation of such links, with respect to the above stated, require that the implementation transmit the OSPF protocol packets over MPLS transport. Since the intention of this document is to ensure that only IP and BGP are required between O-CE routers, this document relaxes the requirements stated in this RFC section, by removing the requirement for the packet to arrive as an MPLS packet. Since the routing information is redistributed into the BGP and labelled by the PE router for use within the Provider's IPVPN network, an additional MPLS LSP is not required. This document adds the requirement that BGP should be used as a PE/ O-CE protocol and that Extended Communities be made available to both peers through mutual negotiation of the relevant BGP capability [RFC3392]. Freedman Expires January 16, 2013 [Page 8] Internet-Draft draft-freedman-l3vpn-ospf2-4364-ce-01 July 2012 6. Behavioral Considerations This document makes the following summary recommendations in respect to behavior: 1. That the requirement stated in Section 3 (Requirements) of RFC4577, that OSPF is used as a PE/CE routing protocol be relaxed, such that BGP is used as a PE/O-CE routing protocol and that BGP extended communities are enabled between PE and O-CE. A mechanism to filter said communities SHOULD be made available to the operator to ensure that no other (unwanted) extended communities are injected to or from the provider space. 2. That the requirement stated in Section 4.2.7.3 (OSPF Protocol on Sham Links) of RFC4577 with regards to the requirement that the OSPF protocol packet be received as an MPLS packet, be relaxed in an O-CE router implementation. In its place, the O-CE router MUST verify that the OSPF protocol packet is valid based on the operator configuration of valid Sham Link endpoints. Freedman Expires January 16, 2013 [Page 9] Internet-Draft draft-freedman-l3vpn-ospf2-4364-ce-01 July 2012 7. Security Considerations The Behavioral Considerations (Section 6) specify that particular behavioral patterns of RFC4577 be relaxed, references to ensuring appropriate security of these modified behaviors can be found here. It is important to note that the O-CE operates only in the context of the O-CD, this means that the RFC4577 requirements supporting multiple domain/instance behaviors are not relevant in the scope of the O-CE. Freedman Expires January 16, 2013 [Page 10] Internet-Draft draft-freedman-l3vpn-ospf2-4364-ce-01 July 2012 8. Acknowledgements The author would like to thank Paul Wells for his valuable input. Freedman Expires January 16, 2013 [Page 11] Internet-Draft draft-freedman-l3vpn-ospf2-4364-ce-01 July 2012 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002. [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4577, June 2006. Freedman Expires January 16, 2013 [Page 12] Internet-Draft draft-freedman-l3vpn-ospf2-4364-ce-01 July 2012 Author's Address David Freedman Claranet London UK Phone: +44 20 7685 8000 Email: david.freedman@uk.clara.net Freedman Expires January 16, 2013 [Page 13]