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

Dinesh Dutt <didutt@gmail.com> Wed, 31 July 2019 18:25 UTC

Return-Path: <didutt@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 7AF1F1206C3; Wed, 31 Jul 2019 11:25: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 mgR7XhPmBoPy; Wed, 31 Jul 2019 11:25:36 -0700 (PDT)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 B744612019C; Wed, 31 Jul 2019 11:25:35 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id r1so70719307wrl.7; Wed, 31 Jul 2019 11:25:35 -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=xNlPx4DxEkgFLI3ccLdFML6TiUma/NrXd0DN2t8ndk0=; b=S0Z57nnO2VpnG2h/INijCbexPKZ0UlbcsdkDptOao7xmQ4JF9ZTiUS9gCe6IuH1eE0 BPZKgRN47b52d9FaFTDXVIqaO8bTloglF1ZI+YMGsf9Nv4i8Cd+m7w7ZNt7DjpRxiqNG XFS/OU4nGcbKsESepRGITdzUMp8K0Eu2dq8JYaHnqMYuyoU4oqZ6XKEOo1a6IMMaeRmB 3MEreNvkySwkeh8pJiB8vUYTQVP1dVW4dLtxxJHTKpU4nf10ABqxL3grCNGwK6/hdIy0 CV21srSHAMk4v7QEB8Pv661rryExu4JT2W93NBUTBeYhzknozWPtGa7mfo4tBGglYDwN iBOw==
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=xNlPx4DxEkgFLI3ccLdFML6TiUma/NrXd0DN2t8ndk0=; b=tatoJEZCp5PWOnKq/BMTTO7xXl8OfX9XNb0HD+9E7tEXYckdy328YYkc5KWyOYHLL/ 8GGQmb0Sm18ESrzvu3zRSdL4MyaXXIMhEcsHbKFAu9dVYRJynOBZI9aZ57jCfbElLWDy jRMWrV5M5fwvjO4rCJ+R8HsWY+sodEI0iaZ4Ybmh9Osq6Dh4MQUOC3xs+C+fqbFLAB7f qtUWTihZjw2CptUsBzuYFaF0RxypLQg/rRYrIUbgSF/tzbbWqCJr+gs5SkNTMPEkoRtn cn/dxUWklkcqE/B0ioBChU7B2jY0imfFmpIGDKpLN4hwwCFg3lJBxXC33gaTYlIxCTXb uzdA==
X-Gm-Message-State: APjAAAXDSEclqlSONhJMEoxpmyJ9hrZQO+sattJg0dg43ZuFCZ0znbE6 0KdpgYY27qQBFHoZTAaf+WMf0UwJt0EGrA1mK1Y=
X-Google-Smtp-Source: APXvYqy+iPZaZmZBpZnL3iUiQMSYD9nW7xgsvhWHMU62grJAqLz+8moIY86wIrV76go5oP16VxOMCQ5P2tQrEAl5YUI=
X-Received: by 2002:adf:cd04:: with SMTP id w4mr86974739wrm.230.1564597534158; Wed, 31 Jul 2019 11:25:34 -0700 (PDT)
MIME-Version: 1.0
References: <CA+RyBmW=byLBNfVQSdaEoMf-QnJtj13k788XhbZ9tqH4bcgqNQ@mail.gmail.com> <CAOPNUTBJztjmNgrDyHgMo8-nRazAaXACGJJZ6Lx8z8aRVBM+GA@mail.gmail.com> <CA+RyBmWrM3v37BO8O_VOGG-NJ+UbrtSVQ_2GwW0R+vLkxbtvHw@mail.gmail.com>
In-Reply-To: <CA+RyBmWrM3v37BO8O_VOGG-NJ+UbrtSVQ_2GwW0R+vLkxbtvHw@mail.gmail.com>
From: Dinesh Dutt <didutt@gmail.com>
Date: Wed, 31 Jul 2019 11:25:21 -0700
Message-ID: <CAOPNUTDqe1iA9N=+kJD4Mih1xu6LqTVi0D=mzvgjUn_KE6K7dA@mail.gmail.com>
Subject: Re: BFD over VXLAN: Trapping BFD Control packet at VTEP
To: Greg Mirsky <gregimirsky@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="0000000000003d7ab2058efe407e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/z8E_a5k_r4pLLs5YfNsL_Xm9_Us>
X-Mailman-Approved-At: Wed, 31 Jul 2019 11:26:55 -0700
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 18:25:37 -0000

Hi Greg,

On Wed, Jul 31, 2019 at 9:20 AM Greg Mirsky <gregimirsky@gmail.com> wrote:

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

If you use the inner IP address as the VTEP IP address, then use the MAC
address that the VTEP would respond with when replying to an ARP for that
VTEP IP address. If a VXLAN expert disagrees with this, could you kindly
tell me who it is so that I can understand their disagreement? So this
handles the case where the VNI is not a user-tenant VNI. If the VNI used in
the BFD packet is a user-tenant VNI, then the receiving VTEP MUST have an
IP address in that VNI (mapped to a VRF) else you cannot use that VNI in
the BFD packet. Why won't this combination address all the cases you've
listed? What am I missing? Define VNI 1 as a possible use, not VNI 0. I
objected to VNI 0 because there are too many switching siicon out there and
some of them will not be able to handle this scenario.

Dinesh

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