Request for Comments: 4577 P. Psenak
Updates: 4364 P. Pillay-Esnault
Category: Standards Track Cisco Systems, Inc.
June 2006
OSPF as the Provider/Customer Edge Protocol for
BGP/MPLS IP Virtual Private Networks (VPNs)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Many Service Providers offer Virtual Private Network (VPN) services
to their customers, using a technique in which customer edge routers
(CE routers) are routing peers of provider edge routers (PE routers).
The Border Gateway Protocol (BGP) is used to distribute the
customer’s routes across the provider’s IP backbone network, and
Multiprotocol Label Switching (MPLS) is used to tunnel customer
packets across the provider’s backbone. This is known as a "BGP/MPLS
IP VPN". The base specification for BGP/MPLS IP VPNs presumes that
the routing protocol on the interface between a PE router and a CE
router is BGP. This document extends that specification by allowing
the routing protocol on the PE/CE interface to be the Open Shortest
Path First (OSPF) protocol.
This document updates RFC 4364.
Table of Contents
1. Introduction ....................................................2
2. Specification of Requirements ...................................3
3. Requirements ....................................................4
4. BGP/OSPF Interaction Procedures for PE Routers ..................6
4.1. Overview ...................................................6
4.1.1. VRFs and OSPF Instances .............................6
4.1.2. VRFs and Routes .....................................6
4.1.3. Inter-Area, Intra-Area, and External Routes .........7
4.1.4. PEs and OSPF Area 0 .................................8
4.1.5. Prevention of Loops .................................9
4.2. Details ....................................................9
4.2.1. Independent OSPF Instances in PEs ...................9
4.2.2. Router ID ..........................................10
4.2.3. OSPF Areas .........................................10
4.2.4. OSPF Domain Identifiers ............................10
4.2.5. Loop Prevention ....................................12
4.2.5.1. The DN Bit ................................12
4.2.5.2. Use of OSPF Route Tags ....................12
4.2.5.3. Other Possible Loops ......................13
4.2.6. Handling LSAs from the CE ..........................14
4.2.7. Sham Links .........................................16
4.2.7.1. Intra-Area Routes .........................16
4.2.7.2. Creating Sham Links .......................17
4.2.7.3. OSPF Protocol on Sham Links ...............18
4.2.7.4. Routing and Forwarding on Sham Links ......19
4.2.8. VPN-IPv4 Routes Received via BGP ...................19
4.2.8.1. External Routes ...........................20
4.2.8.2. Summary Routes ............................22
4.2.8.3. NSSA Routes ...............................22
5. IANA Considerations ............................................22
6. Security Considerations ........................................23
7. Acknowledgements ...............................................23
8. Normative References ...........................................23
9. Informative References .........................................24
1. Introduction
[VPN] describes a method by which a Service Provider (SP) can use its
IP backbone to provide a VPN (Virtual Private Network) service to
customers. In that method, a customer’s edge devices (CE devices)
are connected to the provider’s edge routers (PE routers). If the CE
device is a router, then the PE router may become a routing peer of
the CE router (in some routing protocol) and may, as a result, learn
the routes that lead to the CE’s site and that need to be distributed
to other PE routers that attach to the same VPN.
The PE routers that attach to a common VPN use BGP (Border Gateway
Protocol) to distribute the VPN’s routes to each other. A CE router
can then learn the routes to other sites in the VPN by peering with
its attached PE router in a routing protocol. CE routers at
different sites do not, however, peer with each other.
It can be expected that many VPNs will use OSPF (Open Shortest Path
First) as their IGP (Interior Gateway Protocol), i.e., the routing
protocol used by a network for the distribution of internal routes
within that network. This does not necessarily mean that the PE
routers need to use OSPF to peer with the CE routers. Each site in a
VPN can use OSPF as its intra-site routing protocol, while using, for
example, BGP [BGP] or RIP (Routing Information Protocol) [RIP] to
distribute routes to a PE router. However, it is certainly
convenient, when OSPF is being used intra-site, to use it on the
PE-CE link as well, and [VPN] explicitly allows this.
Like anything else, the use of OSPF on the PE-CE link has advantages
and disadvantages. The disadvantage to using OSPF on the PE-CE link
is that it gets the SP’s PE router involved, however peripherally, in
a VPN site’s IGP. The advantages though are:
- The administrators of the CE router need not have any expertise
in any routing protocol other than OSPF.
- The CE routers do not need to have support for any routing
protocols other than OSPF.
- If a customer is transitioning his network from a traditional
OSPF backbone to the VPN service described in [VPN], the use of
OSPF on the PE-CE link eases the transitional issues.
It seems likely that some SPs and their customers will resolve these
trade-offs in favor of the use of OSPF on the PE-CE link. Thus, we
need to specify the procedures that must be implemented by a PE
router in order to make this possible. (No special procedures are
needed in the CE router though; CE routers just run whatever OSPF
implementations they may have.)
2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Requirements
Consider a set of VPN sites that are thought of as being in the same
"OSPF domain". Two sites are considered to be in the same OSPF
domain if it is intended that routes from one site to the other be
considered intra-network routes. A set of OSPF sites in the same
domain will almost certainly be a set of sites that together
constitute an "intranet", each of which runs OSPF as its intra-site
routing protocol.
Per [VPN], the VPN routes are distributed among the PE routers by
BGP. If the PE uses OSPF to distribute routes to the CE router, the
standard procedures governing BGP/OSPF interactions [OSPFv2] would
cause routes from one site to be delivered to another in type 5 LSAs
(Link State Advertisements), as "AS-external" routes. This is
undesirable; it would be much better to deliver such routes in type 3
LSAs (as inter-area routes), so that they can be distinguished from
any "real" AS-external routes that may be circulating in the VPN
(that is, so that they can be distinguished by OSPF from routes that
really do not come from within the VPN). Hence, it is necessary for
the PE routers to implement a modified version of the BGP/OSPF
interaction procedures.
In fact, we would like to have a very general set of procedures that
allows a customer to replace a legacy private OSPF backbone easily
with the VPN service. We would like this procedure to meet the
following set of requirements:
- The procedures should not make assumptions about the OSPF
topology. In particular, it should not be assumed that
customer sites are OSPF stub sites or NSSA (Not So Stubby Area)
sites. Nor should it be assumed that a customer site contains
only one OSPF area, or that it has no area 0 routers.
- If VPN sites A and B are in the same OSPF domain, then routes
from one should be presented to the other as OSPF intra-network
routes. In general, this can be done by presenting such routes
as inter-area routes in type 3 LSAs.
Note that this allows two VPN sites to be connected via an
"OSPF backdoor link". That is, one can have an OSPF link
between the two sites that is used only when the VPN backbone
is unavailable. (This would not be possible with the ordinary
BGP/OSPF interaction procedures. The ordinary procedures would
present routes via the VPN backbone as AS-external routes, and
these could never be preferred to intra-network routes.) This
may be very useful during a period of transition from a legacy
OSPF backbone to a VPN backbone.
- It should be possible to make use of an "OSPF backdoor link"
between two sites, even if the two sites are in the same OSPF
area and neither of the routers attached to the inter-site
backdoor link is an area 0 router. This can also be very
useful during a transition period, and it eliminates any need
to reconfigure the sites’ routers to be ABRs (Area Border
Routers).
Assuming that it is desired to have the route via the VPN
backbone be preferred to the backdoor route, the VPN backbone
itself must be presented to the CE routers at each site as a
link between the two PE routers to which the CE routers are
respectively attached.
- CE routers, connected to PE routers of the VPN service, may
themselves function as OSPF backbone (area 0) routers. An OSPF
backbone may even consist of several "segments" that are
interconnected themselves only via the VPN service. In such a
scenario, full intercommunication between sites connected to
different segments of the OSPF backbone should still be
possible.
- The transition from the legacy private OSPF backbone to the VPN
service must be simple and straightforward. The transition is
likely to be phased, such that customer sites are migrated one
by one from the legacy private OSPF backbone to the VPN
service. During the transition, any given site might be
connected to the VPN service, to the legacy OSPF backbone, or
to both. Complete connectivity among all such sites must be
maintained.
Since the VPN service is to replace the legacy backbone, it
must be possible, by suitable adjustment of the OSPF metrics,
to make OSPF prefer routes that traverse the SP’s VPN backbone
to alternative routes that do not.
- The OSPF metric assigned to a given route should be carried
transparently over the VPN backbone.
Routes from sites that are not in the same OSPF domain will appear as
AS-external routes.
We presuppose familiarity with the contents of [OSPFv2], including
the OSPF LSA types, and will refer without further exegesis to type
1, 2, 3, etc. LSAs. Familiarity with [VPN] is also presupposed.
4. BGP/OSPF Interaction Procedures for PE Routers
4.1. Overview
4.1.1. VRFs and OSPF Instances
A PE router that attaches to more than one OSPF domain MUST run an
independent instance of OSPF for each domain. If the PE is running
OSPF as its IGP (Interior Gateway Protocol), the instance of OSPF
running as the IGP must be separate and independent from any other
instance of OSPF that the PE is running. (Whether these instances
are realized as separate processes or merely as separate contexts of
a common process is an implementation matter.) Each interface that
attaches to a VPN site belongs to no more than one OSPF instance.
[VPN] defines the notion of a Per-Site Routing and Forwarding Table,
or VRF. Each VRF is associated with a set of interfaces. If a VRF
is associated with a particular interface, and that interface belongs
to a particular OSPF instance, then that OSPF instance is said to be
associated with the VRF. If two interfaces belong to the same OSPF
instance, then both interfaces must be associated with the same VRF.
If an interface attaches a PE to a CE, and that interface is
associated with a VRF, we will speak of the CE as being associated
with the VRF.
4.1.2. VRFs and Routes
OSPF is used to distribute routes from a CE to a PE. The standard
OSPF decision process is used to install the best OSPF-distributed
routes in the VRF.
Per [VPN], BGP is used to distribute VPN-IPv4 routes among PE
routers. An OSPF route installed in a VRF may be "exported" by being
redistributed into BGP as a VPN-IPv4 route. It may then be
distributed by BGP to other PEs. At the other PEs, a VPN-IPv4 route
may be "imported" by a VRF and may then be redistributed into one or
more of the OSPF instances associated with that VRF.
Import from and export to particular VRFs is controlled by the use of
the Route Target Extended Communities attribute (or, more simply,
Route Target or RT), as specified in [VPN].
A VPN-IPv4 route is "eligible for import" into a particular VRF if
its Route Target is identical to one of the VRF’s import Route
Targets. The standard BGP decision process is used to select, from
among the routes eligible for import, the set of VPN-IPv4 routes to
be "installed" in the VRF.
If a VRF contains both an OSPF-distributed route and a VPN-IPv4 route
for the same IPv4 prefix, then the OSPF-distributed route is
preferred. In general, this means that forwarding is done according
to the OSPF route. The one exception to this rule has to do with the
"sham link". If the next hop interface for an installed (OSPF-
distributed) route is the sham link, forwarding is done according to
a corresponding BGP route. This is detailed in Section 4.2.7.4.
To meet the requirements of Section 3, a PE that installs a
particular route into a particular VRF needs to know whether that
route was originally an OSPF route and, if so, whether the OSPF
instance from which it was redistributed into BGP is in the same
domain as the OSPF instances into which the route may be
redistributed. Therefore, a domain identifier is encoded as a BGP
Extended Communities attribute [EXTCOMM] and distributed by BGP along
with the VPN-IPv4 route. The route’s OSPF metric and OSPF route type
are also carried as BGP attributes of the route.
4.1.3. Inter-Area, Intra-Area, and External Routes
If a PE installs a particular VPN-IPv4 route (learned via BGP) in a
VRF, and if this is the preferred BGP route for the corresponding
IPv4 prefix, the corresponding IPv4 route is then "eligible for
redistribution" into each OSPF instance that is associated with the
VRF. As a result, it may be advertised to each CE in an LSA.
Whether a route that is eligible for redistribution into OSPF is
actually redistributed into a particular OSPF instance may depend
upon the configuration. For instance, the PE may be configured to
distribute only the default route into a given OSPF instance. In
this case, the routes that are eligible for redistribution would not
actually be redistributed.
In the following, we discuss the procedures for redistributing a
BGP-distributed VPN-IPv4 route into OSPF; these are the procedures to
be followed whenever such a route is eligible to be redistributed
into OSPF and the configuration does not prevent such redistribution.
If the route is from an OSPF domain different from that of the OSPF
instance into which it is being redistributed, or if the route is not
from an OSPF domain at all, then the route is considered an external
route.
If the route is from the same OSPF domain as the OSPF instance into
which it is being redistributed, and if it was originally advertised
to a PE as an OSPF external route or an OSPF NSSA route, it will be
treated as an external route. Following the normal OSPF procedures,
external routes may be advertised to the CE in type 5 LSAs, or in
type 7 LSAs, or not at all, depending on the type of area to which
the PE/CE link belongs.
If the route is from the same OSPF domain as the OSPF instance into
which it is being redistributed, and if it was originally advertised
to a PE as an inter-area or intra-area route, the route will
generally be advertised to the CE as an inter-area route (in a type 3
LSA).
As a special case, suppose that PE1 attaches to CE1, and that PE2
attaches to CE2, where:
- the OSPF instance containing the PE1-CE1 link and the OSPF
instance containing the PE2-CE2 link are in the same OSPF
domain, and
- the PE1-CE1 and PE2-CE2 links are in the same OSPF area A (as
determined by the configured OSPF area number),
then, PE1 may flood to CE1 a type 1 LSA advertising a link to PE2,
and PE2 may flood to CE2 a type 1 LSA advertising a link to PE1. The
link advertised in these LSAs is known as a "sham link", and it is
advertised as a link in area A. This makes it look to routers within
area A as if the path from CE1 to PE1 across the service provider’s
network to PE2 to CE2 is an intra-area path. Sham links are an
OPTIONAL feature of this specification and are used only when it is
necessary to have the service provider’s network treated as an
intra-area link. See Section 4.2.7 for further details about the
sham link.
The precise details by which a PE determines the type of LSA used to
advertise a particular route to a CE are specified in Section 4.2.8.
Note that if the VRF is associated with multiple OSPF instances, the
type of LSA used to advertise the route might be different in
different instances.
Note that if a VRF is associated with several OSPF instances, a given
route may be redistributed into some or all of those OSPF instances,
depending on the characteristics of each instance. If redistributed
into two or more OSPF instances, it may be advertised within each
instance using a different type of LSA, again depending on the
characteristics of each instance.
4.1.4. PEs and OSPF Area 0
Within a given OSPF domain, a PE may attach to multiple CEs. Each
PE/CE link is assigned (by configuration) to an OSPF area. Any link
can be assigned to any area, including area 0.
If a PE attaches to a CE via a link that is in a non-zero area, then
the PE serves as an ABR for that area.
PEs can thus be considered OSPF "area 0 routers", i.e., they can be
considered part of the "OSPF backbone". Thus, they are allowed to
distribute inter-area routes to the CE via Type 3 LSAs.
If the OSPF domain has any area 0 routers other than the PE routers,
then at least one of those MUST be a CE router and MUST have an area
0 link to at least one PE router. This adjacency MAY be via an OSPF
virtual link. (The ability to use an OSPF virtual link in this way
is an OPTIONAL feature.) This is necessary to ensure that inter-area
routes and AS-external routes can be leaked between the PE routers
and the non-PE OSPF backbone.
Two sites that are not in the same OSPF area will see the VPN
backbone as being an integral part of the OSPF backbone. However, if
there are area 0 routers that are NOT PE routers, then the VPN
backbone actually functions as a sort of higher-level backbone,
providing a third level of hierarchy above area 0. This allows a
legacy OSPF backbone to become disconnected during a transition
period, as long as the various segments all attach to the VPN
backbone.
4.1.5. Prevention of Loops
If a route sent from a PE router to a CE router could then be
received by another PE router from one of its own CE routers, it
would be possible for routing loops to occur. To prevent this, a PE
sets the DN bit [OSPF-DN] in any LSA that it sends to a CE, and a PE
ignores any LSA received from a CE that already has the DN bit sent.
Older implementations may use an OSPF Route Tag instead of the DN
bit, in some cases. See Sections 4.2.5.1 and 4.2.5.2.
4.2. Details
4.2.1. Independent OSPF Instances in PEs
The PE MUST support one OSPF instance for each OSPF domain to which
it attaches. These OSPF instances function independently and do not
leak routes to each other. Each instance of OSPF MUST be associated
with a single VRF. If n CEs associated with that VRF are running
OSPF on their respective PE/CE links, then those n CEs are OSPF
adjacencies of the PE in the corresponding instance of OSPF.
Generally, though not necessarily, if the PE attaches to several CEs
in the same OSPF domain, it will associate the interfaces to those
PEs with a single VRF.
4.2.2. Router ID
If a PE and a CE are communicating via OSPF, the PE will have an OSPF
Router ID that is valid (i.e., unique) within the OSPF domain. More
precisely, each OSPF instance has a Router ID. Different OSPF
instances may have different Router IDs.
4.2.3. OSPF Areas
A PE-CE link may be in any area, including area 0; this is a matter
of the OSPF configuration.
If a PE has a link that belongs to a non-zero area, the PE functions
as an Area Border Router (ABR) for that area.
PEs do not pass along the link state topology from one site to
another (except in the case where a sham link is used; see Section
4.2.7).
Per [OSPFv2, Section 3.1], "the OSPF backbone always contains all
area border routers". The PE routers are therefore considered area 0
routers. Section 3.1 of [OSPFv2] also requires that area 0 be
contiguous. It follows that if the OSPF domain has any area 0
routers other than the PE routers, at least one of those MUST be a CE
router, and it MUST have an area 0 link (possibly a virtual link) to
at least one PE router.
4.2.4. OSPF Domain Identifiers
Each OSPF instance MUST be associated with one or more Domain
Identifiers. This MUST be configurable, and the default value (if
none is configured) SHOULD be NULL.
If an OSPF instance has multiple Domain Identifiers, one of these is