draft-ietf-l3vpn-ospfv3-pece-11.txt   rfc6565.txt 
Network Working Group P. Pillay-Esnault Internet Engineering Task Force (IETF) P. Pillay-Esnault
Internet-Draft Cisco Systems Request for Comments: 6565 Cisco Systems
Intended status: Standards Track P. Moyer Category: Standards Track P. Moyer
Expires: July 13, 2012 Pollere, Inc ISSN: 2070-1721 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
January 10, 2012 June 2012
OSPFv3 as a PE-CE routing protocol
draft-ietf-l3vpn-ospfv3-pece-11
This document may contain material from IETF Documents or IETF OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
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. Support currently exists for both IPv4 and IPv6 provider's backbone. Support currently exists for both IPv4 and IPv6
VPNs, however only Open Shortest Path First protocol version 2 VPNs; however, only Open Shortest Path First version 2 (OSPFv2) as
(OSPFv2) as PE-CE protocol is specified. This document extends those PE-CE protocol is specified. This document extends those
specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing
protocol. The OSPFv3 PE-CE functionality is identical to that of protocol. The OSPFv3 PE-CE functionality is identical to that of
OSPFv2 except for the differences described in this document. 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 is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on July 13, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6565.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 3, line 7 skipping to change at page 3, line 7
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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements ....................................................4
3.1. OSPFv3 Specificities . . . . . . . . . . . . . . . . . . . 5 3.1. OSPFv3 Specificities .......................................5
4. BGP/OSPFv3 Interaction Procedures for PE Routers . . . . . . . 5 4. BGP/OSPFv3 Interaction Procedures for PE Routers ................5
4.1. VRFs and OSPFv3 Instances . . . . . . . . . . . . . . . . 5 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 PEs ................................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 . . . . . . . . . . . . 11 4.4. BGP Extended Communities Attribute ........................12
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 ....................................15
4.5.2. Other Possible Loops . . . . . . . . . . . . . . . . . 14 4.5.2. Other Possible Loops ...............................15
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 ........................................18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations ............................................18
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments ................................................18
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 10. References ....................................................18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References .....................................18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.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
Layer-3 Virtual Private Network (VPN) services to subtending customer 3 Virtual Private Network (VPN) services to subtending customer
networks. Using the procedures defined in [rfc4364], provider edge networks. Using the procedures defined in [RFC4364], Provider Edge
(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 specification The OSPFv2 as the Provider/Customer Edge Protocol specification
[rfc4577] further updates the operation of OSPFv2 as the PE-CE [RFC4577] further updates the operation of OSPFv2 as the PE-CE
routing protocol by detailing additional extensions to enable intra- routing protocol by detailing additional extensions to enable intra-
domain routing connectivity between OSPFv2-based customer sites. domain routing connectivity between OSPFv2-based customer sites.
While [rfc4364] was defined for IPv4 based networks, [rfc4659] While [RFC4364] was defined for IPv4-based networks, [RFC4659]
extends support to IPv6 VPNs. It is expected that OSPFv3 will be extends support to IPv6 VPNs. It is expected that OSPFv3 will be
used as the IGP for some IPv6 VPNs just as the OSPFv2 was used for used as the IGP for some IPv6 VPNs just as the OSPFv2 was used for
IPv4 VPNs. The advantages of using OSPFv3 as a PE-CE protocol are IPv4 VPNs. The advantages of using OSPFv3 as a PE-CE protocol are
the same as for the IPv4 VPN deployment. 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 doing so, it reuses, and of OSPFv3 as the PE-CE routing protocol. In doing so, it reuses, and
extends where necessary, methods defined in [rfc4659], and [rfc4577]. extends where necessary, methods defined in [RFC4659] and [RFC4577].
This document also includes the specifications for maintaining intra- This document also includes the specifications for maintaining intra-
domain routing connectivity between OSPFv3-based customer sites domain routing connectivity between OSPFv3-based customer sites
across a SP backbone. across an 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].
3. Requirements 3. Requirements
The benefits and considerations associated with deploying OSPFv3 as The benefits and considerations associated with deploying OSPFv3 as
the PE-CE routing protocol are similar to those described in the PE-CE routing protocol are similar to those described in
[rfc4577]. The requirements described in Section 3 of [rfc4577] [RFC4577]. The requirements described in Section 3 of [RFC4577]
remain semantically identical for the deployment of OSPFv3. remain semantically identical for the deployment of OSPFv3.
[rfc5340] describes the modifications required to OSPF to support [RFC5340] describes the modifications required to OSPF to support
IPv6. In that specification, many of the fundamental mechanisms IPv6. In that specification, many of the fundamental mechanisms
associated with OSPFv2 remain unchanged for OSPFv3. Consequently, associated with OSPFv2 remain unchanged for OSPFv3. Consequently,
the operation of OSPFv3 as the PE-CE routing protocol is very similar the operation of OSPFv3 as the PE-CE routing protocol is very similar
to OSPFv2 as the PE-CE protocol. to OSPFv2 as the PE-CE protocol.
3.1. OSPFv3 Specificities 3.1. OSPFv3 Specificities
Section 2.0 of [rfc5340] describes differences between OSPFv3 and Section 2 of [RFC5340] describes the 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 VPN architecture where customers interface to For an IPv6 VPN architecture where customers interface with
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:
OSPFv3 operates on a per-link basis as opposed to OSPFv2, which OSPFv3 operates on a per-link basis as opposed to OSPFv2, which
operates on a per-IP-subnet basis. The support of multiple OSPFv3 operates on a per-IP-subnet basis. The support of multiple OSPFv3
protocol instances on a link changes the architecture described in protocol instances on a link changes the architecture described in
[rfc4577]. [rfc4577] specifies that each interface belongs to no [RFC4577]. [RFC4577] specifies that each interface belongs to no
more than one OSPF instance. For OSPFv3, multiple instances can more than one OSPF instance. For OSPFv3, multiple instances can
be established over a single interface, and associated with the be established over a single interface and associated with the
same VRF. same VRF.
In addition to establishing multiple OSPFv3 instances over a In addition to establishing multiple OSPFv3 instances over a
single PE-CE link, multiple OSPFv3 instances can also be single PE-CE link, multiple OSPFv3 instances can also be
established across a sham link. This enables multiple OSPFv3 established across a sham link. This enables multiple OSPFv3
instances associated with a VRF to independently establish intra- instances associated with a VRF to independently establish intra-
area connectivity to other OSPFv3 instances attached to a remote area connectivity to other OSPFv3 instances attached to a remote
PE VRF. Support for multiple OSPFv3 instances across the sham PE VRF. Support for multiple OSPFv3 instances across the sham
link is described in Section 5. link is described in Section 5.
4. BGP/OSPFv3 Interaction Procedures for PE Routers 4. BGP/OSPFv3 Interaction Procedures for PE Routers
4.1. VRFs and OSPFv3 Instances 4.1. VRFs and OSPFv3 Instances
The relationship between VRFs, interfaces, and OSPFv3 instances on a The relationship between VRFs, interfaces, and OSPFv3 instances on a
PE router is described in the following section. PE router is described in the following section.
As defined in [rfc4364], a PE router can be configured with one or As defined in [RFC4364], a PE router can be configured with one or
more VRFs. Each VRF configured on the PE corresponds to a customer more VRFs. Each VRF configured on the PE corresponds to a customer
VPN, and retains the destinations that are reachable within that VPN. VPN and retains the destinations that are reachable within that VPN.
Each VRF may be associated with one or more interfaces, which allows Each VRF may be associated with one or more interfaces, which allows
multiple sites to participate in the same VPN. If OSPFv3 is multiple sites to participate in the same VPN. If OSPFv3 is
instantiated on an interface associated with a VRF, the VRF will be instantiated on an interface associated with a VRF, the VRF will be
populated with OSPFv3 routing information. populated with OSPFv3 routing information.
As OSPFv3 supports multiple instances on a single interface, it is As OSPFv3 supports multiple instances on a single interface, it is
therefore possible that multiple customer sites can connect to the therefore possible that multiple customer sites can connect to the
same interface of a PE router (e.g., through a layer 2 switch) using same interface of a PE router (e.g., through a Layer 2 switch) using
distinct OSPFv3 instances. A PE interface can be associated with distinct OSPFv3 instances. A PE interface can be associated with
only one VRF, and all OSPFv3 instances running on the same interface only one VRF, and all OSPFv3 instances running on the same interface
MUST be associated with the same VRF. Configurations where a PE MUST be associated with the same VRF. Configurations where a PE
interface is associated with multiple VRFs are out of scope for this interface is associated with multiple VRFs are out of scope for this
document. document.
4.1.1. Independent OSPFv3 Instances in PEs 4.1.1. Independent OSPFv3 Instances in PEs
Similar to [rfc4577], the PE must associate at least one OSPFv3 Similar to [RFC4577], the PE must associate at least one OSPFv3
instance for each OSPFv3 domain to which it attaches, and each instance for each OSPFv3 domain to which it attaches, and each
instance of OSPFv3 MUST be associated with a single VRF. instance of OSPFv3 MUST be associated with a single VRF.
The support of multiple PE-CE OSPFv3 instances per PE interface does The support of multiple PE-CE OSPFv3 instances per PE interface does
not change the paradigm that an OSPF instance can be associated with not change the paradigm that an OSPF instance can be associated with
only a single VRF. Furthermore, for each instance instantiated on only a single VRF. Furthermore, for each instance instantiated on
the interface, the PE establishes adjacencies with corresponding CEs the interface, the PE establishes adjacencies with corresponding CEs
associated with the instance. Note that although multiple instances associated with the instance. Note that although multiple instances
may populate a common VRF, they do not leak routes to one another, may populate a common VRF, they do not leak routes to one another,
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 that 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 that 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
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 that 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 be set to a value
value of NULL. The secondary Domain IDs are only allowed if a non- of NULL. The secondary Domain IDs are only allowed if a non-NULL
null primary Domain ID is configured. The Domain ID MUST be primary Domain ID is configured. The Domain ID MUST be configured on
configured on a per-OSPFv3 instance basis. 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
incoming VPN-IPv6 route is said to belong to the same domain if a incoming VPN-IPv6 route is said to belong to the same domain if a
non-NULL incoming Domain ID matches either the local primary or one non-NULL incoming Domain ID matches either the local primary or one
of the secondary Domain IDs. If the local Domain ID and incoming of the secondary Domain IDs. If the local Domain ID and incoming
Domain ID are NULL, it is considered a match. Domain ID are NULL, it is considered a match.
4.2. OSPFv3 Areas 4.2. OSPFv3 Areas
Sections 4.1.4 and 4.2.3 of [rfc4577] describe the characteristics of Sections 4.1.4 and 4.2.3 of [RFC4577] describe the characteristics of
a PE router within an OSPFv2 domain. The mechanisms and expected a PE router within an OSPFv2 domain. The mechanisms and expected
behavior described in [rfc4577] are applicable to an OSPFv3 domain. behavior described in [RFC4577] are applicable to an OSPFv3 domain.
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 VPN to be installed in different VRFs of the same OSPFv3 domain, the VPN
backbone cannot be considered as a single router from the perspective backbone cannot be considered as a single router from the perspective
of the domain's CEs. Rather, each CE should view its connected PE as of the domain's CEs. Rather, each CE should view its 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 [RFC4760]
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 (RT) Extended Communities
attribute to the Network Layer Reachability Information (NLRI) attribute to the Network Layer Reachability Information (NLRI)
[rfc4360]. [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 8, line 21 skipping to change at page 8, line 23
instances, the route might be advertised using different LSA types in instances, the route might be advertised using different LSA types in
different instances. different instances.
If an IPv6 route learned from MP-BGP is to be redistributed into a If an IPv6 route learned from MP-BGP is to be redistributed into a
particular OSPFv3 instance, the OSPF Domain Identifier Extended particular OSPFv3 instance, the OSPF Domain Identifier Extended
Communities attribute of the VPN-IPv6 route is used to determine Communities attribute of the VPN-IPv6 route is used to determine
whether the OSPFv3 instance from which the route was learned is the whether the OSPFv3 instance from which the route was learned is the
same as the OSPFv3 instance into which the route is to be same as the OSPFv3 instance into which the route is to be
redistributed. redistributed.
4.3.1. OSPFv3 Routes on PE 4.3.1. OSPFv3 Routes on PEs
VRFs may be populated by both OSPFv3 routes from a CE or VPN-IPv6 VRFs may be populated by both OSPFv3 routes from a CE or VPN-IPv6
routes from other PEs via MP-BGP. OSPFv3 routes are installed in a routes from other PEs via MP-BGP. OSPFv3 routes are installed in a
VRF using the OSPFv3 decision process. They may be redistributed VRF using the OSPFv3 decision process. They may be redistributed
into BGP and disseminated to other PEs participating in the VPN. At into BGP and disseminated to other PEs participating in the VPN. At
these remote PEs, the VPN-IPv6 routes may be imported into a VRF and these remote PEs, the VPN-IPv6 routes may be imported into a VRF and
redistributed into the OSPFv3 instance(s) associated with that VRF. redistributed into the OSPFv3 instance(s) associated with that VRF.
As specified in [rfc4659], routes imported and exported into a VRF As specified in [RFC4659], routes imported and exported into a VRF
are controlled by the Route Target (RT) Extended Communities are controlled by the Route Target (RT) Extended Communities
attribute. OSPFv3 routes that are redistributed into BGP are given a attribute. OSPFv3 routes that are redistributed into BGP are given
RT that corresponds to the VRF. This RT is examined at remote PEs. an RT that corresponds to the VRF. This RT is examined at remote
In order to import a route, a VRF must have an import RT that is PEs. In order to import a route, a VRF must have an import RT that
identical to the route's RT. For routes which are eligible to be is identical to the route's RT. For routes that are eligible to be
imported into the VRF, the standard BGP decision process is used to imported into the VRF, the standard BGP decision process is used to
choose the "best" route(s). choose the "best" route(s).
When a route is advertised from a CE to a PE via OSPFv3 and that When a route is advertised from a CE to a PE via OSPFv3 and that
route is installed in the VRF associated with the CE, the route is route is installed in the VRF associated with the CE, the route is
advertised to other locally attached CEs under normal OSPFv3 advertised to other locally attached CEs under normal OSPFv3
procedures. procedures.
The route is also redistributed into MP-BGP to be advertised to The route is also redistributed into MP-BGP to be advertised to
remote PEs. The information necessary for accurate redistribution remote PEs. The information necessary for accurate redistribution
back into OSPFv3 by the remote PEs is carried in the OSPF Route Type, back into OSPFv3 by the remote PEs is carried in the OSPF Route Type,
OSPF Domain ID, and OSPF Router ID Extended Communities attributes OSPF Domain ID, and OSPF Router ID Extended Communities attributes
(Section 4.4). The relevant local OSPFv3 information encoded into (Section 4.4). The relevant local OSPFv3 information encoded into
these attributes are: these attributes are as follows:
The Area ID of the PE-CE link. The Area ID of the PE-CE link.
The Route Type, as determined by the LSA type from which the route The Route Type, as determined by the LSA type from which the route
was learned. was learned.
The Options fields (External metric-type) The Options fields (External metric-type).
The Domain ID of the OSPFv3 process. If no Domain ID is The Domain ID of the OSPFv3 process. If no Domain ID is
configured, the NULL identifier is used. configured, the NULL identifier is used.
The PE's Router ID associated with the OSPFv3 instance. The PE's Router ID associated with the OSPFv3 instance.
A Multi-Exit-Discriminator (MED) attribute SHOULD also be set to the A Multi-Exit-Discriminator (MED) attribute SHOULD also be set to the
value of the OSPFv3 metric associated with the route plus 1, when the value of the OSPFv3 metric associated with the route plus 1, when the
OSPFv3 route is redistributed into the MP-BGP. OSPFv3 route is redistributed into the MP-BGP.
skipping to change at page 9, line 33 skipping to change at page 9, line 33
When a PE receives a valid VPN-IPv6 route from MP-BGP and has When a PE receives a valid VPN-IPv6 route from MP-BGP and has
identified an association with a local VRF, it must determine: identified an association with a local VRF, it must determine:
Whether a route to the corresponding IPv6 prefix is to be Whether a route to the corresponding IPv6 prefix is to be
installed in the VRF; installed in the VRF;
Whether the installed IPv6 route is to be redistributed to one or Whether the installed IPv6 route is to be redistributed to one or
more local OSPFv3 instances; and more local OSPFv3 instances; and
What OSPFv3 LSA type is to be used when advertising the route into What OSPFv3 LSA type is to be used when advertising the route into
each OSPFv3 instance each OSPFv3 instance.
An IPv6 route derived from a received VPN-IPv6 route is not installed An IPv6 route derived from a received VPN-IPv6 route is not installed
in the associated local VRF if: in the associated local VRF if:
The BGP decision process identifies a better route to the The BGP decision process identifies a better route to the
destination NLRI destination NLRI; or
A configured import policy prohibits the installation of the route A configured import policy prohibits the installation of the
route.
The PE advertises the IPv6 route learned from MP-BGP to attached CEs The PE advertises the IPv6 route learned from MP-BGP to attached CEs
via OSPFv3 if: via OSPFv3 if:
No configured filtering prohibits redistributing the route to No configured filtering prohibits redistributing the route to
OSPFv3 OSPFv3;
No configured policy blocks the route in favor of a less-specific No configured policy blocks the route in favor of a less-specific
summary route summary route; and
Redistribution of a BGP learned IPv6 route into OSPF is based on Redistribution of a BGP learned IPv6 route into OSPF is based on
local policy. local policy.
The subsequent sections discuss the advertisement of routes learned The subsequent sections discuss the advertisement of routes learned
from MP-BGP, and the rules for determining what LSA types and what from MP-BGP and the rules for determining to which LSA types and to
CEs to advertise the routes to. which CEs to advertise the routes.
When the PE sends an LSA to a CE, it sets the DN bit in the LSA to When the PE sends an LSA to a CE, it sets the DN-bit in the LSA to
prevent looping. The DN bit is discussed in Section 4.5.1. prevent looping. The DN-bit is discussed in Section 4.5.1.
4.3.2.1. OSPF Inter-Area Routes 4.3.2.1. OSPF Inter-Area Routes
A PE advertises an IPv6 route using an Inter-Area-Prefix (type A PE advertises an IPv6 route using an Inter-Area-Prefix (type
0x2003) LSA under the following circumstances: 0x2003) LSA under the following circumstances:
The OSPFv3 domain from which the IPv6 route was learned is the The OSPFv3 domain from which the IPv6 route was learned is the
same (as determined by the Domain ID) as the domain of the OSPFv3 same (as determined by the Domain ID) as the domain of the OSPFv3
instance into which it is to be redistributed; AND instance into which it is to be redistributed; and
The IPv6 route was advertised to a remote PE in an Intra-Area- The IPv6 route was advertised to a remote PE in an Intra-Area-
Prefix (type 0x2009) OR an Inter-Area-Prefix (type 0x2003) LSA. Prefix (type 0x2009) OR an Inter-Area-Prefix (type 0x2003) LSA.
Note that under these rules the PE represents itself as an Area Note that under these rules, the PE represents itself as an Area
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/Not-So-Stubby Area (NSSA) (Sections (Section 4.3.2.1) or external / Not-So-Stubby Area (NSSA) (Section
4.3.2.3) routes. 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-LSA (type
0x4005) or a Type-7 (type 0x2007, NSSA) LSA; OR 0x4005) or an NSSA-LSA (type 0x2007); 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
local OSPFv3 Domain ID, if configured. Compared Domain IDs are local OSPFv3 Domain ID, if configured. Compared Domain IDs are
considered identical if: considered identical if:
1. All eight bytes are identical; or 1. All 8 bytes are identical; or
2. Both Domain IDs are NULL (all zeroes). 2. Both Domain IDs are NULL (all zeroes).
Note that if the VPN-IPv6 route does not have a Domain ID in its Note that if the VPN-IPv6 route does not have a Domain ID in its
attributes, or if the local OSPFv3 instance does not have a attributes, or if the local OSPFv3 instance does not have a
configured Domain ID, in either case the route is considered to have configured Domain ID (i.e., in either case), the route is considered
a NULL Domain ID. to have a NULL Domain ID.
An IPv6 route that is determined to be external might or might not be An IPv6 route that is determined to be external might or might not be
advertised to a connected CE, depending on the type of area to which advertised to a connected CE, depending on the type of area to which
the PE-CE link belongs and whether there is a configured policy the PE-CE link belongs and whether there is a configured policy
restricting its advertisement. restricting its advertisement.
If there are multiple external routes to the same prefix, the If there are multiple external routes to the same prefix, the
standard OSPFv3 decision process is used to select the "best" route. standard OSPFv3 decision process is used to select the "best" route.
If the external route is to be advertised and the area type of the If the external route is to be advertised and the area type of the
PE-CE link is NSSA, the PE advertises the route in a Type-7 (type PE-CE link is NSSA, the PE advertises the route in an NSSA-LSA (type
0x2007) LSA; otherwise the external route is advertised in an AS- 0x2007); otherwise, the external route is advertised in an
External (type 0x4005) LSA. AS-External-LSA (type 0x4005).
The DN bit of the LSA advertising the external route MUST be set, as The DN-bit of the LSA advertising the external route MUST be set, as
described in Section 4.5.1. described in Section 4.5.1.
If the VPN-IPv6 route indicates a route type-1 metric, the PE should If the VPN-IPv6 route indicates a route Type-1 metric, the PE should
advertise the external route with that metric-type; otherwise the advertise the external route with that metric-type; otherwise, the
metric-type of the external IPv6 route is set to type-2 by default. metric-type of the external IPv6 route is set to Type-2 by default.
Note that by default, a PE should advertise an external route with a Note that, by default, a PE should advertise an external route with a
type-2 metric if the IPv6 route's Domain ID is different than the Type-2 metric if the IPv6 route's Domain ID is different than the
local OSPFv3 instance, unless specified otherwise by local policy. local OSPFv3 instance, unless specified otherwise by local policy.
4.4. BGP Extended Communities Attribute 4.4. BGP Extended Communities Attributes
OSPFv3 routes from one site are translated and delivered OSPFv3 routes from one site are translated and delivered
transparently to the remote site as BGP VPN-IPv6 routes. The transparently to the remote site as BGP VPN-IPv6 routes. The
original OSPFv3 routes carry OSPFv3 specific information which need original OSPFv3 routes carry OSPFv3-specific information that needs
to be communicated to the remote PE to ensure transparency. BGP to be communicated to the remote PE to ensure transparency. BGP
Extended Communities are used to carry the needed information to Extended Communities are used to carry the needed information to
enable the receiving side to reconstruct a database just as in the enable the receiving side to reconstruct a database just as in the
OSPFv2 case. OSPFv2 case.
All OSPFv3 routes added to the VRF routing table on a PE router are All OSPFv3 routes added to the VRF routing table on a PE router are
examined to create a corresponding VPN-IPv6 route in BGP. Each of examined to create a corresponding VPN-IPv6 route in BGP. Each of
the OSPFv3 routes MUST have corresponding the BGP Extended the OSPFv3 routes MUST have the corresponding BGP Extended
Communities Attributes which contain and preserve the OSPFv3 Communities Attributes that contain and preserve the OSPFv3
information of the original OSPFv3 route. The BGP Extended information of the original OSPFv3 route. The BGP Extended
Communities attributes defined in [rfc4577] are reused for Communities attributes defined in [RFC4577] are reused for
convenience. convenience.
OSPF Domain Identifier Extended Communities Attribute OSPF Domain Identifier Extended Communities Attribute
Each OSPFv3 Instance within a VRF MUST have a Domain ID. The Domain Each OSPFv3 Instance within a VRF MUST have a Domain ID. The Domain
ID is configured per OSPFv3 Instance. The OSPFv3 Domain ID is a ID is configured per OSPFv3 Instance. The OSPFv3 Domain ID is a
6-byte number and its default value is 0. This attribute has a two 6-byte number, and its default value is 0. This attribute has a
byte type field, encoded with a value of 0x0005, 0x0105, or 0x0205. 2-byte type field, encoded with a value of 0x0005, 0x0105, or 0x0205.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Value | Domain Identifier | | Type Value | Domain Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Identifier Cont. | | Domain Identifier Cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OSPF Domain Identifier Extended Communities Attribute The OSPF Domain Identifier Extended Communities Attribute
OSPFv3 Domain IDs field : 6 bytes OSPFv3 Domain IDs field : 6 bytes
Each OSPFv3 Instance within a VRF MUST have a Domain ID and its Each OSPFv3 Instance within a VRF MUST have a Domain ID and its
default value (if none is configured) is 0. The Domain ID is default value (if none is configured) is 0. The Domain ID is
configured per OSPFv3 Instance. configured per OSPFv3 Instance.
OSPF Router ID Extended Communities Attribute OSPF Router ID Extended Communities Attribute
The OSPFv3 Router ID is a 32-bit number as in OSPFv2. This attribute The OSPFv3 Router ID is a 32-bit number as in OSPFv2. This attribute
has a two byte type field, encoded with a value of 0x0107. has a 2-byte type field, encoded with a value of 0x0107.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Value | Router ID | | Type Value | Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID Cont. | UNUSED | | Router ID Cont. | UNUSED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OSPF Router ID Extended Communities Attribute The OSPF Router ID Extended Communities Attribute
OSPFv3 Router ID field : 4 bytes OSPFv3 Router ID field : 4 bytes
The OSPFv3 Router ID is a 32 bit number as in OSPFv2. Setting The OSPFv3 Router ID is a 32-bit number as in OSPFv2. Setting
this field is OPTIONAL and its default value is 0. this field is OPTIONAL, and its default value is 0.
OSPF Route Type Extended Communities Attribute OSPF Route Type Extended Communities Attribute
The OSPF Route Type Extended Communities attribute MUST be present. The OSPF Route Type Extended Communities Attribute MUST be present.
It contains a two byte type field, encoded with a value of 0x0306. It contains a 2-byte type field, encoded with a value of 0x0306. The
The remaining six bytes are divided into three fields, an Area remaining 6 bytes are divided into 3 fields, an Area Number, a Route
Number, a Route Type, and an Options field Type, and an Options field.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Value | Area Number | | Type Value | Area Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area Number Cont. | Route Type | Options | | Area Number Cont. | Route Type | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OSPF Route Type Extended Communities Attribute The OSPF Route Type Extended Communities Attribute
Area Number : 4 bytes Area Number : 4 bytes
The area number indicates the 32-bit Area ID to which the route The area number indicates the 32-bit Area ID to which the route
belongs. belongs.
Route Types : 1 byte Route Types : 1 byte
To accommodate OSPFv3 LSA types (as registered by [RFC5340]), the
To accommodate OSPFv3 LSA types, the Route Type field is encoded Route Type field is encoded as follows:
as follows:
Route Type Route Type LSA Type Description Route Type Route Type LSA Type Description
Code Code
----------------------------------------------------------- -----------------------------------------------------------
3 Inter-area 0x2003 Inter-area-prefix-LSA 3 Inter-area-prefix 0x2003 Inter-Area-Prefix-LSA
5 External 0x4005 AS-external-LSA 5 External 0x4005 AS-External-LSA
7 NSSA 0x2007 NSSA-LSA 7 NSSA 0x2007 NSSA-LSA
1 or 2 Intra-area-prefix 0x2009 Intra-area-prefix-LSA 1 or 2 Intra-area-prefix 0x2009 Intra-Area-Prefix-LSA
Route Type Field Encoding Route Type Field Encoding
Options : 1 byte Options : 1 byte
The Options field indicates the options that are associated with The Options field indicates the options that are associated with
the OSPFv3 route. the OSPFv3 route.
8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | | | | | | E | | | | | | | | | E |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
The OSPFv3 Route Options Field The OSPFv3 Route Options Field
The least significant bit (i.e., bit E) in this field designates The least significant bit (i.e., bit E) in this field designates
the external metric type. If the bit is clear, the route carries the external metric-type. If the bit is clear, the route carries
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 VPN backbone, it is not possible for the PE OSPFv3 routes over the VPN backbone, it is not possible for the 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 Sections 4.2.5.1 and 4.2.5.2 of
[rfc4577]. Of the two loop preventions mechanisms described in the [RFC4577]. Of the two loop prevention mechanisms described in the
sections aforementioned, only the DN bit option will be supported in aforementioned sections, 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 [RFC4576] describes the usage of the DN-bit for OSPFv2 and is
for OSPFv2 and are applicable for OSPFv3 for inter-area-prefix LSAs, applicable for OSPFv3 for Inter-area-prefix LSAs, NSSA LSAs, and
NSSA LSAs and External LSAs. Similarly, the DN-bit MUST be set in External LSAs. Similarly, the DN-bit MUST be set in Inter-area-
inter-area-prefix-LSAs, NSSA-LSAs and AS-External-LSAs, when these prefix LSAs, NSSA LSAs, and AS-External LSAs, when these are
are originated from a PE to a CE, to prevent those prefixes from originated from a PE to a CE, to prevent those prefixes from being
being re-advertised into BGP. As in [rfc4577], any LSA with the DN re-advertised into BGP. As in [RFC4577], any LSA with the DN-bit set
bit set must not be used for route calculations on PE routers. must not be used for route calculations on PE routers.
The DN bit MUST be clear in all other LSA types. The OSPFv3 DN-bit The DN-bit MUST be clear in all other LSA types. The OSPFv3 DN-bit
format is described in Appendix 4.1.1 of [rfc5340]. format is described in Appendix A.4.1.1 of [RFC5340].
4.5.2. Other Possible Loops 4.5.2. Other Possible Loops
The mechanism described in Section 4.5.1 of this document is The mechanism described in Section 4.5.1 of this document is
sufficient to prevent looping if the DN bit information attached to a sufficient to prevent looping if the DN-bit information attached to a
prefix is preserved in the OSPF domain. As described in Section prefix is preserved in the OSPF domain. As described in Section
4.2.5.3 of [rfc4576], caution must be exercised if mutual 4.2.5.3 of [RFC4577], caution must be exercised if mutual
redistribution is performed on a PE causing loss of loop prevention redistribution that is performed on a PE causes loss of loop
information. prevention 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 VPN backbone route would be less preferable link and the inter-area VPN backbone route would be less preferable
due to OSPF route preference rules. The figure below shows the due to OSPF route preference rules. The figure below 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)
skipping to change at page 15, line 34 skipping to change at page 16, line 6
(OSPF intra-area link) (OSPF intra-area link)
Sham Link Sham Link
Much of the operation of sham links remains semantically identical to Much of the operation of sham links remains semantically identical to
what was previously specified. There are, however, several what was previously specified. There are, however, several
differences that need to be defined to ensure the proper operation of differences that need to be defined to ensure the proper operation of
OSPFv3 sham links. OSPFv3 sham links.
One of the primary differences between sham links for OSPFv3 and sham One of the primary differences between sham links for OSPFv3 and sham
links as specified in [rfc4577] are for configurations where multiple links as specified in [RFC4577] is for configurations where multiple
OSPFv3 instances populate a VRF. It may be desirable to provide OSPFv3 instances populate a VRF. It may be desirable to provide
separate intra-area links between these instances over the same sham separate intra-area links between these instances over the same sham
link. To achieve this, multiple OSPFv3 instances may be established link. To achieve this, multiple OSPFv3 instances may be established
across the PE-PE sham link to provide intra-area connectivity between across the PE-PE sham link to provide intra-area connectivity between
PE-CE OSPFv3 instances. PE-CE OSPFv3 instances.
Note that even though multiple OSPFv3 instances may be associated Note that even though multiple OSPFv3 instances may be associated
with a VRF, a sham link is still thought of as a relation between two with a VRF, a sham link is still thought of as a relation between two
VRFs. VRFs.
Another modification to OSPFv2 sham links is that OSPFv3 sham links Another modification to OSPFv2 sham links is that OSPFv3 sham links
are now identified by 128-bit endpoint addresses. Since sham links are now identified by 128-bit endpoint addresses. Since sham link
end-point addresses are now 128-bits, they can no longer default to endpoint addresses are now 128 bits, they can no longer default to
the RouterID, which is a 32-bit number. Sham link endpoint addresses the RouterID, which is a 32-bit number. Sham link endpoint addresses
MUST be configured. MUST be configured.
Sham link endpoint addresses MUST be distributed by BGP as routeable Sham link endpoint addresses MUST be distributed by BGP as routeable
VPN IPv6 addresses whose IPv6 address prefix is 128 bits long. As VPN IPv6 addresses, each with an IPv6 address prefix that is 128 bits
specified in section 4.2.7.1 of [rfc4577], these endpoint addresses long. As specified in Section 4.2.7.1 of [RFC4577], these endpoint
MUST NOT be advertised by OSPFv3; if there is no BGP route to the addresses MUST NOT be advertised by OSPFv3; if there is no BGP route
sham link endpoint address, that address is to appear unreachable, so to the sham link endpoint address, that address is to appear
that the sham link appears to be down. unreachable, so that the sham link appears to be down.
If there is a BGP route to the remote sham link endpoint address, the If there is a BGP route to the remote sham link endpoint address, the
sham link appears to be up. Conversely, if there is no BGP route to sham link appears to be up. Conversely, if there is no BGP route to
the sham link endpoint address, the sham link appears to be down. the sham link endpoint address, the sham link appears to be down.
5.1. Creating A Sham link 5.1. Creating a Sham Link
The procedures for creating an OSPFv3 sham link are identical to The procedures for creating an OSPFv3 sham link are identical to
those specified in Section 4.2.7.2 of [rfc4577]. Note that the those specified in Section 4.2.7.2 of [RFC4577]. Note that the
creation of OSPFv3 sham links requires the configuration of both creation of OSPFv3 sham links requires the configuration of both
local and remote 128-bit sham link endpoint addresses. The local local and remote 128-bit sham link endpoint addresses. The local
Sham link endpoint address associated with a VRF MAY be used by all sham link endpoint address associated with a VRF MAY be used by all
OSPFv3 instances that are attached to that VRF. The OSPFv3 PE-PE OSPFv3 instances that are attached to that VRF. The OSPFv3 PE-PE
"link" Instance ID in the protocol packet header is used to "link" Instance ID in the protocol packet header is used to
demultiplex multiple OSPFv3 instance protocol packets exchanged over demultiplex multiple OSPFv3 instance protocol packets exchanged over
the sham link. the sham link.
5.2. OSPF Protocol On Sham link 5.2. OSPF Protocol on Sham Link
Much of the operation of OSPFv3 over a sham link is semantically the Much of the operation of OSPFv3 over a sham link is semantically the
same as the operation of OSPFv2 over a sham link, as described in same as the operation of OSPFv2 over a sham link, as described in
Section 4.2.7.3 of [rfc4577]. This includes the methodology for Section 4.2.7.3 of [RFC4577]. This includes the methodology for
sending and receiving OSPFv3 packets over sham links, as well as sending and receiving OSPFv3 packets over sham links, as well as
Hello/Router Dead Intervals. Furthermore, the procedures associated Hello/Router Dead Intervals. Furthermore, the procedures associated
with the assignment of sham link metrics adhere to those set forth with the assignment of sham link metrics adhere to those set forth
for OSPFv2. OSPFv3 sham links are treated as on demand circuits. for OSPFv2. OSPFv3 sham links are treated as on-demand circuits.
Although the operation of the OSPFv3 protocol over the sham link is Although the operation of the OSPFv3 protocol over the sham link is
the same as OSPFv2, multiple OSPFv3 instances may be instantiated the same as OSPFv2, multiple OSPFv3 instances may be instantiated
across this link. By instantiating multiple instances across the across this link. By instantiating multiple instances across the
sham link, distinct intra-area connections can be established between sham link, distinct intra-area connections can be established between
PE-PE OSPFv3 instances associated with the endpoint addresses. PE-PE OSPFv3 instances associated with the endpoint addresses.
For example, if two OSPFv3 instances (O1, O2) attach to a VRF V1, and For example, if two OSPFv3 instances (O1, O2) attach to a VRF V1, and
on a remote PE, two other OSPFv3 instances (O3, O4) attach to a VRF on a remote PE, two other OSPFv3 instances (O3, O4) attach to a VRF
V2, it may be desirable to connect, O1 and O3 with an intra-area V2, it may be desirable to connect O1 and O3 with an intra-area link,
link, and O2 and O4 with an intra-area link. This can be and O2 and O4 with an intra-area link. This can be accomplished by
accomplished by instantiating two OSPFv3 instances across the sham instantiating two OSPFv3 instances across the sham link, which
link, which connects V1 and V2. O1 and O3 can be mapped to one of connects V1 and V2. O1 and O3 can be mapped to one of the sham link
the sham link OSPFv3 instances; O2 and O4 can be mapped to the other OSPFv3 instances; O2 and O4 can be mapped to the other sham link
sham link OSPFv3 instance. OSPFv3 instance.
5.3. OSPF Packet Forwarding On Sham Link 5.3. OSPF Packet Forwarding on Sham Link
The rules associated with route redistribution, stated in Section The rules associated with route redistribution, stated in Section
4.2.7.4 of [rfc4577], remain unchanged in this specification. 4.2.7.4 of [RFC4577], remain unchanged in this specification.
Specifically: Specifically:
If the next hop interface for a particular route is a sham link, If the next-hop interface for a particular route is a sham link,
then the PE SHOULD NOT redistribute that route into BGP as a VPN- then the PE SHOULD NOT redistribute that route into BGP as a VPN-
IPv6 route. IPv6 route.
Any other route advertised in an LSA that is transmitted over a Any other route advertised in an LSA that is transmitted over a
sham link MUST also be redistributed (by the PE flooding the LSA sham link MUST also be redistributed (by the PE flooding the LSA
over the sham link) into BGP. over the sham link) into BGP.
When redistributing these LSAs into BGP, they are encoded with the When redistributing these LSAs into BGP, they are encoded with the
BGP Extended Communities Attributes, as defined in Section 4.4 of BGP Extended Communities Attributes, as defined in Section 4.4 of
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 (AFs) in OSPFv3 is described
in [rfc5838]. [rfc5838] differentiates between AF using reserved in [RFC5838]. [RFC5838] differentiates between AFs by 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 VPN backbone. All AFs redistributed from OSPFv3 families across a VPN backbone. All AFs redistributed from OSPFv3
into BGP on a PE MUST contain the BGP Extended Communities Attributes into BGP on a PE MUST contain the BGP Extended Communities 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 new security OSPFv3 as the PE-CE protocol and do not introduce any new security
concerns other than those already defined in Section 6 of [rfc4577]. 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 An early version of this document resulted in the allocation of
Route Attributes (0x0004) entry in the BGP IPv6 Address Specific OSPFv3 Route Attributes (0x0004) entry in the BGP IPv6 Address
Extended Community. This allocation is no longer required. IANA is Specific Extended Community. This allocation is no longer required.
requested to mark the OSPFv3 Route Attributes (0x0004) entry in the IANA has marked the OSPFv3 Route Attributes (0x0004) entry in the BGP
BGP IPv6 Address Specific Extended Community registry as deprecated. IPv6 Address Specific Extended Community registry as deprecated. The
BGP Extended Communities Attributes in this document have already
The BGP Extended Communities Attributes in this document are already been registered by IANA.
referenced in IANA.
9. Contributors
Joe Lapolito
10. Acknowledgments 9. 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. Special thanks to Stewart Bryant, Stephen Farrel and Fred comments. Special thanks to Stewart Bryant, Stephen Farrel, and Fred
Baker for their thorough review. Baker for their thorough review.
This document was produced using Marshall Rose's xml2rfc tool. 10. References
11. References
11.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFC's to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[rfc2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[rfc2858] Bates, T., Rehkter, Y., Chandra, R., and D. Katz,
"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. Rekhter, "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. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
[rfc4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a [RFC4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a
Link State Advertisement (LSA) Options Bit to Prevent Link State Advertisement (LSA) Options Bit to Prevent
Looping in BGP/MPLS IP Virtual Private Networks (VPNs)", Looping in BGP/MPLS IP Virtual Private Networks (VPNs)",
RFC 4576, June 2006. RFC 4576, June 2006.
[rfc4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the
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. Le Faucheur,
"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 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, January
2007.
[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. [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and
Lindem, "Support of address families in OSPFv3", R. Aggarwal, "Support of Address Families in OSPFv3", RFC
April 2010. 5838, April 2010.
11.2. Informative References 10.2. Informative References
[rfc2547] Rosen, E. and Y. Rehkter, "BGP/MPLS VPNs", RFC 2547, [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March
March 1999. 1999.
Authors' Addresses Authors' Addresses
Padma Pillay-Esnault Padma Pillay-Esnault
Cisco Systems Cisco Systems
510 McCarty Blvd 510 McCarty Blvd.
Milpitas, CA 95035 Milpitas, CA 95035
USA USA
EMail: ppe@cisco.com EMail: ppe@cisco.com
Peter Moyer Peter Moyer
Pollere, Inc Pollere, Inc.
325M Sharon Park Drive #214 325M Sharon Park Drive #214
Menlo Park, CA 94025 Menlo Park, CA 94025
USA USA
EMail: pete@pollere.net EMail: pete@pollere.net
Jeff Doyle Jeff Doyle
Jeff Doyle and Associates Jeff Doyle and Associates
9878 Teller Ct. 9878 Teller Ct.
Westminster, CO 80021 Westminster, CO 80021
USA USA
EMail: jdoyle@doyleassociates.net EMail: jdoyle@doyleassociates.net
Emre Ertekin Emre Ertekin
Booz Allen Hamilton Booz Allen Hamilton
5220 Pacific Concourse Drive 5220 Pacific Concourse Drive
Los Angeles, CA 90045 Los Angeles, CA 90045
USA USA
EMail: ertekin_emre@bah.com EMail: ertekin_emre@bah.com
Michael Lundberg Michael Lundberg
Booz Allen Hamilton Booz Allen Hamilton
22 Batterymarch Street 8283 Greensboro Drive
Boston, MA 02109 McLean, VA 22102
USA USA
EMail: lundberg_michael@bah.com EMail: lundberg_michael@bah.com
 End of changes. 124 change blocks. 
253 lines changed or deleted 231 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/