Network Working Group                                      Eric C. Rosen
Internet Draft                                              Peter Psenak
Expiration Date: December 2003 March 2004                          Cisco Systems, Inc.

                                                    Padma Pillay-Esnault
                                                  Juniper Networks, Inc.


                                                          September 2003

    Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs



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

   The list of Internet-Draft Shadow Directories can be accessed at


    [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
   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",
   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 (i.e., performs the routing
   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

     - 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" redistribute routes
   to these address prefixes into BGP, and so that they can 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  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 space.  Thus routes of a particular VPN are from different
   VPNs can be carried
   only to the PE routers which attach to that VPN. by a single BGP instance, and can be stored in a
   common BGP table, without fear of conflict.

   If a PE router receives a particular VPN-IP route via BGP, and if
   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
   table.  If so, the PE will
   translate translates the route back to IP, into an IP route, and leak
   redistributes it into to the routing
   algorithm protocol 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


   If a VPN uses OSPF as its internal routing protocol this does protocol, it is not
   necessarily mean the case 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 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 PE-CE link as well,
   and [VPN] explicitly allows this.

   When  In this case, a PE will run a
   separate instance of OSPF for each VPN which is done, attached to the PE;
   the PE routers will in general have multiple VPN-specific OSPF routing

   When OSPF is used on a PE-CE link which belongs to a particular VPN,
   the PE router must convert between redistribute to that VPN's OSPF instance certain
   routes which have been installed in the BGP routing table.
   Similarly, a PE router must redistribute to BGP routes and which have
   been installed in the VPN-specific OSPF routes. routing tables.  Procedures
   for this are specified in [VPN-OSPF].  PE
   routers act like OSPF border routers.  PE routers will sometimes
   convert BGP

   The routes to OSPF AS-external routes, and will sometimes
   convert which are redistributed from BGP routes to OSPF summary routes.  In either case, are advertised in
   LSAs that are originated by the PE.  The PE
   will originate an LSA, and distribute it to any CE routers (in the
   appropriate VPN) with which it maintains acts as an OSPF adjacency. border
   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 a summary LSA or an AS-external LSA from a CE router, it may convert those LSAs to 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 for
   distribution to the
   other PEs. PE routers.

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 routing
   computation 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,
   routing computation, 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  Per [OSPF-VPN], each PE router must function as an OSPF area 0
   router.  If the PE-CE links are link is an area 0 links; however, this link, then it is an
   important case possible for
   the PE to handle correctly.)  Thus one needs receive, over that link, a more generally
   applicable method summary LSA which originated at
   another PE router.  Thus we need some way of indicating that an marking a summary LSA contains to
   indicate that it is carrying information about a path via a PE

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.

                     | 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,
   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

   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.  We also wish to thank Acee Lindem for his helpful comments.

6. Authors' Addresses

   Eric C. Rosen
   Cisco Systems, Inc.
   1414 Massachusetts Avenue
   Boxborough, MA 01719

   Peter Psenak
   Parc Pegasus,
   De Kleetlaan 6A
   1831 Diegem


   Padma Pillay-Esnault
   Juniper Networks
   1194 N. Mathilda Avenue
   Sunnyvale, CA 94089


7. Normative References

   [OSPF] "OSPF Version 2", RFC 2328, Moy, J., April 1998

   [VPN] "BGP/MPLS VPNs", draft-ietf-ppvpn-rfc2547bis-04.txt, draft-ietf-l3vpn-rfc2547bis-01.txt, Rosen,
   Rekhter, et. al., May September 2003

   [OSPF-VPN] "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", draft-
   ietf-l3vpn-ospf-2547-00.txt, Rosen, Psenak, Pillay-Esnault, June 2003