[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                                J. Durand
Internet-Draft                                                     CISCO
Intended status: Standards Track                             D. Freedman
Expires: September 10, 2015                                     Claranet
                                                           March 9, 2015

           Path validation toward BGP next-hop with AUTO-BFD


   This document describes a solution called AUTO-BFD, that
   automatically initiates BFD sessions for BGP next-hops.  This makes
   it possible to avoid blackholing scenarios when a BGP peer is not the
   BGP next-hop, especially on Internet eXchange Points (IXPs) when BGP
   Route-Servers are deployed.  When they are configured with this
   mechanism, routers can automatically try to establish a new adjacency
   for every new BGP next-hop.  BGP routes are then checked against the
   state of the BFD session for the corresponding next-hop.


   A placeholder to list general observations about this document.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [1].

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 10, 2015.

Durand & Freedman      Expires September 10, 2015               [Page 1]

Internet-Draft                  AUTO-BFD                      March 2015

Copyright Notice

   Copyright (c) 2015 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.  Definitions and Accronyms . . . . . . . . . . . . . . . . . .   3
   3.  Solution Requirements . . . . . . . . . . . . . . . . . . . .   3
   4.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .   4
   5.  BFD Session Ageing  . . . . . . . . . . . . . . . . . . . . .   5
   6.  Possible other use cases  . . . . . . . . . . . . . . . . . .   6
   7.  Future Work . . . . . . . . . . . . . . . . . . . . . . . . .   6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   7
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     11.2.  Informative References . . . . . . . . . . . . . . . . .   7
   Appendix A.  Configuration  . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Internet eXchange Points (IXPs) implement BGP Route-Servers (RS) [5]
   so that connected members do not need to configure BGP peerings with
   every other member to exchange routes.  Through a single peering with
   the RS, a member can receive routes of all the other members peering
   with the RS.  The RS redistributes routes and could simply be
   described as a Route-Reflector for eBGP peerings.

   Usually, deployed RS do not modify the BGP next-hop of exchanged
   routes so traffic exchanged between IXP members does not pass through
   the RS, which keeps only a control-plane role, exactly as for a BGP
   RR.  The drawback is that it may happen that a peering stays up
   between members and route-server while there is no connectivity
   between members.  This results in black holes for members with no

Durand & Freedman      Expires September 10, 2015               [Page 2]

Internet-Draft                  AUTO-BFD                      March 2015

   easy troubleshooting: usually upon such problem a member just shuts
   its connectivity to the IXP.  This situation has happened several
   times on many different IXPs and many members do not want to peer
   with route-servers for this reason.

                       EBGP UP---->  RS <-------EBGP UP
                           |              |               |
                       |              |               |
                  ----------------IXP LAN---------------------
                       |   |                       |  |
                       V   |                       |  V
                     Member 1 <================> Member 2

                                 Figure 1

   This proposal intends to solve this situation with the automation of
   BFD adjacency creation when new BGP next-hops are discovered.  When
   configured with this solution, routers can automatically try to
   establish a new adjacency for every new BGP next-hop.  BGP routes are
   then checked against the BFD session states for the corresponding

2.  Definitions and Accronyms

   o  BFD: Bidirectional Forwarding Detection protocol [3][4]

   o  BGP: Border Gateway Protocol [2]

   o  IXP: Internet eXchange Point

   o  RR: Route Reflector (BGP Route-Reflector)

   o  RS: Route Server (BGP Route-Server) [5]

3.  Solution Requirements

   The following requirements apply to the solution described in this

   o  The solution MUST be independent of the BGP route-server's
      configuration.  In other words IXP members SHOULD be able to check
      each other's liveliness without anything configured on the route-

Durand & Freedman      Expires September 10, 2015               [Page 3]

Internet-Draft                  AUTO-BFD                      March 2015

   o  Solution MUST NOT imply a configuration per IXP member.  Each IXP
      member SHOULD automatically discover other members and
      automatically start probing when this is possible.

   o  The solution MUST accept situations when not all the IXP members
      do not implement it.  In other words the implementation of this
      mechanism on one of the IXP member MUST NOT impact the other

   o  The solution SHOULD rely on a widely adopted host liveliness
      verification protocol in the context of BGP peerings.  The used
      host liveliness mechanism MUST be negotiated between members to
      avoid false positives.

   o  The solution SHOULD be as simple as possible and SHOULD NOT
      require the design of a new protocol.

   Based on these requirements, the following is suggested:

   o  BFD [3] (Bidirectional Forwarding Detection) is an appropriate
      liveliness verification mechanism that IXP members can use to
      check their mutual status.  It is widely adopted in the Internet
      community for this use and its scalability on modern routers makes
      it suitable for IXPs.  Also BFD integrates an initial negotiation
      phase that makes it appropriate to interdomain scenarios, when all
      routers are not configured with the same options.

   o  IXP members cannot easily rely on an existing protocol to announce
      their mutual capability to support a host liveliness protocol.
      Since IXP members using BGP RS do not directly establish BGP
      peerings between them, any use of BGP to announce BFD capability
      would require solution support on the BGP RS which would prevent
      any usage on an IXP not implementing it.  Solutions based on
      optional transitive BGP attribute have been studied [6] and showed
      some complexity and privacy challenges as it could force every
      member to disclose topology information globally to the
      downstreams of other IXP members.

4.  Solution Overview

   The solution proposed in this document, named AUTO-BFD, is
   straightforward and relies on existing mechanisms.  It works as

   o  AUTO-BFD is configured on the BGP peering to the BGP RS.

   o  Every time a new BGP next-hop is received from this peering, AUTO-
      BFD triggers a new BFD session with this next-hop (or reinstates

Durand & Freedman      Expires September 10, 2015               [Page 4]

Internet-Draft                  AUTO-BFD                      March 2015

      an existing session, see Section 5).  The operation mode for this
      BFD session MUST be asynchronous.  Timers can be locally
      configured.  Optional security configuration can limit the number
      of authorized adjacencies or trigger BFD only for next-hops in a
      given prefix.  Other optional configuration can define the BFD

   o  Routes coming from the AUTO-BFD enabled BGP neighbor are then
      checked based on the BGP next-hop and its BFD session state.
      Acceptance of routes is then subject to the administrative policy
      based on BFD session state.  An example of such a policy can be
      found in appendix Appendix A

5.  BFD Session Ageing

   In order to maintain the relevance of AUTO-BFD sessions, it is
   required to prune sessions when they are not needed anymore.  A
   router X may not simply prune BFD session toward Y when there are no
   more routes with corresponding next-hop Y as the BFD session may
   still be needed by the Y to accept route from X.

   The following solution makes it possible to prune BFD sessions only
   when it is sure the remote end does not need it anymore.  A per-
   session timer (bfd.AutoAge) is defined to determine an interval.
   This timer MAY derive its configuration from a global value in an
   implementation.  The timer counts down until it expires, at which
   point, the relevant AUTO-BFD session is checked against next-hop
   information received from the AUTO-BFD configured BGP session to
   determine if there are still next hops received which relate to the
   session.  Based on the information, the following occurs:

   o  If next-hops for the remote system are still being received,
      bfd.LocalDiag should be set to XX, which will set the appropriate
      diagnostic code "XX - Continuing AUTO-BFD" (to be assigned by
      IANA) in the outgoing control packet, to indicate that the next
      hop continues to be seen and used by this system.  At this point,
      the timer is reset and no further action is taken until it expires

   o  If next-hops for the remote system are no longer being received,
      the following occurs:

      *  If the session is still up (bfd.Sessionstate is UP) and a
         control packet arrives which would not change the state, but
         with the flag "XX - Continuing AUTO-BFD" set, this indicates
         that the remote system is still receiving routes with the local
         system as the next hop.  In this case, the session MUST remain

Durand & Freedman      Expires September 10, 2015               [Page 5]

Internet-Draft                  AUTO-BFD                      March 2015

         up, the timer is reset and no further action is taken until it
         expires next.

      *  If the session is still up (bfd.Sessionstate is UP) and a
         control packet arrives which would not change the state, but
         does not set the "XX - Continuing AUTO-BFD" diagnostic flag,
         then we must consider that the remote system is no longer
         receiving routes with the local system as next hop.  In this
         case, the bfd.LocalState should be set to 'AdminDown' and the
         session should be placed in an Administrative Down state.

   When a session is first established (or indeed re-established as per
   Section 4), it is important that the bfd.LocalDiag should be set to
   XX to ensure that control packets start to signal this state to the
   remote system.

6.  Possible other use cases

   While the primary focus of the authors is to solve the issue met with
   BGP route-servers on IXPs described in section Section 1, the
   proposed solution may also apply to the following use cases:

   o  IBGP Route-Reflector (RR): the scenario described for BGP RS could
      also apply for IBGP RR.  The solution described in this draft
      could be used to validate received IBGP routes against real
      reachability of BGP next-hop (a router in same AS in case next-hop
      self is used, or the EBGP next-hop announcing the route.

   o  Any EBGP peering: the proposed solution would enable automatic BFD
      auto-deployment on every EBGP peering.  AUTO-BFD would
      automatically "harden" the peering without the need of any
      additional configuration.

7.  Future Work

   Following points may need to be documented further in next versions
   of this document based on comments received by the community:

   o  AUTO-BFD interoperability with manual BFD sessions.

   o  S-BFD integration

   o  Security considerations

Durand & Freedman      Expires September 10, 2015               [Page 6]

Internet-Draft                  AUTO-BFD                      March 2015

8.  Acknowledgements

   The authors would like to thank the following people for their
   comments and support: [TBD].

9.  IANA Considerations

   This memo requests a code point from the registry for BFD diagnostic
   codes [3]: XX -- Continuing Auto-BFD

10.  Security Considerations


11.  References

11.1.  Normative References

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

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

   [3]        Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, June 2010.

   [4]        Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June

   [5]        "Internet Exchange Route Server",

11.2.  Informative References

   [6]        "Path validation toward BGP next-hop",

Appendix A.  Configuration

   This configuration in classic Cisco IOS style will help reader
   understand the way AUTO-BFD can be integrated in current deployments.

Durand & Freedman      Expires September 10, 2015               [Page 7]

Internet-Draft                  AUTO-BFD                      March 2015

   router bgp 65001
    neighbor remote-as 65102
    address-family ipv4 unicast
     neighbor activate
     neighbor auto-bfd
     neighbor route-map FROM-RS in
   route-map FROM-RS permit 10
    match next-hop bfd-session-state Up
    set local-pref 120
   route-map FROM-RS deny 20
    match next-hop bfd-session-state Down Init
   route-map FROM-RS permit 30
    match next-hop bfd-session-state AdminDown
    set local-pref 50

                                 Figure 2

Authors' Addresses

   Jerome Durand
   CISCO Systems, Inc.
   11 rue Camille Desmoulins
   Issy-les-Moulineaux  92782 CEDEX

   Email: jerduran@cisco.com

   David Freedman
   21 Southampton Row, Holborn
   London  WC1B 5HA

   Email: david.freedman@uk.clara.net

Durand & Freedman      Expires September 10, 2015               [Page 8]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/