Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

Greg Mirsky <gregimirsky@gmail.com> Wed, 23 October 2019 20:03 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 0CF45120274; Wed, 23 Oct 2019 13:03:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=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 Zr4SVZe4gzZu; Wed, 23 Oct 2019 13:03:19 -0700 (PDT)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 E324D120129; Wed, 23 Oct 2019 13:03:18 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id v24so22464623ljj.3; Wed, 23 Oct 2019 13:03:18 -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=dKa9YLMEbO52aPvkshcsM2ObUEWjti2/qPsfZcXv/0c=; b=IfvaXjuBczdrfEscj+DXzjZO6Y0Cn6eFfZh5TJih+wT9baBSvaMetheruomMf7vZfU PxWM51O5PNsAOIJVM/OhOpUfhyVe9IW8AO787yKYwqCxJKvhHAl8cBN6dqRt2iX7s2R8 g3C40qmR78iz0rWC43cpQtKMXFGsJOc6rdx9UtN2TVl3dWuXPPtz5z/zcI5hSHm0NWv+ lgbUOangLR8LO43ZRCw3993iSIhmNbIUJyUaF5ISTuYgALA5w7XyOXnSpFKkd/padaAX 0MRyLHDE3usjQfWFBr/JTmB8Xowzy/L+0707WkTi9uRzYprb+Z0B+Baiztdf6ful4GaC SDFw==
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=dKa9YLMEbO52aPvkshcsM2ObUEWjti2/qPsfZcXv/0c=; b=b/XksQYtE+GuAzOIZfiiOgGkzBCK7SxeYKMiWBnoGTHNdhCkibcKep0umuheNTvaxg cPiED0qJGydShMdyKAfaPn3o/3+IG93fSOMgycvI9+bqFVjsXnuKcvyXIAVwlIiRcfaH 8VNZmgxB6omMpfhgXl/zhOPg/xLRWq9I2ylrNFyqxOrpxbbVw9RpHTflcXo9Xvn4jvlU 51xtm2iVrfQdnGVgyQd2zOm4GvaVHoPKfzZudWzSiJK/u49jT80UK5sWm1vyr6WBLeOB T7WhSGtIs8/az7gQVJHafJvx3Y3YFSSPQPaJ2fHkEHVYXPGhR/hWNjxayYn9Iu7Rzqby tmrg==
X-Gm-Message-State: APjAAAXQIgtSNFeTgxJHHlvAJXTNTB/tj6uIDCXU7HcyN3fmjcG+unW4 lAnGGbN9fGqgoLK+Stj18lxKj0bvB60H3Taf2FM=
X-Google-Smtp-Source: APXvYqxI2IrRZe2gLaIdOpEHVyZFYzU7t5YefnGO6tyblKw+Onq8DzFttwzFqf5NVXzqxrEGRCUIZVYRuGRjNbDY0kE=
X-Received: by 2002:a2e:a0d6:: with SMTP id f22mr24056838ljm.74.1571860996860; Wed, 23 Oct 2019 13:03:16 -0700 (PDT)
MIME-Version: 1.0
References: <CACi9rdu8PKsLW_Pq4ww5DEwLL8Bs6Hq1Je_jmAjES4LKBuE8MQ@mail.gmail.com> <201909251039413767352@zte.com.cn> <CACi9rdv-760M8WgZ1mOOOa=yoJqQFP=vdc3xJKLe7wCR18NSvA@mail.gmail.com> <20191021210752.GA8916@pfrc.org> <0e99a541-b2ca-85d4-4a8f-1165cf7ac01e@joelhalpern.com> <CA+-tSzziDc+Tk8AYfOr5-Xn6oO_uqW2C1dRA9LLOBBVmzVhWEQ@mail.gmail.com> <CA+RyBmVcBgeoGc2z5Gv0grv8OY34tyw+T-T-W2vn1O3AxCSQ9Q@mail.gmail.com> <CA+-tSzyHgspKBfLWZ3C69EBb+-k-POqJ7vG7VoN=g077+qzGBA@mail.gmail.com> <1571795542.10436.5@smtp.gmail.com> <CA+RyBmXkyQMumeCDxM6OSzdn=DCL=aeyQ+tJmUiyEg0VZuUpRg@mail.gmail.com> <1571798869.2855.1@smtp.gmail.com> <CACi9rduyvhweJd_aNx6miiUGyu-nCeqnNHGbPjyCfswHx1RD5A@mail.gmail.com> <CA+RyBmXLBLARxhA4MUvD6DE8vvY1oDP0opkxDqiPA4zYw9Jpug@mail.gmail.com> <1571860470.2855.11@smtp.gmail.com>
In-Reply-To: <1571860470.2855.11@smtp.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 23 Oct 2019 16:03:04 -0400
Message-ID: <CA+RyBmVJ_q37ZzLO2ABhkpT1YvLRQNcLhZd+-UG9=M0xXATASA@mail.gmail.com>
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
To: Dinesh Dutt <didutt@gmail.com>
Cc: Santosh P K <santosh.pallagatti@gmail.com>, Anoop Ghanwani <anoop@alumni.duke.edu>, "Joel M. Halpern" <jmh@joelhalpern.com>, Jeffrey Haas <jhaas@pfrc.org>, NVO3 <nvo3@ietf.org>, draft-ietf-bfd-vxlan@ietf.org, rtg-bfd WG <rtg-bfd@ietf.org>, "T. Sridhar" <tsridhar@vmware.com>, xiao.min2@zte.com.cn
Content-Type: multipart/alternative; boundary="0000000000005aade105959968f2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/rc5LeZfB_CT8vy2QL-AToFxFqvU>
X-Mailman-Approved-At: Wed, 23 Oct 2019 14:53:52 -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, 23 Oct 2019 20:03:23 -0000

