Skip to main content

OSPF Version 2 as the Customer Edge/Customer Protocol for BGP/MPLS IP VPNs
draft-freedman-l3vpn-ospf2-4364-ce-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author David Freedman
Last updated 2012-02-29
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-freedman-l3vpn-ospf2-4364-ce-00
Internet Engineering Task Force                              D. Freedman
Internet-Draft                                                  Claranet
Intended status: Standards Track                       February 29, 2012
Expires: September 1, 2012

 OSPF Version 2 as the Customer Edge/Customer Protocol for BGP/MPLS IP
                                  VPNs
                 draft-freedman-l3vpn-ospf2-4364-ce-00

Abstract

   RFC4577 (OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP
   VPNs) proposes a mechanism for the use of the Open Shortest Path
   First V2 ("OSPF", RFC2328) protocol between the Provider Edge ("PE")
   and Customer Edge ("CE") routers within a BGP/MPLS IP Virtual Private
   Network ("IP/VPN", RFC4364).

   The standard provides for use of such a provider VPN to join
   discontiguous locations together, preserving the OSPF area and domain
   behaviour.

   This document describes a technique for utilising the same, IPVPN
   network infrastructure without the requirement to enable the OSPF
   protocol on the PE/CE interface and thus relieve the PE router of
   OSPF duties.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on September 1, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Freedman                Expires September 1, 2012               [Page 1]
Internet-Draft    draft-freedman-l3vpn-ospf2-4364-ce-00    February 2012

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Solution Statement . . . . . . . . . . . . . . . . . . . . . .  6
   4.  With respect to RFC4577  . . . . . . . . . . . . . . . . . . .  7
   5.  Behavioral Considerations  . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11

Freedman                Expires September 1, 2012               [Page 2]
Internet-Draft    draft-freedman-l3vpn-ospf2-4364-ce-00    February 2012

1.  Introduction

   [RFC4577] describes a mechanism whereby discontiguous locations
   belonging to the same OSPF area and domain are connected by use of an
   [RFC4364] IPVPN network.

   The premise (see Figure 1) is that OSPF [RFC2328] routing information
   from a site is learned by the attached PE router through an OSPF
   adjacency with the site's CE router.  This OSPF routing information
   is learned in the context of a Virtual Routing and Forwarding ("VRF")
   instance intended to trigger redistribution into the provider BGP as
   a VPN-IPv4 route through the addition of various Extended Communities
   [RFC4360] such as "Route Target" (to select the desired destination
   VRFs when imported by other PE routers), "OSPF Domain Identifier" (to
   determine if the route should be treated as internal or external to
   the CE OSPF domain) and "OSPF Route Type" (to encode the LSA type as
   it was received from the OSPF neighbor).

   When a remote PE router, importing such routes into a VRF (due to a
   matching Route-Target in a VRF import policy), locates the OSPF
   extended communities, it uses them to originate OSPF LSAs to its
   attached CE, providing the OSPF domain ID is the same, BGP routes can
   be redistributed back into the CE-attached OSPF area using the
   information encoded in the BGP update, fooling the attached site into
   thinking that there is a contiguous OSPF domain.

   "Sham Links" may then be created between VPN residing endpoints on
   all involved PE routers, to provide simulated intra-area links,
   ensuring that any "Backdoor" links between C routers are not
   automatically selected by OSPF in preference to the provider network
   links (which would normally be treated as inter-area had the Sham
   Link not been present).

Freedman                Expires September 1, 2012               [Page 3]
Internet-Draft    draft-freedman-l3vpn-ospf2-4364-ce-00    February 2012

                                  Sham Link
                                _____________
                               /             \
                              /    ,-----.    \
                             [PE1]; IPVPN ++PE2]
                               |  :  BGP  +  |
                   OSPF        |   `-----'   |    OSPF
                               |             |
                   Site A    [CE1]         [CE2]   Site B
                               |    Area 0   |
                   OSPF        |             |    OSPF
                             [ C1]         [C3 ]
                   OSPF      ,-'             `.   OSPF
                          [ C2]              [C4 ]
                            \__________________/
                                Backdoor Link

                                 Figure 1

Freedman                Expires September 1, 2012               [Page 4]
Internet-Draft    draft-freedman-l3vpn-ospf2-4364-ce-00    February 2012

2.  Problem Statement

   The author infers from the title and language in RFC4577 that the
   original intention of the document was to provide OSPF functionality
   over an IPVPN network through use of the Provider's PE routers.
   Since the Provider may use the PE router for multiple customers, and
   OSPF is based on repeated execution of the Shortest Path First
   ("SPF") algorithm, this approach may create computation scaling
   considerations for the PE as the number or complexity of customer
   topologies using this technology on the PE increases.

