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

Dinesh Dutt <didutt@gmail.com> Wed, 23 October 2019 21:26 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 D18AA1200A4; Wed, 23 Oct 2019 14:26:15 -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 oUYzd9VvTJYk; Wed, 23 Oct 2019 14:26:13 -0700 (PDT)
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 DEB92120100; Wed, 23 Oct 2019 14:26:12 -0700 (PDT)
Received: by mail-pg1-x530.google.com with SMTP id 23so12891646pgk.3; Wed, 23 Oct 2019 14:26:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=lpjNO5kQKa1TexolVSnX3wdML7M9zkzlNz6MZEo293Y=; b=Acn3/PwIrlSW/KvZOaSUBexbEshUZeZPgrlnKHP2eNWA9WL+ryPE9eqviYqztgXIN2 cTElESmpt/WqUYc58ncEcdBiwtVxA5enQKMjV7WfOlBMnGkvShfLnwHtC6IaHoC7rqYL lVYiyHT/e1OcxcnUgjBtsXSirOmmHmcxQo3trQtZ0tfBoE1LoJtrE0WAzecCyG8/crC9 RBAKEJtcPjmhpEerbPQbXTC4LZYqsHlLN/BntnW186Da91ERHuD1bV3eXJpIqk1VnJOe oLeH9J6AosjPZL1Ukz7Nbe213XJ8/GSxi3/a70Z7fGp7Dx4GIvSRbylp6ytyzNXb2G47 YdMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=lpjNO5kQKa1TexolVSnX3wdML7M9zkzlNz6MZEo293Y=; b=ufvqQCYFLk2aaUWy9vYDQBMnsXPYoAxC5OaojXpMwKyRR1xlN0vv+YRRMcAhvtnsGG xdPn4+1cf8uzdIZeZDWfu4QOuKjytE3hcXbYz3zvnJrzpFVTb4zpJSb3Y9bhhnPGt17Y dwVhvIjUDjllpjcL9Ib4Y4f0Q07GBHbF+ardt5HVh83A3PmwaA/oobmyKZx2qSkzMwLr /MaQPKcDBJZxOZf+hOcWnHTM6Lmlu9U0Tq11CyX68TMWrKH3dWnY0YoYjS9g7GmeSH6A Al8h1yz8C6yvkP9BHub2Bn1WyLNnQSIjGUMke/sJgQAFj1YSX5A5XH2SJDkivhM91AZ9 nwaA==
X-Gm-Message-State: APjAAAUfrM2GXRA8gq+Fl/q6+mbCd1Mg2WNKGXBqxXML1QJJd4ef30wL A+YX2ElH1Eyg93KhNPHUvGU=
X-Google-Smtp-Source: APXvYqwQWxeqvg0dz1VKamRkEkhUAEL8wjwWGyadRGFf2VSQP9Sz4q8/xzqVQYRuqq9SwliTHYHo+A==
X-Received: by 2002:a63:8b4a:: with SMTP id j71mr12033771pge.186.1571865972142; Wed, 23 Oct 2019 14:26:12 -0700 (PDT)
Received: from [192.168.0.106] ([117.216.128.128]) by smtp.gmail.com with ESMTPSA id z5sm23137248pgi.19.2019.10.23.14.26.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Oct 2019 14:26:10 -0700 (PDT)
Date: Thu, 24 Oct 2019 02:55:56 +0530
From: Dinesh Dutt <didutt@gmail.com>
To: Greg Mirsky <gregimirsky@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
Message-ID: <b470569f-43e7-4012-ac8f-1ee63a6424fc@Spark>
In-Reply-To: <CA+RyBmVJ_q37ZzLO2ABhkpT1YvLRQNcLhZd+-UG9=M0xXATASA@mail.gmail.com>
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> <CA+RyBmVJ_q37ZzLO2ABhkpT1YvLRQNcLhZd+-UG9=M0xXATASA@mail.gmail.com>
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
X-Readdle-Message-ID: b470569f-43e7-4012-ac8f-1ee63a6424fc@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5db0c56a_559fe50_c2e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/LUxCrX0BukyO-XxIlW97Fz5ejgA>
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 21:26:16 -0000

You're welcome Greg. I'm glad my input was useful,

Dinesh
On Oct 24, 2019, 1:33 AM +0530, Greg Mirsky <gregimirsky@gmail.com>om>, wrote:
> 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