IETF Logo Mail Archive

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

Robert Raszuk <robert@raszuk.net> Thu, 28 March 2019 12:04 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 C3795120457 for <idr@ietfa.amsl.com>; Thu, 28 Mar 2019 05:04:33 -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 9jsRgx4fvynp for <idr@ietfa.amsl.com>; Thu, 28 Mar 2019 05:04:31 -0700 (PDT)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 E91A21202E6 for <idr@ietf.org>; Thu, 28 Mar 2019 05:04:30 -0700 (PDT)
Received: by mail-qt1-x834.google.com with SMTP id h39so22718484qte.2 for <idr@ietf.org>; Thu, 28 Mar 2019 05:04:30 -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=iYyPq9V0xYz9HtOc/49sYR1UGs9WR2KljM2rUe9ADaY=; b=RfWj7sDSOM//nikZdVClr50SEvqyxIsG6T7F9fSHrY+iDs+85x0hPe/5enip/D3uv3 8up0blSAaiAYpvVddUR1EuZ5CbOLsZNltiwm+iL5xzpM2y4eI29WQj3ZxaSILHG21dyf DzxGX5paiKUErT920cw4MBeOFE9HZIUuCpazPpvo50AK9v+tAHFdOYGsTjyvjz5VKiNS 6HlVo6UnyU1K39PUGT+BLSbDvSNP2+ydqnNKt4tlmSRRlR+GiSojqsigNA79Bm4b7Y08 Q7HzuoU7OWTpOYAvsg/gABQTQhEGgA/Icr/3zV/0VM8oIRZvlA0kI/dWhcFMCFTrRP3W Jzhg==
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=iYyPq9V0xYz9HtOc/49sYR1UGs9WR2KljM2rUe9ADaY=; b=AZYPpEY2lsGq1gP7QdNVxGledtVAEwFIab1zVZNldJuAvQbUBZz6iGqAhb/56IwPYV 9SyYIzhWuxQnNrjzekY0NEo3pT/TGCh11yQQoDx+XvyGp84RzUmAN/DA87tLghF4MiAj Eq3Okqfpvdu+cCtGq7XGrSQLenBIoP2kActVmCtU6+5SIEiuqVvDiz1VDAlhsY93Fwg0 aH/ohcr6F992y2Bd5BDthoEHEmtxoRYxGeIYBOTLsv7ot5SELCJ8GkJW3KNPw5TtEPFG y51Os5w8lGlW82SIZ1i8XLpQ2xZ/eXe6YP4KW+iNIjELRlRt+fm3FjLB2ojvxu97PLiC dCiA==
X-Gm-Message-State: APjAAAXy3ArwAoDMUlxS+myx82oVxfXGAH5ye08KFuMOHBiZgVOflW27 BnTtph/ET4DkAnbYVDJprZ31BrNQQqA3k7az2gjnqg==
X-Google-Smtp-Source: APXvYqyXtb8AglZxB8V6W1FuYaDn0kGNeFNm8kXxg3CPlyKES3sKHeFiqIo9AicegfLkk192+ZImgWWjtLnL5/rqZGA=
X-Received: by 2002:aed:3fd6:: with SMTP id w22mr36591841qth.361.1553774669882; Thu, 28 Mar 2019 05:04:29 -0700 (PDT)
MIME-Version: 1.0
References: <20190328111833.GB24351@pfrc.org>
In-Reply-To: <20190328111833.GB24351@pfrc.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 28 Mar 2019 13:04:15 +0100
Message-ID: <CAOj+MMGorV9StNVCvDyHgHHTdg+u0EQ0VDT-L6AVVUQTKGkwfQ@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000042b42b0585265bc0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/seHZuVn3gA7S6X9OaXBOpsQB4OM>
Subject: Re: [Idr] ietf-104 responding to Rüdiger's comment 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 12:04:47 -0000

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 <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
>

v2.23.0 | Report a Bug | By Email