Re: Rtg-bfd Digest, Vol 163, Issue 25

Robert Raszuk <> Thu, 03 October 2019 20:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41C371200BA for <>; Thu, 3 Oct 2019 13:10:46 -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_HELO_NONE=0.001, SPF_PASS=-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 N-QF0RNHD6fS for <>; Thu, 3 Oct 2019 13:10:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6FEF91200B7 for <>; Thu, 3 Oct 2019 13:10:43 -0700 (PDT)
Received: by with SMTP id u22so3645921qkk.11 for <>; Thu, 03 Oct 2019 13:10:43 -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=s89vQaLbMbe/4SNwYj3gfjVqbpb7XhpExyM3EvVG/7M=; b=To7Kp4w9gx3DB1Jv4W2v2lrcpbvWRvsnoaN6WLPcjJOh2MddPwtxcNlUQDyPltuh4a f7eLg2WFlUFvOLWnIcyJt8KSLRWNX3J7LvK9yGCCB9WPzE3IJpczCCP30V9tgw8KhGXJ YRZIymcd9/jLAmEnv90TfSglrqdm680b5hw7xknyGlt931masiqBM5CND0d2sP48G2aQ vhpbrMcA2/tSgs8QVSdfg2WANGFKnI/znv8TypsOqTDcPZE/rB5WkS6zJ29/wAVH6qgt R9ZzD4DST5HDDTRe8hN+BA2EaQK+b94tTXcOr9KanLQ+593+W+1Kfy1HfRefNAJMQQTg x6FQ==
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=s89vQaLbMbe/4SNwYj3gfjVqbpb7XhpExyM3EvVG/7M=; b=dYBGkM9AxWNSFIgxvyEnj6F9HLsQYQ9PTl98mO1zhcOgNVXcLv/2KrL0rXxy07RVou 3XuB1Zc7XbIhc0Shipxg1LM/jB/zg8FtlYL5QgsRGFJnG5Cg0yo+6oHI2X9Dsn6sCEUI sGP0NXhsyapitd55tH66zxyvAXkxy7QLpXmqudWzJR8dIfh7RJepasMpwx6KjSU+7rdQ x6qu3SXauvtF+LWZlbxYjFVZ+t7BrY0PnzWaQEHxOFtv4kIwsJWiqfz5wpk+oTFrzhSn 25iMti3pI6Op0jZ7TG3T+dQxRFYUV2G0of2ZW3CHZeXzV+/Pjv7+/FeODvU2ET3Hgt0B 46jw==
X-Gm-Message-State: APjAAAXyixpPl6Pczd5+bCgmlibm/Fu8kY7Ih+t1DnE2ET84eeZI/uHn PPZuio+dPzk6gst6PHP6d7mYoQhIrPxdFcgeikb8Bg==
X-Google-Smtp-Source: APXvYqwUjVjfjk79vpolxn7EQ0qOfAn7oa5FRGnFxIlGwzhA3gwL/atR0bRpzagOF1Mr+wdtzkW/GLnG1NksmeYFd6c=
X-Received: by 2002:a37:274e:: with SMTP id n75mr6366140qkn.134.1570133442262; Thu, 03 Oct 2019 13:10:42 -0700 (PDT)
MIME-Version: 1.0
References: <5D93DD11010004620119029E_0_2183410@msclnypmsgsv04> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Thu, 3 Oct 2019 22:10:32 +0200
Message-ID: <>
Subject: Re: Rtg-bfd Digest, Vol 163, Issue 25
To: Jeffrey Haas <>
Content-Type: multipart/alternative; boundary="00000000000013aa240594072e22"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Oct 2019 20:10:47 -0000

Hi Jeff,

> That said, Robert, there's room for you to work on that if you want to
> off a draft on the topic.

Thx for the hint, but I do not think this extension should be done in BFD
for three reasons:

Reason 1 -

BFD works well to quickly detect failures. Loading on it more stuff
compromises it. Moreover other vendors already have shipping tools which
already can detect issues due to changes in MTU of the paths: Example:

Reason 2 -

As the draft states that the idea is to automate use of this extension by
client protocols. I do not agree with such deployment model of this
enhancement. At most if frequency of MTU probing would be 100-1000 times
less frequent then up/down link detection it would serve its purpose - yet
there is no word in the draft about such option. Essentially instead of
replacing current tiny BFD packets one could use bfd-large as different
sessions with completely different timers. Maybe even end to end instead of
link by link.

Reason 3 -

As we know BFD is very often used between ASes. How do you signal over p2p
link willingness to now encapsulate BFD in stuffed UDP ? Email ? Phone ?
Text ? Note that with mentioned icmp pathecho I can seamlessly detect issue
with MTU of the link to my peer without telling anyone or asking for
support of the other side.


On Thu, Oct 3, 2019 at 9:34 PM Jeffrey Haas <> wrote:

> On Tue, Oct 01, 2019 at 11:11:13PM -0000, Albert Fu (BLOOMBERG/ 120 PARK)
> wrote:
> > There are well known cases, including those you mentioned, where BFD has
> > limitations in deterministically detecting data plane issue, and not
> > specific with the BFD Large Packet Draft. I am a novice to the IETF
> > process, and not sure if we need to mention them here, but shall discuss
> > with Jeff if it is worth highlighting them.
> It's reasonable to make note of issues where common operational scenarios
> will complicate the solution.  But it's not up to a draft carried on top of
> an RFC with that core issue to try to solve the issue in that core RFC.
> So, trying to solve "BFD doesn't work perfectly in the presence of LAGs" in
> bfd-large is the wrong place to do it. :-)
> That said, Robert, there's room for you to work on that if you want to kick
> off a draft on the topic.
> > > We won't have control over how the Provider maps our traffic
> (BFD/data).
> >
> > > Well of course you do :)  Just imagine if your BFD packets (in set
> equal to configured multiplier) would start
> > > using random UDP source port which then would be mapped to different
> ECMP buckets along the way in provider's
> > > underlay ?
> And that's an example of possible solution space for such a draft on the
> underlying issue.
> That said, LAG fan-out issues are a massive operational pain.  While it's
> likely that varying L3 PDU fields for entropy to distribute traffic across
> the LAG may work (and we have any number of customers who rely on this for
> UDP especially), it starts getting very problematic when you have multiple
> LAGs in a path.  I have a vague memory that someone had started some
> discussions with IEEE to try to figure out what OAM mechanisms would look
> like for such scenarios, but that's very much out of normal BFD scope.
> -- Jeff