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

Santosh P K <santosh.pallagatti@gmail.com> Wed, 31 July 2019 17:44 UTC

Return-Path: <santosh.pallagatti@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 BDC251205DC; Wed, 31 Jul 2019 10:44:27 -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 ZtAr4KoPvWhK; Wed, 31 Jul 2019 10:44:25 -0700 (PDT)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 5DCFF1201ED; Wed, 31 Jul 2019 10:44:25 -0700 (PDT)
Received: by mail-wr1-x432.google.com with SMTP id n9so70727860wru.0; Wed, 31 Jul 2019 10:44:25 -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=cPdRfI6xuxx/ctmheEnBOKwUO5eli21wPX+MRGVQYlY=; b=umGkaob9FFOyz9hFUb6WV20tRpBa6X43cmt7yiuPJwITvoO0uKowUOFX3eIfL1AjBa o1cnBQLs2YCrIF+rXsDoRvIqqr+rKw4+TcKfTiR4WZMW6Wmlf6+g6h9CMC9shwDC4mGm OoNfIizmJRwD9CplTQYwT+swDSvK/mC5li03bk1Rs6gVxpc+yD1XS5KRFEzqt52Cu9Qn 4DboXiQj9xKPu8UlOdWHWCVPkufeviS7Uq5nKwnL0ZecYMB/f0uA9B71+hEgkKe2xYGp mzMcJj3wDE+gzyOgWXCY/yxXz5+hjjcHnsZ71zgvTVVoq93x7NS3SW7aw5fbmJaxd9bx DCqg==
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=cPdRfI6xuxx/ctmheEnBOKwUO5eli21wPX+MRGVQYlY=; b=KAfMwvDvPsX2XAk0obItyyAbhqL6kxvyNlaj4Db/StgvCpn4VqljEHuffLjddm8zEi yFa4av5R45a9ZyuyaMP+m0t//H9yZpPyHW9dN+yg7MlMccSpBHfb/c/8URJSjU7RGh1w KZsW58fG0EoO97fYM90Tf4e86u2DPsyWTD08/O4hnUTwAb1CMu3CQCBKInVyuVvVDund fi1e+mwOZmylxVLW3mk0oWTGoLBPoeNQTrhqgyWYLtkBv8Cov5rjWoNX6btKAmBfXvf1 E8VfQt+Ca+dRfH1ffB7RFy97SMFvKiHMpytSSmhirqTuyUK1O33fme5Yomak9HYdxpGQ MHYw==
X-Gm-Message-State: APjAAAXEsOX4S+p2uphxCr6MUp0c3alT7UGV7o+qhyzYGksPg+B3y6NP Ss4G7s6UU96sQE6Ihq+535JupXCq5ak6oHiO824=
X-Google-Smtp-Source: APXvYqwEg7ISVvy7QFgci9lwgCkxvxi9Mc7aXpJ1jL+QKR0T7p/4N3ezS8nzfv5m2kUH+uZLTX6TMHpaOyooyNEaHtQ=
X-Received: by 2002:a05:6000:145:: with SMTP id r5mr55739000wrx.208.1564595063798; Wed, 31 Jul 2019 10:44:23 -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: Santosh P K <santosh.pallagatti@gmail.com>
Date: Wed, 31 Jul 2019 10:44:13 -0700
Message-ID: <CACi9rdvKTLwBQn9mcJksGTW79QTFj0d45DOpDT1Jee4QpGnv3Q@mail.gmail.com>
Subject: Re: BFD over VXLAN: Trapping BFD Control packet at VTEP
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: Dinesh Dutt <didutt@gmail.com>, 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="000000000000fec26b058efdac9e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/xkxGbmMiTx8_NUM6xD7RATXT04Y>
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 17:44:28 -0000

I have checked with implementation in data path. When we receive a packet
with valid VNI then lookup for MAC will happen and it is VTEP own MAC then
it will be trapped to control plane for processing. I think we can have
following options
1. Optional managment VNI
2. Mandatory inner MAC set to VTEP mac
3. Inner IP TTL set to 1 to avoid forwarding of packet via inner IP
address.


Thoughts?

Thansk
Santosh P K

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