Unsolicited BFD for Sessionless Applications
draft-chen-bfd-unsolicited-03

Document Type Active Internet-Draft (candidate for bfd WG)
Last updated 2018-11-08 (latest revision 2018-08-03)
Stream IETF
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream WG state Call For Adoption By WG Issued
Document shepherd No shepherd assigned
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           E. Chen
Internet Draft                                                  N. Shen
Intended Status: Informational                            Cisco Systems
Expiration Date: February 4, 2019                             R. Raszuk
                                                           Bloomberg LP
                                                         August 3, 2018

              Unsolicited BFD for Sessionless Applications
                   draft-chen-bfd-unsolicited-03.txt

Status of this Memo

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

   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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on February 4, 2019.

Copyright Notice

   Copyright (c) 2018 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

Chen, Shen & Raszuk                                             [Page 1]

Internet Draft      draft-chen-bfd-unsolicited-03.txt        August 2018

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Abstract

   For operational simplification of "sessionless" applications using
   BFD, in this document we present procedures for "unsolicited BFD"
   that allow a BFD session to be initiated by only one side, and be
   established without explicit per-session configuration or
   registration by the other side (subject to certain per-interface or
   per-router policies).

1. Introduction

   The current implementation and deployment practice for BFD ([RFC5880]
   and [RFC5881]) usually requires BFD sessions be explicitly configured
   or registered on both sides. This requirement is not an issue when an
   application like BGP [RFC4271] has the concept of a "session" that
   involves both sides for its establishment.  However, this requirement
   can be operationally challenging when the prerequisite "session" does
   not naturally exist between two endpoints in an application.
   Simultaneous configuration and coordination may be required on both
   sides for BFD to take effect. For example:

      o When BFD is used to keep track of the "liveness" of the nexthop
        of static routes. Although only one side may need the BFD
        functionality, currently both sides need to be involved in
        specific configuration and coordination and in some cases
        static routes are created unnecessarily just for BFD.

      o When BFD is used to keep track of the "liveness" of the
        third-pary nexthop of BGP routes received from the Route Server
        [RFC7947] at an Internet Exchange Point (IXP).  As the
        third-party nexthop is different from the peering address of
        the Route Server, for BFD to work, currently two routers peering
        with the Route Server need to have routes and nexthops from each
        other (although indirectly via the Router Server), and the
        nexthop of each router must be present at the same time. These
        issues are also discussed in [I-D.ietf-idr-rs-bfd].

   Clearly it is beneficial and desirable to reduce or eliminate
   unnecessary configurations and coordination in these "sessionless"
   applications using BFD.

   In this document we present procedures for "unsolicited BFD" that
   allow a BFD session to be initiated by only one side, and be
   established without explicit per-session configuration or

Chen, Shen & Raszuk                                             [Page 2]

Internet Draft      draft-chen-bfd-unsolicited-03.txt        August 2018

   registration by the other side (subject to certain per-interface or
   per-router policies).

   With "unsolicited BFD" there is potential risk for excessive resource
   usage by BFD from "unexpected" remote systems.  To mitigate such
   risks, several mechanisms are recommended in the Security
Show full document text