Network Working Group                                    Pierre Francois
Internet-Draft                                  Institute IMDEA Networks
Intended status: Informational                            Camilo Cardona
Expires: February 13, 2015               Institute IMDEA Networks / UC3M
                                                            Adam Simpson
                                                          Alcatel-Lucent
                                                            Jeffrey Haas
                                                        Juniper Networks
                                                         August 12, 2014


                       ADD-PATH for Route Servers
                   draft-francois-idr-rs-addpaths-01

Abstract

   BGP speakers at Internet Exchange Points typically exchange routes
   with a large number of peers.  To reduce the burden of maintaining
   many sessions, IXPs implement and administrate BGP route servers.
   Route servers announce to their clients the paths of multiple peers
   by using a single eBGP session.  Route servers, however, are
   restricted to propagating a single path per NLRI per eBGP session.
   This constraint affects the diversity of paths received by clients.
   To overcome this limitation, we propose the extension of ADD-PATH to
   eBGP peers.  ADD-PATH allows a BGP speaker to send multiple paths for
   the same NLRI, typically through different nexthops, over a single
   session with a peer.  By supporting ADD-PATH, a route server hence
   allows a client to potentially select among all the available paths
   for that NLRI, instead of the one arbitrarily chosen by the Route
   Server.

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 February 13, 2015.




Pierre Francois, et al. Expires February 13, 2015               [Page 1]


Internet-Draft         ADD-PATH for Route Servers            August 2014


