draft-ietf-l3vpn-ospfv3-pece-10.txt   draft-ietf-l3vpn-ospfv3-pece-11.txt 
Network Working Group P. Pillay-Esnault Network Working Group P. Pillay-Esnault
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track P. Moyer Intended status: Standards Track P. Moyer
Expires: June 4, 2012 Pollere, Inc Expires: July 13, 2012 Pollere, Inc
J. Doyle J. Doyle
Jeff Doyle and Associates Jeff Doyle and Associates
E. Ertekin E. Ertekin
M. Lundberg M. Lundberg
Booz Allen Hamilton Booz Allen Hamilton
December 2, 2011 January 10, 2012
OSPFv3 as a PE-CE routing protocol OSPFv3 as a PE-CE routing protocol
draft-ietf-l3vpn-ospfv3-pece-10 draft-ietf-l3vpn-ospfv3-pece-11
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 1, line 37 skipping to change at page 1, line 37
than English. than English.
Abstract Abstract
Many Service Providers (SPs) offer Virtual Private Network (VPN) Many Service Providers (SPs) offer Virtual Private Network (VPN)
services to their customers using a technique in which Customer Edge services to their customers using a technique in which Customer Edge
(CE) routers are routing peers of Provider Edge (PE) routers. The (CE) routers are routing peers of Provider Edge (PE) routers. The
Border Gateway Protocol (BGP) is used to distribute the customer's Border Gateway Protocol (BGP) is used to distribute the customer's
routes across the provider's IP backbone network, and Multiprotocol routes across the provider's IP backbone network, and Multiprotocol
Label Switching (MPLS) is used to tunnel customer packets across the Label Switching (MPLS) is used to tunnel customer packets across the
provider's backbone. This is known as a "BGP/MPLS IP VPN". provider's backbone. Support currently exists for both IPv4 and IPv6
Originally only IPv4 was supported and it was later extended to VPNs, however only Open Shortest Path First protocol version 2
support IPv6 VPNs as well. Extensions were later added for the (OSPFv2) as PE-CE protocol is specified. This document extends those
support of the Open Shortest Path First protocol version 2 (OSPFv2) specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing
as a PE-CE routing protocol for the IPv4 VPNs. This document extends protocol. The OSPFv3 PE-CE functionality is identical to that of
those specifications to support OSPF version 3 (OSPFv3) as a PE-CE OSPFv2 except for the differences described in this document.
routing protocol. The OSPFv3 PE-CE functionality is identical to
that of OSPFv2 except for the differences described in this document.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 4, 2012. This Internet-Draft will expire on July 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 9 skipping to change at page 3, line 9
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Specification of Requirements . . . . . . . . . . . . . . . . 4 2. Specification of Requirements . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. OSPFv3 Specificities . . . . . . . . . . . . . . . . . . . 5 3.1. OSPFv3 Specificities . . . . . . . . . . . . . . . . . . . 5
4. BGP/OSPFv3 Interaction Procedures for PE Routers . . . . . . . 6 4. BGP/OSPFv3 Interaction Procedures for PE Routers . . . . . . . 5
4.1. VRFs and OSPFv3 Instances . . . . . . . . . . . . . . . . 6 4.1. VRFs and OSPFv3 Instances . . . . . . . . . . . . . . . . 5
4.1.1. Independent OSPFv3 Instances in PEs . . . . . . . . . 6 4.1.1. Independent OSPFv3 Instances in PEs . . . . . . . . . 6
4.1.2. OSPFv3 Domain Identifier . . . . . . . . . . . . . . . 6 4.1.2. OSPFv3 Domain Identifier . . . . . . . . . . . . . . . 6
4.2. OSPFv3 Areas . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. OSPFv3 Areas . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. VRFs and Routes . . . . . . . . . . . . . . . . . . . . . 7 4.3. VRFs and Routes . . . . . . . . . . . . . . . . . . . . . 7
4.3.1. OSPFv3 Routes on PE . . . . . . . . . . . . . . . . . 8 4.3.1. OSPFv3 Routes on PE . . . . . . . . . . . . . . . . . 8
4.3.2. VPN-IPv6 Routes Received from MP-BGP . . . . . . . . . 9 4.3.2. VPN-IPv6 Routes Received from MP-BGP . . . . . . . . . 9
4.4. BGP Extended Communities Attribute . . . . . . . . . . . . 12 4.4. BGP Extended Communities Attribute . . . . . . . . . . . . 11
4.5. Loop Prevention Techniques . . . . . . . . . . . . . . . . 14 4.5. Loop Prevention Techniques . . . . . . . . . . . . . . . . 14
4.5.1. OSPFv3 Down Bit . . . . . . . . . . . . . . . . . . . 14 4.5.1. OSPFv3 Down Bit . . . . . . . . . . . . . . . . . . . 14
4.5.2. Other Possible Loops . . . . . . . . . . . . . . . . . 15 4.5.2. Other Possible Loops . . . . . . . . . . . . . . . . . 14
5. OSPFv3 Sham Links . . . . . . . . . . . . . . . . . . . . . . 15 5. OSPFv3 Sham Links . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Creating A Sham link . . . . . . . . . . . . . . . . . . . 16 5.1. Creating A Sham link . . . . . . . . . . . . . . . . . . . 16
5.2. OSPF Protocol On Sham link . . . . . . . . . . . . . . . . 16 5.2. OSPF Protocol On Sham link . . . . . . . . . . . . . . . . 16
5.3. OSPF Packet Forwarding On Sham Link . . . . . . . . . . . 17 5.3. OSPF Packet Forwarding On Sham Link . . . . . . . . . . . 17
6. Multiple Address Family Support . . . . . . . . . . . . . . . 17 6. Multiple Address Family Support . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
[rfc4364] offers Service Providers (SPs) a method for providing [rfc4364] offers Service Providers (SPs) a method for providing
Layer-3 Virtual Private Network (VPN) services to subtending customer Layer-3 Virtual Private Network (VPN) services to subtending customer
skipping to change at page 4, line 20 skipping to change at page 4, line 20
(PE) routers separate customer VPN routing information into Virtual (PE) routers separate customer VPN routing information into Virtual
Routing and Forwarding (VRF) tables. The Border Gateway Protocol Routing and Forwarding (VRF) tables. The Border Gateway Protocol
(BGP) is used to disseminate customer network VPN routes between PE (BGP) is used to disseminate customer network VPN routes between PE
VRFs configured in the same VPN. VRFs configured in the same VPN.
The initial BGP/MPLS IP VPN specification enabled PE routers to learn The initial BGP/MPLS IP VPN specification enabled PE routers to learn
routes within customer sites through static routing, or through a routes within customer sites through static routing, or through a
dynamic routing protocol instantiated on the PE-CE link. dynamic routing protocol instantiated on the PE-CE link.
Specifically, [rfc4364] (and its predecessor, [rfc2547]) included Specifically, [rfc4364] (and its predecessor, [rfc2547]) included
support for dynamic routing protocols such as BGP, RIP, and OSPFv2. support for dynamic routing protocols such as BGP, RIP, and OSPFv2.
The OSPFv2 as the Provider/Customer Edge Protocol for BGP/MPLS IP The OSPFv2 as the Provider/Customer Edge Protocol specification
Virtual Private Networks specification [rfc4577] further updates the [rfc4577] further updates the operation of OSPFv2 as the PE-CE
operation of OSPFv2 as the PE-CE routing protocol by detailing routing protocol by detailing additional extensions to enable intra-
additional extensions to enable intra-domain routing connectivity domain routing connectivity between OSPFv2-based customer sites.
between OSPFv2-based customer sites.
While [rfc4364] was defined for IPv4 based networks, [rfc4659] While [rfc4364] was defined for IPv4 based networks, [rfc4659]
extends the BGP/MPLS IP VPN framework to support IPv6 VPNs. This extends support to IPv6 VPNs. It is expected that OSPFv3 will be
includes the capability to connect IPv6 based sites over an IPv4 or used as the IGP for some IPv6 VPNs just as the OSPFv2 was used for
IPv6 SP backbone. It is expected that OSPFv3 will be used as the IGP IPv4 VPNs. The advantages of using OSPFv3 as a PE-CE protocol are
for some IPv6 VPNs just as the OSPFv2 was used for IPv4 VPNs. The the same as for the IPv4 VPN deployment.
advantages of using OSPFv3 as a PE-CE protocol are the same as for
the IPv4 VPN deployment.
This document defines the mechanisms required to enable the operation This document defines the mechanisms required to enable the operation
of OSPFv3 as the PE-CE Routing Protocol in BGP MPLS/IP VPNs. In of OSPFv3 as the PE-CE Routing Protocol. In doing so, it reuses, and
doing so, it reuses, and extends where necessary, the "BGP/MPLS IP extends where necessary, methods defined in [rfc4659], and [rfc4577].
VPN" method for IPv6 VPNs defined in [rfc4659], and OSPFv2 as the This document also includes the specifications for maintaining intra-
PE-CE routing protocol defined in [rfc4577]. This document also domain routing connectivity between OSPFv3-based customer sites
includes the specifications for maintaining intra-domain routing across a SP backbone.
connectivity between OSPFv3-based customer sites across a SP
backbone.
We presuppose familiarity with the contents of [rfc4364], [rfc4659], We presuppose familiarity with the contents of [rfc4364], [rfc4659],
[rfc4577], [rfc4576], [rfc5340] and [rfc2328]. [rfc4577], [rfc4576], [rfc5340] and [rfc2328].
2. Specification of Requirements 2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 5, line 27 skipping to change at page 5, line 20
3.1. OSPFv3 Specificities 3.1. OSPFv3 Specificities
Section 2.0 of [rfc5340] describes differences between OSPFv3 and Section 2.0 of [rfc5340] describes differences between OSPFv3 and
OSPFv2. Several of these changes will require modifications to the OSPFv2. Several of these changes will require modifications to the
architecture described in [rfc4577]. These differences and their architecture described in [rfc4577]. These differences and their
corresponding impact to [rfc4577] are described below: corresponding impact to [rfc4577] are described below:
New LSA types: New LSA types:
For an IPv6 MPLS/VPN architecture where customers interface to For an IPv6 VPN architecture where customers interface to
providers through OSPFv3, traditional BGP/OSPF interactions providers through OSPFv3, traditional BGP/OSPF interactions
specify that VPN-IPv6 reachability information redistributed into specify that VPN-IPv6 reachability information redistributed into
OSPFv3 will be expressed as AS-External OSPFv3 LSAs. Instead, it OSPFv3 will be expressed as AS-External OSPFv3 LSAs. Instead, it
may be desirable to view these LSAs as inter-area-prefix LSAs. may be desirable to view these LSAs as inter-area-prefix LSAs.
The OSPF Route Type Extended Communities attribute defined in The OSPF Route Type Extended Communities attribute defined in
[rfc4577] is extended to include OSPFv3 route types. These new [rfc4577] is extended to include OSPFv3 route types. These new
encodings are defined in Section 4.4. encodings are defined in Section 4.4.
Multiple instances over a link: Multiple instances over a link:
skipping to change at page 6, line 51 skipping to change at page 6, line 44
unless configured to do so. unless configured to do so.
4.1.2. OSPFv3 Domain Identifier 4.1.2. OSPFv3 Domain Identifier
The OSPFv3 Domain ID describes the administrative domain of the OSPF The OSPFv3 Domain ID describes the administrative domain of the OSPF
instance which originated the route. It has an AS wide significance instance which originated the route. It has an AS wide significance
and is one of the parameters used to determine whether a VPN-IPv6 and is one of the parameters used to determine whether a VPN-IPv6
route should be translated as an Inter-area-prefix-LSA or External- route should be translated as an Inter-area-prefix-LSA or External-
LSA. Each OSPFv3 instance MUST have a primary Domain ID which is LSA. Each OSPFv3 instance MUST have a primary Domain ID which is
transported along with the VPN-IPv6 route in a BGP attribute over the transported along with the VPN-IPv6 route in a BGP attribute over the
MPLS VPN backbone. Each OSPFv3 instance may have a set of secondary VPN backbone. Each OSPFv3 instance may have a set of secondary
Domain IDs which applies to other OSPFv3 instances within its Domain IDs which applies to other OSPFv3 instances within its
administrative domain. administrative domain.
The primary Domain ID may either be configured or may be set to a The primary Domain ID may either be configured or may be set to a
value of NULL. The secondary Domain IDs are only allowed if a non- value of NULL. The secondary Domain IDs are only allowed if a non-
null primary Domain ID is configured. The Domain ID MUST be null primary Domain ID is configured. The Domain ID MUST be
configured on a per-OSPFv3 instance basis. configured on a per-OSPFv3 instance basis.
The Domain ID is used to determine whether an incoming VPN-IPv6 route The Domain ID is used to determine whether an incoming VPN-IPv6 route
belongs to the same domain as the receiving OSPFv3 instance. An belongs to the same domain as the receiving OSPFv3 instance. An
skipping to change at page 7, line 33 skipping to change at page 7, line 27
4.3. VRFs and Routes 4.3. VRFs and Routes
From the perspective of the CE, the PE appears as any other OSPFv3 From the perspective of the CE, the PE appears as any other OSPFv3
neighbor. There is no requirement for the CE to support any neighbor. There is no requirement for the CE to support any
mechanisms of IPv6 BGP/MPLS VPNs or for the CE to have any awareness mechanisms of IPv6 BGP/MPLS VPNs or for the CE to have any awareness
of the VPNs, thereby enabling any OSPFv3 implementation to be used on of the VPNs, thereby enabling any OSPFv3 implementation to be used on
a CE. a CE.
Because the export and import policies might cause different routes Because the export and import policies might cause different routes
to be installed in different VRFs of the same OSPFv3 domain, the MPLS to be installed in different VRFs of the same OSPFv3 domain, the VPN
VPN backbone cannot be considered as a single router from the backbone cannot be considered as a single router from the perspective
perspective of the domain's CEs. Rather, each CE should view its of the domain's CEs. Rather, each CE should view its connected PE as
connected PE as a separate router. a separate router.
The PE uses OSPFv3 to distribute routes to CEs, and MP-BGP [rfc2858] The PE uses OSPFv3 to distribute routes to CEs, and MP-BGP [rfc2858]
to distribute VPN-IPv6 routes to other (remote) PE routers as defined to distribute VPN-IPv6 routes to other (remote) PE routers as defined
in [rfc4659]. An IPv6 prefix installed in the VRF by OSPFv3 is in [rfc4659]. An IPv6 prefix installed in the VRF by OSPFv3 is
changed to a VPN-IPv6 prefix by the addition of an 8-octet Route changed to a VPN-IPv6 prefix by the addition of an 8-octet Route
Distinguisher (RD) as discussed in Section 2 of [rfc4659]. This VPN- Distinguisher (RD) as discussed in Section 2 of [rfc4659]. This VPN-
IPv6 route can then be redistributed into MP-BGP according to an IPv6 route can then be redistributed into MP-BGP according to an
export policy that adds a Route Target Extended Communities (RT) export policy that adds a Route Target Extended Communities (RT)
attribute to the NLRI [rfc4360]. attribute to the Network Layer Reachability Information (NLRI)
[rfc4360].
Domain IDs are used to distinguish between OSPFv3 instances. When an Domain IDs are used to distinguish between OSPFv3 instances. When an
OSPFv3 distributed route is redistributed into MP-BGP, the Domain ID, OSPFv3 distributed route is redistributed into MP-BGP, the Domain ID,
OSPFv3 Router ID, Area, OSPFv3 Route Type, and Options fields OSPFv3 Router ID, Area, OSPFv3 Route Type, and Options fields
(External Route Type) are also carried in Extended Community (External Route Type) are also carried in Extended Community
Attributes of the MP-BGP route. Attributes of the MP-BGP route.
A PE receiving a VPN-IPv6 NLRI from MP-BGP uses an import policy to A PE receiving a VPN-IPv6 NLRI from MP-BGP uses an import policy to
determine, based on the RT, whether the route is eligible to be determine, based on the RT, whether the route is eligible to be
installed in one of its local VRFs. The BGP decision process selects installed in one of its local VRFs. The BGP decision process selects
skipping to change at page 10, line 40 skipping to change at page 10, line 37
Border Router (ABR) regardless of whether or not the route is being Border Router (ABR) regardless of whether or not the route is being
advertised into the same area number from which the remote PE learned advertised into the same area number from which the remote PE learned
it (that is, whether the VPN-IPv6 route carries the same or different it (that is, whether the VPN-IPv6 route carries the same or different
area numbers). area numbers).
4.3.2.2. OSPF Intra-Area Route 4.3.2.2. OSPF Intra-Area Route
A route is advertised as an intra-area route using an Intra-Area- A route is advertised as an intra-area route using an Intra-Area-
Prefix (type 0x2009) LSA only when sham links are used, as described Prefix (type 0x2009) LSA only when sham links are used, as described
in Section 5. Otherwise routes are advertised as either inter-area in Section 5. Otherwise routes are advertised as either inter-area
(Section 4.3.2.1) or external/NSSA (Sections 4.3.2.3) routes. (Section 4.3.2.1) or external/Not-So-Stubby Area (NSSA) (Sections
4.3.2.3) routes.
4.3.2.3. OSPF External Routes And NSSA Routes 4.3.2.3. OSPF External Routes And NSSA Routes
A PE considers an IPv6 route to be external under the following A PE considers an IPv6 route to be external under the following
circumstances: circumstances:
The OSPFv3 domain from which the route was learned is different The OSPFv3 domain from which the route was learned is different
(as determined by the Domain ID) from the domain of the OSPFv3 (as determined by the Domain ID) from the domain of the OSPFv3
instance into which it is redistributed; OR instance into which it is redistributed; OR
The OSPFv3 domain from which the route was learned is the same as The OSPFv3 domain from which the route was learned is the same as
the domain of the OSPFv3 instance into which it is redistributed the domain of the OSPFv3 instance into which it is redistributed
AND it was advertised to the remote PE in an AS-External (type AND it was advertised to the remote PE in an AS-External (type
0x4005) or a Type-7 (type 0x2007, NSSA) LSA; OR 0x4005) or a Type-7 (type 0x2007, NSSA) LSA; OR
The route was not learned from an OSPFv3 instance The route was not learned from an OSPFv3 instance
To determine if the learned route is from a different domain, the To determine if the learned route is from a different domain, the
Domain ID associated with the VPN-IPv6 route (in the OSPF Domain ID Domain ID associated with the VPN-IPv6 route (in the OSPF Domain ID
Extended Communities attribute or attributes) is compared with the Extended Communities attribute or attributes) is compared with the
skipping to change at page 14, line 32 skipping to change at page 14, line 24
a Type-1 external metric; if the bit is set, the route carries a a Type-1 external metric; if the bit is set, the route carries a
Type-2 external metric. Type-2 external metric.
4.5. Loop Prevention Techniques 4.5. Loop Prevention Techniques
In some topologies, it is possible for routing loops to occur due to In some topologies, it is possible for routing loops to occur due to
the nature and manner of route reachability propagation. One such the nature and manner of route reachability propagation. One such
example is the case of a dual homed CE router connected to two PEs; example is the case of a dual homed CE router connected to two PEs;
those PE routers would receive reachability information both through those PE routers would receive reachability information both through
their CE and their peer PE. As there is transparent transport of their CE and their peer PE. As there is transparent transport of
OSPFv3 routes over the BGP/MPLS backbone, it is not possible for the OSPFv3 routes over the VPN backbone, it is not possible for the PE
PE routers to determine whether they are within a loop. routers to determine whether they are within a loop.
The loop scenarios in OSPFv3 topologies are identical to those in the The loop scenarios in OSPFv3 topologies are identical to those in the
OSPFv2 topologies described in Section 4.2.5.1 and Section 4.2.5.2 of OSPFv2 topologies described in Section 4.2.5.1 and Section 4.2.5.2 of
[rfc4577]. Of the two loop preventions mechanisms described in the [rfc4577]. Of the two loop preventions mechanisms described in the
sections aforementioned, only the DN bit option will be supported in sections aforementioned, only the DN bit option will be supported in
the OSPFv3 implementation. the OSPFv3 implementation.
4.5.1. OSPFv3 Down Bit 4.5.1. OSPFv3 Down Bit
Section 1 and Section 3 of [rfc4576] describe the usage of the DN-bit Section 1 and Section 3 of [rfc4576] describe the usage of the DN-bit
skipping to change at page 15, line 23 skipping to change at page 15, line 14
information. information.
5. OSPFv3 Sham Links 5. OSPFv3 Sham Links
This section modifies the specification of OSPFv2 sham links (defined This section modifies the specification of OSPFv2 sham links (defined
in Section 4.2.7 of [rfc4577]) to support OSPFv3. Support for OSPFv3 in Section 4.2.7 of [rfc4577]) to support OSPFv3. Support for OSPFv3
sham links is an OPTIONAL feature of this specification. sham links is an OPTIONAL feature of this specification.
A sham link enables a VPN backbone to act as an intra-area link. It A sham link enables a VPN backbone to act as an intra-area link. It
is needed when two sites are connected by an intra-area "backdoor" is needed when two sites are connected by an intra-area "backdoor"
link and the inter-area MPLS VPN backbone route would be less link and the inter-area VPN backbone route would be less preferable
preferable due to OSPF route preference rules. The figure below due to OSPF route preference rules. The figure below shows the
shows the instantiation of a sham link between two VPN sites. instantiation of a sham link between two VPN sites.
(VPN backbone) (VPN backbone)
(site-1) <-------- sham link --------> (site-2) (site-1) <-------- sham link --------> (site-2)
CE1 -------- PE1 -------- P ---------- PE2 -------- CE2 CE1 -------- PE1 -------- P ---------- PE2 -------- CE2
| | | |
|___________________________________________________| |___________________________________________________|
<------------ backdoor link --------------> <------------ backdoor link -------------->
(OSPF intra-area link) (OSPF intra-area link)
Sham Link Sham Link
skipping to change at page 17, line 40 skipping to change at page 17, line 31
this document. this document.
When forwarding a packet, if the preferred route for that packet has When forwarding a packet, if the preferred route for that packet has
the sham link as its next hop interface, then the packet MUST be the sham link as its next hop interface, then the packet MUST be
forwarded according to the corresponding BGP route (as defined in forwarded according to the corresponding BGP route (as defined in
[rfc4364] and [rfc4659]). [rfc4364] and [rfc4659]).
6. Multiple Address Family Support 6. Multiple Address Family Support
The support of multiple address families (AF) in OSPFv3 is described The support of multiple address families (AF) in OSPFv3 is described
in [RFC5838]. [RFC5838] differentiates between AF using reserved in [rfc5838]. [rfc5838] differentiates between AF using reserved
ranges of Instance IDs for each AF. ranges of Instance IDs for each AF.
The architecture described in this document is fully compatible with The architecture described in this document is fully compatible with
[RFC5838]. The OSPFv3 PE-CE protocol can support multiple address [rfc5838]. The OSPFv3 PE-CE protocol can support multiple address
families across a MPLS VPN backbone. All AFs redistributed from families across a VPN backbone. All AFs redistributed from OSPFv3
OSPFv3 into BGP on a PE MUST contain the BGP Extended Communities into BGP on a PE MUST contain the BGP Extended Communities Attributes
Attributes as described in Section 4.4. as described in Section 4.4.
7. Security Considerations 7. Security Considerations
The extensions described in this document are specific to the use of The extensions described in this document are specific to the use of
OSPFv3 as the PE-CE protocol and do not introduce any concerns OSPFv3 as the PE-CE protocol and do not introduce any new security
regarding the use of BGP as transport of IPv6 reachability over the concerns other than those already defined in Section 6 of [rfc4577].
MPLS Backbone. The Security considerations for the transport of IPv6
reachability information using BGP are discussed in Section 11 of
[rfc4659] and are not altered.
The new extensions defined in this document do not introduce any new
security concerns other than those already defined in Section 6 of
[rfc4577].
8. IANA Considerations 8. IANA Considerations
A early draft of this document resulted in the allocation of OSPFv3 A early draft of this document resulted in the allocation of OSPFv3
Route Attributes (0x0004) entry in the BGP IPv6 Address Specific Route Attributes (0x0004) entry in the BGP IPv6 Address Specific
Extended Community. This allocation is no longer required. IANA is Extended Community. This allocation is no longer required. IANA is
requested to mark the OSPFv3 Route Attributes (0x0004) entry in the requested to mark the OSPFv3 Route Attributes (0x0004) entry in the
BGP IPv6 Address Specific Extended Community registry as deprecated. BGP IPv6 Address Specific Extended Community registry as deprecated.
The BGP Extended Communities Attributes in this document are already The BGP Extended Communities Attributes in this document are already
skipping to change at page 18, line 34 skipping to change at page 18, line 18
9. Contributors 9. Contributors
Joe Lapolito Joe Lapolito
10. Acknowledgments 10. Acknowledgments
The authors would like to thank Kelvin Upson, Seiko Okano, Matthew The authors would like to thank Kelvin Upson, Seiko Okano, Matthew
Everett, Dr. Vineet Mehta, Paul Wells and Marek Karasek for their Everett, Dr. Vineet Mehta, Paul Wells and Marek Karasek for their
support of this work. Thanks to Peter Psenak, Abhay Roy, Acee support of this work. Thanks to Peter Psenak, Abhay Roy, Acee
Lindem, Nick Weeds, Robert Hanzl and Daniel Cohn for their last call Lindem, Nick Weeds, Robert Hanzl and Daniel Cohn for their last call
comments. comments. Special thanks to Stewart Bryant, Stephen Farrel and Fred
Baker for their thorough review.
This document was produced using Marshall Rose's xml2rfc tool. This document was produced using Marshall Rose's xml2rfc tool.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFC's to Indicate [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5838] Mirtorabi, S., Roy, A., Barnes, M., Aggarwal, R., and A.
Lindem, "Support of address families in OSPFv3",
April 2010.
[rfc2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [rfc2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[rfc2858] Bates, T., Rehkter, Y., Chandra, R., and D. Katz, [rfc2858] Bates, T., Rehkter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[rfc4360] Sangli, S., Tappan, D., and Y. Rehkter, "BGP Extended [rfc4360] Sangli, S., Tappan, D., and Y. Rehkter, "BGP Extended
Communities Attribute", RFC 4360, February 2006. Communities Attribute", RFC 4360, February 2006.
[rfc4364] Rosen, E. and Y. Rehkter, "BGP/MPLS IP Virtual Private [rfc4364] Rosen, E. and Y. Rehkter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
skipping to change at page 19, line 28 skipping to change at page 19, line 8
Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Provider/Customer Edge Protocol for BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC 4577, June 2006. Private Networks (VPNs)", RFC 4577, June 2006.
[rfc4659] De Clercq, J., Ooms, D., Carugi, M., and F. Lefaucheur, [rfc4659] De Clercq, J., Ooms, D., Carugi, M., and F. Lefaucheur,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for "BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", RFC 4659, September 2006. IPv6 VPN", RFC 4659, September 2006.
[rfc5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [rfc5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, July 2008.
[rfc5838] Mirtorabi, S., Roy, A., Barnes, M., Aggarwal, R., and A.
Lindem, "Support of address families in OSPFv3",
April 2010.
11.2. Informative References 11.2. Informative References
[rfc2547] Rosen, E. and Y. Rehkter, "BGP/MPLS VPNs", RFC 2547, [rfc2547] Rosen, E. and Y. Rehkter, "BGP/MPLS VPNs", RFC 2547,
March 1999. March 1999.
Authors' Addresses Authors' Addresses
Padma Pillay-Esnault Padma Pillay-Esnault
Cisco Systems Cisco Systems
510 McCarty Blvd 510 McCarty Blvd
 End of changes. 28 change blocks. 
69 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/