Freedman                Expires September 1, 2012               [Page 5]
Internet-Draft    draft-freedman-l3vpn-ospf2-4364-ce-00    February 2012

3.  Solution Statement

   This document proposes a mechanism for providing this OSPF
   functionality over IPVPN networks, using only CE routers, ensuring
   that only IP and BGP is required between PE and CE.  This is
   illustrated below in Figure 2

                                   ,-----.
                             [PE1]; IPVPN ++PE2]
                               |  :       +  |
                         BGP   |   `-----'   |   BGP
                               |    Sham     |
                   Site A    [CE1]--------- [CE2]   Site B
                               |    Link     |
                        OSPF   |    Area 0   |   OSPF
                             [ C1]         [C3 ]
                    OSPF     ,-'             `.     OSPF
                          [ C2]              [C4 ]
                            \__________________/
                                Backdoor Link

                                 Figure 2

   By removing the OSPF from the PE router and placing the
   responsibility on the CE, the provider's existing IPVPN PE routers
   are no longer forced to run the SPF algorithm since this task can be
   delegated to the CE which does not have the same scaling concerns
   (since it does not share this task with multiple customer domains).

Freedman                Expires September 1, 2012               [Page 6]
Internet-Draft    draft-freedman-l3vpn-ospf2-4364-ce-00    February 2012

4.  With respect to RFC4577

   RFC4577 makes the following requirement of creating Sham Links (Sec
   4.2.7.3):

   An OSPF protocol packet is regarded as having been received on a
   particular Sham Link if and only if the following three conditions
   hold:

      -  The packet arrives as an MPLS packet, and its MPLS label stack
         causes it to be "delivered" to the local Sham Link endpoint
         address.

      -  The packet's IP destination address is the local Sham Link
         endpoint address.

      -  The packet's IP source address is the remote Sham Link endpoint
         address.

   Although RFC4577 marks the use of Sham Links as "OPTIONAL", creation
   of such links, with respect to the above stated, require that the
   implementation transmit the OSPF protocol packets over MPLS
   transport.

   Since the intention of this document is to ensure that only IP and
   BGP are required between CE routers, this document relaxes the
   requirements stated in this RFC section, by removing the requirement
   for the packet to arrive as an MPLS packet.  Since the routing
   information is redistributed into the BGP and labelled by the PE
   router for use within the Provider's IPVPN network, an additional
   MPLS LSP is not required.

   This document adds the requirement that BGP should be used as a PE/CE
   protocol and that Extended Communities be made available to both
   peers through mutual negotiation of the relevant BGP capability
   ([RFC3392]).

Freedman                Expires September 1, 2012               [Page 7]
Internet-Draft    draft-freedman-l3vpn-ospf2-4364-ce-00    February 2012

5.  Behavioral Considerations

   This document makes the following recommendations in respect to
   behavior:

   1.  That the requirement stated in Section 6 (Security
       Considerations) of RFC4577 with regards to multiple OSPF
       instances be relaxed in a CE router implementation which MUST NOT
       share routing information with other OSPF domains.

   2.  That the requirement stated in Section 4.2.7.3 (OSPF Protocol on
       Sham Links) of RFC4577 with regards to the requirement that the
       OSPF protocol packet be received as an MPLS packet, be relaxed in
       a CE router implementation.  In its place, the CE router MUST
       verify that the OSPF protocol packet is valid based on the
       operator configuration of valid Sham Link endpoints.

   3.  That the requirement stated in Section 3 (Requirements) of
       RFC4577, that OSPF is used as a PE/CE routing protocol be
       relaxed, such that BGP is used as a PE/CE routing protocol and
       that extended communities are enabled between PE and CE, a
       mechanism to filter said communities MUST be made available to
       the operator to ensure that no other (unwanted) extended
       communities are injected to or from the provider space.

Freedman                Expires September 1, 2012               [Page 8]
Internet-Draft    draft-freedman-l3vpn-ospf2-4364-ce-00    February 2012

6.  Security Considerations

   The Behavioral Considerations (Section 5) specify that particular
   behavioral patterns of RFC4577 be relaxed, references to ensuring
   appropriate security should be found here.

Freedman                Expires September 1, 2012               [Page 9]
Internet-Draft    draft-freedman-l3vpn-ospf2-4364-ce-00    February 2012

7.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC3392]  Chandra, R. and J. Scudder, "Capabilities Advertisement
              with BGP-4", RFC 3392, November 2002.

   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, February 2006.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, February 2006.

   [RFC4577]  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.

Freedman                Expires September 1, 2012              [Page 10]
Internet-Draft    draft-freedman-l3vpn-ospf2-4364-ce-00    February 2012

Author's Address

   David Freedman
   Claranet
   London
   UK

   Phone: +44 20 7685 8000
   Email: david.freedman@uk.clara.net

Freedman                Expires September 1, 2012              [Page 11]