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]