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

Robert Raszuk <> Mon, 30 September 2019 09:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1691A120142 for <>; Mon, 30 Sep 2019 02:53:11 -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 kPpuxKZ8bFbb for <>; Mon, 30 Sep 2019 02:53:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1B10812013F for <>; Mon, 30 Sep 2019 02:53:09 -0700 (PDT)
Received: by with SMTP id 4so7168029qki.6 for <>; Mon, 30 Sep 2019 02:53:09 -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=yFsvFTp5hL2NiysKf6LhxJCHVzsWPMrbCMhFgA4u8GY=; b=U59jKq84iBBKg2JHsOb66uwAdgd0RLCzWJy4Tbt0TTgY5WdR3itcWoJ6TjYXIsN7mz AyGuikuFfnVL9Mf1i4PSIHg3e8Avht2hangDQfjtEFg4LgQKUVa1w/P5LL99YbauHP2X rCPkGiTDh6TzyHSre5gUp663l7WMWWo/oXlEvKfY7G/IRhKwF8m2WuiNaEVfCQwqtn+g Y3U2sU92YEeEeaFUJsMz/Wa0vMdGrCkE+8uMeDc6/cDnOkMWlw3fG25pBHPSZoYw/nWs /lZ9LkplQ0E6wVWyA5kzSI9L3bgAEtG7Cx/7yVN0w5m62lbVfC3+wnJTfh3VsHchm6lG xzWw==
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=yFsvFTp5hL2NiysKf6LhxJCHVzsWPMrbCMhFgA4u8GY=; b=LMVG4hU6lrTwZveMSAtbhE78Ed1JZA6/AAe+haCPcVtSdx6JUxzYg/VOM3/HIZaHs7 pr9AvMhORowFl7UjMw77NIUiZEXIaJ0THMwEfvjF8sWtGElsLRwa2RHW52B2juqzKWmN iwlBDH6e89M9By1CJcJrXOQjj1DChi35qH38Dp4eGLYLlJNnuHsSOsPAjsKrlCmjy3jF HUIzMBec0lf9xV4ywvNVfIAt2QMt1m4Dh552VSW7h12rddTtVEUqI8NpOPJhxQt2FSNd IcYgyhf6f6VQeCtJIiDCKtf6t2cA1eGPGkOF88WoJ8VTAPdbKGbvsVT3tGdk7fHqN0F4 oP4A==
X-Gm-Message-State: APjAAAVSv6Kbo58HiCp9JSe41K0eLvMJHei8WHKkU+9wHM1ILIvZRx0D Dr8V7VgbvYrbaN1I7q9efi9p/PFxPrY80DmvjpL8zQ==
X-Google-Smtp-Source: APXvYqxm4OZZzYCVxeoumdzjkGMRq5hbozgNpLcOq3ZgFSu6IrMIL9kMrQya0pgucSLLAjLRHGLxQc6zK4Rr9sIeaVI=
X-Received: by 2002:a37:2784:: with SMTP id n126mr17021137qkn.302.1569837187926; Mon, 30 Sep 2019 02:53:07 -0700 (PDT)
MIME-Version: 1.0
References: <5D9180750134017A00390137_0_6820@msllnjpmsgsv06>
In-Reply-To: <5D9180750134017A00390137_0_6820@msllnjpmsgsv06>
From: Robert Raszuk <>
Date: Mon, 30 Sep 2019 11:52:57 +0200
Message-ID: <>
Subject: Re: Rtg-bfd Digest, Vol 163, Issue 25
To: Albert Fu <>
Content-Type: multipart/alternative; boundary="000000000000f128840593c2334c"
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: Mon, 30 Sep 2019 09:53:11 -0000

Hi Albert,

Thank you for sharing the experience and your use case.

However when we make any protocol extension we need to make sure all
possible deployment cases are covered and it must be well understood how
the proposed extension will operate in basic deployment scenarios I
enumerated. I really do not think we should be standardizing extension for
single use case based on the behavior someone is reporting as "likely to

We all agree that if you have a p2p fiber link between routers there is no

The issue surface when you are using emulated circuits as your p2p links.
So the solution should allow to detect the problem in all cases it can
happen. Perhaps BFD is not the right tool for this. Perhaps we need to go
back to BESS WG and report that VPWS or EVPN based p2p emulated circuits
were not design right as they exhibit observed issues.

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

Kind regards,

On Mon, Sep 30, 2019 at 6:11 AM Albert Fu (BLOOMBERG/ 120 PARK) <> wrote:

> Hi Robert,
> > Imagine two scenarios which were already highlighted as justification for
> > this work:
> > *Scenario 1 -* IGP with nodes interconnected with ECMP links
> > *Scenario 2 -* IGP nodes interconnected with L2 emulated circuits which
> in
> > turn are riding on telco IP network with ECMPs or LAGs.
> > *Questions Ad 1 - *
> > Is the idea to use in those cases "ECMP-Aware BFD for LDP LSPs" vendor's
> > feature to be able to detect MTU issues on any of the L3 paths ? Is there
> > feature extension to accomplish the same without LDP just when using ECMP
> > with OSPF ?
> The draft does not go into the specific use cases. I think most BFD uses
> cases (certainly in our case) are on p2p IGP/eBGP links. (btw some vendors
> do not support control-plane BFD independence for multihops BFD, making it
> unreliable for fast detection).
> The end to end paths may have multiple multiple-ECMP links/paths. The BFD
> sessions on the individual link along the path will detect large packet
> issue.
> > How do you solve this when there is L2 LAG hashing across N links
> enabled ?
> This is a situation where you need more than standard BFD. It is a reason
> why some customers like us prefer not to run LAG on parallel WAN circuits,
> so we can diagnose interface issues easily via standard tools like ping. It
> is a design compromise.
> > *Question Ad 2 - *
> > How do you detect it if your L2 circuit provider maps BFD flows to one
> > underlay path and some encapsulated data packets is hashed to traverse
> the
> > other path(s) ? Clearly running multiple BFD sessions is not going to
> help
> > much in this scenario .... For example if someone is using v6 flow label
> it
> > may be directly copied to the outer service header.
> We won't have control over how the Provider maps our traffic (BFD/data).
> In my experience, the chances of this happening is prob small based on my
> involvement with all of these issues, in that when the issue happened, all
> packets > certain size would fail, not some getting through and some
> failing.
> Thanks
> Albert