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

Robert Raszuk <robert@raszuk.net> Thu, 28 March 2019 15:37 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 98B951204B2 for <idr@ietfa.amsl.com>; Thu, 28 Mar 2019 08:37:09 -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 J3FNA3v4ifxQ for <idr@ietfa.amsl.com>; Thu, 28 Mar 2019 08:37:04 -0700 (PDT)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 5E344120186 for <idr@ietf.org>; Thu, 28 Mar 2019 08:37:04 -0700 (PDT)
Received: by mail-qk1-x72b.google.com with SMTP id c189so12400785qke.6 for <idr@ietf.org>; Thu, 28 Mar 2019 08:37:04 -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=uh/0YDMk3imrpCAAiCgTzUJ5kl5daXZB/h9PW6NgXaY=; b=I7hF405/cvorA5K/Vgdjrzssec2fHHwag09iPrc0663Hw4JM+BzGHdhx3935pt1gBk eZVBElw+hpnmsw3+okl8b/F+wtNTydIPxSzB6pEjAUitKkY31vz6jgI5+vLjZJN30+AV IIN7usscZN2HJvYDf0KxaPmWWbwDvxGBYxlWot1VrprOEjuMW+tY4UymSS8YWu1mevQJ 6tJbWyLF0BCPmDYkWVFf8FDfgswets40WSULDG4dlIOM48peLkUY3K9ObJlgegPaMzD0 jJCdJZNfCC3+D+ZSZJz8A40bZKsVrbIGG2kp726eL4eT/mswLTo9f7ykxeawctY5MRWd RkSw==
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=uh/0YDMk3imrpCAAiCgTzUJ5kl5daXZB/h9PW6NgXaY=; b=MH7xUj6XxVp4S+716pMfivim/F3C0eUjRXx/C9iyCEp34zOh8seUSMcWUv2B/fACMj ImZnp1EXINBrmC7Yu5OM4LrkxosdJOQvdpmNW4Iagtv1FoQDDU7l8GllRfgW3RzabA/2 +o+3N4FlVrn9e+Z0/06WnPtfoyS/Jc182yTTihv0bzot28pIWqny79p3YKabtakPla2z O+iXebXDiEte+75m6AgwzlAoldcx1zCgUax2ERS2u9lnVLVxMN2XxjrcokuauriXkIiI zdtOPgw6pFyLN5tyyiIRHNXSQwh4FbWgNk7t2nwvrY8Fti7SiHbvojT091EzQS78uO5l nWWg==
X-Gm-Message-State: APjAAAWIkJahiB7CxC/YINklWA6miOl3BPM6PHJsj+SpHg8A9hSEned7 NMUl5atVw/P85uCXfa1qREvg7Yy8SpNmM9QEXZUhGQ==
X-Google-Smtp-Source: APXvYqwF7CPLUBSt/rdQPnx3RWRy/208o9h0rK6XRF8kuzhI7Y5s6bhaiXONWGZitbSgFOr1neG1DcC7X6APLPzh/Cw=
X-Received: by 2002:a37:64a:: with SMTP id 71mr34597429qkg.41.1553787423391; Thu, 28 Mar 2019 08:37:03 -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> <CAOj+MMGcKsuEomSBw_1MtaYwND4+VQjE2LjqEBAeoHKvpeA3DA@mail.gmail.com> <20190328151954.GA2120@pfrc.org>
In-Reply-To: <20190328151954.GA2120@pfrc.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 28 Mar 2019 16:36:49 +0100
Message-ID: <CAOj+MMHOktd3PuE_9GZvGd8_VxVU0HodLnjOCmBJxDH2JYTuWQ@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: acee@cisco.com, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006d98e605852953a4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/RLp6IkOvt7AotTWlqMktT9aBdH8>
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 15:37:16 -0000

Hi Jeff,

Yes clarification of the scope is needed.

But my broader point also was to clarify which operational model fits best
to different scenarios.

We have clearny two options:

* keeping up/down of bgp session on say loosy links

vs

* extend the notion of valid/invalid next hop in the same env.

The latter seems much more universal and applies to various deployment
models.

Former can be used for specific use cases ex: directly connected ebgp peers
or in more general it can be used where bgp control plane is congruent with
data plane. That often for ibgp is not the case.

Thx,
R.



On Thu, Mar 28, 2019, 16:20 Jeffrey Haas <jhaas@pfrc.org> wrote:

> Robert,
>
> On Thu, Mar 28, 2019 at 03:26:09PM +0100, Robert Raszuk wrote:
> > 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.
>
> I find it likely that the draft needs some clarity as to whether we'd want
> this capability present (or not) when BFD is not intended to be used on the
> link.
>
> Your example of "we're doing ibgp, please don't use BFD for BGP":
> - If we did want to use BFD, please use strict.
> - If we didn't want to use BFD, we might still want to specify strict as a
>   capability so that by not having it come up you didn't end up in one of
>   your interop scenarios.
>
> -- Jeff
>