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

Robert Raszuk <robert@raszuk.net> Thu, 28 March 2019 14:26 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664D21204C4 for <idr@ietfa.amsl.com>; Thu, 28 Mar 2019 07:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7ztlJoduQpX for <idr@ietfa.amsl.com>; Thu, 28 Mar 2019 07:26:24 -0700 (PDT)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42C10120499 for <idr@ietf.org>; Thu, 28 Mar 2019 07:26:24 -0700 (PDT)
Received: by mail-qt1-x835.google.com with SMTP id v20so23228154qtv.12 for <idr@ietf.org>; Thu, 28 Mar 2019 07:26:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1w94o+QlPpn1E856pSiRqNdT2e4zz8aIOeBhkU2J2Nk=; b=RhyJqlBXMyQ0lq0hMN6hyxhxiSK+sM+cVLEqHMIn1YX03BGF4h/5kpaYbvx2kc8v19 nFtx2Vt6bNZGaALn4G462bFVm5tyYMoQt/xbT0/1dAq/L9Dn84UH5LwntYwJkNmwq/5j Mdpqu0y6zHOESvIREbecXnqYugFx1o8vlMhaDDlhognQhZL+qLYbeKDzb0BcBCDSWiAS lyaURIPALyFkDsv2n955CMvTAmws/YIZzxIEg1/mW6tyGw/O8oim5zCckY2Udng4kWvl 0VjftuuguSm1I6lGmcdkry+NbgOxGTjYkkUldYtTkkMEVLg3jPmuIeqO7cNBKE3fGgaN 23pQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1w94o+QlPpn1E856pSiRqNdT2e4zz8aIOeBhkU2J2Nk=; b=q3OMjKSx5wp8gxouKaxJHiEjZSx1uraHMYBE4luQOtOsC8vMFgx37nqtn24dOIJXd2 yS3uKIVl4mTfzX3CNIJRI+f1qbWZqSAWSKghTxaTht1FP3bz+IDg1GpsmuDQbYFXxllO b1p3P6pum0RsKmB++XZhqZ0RsuY/4tBRuh67gDVpua2Xo/5WgSm3Knz3iH4zIFV7xmdB LK6dhhc5Id4Jvbe4ZWpf7ZkU8xDFgGDnY1Vo7rZFbODN05nlfiMI/jYt6Qzmu4I0vLs3 LwYx1FRjz1F0p77KGxTdkmiEYcr62EVs+RPVhWfcn7UXR3rY+hoCPuMjzS0AtbkbvcNq fkoA==
X-Gm-Message-State: APjAAAUUpoMMVDxX0V17qPf06Nkik/qrOH8tR6RRzVmhv9PSjYqfVrOM vPLqDHBUDTpddVP6NLNWUKbLf/U/LcnY819O+IagIA==
X-Google-Smtp-Source: APXvYqxQssB24Mw2Gz64ZRytOZVN+cLz+wSGhfo3lDS8MHpOTx0Io3hihEPIE6Ip4o5hjqoehXhFLupa7yTj6PoA4ww=
X-Received: by 2002:ac8:fb0:: with SMTP id b45mr36565828qtk.293.1553783183310; Thu, 28 Mar 2019 07:26:23 -0700 (PDT)
MIME-Version: 1.0
References: <20190328111833.GB24351@pfrc.org> <CAOj+MMGorV9StNVCvDyHgHHTdg+u0EQ0VDT-L6AVVUQTKGkwfQ@mail.gmail.com> <FBE4CC86-EE29-4E44-AC27-171D4DDD8FEC@cisco.com>
In-Reply-To: <FBE4CC86-EE29-4E44-AC27-171D4DDD8FEC@cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 28 Mar 2019 15:26:09 +0100
Message-ID: <CAOj+MMGcKsuEomSBw_1MtaYwND4+VQjE2LjqEBAeoHKvpeA3DA@mail.gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: Jeffrey Haas <jhaas@pfrc.org>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b316a505852856c6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/WLqPa3_MCWMK9axGVwmQ7HnHlkc>
Subject: Re: [Idr] =?utf-8?q?ietf-104_responding_to_R=C3=BCdiger=27s_comment_?= =?utf-8?q?about_bfd_strict_mode?=
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Mar 2019 14:26:38 -0000

Acee,

Yes you have bfd for bgp. Use case is for ebgp to bring bgp down as soon as
your peer goes down without cranking up bgp keepalives.

Well as it was presented today the scope of current proposal is much
broader. Hence the comments.

And as far as the draft here you go:

draft-ietf-idr-bgp-bestpath-selection-criteria-10

Each bgp implementation knows how to validate next hops quite efficiently
so if we extend it with proper criteria IMO overall we will be much better
off.

Said this I continue to believe that using BFD for liveness detection of
all bgp sessions (including ibgp) is not always a good idea.

Many thx,
R.


On Thu, Mar 28, 2019, 14:52 Acee Lindem (acee) <acee@cisco.com> wrote:

> Hi Robert,
>
> As was discussed, manually configured BFD strict mode exist today. This is
> simply adding BGP signaling to these techniques.
>
>
>
> *From: *Idr <idr-bounces@ietf.org> on behalf of Robert Raszuk <
> robert@raszuk.net>
> *Date: *Thursday, March 28, 2019 at 8:06 AM
> *To: *Jeff Haas <jhaas@pfrc.org>
> *Cc: *IDR List <idr@ietf.org>
> *Subject: *Re: [Idr] ietf-104 responding to Rüdiger's comment about bfd
> strict mode
>
>
>
> 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 ...
>
>
>
> We await your draft 😉
>
>
>
> Thanks,
>
> Acee
>
>
>
> Thx
>
> R.
>
>
>
> On Thu, Mar 28, 2019, 12:19 Jeffrey Haas <jhaas@pfrc.org> 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
> https://tools.ietf.org/html/draft-am-bfd-performance-00)
>
> -- Jeff
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>