draft-ietf-l3vpn-ospfv3-pece-04.txt   draft-ietf-l3vpn-ospfv3-pece-05.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 28, 2010 Pollere, Inc Expires: September 9, 2010 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 24, 2009 March 8, 2010
OSPFv3 as a PE-CE routing protocol OSPFv3 as a PE-CE routing protocol
draft-ietf-l3vpn-ospfv3-pece-04 draft-ietf-l3vpn-ospfv3-pece-05
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 2, line 22 skipping to change at page 2, line 22
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 28, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Specification of Requirements . . . . . . . . . . . . . . . . 4 2. Specification of Requirements . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. OSPFv3 Specificities . . . . . . . . . . . . . . . . . . . 5 3.1. OSPFv3 Specificities . . . . . . . . . . . . . . . . . . . 5
4. BGP/OSPFv3 Interaction Procedures for PE Routers . . . . . . . 6 4. BGP/OSPFv3 Interaction Procedures for PE Routers . . . . . . . 6
4.1. VRFs and OSPFv3 Instances . . . . . . . . . . . . . . . . 6 4.1. VRFs and OSPFv3 Instances . . . . . . . . . . . . . . . . 6
4.1.1. Independent OSPFv3 Instances in PEs . . . . . . . . . 6 4.1.1. Independent OSPFv3 Instances in PEs . . . . . . . . . 6
4.1.2. OSPFv3 Domain and PE-PE Link Instance Identifiers . . 7 4.1.2. OSPFv3 Domain Identifier . . . . . . . . . . . . . . . 6
4.2. OSPFv3 Areas . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. OSPFv3 Areas . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. VRFs and Routes . . . . . . . . . . . . . . . . . . . . . 8 4.3. VRFs and Routes . . . . . . . . . . . . . . . . . . . . . 7
4.3.1. OSPFv3 Routes on PE . . . . . . . . . . . . . . . . . 9 4.3.1. OSPFv3 Routes on PE . . . . . . . . . . . . . . . . . 8
4.3.2. VPN-IPv6 Routes Received from MP-BGP . . . . . . . . . 10 4.3.2. VPN-IPv6 Routes Received from MP-BGP . . . . . . . . . 9
4.4. OSPFv3 Route Extended Communities Attribute . . . . . . . 12 4.4. OSPFv3 Route Extended Communities Attribute . . . . . . . 11
4.5. Loop Prevention Techniques . . . . . . . . . . . . . . . . 14 4.5. Loop Prevention Techniques . . . . . . . . . . . . . . . . 13
4.5.1. OSPFv3 Down Bit . . . . . . . . . . . . . . . . . . . 15 4.5.1. OSPFv3 Down Bit . . . . . . . . . . . . . . . . . . . 14
4.5.2. Other Possible Loops . . . . . . . . . . . . . . . . . 15 4.5.2. Other Possible Loops . . . . . . . . . . . . . . . . . 14
5. OSPFv3 Sham Links . . . . . . . . . . . . . . . . . . . . . . 15 5. OSPFv3 Sham Links . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Creating A Sham link . . . . . . . . . . . . . . . . . . . 16 5.1. Creating A Sham link . . . . . . . . . . . . . . . . . . . 15
5.2. OSPF Protocol On Sham link . . . . . . . . . . . . . . . . 16 5.2. OSPF Protocol On Sham link . . . . . . . . . . . . . . . . 16
5.3. OSPF Packet Forwarding On Sham Link . . . . . . . . . . . 17 5.3. OSPF Packet Forwarding On Sham Link . . . . . . . . . . . 16
6. Multiple Address Family Support . . . . . . . . . . . . . . . 18 6. Multiple Address Family Support . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
[rfc4364] offers Service Providers (SPs) a method for providing [rfc4364] offers Service Providers (SPs) a method for providing
Layer-3 Virtual Private Network (VPN) services to subtending customer Layer-3 Virtual Private Network (VPN) services to subtending customer
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 5, line 31 skipping to change at page 5, line 31
OSPFv2. Several of these changes will require modifications to the OSPFv2. Several of these changes will require modifications to the
architecture described in [rfc4577]. These differences and their architecture described in [rfc4577]. These differences and their
corresponding impact to [rfc4577] are described below: corresponding impact to [rfc4577] are described below:
New LSA types: New LSA types:
For an IPv6 MPLS/VPN architecture where customers interface to For an IPv6 MPLS/VPN architecture where customers interface to
providers through OSPFv3, traditional BGP/OSPF interactions providers through OSPFv3, traditional BGP/OSPF interactions
specify that VPN-IPv6 reachability information redistributed into specify that VPN-IPv6 reachability information redistributed into
OSPFv3 will be expressed as an AS-External OSPFv3 LSAs. Instead, OSPFv3 will be expressed as an AS-External OSPFv3 LSAs. Instead,
it may be desirable to view these LSAs as AS-internal (inter-area- it may be desirable to view these LSAs as inter-area-prefix LSAs.
prefix, and intra-area-prefix) LSAs. For the encoding of OSPFv3 For the encoding of OSPFv3 LSAs, a new OSPFv3 Route Extended
LSAs, a new OSPFv3 Route Extended Community attribute is defined Community attribute is defined in Section 4.4.
in Section 4.4.
Multiple instances over a link: Multiple instances over a link:
OSPFv3 operates on a per-link basis as opposed to OSPFv2, which OSPFv3 operates on a per-link basis as opposed to OSPFv2, which
operates on a per-IP-subnet basis. The support of multiple OSPFv3 operates on a per-IP-subnet basis. The support of multiple OSPFv3
protocol instances on a link changes the architecture described in protocol instances on a link changes the architecture described in
[rfc4577]. [rfc4577] specifies that each interface belongs to no [rfc4577]. [rfc4577] specifies that each interface belongs to no
more than one OSPF instance. For OSPFv3, multiple instances can more than one OSPF instance. For OSPFv3, multiple instances can
be established over a single interface, and associated with the be established over a single interface, and associated with the
same VRF. To distinguish between routes originated from different same VRF.
OSPFv3 instances, an Instance ID field is carried in a newly-
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. link is described in Section 5.
4. BGP/OSPFv3 Interaction Procedures for PE Routers 4. BGP/OSPFv3 Interaction Procedures for PE Routers
skipping to change at page 6, line 29 skipping to change at page 6, line 27
instantiated on an interface associated with a VRF, the VRF will be instantiated on an interface associated with a VRF, the VRF will be
populated with OSPFv3 routing information. populated with OSPFv3 routing information.
As OSPFv3 supports multiple instances on a single interface, it is As OSPFv3 supports multiple instances on a single interface, it is
therefore possible that multiple customer sites can connect to the therefore possible that multiple customer sites can connect to the
same interface of a PE router (e.g., through a layer 2 switch) using same interface of a PE router (e.g., through a layer 2 switch) using
distinct OSPFv3 instances. 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,
an additional mechanism is needed to demultiplex routes across these
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
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
backbone may be used to demultiplex routes for multiple instances.
Further details on Domain IDs 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
the interface, the PE establishes adjacencies with corresponding CEs the interface, the PE establishes adjacencies with corresponding CEs
associated with the instance. Note that although multiple instances associated with the instance. Note that although multiple instances
may populate a common VRF, they do not leak routes to one another, may populate a common VRF, they do not leak routes to one another,
unless configured to do so. unless configured to do so.
4.1.2. OSPFv3 Domain and PE-PE Link Instance Identifiers 4.1.2. OSPFv3 Domain Identifier
The OSPFv3 Domain ID describes the administrative domain of the OSPF The OSPFv3 Domain ID describes the administrative domain of the OSPF
instance which originated the route. It has an AS wide significance instance which originated the route. It has an AS wide significance
and is one of the parameters used to determine whether a VPN-IPv6 and is one of the parameters used to determine whether a VPN-IPv6
route should be translated as an Inter-area-prefix-LSA or External- route should be translated as an Inter-area-prefix-LSA or External-
LSA. Each OSPFv3 instance MUST have a primary Domain ID which is LSA. Each OSPFv3 instance MUST have a primary Domain ID which is
transported along with the VPN-IPv6 route in a BGP attribute over the transported along with the VPN-IPv6 route in a BGP attribute over the
MPLS VPN backbone. Each OSPFv3 instance may have a set of secondary 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 MUST be
configured on a per-OSPFv3 instance basis or per-VRF. If the Domain configured on a per-OSPFv3 instance basis.
ID is configured on the VRF level, consequently all OSPFv3 instances
associated with the VRF will share the same Domain ID.
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
Instance ID is used for the support of multiple OSPFv3 instances
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
"link" Instance ID is needed only if multiple OSPFv3 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" Instance ID.
The <Domain ID, Instance ID> tuple is used to determine whether an
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
same domain if both conditions below are met
1. A non-NULL incoming Domain ID matches either the local primary or
one of the secondary Domain IDs. If the local Domain ID and
incoming Domain ID are NULL, it is considered a match.
2. A non-NULL incoming Instance ID matches the local Instance ID. The Domain ID is used to determine whether an incoming VPN-IPv6 route
If the local Instance ID and incoming Instance ID are NULL, it is belongs to the same domain as the receiving OSPFv3 instance. An
considered a match. incoming VPN-IPv6 route is said to belong to the same domain if a
non-NULL incoming Domain ID matches either the local primary or one
of the secondary Domain IDs. If the local Domain ID and incoming
Domain ID are NULL, it is considered a match.
4.2. OSPFv3 Areas 4.2. OSPFv3 Areas
Sections 4.1.4 and 4.2.3 of [rfc4577] describe the characteristics of Sections 4.1.4 and 4.2.3 of [rfc4577] describe the characteristics of
a PE router within an OSPFv2 domain. The mechanisms and expected a PE router within an OSPFv2 domain. The mechanisms and expected
behavior described in [rfc4577] are applicable to an OSPFv3 domain. behavior described in [rfc4577] are applicable to an OSPFv3 domain.
4.3. VRFs and Routes 4.3. VRFs and Routes
From the perspective of the CE, the PE appears as any other OSPFv3 From the perspective of the CE, the PE appears as any other OSPFv3
skipping to change at page 8, line 33 skipping to change at page 7, line 45
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
Extended Communities attribute as described in [BGP-EXTCOMM-IPV6] may Extended Communities attribute as described in [rfc5701] may also be
also be attached to the route. attached to the route.
Domain IDs and Instance IDs are used to distinguish between OSPFv3 Domain IDs are used to distinguish between OSPFv3 instances. When an
instances. When an OSPFv3-distributed route is redistributed into OSPFv3 distributed route is redistributed into MP-BGP, the Domain ID,
MP-BGP, the Domain ID, OSPFv3 Router ID, Area, OSPFv3 Route Type, OSPFv3 Router ID, Area, OSPFv3 Route Type, and Options fields
External Route Type, Options fields, and Instance ID are also carried (External Route Type) are also carried in an attribute of the MP-BGP
in an attribute of the MP-BGP route. 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 9, line 49 skipping to change at page 9, line 11
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 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)
A Multi-Exit-Discriminator (MED) attribute SHOULD also be set to the A Multi-Exit-Discriminator (MED) attribute SHOULD also be set to the
skipping to change at page 11, line 14 skipping to change at page 10, line 22
When the PE sends an LSA to a CE, it sets the DN bit in the LSA to When the PE sends an LSA to a CE, it sets the DN bit in the LSA to
prevent looping. The DN bit is discussed in Section 4.5.1. prevent looping. The DN bit is discussed in Section 4.5.1.
4.3.2.1. OSPF Inter-Area Routes 4.3.2.1. OSPF Inter-Area Routes
A PE advertises an IPv6 route using an Inter-Area-Prefix (type A PE advertises an IPv6 route using an Inter-Area-Prefix (type
0x2003) LSA under the following circumstances: 0x2003) LSA under the following circumstances:
The OSPFv3 domain from which the IPv6 route was learned is the The OSPFv3 domain from which the IPv6 route was learned is the
same (as determined by the <Domain ID, Instance ID> tuple) as the same (as determined by the Domain ID) as the domain of the OSPFv3
domain of the OSPFv3 instance into which it is to be 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). numbers).
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 as an intra-area route using an Intra-Area-
an Intra-Area-Prefix (type 0x2009) LSA only when sham links are used, Prefix (type 0x2009) LSA only when sham links are used, as described
as described in Section 5. Otherwise routes are advertised as either in Section 5. Otherwise routes are advertised as either inter-area
inter-area (Section 4.3.2.1) or external (Sections 4.3.2.3) routes. (Section 4.3.2.1) or external/NSSA (Sections 4.3.2.3) routes.
4.3.2.3. OSPF External Routes And NSSA Routes 4.3.2.3. OSPF External Routes And NSSA Routes
A PE considers an IPv6 route to be external under the following A PE considers an IPv6 route to be external under the following
circumstances: circumstances:
The OSPFv3 domain from which the route was learned is different The OSPFv3 domain from which the route was learned is different
(as determined by the <Domain ID, Instance ID> tuple) from the (as determined by the Domain ID) from the domain of the OSPFv3
domain of the OSPFv3 instance into which it is redistributed; OR instance into which it is redistributed; OR
The OSPFv3 domain from which the route was learned is the same as The OSPFv3 domain from which the route was learned is the same as
the domain of the OSPFv3 instance into which it is redistributed the domain of the OSPFv3 instance into which it is redistributed
AND it was advertised to the remote PE in an AS-External (type AND it was advertised to the remote PE in an AS-External (type
0x4005) or a Type-7 (type 0x2007, NSSA) LSA; OR 0x4005) or a Type-7 (type 0x2007, NSSA) LSA; OR
The route was not learned from an OSPFv3 instance The route was not learned from an OSPFv3 instance
To determine if the learned route is from a different domain, the To determine if the learned route is from a different domain, the
<Domain ID, Instance ID> tuple associated with the VPN-IPv6 route (in Domain ID associated with the VPN-IPv6 route (in the OSPFv3 Route
the OSPFv3 Route Extended Communities attribute or attributes) is Extended Communities attribute or attributes) is compared with the
compared with the local OSPFv3 Domain ID and Instance ID, if local OSPFv3 Domain ID, if configured. Compared Domain IDs are
configured. Compared Domain IDs are considered identical if: 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 13, line 7 skipping to change at page 12, line 14
OSPFv2 case. OSPFv2 case.
All OSPFv3 routes added to the VRF routing table on a PE router are All OSPFv3 routes added to the VRF routing table on a PE router are
examined to create a corresponding VPN-IPv6 route in BGP. Each of examined to create a corresponding VPN-IPv6 route in BGP. Each of
the OSPFv3 routes MUST have a corresponding BGP Extended Community the OSPFv3 routes MUST have a corresponding BGP Extended Community
Attribute which contains and preserves the OSPFv3 information Attribute which contains and preserves the OSPFv3 information
attached to the 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 [rfc5701]. The OSPFv3 Route Extended Community Attribute has the
has the Sub-type value of 0x0004. It carries an OSPFv3 Domain ID, Sub-type value of 0x0004. It carries an OSPFv3 Domain ID, OSPFv3
OSPFv3 Router ID, OSPFv3 Area ID, OSPFv3 Route type, Options, and an Router ID, OSPFv3 Area ID, OSPFv3 Route type, and Options 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.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Router ID | | OSPF Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID | | Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type | Options |OSPF InstanceID| UNUSED | | Route Type | Options | UNUSED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OSPFv3 Route Extended Community Attribute The OSPFv3 Route Extended Community Attribute
This attribute is MANDATORY for all OSPFv3 routes in a VRF instance This attribute is MANDATORY for all OSPFv3 routes in a VRF instance
on a PE router. The fields of this new BGP Extended Community on a PE router. The fields of this new BGP Extended Community
attribute are described in the following sections. attribute are described in the following sections.
OSPFv3 Domain IDs field : 6 bytes OSPFv3 Domain IDs field : 6 bytes
Each OSPFv3 Instance within a VRF MUST have a Domain ID. The Each OSPFv3 Instance within a VRF MUST have a Domain ID. The
Domain ID may be configured at the VRF level or at the OSPFv3 Domain ID is configured per OSPFv3 Instance. The OSPFv3 Domain ID
Instance level. The OSPFv3 Domain ID is a 6-byte number and its is a 6-byte number and its default value is 0.
default value is 0.
OSPFv3 Router ID field : 4 bytes OSPFv3 Router ID field : 4 bytes
The OSPFv3 Router ID is a 32 bit number as in OSPFv2. Setting The OSPFv3 Router ID is a 32 bit number as in OSPFv2. Setting
this field is OPTIONAL and its default value is 0. this field is OPTIONAL and its default value is 0.
OSPFv3 Area ID : 4 bytes OSPFv3 Area ID : 4 bytes
The Area ID field indicates the 32-bit Area ID to which the route The Area ID field indicates the 32-bit Area ID to which the route
belongs. belongs.
OSPFv3 Route Types : 1 byte OSPFv3 Route Types : 1 byte
To accommodate OSPFv3 LSA types, the OSPF Route Type field is To accommodate OSPFv3 LSA types, the OSPF Route Type field is
encoded as follows: encoded as follows:
Route Type Route Type LSA Type Description Route Type Route Type LSA Type Description
Code Code
----------------------------------------------------------- -----------------------------------------------------------
0x30 Inter-area 0x2003 Inter-area-prefix-LSA 0x30 Inter-area 0x2003 Inter-area-prefix-LSA
0x50 External 0x2005 AS-external-LSA 0x50 External 0x4005 AS-external-LSA
0x70 NSSA 0x2007 NSSA-LSA 0x70 NSSA 0x2007 NSSA-LSA
0x90 Intra-area-prefix 0x2009 Intra-area-prefix-LSA 0x90 Intra-area-prefix 0x2009 Intra-area-prefix-LSA
The OSPFv3 Route Type Field Encoding The OSPFv3 Route Type Field Encoding
OSPFv3 Options : 1 byte OSPFv3 Route Options : 1 byte
The Options field indicates if the route carries a type-1 or The Options field indicates the options that are associated with
type-2 metric. Setting the least significant bit in the field the OSPFv3 route.
indicates that the route carries a External type-2 metric.
OSPFv3 Instance ID field : 1 byte 8 7 6 5 4 3 2 1
+---+---+---+---+---+---+---+---+
| | | | | | | | E |
+---+---+---+---+---+---+---+---+
The OSPFv3 Instance ID field is defined to carry the OSPFv3 The OSPFv3 Route Options Field
Instance ID which is a one-byte number. The OSPFv3 Instance ID is
configured for the "link" simulated by the MPLS VPN backbone. The least significant bit (i.e., bit E) in this field designates
This attribute MAY be present whether several OSPFv3 instances are the external metric type. If the bit is clear, the route carries
defined or not. The Instance ID default value is 0. a Type-1 external metric; if the bit is set, the route carries a
Type-2 external metric.
4.5. Loop Prevention Techniques 4.5. Loop Prevention Techniques
In some topologies, it is possible for routing loops to occur due to In some topologies, it is possible for routing loops to occur due to
the nature and manner of route reachability propagation. One such the nature and manner of route reachability propagation. One such
example is the case of a dual homed CE router connected to two PEs; example is the case of a dual homed CE router connected to two PEs;
those PE routers would receive this information both through their CE those PE routers would receive this information both through their 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.
skipping to change at page 15, line 9 skipping to change at page 14, line 17
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. As in [rfc4577], any LSA with the DN being re-advertised into BGP. As in [rfc4577], any LSA with the DN
bit set must not be used for route calculations. 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
skipping to change at page 16, line 27 skipping to change at page 15, line 40
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 a 32-bit number. Sham link endpoint addresses the RouterID, which is a 32-bit number. Sham link endpoint addresses
MUST be configured. MUST be configured.
Sham link endpoint addresses MUST be distributed by BGP as routeable Sham link endpoint addresses MUST be distributed by BGP as routeable
VPN IPv6 addresses whose IPv6 address prefix is 128 bits long. As VPN IPv6 addresses whose IPv6 address prefix is 128 bits long. As
specified in [rfc4577], these endpoint addresses MUST NOT be specified in section 4.2.7.1 of [rfc4577], these endpoint addresses
advertised by OSPFv3. MUST NOT be advertised by OSPFv3; if there is no BGP route to the
sham link endpoint address, that address is to appear unreachable, so
that the sham link appears to be down.
If there is a BGP route to the remote sham link endpoint address, the If there is a BGP route to the remote sham link endpoint address, the
sham link appears to be up. Conversely, if there is no BGP route to sham link appears to be up. Conversely, if there is no BGP route to
the sham link endpoint address, the sham link appears to be down. the sham link endpoint address, the sham link appears to be down.
5.1. Creating A Sham link 5.1. Creating A Sham link
The procedures for creating an OSPFv3 sham link are identical to The procedures for creating an OSPFv3 sham link are identical to
those specified in Section 4.2.7.2 of [rfc4577]. Note that the those specified in Section 4.2.7.2 of [rfc4577]. Note that the
creation of OSPFv3 sham links requires the configuration of both creation of OSPFv3 sham links requires the configuration of both
local and remote 128-bit sham link endpoint addresses. The local local and remote 128-bit sham link endpoint addresses. The local
Sham link endpoint address associated with a VRF MAY be used by all Sham link endpoint address associated with a VRF MAY be used by all
OSPFv3 instances that are attached to that VRF. The OSPFv3 PE-PE OSPFv3 instances that are attached to that VRF. The OSPFv3 PE-PE
"link" Instance ID is used to demultiplex multiple OSPFv3 instance "link" Instance ID in the protocol packet header is used to
protocol packets exchanged over the sham link. demultiplex multiple OSPFv3 instance 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
for OSPFv2. OSPFv3 sham links are treated as on demand circuits. for OSPFv2. OSPFv3 sham links are treated as on demand circuits.
skipping to change at page 17, line 22 skipping to change at page 16, line 37
For example, if two OSPFv3 instances (O1, O2) attach to a VRF V1, and For example, if two OSPFv3 instances (O1, O2) attach to a VRF V1, and
on a remote PE, two other OSPFv3 instances (O3, O4) attach to a VRF on a remote PE, two other OSPFv3 instances (O3, O4) attach to a VRF
V2, it may be desirable to connect, O1 and O3 with an intra-area V2, it may be desirable to connect, O1 and O3 with an intra-area
link, 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
Type 0x2009 intra-area-prefix LSAs, and the flooding of these LSAs
across the sham link. Furthermore, where prefixes associated with
OSPFv2 sham links are advertised in Type-1 LSAs, prefixes associated
with OSPFv3 sham links are advertised as OSPFv3 Type 0x2009 LSAs.
This change is required based on [rfc5340], which states that
loopback interfaces are advertised in intra-area-prefix LSAs.
5.3. OSPF Packet Forwarding On Sham Link 5.3. OSPF Packet Forwarding On Sham Link
The rules associated with route redistribution, stated in Section The rules associated with route redistribution, stated in Section
4.2.7.4 of [rfc4577], remain unchanged in this specification. 4.2.7.4 of [rfc4577], remain unchanged in this specification.
Specifically: Specifically:
If the next hop interface for a particular route is a sham link, If the next hop interface for a particular route is a sham link,
then the PE SHOULD NOT redistribute that route into BGP as a VPN- then the PE SHOULD NOT redistribute that route into BGP as a VPN-
IPv6 route. IPv6 route.
skipping to change at page 18, line 38 skipping to change at page 17, line 45
[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].
8. 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 [rfc5701]. This document makes the following assignments in the
in the "IPv6 Address Specific Extended Community" registry. "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
This document also defines a new "OSPFv3 Route Attribute Options"
registry. Represented by 8 bits, the new registry documents the
contents of the Options field in the OSPFv3 Route Attributes Extended
Community. This document makes the following assignment in the
"OSPFv3 Route Attribute Options" registry.
Value Description Reference
----- ----------- ---------
0x01 External Metric Type [rfcThis]
OSPFv3 Route Attribute Options
Following the policies outlined in [RFC5226], the IANA policy for
assigning the remaining bits for the "OSPFv3 Route Attribute Options"
registry shall be "Standards Action": values are assigned only for
Standards Track RFCs approved by the IESG.
9. Contributors 9. Contributors
Joe Lapolito Joe Lapolito
10. Acknowledgments 10. Acknowledgments
The authors would like to thank Kelvin Upson, Seiko Okano, Matthew The authors would like to thank Kelvin Upson, Seiko Okano, Matthew
Everett, and Dr. Vineet Mehta for their support of this work. Everett, and Dr. Vineet Mehta for their support of this work. Thanks
to Peter Psenak, Abhay Roy and Acee Lindem for their last call
comments.
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
Indicate Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119, March 1997.
March 1997.
[rfc2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26,
RFC 5226, May 2008.
[rfc2858] Bates, T., Rehkter, Y., Chandra, R., and D. Katz, [rfc2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
"Multiprotocol Extensions for BGP-4", RFC 2858,
June 2000.
[rfc4360] Sangli, S., Tappan, D., and Y. Rehkter, "BGP [rfc2858] Bates, T., Rehkter, Y., Chandra, R., and D. Katz,
Extended Communities Attribute", RFC 4360, "Multiprotocol Extensions for BGP-4", RFC 2858,
February 2006. June 2000.
[rfc4364] Rosen, E. and Y. Rehkter, "BGP/MPLS IP Virtual [rfc4360] Sangli, S., Tappan, D., and Y. Rehkter, "BGP Extended
Private Networks (VPNs)", RFC 4364, Communities Attribute", RFC 4360, February 2006.
February 2006.
[rfc4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, [rfc4364] Rosen, E. and Y. Rehkter, "BGP/MPLS IP Virtual Private
"Using a Link State Advertisement (LSA) Options Networks (VPNs)", RFC 4364, February 2006.
Bit to Prevent Looping in BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC 4576, June 2006.
[rfc4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, [rfc4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a
"OSPF as the Provider/Customer Edge Protocol for Link State Advertisement (LSA) Options Bit to Prevent
BGP/MPLS IP Virtual Private Networks (VPNs)", Looping in BGP/MPLS IP Virtual Private Networks
RFC 4577, June 2006. (VPNs)", RFC 4576, June 2006.
[rfc4659] De Clercq, J., Ooms, D., Carugi, M., and F. [rfc4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as
Lefaucheur, "BGP-MPLS IP Virtual Private Network the Provider/Customer Edge Protocol for BGP/MPLS IP
(VPN) Extension for IPv6 VPN", RFC 4659, Virtual Private Networks (VPNs)", RFC 4577, June 2006.
September 2006.
[rfc5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, [rfc4659] De Clercq, J., Ooms, D., Carugi, M., and F.
"OSPF for IPv6", RFC 5340, July 2008. Lefaucheur, "BGP-MPLS IP Virtual Private Network (VPN)
Extension for IPv6 VPN", RFC 4659, September 2006.
11.2. Informative References [rfc5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem,
"OSPF for IPv6", RFC 5340, July 2008.
[BGP-EXTCOMM-IPV6] Rehkter, Y., "IPv6 Address Specific BGP Extended [rfc5701] Rehkter, Y., "IPv6 Address Specific BGP Extended
Communities Attribute", October 2008, <http:// Communities Attribute", November 2009.
www.ietf.org/internet-drafts/
draft-rekhter-v6-ext-communities-03.txt>.
[OSPF-AF-ALT] Mirtorabi, S., Roy, A., Barnes, M., Aggarwal, R., 11.2. Informative References
and A. Lindem, "Support of address families in
OSPFv3", October 2008, <http://www.ietf.org/
internet-drafts/draft-ietf-ospf-af-alt-07.txt>.
[rfc2547] Rosen, E. and Y. Rehkter, "BGP/MPLS VPNs", [OSPF-AF-ALT] Mirtorabi, S., Roy, A., Barnes, M., Aggarwal, R., and
RFC 2547, March 1999. A. Lindem, "Support of address families in OSPFv3",
December 2009, <http://www.ietf.org/internet-drafts/
draft-ietf-ospf-af-alt-10.txt>.
[rfc2547] Rosen, E. and Y. Rehkter, "BGP/MPLS VPNs", RFC 2547,
March 1999.
Authors' Addresses Authors' Addresses
Padma Pillay-Esnault Padma Pillay-Esnault
Cisco Systems Cisco Systems
510 McCarty Blvd 510 McCarty Blvd
Milpitas, CA 95035 Milpitas, CA 95035
USA USA
EMail: ppe@cisco.com EMail: ppe@cisco.com
 End of changes. 50 change blocks. 
167 lines changed or deleted 141 lines changed or added

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