draft-ietf-l3vpn-ospfv3-pece-01.txt   draft-ietf-l3vpn-ospfv3-pece-02.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: May 7, 2009 Pollere LLC Expires: September 9, 2009 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
November 3, 2008 March 8, 2009
OSPFv3 as a PE-CE routing protocol OSPFv3 as a PE-CE routing protocol
draft-ietf-l3vpn-ospfv3-pece-01 draft-ietf-l3vpn-ospfv3-pece-02
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
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 May 7, 2009. This Internet-Draft will expire on September 9, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
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 the Virtual Private Network (VPN) Many Service Providers (SPs) offer Virtual Private Network (VPN)
services to their customers, using a technique in which Customer Edge services to their customers using a technique in which Customer Edge
(CE) routers are routing peers of Provider Edge (PE) routers. The (CE) routers are routing peers of Provider Edge (PE) routers. The
Border Gateway Protocol (BGP) is used to distribute the customer's Border Gateway Protocol (BGP) is used to distribute the customer's
routes across the provider's IP backbone network, and Multiprotocol routes across the provider's IP backbone network, and Multiprotocol
Label Switching (MPLS) is used to tunnel customer packets across the Label Switching (MPLS) is used to tunnel customer packets across the
provider's backbone. This is known as a "BGP/MPLS IP VPN". provider's backbone. This is known as a "BGP/MPLS IP VPN".
Originally only IPv4 was supported and it was later extended to Originally only IPv4 was supported and it was later extended to
support IPv6 VPNs as well. Extensions were later added for the support IPv6 VPNs as well. Extensions were later added for the
support of the Open Shortest Path First protocol version 2 (OSPFv2) support of the Open Shortest Path First protocol version 2 (OSPFv2)
as a PE-CE routing protocol for the IPv4 VPNs. This document extends as a PE-CE routing protocol for the IPv4 VPNs. This document extends
those specifications to support OSPF version 3 (OSPFv3) as a PE-CE those specifications to support OSPF version 3 (OSPFv3) as a PE-CE
routing protocol. The OSPFv3 PE-CE functionality is identical to routing protocol. The OSPFv3 PE-CE functionality is identical to
that of OSPFv2 except for the differences described in this document. that of OSPFv2 except for the differences described in this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Specification of Requirements . . . . . . . . . . . . . . . . 3 2. Specification of Requirements . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. OSPFv3 Specificities . . . . . . . . . . . . . . . . . . . 4 3.1. OSPFv3 Specificities . . . . . . . . . . . . . . . . . . . 5
4. BGP/OSPFv3 Interaction Procedures for PE Routers . . . . . . . 5 4. BGP/OSPFv3 Interaction Procedures for PE Routers . . . . . . . 6
4.1. VRFs and OSPFv3 Instances . . . . . . . . . . . . . . . . 5 4.1. VRFs and OSPFv3 Instances . . . . . . . . . . . . . . . . 6
4.1.1. Independent OSPFv3 Instances in PEs . . . . . . . . . 5 4.1.1. Independent OSPFv3 Instances in PEs . . . . . . . . . 6
4.1.2. OSPFv3 Domain and PE-PE Link Instance Identifiers . . 6 4.1.2. OSPFv3 Domain and PE-PE Link Instance Identifiers . . 7
4.2. OSPFv3 Areas . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. OSPFv3 Areas . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. VRFs and Routes . . . . . . . . . . . . . . . . . . . . . 7 4.3. VRFs and Routes . . . . . . . . . . . . . . . . . . . . . 8
4.3.1. OSPFv3 Routes on PE . . . . . . . . . . . . . . . . . 8 4.3.1. OSPFv3 Routes on PE . . . . . . . . . . . . . . . . . 9
4.3.2. VPN-IPv6 Routes Received from MP-BGP . . . . . . . . . 9 4.3.2. VPN-IPv6 Routes Received from MP-BGP . . . . . . . . . 10
4.4. OSPFv3 Route Extended Communities Attribute . . . . . . . 11 4.4. OSPFv3 Route Extended Communities Attribute . . . . . . . 12
4.5. Loop Prevention Techniques . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . 14 5. OSPFv3 Sham Links . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Creating A Sham link . . . . . . . . . . . . . . . . . . . 15 5.1. Creating A Sham link . . . . . . . . . . . . . . . . . . . 16
5.2. OSPF Protocol On Sham link . . . . . . . . . . . . . . . . 15 5.2. OSPF Protocol On Sham link . . . . . . . . . . . . . . . . 16
5.3. OSPF Packet Forwarding On Sham Link . . . . . . . . . . . 16 5.3. OSPF Packet Forwarding On Sham Link . . . . . . . . . . . 17
6. Multiple Address Family Support . . . . . . . . . . . . . . . 17 6. Multiple Address Family Support . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . . 20
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.
Initially, the BGP/MPLS IP VPN specification enabled PE routers to The initial BGP/MPLS IP VPN specification enabled PE routers to learn
learn routes within customer sites through static routing, or through routes within customer sites through static routing, or through a
a dynamic routing protocol instantiated on the PE-CE link. dynamic routing protocol instantiated on the PE-CE link.
Specifically, [rfc4364] (and its predecessor, [rfc2547]) included Specifically, [rfc4364] (and its predecessor, [rfc2547]) included
support for dynamic routing protocols such as BGP, RIP, and OSPFv2. support for dynamic routing protocols such as BGP, RIP, and OSPFv2.
The OSPFv2 as the Provider/Customer Edge Protocol for BGP/MPLS IP The OSPFv2 as the Provider/Customer Edge Protocol for BGP/MPLS IP
Virtual Private Networks specification [rfc4577] further updates the Virtual Private Networks specification [rfc4577] further updates the
operation of OSPFv2 as the PE-CE routing protocol by detailing operation of OSPFv2 as the PE-CE routing protocol by detailing
additional extensions to enable intra-domain routing connectivity additional extensions to enable intra-domain routing connectivity
between OSPFv2-based customer sites. between OSPFv2-based customer sites.
While [rfc4364] was defined for IPv4 based networks, [rfc4659] While [rfc4364] was defined for IPv4 based networks, [rfc4659]
extends the BGP/MPLS IP VPN framework to support IPv6 VPNs. This extends the BGP/MPLS IP VPN framework to support IPv6 VPNs. This
skipping to change at page 5, line 39 skipping to change at page 6, line 39
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). As specified in [rfc5340], the Instance ID has VPN backbone (PE-PE). As specified in [rfc5340], the Instance ID has
link-local significance only. Therefore, the Instance IDs assigned 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-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. 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.
Further details on Domain and Instance IDs are provided in Section Further details on Domain IDs and Instance IDs are provided in
4.1.2. 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 28 skipping to change at page 7, line 28
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 associated with a VRF, each instance should have a unique PE-PE
"link" 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 the receiving incoming VPN-IPv6 route belongs to the same domain as the receiving
OSPFv3 instance. An incoming VPN-IPv6 route is said to belong to the OSPFv3 instance. An incoming VPN-IPv6 route is said to 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. A non-NULL incoming Domain ID matches either the local primary or
or one of the secondary Domain IDs. If the local Domain ID or one of the secondary Domain IDs. If the local Domain ID and
incoming Domain ID is NULL, it is considered a match. incoming Domain ID are NULL, it is considered a match.
2. The non-NULL incoming Instance ID matches the local Instance ID. 2. A 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 and incoming Instance ID are 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 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 MPLS to be installed in different VRFs of the same OSPFv3 domain, the MPLS
VPN backbone cannot be considered as a single router from the VPN backbone cannot be considered as a single router from the
perspective of the Domain's CEs. Rather, each CE should view its perspective of the domain's CEs. Rather, each CE should view its
connected PE as a separate router. connected PE as a separate router.
The PE uses OSPFv3 to distribute routes to CEs, and MP-BGP [rfc2858] The PE uses OSPFv3 to distribute routes to CEs, and MP-BGP [rfc2858]
to distribute VPN-IPv6 routes to other (remote) PE routers as defined to distribute VPN-IPv6 routes to other (remote) PE routers as defined
in [rfc4659]. An IPv6 prefix installed in the VRF by OSPFv3 is in [rfc4659]. An IPv6 prefix installed in the VRF by OSPFv3 is
changed to a VPN-IPv6 prefix by the addition of an 8-octet Route changed to a VPN-IPv6 prefix by the addition of an 8-octet Route
Distinguisher (RD) as discussed in Section 2 of [rfc4659]. This VPN- Distinguisher (RD) as discussed in Section 2 of [rfc4659]. This VPN-
IPv6 route can then be redistributed into MP-BGP according to an IPv6 route can then be redistributed into MP-BGP according to an
export policy that adds a Route Target Extended Communities (RT) export policy that adds a Route Target Extended Communities (RT)
attribute to the NLRI [rfc4360]. An IPv6 Address Specific BGP attribute to the NLRI [rfc4360]. An IPv6 Address Specific BGP
skipping to change at page 8, line 19 skipping to change at page 9, line 19
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 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 MP-BGP. OSPFv3 routes are installed in a
using the OSPFv3 decision process. As described in [rfc4577], OSPFv2 VRF using the OSPFv3 decision process. As described in [rfc4577],
routes installed in a VRF may be redistributed into BGP and OSPFv2 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
skipping to change at page 8, line 49 skipping to change at page 9, line 49
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 PE's Router ID associated with the OSPFv3 instance.
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)
skipping to change at page 9, line 47 skipping to change at page 10, line 47
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
No OSPFv3 route to the same prefix exists in the VRF, as discussed No OSPFv3 route to the same prefix exists in the VRF.
in Section 4.3.2.4.
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 what LSA types and what
CEs to advertise the routes to. CEs to advertise the routes to.
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
skipping to change at page 10, line 43 skipping to change at page 11, line 43
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 OSPFv3 Route Extended Communities attribute or attributes) is the OSPFv3 Route Extended Communities attribute or attributes) is
compared with the local OSPFv3 Domain ID and Instance ID, if compared with the local OSPFv3 Domain ID and Instance ID, if
skipping to change at page 11, line 48 skipping to change at page 12, line 48
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.
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 MUST have a corresponding BGP Extended Community
which contains and preserves the OSPFv3 information attached to the Attribute which contains and preserves the OSPFv3 information
original OSPFv3 route. attached to the 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
skipping to change at page 15, line 42 skipping to change at page 16, line 42
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 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. 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
skipping to change at page 18, line 7 skipping to change at page 19, line 7
OSPFv3 Route Attributes 0x0004 OSPFv3 Route Attributes 0x0004
The OSPFv3 specific BGP Extended Community types The OSPFv3 specific BGP Extended Community types
9. Contributors 9. Contributors
Joe Lapolito Joe Lapolito
10. 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, Matthew
Vineet Mehta for their support of this work. Everett, and Dr. 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.
11. References 11. References
11.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.
skipping to change at page 19, line 29 skipping to change at page 20, line 29
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 LLC 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
skipping to change at page 20, line 14 skipping to change at page 21, line 14
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
35 Corporate Dr. 22 Batterymarch Street
Burlington, MA 01803 Boston, MA 02109
USA USA
EMail: lundberg_michael@bah.com EMail: lundberg_michael@bah.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 26 change blocks. 
69 lines changed or deleted 89 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/