Skip to main content

Covering Prefixes Outbound Route Filter for BGP-4
draft-bonica-l3vpn-orf-covering-prefixes-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 "Replaced".
Authors Huajin Jeng , Ron Bonica , Yakov Rekhter
Last updated 2013-09-16
Replaced by draft-ietf-l3vpn-orf-covering-prefixes
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-bonica-l3vpn-orf-covering-prefixes-00
L3VPN Routing Working Group                                      H. Jeng
Internet-Draft                                                      AT&T
Intended status: Standards Track                               R. Bonica
Expires: March 19, 2014                                       Y. Rekhter
                                                        Juniper Networks
                                                      September 15, 2013

           Covering Prefixes Outbound Route Filter for BGP-4
              draft-bonica-l3vpn-orf-covering-prefixes-00

Abstract

   This document defines a new ORF-type, called the "Covering Prefixes
   ORF (CP-ORF)".  The CP-ORF is applicable in the context of a Virtual
   Hub-and-Spoke VPN.  It may also be applicable in other BGP/MPLS VPN
   environments.

Requirements Language

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

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 March 19, 2014.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents

Jeng, et al.             Expires March 19, 2014                 [Page 1]
Internet-Draft            ORF Shortest Conveing           September 2013

   (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.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  CP-ORF Encoding . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Processing Rules  . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Applicability In Virtual Hub-and-Spoke VPNs . . . . . . . . .   5
     4.1.  CP-ORF Clean-up . . . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Problem Statement

   [RFC5291] provides a mechanism through which a BGP [RFC4271] speaker
   can send a set of Outbound Route Filters (ORFs) to a peer.  The peer
   uses those ORFs to filter routing updates that it sends to the BGP
   speaker.

   The ORF mechanism allows the speaker to realize the "route pull"
   paradigm with BGP, where the speaker, on demand, can pull certain
   routes from the peer.

   This document defines a new ORF-type, called the "Covering Prefixes
   ORF (CP-ORF)".  The CP-ORF is applicable in the context of a Virtual
   Hub-and-Spoke VPN [I-D.ietf-l3vpn-virtual-hub].  However, it may also
   be applicable in other BGP/MPLS VPN [RFC4364] environments.

1.1.  Terminology

   This document uses the terms "Address Family Identifier (AFI)" and
   "Subsequent Address Family Identifier (SAFI)".  In the context of
   this document, the meaning of these terms is the same as in
   [RFC4760].

   This document also uses the terms "VPN IP default route"," V-hub" and
   "V-spoke".  In the context of this document, the meaning of these
   terms is the same as in [I-D.ietf-l3vpn-virtual-hub].

Jeng, et al.             Expires March 19, 2014                 [Page 2]
Internet-Draft            ORF Shortest Conveing           September 2013

2.  CP-ORF Encoding

   [RFC5291] augments the BGP ROUTE-REFRESH message so that it can carry
   ORF entries.  When the ROUTE-REFRESH message carries ORF entries, it
   includes the following fields:

   o  AFI

   o  SAFI

   o  When-to-refresh (IMMEDIATE or DEFERRED)

   o  ORF Type

   o  Length (of ORF entries)

   The ROUTE-REFRESH message also contains a list of ORF entries.  Each
   ORF entry contains the following fields:

   o  Action (ADD, REMOVE, or REMOVE-ALL)

   o  Match (PERMIT or DENY)

   The ORF entry may also contain Type-specific information.  Type-
   specific information is present only when the Action is equal to ADD
   or REMOVE.  It is not present when the Action is equal to REMOVE-ALL.

   When the BGP ROUTE-REFRESH message carries CP-ORF entries, the
   following conditions must be true:

   o  ORF Type MUST be equal to CP-ORF.  (The value of CP-ORF is TBD.
      See Section 5 for details.)

   o  AFI MUST be equal to either IPv4 or IPv6

   o  SAFI MUST be equal to "MPLS-labeled VPN address" [IANA.SAFI]

   o  Match field MUST be equal to PERMIT

   Figure 1 depicts the encoding of the CP-ORF type-specific
   information.

                  +--------------------------------+
                  |       Sequence (32 bits)       |
                  +--------------------------------+
                  |   VPN Route Target (64 bits)   |
                  +--------------------------------+
                  |  Import Route Target (64 bits) |

Jeng, et al.             Expires March 19, 2014                 [Page 3]
Internet-Draft            ORF Shortest Conveing           September 2013

                  +--------------------------------+
                  | Host Address (32 or 128 bits)  |
                  +--------------------------------+

                  Figure 1: CP-ORF Type-specific Encoding

   The Sequence field specifies the relative ordering of the entry among
   all CP-ORF entries.

   The VPN Route Target field is used by the recipient of CP-ORF to
   identify the set of routes to which CP-ORF applies.  See Section 3
   for details.

   The Import Route Target also is used by the recipient of CP-ORF.  The
   CP-ORF recipient marks routes selected by CP-ORF with the value of
   the Route Target extended community before advertising them to the
   originator of the CP-ORF.  See Section 3 for details.

   If the AFI field in the ROUTE-REFRESH message is equal to IPv4, the
   Host Address field MUST contain exactly 32 bits and MUST represent an
   IPv4 host address.  If the AFI field in the ROUTE-REFRESH message is
   equal to IPv6, the Host Address field MUST contain exactly 128 bits
   and MUST represent an IPv6 host address.

3.  Processing Rules

   When a BGP speaker receives a ROUTE-REFRESH message that contains a
   CP-ORF, and that ROUTE-REFRESH message that violates any of the
   encoding rules specified in Section 2, the BGP speaker MUST log the
   event and ignore the entire ROUTE-REFRESH message.

   Otherwise, the BGP speaker processes each CP-ORF entry as indicated
   by the Action field.  If the Action is equal to ADD, the BGP speaker
   adds a CP-ORF entry in the position specified by the Sequence field.
   If the Action is equal to REMOVE, the BGP speaker removes a CP-ORF
   entry.  If the Action is equal to REMOVE-ALL, the BGP speaker removes
   all CP-ORF entries.

   Whenever the BGP speaker advertises routes to a peer, it evaluates
   each route in terms of each CP-ORF entry received from that peer.  A
   route matches the selection criteria of a CP-ORF if the following
   statements are true:

   o  the route is more specific than a /64 (i.e., the route more
      specific than an IP VPN default route)

   o  the route carries RT whose value is the same as the CP-ORF VPN
      Route Target

Jeng, et al.             Expires March 19, 2014                 [Page 4]
Internet-Draft            ORF Shortest Conveing           September 2013

   o  the route covers the CP-ORF Host Address

   When evaluating whether the route covers the CP-ORF Host Address, the
   BGP speaker ignores Route Distinguishers.  For example, assume that
   the CP-ORF Host Address is equal to 192.0.2.1.  Assume also that the
   RIB contains routes for the following IPv4 VPN prefixes, and that all
   of these routes carry an RT whose value is the same as the CP-ORF VPN
   Route Target:

   o  1:0.0.0.0/64.

   o  2:192.0.2.0/88

   o  3:192.0.2.0/89

   For the purposes of this search, 2:192.0.2.0/88 and 3:192.0.2.0/89
   cover 192.0.2.1.  This is because the search algorithm ignores Route
   Distinguishers.  However, 1:0.0.0.0/64 does not cover 192.0.2.1,
   because the search algorithm requires a prefix length greater than /
   64.

   If a route matches the selection criteria of a CP-ORF, the BGP
   speaker places the route into the Adj-RIB-Out associated with the
   peer from which CP-ORF was received.  When placing the route into the
   Adj-RIB-Out, the speaker applies the following rules:

   o  all BGP attributes except for Route Targets are unchanged

   o  The Route Target specified by the CP-ORF Import Route Target is
      added to the list or Route Targets that the route already carries

   As a result of placing the route into the Adj-RIB-Out, the route is
   advertised to the peer.

4.  Applicability In Virtual Hub-and-Spoke VPNs

   In a Virtual Hub-and-Spoke environment, VPN sites are attached to
   Provider Edge (PE) routers, V-hubs and V-spokes.  PE routers, V-hubs
   and V-spokes can exchange VPN routes through an iBGP mesh.
   Alternatively, they can exchange customer routes using Route
   Reflectors (RR).

   For the purposes of this document, assume that RED-VPN sites are
   attached to PE routers, V-hub1 and V-spoke1.  All of these devices
   advertise RED-VPN routes to a RR.  They mark these routes with a
   route target, which we will call RT-RED.

Jeng, et al.             Expires March 19, 2014                 [Page 5]
Internet-Draft            ORF Shortest Conveing           September 2013

   V-hub1 serves the RED-VPN.  Therefore, V-hub1 advertises a VPN IP
   default route for the RED-VPN to the RR, carrying the route target
   RT-RED-FROM-HUB1.

   V-spoke1 establishes a BGP session with the RR, negotiating the CP-
   ORF capability, as well as the Multiprotocol Extensions Capability
   [RFC2858] . Upon establishment of the BGP session, the RR does not
   advertise any routes to V-spoke1.  The RR will not advertise any
   routes until it receives either a ROUTE-REFRESH message or a BGP
   UPDATE message containing a Route Target Membership NLRI [RFC4684].

   Immediately after the BGP session is established, V-spoke1 sends the
   RR a BGP UPDATE message containing a Route Target Membership NLRI.
   The Route Target Membership NLRI specifies RT-RED-FROM-HUB1 as its
   route target.  In response to the BGP-UPDATE message, the RR
   advertises the VPN IP default route for the RED-VPN to V-spoke1.
   This route still carries the route target RT-RED-FROM-HUB1.  V-spoke1
   subjects this route to its import policy and accepts it because it
   carries the route target RT-RED-FROM-HUB1.

   Now, V-spoke1 begins normal operation, sending all of its traffic
   through V-hub1.  At some point, V-spoke1 determines that it might
   benefit from a more direct route to a destination.  (Criteria by
   which V-spoke1 determines that it needs a more direct route are
   beyond the scope of this document.)

   In order to discover a more direct route, V-spoke1 assigns a unique
   numeric identifier to the flow.  V-spoke1 then sends a ROUTE-REFRESH
   message to the RR, containing the following information:

   o  AFI is equal to IPv4 or IPv6, as appropriate

   o  SAFI is equal to "MPLS-labeled VPN address"

   o  When-to-refresh is equal IMMEDIATE

   o  Action is equal to ADD

   o  Match is equal to PERMIT

   o  ORF Type is equal to CP-ORF

   o  CP-ORF Sequence is equal to the identifier associated with the
      flow

   o  CP-ORF VPN Route Target is equal to RT-RED

   o  CP-ORF Import Route Target is equal to RT-RED-FROM-HUB1

Jeng, et al.             Expires March 19, 2014                 [Page 6]
Internet-Draft            ORF Shortest Conveing           September 2013

   o  CP-ORF Host Address is equal the destination address associated
      with the flow

   Upon receipt of the ROUTE-REFRESH message, the RR must ensure that it
   carries all routes belonging to the RED-VPN.  In at least one special
   case, where all of the RR clients are V-spokes and none of the RR
   clients are V-hubs, the RR will lack some or all of the required RED-
   VPN routes.  So, the RR sends a BGP UPDATE message containing a Route
   Target Membership NLRI for VPN-RED to all of its peers.  This causes
   the peers to advertise VPN-RED routes to the RR, if they have not
   done so already.

   Next, the RR installs the CP-ORF and refreshes routes for V-spoke1.
   If the RR maintains any routes matching the CP-ORF selection
   criteria, it advertises those routes.  As it advertises those routes,
   it adds the CP-ORF Import Route Target to the list of route targets
   that they carry.  The advertised routes may specify either V-hub1 or
   any other node as the NEXT-HOP.

   V-spoke1 subjects the advertised routes to its import policy and
   accepts them because they carry the route target RT-RED-FROM-HUB1.

   V-spoke1 may repeat this process whenever it discovers another flow
   that might benefit from a more direct route to its destination.

4.1.  CP-ORF Clean-up

   Each CP-ORF consumes memory and compute resources on the device that
   supports it.  Therefore, in order to obtain optimal performance, the
   V-spoke periodically evaluates all CP-ORFs that it has originated and
   removes unneeded CP-ORFs.  The V-spoke determines that a CP-ORF is
   unneeded if its forwarding table includes no route satisfying the
   following criteria:

   o  Covers the CP-ORF Host Address

   o  Carries the same route target as the CP-ORF VPN Route Target

   o  Has prefix length greater than 64 (i.e., is not a default route)

   o  Has NEXT-HOP different from that of any VPN IP default route
      (i.e., different from any V-hub with which the V-Spoke is
      associated)

   When the V-spoke finds an unneeded CP-ORF, it removes the CP-ORF, as
   described below, and adds CP-ORF Host Address to a list of addresses
   known to be reachable only through the V-hub.  The Host Address
   remains on that list for a configurable period of time.  While the

Jeng, et al.             Expires March 19, 2014                 [Page 7]
Internet-Draft            ORF Shortest Conveing           September 2013

   Host Address is on that list, flows directed toward it will not be
   considered as candidates for a more direct route.

   Also, the V-spoke removes all CP-ORFs when a configurable period of
   time has elapsed since their installation.  When it does this, it
   does not add CP-ORF Host Address to the list of addresses known to be
   reachable only through a V-hub.  If the V-spoke once again determines
   that a flow directed towards the Host Address might benefit from a
   more direct route, it will send another CP-ORF.

   In order to removed unneeded CP-ORFs, the V-spoke sends a single
   ROUTE Refresh message containing the following information:

   o  AFI is equal to IPv4 or IPv6, as appropriate

   o  SAFI is equal to "MPLS-labeled VPN address"

   o  When-to-refresh is equal IMMEDIATE

   o  Action is equal to REMOVE

   o  Match is equal to PERMIT

   o  ORF Type is equal to CP-ORF

   o  A list of CP-ORFs, with one element representing each unneeded CP-
      ORF

   The recipient of this message responds to it as described in
   [RFC5291].

5.  IANA Considerations

   IANA is requested to assign a All Covering Prefixes ORF Type from the
   BGP Outbound Route Filtering (ORF) Types Registry.

6.  Security Considerations

   Each CP-ORF consumes finite memory and compute resources on the
   control plane of the V-hub.  Therefore, the V-hub MUST take the
   following steps to protect itself from oversubscription:

   o  When negotiating the ORF capability, advertise willingness to
      receive the CP-ORF only to known, trusted iBGP peers

   o  Enforce a per-peer limit on the number of CP-ORFs that can be
      installed at any given time.  Ignore all requests to add CP-ORFs
      beyond that limit

Jeng, et al.             Expires March 19, 2014                 [Page 8]
Internet-Draft            ORF Shortest Conveing           September 2013

7.  Acknowledgements

   The authors wish to acknowledge Han Nguyen and James Uttaro for their
   comments and contributions.

8.  Normative References

   [I-D.ietf-l3vpn-virtual-hub]
              Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter,
              Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS
              VPNs", draft-ietf-l3vpn-virtual-hub-08 (work in progress),
              July 2013.

   [IANA.SAFI]
              IANA, "abbrev="Subsequent Address Family Identifiers
              (SAFI) Parameters"", , <http://www.iana.org/assignments/
              safi-namespace/safi-namespace.xhtml#safi-namespace-2>.

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

   [RFC2858]  Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
              "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

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

   [RFC4684]  Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
              R., Patel, K., and J. Guichard, "Constrained Route
              Distribution for Border Gateway Protocol/MultiProtocol
              Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
              Private Networks (VPNs)", RFC 4684, November 2006.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760, January
              2007.

   [RFC5291]  Chen, E. and Y. Rekhter, "Outbound Route Filtering
              Capability for BGP-4", RFC 5291, August 2008.

   [RFC5292]  Chen, E. and S. Sangli, "Address-Prefix-Based Outbound
              Route Filter for BGP-4", RFC 5292, August 2008.

Authors' Addresses

Jeng, et al.             Expires March 19, 2014                 [Page 9]
Internet-Draft            ORF Shortest Conveing           September 2013

   Huajin Jeng
   AT&T

   Email: hj2387@att.com

   Ron Bonica
   Juniper Networks
   2251 Corporate Park Drive
   Herndon, Virginia  20170
   USA

   Email: rbonica@juniper.net

   Yakov Rekhter
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, California  94089
   USA

   Email: yakov@juniper.net

Jeng, et al.             Expires March 19, 2014                [Page 10]