draft-ietf-ospf-2547-dnbit-00.txt   draft-ietf-ospf-2547-dnbit-01.txt 
Network Working Group Eric C. Rosen Network Working Group Eric C. Rosen
Internet Draft Peter Psenak Internet Draft Peter Psenak
Expiration Date: December 2003 Cisco Systems, Inc. Expiration Date: March 2004 Cisco Systems, Inc.
Padma Pillay-Esnault Padma Pillay-Esnault
Juniper Networks, Inc. Juniper Networks, Inc.
June 2003 September 2003
Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs
draft-ietf-ospf-2547-dnbit-00.txt draft-ietf-ospf-2547-dnbit-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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.
Abstract Abstract
[VPN] describes a method by which a Service Provider (SP) may provide [VPN] describes a method by which a Service Provider (SP) may
an "IP VPN" service to its customers. In VPNs of that sort, a provide an "IP VPN" service to its customers. In VPNs of that sort,
Customer Edge (CE) Router and a Provider Edge Router become routing a Customer Edge (CE) Router and a Provider Edge Router become routing
peers, and the customer routes are sent to the SP. BGP is then used peers, and the customer routes are sent to the SP. BGP is then used
to carry the customer routes across the SP's backbone to other PE to carry the customer routes across the SP's backbone to other PE
routers, and the routes are then sent to other CE routers. Since CE routers, and the routes are then sent to other CE routers. Since CE
routers and PE routers are routing peers, it is customary to run a routers and PE routers are routing peers, it is customary to run a
routing protocol between them. [VPN] allows a number of different routing protocol between them. [VPN] allows a number of different
PE-CE protocols. If OSPF is used as the PE-CE routing protocol, the PE-CE protocols. If OSPF is used as the PE-CE routing protocol, the
PE must execute additional procedures not specified in [VPN]; these PE must execute additional procedures not specified in [VPN]; these
procedures are specified in [OSPF-VPN]. These additional procedures procedures are specified in [OSPF-VPN]. These additional procedures
translate customer OSPF routes from a CE router into BGP routes. The translate customer OSPF routes from a CE router into BGP routes. The
BGP routes are sent to the other PE routers, which translate them BGP routes are sent to the other PE routers, which translate them
skipping to change at page 2, line 41 skipping to change at page 2, line 41
[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 VPN. Each PE device may attach to multiple CEs, of the same
or of different VPNs. A VPN thus consists of a set of "network or of different VPNs. A VPN thus consists of a set of "network
segments" connected by the SP's backbone. 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 that is
jointly agreed to by the customer and the SP. The PE runs that jointly agreed to by the customer and the SP. The PE runs that
routing protocol's decision process to determine the set of IP routing protocol's decision process (i.e., performs the routing
address prefixes for which the following two conditions hold: computation) to determine the set of IP address prefixes for which
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., does not include any PE routers).
The PE routers which attach to a particular VPN then "leak" routes to The PE routers which attach to a particular VPN redistribute routes
these address prefixes into BGP, and use BGP to distribute the VPN's to these address prefixes into BGP, so that they can use BGP to
routes to each other. BGP carries these routes in the "VPN-IP distribute the VPN's routes to each other. BGP carries these routes
address family", so that they are distinct from ordinary Internet in the "VPN-IP address family", so that they are distinct from
routes. (The VPN-IP address family also extends the IP addresses on ordinary Internet routes. The VPN-IP address family also extends the
the left so that address prefixes from two different VPNs are always IP addresses on the left so that address prefixes from two different
distinct to BGP, even if both VPNs use the same piece of the private VPNs are always distinct to BGP, even if both VPNs use the same piece
RFC1918 address space.) The routes of a particular VPN are carried of the private RFC1918 address space. Thus routes from different
only to the PE routers which attach to that VPN. VPNs can be carried by a single BGP instance, and can be stored in a
common BGP table, without fear of conflict.
If a PE router receives a VPN-IP route via BGP, and that PE is If a PE router receives a particular VPN-IP route via BGP, and if
attached to a CE in the VPN to which the route belongs, the PE will that PE is attached to a CE in the VPN to which the route belongs,
translate the route back to IP, and leak it into the routing then BGP's decision process may install that route in the BGP route
algorithm which is running on the link to that CE. 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
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.
When a VPN uses OSPF as its internal routing protocol this does not If a VPN uses OSPF as its internal routing protocol, it is not
necessarily mean that the CE routers of that VPN must use OSPF to necessarily the case that the CE routers of that VPN use OSPF to peer
peer with the PE routers. Each site in a VPN can use OSPF as its with the PE routers. Each site in a VPN can use OSPF as its intra-
intra-site routing protocol, while using, e.g., BGP or RIP to site routing protocol, while using, e.g., BGP or RIP to distribute
distribute routes to a PE router. However, it is certainly routes to a PE router. However, it is certainly convenient, when
convenient, when OSPF is being used intra-site, to use it on the PE- OSPF is being used intra-site, to use it on the PE-CE link as well,
CE link as well, and [VPN] explicitly allows this. and [VPN] explicitly allows this. In this case, a PE will run a
separate instance of OSPF for each VPN which is attached to the PE;
the PE will in general have multiple VPN-specific OSPF routing
tables.
When this is done, the PE routers must convert between BGP routes and When OSPF is used on a PE-CE link which belongs to a particular VPN,
OSPF routes. Procedures for this are specified in [VPN-OSPF]. PE the PE router must redistribute to that VPN's OSPF instance certain
routers act like OSPF border routers. PE routers will sometimes routes which have been installed in the BGP routing table.
convert BGP routes to OSPF AS-external routes, and will sometimes Similarly, a PE router must redistribute to BGP routes which have
convert BGP routes to OSPF summary routes. In either case, the PE been installed in the VPN-specific OSPF routing tables. Procedures
will originate an LSA, and distribute it to any CE routers (in the for this are specified in [VPN-OSPF].
appropriate VPN) with which it maintains an OSPF adjacency.
Similarly, when a PE router receives a summary LSA or an AS-external The routes which are redistributed from BGP to OSPF are advertised in
LSA from a CE router, it may convert those LSAs to BGP routes for LSAs that are originated by the PE. The PE acts as an OSPF border
distribution to other PEs. router, advertising some of these routes in AS-external LSAs, and
some in summary LSAs, as specified in [VPN-OSPF].
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
OSPF routing table must be translated into a VPN-IP route and then
redistributed into BGP. BGP will then distribute these routes to the
other PE routers.
3. Information Loss and Loops 3. Information Loss and Loops
A PE, say PE1, may learn a route to a particular VPN-IP address A PE, say PE1, may learn a route to a particular VPN-IP 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 decision As stated in the previous section, PE2 must run the OSPF routing
process to determine whether a particular address prefix, reported in computation to determine whether a particular address prefix,
an LSA from CE2, is reachable from CE2 via a path which does not reported in an LSA from CE2, is reachable from CE2 via a path which
include any PE router. Unfortunately, there is no standard way to do does not include any PE router. Unfortunately, there is no standard
this. The OSPF LSAs do not necessarily carry the information needed way to do this. The OSPF LSAs do not necessarily carry the
to enables PE2 to determine that the path to address prefix X in a information needed to enables PE2 to determine that the path to
particular LSA from CE2 is actually a path that includes, say, PE1. address prefix X in a particular LSA from CE2 is actually a path that
If PE2 then leaks X into BGP as a VPN-IP route, then PE2 is violating includes, say, PE1. If PE2 then leaks X into BGP as a VPN-IP route,
one of the constraints for loop-freedom in BGP, viz., that routes then PE2 is violating one of the constraints for loop-freedom in BGP,
learned from a particular BGP domain not be redistributed back into viz., that routes learned from a particular BGP domain not be
that BGP domain. This could cause a routing loop to be created. redistributed back into that BGP domain. This could cause a routing
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 which 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
decision process, and thus would not leak the information back into routing computation, and thus would not leak the information back
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. (The reader will note that loops can only induced by Summary LSA. Per [OSPF-VPN], each PE router must function as an OSPF area 0
LSAs when the PE-CE links are area 0 links; however, this is an router. If the PE-CE link is an area 0 link, then it is possible for
important case to handle correctly.) Thus one needs a more generally the PE to receive, over that link, a summary LSA which originated at
applicable method of indicating that an LSA contains information another PE router. Thus we need some way of marking a summary LSA to
about a path via a PE router. indicate that it is carrying information about a path via a PE
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 an LSA is sent from a PE to a refer to this bit as the DN bit. When an LSA is sent from a PE to a
CE, the DN bit MUST be set. CE, the DN bit MUST be set.
+-------------------------------------+
| DN | * | DC | EA | N/P | MC | E | * |
+-------------------------------------+
Options Field with DN Bit
(RFC 2328, Section A.2)
When the PE receives, from a CE router, an LSA with the DN bit set, When the PE receives, from a CE router, an LSA with the DN bit set,
the information from that LSA MUST NOT be used during the OSPF route the information from that LSA MUST NOT be used during the OSPF route
calculation. As a result, the LSA is not translated into a BGP calculation. As a result, the LSA is not translated into a BGP
route. route.
This prevents routes learned via BGP from being redistributed to BGP. This prevents routes learned via BGP from being redistributed to BGP.
5. Acknowledgments 5. Acknowledgments
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. work. We also wish to thank Acee Lindem for his helpful comments.
6. Authors' Addresses 6. 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 E-mail: erosen@cisco.com
Peter Psenak Peter Psenak
Parc Pegasus, Parc Pegasus,
De Kleetlaan 6A De Kleetlaan 6A
1831 Diegem 1831 Diegem
Belgium Belgium
E-mail: ppsenak@cisco.com E-mail: ppsenak@cisco.com
Padma Pillay-Esnault Padma Pillay-Esnault
Juniper Networks Juniper Networks
1194 N. Mathilda Avenue 1194 N. Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
E-mail: padma@juniper.net E-mail: padma@juniper.net
7. Normative References 7. Normative References
[OSPF] "OSPF Version 2", RFC 2328, Moy, J., April 1998 [OSPF] "OSPF Version 2", RFC 2328, Moy, J., April 1998
skipping to change at page 6, line 15 skipping to change at page 6, line 23
Juniper Networks Juniper Networks
1194 N. Mathilda Avenue 1194 N. Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
E-mail: padma@juniper.net E-mail: padma@juniper.net
7. Normative References 7. Normative References
[OSPF] "OSPF Version 2", RFC 2328, Moy, J., April 1998 [OSPF] "OSPF Version 2", RFC 2328, Moy, J., April 1998
[VPN] "BGP/MPLS VPNs", draft-ietf-ppvpn-rfc2547bis-04.txt, Rosen, [VPN] "BGP/MPLS VPNs", draft-ietf-l3vpn-rfc2547bis-01.txt, Rosen,
Rekhter, et. al., May 2003 Rekhter, et. al., September 2003
[OSPF-VPN] "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", draft- [OSPF-VPN] "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", draft-
ietf-ppvpn-ospf-2547-00.txt, Rosen, Psenak, Pillay-Esnault, June 2003 ietf-l3vpn-ospf-2547-00.txt, Rosen, Psenak, Pillay-Esnault, June 2003
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/