Re: BFD over VXLAN: Trapping BFD Control packet at VTEP

Greg Mirsky <gregimirsky@gmail.com> Wed, 31 July 2019 16:20 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7437C1203E1; Wed, 31 Jul 2019 09:20:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 5cvrOEAlZmf3; Wed, 31 Jul 2019 09:20:35 -0700 (PDT)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 6A8481203E9; Wed, 31 Jul 2019 09:20:28 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id c19so47864302lfm.10; Wed, 31 Jul 2019 09:20:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Sy22dU+9+wT0xjz3jl1Am9nZJ8AFf0TB5rVk3JZ3NtY=; b=CTw/hbvz75ztasxvWA4FJ7hazSdIN6uKLkp7yf5j1d5/41Puk2/gXUiL9Tc5vm/JDb aXdohLpv6GSzRuzfBfBAJ6KDipqUqBEdEXv+uJrvqO++vd7QIB/CIieJjCl/4n1qQF7H XcQNmsgANjstB3Dna9zlV3rWojEFQ+wLPfVzxwnBYpKWDPwWDOWySxu7P7evF/lN1PAC tUwetAWUPTyfr7OGAz9xhyTjSm3zKK2tTmNTtk27vdp0T97sN3UgCEqGkySMwM97vjvQ 6oB9SvjOlMte+TDrX+XBjGdHhVDCJ5OzSCfQhdcpS/12AHLOdB+/LmafdGj67MG99zX8 /PLg==
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=Sy22dU+9+wT0xjz3jl1Am9nZJ8AFf0TB5rVk3JZ3NtY=; b=bu3sjczWgMDU6PjP7KoJIV8o3Da8dkofkjjCCo3pP8iXbDL/cdAcfua/TVxx6UA8fp wAKKROsZ9hId3IFCDex8U7g62SotOz5x3TJvW0330XXAXlNuSHTGwVoOSsxyFRtfZixG Ff0DE/M5S28mzDFG5KoMG3ZjrcgNBKqKKV7BCFwplA4YKRExZC/E1CXQRo3pwzs46ImY C/7faHETVfTKn0EUNYVMVPGNxOb+kMDfukx0o+jwMxDx7Vp/mhzzjgZNNmjkuxBDtGu3 y1PZR+7hrrHDfn856c8Avuuqa7fkuzzvvUOEdCW2jY0DONGgNh79Q6IIgjVrPm2izkUs P0MQ==
X-Gm-Message-State: APjAAAVIM4ljag/ca+sYDuuQPz0WgJgp6KzcAZc0bx1L4TQoaFKl1tKe y3PJ0TUErxE8ihyd5Fny8/+PDJhw2rxFuzzZi4A=
X-Google-Smtp-Source: APXvYqz11vL8d8tAWWvNp6ZXV+2vtwqGuPckAAXjmN9sFq9ZOe1eTgRFwVZNGL6glwkxXQ2IfFZkhnlmZujS1nHncKY=
X-Received: by 2002:ac2:5609:: with SMTP id v9mr55932034lfd.27.1564590026623; Wed, 31 Jul 2019 09:20:26 -0700 (PDT)
MIME-Version: 1.0
References: <CA+RyBmW=byLBNfVQSdaEoMf-QnJtj13k788XhbZ9tqH4bcgqNQ@mail.gmail.com> <CAOPNUTBJztjmNgrDyHgMo8-nRazAaXACGJJZ6Lx8z8aRVBM+GA@mail.gmail.com>
In-Reply-To: <CAOPNUTBJztjmNgrDyHgMo8-nRazAaXACGJJZ6Lx8z8aRVBM+GA@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 31 Jul 2019 12:20:15 -0400
Message-ID: <CA+RyBmWrM3v37BO8O_VOGG-NJ+UbrtSVQ_2GwW0R+vLkxbtvHw@mail.gmail.com>
Subject: Re: BFD over VXLAN: Trapping BFD Control packet at VTEP
To: Dinesh Dutt <didutt@gmail.com>
Cc: rtg-bfd WG <rtg-bfd@ietf.org>, "T. Sridhar" <tsridhar@vmware.com>, Joel Halpern <jmh@joelhalpern.com>, bfd-chairs@ietf.org, Martin Vigoureux <martin.vigoureux@nokia.com>, draft-ietf-bfd-vxlan@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c18f29058efc804f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/ZcUrYHMxhS36rOyUTD7IH15dsdM>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jul 2019 16:20:38 -0000

Hi Dinesh,
thank you for your consideration of the proposal and questions. What would
you see as the scope of testing the connectivity for the specific VNI? If
it is tenant-to-tenant, then VTEPs will treat these packets as regular user
frames. More likely, these could be Layer 2 OAM, e.g. CCM frames. The
reason to use 127/8 for IPv4, and 0:0:0:0:0:FFFF:7F00:0/104 for IPv6 is to
safeguard from leaking Ethernet frames with BFD Control packet to a tenant.
You've suggested using a MAC address to trap the control packet at VTEP.
What that address could be? We had proposed using the dedicated MAC and
VTEP's MAC and both raised concerns among VXLAN experts. The idea of using
Management VNI may be more acceptable based on its similarity to the
practice of using Management VLAN.

Regards,
Greg

On Wed, Jul 31, 2019 at 12:03 PM Dinesh Dutt <didutt@gmail.com> wrote:

> Hi Greg,
>
> As long as the inner MAC address is such that the packet is trapped to the
> CPU, it should be fine for use as an inner MAC is it not? Stating that is
> better than trying to force a management VNI. What if someone wants to test
> connectivity on a specific VNI? I would not pick a loopback IP address for
> this since that address range is host/node local only. Is there a reason
> you're not using the VTEP IP as the inner IP address ?
>
> Dinesh
>
> On Wed, Jul 31, 2019 at 5:48 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
>
>> Dear All,
>> thank you for your comments, suggestions on this issue, probably the most
>> challenging for this specification. In the course of our discussions, we've
>> agreed to abandon the request to allocate the dedicated MAC address to be
>> used as the destination MAC address in the inner Ethernet frame. Also,
>> earlier using VNI 0 was changed from mandatory to one of the options an
>> implementation may offer to an operator. The most recent discussion was
>> whether VTEP's MAC address might be used as the destination MAC address in
>> the inner Ethernet frame. As I recall it, the comments from VXLAN experts
>> equally split with one for it and one against. Hence I would like to
>> propose a new text to resolve the issue. The idea is to let an operator
>> select Management VNI and use that VNI in VXLAN encapsulation of BFD
>> Control packets:
>> NEW TEXT:
>>
>> An operator MUST select a VNI number to be used as Management VNI. VXLAN
>> packet for Management VNI MUST NOT be sent to a tenant. VNI number 1 is
>> RECOMMENDED as the default for Management VNI.
>>
>> With that new text, what can be the value of the destination MAC in the
>> inner Ethernet? I tend to believe that it can be anything and ignored by
>> the reciever VTEP. Also, if the trapping is based on VNI number, the
>> destination IP address of the inner IP packet can from the range 127/8 for
>> IPv4, and for IPv6 from the range 0:0:0:0:0:FFFF:7F00:0/104. And lastly,
>> the TTL to be set to 1 (no change here).
>>
>> Much appreciate your comments, questions, and suggestions.
>>
>> Best regards,
>> Greg
>>
>