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 14, 2013.

Copyright Notice

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

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
• 2. Problem Statement
• 3. Solution Statement
• 4. Domains
• 5. Sham Links
• 6. Behavioral Considerations
• 7. Security Considerations
• 8. Acknowledgements
• 9. References
• Author's Address

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).

		               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

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.

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).

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).

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].

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.

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.

8. Acknowledgements

The author would like to thank Paul Wells for his valuable input.

9. References

Author's Address