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

Dinesh Dutt <didutt@gmail.com> Fri, 02 August 2019 17:44 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 9CDC1120774; Fri, 2 Aug 2019 10:44:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 SpmN2lDRsFeQ; Fri, 2 Aug 2019 10:44:48 -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 96BB1120251; Fri, 2 Aug 2019 10:44:47 -0700 (PDT)
Received: by mail-wr1-x432.google.com with SMTP id c2so74787598wrm.8; Fri, 02 Aug 2019 10:44:47 -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=JgLSVtnXP3lsBciiVnnEw4FQhFcxw0zg39MS/ewx/IU=; b=F+ISG0Ys1mQ03frgb6vKhmltO+Ub0A/QtxhkgKbR1GXFSpyqprGGdYTPp5rKmm/EPa V3lE4wpHwgzRUE6k4S3Eal5AwlT9oaPGuyPRPOT+UgDeHNxlyrKHIAoZsjnIL2F7M0Wh lCo6AwiUL9W6ASi+oZ2IVs2iJlUSLEjeNVEEbg8GOOH0hQH5hl1Q+Qi54VUoGQm0BHxR swVVvWt8c28IHkqESdWev5eiBU3cLwDLZvr5BjFvuo9D9iquJOVsbSV1Ax4f9N40IXMV W/pTRG45ABIQvj7IOVn797SO8ER6PyDVo4arFOTnwkAfMYglfsGRwboOjpT3W6gQOr3w qLIA==
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=JgLSVtnXP3lsBciiVnnEw4FQhFcxw0zg39MS/ewx/IU=; b=rAEVaxE//kAtgGRPa5GLlihsIPktwF8sYgpgVKQbw0i07tTW5Xs3tDhxVyEqJZ0mTC r+RmH7Nh/R7m4VY6fFUitAx/dIjj3qmjNljU131LpPObfCgNesExCC4L0P8EPcZTh4Sn ca3xDpnX707qtNW4sztqz1B/ylDURUYJRwjqdNrIsG5dIAP/PTdTJ0tLhQfUjDUp7Dor 0lHd7mf1DEMEJUxTSW3gJe1LFTMs4pMaRGycPTQMqbc0WTHgq6zjg45XGkMQ/dEMXbRZ OyoXoaqkwhotDRjVk17SYpf5I61xJjM7BLJDaqOXTspouaOZzeBcNsEbW9BUxMnLFiQ3 zbUg==
X-Gm-Message-State: APjAAAXUuCvEC3gnR9x1mNET7LdBNDmxJ9dXSx5W1GrrzQBHEKzU5j7x M6kAeDWUVvmV73wb5cvJU3swRiERnh+vAmoUFh4=
X-Google-Smtp-Source: APXvYqxWDSRynrzHLPIJlU2fk9qqCsPAlOd/gatFgUhWuCykhfGw3SLdiwmskT407Mps9EgBgbKzVyNhZH4cDZaMOGA=
X-Received: by 2002:adf:cd04:: with SMTP id w4mr99577996wrm.230.1564767886038; Fri, 02 Aug 2019 10:44:46 -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> <CACi9rdvKTLwBQn9mcJksGTW79QTFj0d45DOpDT1Jee4QpGnv3Q@mail.gmail.com> <c57a3cf3-ab77-99df-0f78-104edef3275c@joelhalpern.com> <CACi9rdubTnzgCVZK0syRf3fsrpTU45SpQV57n2rNcNCqk+3+7Q@mail.gmail.com> <CACi9rdsmP8SFwP+Her45XKFwQZ3SQgwLpr62kAY-kP4vZtnFnQ@mail.gmail.com>
In-Reply-To: <CACi9rdsmP8SFwP+Her45XKFwQZ3SQgwLpr62kAY-kP4vZtnFnQ@mail.gmail.com>
From: Dinesh Dutt <didutt@gmail.com>
Date: Fri, 2 Aug 2019 10:44:34 -0700
Message-ID: <CAOPNUTD4nQ4YROxUA9hxdTFOtv4XpmazA=apm2ceuCxt3yM=XA@mail.gmail.com>
Subject: Re: BFD over VXLAN: Trapping BFD Control packet at VTEP
To: Santosh P K <santosh.pallagatti@gmail.com>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, Greg Mirsky <gregimirsky@gmail.com>, rtg-bfd WG <rtg-bfd@ietf.org>, "T. Sridhar" <tsridhar@vmware.com>, bfd-chairs@ietf.org, Martin Vigoureux <martin.vigoureux@nokia.com>, draft-ietf-bfd-vxlan@ietf.org
Content-Type: multipart/alternative; boundary="00000000000000dad6058f25ea85"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/6yugOOZRMwpjahEwnstBhJ3gWQI>
X-Mailman-Approved-At: Fri, 02 Aug 2019 10:48:45 -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: Fri, 02 Aug 2019 17:44:51 -0000

Thanks for verifying this. On Linux and hardware routers that I'm aware of
(Cisco circa 2012 and Cumulus), the physical MAC address is reused across
the VNIs on the VTEP. Did you check on a non-VMW device? This is more for
my own curiosity.

To address the general case, can we not define a well-known (or reserve
one) unicast MAC address for use with VTEP? If the MAC address is
configurable in BFD command, this can be moot.

Dinesh

On Fri, Aug 2, 2019 at 10:27 AM Santosh P K <santosh.pallagatti@gmail.com>
wrote:

> I have cross checked point raised about MAC address usage. It is possible
> that tenant could be using physical MAC address and when a packet comes
> with valid VNI with a MAC address that is being used by tenant then packet
> will be sent to that tenant. This rules out the fact that we could use
> physical MAC address as inner MAC to ensure packets get terminated at VTEP
> itself.
>
> Thanks
> Santosh P K
>
> On Wed, Jul 31, 2019 at 11:00 AM Santosh P K <santosh.pallagatti@gmail.com>
> wrote:
>
>> Joel,
>>    Thanks for your inputs. I checked implementation within Vmware.
>> Perhaps I should have been more clear about MAC address space while
>> checking internally. I will cross check again for the same and get back on
>> this list.
>>
>> Thanks
>> Santosh P K
>>
>> On Wed, Jul 31, 2019 at 10:54 AM Joel M. Halpern <jmh@joelhalpern.com>
>> wrote:
>>
>>> Sorry to ask a stupid question.  Whose implementation?
>>>
>>> The reason I ask is that as far as I can tell, since the tenant does not
>>> have any control access to the VTEP, there is no reason for the VTEP to
>>> have a MAC address in the tenant space.  Yes, the device has a physical
>>> MAC address.  But the tenant could well be using that MAC address.  Yes,
>>> they would be violating the Ethernet spec.  But the whole point of
>>> segregation is not to care about such issues.
>>>
>>> On the other hand, if you tell me that the VMWare implementation has an
>>> Ethernet address that is part of the tenant space, well, they made up
>>> this particular game.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 7/31/2019 1:44 PM, Santosh P K wrote:
>>> > 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
>>> > <mailto: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
>>> >     <mailto: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 <mailto: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
>>> >
>>>
>>