draft-ietf-ospf-2547-dnbit-04.txt   rfc4576.txt 
Network Working Group Eric C. Rosen Network Working Group E. Rosen
Internet Draft Peter Psenak Request for Comments: 4576 P. Psenak
Expiration Date: September 2004 Cisco Systems, Inc. Category: Standards Track P. Pillay-Esnault
Cisco Systems, Inc.
Padma Pillay-Esnault
Juniper Networks, Inc.
Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs
draft-ietf-ospf-2547-dnbit-04.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with Using a Link State Advertisement (LSA) Options Bit to
all provisions of Section 10 of RFC2026. Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet-Drafts as reference improvements. Please refer to the current edition of the "Internet
material or to cite them other than as "work in progress." Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2006).
http://www.ietf.org/shadow.html.
Abstract Abstract
This document specifies a procedure that deals with a particular This document specifies a procedure that deals with a particular
issue that may arise when a Service Provider (SP) provides "BGP/MPLS issue that may arise when a Service Provider (SP) provides "BGP/MPLS
IP VPN" service to a customer, and the customer uses OSPFv2 to IP VPN" service to a customer and the customer uses OSPFv2 to
advertise its routes to the SP. In this situation, a Customer Edge advertise its routes to the SP. In this situation, a Customer Edge
(CE) Router and a Provider Edge (PE) Router are OSPF peers, and (CE) Router and a Provider Edge (PE) Router are OSPF peers, and
customer routes are sent via OSPFv2 from the CE to the PE. The customer routes are sent via OSPFv2 from the CE to the PE. The
customer routes are converted into BGP routes, and BGP carries them customer routes are converted into BGP routes, and BGP carries them
across the backbone to other PE routers. The routes are then across the backbone to other PE routers. The routes are then
converted back to OSPF routes sent via OSPF to other CE routers. As converted back to OSPF routes sent via OSPF to other CE routers. As
a result of converting the routes from OSPF to BGP and back to OSPF, a result of this conversion, some of the information needed to
some of the information needed to prevent loops may be lost. A prevent loops may be lost. A procedure is needed to ensure that once
procedure is needed to ensure that once a route is sent from a PE to a route is sent from a PE to a CE, the route will be ignored by any
a CE, the route will be ignored by any PE which receives it back from PE that receives it back from a CE. This document specifies the
a CE. This document specifies the necessary procedure, using one of necessary procedure, using one of the options bits in the LSA (Link
the options bits in the LSA (Link State Advertisements) to indicate State Advertisements) to indicate that an LSA has already been
that an LSA has already been forwarded by a PE, and should be ignored forwarded by a PE and should be ignored by any other PEs that see it.
by any other PEs that see it.
Table of Contents Table of Contents
1 Specification of Requirements ........................ 2 1. Introduction ....................................................2
2 Introduction ......................................... 2 2. Specification of Requirements ...................................3
3 Information Loss and Loops ........................... 4 3. Information Loss and Loops ......................................3
4 Using the LSA Options to Prevent Loops ............... 5 4. Using the LSA Options to Prevent Loops ..........................4
5 Security Considerations .............................. 5 5. Security Considerations .........................................5
6 Acknowledgments ...................................... 6 6. Acknowledgements ................................................5
7 Authors' Addresses ................................... 6 7. Normative References ............................................6
8 Normative References ................................. 7
9 Intellectual Property Statement ...................... 7
10 Full Copyright Statement ............................. 7
1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
2. Introduction 1. Introduction
[VPN] describes a method by which a Service Provider (SP) can use its [VPN] describes a method by which a Service Provider (SP) can use its
IP backbone to provide an "IP VPN" service to customers. In that IP backbone to provide an "IP VPN" service to customers. In that
sort of service, a customer's edge devices (CE devices) are connected sort of service, a customer's edge devices (CE devices) are connected
to the provider's edge routers (PE routers). Each CE device is in a to the provider's edge routers (PE routers). Each CE device is in a
single VPN. Each PE device may attach to multiple CEs, of the same single Virtual Private Network (VPN). Each PE device may attach to
or of different VPNs. A VPN thus consists of a set of "network multiple CEs of the same or of different VPNs. A VPN thus consists
segments" connected by the SP's backbone. of a set of "network segments" connected by the SP's backbone.
A CE exchanges routes with a PE, using a routing protocol that is A CE exchanges routes with a PE, using a routing protocol to which
jointly agreed to by the customer and the SP. The PE runs that the customer and the SP jointly agree. The PE runs that routing
routing protocol's decision process (i.e., performs the routing protocol's decision process (i.e., it performs the routing
computation) to determine the set of IP address prefixes for which computation) to determine the set of IP address prefixes for which
the following two conditions hold: the following two conditions hold:
- each address prefix in the set can be reached via that CE - Each address prefix in the set can be reached via that CE.
- the path from that CE to each such address prefix does NOT - The path from that CE to each such address prefix does NOT
include the SP backbone (i.e., does not include any PE routers). include the SP backbone (i.e., it does not include any PE
routers).
The PE routers which attach to a particular VPN redistribute routes The PE routers that attach to a particular VPN redistribute routes to
to these address prefixes into BGP, so that they can use BGP to these address prefixes into BGP, so that they can use BGP to
distribute the VPN's routes to each other. BGP carries these routes distribute the VPN's routes to each other. BGP carries these routes
in the "VPN-IPv4 address family", so that they are distinct from in the "VPN-IPv4 address family", so that they are distinct from
ordinary Internet routes. The VPN-IPv4 address family also extends ordinary Internet routes. The VPN-IPv4 address family also extends
the IP addresses on the left so that address prefixes from two the IP addresses on the left so that address prefixes from two
different VPNs are always distinct to BGP, even if both VPNs use the different VPNs are always distinct to BGP, even if both VPNs use the
same piece of the private RFC1918 address space. Thus routes from same piece of the private RFC 1918 address space. Thus, routes from
different VPNs can be carried by a single BGP instance, and can be different VPNs can be carried by a single BGP instance and can be
stored in a common BGP table, without fear of conflict. stored in a common BGP table without fear of conflict.
If a PE router receives a particular VPN-IPv4 route via BGP, and if If a PE router receives a particular VPN-IPv4 route via BGP, and if
that PE is attached to a CE in the VPN to which the route belongs, that PE is attached to a CE in the VPN to which the route belongs,
then BGP's decision process may install that route in the BGP route then BGP's decision process may install that route in the BGP route
table. If so, the PE translates the route back into an IP route, and table. If so, the PE translates the route back into an IP route and
redistributes it to the routing protocol which is running on the link redistributes it to the routing protocol that is running on the link
to that CE. to that CE.
This methodology provides a "peer model"; CE routers peer with PE This methodology provides a "peer model". CE routers peer with PE
routers, but CE routers at different sites do not peer with each routers, but CE routers at different sites do not peer with each
other. other.
If a VPN uses OSPFv2 as its internal routing protocol, it is not If a VPN uses OSPFv2 as its internal routing protocol, it is not
necessarily the case that the CE routers of that VPN use OSPFv2 to necessarily the case that the CE routers of that VPN use OSPFv2 to
peer with the PE routers. Each site in a VPN can use OSPFv2 as its peer with the PE routers. Each site in a VPN can use OSPFv2 as its
intra-site routing protocol, while using, e.g., BGP or RIP to intra-site routing protocol while using BGP or RIP (for example) to
distribute routes to a PE router. However, it is certainly distribute routes to a PE router. However, it is certainly
convenient, when OSPFv2 is being used intra-site, to use it on the convenient when OSPFv2 is being used intra-site to use it on the PE-
PE-CE link as well, and [VPN] explicitly allows this. In this case, CE link as well, and [VPN] explicitly allows this. In this case, a
a PE will run a separate instance of OSPFv2 for each VPN which is PE will run a separate instance of OSPFv2 for each VPN that is
attached to the PE; the PE will in general have multiple VPN-specific attached to the PE; the PE will in general have multiple VPN-specific
OSPFv2 routing tables. OSPFv2 routing tables.
When OSPFv2 is used on a PE-CE link which belongs to a particular When OSPFv2 is used on a PE-CE link that belongs to a particular VPN,
VPN, the PE router must redistribute to that VPN's OSPFv2 instance the PE router must redistribute to that VPN's OSPFv2 instance certain
certain routes which have been installed in the BGP routing table. routes that have been installed in the BGP routing table. Similarly,
Similarly, a PE router must redistribute to BGP routes which have a PE router must redistribute to BGP routes that have been installed
been installed in the VPN-specific OSPF routing tables. Procedures in the VPN-specific OSPF routing tables. Procedures for this are
for this are specified in [VPN-OSPF]. specified in [VPN-OSPF].
The routes which are redistributed from BGP to OSPFv2 are advertised The routes that are redistributed from BGP to OSPFv2 are advertised
in LSAs that are originated by the PE. The PE acts as an OSPF border in LSAs that are originated by the PE. The PE acts as an OSPF border
router, advertising some of these routes in AS-external LSAs, and router, advertising some of these routes in AS-external LSAs, and
some in summary LSAs, as specified in [VPN-OSPF]. some in summary LSAs, as specified in [VPN-OSPF].
Similarly, when a PE router receives an LSA from a CE router, it runs Similarly, when a PE router receives an LSA from a CE router, it runs
the OSPF routing computation. Any route that gets installed in the the OSPF routing computation. Any route that gets installed in the
OSPF routing table must be translated into a VPN-IPv4 route and then OSPF routing table must be translated into a VPN-IPv4 route and then
redistributed into BGP. BGP will then distribute these routes to the redistributed into BGP. BGP will then distribute these routes to the
other PE routers. other PE routers.
2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
3. Information Loss and Loops 3. Information Loss and Loops
A PE, say PE1, may learn a route to a particular VPN-IPv4 address A PE, say PE1, may learn a route to a particular VPN-IPv4 address
prefix via BGP. This may cause it to generate a summary LSA or an prefix via BGP. This may cause it to generate a summary LSA or an
AS-external LSA in which it reports that address prefix. This LSA AS-external LSA in which it reports that address prefix. This LSA
may then be distributed to a particular CE, say CE1. The LSA may may then be distributed to a particular CE, say CE1. The LSA may
then be distributed throughout a particular OSPF area, reaching then be distributed throughout a particular OSPF area, reaching
another CE, say CE2. CE2 may then distribute the LSA to another PE, another CE, say CE2. CE2 may then distribute the LSA to another PE,
say PE2. say PE2.
As stated in the previous section, PE2 must run the OSPF routing As stated in the previous section, PE2 must run the OSPF routing
computation to determine whether a particular address prefix, computation to determine whether a particular address prefix,
reported in an LSA from CE2, is reachable from CE2 via a path which reported in an LSA from CE2, is reachable from CE2 via a path that
does not include any PE router. Unfortunately, there is no standard does not include any PE router. Unfortunately, there is no standard
way to do this. The OSPFv2 LSAs do not necessarily carry the way to do this. The OSPFv2 LSAs do not necessarily carry the
information needed to enables PE2 to determine that the path to information needed to enable PE2 to determine that the path to
address prefix X in a particular LSA from CE2 is actually a path that address prefix X in a particular LSA from CE2 is actually a path that
includes, say, PE1. If PE2 then leaks X into BGP as a VPN-IPv4 includes, say PE1. If PE2 then leaks X into BGP as a VPN-IPv4 route,
route, then PE2 is violating one of the constraints for loop-freedom then PE2 is violating one of the constraints for loop-freedom in BGP;
in BGP, viz., that routes learned from a particular BGP domain not be viz., that routes learned from a particular BGP domain are not
redistributed back into that BGP domain. This could cause a routing redistributed back into that BGP domain. This could cause a routing
loop to be created. loop to be created.
It is therefore necessary to have a means by which an LSA may carry It is therefore necessary to have a means by which an LSA may carry
the information that a particular address prefix has been learned the information that a particular address prefix has been learned
from a PE router. Any PE router which receives an LSA with this from a PE router. Any PE router that receives an LSA with this
information would omit the information in this LSA from its OSPF information would omit the information in this LSA from its OSPF
routing computation, and thus would not leak the information back routing computation, and thus it would not leak the information back
into BGP. into BGP.
When a PE generates an AS-external LSA, it could use a distinct tag When a PE generates an AS-external LSA, it could use a distinct tag
value to indicate that the LSA is carrying information about an value to indicate that the LSA is carrying information about an
address prefix for whom the path includes a PE router. However, this address prefix for whom the path includes a PE router. However, this
method is not available in the case where the PE generates a Summary method is not available in the case where the PE generates a Summary
LSA. Per [VPN-OSPF], each PE router must function as an OSPF area 0 LSA. Per [VPN-OSPF], each PE router must function as an OSPF area 0
router. If the PE-CE link is an area 0 link, then it is possible for router. If the PE-CE link is an area 0 link, then it is possible for
the PE to receive, over that link, a summary LSA which originated at the PE to receive, over that link, a summary LSA that originated at
another PE router. Thus we need some way of marking a summary LSA to another PE router. Thus, we need some way of marking a summary LSA
indicate that it is carrying information about a path via a PE to indicate that it is carrying information about a path via a PE
router. router.
4. Using the LSA Options to Prevent Loops 4. Using the LSA Options to Prevent Loops
The high-order bit of the LSA Options field (a previously unused bit) The high-order bit of the LSA Options field (a previously unused bit)
is used to solve the problem described in the previous section. We is used to solve the problem described in the previous section. We
refer to this bit as the DN bit. When a type 3, 5, or 7 LSA is sent refer to this bit as the DN bit. When a type 3, 5, or 7 LSA is sent
from a PE to a CE, the DN bit MUST be set. The DN bit MUST be clear from a PE to a CE, the DN bit MUST be set. The DN bit MUST be clear
in all other LSA types. in all other LSA types.
skipping to change at page 5, line 29 skipping to change at page 5, line 19
Options Field with DN Bit Options Field with DN Bit
(RFC 2328, Section A.2) (RFC 2328, Section A.2)
When the PE receives, from a CE router, a type 3, 5, or 7 LSA with When the PE receives, from a CE router, a type 3, 5, or 7 LSA with
the DN bit set, the information from that LSA MUST NOT be used during the DN bit set, the information from that LSA MUST NOT be used during
the OSPF route calculation. As a result, the LSA is not translated the OSPF route calculation. As a result, the LSA is not translated
into a BGP route. The DN bit MUST be ignored in all other LSA types. into a BGP route. The DN bit MUST be ignored in all other LSA types.
This prevents routes learned via BGP from being redistributed to BGP. This prevents routes learned via BGP from being redistributed to BGP.
(This restriction is analogous to the usual OSPF restriction that (This restriction is analogous to the usual OSPF restriction that
inter-area routes which are learned from area 0 are not passed back inter-area routes that are learned from area 0 are not passed back to
to area 0.) area 0.)
Note that the DN bit has no other effect on LSA handling. In Note that the DN bit has no other effect on LSA handling. In
particular, an LSA with the DN bit set will be put in the topological particular, an LSA with the DN bit set will be put in the topological
database, aged, flooded, etc., just as if DN were not set. database, aged, flooded, etc., just as if DN were not set.
5. Security Considerations 5. Security Considerations
An attacker may cause the DN bit to be set, in an LSA traveling from An attacker may cause the DN bit to be set, in an LSA traveling from
CE to PE, when the DN bit should really be clear. This may cause the CE to PE, when the DN bit should really be clear. This may cause the
address prefixes mentioned in that LSA to be unreachable from other address prefixes mentioned in that LSA to be unreachable from other
sites of the VPN. Similarly, an attacker may cause the DN bit to be sites of the VPN. Similarly, an attacker may cause the DN bit to be
clear, in an LSA traveling in either direction, when the DN bit clear, in an LSA traveling in either direction, when the DN bit
should really be set. This may cause routing loops for traffic which should really be set. This may cause routing loops for traffic that
is destined to the address prefixes mentioned in that LSA. is destined to the address prefixes mentioned in that LSA.
These possibilities may be eliminated by using cryptographic These possibilities may be eliminated by using cryptographic
authentication as specified in section D of [OSPFv2]. authentication as specified in Section D of [OSPFv2].
6. Acknowledgments 6. Acknowledgements
The idea of using the high-order options bit for this purpose is due The idea of using the high-order options bit for this purpose is due
to Derek Yeung. Thanks to Yakov Rekhter for his contribution to this to Derek Yeung. Thanks to Yakov Rekhter for his contribution to this
work. We also wish to thank Acee Lindem for his helpful comments. work. We also wish to thank Acee Lindem for his helpful comments.
7. Authors' Addresses 7. Normative References
[OSPFv2] Postel, J., "Suggested Telnet Protocol Changes", RFC 328,
April 1972.
[VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[VPN-OSPF] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the
Provider/Customer Edge Protocol for BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC 4577, June 2006.
Authors' Addresses
Eric C. Rosen Eric C. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
E-mail: erosen@cisco.com EMail: erosen@cisco.com
Peter Psenak Peter Psenak
Parc Pegasus, Cisco Systems
De Kleetlaan 6A BA Business Center, 9th Floor
1831 Diegem Plynarenska 1
Belgium Bratislava 82109
Slovakia
E-mail: ppsenak@cisco.com EMail: ppsenak@cisco.com
Padma Pillay-Esnault Padma Pillay-Esnault
Juniper Networks Cisco Systems
1194 N. Mathilda Avenue 3750 Cisco Way
Sunnyvale, CA 94089 San Jose, CA 95134
E-mail: padma@juniper.net EMail: ppe@cisco.com
8. Normative References Full Copyright Statement
[VPN] "BGP/MPLS IP VPNs", draft-ietf-l3vpn-rfc2547bis-01.txt, Rosen,
Rekhter, et. al., September 2003
[VPN-OSPF] "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", draft- Copyright (C) The Internet Society (2006).
ietf-l3vpn-ospf-2547-01.txt, Rosen, Psenak, Pillay-Esnault, February
2004
9. Intellectual Property Statement This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
10. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Acknowledgement
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an Funding for the RFC Editor function is provided by the IETF
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS Administrative Support Activity (IASA).
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 45 change blocks. 
119 lines changed or deleted 122 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/