draft-ietf-l3vpn-ospfv3-pece-00.txt   draft-ietf-l3vpn-ospfv3-pece-01.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: April 10, 2009 Pollere LLC Expires: May 7, 2009 Pollere LLC
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
October 7, 2008 November 3, 2008
OSPFv3 as a PE-CE routing protocol OSPFv3 as a PE-CE routing protocol
draft-ietf-l3vpn-ospfv3-pece-00 draft-ietf-l3vpn-ospfv3-pece-01
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 10, 2009. This Internet-Draft will expire on May 7, 2009.
Abstract Abstract
Many Service Providers (SPs) offer the Virtual Private Network (VPN) Many Service Providers (SPs) offer the 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. This is known as a "BGP/MPLS IP VPN".
skipping to change at page 2, line 23 skipping to change at page 2, line 23
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Specification of Requirements . . . . . . . . . . . . . . . . 3 2. Specification of Requirements . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. OSPFv3 Specificities . . . . . . . . . . . . . . . . . . . 4 3.1. OSPFv3 Specificities . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . 5 4.1.1. Independent OSPFv3 Instances in PEs . . . . . . . . . 5
4.1.2. OSPFv3 Domain and PE-PE Link Instance Identifiers . . 6 4.1.2. OSPFv3 Domain and PE-PE Link Instance Identifiers . . 6
4.2. OSPFv3 Areas . . . . . . . . . . . . . . . . . . . . . . . 6 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. OSPFv3 Route Extended Communities Attribute . . . . . . . 11 4.4. OSPFv3 Route Extended Communities Attribute . . . . . . . 11
4.5. Loop Prevention Techniques . . . . . . . . . . . . . . . . 13 4.5. Loop Prevention Techniques . . . . . . . . . . . . . . . . 13
4.5.1. OSPFv3 Down Bit . . . . . . . . . . . . . . . . . . . 13 4.5.1. OSPFv3 Down Bit . . . . . . . . . . . . . . . . . . . 14
4.5.2. Other Possible Loops . . . . . . . . . . . . . . . . . 14 4.5.2. Other Possible Loops . . . . . . . . . . . . . . . . . 14
5. OSPFv3 VRF Instance Processing . . . . . . . . . . . . . . . . 14 5. OSPFv3 Sham Links . . . . . . . . . . . . . . . . . . . . . . 14
5.1. OSPFv3 VRF LSA Handling From CE . . . . . . . . . . . . . 14 5.1. Creating A Sham link . . . . . . . . . . . . . . . . . . . 15
5.2. OSPFv3 Sham Links . . . . . . . . . . . . . . . . . . . . 14 5.2. OSPF Protocol On Sham link . . . . . . . . . . . . . . . . 15
5.2.1. Creating A Sham link . . . . . . . . . . . . . . . . . 16 5.3. OSPF Packet Forwarding On Sham Link . . . . . . . . . . . 16
5.2.2. OSPF Protocol On Sham link . . . . . . . . . . . . . . 16 6. Multiple Address Family Support . . . . . . . . . . . . . . . 17
5.2.3. OSPF Packet Forwarding On Sham Link . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . . 19
10.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
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.
skipping to change at page 4, line 10 skipping to change at page 4, line 10
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 for IPv6 remain semantically identical for the deployment of OSPFv3.
VPNs.
[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.0 of [rfc5340] describes differences between OSPFv3 and
skipping to change at page 4, line 46 skipping to change at page 4, line 45
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. To distinguish between routes originated from different same VRF. To distinguish between routes originated from different
OSPFv3 instances, an Instance ID field is carried in the newly- OSPFv3 instances, an Instance ID field is carried in a newly-
defined OSPFv3 Route Extended Community attribute. defined OSPFv3 Route Extended Community attribute.
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.2. 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
skipping to change at page 5, line 34 skipping to change at page 5, line 33
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. However, since a PE interface can be distinct OSPFv3 instances. However, since a PE interface can be
associated with only one VRF, all OSPFv3 instances running on the associated with only one VRF, all OSPFv3 instances running on the
same interface MUST be associated with the same VRF. same interface MUST be associated with the same VRF.
Since multiple OSPFv3 instances can be associated with a single VRF, Since multiple OSPFv3 instances can be associated with a single VRF,
an additional mechanism is needed to demultiplex routes across these an additional mechanism is needed to demultiplex routes across these
instances. When a PE supports multiple OSPFv3 instances in a VRF, a instances. When a PE supports multiple OSPFv3 instances in a VRF, a
local Instance ID is assigned to the "link" that spans over the MPLS local Instance ID is assigned to the "link" that spans over the MPLS
VPN backbone (PE-PE). By default, this Instance ID is set to NULL. VPN backbone (PE-PE). As specified in [rfc5340], the Instance ID has
link-local significance only. Therefore, the Instance IDs assigned
to the PE-PE "link" need not be the same as the Instance IDs assigned
to the PE-CE links. By default, this Instance ID is set to NULL.
The OSPFv3 Domain ID and local Instance ID associated with the MPLS The OSPFv3 Domain ID and local Instance ID associated with the MPLS
backbone may be used to demultiplex routes for multiple instances. backbone may be used to demultiplex routes for multiple instances.
The detailed mechanism is described in Section 4.1.2. Further details on Domain and Instance IDs are provided in Section
4.1.2.
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
skipping to change at page 6, line 20 skipping to change at page 6, line 23
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 MPLS 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 may be null primary Domain ID is configured. The Domain ID may be
configured on a per-OSPFv3 Instance basis or per-VRF. If the Domain configured on a per-OSPFv3 instance basis or per-VRF. If the Domain
ID is configured on the VRF level, consequently all OSPFv3 instances ID is configured on the VRF level, consequently all OSPFv3 instances
associated with the VRF will share the same Domain ID. associated with the VRF will share the same Domain ID.
The OSPFv3 PE-PE Link Instance ID has local significance for the The OSPFv3 PE-PE "link" Instance ID has local significance for the
PE-PE link over the MPLS VPN backbone within a VRF. This link PE-PE link over the MPLS VPN backbone within a VRF. This link
Instance ID is used for the support of multiple OSPFv3 instances Instance ID is used for the support of multiple OSPFv3 instances
within the same VRF and it is also transported along with the VPN- within the same VRF and it is also transported along with the VPN-
IPv6 route in a BGP attribute over the MPLS VPN backbone. A PE-PE IPv6 route in a BGP attribute over the MPLS VPN backbone. A PE-PE
Link Instance ID is needed only if multiple OSPFv3 instances are "link" Instance ID is needed only if multiple OSPFv3 instances are
supported, otherwise it is set to NULL. When multiple instances are supported, otherwise it is set to NULL. When multiple instances are
associated with a VRF, each instance should have a unique PE-PE Link associated with a VRF, each instance should have a unique PE-PE
Instance ID. "link" Instance ID.
The <Domain ID, Instance ID> tuple is used to determine whether an The <Domain ID, Instance ID> tuple is used to determine whether an
incoming VPN-IPv6 route belongs to the same Domain as in the incoming VPN-IPv6 route belongs to the same Domain as the receiving
receiving OSPFv3 instance. An incoming VPN-IPv6 route is said to OSPFv3 instance. An incoming VPN-IPv6 route is said to belong to the
belong to the same domain if both conditions below are met same domain if both conditions below are met
1. The non-NULL incoming Domain ID matches either the local primary 1. The non-NULL incoming Domain ID matches either the local primary
or one of the secondary Domain IDs. If the local Domain ID or or one of the secondary Domain IDs. If the local Domain ID or
incoming Domain ID is NULL, it is considered a match. incoming Domain ID is NULL, it is considered a match.
2. The non-NULL incoming Instance ID matches the local Instance ID. 2. The non-NULL incoming Instance ID matches the local Instance ID.
If the local Instance ID or incoming Instance ID is NULL, it is If the local Instance ID or incoming Instance ID is NULL, it is
considered a match. 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 OSPF 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.
skipping to change at page 7, line 33 skipping to change at page 7, line 39
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]. An IPv6 Address Specific BGP attribute to the NLRI [rfc4360]. An IPv6 Address Specific BGP
Extended Communities attribute as described in [BGP-EXTCOMM-IPV6] may Extended Communities attribute as described in [BGP-EXTCOMM-IPV6] may
also be attached to the route. also be attached to the route.
Domain IDs and Instance IDs are used to distinguish between OSPFv3 Domain IDs and Instance IDs are used to distinguish between OSPFv3
instances. When an OSPFv3-distributed route is redistributed into instances. When an OSPFv3-distributed route is redistributed into
MP-BGP, the Domain ID, OSPFv3 Router ID, Area, OSPFv3 Route Type, MP-BGP, the Domain ID, OSPFv3 Router ID, Area, OSPFv3 Route Type,
External Route Type, and Instance ID are also carried in an attribute External Route Type, Options fields, and Instance ID are also carried
of the MP-BGP route. in an attribute 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
which of the eligible routes are to be installed in the associated which of the eligible routes are to be installed in the associated
VRF, and the selected set of VPN-IPv6 routes are converted into IPv6 VRF, and the selected set of VPN-IPv6 routes are converted into IPv6
routes by removing the RD before installation. routes by removing the RD before installation.
An IPv6 route learned from MP-BGP and installed in a VRF might or An IPv6 route learned from MP-BGP and installed in a VRF might or
might not be redistributed into OSPFv3, depending on the local might not be redistributed into OSPFv3, depending on the local
skipping to change at page 8, line 13 skipping to change at page 8, line 20
particular OSPFv3 instance, the OSPFv3 Route Extended Community particular OSPFv3 instance, the OSPFv3 Route Extended Community
attribute (Section 4.4) of the VPN-IPv6 route is used to determine attribute (Section 4.4) 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 PE
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 BGP. OSPFv3 routes are installed in a VRF routes from other PEs via BGP. OSPFv3 routes are installed in a VRF
using the OSPFv3 decision process. As described in [rfc4577], OSPF using the OSPFv3 decision process. As described in [rfc4577], OSPFv2
routes installed in a VRF may be redistributed into BGP and routes installed in a VRF may be redistributed into BGP and
disseminated to other PEs participating in the VPN. At these remote disseminated to other PEs participating in the VPN. At these remote
PEs, the VPN-IPv6 routes may be imported into a VRF and redistributed PEs, the VPN-IPv6 routes may be imported into a VRF and redistributed
into the OSPFv3 instance(s) associated with that VRF. 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 a
RT that corresponds to the VRF. This RT is examined at remote PEs. RT that corresponds to the VRF. This RT is examined at remote PEs.
In order to import a route, a VRF must have a RT that is identical to In order to import a route, a VRF must have a RT that is identical to
the route's RT. For routes which are eligible to be imported into the route's RT. For routes which are eligible to be imported into
the VRF, the standard BGP decision process is used to choose the the VRF, the standard BGP decision process is used to choose the
"best" route(s). "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 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 an OSPFv3 Route back into OSPFv3 by the remote PEs is carried in an OSPFv3 Route
Extended Communities attribute (Section 4.4). The relevant local Extended Communities attribute (Section 4.4). The relevant local
OSPFv3 information encoded into the attribute is: OSPFv3 information encoded into the attribute is:
The Domain ID of the local OSPFv3 process. If no Domain ID is The Domain ID of the local OSPFv3 process. If no Domain ID is
configured, the NULL identifier is used. configured, the NULL identifier is used.
The Instance ID of the PE-PE link The Instance ID of the PE-PE link
The Area ID of the PE-CE link. The Area ID of the PE-CE link.
The PE's Router ID associated with the OSPFv3 instance. The Route The PE's Router ID associated with the OSPFv3 instance.
Type, as determined by the LSA type from which the route was
learned. The Route Type, as determined by the LSA type from which the route
was learned.
The Options fields (External metric-type)
A Multi-Exit-Discriminator (MED) attribute SHOULD also be set to the
value of the OSPFv3 distance associated with the route plus 1, when
the OSPFv3 route is redistributed into the MP-BGP.
4.3.2. VPN-IPv6 Routes Received from MP-BGP 4.3.2. VPN-IPv6 Routes Received from MP-BGP
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 to advertise the route What OSPFv3 LSA type is to be used when advertising the route into
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
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
skipping to change at page 10, line 13 skipping to change at page 10, line 25
domain of the OSPFv3 instance into which it is to be domain of the OSPFv3 instance into which it is to be
redistributed; AND 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 ABR Note that under these rules the PE represents itself as an ABR
regardless of whether or not the route is being advertised into the regardless of whether or not the route is being advertised into the
same area number from which the remote PE learned it (that is, same area number from which the remote PE learned it (that is,
whether the VPN-IPv6 route carries the same or different area whether the VPN-IPv6 route carries the same or different area
numbers). This insures that if an area becomes partitioned, so that numbers).
two areas with the same area ID are separated by the VPN MPLS
backbone connectivity is maintained through an inter-area route.
4.3.2.2. OSPF Intra-Area Route 4.3.2.2. OSPF Intra-Area Route
A route is advertised from a PE to a CE as an intra-area route using A route is advertised from a PE to a CE as an intra-area route using
an Intra-Area-Prefix (type 0x2009) LSA only when sham links are used, an Intra-Area-Prefix (type 0x2009) LSA only when sham links are used,
as described in Section 5.2. Otherwise routes are advertised as as described in Section 5. Otherwise routes are advertised as either
either inter-area (Section 4.3.2.1) or external (Sections 4.3.2.3) inter-area (Section 4.3.2.1) or external (Sections 4.3.2.3) routes.
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, Instance ID> tuple) from the (as determined by the <Domain ID, Instance ID> tuple) from the
domain of the OSPFv3 instance into which it is redistributed; OR domain of the OSPFv3 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, Instance ID> tuple associated with the VPN-IPv6 route (in <Domain ID, Instance ID> tuple associated with the VPN-IPv6 route (in
the route OSPFv3 Route Extended Communities attribute or attributes) the OSPFv3 Route Extended Communities attribute or attributes) is
is compared with the local OSPFv3 Domain ID and Instance ID, if compared with the local OSPFv3 Domain ID and Instance ID, if
configured. Compared Domain IDs are considered identical if: configured. Compared Domain IDs are considered identical if:
1. All six bytes are identical; or 1. All six 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, in either case the route is considered to have
a NULL Domain ID. a NULL Domain ID.
skipping to change at page 11, line 24 skipping to change at page 11, line 32
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 a Type-7 (type
0x2007) LSA; otherwise the external route is advertised in an AS- 0x2007) LSA; otherwise the external route is advertised in an AS-
External (type 0x4005) LSA. External (type 0x4005) LSA.
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.
The PE sets the metric of the advertised external IPv6 route to the If the VPN-IPv6 route indicates a route type-1 metric, the PE
same value as the MED attribute of the VPN-IPv6 route from which the advertises the external route with that metric-type; otherwise the
IPv6 route was derived. If the VPN-IPv6 route has no associated MED metric-type of the external IPv6 route is set to type-2 by default.
attribute, a default metric value is used.
If the VPN-IPv6 route indicates a route type of 1, the PE advertises
the external route with that route type; otherwise the route type of
the external IPv6 route is set to 2 by default.
4.4. OSPFv3 Route Extended Communities Attribute 4.4. OSPFv3 Route Extended Communities Attribute
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 which need
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.
skipping to change at page 12, line 5 skipping to change at page 12, line 9
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 need to carry a BGP Extended Community Attribute the OSPFv3 routes need to carry a BGP Extended Community Attribute
which contains and preserves the OSPFv3 information attached to the which contains and preserves the OSPFv3 information attached to the
original OSPFv3 route. original OSPFv3 route.
This document defines a new BGP attribute in the proposed "IPv6 This document defines a new BGP attribute in the proposed "IPv6
Address Specific Extended Community" registry described in Section 3 Address Specific Extended Community" registry described in Section 3
of [BGP-EXTCOMM-IPV6]. The OSPFv3 Route Extended Community Attribute of [BGP-EXTCOMM-IPV6]. The OSPFv3 Route Extended Community Attribute
has the Sub-type value of 0x0004. It carries an OSPFv3 Domain ID, has the Sub-type value of 0x0004. It carries an OSPFv3 Domain ID,
OSPFv3 Router ID, OSPFv3 Area ID OSPFv3 Route type, Options, and an OSPFv3 Router ID, OSPFv3 Area ID, OSPFv3 Route type, Options, and an
OSPFv3 Instance ID field. OSPFv3 Instance ID 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 4 | OSPF Domain ID | | 0x00 | 4 | OSPF Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Domain ID (Cont.) | | OSPF Domain ID (Cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 34 skipping to change at page 13, line 39
Instance ID which is a one-byte number. The OSPFv3 Instance ID is Instance ID which is a one-byte number. The OSPFv3 Instance ID is
configured for the "link" simulated by the MPLS VPN backbone. configured for the "link" simulated by the MPLS VPN backbone.
This attribute MAY be present whether several OSPFv3 instances are This attribute MAY be present whether several OSPFv3 instances are
defined or not. The Instance ID default value is 0. defined or not. The Instance ID default value is 0.
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 received this information both through their those PE routers would receive this information both through their CE
CE and their peer PE. As there is transparent transport of OSPFv3 and their peer PE. As there is transparent transport of OSPFv3
routes over the BGP/MPLS backbone, it is not possible for the PE routes over the BGP/MPLS 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 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
for OSPFv2 and are applicable for OSPFv3 for inter-area-prefix LSAs, for OSPFv2 and are applicable for OSPFv3 for inter-area-prefix LSAs,
NSSA LSAs and External LSAs. Similarly, the DN-bit must be set in NSSA LSAs and External LSAs. Similarly, the DN-bit must be set in
inter-area-prefix-LSAs, NSSA-LSAs and AS-External-LSAs, when these inter-area-prefix-LSAs, NSSA-LSAs and AS-External-LSAs, when these
are originated from a PE to a CE, to prevent those prefixes from are originated from a PE to a CE, to prevent those prefixes from
being re-advertised into BGP. being re-advertised into BGP. As in [rfc4577], any LSA with the DN
bit set must not be used for route calculations.
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 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 [rfc4576], caution must be exercised if mutual
redistribution is performed on a PE causing loss of loop prevention redistribution is performed on a PE causing loss of loop prevention
information. information.
5. OSPFv3 VRF Instance Processing 5. OSPFv3 Sham Links
5.1. OSPFv3 VRF LSA Handling From CE
Much like [rfc4577], any LSA with the DN bit set must not be used for
route calculation. The DN bit for OSPFv3 LSAs is defined in
[rfc5340].
Section 4.2.6 of [rfc4577] states that a PE router must create a VPN
route in BGP for "every address prefix that was installed in the VRF
by one of its associated OSPFv3 instances". This holds true for
OSPFv3 as well.
Each VPN-IPv6 route created by a PE will carry an OSPFv3 Route
Extended Community Attribute, as defined in Section 4.4. The Domain
ID, Router ID, and area ID, Route Type and options fields within this
extended community correspond to the attributes defined in [rfc4577],
as they convey information about an OSPFv3 route in BGP. One new
addition is the Instance ID field. This field is used to encode
information about the OSPFv3 instances associated with a VRF.
Note that the new OSPFv3 Route Extended Community Attribute contains
all extended community attributes specified in [rfc4577] and the
OSPFv3 Instance ID but packs them into one attribute.
5.2. 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.
Sham links are used to allow two sites that have an intra-area A sham link enables a VPN backbone to act as an intra-area link. It
connection between them to act as a single VPN site that is multi- is needed when two sites are connected by an intra-area "backdoor"
homed to the backbone. Figure 1 shows the instantiation of a sham link and the inter-area MPLS VPN backbone route would be less
link between two VPN sites. preferable due to OSPF route preference rules. The figure below
shows the 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 15, line 36 skipping to change at page 15, line 22
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 links
end-point addresses are now 128-bits, they can no longer default to end-point addresses are now 128-bits, they can no longer default to
the RouterID, which is 32-bits 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 whose IPv6 address prefix is 128 bits long. As
specified in [rfc4577], these endpoint addresses MUST NOT be specified in [rfc4577], these endpoint addresses MUST NOT be
advertised by OSPFv3. advertised by OSPFv3.
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.2.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 is used to demultiplex multiple OSPFv3 instance link Instance ID is used to demultiplex multiple OSPFv3 instance
protocol packets exchanged over the sham link. protocol packets exchanged over the sham link.
5.2.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
skipping to change at page 16, line 43 skipping to change at page 16, line 24
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, and O2 and O4 with an intra-area link. This can be link, and O2 and O4 with an intra-area link. This can be
accomplished by instantiating two OSPFv3 instances across the sham accomplished by instantiating two OSPFv3 instances across the sham
link, which connects V1 and V2. O1 and O3 can be mapped to one of link, which connects V1 and V2. O1 and O3 can be mapped to one of
the sham link OSPFv3 instances; O2 and O4 can be mapped to the other the sham link OSPFv3 instances; O2 and O4 can be mapped to the other
sham link OSPFv3 instance. sham link OSPFv3 instance.
One difference from Section 4.2.7.3 of [rfc4577] is the addition of One difference from Section 4.2.7.3 of [rfc4577] is the addition of
Type 0x2009 intra-area-prefix LSAs, and the flooding of these LSAs Type 0x2009 intra-area-prefix LSAs, and the flooding of these LSAs
across the sham link. Furthermore, where OSPFv2 sham links are across the sham link. Furthermore, where prefixes associated with
advertised in Type-1 LSAs, prefixes associated with OSPFv3 sham links OSPFv2 sham links are advertised in Type-1 LSAs, prefixes associated
are advertised as OSPFv3 Type 0x2009 LSAs. This change is required with OSPFv3 sham links are advertised as OSPFv3 Type 0x2009 LSAs.
based on [rfc5340], which states that loopback interfaces are This change is required based on [rfc5340], which states that
advertised in intra-area-prefix LSAs. loopback interfaces are advertised in intra-area-prefix LSAs.
5.2.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.
skipping to change at page 17, line 24 skipping to change at page 17, line 5
When redistributing these LSAs into BGP, they are encoded with the When redistributing these LSAs into BGP, they are encoded with the
OSPFv3 Route Extended Community, as defined in Section 4.4 of this OSPFv3 Route Extended Community, as defined in Section 4.4 of this
document. 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. Security Considerations 6. Multiple Address Family Support
The support of multiple address families (AF) in OSPFv3 is described
in [OSPF-AF-ALT]. [OSPF-AF-ALT] differentiates between AF using
reserved ranges of InstanceIDs for each AF.
The architecture described in this document is fully compatible with
[OSPF-AF-ALT]. The OSPFv3 PE-CE protocol can support multiple
address families across a MPLS VPN backbone. All AFs redistributed
from OSPFv3 into BGP on a PE MUST contain the OSPFv3 Route Extended
Community Attribute.
Note that since [OSPF-AF-ALT] does not support multiple AFs across
virtual links, this document only addresses support for unicast IPv6
addresses across the sham link.
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 concerns
regarding the use of BGP as transport of IPv6 reachability over the regarding the use of BGP as transport of IPv6 reachability over the
MPLS Backbone. The Security considerations for the transport of IPv6 MPLS Backbone. The Security considerations for the transport of IPv6
reachability information using BGP are discussed in Section 11 of reachability information using BGP are discussed in Section 11 of
[rfc4659] and are not altered. [rfc4659] and are not altered.
The new extensions defined in this document do not introduce any new The new extensions defined in this document do not introduce any new
security concerns other than those already defined in Section 6 of security concerns other than those already defined in Section 6 of
[rfc4577]. [rfc4577].
7. IANA Considerations 8. IANA Considerations
This document defines a new BGP attribute in the proposed "IPv6 This document defines a new BGP attribute in the proposed "IPv6
Address Specific Extended Community" registry described in Section 3 Address Specific Extended Community" registry described in Section 3
of [BGP-EXTCOMM-IPV6]. This document makes the following assignments of [BGP-EXTCOMM-IPV6]. This document makes the following assignments
in the "IPv6 Address Specific Extended Community" registry. in the "IPv6 Address Specific Extended Community" registry.
Name Sub-type Value Name Sub-type Value
---- -------------- ---- --------------
OSPFv3 Route Attributes 0x0004 OSPFv3 Route Attributes 0x0004
The OSPFv3 specific BGP Extended Community types The OSPFv3 specific BGP Extended Community types
8. Contributors 9. Contributors
Joe Lapolito Joe Lapolito
9. Acknowledgments 10. Acknowledgments
The authors would like to thank Kelvin Upson, Seiko Okano, and Dr. The authors would like to thank Kelvin Upson, Seiko Okano, and Dr.
Vineet Mehta for their support of this work. Vineet Mehta for their support of this work.
This document was produced using Marshall Rose's xml2rfc tool. This document was produced using Marshall Rose's xml2rfc tool.
10. References 11. References
10.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFC's to [RFC2119] Bradner, S., "Key words for use in RFC's to
Indicate Requirement Levels", BCP 14, RFC 2119, Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997. March 1997.
[rfc2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [rfc2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[rfc2547] Rosen, E. and Y. Rehkter, "BGP/MPLS VPNs", [rfc2547] Rosen, E. and Y. Rehkter, "BGP/MPLS VPNs",
RFC 2547, March 1999. RFC 2547, March 1999.
skipping to change at page 19, line 10 skipping to change at page 19, line 6
RFC 4577, June 2006. RFC 4577, June 2006.
[rfc4659] De Clercq, J., Ooms, D., Carugi, M., and F. [rfc4659] De Clercq, J., Ooms, D., Carugi, M., and F.
Lefaucheur, "BGP-MPLS IP Virtual Private Network Lefaucheur, "BGP-MPLS IP Virtual Private Network
(VPN) Extension for IPv6 VPN", RFC 4659, (VPN) Extension for IPv6 VPN", RFC 4659,
September 2006. September 2006.
[rfc5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, [rfc5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem,
"OSPF for IPv6", RFC 5340, July 2008. "OSPF for IPv6", RFC 5340, July 2008.
10.2. Informative References 11.2. Informative References
[BGP-EXTCOMM-IPV6] Rehkter, Y., "IPv6 Address Specific BGP Extended [BGP-EXTCOMM-IPV6] Rehkter, Y., "IPv6 Address Specific BGP Extended
Communities Attribute", October 2008, <http:// Communities Attribute", October 2008, <http://
www.ietf.org/internet-drafts/ www.ietf.org/internet-drafts/
draft-rekhter-v6-ext-communities-02.txt>. draft-rekhter-v6-ext-communities-02.txt>.
[OSPF-AF-ALT] Mirtorabi, S., Roy, A., Barnes, M., Aggarwal, R.,
and A. Lindem, "Support of address families in
OSPFv3", October 2008, <http://www.ietf.org/
internet-drafts/draft-ietf-ospf-af-alt-07.txt>.
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
 End of changes. 46 change blocks. 
109 lines changed or deleted 108 lines changed or added

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