Re: [Idr] ietf-104 responding to Rüdiger's comment about bfd strict mode

Robert Raszuk <> Thu, 28 March 2019 12:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BADE1202CE for <>; Thu, 28 Mar 2019 05:23:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id obxF4ftIXiBP for <>; Thu, 28 Mar 2019 05:23:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9C0B7120296 for <>; Thu, 28 Mar 2019 05:23:29 -0700 (PDT)
Received: by with SMTP id w30so22738562qta.8 for <>; Thu, 28 Mar 2019 05:23:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hB/P0pwvepttszJTcOifQ4TFo1c8Yvp5Zw+Ba7L9dak=; b=EaA+J6BcbGUPurrzTz++4XqLp28RUSsMOH8d6jhmfXd9Da5/zYrft+C82HhFangp7/ h+76DBoxm74PeT1OG5ucnXOVEVQmGP9O6LBFw4qSAbfL/6OlG947KxGjM8A8+sbVCTnD Kcmh8lOUe/wv/mi+CNCGQshzcp6b6xgTBWkbaHAouxFbTA2yorTTfxDQDNH9fPQYIlr4 qDFZe0+h908ENi7E4ceGvccyX6dQVerueNkusIXAyHAyVrOpLHJCWBt5kYGnoIDi4oAo AWvLGXk5pzJFFLyFi/0F752wZ9gqLOQQC+5uNBJNuGEk+wx+zn7B0kbX3O/JDKWdW0zE Caxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hB/P0pwvepttszJTcOifQ4TFo1c8Yvp5Zw+Ba7L9dak=; b=E42ivNbkWBK7qFQpmeu5zTQU7k5p0jzIv+c1iUnWfBEgebFon4JfKFtDwSZSKV/ApR ny5Wwf/uw5rI7Nx0jB9RrDNrgH+exF1DHiyCi6wW0oF6oOJV7bQ5LHruMURhEJSN7t/F unhp782u8mwxmEMbUSyDy+rmPvdYpuRaVERLnhCQl8Xdl6LSFm5stptN5mG4Pr7X5aXL 7ho12HcaNQzws15E9ymzYKqSf7SDGYfBSdMY8zeJS5QgoL2Dzxkj+rcdu5kxdrZ7ebyn vIAwtFe1oYYObQ7oW9VJfhEdSds/Tiub4+dGLqJ5A+m22UKforCv72S0MGFUqX3n4Z+A MUzA==
X-Gm-Message-State: APjAAAWANKCE3RL4ZTJsEakfEu70YAr4OoFPqsd3hBpNBkty5dvRuSJh PIYlZa2xZFP7XJtQ1Kuay3EZTxdvOPLLald1gBo27g==
X-Google-Smtp-Source: APXvYqy124woeK1KJlZbF94mUH2anRPMKlPO9naThKOrpY7aRcOuoggje7GCZ2EwigV10OiNICQGv7o6xuRoeC8OYCA=
X-Received: by 2002:a0c:a8d5:: with SMTP id h21mr1687466qvc.124.1553775808659; Thu, 28 Mar 2019 05:23:28 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Thu, 28 Mar 2019 13:23:14 +0100
Message-ID: <>
To: Jeffrey Haas <>
Cc: "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="00000000000022d6460585269fb2"
Archived-At: <>
Subject: Re: [Idr] ietf-104 responding to Rüdiger's comment about bfd strict mode
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 28 Mar 2019 12:23:33 -0000

Let's also observe that while strict mode works fine for IGPs for BGP in
general it may be cause of a bit of surprise.

Imagine this is used on IBGP side and sessions to RR are getting dropped
while there is nothing wrong with reachability and quality of paths to
actual next hops.

Therefor shouldn't this discussion be moved a bit up to enhance the way we
validate the quality of next hop reachability before using paths containg
them vs heavy hammer to put the actual session down ?

I am sure Rajiv can be happy to enhance his proposal along those lines.

Unless this is only for p2p ebgp session I am not sure this proposal of bgp
strict mode as presented today is actually a good idea.


On Thu, Mar 28, 2019, 13:04 Robert Raszuk <> wrote:

> Hi,
> As commented on the mic for partially loosy links I would like to see
> hooks in BGP outside of BFD to determine if BGP session is to be
> established or torn down.
> Specifically using existing tools like rpm or ip sla probes ...
> Thx
> R.
> On Thu, Mar 28, 2019, 12:19 Jeffrey Haas <> wrote:
>> In IETF 104, Rüdiger responded that he'd like to see BFD in BGP be used to
>> prove that a link is "stable enough" before we even announce routes.
>> As I mentioned at the mic, the critical issue is that we have varying
>> implementations of when BFD must be up in differing implementations with
>> regard to the BGP FSM.  E.g. Up before we start the transport session
>> (Connect), or Up before we transition to Established, or Up after
>> Established.
>> The proposal from Mercia and Acee effective summ to "if BFD strict
>> negotiated, wait for BFD to come up before transition to Established".
>> This
>> provides a common point for implementations to interoperate.  There is
>> still
>> potentially issue with older implementations that relied on BFD to be Up
>> before BGP starts its TCP session; however upon supporting this feature we
>> implicitly add an option where the behavior is changed.
>> Back to Rüdiger's point: He has a desire that the session is stable before
>> we start announcing routes.  In BGP RFC parlance, we do not exchange our
>> routes in the Update-Send process until stability is declared.
>> While this is doable, how do you negotiate what level of stability is
>> desired?  BFD, without extensions, mostly will simply declare the session
>> Down when enough packets are lost.  If the link quality is very bad, this
>> should happen quite quickly. If the link quality is partially lossy, BFD
>> doesn't help.  (However, see
>> -- Jeff
>> _______________________________________________
>> Idr mailing list