One document matched: draft-rosen-ospf-2547bis-dn-00.txt

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

                                                    Padma Pillay-Esnault
                                                  Juniper Networks, Inc.

                                                           February 2003


              OSPF as the PE/CE Protocol in BGP/MPLS VPNs


                   draft-rosen-ospf-2547bis-dn-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
   a VPN service to its customers.  In that method, BGP is used to carry
   customer routes across the SP's backbone.  That method allows a
   variety of different protocols to be used as the routing protocol
   between the Customer Edge (CE) router and the Provider Edge (PE)
   router.  [VPN-OSPF] specifies additional procedures to be used when
   the CE/PE router protocol is OSPF.  In these additional procedures,
   customer OSPF routes from a CE router are translated into BGP routes
   by a PE router.  Then they are sent via BGP to another PE router,
   which translates them back into OSPF routes and distributes them to
   another CE router.  This translation may lose some of the information



Rosen, et al.                                                   [Page 1]


Internet Draft     draft-rosen-ospf-2547bis-dn-00.txt      February 2003


   needed to prevent loops.   This document proposes 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  ...............   4
    5        Acknowledgments  ......................................   5
    6        Normative References  .................................   5





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 a VPN service to customers.  In that method, 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 CE, 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:

     - 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



Rosen, et al.                                                   [Page 2]


Internet Draft     draft-rosen-ospf-2547bis-dn-00.txt      February 2003


   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-rosen-ospf-2547bis-dn-00.txt      February 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 CE.  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.

   Hence a method is needed 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.


4. Using the LSA Options to Prevent Loops

   We propose that when an LSA is sent from a PE to a CE, the high-order
   bit of the LSA Options field (a previously unused bit) MUST be set.
   We refer to this bit as the DN bit.

   When the PE receives, from a CE router, an LSA with the DN bit set,
   the information from that LSA is not used during the OSPF route
   calculation, and as a result the LSA is not translated into a BGP
   route.



Rosen, et al.                                                   [Page 4]


Internet Draft     draft-rosen-ospf-2547bis-dn-00.txt      February 2003


   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. Normative References

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

   [VPN] "BGP/MPLS VPNs", draft-ietf-ppvpn-rfc2547bis-03.txt, Rosen, E.,
   et. al., October 2002.

   [OSPF-VPN] "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", draft-
   rosen-vpns-ospf-bgp-mpls-06.txt, Rosen, E., et. all., February 2003
































Rosen, et al.                                                   [Page 5]