Hi Dinesh,
many thanks for your time, the expertise you've kindly shared on this
discussion.
I believe that Santosh has volunteered ;) to provide some text on the
firewall interaction. Any other contributions are welcome and greatly
appreciated.

Regards,
Greg

On Wed, Oct 23, 2019 at 3:54 PM Dinesh Dutt <didutt@gmail.com> wrote:

> Looks good to me Greg. I see that the text around the use of the inner IP
> address as also quite acceptable. Will you add any words about the firewall?
>
> Dinesh
>
> On Wed, Oct 23, 2019 at 8:36 PM, Greg Mirsky <gregimirsky@gmail.com>
> wrote:
>
> Hi Dinesh, et al.,
> please check the updated version that removed the reference to Hypervisor
> in the text and Figure 1.
>
> Regards,
> Greg
>
> On Wed, Oct 23, 2019 at 10:47 AM Santosh P K <santosh.pallagatti@gmail.com>
> wrote:
>
>> Dinesh,
>>      Please see my inline comments [SPK]
>>
>>>
>>> - In section 3, there's a sentence that is: "BFD packets intended for a
>>> Hypervisor VTEP MUST NOT..". I recommend getting rid of the word
>>> "Hypervisor" ashe logic applies to any VTEP.
>>>
>>> [SPK] Thanks for comments. We will change this.
>>
>>
>>> - You already explained the precedence of the use of 127/8 address in
>>> the inner header in MPLS. I have no specific comments in that area. I have
>>> only two questions:
>>>    - Has anybody verified that the use of 127/8 address (and the right
>>> MAC) works with existing implementations, including the silicon ones? If
>>> this doesn't work there, is it worth adding the possibilit y of another
>>> address, one that is owned by the VTEP node?
>>>
>>    - Do we know if Firewalls stop such VXLAN packets? I ask this because
>>> VXLAN has an IP header and I don't know if firewalls stop packets with
>>> 127/8 in the inner header. If not, is it worth adding a sentence to say
>>> that firewalls  allow such packets? The use of a non-127/8 address may
>>> alleviate this case as well.
>>>
>>
>> [SPK] I think we may need to add the text about firewall as some checks
>> in firewall will be there if they are not already using MPLS OAM which has
>> inner IP header with 127/8 address range.
>>
>>
>>>
>>> The rest of the draft looks good to me,
>>>
>>> Dinesh
>>>
>>> On Wed, Oct 23, 2019 at 7:58 AM, Greg Mirsky <gregimirsky@gmail.com>
>>> wrote:
>>>
>>> Hi Dinesh,
>>> I greatly appreciate your comments. Please heave a look at the attached
>>> copy of the working version and its diff to -07 (latest in the datatracker).
>>>
>>> Regards,
>>> Greg
>>>
>>> On Tue, Oct 22, 2019 at 9:52 PM Dinesh Dutt <didutt@gmail.com> wrote:
>>>
>>>> I have the same feeling as Anoop. Greg, can you please point me to the
>>>> latest draft so that I can quickly glance through it to be doubly sure,
>>>>
>>>> Dinesh
>>>>
>>>> On Wed, Oct 23, 2019 at 4:35 AM, Anoop Ghanwani <anoop@alumni.duke.edu>
>>>> wrote:
>>>>
>>>> Greg,
>>>>
>>>> I think the draft is fine as is.
>>>>
>>>> I discussion with Xiao Min was about #3 and I see that as unnecessary
>>>> until we have a draft that explains why that is needed in the context of
>>>> the NVO3 architecture.
>>>>
>>>> Anoop
>>>>
>>>> On Tue, Oct 22, 2019 at 11:17 AM Greg Mirsky <gregimirsky@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Anoop, et al.,
>>>>> I agree with your understanding of what is being defined in the
>>>>> current version of the BFD over VxLAN specification. But, as I understand,
>>>>> the WG is discussing the scope before the WGLC is closed. I believe there
>>>>> are three options:
>>>>>
>>>>>    1. single BFD session between two VTEPs
>>>>>    2. single BFD session per VNI between two VTEPs
>>>>>    3. multiple BFD sessions per VNI between two VTEPs
>>>>>
>>>>> The current text reflects #2. Is WG accepts this scope? If not, which
>>>>> option WG would accept?
>>>>>
>>>>> Regards,
>>>>> Greg
>>>>>
>>>>> On Tue, Oct 22, 2019 at 2:09 PM Anoop Ghanwani <anoop@alumni.duke.edu>
>>>>> wrote:
>>>>>
>>>>>> I concur with Joel's assessment with the following clarifications.
>>>>>>
>>>>>> The current document is already capable of monitoring multiple VNIs
>>>>>> between VTEPs.
>>>>>>
>>>>>> The issue under discussion was how do we use BFD to monitor multiple
>>>>>> VAPs that use the same VNI between a pair of VTEPs.  The use case for this
>>>>>> is not clear to me, as from my understanding, we cannot have a situation
>>>>>> with multiple VAPs using the same VNI--there is 1:1 mapping between VAP and
>>>>>> VNI.
>>>>>>
>>>>>> Anoop
>>>>>>
>>>>>> On Tue, Oct 22, 2019 at 6:06 AM Joel M. Halpern <jmh@joelhalpern.com>
>>>>>> wrote:
>>>>>>
>>>>>>>  From what I can tell, there are two separate problems.
>>>>>>> The document we have is a VTEP-VTEP monitoring document.  There is
>>>>>>> no
>>>>>>> need for that document to handle the multiple VNI case.
>>>>>>> If folks want a protocol for doing BFD monitoring of things behind
>>>>>>> the
>>>>>>> VTEPs (multiple VNIs), then do that as a separate document.   The
>>>>>>> encoding will be a tenant encoding, and thus sesparate from what is
>>>>>>> defined in this document.
>>>>>>>
>>>>>>> Yours,
>>>>>>> Joel
>>>>>>>
>>>>>>> On 10/21/2019 5:07 PM, Jeffrey Haas wrote:
>>>>>>> > Santosh and others,
>>>>>>> >
>>>>>>> > On Thu, Oct 03, 2019 at 07:50:20PM +0530, Santosh P K wrote:
>>>>>>> >>     Thanks for your explanation. This helps a lot. I would wait
>>>>>>> for more
>>>>>>> >> comments from others to see if this what we need in this draft to
>>>>>>> be
>>>>>>> >> supported based on that we can provide appropriate sections in
>>>>>>> the draft.
>>>>>>> >
>>>>>>> > The threads on the list have spidered to the point where it is
>>>>>>> challenging
>>>>>>> > to follow what the current status of the draft is, or should be.
>>>>>>> :-)
>>>>>>> >
>>>>>>> > However, if I've followed things properly, the question below is
>>>>>>> really the
>>>>>>> > hinge point on what our encapsulation for BFD over vxlan should
>>>>>>> look like.
>>>>>>> > Correct?
>>>>>>> >
>>>>>>> > Essentially, do we or do we not require the ability to permit
>>>>>>> multiple BFD
>>>>>>> > sessions between distinct VAPs?
>>>>>>> >
>>>>>>> > If this is so, do we have a sense as to how we should proceed?
>>>>>>> >
>>>>>>> > -- Jeff
>>>>>>> >
>>>>>>> > [context preserved below...]
>>>>>>> >
>>>>>>> >> Santosh P K
>>>>>>> >>
>>>>>>> >> On Wed, Sep 25, 2019 at 8:10 AM <xiao.min2@zte.com.cn> wrote:
>>>>>>> >>
>>>>>>> >>> Hi Santosh,
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>> With regard to the question whether we should allow multiple BFD
>>>>>>> sessions
>>>>>>> >>> for the same VNI or not, IMHO we should allow it, more
>>>>>>> explanation as
>>>>>>> >>> follows.
>>>>>>> >>>
>>>>>>> >>> Below is a figure derived from figure 2 of RFC8014 (An
>>>>>>> Architecture for
>>>>>>> >>> Data-Center Network Virtualization over Layer 3 (NVO3)).
>>>>>>> >>>
>>>>>>> >>>                      |         Data Center Network (IP)        |
>>>>>>> >>>                      |                                         |
>>>>>>> >>>                      +-----------------------------------------+
>>>>>>> >>>                           |                           |
>>>>>>> >>>                           |       Tunnel Overlay      |
>>>>>>> >>>              +------------+---------+
>>>>>>>  +---------+------------+
>>>>>>> >>>              | +----------+-------+ |       |
>>>>>>> +-------+----------+ |
>>>>>>> >>>              | |  Overlay Module  | |       | |  Overlay Module
>>>>>>> | |
>>>>>>> >>>              | +---------+--------+ |       |
>>>>>>> +---------+--------+ |
>>>>>>> >>>              |           |          |       |           |
>>>>>>>   |
>>>>>>> >>>       NVE1   |           |          |       |           |
>>>>>>>   | NVE2
>>>>>>> >>>              |  +--------+-------+  |       |
>>>>>>> +--------+-------+  |
>>>>>>> >>>              |  |VNI1 VNI2  VNI1 |  |       |  | VNI1 VNI2 VNI1
>>>>>>> |  |
>>>>>>> >>>              |  +-+-----+----+---+  |       |
>>>>>>> +-+-----+-----+--+  |
>>>>>>> >>>              |VAP1| VAP2|    | VAP3 |       |VAP1| VAP2|     |
>>>>>>> VAP3|
>>>>>>> >>>              +----+-----+----+------+
>>>>>>>  +----+-----+-----+-----+
>>>>>>> >>>                   |     |    |                   |     |     |
>>>>>>> >>>                   |     |    |                   |     |     |
>>>>>>> >>>                   |     |    |                   |     |     |
>>>>>>> >>>
>>>>>>> -------+-----+----+-------------------+-----+-----+-------
>>>>>>> >>>                   |     |    |     Tenant        |     |     |
>>>>>>> >>>              TSI1 | TSI2|    | TSI3          TSI1| TSI2|
>>>>>>>  |TSI3
>>>>>>> >>>                  +---+ +---+ +---+             +---+ +---+
>>>>>>>  +---+
>>>>>>> >>>                  |TS1| |TS2| |TS3|             |TS4| |TS5|
>>>>>>>  |TS6|
>>>>>>> >>>                  +---+ +---+ +---+             +---+ +---+
>>>>>>>  +---+
>>>>>>> >>>
>>>>>>> >>> To my understanding, the BFD sessions between NVE1 and NVE2 are
>>>>>>> actually
>>>>>>> >>> initiated and terminated at VAP of NVE.
>>>>>>> >>>
>>>>>>> >>> If the network operator want to set up one BFD session between
>>>>>>> VAP1 of
>>>>>>> >>> NVE1 and VAP1of NVE2, at the same time another BFD session
>>>>>>> between VAP3 of
>>>>>>> >>> NVE1 and VAP3 of NVE2, although the two BFD sessions are for the
>>>>>>> same
>>>>>>> >>> VNI1, I believe it's reasonable, so that's why I think we should
>>>>>>> allow it
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> nvo3 mailing list
>>>>>>> nvo3@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>>>>>
>>>>>>