BFD over VXLAN: Trapping BFD Control packet at VTEP

Greg Mirsky <gregimirsky@gmail.com> Wed, 31 July 2019 12:48 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 574611200E6; Wed, 31 Jul 2019 05:48:47 -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 OsNAXkuBerzL; Wed, 31 Jul 2019 05:48:45 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 212C41200FF; Wed, 31 Jul 2019 05:48:44 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id t28so65460835lje.9; Wed, 31 Jul 2019 05:48:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=fOdE6JXwlUUhS/qQxtCzoNVQbwWBm2nSwIz1Ok6i22Y=; b=eGTOsSrX2/9nlE0BJxCW/shOF3IU9nMTURCdUKRhK4azBLY1M6WC20g93f2OnskWpK Zs6cZbhlD2OrrYmfNqvv8IlN9KgZ9YHuskY9UOHompidiJm7lc3c/ZGF5LBoAfUk4WGs AHSwGICNywMhiaroLcN02zQ6R5Rz9DrhiN+R/R5AHG4mNWvqK2xWahwT+qKGrfIQrpwN QmoR+OvKTvNw3bj8KpG+V0pExt6q/v7cVC1KAyQpPriIMgrddA3dYCakRYJe2pqGW/SG B5TTJKtsPpBMlpmWF+043P6W1gBSr/g/Q+7E7FWMEVSNys1kx+mKvb0ODa0cODZ0FEdh HQTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=fOdE6JXwlUUhS/qQxtCzoNVQbwWBm2nSwIz1Ok6i22Y=; b=HIiStgdAzgWU7X0khzWcytApJmsJBoR9/8DzAfLM1B3xDNUWphDZ7Iy7xHJMW11ny6 oWW4d88beFImy7aK2+wVcdWp1zbWlIdxUh5rntty/lKFXVzY1MRfW3EY2sKv1BdQzGOZ MDNyJbSfrJt6NPjNsEOP1ViB0F6k5/Usl9X9/bpwEE93VKqu93cGLOMO19IML0Wh9+ID 2LDTKeaQ5AEwYWAcw910sXQSR8BnJQuesjPQpaqJ88PIPQCEKSw9Gr8iIpXVG+Y2NRfC ZRxce7QcpLJlhWa11H/+fCUYQvC7M05IW1psWykIkCX7CJ3iNkNlfKi6Nba9tn7uu/b6 UUfw==
X-Gm-Message-State: APjAAAX1KYcK1I3J0KV6bT5C5sk08FLYH8fyPlUppBejtZpkaDKIHyPd ziFxdRsol0j1KybIMnRP297k9ufvGoZ/MWZBrEUI932i
X-Google-Smtp-Source: APXvYqwe/Eclim2Ld3vkQNvbym1jXyTK8+7ZS8fprLWAsEOmh2RJXFPv/uTMFvWcYwbSRt3Sh1BRHco+PFP5EpbdQn0=
X-Received: by 2002:a2e:7614:: with SMTP id r20mr65340585ljc.42.1564577322731; Wed, 31 Jul 2019 05:48:42 -0700 (PDT)
MIME-Version: 1.0
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 31 Jul 2019 08:48:31 -0400
Message-ID: <CA+RyBmW=byLBNfVQSdaEoMf-QnJtj13k788XhbZ9tqH4bcgqNQ@mail.gmail.com>
Subject: BFD over VXLAN: Trapping BFD Control packet at VTEP
To: rtg-bfd WG <rtg-bfd@ietf.org>, "T. Sridhar" <tsridhar@vmware.com>, Dinesh Dutt <didutt@gmail.com>, Joel Halpern <jmh@joelhalpern.com>, bfd-chairs@ietf.org, Martin Vigoureux <martin.vigoureux@nokia.com>
Cc: draft-ietf-bfd-vxlan@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008b8cf5058ef98b3b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/SfXfu3pCh9BxaRFrXbEOgGt6xjE>
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 12:48:48 -0000

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