draft-ietf-l3vpn-ospfv3-pece-07.txt   draft-ietf-l3vpn-ospfv3-pece-08.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: September 13, 2011 Pollere, Inc Expires: January 13, 2012 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
March 12, 2011 July 12, 2011
OSPFv3 as a PE-CE routing protocol OSPFv3 as a PE-CE routing protocol
draft-ietf-l3vpn-ospfv3-pece-07 draft-ietf-l3vpn-ospfv3-pece-08
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 September 13, 2011. This Internet-Draft will expire on January 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
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. BGP Extended Communities Attribute . . . . . . . . . . . . 11 4.4. BGP Extended Communities Attribute . . . . . . . . . . . . 12
4.5. Loop Prevention Techniques . . . . . . . . . . . . . . . . 14 4.5. Loop Prevention Techniques . . . . . . . . . . . . . . . . 14
4.5.1. OSPFv3 Down Bit . . . . . . . . . . . . . . . . . . . 14 4.5.1. OSPFv3 Down Bit . . . . . . . . . . . . . . . . . . . 14
4.5.2. Other Possible Loops . . . . . . . . . . . . . . . . . 14 4.5.2. Other Possible Loops . . . . . . . . . . . . . . . . . 15
5. OSPFv3 Sham Links . . . . . . . . . . . . . . . . . . . . . . 15 5. OSPFv3 Sham Links . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Creating A Sham link . . . . . . . . . . . . . . . . . . . 16 5.1. Creating A Sham link . . . . . . . . . . . . . . . . . . . 16
5.2. OSPF Protocol On Sham link . . . . . . . . . . . . . . . . 16 5.2. OSPF Protocol On Sham link . . . . . . . . . . . . . . . . 16
5.3. OSPF Packet Forwarding On Sham Link . . . . . . . . . . . 17 5.3. OSPF Packet Forwarding On Sham Link . . . . . . . . . . . 17
6. Multiple Address Family Support . . . . . . . . . . . . . . . 17 6. Multiple Address Family Support . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
skipping to change at page 9, line 20 skipping to change at page 9, line 20
was learned. was learned.
The Options fields (External metric-type) The Options fields (External metric-type)
The Domain ID of the OSPFv3 process. If no Domain ID is The Domain ID of the OSPFv3 process. If no Domain ID is
configured, the NULL identifier is used. configured, the NULL identifier is used.
The PE's Router ID associated with the OSPFv3 instance. The PE's Router ID associated with the OSPFv3 instance.
A Multi-Exit-Discriminator (MED) attribute SHOULD also be set to the A Multi-Exit-Discriminator (MED) attribute SHOULD also be set to the
value of the OSPFv3 distance associated with the route plus 1, when value of the OSPFv3 metric associated with the route plus 1, when the
the OSPFv3 route is redistributed into the MP-BGP. OSPFv3 route is redistributed into the MP-BGP.
4.3.2. VPN-IPv6 Routes Received from MP-BGP 4.3.2. VPN-IPv6 Routes Received from MP-BGP
When a PE receives a valid VPN-IPv6 route from MP-BGP and has When a PE receives a valid VPN-IPv6 route from MP-BGP and has
identified an association with a local VRF, it must determine: identified an association with a local VRF, it must determine:
Whether a route to the corresponding IPv6 prefix is to be Whether a route to the corresponding IPv6 prefix is to be
installed in the VRF; installed in the VRF;
Whether the installed IPv6 route is to be redistributed to one or Whether the installed IPv6 route is to be redistributed to one or
skipping to change at page 10, line 7 skipping to change at page 10, line 7
A configured import policy prohibits the installation of the route A configured import policy prohibits the installation of the route
The PE advertises the IPv6 route learned from MP-BGP to attached CEs The PE advertises the IPv6 route learned from MP-BGP to attached CEs
via OSPFv3 if: via OSPFv3 if:
No configured filtering prohibits redistributing the route to No configured filtering prohibits redistributing the route to
OSPFv3 OSPFv3
No configured policy blocks the route in favor of a less-specific No configured policy blocks the route in favor of a less-specific
summary route summary route
No OSPFv3 route to the same prefix exists in the VRF. Redistribution of a BGP learned IPv6 route into OSPF is based on
local policy.
The subsequent sections discuss the advertisement of routes learned The subsequent sections discuss the advertisement of routes learned
from MP-BGP, and the rules for determining what LSA types and what from MP-BGP, and the rules for determining what LSA types and what
CEs to advertise the routes to. CEs to advertise the routes to.
When the PE sends an LSA to a CE, it sets the DN bit in the LSA to When the PE sends an LSA to a CE, it sets the DN bit in the LSA to
prevent looping. The DN bit is discussed in Section 4.5.1. prevent looping. The DN bit is discussed in Section 4.5.1.
4.3.2.1. OSPF Inter-Area Routes 4.3.2.1. OSPF Inter-Area Routes
skipping to change at page 11, line 15 skipping to change at page 11, line 17
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 OSPF Domain ID Domain ID associated with the VPN-IPv6 route (in the OSPF Domain ID
Extended Communities attribute or attributes) is compared with the Extended Communities attribute or attributes) is compared with the
local OSPFv3 Domain ID, if configured. Compared Domain IDs are local OSPFv3 Domain ID, if configured. Compared Domain IDs are
considered identical if: considered identical if:
1. All six bytes are identical; or 1. All eight 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.
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
skipping to change at page 11, line 40 skipping to change at page 11, line 42
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 should
advertises the external route with that metric-type; otherwise the advertise the external route with that metric-type; otherwise the
metric-type of the external IPv6 route is set to type-2 by default. metric-type of the external IPv6 route is set to type-2 by default.
Note that by default, a PE should advertise an external route with a
type-2 metric if the IPv6 route's Domain ID is different than the
local OSPFv3 instance, unless specified otherwise by local policy.
4.4. BGP 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.
skipping to change at page 18, line 18 skipping to change at page 18, line 26
referenced in IANA. referenced in IANA.
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, Dr. Vineet Mehta, Paul Wells and Marek Karasek for their Everett, Dr. Vineet Mehta, Paul Wells and Marek Karasek for their
support of this work. Thanks to Peter Psenak, Abhay Roy and Acee support of this work. Thanks to Peter Psenak, Abhay Roy, Acee
Lindem for their last call comments. Lindem, Nick Weeds and Robert Hanzl 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.
 End of changes. 12 change blocks. 
14 lines changed or deleted 18 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/