Re: Fwd: I-D Action: draft-ietf-bfd-vxlan-02.txt

Marc Binderberger <> Thu, 13 September 2018 21:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D69A130E88 for <>; Thu, 13 Sep 2018 14:36:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sBakDo4FvYU5 for <>; Thu, 13 Sep 2018 14:36:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B723F130E7C for <>; Thu, 13 Sep 2018 14:36:13 -0700 (PDT)
Received: from [IPv6:::1] ( []) by (Postfix) with ESMTP id 43A534BD0EA; Thu, 13 Sep 2018 21:36:10 +0000 (UTC)
Date: Thu, 13 Sep 2018 14:36:11 -0700
From: Marc Binderberger <>
To: Greg Mirsky <>, rtg-bfd WG <>
Message-ID: <>
In-Reply-To: <>
References: <> <>
Subject: Re: Fwd: I-D Action: draft-ietf-bfd-vxlan-02.txt
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: GyazMail version 1.5.19
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, 13 Sep 2018 21:36:17 -0000

Hello Greg & Authors,

great to see this draft progressing!

As usual I'm a bit late :-/ but I do have some questions/comments:

Q1: the TTL = 1 requirement for the inner IP packet. The explanation for the 

         TTL: MUST be set to 1 to ensure that the BFD packet is not
         routed within the L3 underlay network.

I find this a very implementation-specific reason that may not apply to many 
other implementations. But the demand for TTL = 1 may limit what can be done 
with today's silicon, which is why I question this demand here :-)

You will find off-the-shelf silicon that offers you BFD RFC5881 "in 
hardware". For the ASIC user the usage is typically fixed by the API/SDK and 
RFC5881 uses TTL = 255 for send and check on receive. Using a loopback port 
it would be simple to use this RFC5881 BFD engine to send packets over the 
VxLAN tunnel.  But the TTL=1 requirements defeats this.  Could we drop it?

Q2: in this context of TTL you write

   10.  Security Considerations

      The document recommends setting the inner IP TTL to 1 which could
      lead to a DDoS attack.

First, you don't recommend - you say MUST. But as a non-native speaker maybe 
this is a misinterpretation on my side ;-)
More interesting: how does TTL = 1 raises the DDoS risk? By someone directly, 
i.e. without any VxLAN encapsulation, sending a BFD packet to the VTEP IP ?

Q3: for the demultiplexing of incoming BFD packets (section 6.1) you write

   [...] For such packets, the BFD session MUST be identified
   using the inner headers, i.e., the source IP and the destination IP
   present in the IP header carried by the payload of the VXLAN
   encapsulated packet.  The VNI of the packet SHOULD be used to derive
   interface-related information for demultiplexing the packet.

I understand the "MUST" for the source IP, to differentiate a session with 
VTEP A from the session with VTEP B. Why is the destination IP, i.e. my local 
IP, of relevance?  Support for multiple VTEP?
But my main question is, why the VNI (or related information like the local 
VLAN or VFI) is only a "SHOULD" ?  In section 4 you say

   [...] Separate BFD
   sessions can be established between the VTEPs (IP1 and IP2) for
   monitoring each of the VXLAN tunnels (VNI 100 and 200).

How would I separate these BFD sessions when src/dst IP are the same?

Finally a nitpick, you write in section 6:

   The UDP destination port and the TTL of the inner Ethernet frame MUST
   be validated

We all understand what you mean but I first stumbled: Ethernet frames have no 
TTL. You mean (of course) the inner IP packet - why not writing it? ;-)

Anyway, overall very useful standard (as you see from my comments, there are 
feature roadmaps coming ;-)

Thanks & Regards,

On Sat, 18 Aug 2018 13:54:22 -0700, Greg Mirsky wrote:
> Dear All,
> the new version addresses comments and editorial suggestions we've received 
> from Donald.
> Your reviews are most welcome, comments, questions, and suggestions much 
> appreciated.
> As discussed at the meeting in Montreal, the authors believe that this 
> document is ready for WGLC.
> Regards,
> Greg
> ---------- Forwarded message ----------
> From: <>
> Date: Sat, Aug 18, 2018 at 1:09 PM
> Subject: I-D Action: draft-ietf-bfd-vxlan-02.txt
> To:
> Cc:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Bidirectional Forwarding Detection WG of 
> the IETF.
>         Title           : BFD for VXLAN
>         Authors         : Santosh Pallagatti
>                           Sudarsan Paragiri
>                           Vengada Prasad Govindan
>                           Mallik Mudigonda
>                           Greg Mirsky
>         Filename        : draft-ietf-bfd-vxlan-02.txt
>         Pages           : 10
>         Date            : 2018-08-18
> Abstract:
>    This document describes the use of the Bidirectional Forwarding
>    Detection (BFD) protocol in Virtual eXtensible Local Area Network
>    (VXLAN) overlay networks.
> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at: