draft-ietf-l3vpn-ospfv3-pece-06.txt   draft-ietf-l3vpn-ospfv3-pece-07.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: March 13, 2011 Pollere, Inc Expires: September 13, 2011 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
September 9, 2010 March 12, 2011
OSPFv3 as a PE-CE routing protocol OSPFv3 as a PE-CE routing protocol
draft-ietf-l3vpn-ospfv3-pece-06 draft-ietf-l3vpn-ospfv3-pece-07
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 16 skipping to change at page 2, line 16
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 13, 2011. This Internet-Draft will expire on September 13, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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 19 skipping to change at page 3, line 19
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 Identifier . . . . . . . . . . . . . . . 6 4.1.2. OSPFv3 Domain Identifier . . . . . . . . . . . . . . . 6
4.2. OSPFv3 Areas . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. OSPFv3 Areas . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. VRFs and Routes . . . . . . . . . . . . . . . . . . . . . 7 4.3. VRFs and Routes . . . . . . . . . . . . . . . . . . . . . 7
4.3.1. OSPFv3 Routes on PE . . . . . . . . . . . . . . . . . 8 4.3.1. OSPFv3 Routes on PE . . . . . . . . . . . . . . . . . 8
4.3.2. VPN-IPv6 Routes Received from MP-BGP . . . . . . . . . 9 4.3.2. VPN-IPv6 Routes Received from MP-BGP . . . . . . . . . 9
4.4. OSPFv3 Route Extended Communities Attribute . . . . . . . 11 4.4. BGP Extended Communities Attribute . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . 14
4.5.2. Other Possible Loops . . . . . . . . . . . . . . . . . 14 4.5.2. Other Possible Loops . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
[rfc4364] offers Service Providers (SPs) a method for providing [rfc4364] offers Service Providers (SPs) a method for providing
Layer-3 Virtual Private Network (VPN) services to subtending customer Layer-3 Virtual Private Network (VPN) services to subtending customer
skipping to change at page 5, line 30 skipping to change at page 5, line 30
Section 2.0 of [rfc5340] describes differences between OSPFv3 and Section 2.0 of [rfc5340] describes differences between OSPFv3 and
OSPFv2. Several of these changes will require modifications to the OSPFv2. Several of these changes will require modifications to the
architecture described in [rfc4577]. These differences and their architecture described in [rfc4577]. These differences and their
corresponding impact to [rfc4577] are described below: corresponding impact to [rfc4577] are described below:
New LSA types: New LSA types:
For an IPv6 MPLS/VPN architecture where customers interface to For an IPv6 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 AS-External OSPFv3 LSAs. Instead, it
it may be desirable to view these LSAs as inter-area-prefix LSAs. may be desirable to view these LSAs as inter-area-prefix LSAs.
For the encoding of OSPFv3 LSAs, a new OSPFv3 Route Extended The OSPF Route Type Extended Communities attribute defined in
Community attribute is defined in Section 4.4. [rfc4577] is extended to include OSPFv3 route types. These new
encodings are defined in Section 4.4.
Multiple instances over a link: Multiple instances over a link:
OSPFv3 operates on a per-link basis as opposed to OSPFv2, which OSPFv3 operates on a per-link basis as opposed to OSPFv2, which
operates on a per-IP-subnet basis. The support of multiple OSPFv3 operates on a per-IP-subnet basis. The support of multiple OSPFv3
protocol instances on a link changes the architecture described in protocol instances on a link changes the architecture described in
[rfc4577]. [rfc4577] specifies that each interface belongs to no [rfc4577]. [rfc4577] specifies that each interface belongs to no
more than one OSPF instance. For OSPFv3, multiple instances can more than one OSPF instance. For OSPFv3, multiple instances can
be established over a single interface, and associated with the be established over a single interface, and associated with the
same VRF. same VRF.
skipping to change at page 7, line 44 skipping to change at page 7, line 44
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].
Extended Communities attribute as described in [rfc5701] may also be
attached to the route.
Domain IDs are used to distinguish between OSPFv3 instances. When an Domain IDs are used to distinguish between OSPFv3 instances. When an
OSPFv3 distributed route is redistributed into MP-BGP, the Domain ID, OSPFv3 distributed route is redistributed into MP-BGP, the Domain ID,
OSPFv3 Router ID, Area, OSPFv3 Route Type, and Options fields OSPFv3 Router ID, Area, OSPFv3 Route Type, and Options fields
(External Route Type) are also carried in an attribute of the MP-BGP (External Route Type) are also carried in Extended Community
route. Attributes of the MP-BGP route.
A PE receiving a VPN-IPv6 NLRI from MP-BGP uses an import policy to A PE receiving a VPN-IPv6 NLRI from MP-BGP uses an import policy to
determine, based on the RT, whether the route is eligible to be determine, based on the RT, whether the route is eligible to be
installed in one of its local VRFs. The BGP decision process selects installed in one of its local VRFs. The BGP decision process selects
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
configuration. For example, the PE might be configured to advertise configuration. For example, the PE might be configured to advertise
only a default route to CEs of a particular OSPFv3 instance. only a default route to CEs of a particular OSPFv3 instance.
Further, if the route is to be redistributed into multiple OSPFv3 Further, if the route is to be redistributed into multiple OSPFv3
instances, the route might be advertised using different LSA types in instances, the route might be advertised using different LSA types in
different instances. different instances.
If an IPv6 route learned from MP-BGP is to be redistributed into a If an IPv6 route learned from MP-BGP is to be redistributed into a
particular OSPFv3 instance, the OSPFv3 Route Extended Community particular OSPFv3 instance, the OSPF Domain Identifier Extended
attribute (Section 4.4) of the VPN-IPv6 route is used to determine Communities attribute of the VPN-IPv6 route is used to determine
whether the OSPFv3 instance from which the route was learned is the whether the OSPFv3 instance from which the route was learned is the
same as the OSPFv3 instance into which the route is to be same as the OSPFv3 instance into which the route is to be
redistributed. redistributed.
4.3.1. OSPFv3 Routes on PE 4.3.1. OSPFv3 Routes on 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 MP-BGP. OSPFv3 routes are installed in a routes from other PEs via MP-BGP. OSPFv3 routes are installed in a
VRF using the OSPFv3 decision process. As described in [rfc4577], VRF using the OSPFv3 decision process. They may be redistributed
OSPFv2 routes installed in a VRF may be redistributed into BGP and into BGP and disseminated to other PEs participating in the VPN. At
disseminated to other PEs participating in the VPN. At these remote these remote PEs, the VPN-IPv6 routes may be imported into a VRF and
PEs, the VPN-IPv6 routes may be imported into a VRF and redistributed 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 an import RT that is
the route's RT. For routes which are eligible to be imported into identical to the route's RT. For routes which are eligible to be
the VRF, the standard BGP decision process is used to choose the imported into the VRF, the standard BGP decision process is used to
"best" route(s). choose the "best" route(s).
When a route is advertised from a CE to a PE via OSPFv3 and that When a route is advertised from a CE to a PE via OSPFv3 and that
route is installed in the VRF associated with the CE, the route is route is installed in the VRF associated with the CE, the route is
advertised to other locally attached CEs under normal OSPFv3 advertised to other locally attached CEs under normal OSPFv3
procedures. procedures.
The route is also redistributed into MP-BGP to be advertised to The route is also redistributed into MP-BGP to be advertised to
remote PEs. The information necessary for accurate redistribution remote PEs. The information necessary for accurate redistribution
back into OSPFv3 by the remote PEs is carried in an OSPFv3 Route back into OSPFv3 by the remote PEs is carried in the OSPF Route Type,
Extended Communities attribute (Section 4.4). The relevant local OSPF Domain ID, and OSPF Router ID Extended Communities attributes
OSPFv3 information encoded into the attribute is: (Section 4.4). The relevant local OSPFv3 information encoded into
these attributes are:
The Domain ID of the local OSPFv3 process. If no Domain ID is
configured, the NULL identifier is used.
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 Type, as determined by the LSA type from which the route The Route Type, as determined by the LSA type from which the route
was learned. was learned.
The Options fields (External metric-type) The Options fields (External metric-type)
The Domain ID of the OSPFv3 process. If no Domain ID is
configured, the NULL identifier is used.
The PE's Router ID associated with the OSPFv3 instance.
A Multi-Exit-Discriminator (MED) attribute SHOULD also be set to the A Multi-Exit-Discriminator (MED) attribute SHOULD also be set to the
value of the OSPFv3 distance associated with the route plus 1, when value of the OSPFv3 distance associated with the route plus 1, when
the OSPFv3 route is redistributed into the MP-BGP. 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
skipping to change at page 10, line 28 skipping to change at page 10, line 28
A PE advertises an IPv6 route using an Inter-Area-Prefix (type A PE advertises an IPv6 route using an Inter-Area-Prefix (type
0x2003) LSA under the following circumstances: 0x2003) LSA under the following circumstances:
The OSPFv3 domain from which the IPv6 route was learned is the The OSPFv3 domain from which the IPv6 route was learned is the
same (as determined by the Domain ID) as the domain of the OSPFv3 same (as determined by the Domain ID) as the domain of the OSPFv3
instance into which it is to be redistributed; AND instance into which it is to be redistributed; AND
The IPv6 route was advertised to a remote PE in an Intra-Area- The IPv6 route was advertised to a remote PE in an Intra-Area-
Prefix (type 0x2009) OR an Inter-Area-Prefix (type 0x2003) LSA. Prefix (type 0x2009) OR an Inter-Area-Prefix (type 0x2003) LSA.
Note that under these rules the PE represents itself as an ABR Note that under these rules the PE represents itself as an Area
regardless of whether or not the route is being advertised into the Border Router (ABR) regardless of whether or not the route is being
same area number from which the remote PE learned it (that is, advertised into the same area number from which the remote PE learned
whether the VPN-IPv6 route carries the same or different area it (that is, whether the VPN-IPv6 route carries the same or different
numbers). area numbers).
4.3.2.2. OSPF Intra-Area Route 4.3.2.2. OSPF Intra-Area Route
A route is advertised as an intra-area route using an Intra-Area- A route is advertised as an intra-area route using an Intra-Area-
Prefix (type 0x2009) LSA only when sham links are used, as described Prefix (type 0x2009) LSA only when sham links are used, as described
in Section 5. Otherwise routes are advertised as either inter-area in Section 5. Otherwise routes are advertised as either inter-area
(Section 4.3.2.1) or external/NSSA (Sections 4.3.2.3) routes. (Section 4.3.2.1) or external/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
skipping to change at page 11, line 10 skipping to change at page 11, line 10
instance into which it is redistributed; OR instance into which it is redistributed; OR
The OSPFv3 domain from which the route was learned is the same as The OSPFv3 domain from which the route was learned is the same as
the domain of the OSPFv3 instance into which it is redistributed the domain of the OSPFv3 instance into which it is redistributed
AND it was advertised to the remote PE in an AS-External (type AND it was advertised to the remote PE in an AS-External (type
0x4005) or a Type-7 (type 0x2007, NSSA) LSA; OR 0x4005) or a Type-7 (type 0x2007, NSSA) LSA; OR
The route was not learned from an OSPFv3 instance The route was not learned from an OSPFv3 instance
To determine if the learned route is from a different domain, the To determine if the learned route is from a different domain, the
Domain ID associated with the VPN-IPv6 route (in the OSPFv3 Route Domain ID associated with the VPN-IPv6 route (in the OSPF Domain ID
Extended Communities attribute or attributes) is compared with the Extended Communities attribute or attributes) is compared with the
local OSPFv3 Domain ID, if configured. Compared Domain IDs are local OSPFv3 Domain ID, if configured. Compared Domain IDs are
considered identical if: considered identical if:
1. All 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
skipping to change at page 11, line 33 skipping to change at page 11, line 33
An IPv6 route that is determined to be external might or might not be An IPv6 route that is determined to be external might or might not be
advertised to a connected CE, depending on the type of area to which advertised to a connected CE, depending on the type of area to which
the PE-CE link belongs and whether there is a configured policy the PE-CE link belongs and whether there is a configured policy
restricting its advertisement. restricting its advertisement.
If there are multiple external routes to the same prefix, the If there are multiple external routes to the same prefix, the
standard OSPFv3 decision process is used to select the "best" route. standard OSPFv3 decision process is used to select the "best" route.
If the external route is to be advertised and the area type of the If the external route is to be advertised and the area type of the
PE/CE link is NSSA, the PE advertises the route in a Type-7 (type PE-CE link is NSSA, the PE advertises the route in 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.
If the VPN-IPv6 route indicates a route type-1 metric, the PE If the VPN-IPv6 route indicates a route type-1 metric, the PE
advertises the external route with that metric-type; otherwise the advertises the external route with that metric-type; otherwise the
metric-type of the external IPv6 route is set to type-2 by default. metric-type of the external IPv6 route is set to type-2 by default.
4.4. OSPFv3 Route Extended Communities Attribute 4.4. BGP 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.
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 corresponding the BGP Extended
Attribute which contains and preserves the OSPFv3 information Communities Attributes which contain and preserve the OSPFv3
attached to the original OSPFv3 route. information of the original OSPFv3 route. The BGP Extended
Communities attributes defined in [rfc4577] are reused for
convenience.
This document defines a new BGP attribute in the proposed "IPv6 OSPF Domain Identifier Extended Communities Attribute
Address Specific Extended Community" registry described in Section 3
of [rfc5701]. The OSPFv3 Route Extended Community Attribute has the Each OSPFv3 Instance within a VRF MUST have a Domain ID. The Domain
Sub-type value of 0x0004. It carries an OSPFv3 Domain ID, OSPFv3 ID is configured per OSPFv3 Instance. The OSPFv3 Domain ID is a
Router ID, OSPFv3 Area ID, OSPFv3 Route type, and Options field. 6-byte number and its default value is 0. This attribute has a two
byte type field, encoded with a value of 0x0005, 0x0105, or 0x0205.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 4 | OSPF Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Domain ID (Cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID | | Type Value | Domain Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type | Options | UNUSED | | Domain Identifier Cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OSPFv3 Route Extended Community Attribute The OSPF Domain Identifier Extended Communities Attribute
This attribute is MANDATORY for all OSPFv3 routes in a VRF instance
on a PE router. The fields of this new BGP Extended Community
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 and its
Domain ID is configured per OSPFv3 Instance. The OSPFv3 Domain ID default value (if none is configured) is 0. The Domain ID is
is a 6-byte number and its default value is 0. configured per OSPFv3 Instance.
OSPF Router ID Extended Communities Attribute
The OSPFv3 Router ID is a 32-bit number as in OSPFv2. This attribute
has a two byte type field, encoded with a value of 0x0107.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Value | Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID Cont. | UNUSED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OSPF Router ID Extended Communities Attribute
OSPFv3 Router ID field : 4 bytes OSPFv3 Router ID field : 4 bytes
The OSPFv3 Router ID is a 32 bit number as in OSPFv2. Setting The OSPFv3 Router ID is a 32 bit number as in OSPFv2. Setting
this field is OPTIONAL and its default value is 0. this field is OPTIONAL and its default value is 0.
OSPFv3 Area ID : 4 bytes OSPF Route Type Extended Communities Attribute
The Area ID field indicates the 32-bit Area ID to which the route The OSPF Route Type Extended Communities attribute MUST be present.
It contains a two byte type field, encoded with a value of 0x0306.
The remaining six bytes are divided into three fields, an Area
Number, a Route Type, and an Options field
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Value | Area Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area Number Cont. | Route Type | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OSPF Route Type Extended Communities Attribute
Area Number : 4 bytes
The area number indicates the 32-bit Area ID to which the route
belongs. belongs.
OSPFv3 Route Types : 1 byte Route Types : 1 byte
To accommodate OSPFv3 LSA types, the OSPF Route Type field is To accommodate OSPFv3 LSA types, the Route Type field is encoded
encoded as follows: 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 3 Inter-area 0x2003 Inter-area-prefix-LSA
0x50 External 0x4005 AS-external-LSA 5 External 0x4005 AS-external-LSA
0x70 NSSA 0x2007 NSSA-LSA 7 NSSA 0x2007 NSSA-LSA
0x90 Intra-area-prefix 0x2009 Intra-area-prefix-LSA 1 or 2 Intra-area-prefix 0x2009 Intra-area-prefix-LSA
The OSPFv3 Route Type Field Encoding Route Type Field Encoding
OSPFv3 Route Options : 1 byte Options : 1 byte
The Options field indicates the options that are associated with The Options field indicates the options that are associated with
the OSPFv3 route. the OSPFv3 route.
8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | | | | | | E | | | | | | | | | E |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
The OSPFv3 Route Options Field The OSPFv3 Route Options Field
skipping to change at page 13, line 47 skipping to change at page 14, line 22
The least significant bit (i.e., bit E) in this field designates The least significant bit (i.e., bit E) in this field designates
the external metric type. If the bit is clear, the route carries the external metric type. If the bit is clear, the route carries
a Type-1 external metric; if the bit is set, the route carries a a Type-1 external metric; if the bit is set, the route carries a
Type-2 external metric. Type-2 external metric.
4.5. Loop Prevention Techniques 4.5. Loop Prevention Techniques
In some topologies, it is possible for routing loops to occur due to In some topologies, it is possible for routing loops to occur due to
the nature and manner of route reachability propagation. One such the nature and manner of route reachability propagation. One such
example is the case of a dual homed CE router connected to two PEs; example is the case of a dual homed CE router connected to two PEs;
those PE routers would receive this information both through their CE those PE routers would receive reachability information both through
and their peer PE. As there is transparent transport of OSPFv3 their CE and their peer PE. As there is transparent transport of
routes over the BGP/MPLS backbone, it is not possible for the PE OSPFv3 routes over the BGP/MPLS backbone, it is not possible for the
routers to determine whether they are within a loop. PE 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. 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 on PE routers.
The DN bit MUST be clear in all other LSA types. The OSPFv3 DN-bit The DN bit MUST be clear in all other LSA types. The OSPFv3 DN-bit
format is described in Appendix 4.1.1 of [rfc5340]. format is described in Appendix 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
skipping to change at page 17, line 4 skipping to change at page 17, line 20
If the next hop interface for a particular route is a sham link, If the next hop interface for a particular route is a sham link,
then the PE SHOULD NOT redistribute that route into BGP as a VPN- then the PE SHOULD NOT redistribute that route into BGP as a VPN-
IPv6 route. IPv6 route.
Any other route advertised in an LSA that is transmitted over a Any other route advertised in an LSA that is transmitted over a
sham link MUST also be redistributed (by the PE flooding the LSA sham link MUST also be redistributed (by the PE flooding the LSA
over the sham link) into BGP. over the sham link) into BGP.
When redistributing these LSAs into BGP, they are encoded with the When redistributing these LSAs into BGP, they are encoded with the
OSPFv3 Route Extended Community, as defined in Section 4.4 of this BGP Extended Communities Attributes, as defined in Section 4.4 of
document. this document.
When forwarding a packet, if the preferred route for that packet has When forwarding a packet, if the preferred route for that packet has
the sham link as its next hop interface, then the packet MUST be the sham link as its next hop interface, then the packet MUST be
forwarded according to the corresponding BGP route (as defined in forwarded according to the corresponding BGP route (as defined in
[rfc4364] and [rfc4659]). [rfc4364] and [rfc4659]).
6. Multiple Address Family Support 6. Multiple Address Family Support
The support of multiple address families (AF) in OSPFv3 is described The support of multiple address families (AF) in OSPFv3 is described
in [RFC5838]. [RFC5838] differentiates between AF using reserved in [RFC5838]. [RFC5838] differentiates between AF using reserved
ranges of Instance IDs for each AF. ranges of Instance IDs for each AF.
The architecture described in this document is fully compatible with The architecture described in this document is fully compatible with
[RFC5838]. The OSPFv3 PE-CE protocol can support multiple address [RFC5838]. The OSPFv3 PE-CE protocol can support multiple address
families across a MPLS VPN backbone. All AFs redistributed from families across a MPLS VPN backbone. All AFs redistributed from
OSPFv3 into BGP on a PE MUST contain the OSPFv3 Route Extended OSPFv3 into BGP on a PE MUST contain the BGP Extended Communities
Community Attribute. Attributes as described in Section 4.4.
Note that since [RFC5838] does not support multiple AFs across
virtual links, this document only addresses support for unicast IPv6
addresses across the sham link.
7. Security Considerations 7. Security Considerations
The extensions described in this document are specific to the use of The extensions described in this document are specific to the use of
OSPFv3 as the PE-CE protocol and do not introduce any concerns OSPFv3 as the PE-CE protocol and do not introduce any 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].
8. IANA Considerations 8. IANA Considerations
This document defines a new BGP attribute in the proposed "IPv6 The BGP Extended Communities Attributes in this document are already
Address Specific Extended Community" registry described in Section 3 referenced in IANA.
of [rfc5701]. This document makes the following assignments in the
"IPv6 Address Specific Extended Community" registry.
Name Sub-type Value
---- --------------
OSPFv3 Route Attributes 0x0004
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. Thanks Everett, Dr. Vineet Mehta, Paul Wells and Marek Karasek for their
to Peter Psenak, Abhay Roy and Acee Lindem for their last call support of this work. Thanks to Peter Psenak, Abhay Roy and Acee
comments. 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 Indicate [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5838] Mirtorabi, S., Roy, A., Barnes, M., Aggarwal, R., and A. [RFC5838] Mirtorabi, S., Roy, A., Barnes, M., Aggarwal, R., and A.
Lindem, "Support of address families in OSPFv3", Lindem, "Support of address families in OSPFv3",
April 2010. April 2010.
[rfc2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [rfc2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[rfc2858] Bates, T., Rehkter, Y., Chandra, R., and D. Katz, [rfc2858] Bates, T., Rehkter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[rfc4360] Sangli, S., Tappan, D., and Y. Rehkter, "BGP Extended [rfc4360] Sangli, S., Tappan, D., and Y. Rehkter, "BGP Extended
skipping to change at page 19, line 32 skipping to change at page 19, line 12
Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Provider/Customer Edge Protocol for BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC 4577, June 2006. Private Networks (VPNs)", RFC 4577, June 2006.
[rfc4659] De Clercq, J., Ooms, D., Carugi, M., and F. Lefaucheur, [rfc4659] De Clercq, J., Ooms, D., Carugi, M., and F. Lefaucheur,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for "BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", RFC 4659, September 2006. IPv6 VPN", RFC 4659, September 2006.
[rfc5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [rfc5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, July 2008.
[rfc5701] Rehkter, Y., "IPv6 Address Specific BGP Extended
Communities Attribute", November 2009.
11.2. Informative References 11.2. Informative References
[rfc2547] Rosen, E. and Y. Rehkter, "BGP/MPLS VPNs", RFC 2547, [rfc2547] Rosen, E. and Y. Rehkter, "BGP/MPLS VPNs", RFC 2547,
March 1999. March 1999.
Authors' Addresses Authors' Addresses
Padma Pillay-Esnault Padma Pillay-Esnault
Cisco Systems Cisco Systems
510 McCarty Blvd 510 McCarty Blvd
 End of changes. 45 change blocks. 
133 lines changed or deleted 121 lines changed or added

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