Network Working Group Eric C. Rosen Internet Draft Peter Psenak Expiration Date: December 2003 Cisco Systems, Inc. Padma Pillay-Esnault Juniper Networks, Inc. June 2003 Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs draft-ietf-ospf-2547-dnbit-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract [VPN] describes a method by which a Service Provider (SP) may provide an "IP VPN" service to its customers. In VPNs of that sort, 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 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 PE routers are routing peers, it is customary to run a 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 must execute additional procedures not specified in [VPN]; these procedures are specified in [OSPF-VPN]. These additional procedures Rosen, et al. [Page 1] Internet Draft draft-ietf-ospf-2547-dnbit-00.txt June 2003 translate customer OSPF routes from a CE router into BGP routes. The BGP routes are sent to the other PE routers, which translate them back into OSPF routes, and then distribute them to CE routers. During this translation, some of the information needed to prevent loops may be lost. The procedures specified in this document remedy this situation by specifying that one of the OSPF options bits be used to ensure that when a VPN route is sent from a PE to a CE, the route will be ignored by any PE which receives it back from a CE. Table of Contents 1 Specification of Requirements ........................ 2 2 Introduction ......................................... 2 3 Information Loss and Loops ........................... 4 4 Using the LSA Options to Prevent Loops ............... 5 5 Acknowledgments ...................................... 5 6 Authors' Addresses ................................... 5 7 Normative References ................................. 6 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 [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 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 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 segments" connected by the SP's backbone. 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 routing protocol's decision process to determine the set of IP address prefixes for which the following two conditions hold: Rosen, et al. [Page 2] Internet Draft draft-ietf-ospf-2547-dnbit-00.txt June 2003 - each address prefix in the set can be reached via that CE - the path from that CE to each such address prefix does NOT 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 these address prefixes into BGP, and use BGP to distribute the VPN's routes to each other. BGP carries these routes in the "VPN-IP address family", so that they are distinct from ordinary Internet routes. (The VPN-IP address family also extends 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 same piece of the private RFC1918 address space.) The routes of a particular VPN are carried only to the PE routers which attach to that VPN. If a PE router receives a VPN-IP route via BGP, and that PE is attached to a CE in the VPN to which the route belongs, the PE will translate the route back to IP, and leak it into the routing algorithm which is running on the link to that CE. This methodology provides a "peer model"; CE routers peer with PE routers, but CE routers at different sites do not peer with each other. When a VPN uses OSPF as its internal routing protocol this does not necessarily mean that the CE routers of that VPN must use OSPF to peer with the PE routers. Each site in a VPN can use OSPF as its intra-site routing protocol, while using, e.g., BGP or RIP to distribute routes to a PE router. However, it is certainly convenient, when OSPF is being used intra-site, to use it on the PE- CE link as well, and [VPN] explicitly allows this. When this is done, the PE routers must convert between BGP routes and OSPF routes. Procedures for this are specified in [VPN-OSPF]. PE routers act like OSPF border routers. PE routers will sometimes convert BGP routes to OSPF AS-external routes, and will sometimes convert BGP routes to OSPF summary routes. In either case, the PE will originate an LSA, and distribute it to any CE routers (in the appropriate VPN) with which it maintains an OSPF adjacency. Similarly, when a PE router receives a summary LSA or an AS-external LSA from a CE router, it may convert those LSAs to BGP routes for distribution to other PEs. Rosen, et al. [Page 3] Internet Draft draft-ietf-ospf-2547-dnbit-00.txt June 2003 3. Information Loss and Loops 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 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 then be distributed throughout a particular OSPF area, reaching another CE, say CE2. CE2 may then distribute the LSA to another PE, say PE2. As stated in the previous section, PE2 must run the OSPF decision process to determine whether a particular address prefix, reported in an LSA from CE2, is reachable from CE2 via a path which does not include any PE router. Unfortunately, there is no standard way to do this. The OSPF LSAs do not necessarily carry the information needed to enables PE2 to determine that the path to 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-IP route, then PE2 is violating one of the constraints for loop-freedom in BGP, viz., that routes learned from a particular BGP domain not be 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 the information that a particular address prefix has been learned from a PE router. Any PE router which receives an LSA with this information would omit the information in this LSA from its OSPF decision process, and thus would not leak the information back into BGP. 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 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 LSA. (The reader will note that loops can only induced by Summary LSAs when the PE-CE links are area 0 links; however, this is an important case to handle correctly.) Thus one needs a more generally applicable method of indicating that an LSA contains information about a path via a PE router. Rosen, et al. [Page 4] Internet Draft draft-ietf-ospf-2547-dnbit-00.txt June 2003 4. Using the LSA Options to Prevent Loops 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 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. 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 calculation. As a result, the LSA is not translated into a BGP route. This prevents routes learned via BGP from being redistributed to BGP. 5. Acknowledgments 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 work. 6. Authors' Addresses Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 E-mail: erosen@cisco.com Peter Psenak Parc Pegasus, De Kleetlaan 6A 1831 Diegem Belgium E-mail: ppsenak@cisco.com Rosen, et al. [Page 5] Internet Draft draft-ietf-ospf-2547-dnbit-00.txt June 2003 Padma Pillay-Esnault Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 E-mail: padma@juniper.net 7. Normative References [OSPF] "OSPF Version 2", RFC 2328, Moy, J., April 1998 [VPN] "BGP/MPLS VPNs", draft-ietf-ppvpn-rfc2547bis-04.txt, Rosen, Rekhter, et. al., May 2003 [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 Rosen, et al. [Page 6]