Copyright Notice

   Copyright (c) 2014 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
   (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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Operation of eBGP ADD-PATH capability for IXP route Server  .   3
     3.1.  Capability  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Path Selection  . . . . . . . . . . . . . . . . . . . . .   4
       3.2.1.  ADD-PATH ALL Policy compliant . . . . . . . . . . . .   4
       3.2.2.  ADD-PATH N Policy compliant . . . . . . . . . . . . .   4
   4.  Error conditions  . . . . . . . . . . . . . . . . . . . . . .   5
   5.  IANA considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   IXP route servers were designed to help network operators reduce the
   difficulties associated with maintaining a large number of sessions
   [IXPRouteServer].  Every route server client can receive paths from
   multiple ASes using the same eBGP session with the route server.  In
   some cases, usually when there are many members in the IXP, multiple
   clients might announce a path to the same NLRI.  Path diversity is an
   advantage for IXPs, as members can choose the path that better suits
   their policy.  However, as a normal eBGP speaker, route servers can
   only advertise a single path per NLRI to each client.  This
   limitation causes the route server to potentially hide paths that
   would be useful for their clients.

   ADD-PATH [AddPath] is a capability that allows BGP speakers to
   announce more than one path to their peers.  Works related to ADD-
   PATH have focused on applications for iBGP deployments.  We propose
   the use of ADD-PATH over eBGP sessions to overcome the problems



Pierre Francois, et al. Expires February 13, 2015               [Page 2]


Internet-Draft         ADD-PATH for Route Servers            August 2014


   associated with the limit on the number of paths that route servers
   can announce.  In this document, we define the operation and error
   conditions of ADD-PATH for these scenarios and describe additional
   benefits for the route servers that implement it.

2.  Motivation

   By collecting paths from all their clients, route servers potentially
   accumulate various paths for some destination prefix.  Multiple of
   these paths may be compliant with the policy of some clients of the
   route server.  However, route servers typically maintain a single
   session with their clients, and hence advertise at most a single path
   towards each of them.  As a result, a route server client will
   typically know only one of these paths.  In some cases, depending on
   the implementation of the IXP route server, the route server client
   would not even receive a path for the NLRI.  Refer to
   [IXPRouteServer] for an explanation of this problem.

   We believe that this aspect of route serving is an unfortunate
   limitation, as it artificially hides paths from clients that may have
   wanted to use them.

   First, it prevents the member from performing a policy based decision
   that is finer than the one advertised to the route server platform.
   That is, the arbitrary best path picked among the policy-compliant
   ones by the route server may be actually different from the one that
   the client would have picked, had it known about all of them.

   Second, it prevents the member from doing temporary preference
   tweaking among the set of available paths in order to perform traffic
   engineering.  That is, a member may only receive a path for a
   destination through a peer that is saturated, while alternate paths
   through non-saturated nexthops are available and would have been used
   if the router (and the operator) were aware of their existence.

   ADD-PATH was designed to advertise more than one path towards a given
   NLRI.  Multiple paths installed in the forwarding planes, as well as
   alternate paths, can be advertised among speakers supporting ADD-
   PATH.  ADD-PATH can be used by a route server to announce all paths
   available for the same NLRI that still fulfill the policy of the
   route server client.

3.  Operation of eBGP ADD-PATH capability for IXP route Server








Pierre Francois, et al. Expires February 13, 2015               [Page 3]


Internet-Draft         ADD-PATH for Route Servers            August 2014


3.1.  Capability

   A route server that supports the advertisement of multiple paths
   toward the same NLRI SHOULD announce the ADD-PATH capability to its
   clients.  Likewise, a client supporting the reception of multiple
   paths SHOULD announce the ADD-PATH capability to the route server.

   In an IXP context, only the route server should propagate multiple
   paths to the route server clients.  The advertisement of multiple
   paths in the other direction is currently out of the specification of
   this document.  Therefore, a route Server client should set the Send/
   Receive field for the Add-Path capability with a value of 1.  The
   route Server should set the same field in the capability with a 2.

3.2.  Path Selection

   We describe here two path selection modes that can be implemented by
   the route server.

3.2.1.  ADD-PATH ALL Policy compliant

   A route server supporting ADD-PATH can announce to its clients all
   paths that comply with their policy.  This selection mode is
   denominated as "ADD-PATH ALL Policy compliant".

3.2.2.  ADD-PATH N Policy compliant

   A route server may also support another type of ADD-PATH mode that
   restricts the number of paths per NLRI announced to each client.  For
   instance, the route server would announce at most N paths to their
   clients that comply with their policies.  This mode would help reduce
   the resources needed in the client, in case the number of available
   paths is large.  Note that once the number of policy-compliant paths
   that can be advertised is restricted, a client might not receive the
   best possible path with respect to its own policies.

   The configuration of the number of paths sent to each route server
   client could be done manually or set by the route server client via a
   communication channel.

   The selection of paths is free to the implementation of the route
   server.  Similarly to the ADD-PATH N mode [AddPathGuidelines], the
   route server COULD choose a set of paths equivalent to the one
   obtained after running the BGP best algorithm N times, excluding the
   selected path after each interaction.






Pierre Francois, et al. Expires February 13, 2015               [Page 4]


Internet-Draft         ADD-PATH for Route Servers            August 2014


4.  Error conditions

   In the specific context of route servers, third party nexthops are
   being used to have the client actually be able to select the
   appropriate nexthop.  This is achieved by letting the route server
   leave the nexthop field of the propagated paths unchanged.

   Similarly, the propagation of multiple paths by the route server to
   one of its clients must be made in a way that allows the receiver to
   actually select one among those paths.  As a result, a route server
   advertising two different paths for the same destination, with equal
   nexthops, is out of specification.  If this situation occurs, the
   client SHOULD log the event and let the normal decision process
   decide the best path.

   As described in Section 3.1, the advertisement of multiple paths in
   an IXP environment SHOULD only be performed from the route server to
   its clients.  A route server SHOULD log any case in which a route
   server client signals, through the ADD-PATH capability, its
   willingness to announce more than one path.  The route server SHOULD
   continue to operate under these events, considering all paths
   received from its clients.

5.  IANA considerations

   None

6.  Security Considerations

   The use of eBGP ADD-PATH in the route server environment does not
   increase the number of destinations for which paths are being
   advertised.  However, the potential number of paths per destination
   is now larger than one, potentially increasing the memory load of the
   Adj-Rib-In.  Systems risking to be short on memory due to this
   increase should be configured to constrain the amount of paths being
   advertised to them by a value which ensures proper operations.

7.  References

   [AddPath]  Walton, D., Chen, E., Retana, A., and J. Scudder,
              "Advertisement of Multiple Paths in BGP", draft-ietf-idr-
              add-paths-09.txt (work in progress), October 2013.









Pierre Francois, et al. Expires February 13, 2015               [Page 5]


Internet-Draft         ADD-PATH for Route Servers            August 2014


   [AddPathGuidelines]
              Uttaro, J., Francois, P., Fragassi, R., Simpson, A.,
              Patel, K., and P. Mohapatra, "Best Practices for
              Advertisement of Multiple Paths in IBGP", draft-ietf-idr-
              add-paths-guidelines-06.txt (work in progress), January
              2014.

   [IXPRouteServer]
              Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker,
              "Internet Exchange Route Server", draft-ietf-idr-ix-bgp-
              route-server-05 (work in progress), June 2014.

Authors' Addresses

   Pierre Francois
   Institute IMDEA Networks
   Avda. del Mar Mediterraneo, 22
   Leganes  28918
   ES

   Email: pierre.francois@imdea.org


   Camilo Cardona
   Institute IMDEA Networks / UC3M
   Avda. del Mar Mediterraneo, 22
   Leganes  28918
   ES

   Email: juancamilo.cardona@imdea.org


   Adam Simpson
   Alcatel-Lucent
   600 March Road
   Ontario  K2K 2E6
   CA

   Email: adam.simpson@alcatel-lucent.com


   Jeffrey Haas
   Juniper Networks
   1194 N. Mathilda Ave
   Sunnyvale  94089
   USA

   Email: jhaas@juniper.net



Pierre Francois, et al. Expires February 13, 2015               [Page 6]