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

Anoop Ghanwani <anoop@alumni.duke.edu> Thu, 31 October 2019 16:33 UTC

Return-Path: <ghanwani@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 52C86120019; Thu, 31 Oct 2019 09:33:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 1I53d5b0CLUQ; Thu, 31 Oct 2019 09:33:49 -0700 (PDT)
Received: from mail-vs1-f44.google.com (mail-vs1-f44.google.com [209.85.217.44]) (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 136B1120099; Thu, 31 Oct 2019 09:33:49 -0700 (PDT)
Received: by mail-vs1-f44.google.com with SMTP id l5so4472453vsh.12; Thu, 31 Oct 2019 09:33:49 -0700 (PDT)
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=DHCGCUdUKXU117PuSOVyTU+Tq0CW/RutQco4X9EqolA=; b=COvTjnKrke7pbPxuvvacU4X+ndEMmcJYzf3NZaDCsZnQB2AOMOSozpGQBpd6zUURYJ iTIS726Re7iaSaF5Ffy8FLMcpV9nZ+6JevJ8ppxrjrKPvXA4OnWU2t3xUyL/U314bG2b Rk9ak21vTb/Tj7aHAdGDNqu13o4p7a76V6YXYQukMLYNk0zz1JRHkK+caVp/DaPQCf+2 QrFAh5CXzctXT4dkBgd66ceEEAgcu2aDpHljBqIEj2P7sYOZT0PB0cPXrn+WyCllK2CD dcwybL0B6FNQephHTH3Be2pBGl/UltBxEN/0RWA7Jxo838mkBAQd5OpJ8z5IxtTs3rfc KVCA==
X-Gm-Message-State: APjAAAVrHcCmP39YBnkUxqkwBL41FBl2kV8dh+Xs00DvW1yFWB8eGIcP pTY3c8aAUEupth8M+LTvGsFr6ozZQDQ+Xahx8X0=
X-Google-Smtp-Source: APXvYqwCbd1SPXqC5aVIQKyjv2U3yDm/0YrM+zuDpd6sc+IRpEGa1Ege+i+Ra4lv8I4/ShdZ2uj+gnruFI8g67uVM94=
X-Received: by 2002:a67:ea09:: with SMTP id g9mr3307288vso.23.1572539627734; Thu, 31 Oct 2019 09:33:47 -0700 (PDT)
MIME-Version: 1.0
References: <CA+-tSzw76E0AM2AJR=2GQsXJ3MtFUtsug7KoGQzAP-=Ds8u7Fg@mail.gmail.com> <aa853b8e-7ff4-a2d9-9b66-f9c22823ac9d@joelhalpern.com> <1572400778.28051.7@smtp.gmail.com> <CA+-tSzyNu8XVqL7=cGVaT7Mbg5yO6d3ohgv2qPTrMHRV1vw0rg@mail.gmail.com> <1a38424c-6bc1-4414-a7fd-c1e2105b581a@Spark> <CA+-tSzzSNnR=fKRU+mEX=d+tL5B0u8eNUAoGcPvfrna_qHL7Hg@mail.gmail.com> <1572435956.28051.12@smtp.gmail.com> <CA+RyBmWgvjDLdxEz7oZEfYjtJT=7CZbiV5bRkx=gf3hQHHokOw@mail.gmail.com> <20191030203051.GD10145@pfrc.org> <CA+RyBmVTWMOuXaWVk_i1Lk7i+GgfiESkfVcLXARNnPD0Y3N5zQ@mail.gmail.com> <20191030211742.GE10145@pfrc.org> <CA+RyBmUfKi79pnPqsA6KNFR9e6cqG42z8yo3c40BcZHL4D79zQ@mail.gmail.com> <34b67556-a405-e4d7-7f72-d097f1201860@joelhalpern.com> <51780FD6-DC02-435B-B18C-CA38C7267F67@pfrc.org>
In-Reply-To: <51780FD6-DC02-435B-B18C-CA38C7267F67@pfrc.org>
From: Anoop Ghanwani <anoop@alumni.duke.edu>
Date: Thu, 31 Oct 2019 09:33:36 -0700
Message-ID: <CA+-tSzzWeNJF8QqH6AUiTG7cK-F6ickjs=Tfd9C9U89gJ4AGCA@mail.gmail.com>
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, Greg Mirsky <gregimirsky@gmail.com>, Dinesh Dutt <didutt@gmail.com>, Santosh P K <santosh.pallagatti@gmail.com>, 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="000000000000e80a820596376988"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/0GNykD0PhtkCxQdirKhi1V0MpXA>
X-Mailman-Approved-At: Thu, 31 Oct 2019 09:42:40 -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: Thu, 31 Oct 2019 16:33:51 -0000

What is the definition of management VNI?  Is it that there is no VAP
corresponding to that VNI or something else?  If there is no VAP, then
there is no chance of forwarding such packets anyway.

Anoop

On Thu, Oct 31, 2019 at 9:22 AM Jeffrey Haas <jhaas@pfrc.org>; wrote:

> I also agree with Joel.
>
> -- Jeff
>
>
> > On Oct 31, 2019, at 11:59 AM, Joel M. Halpern <jmh@joelhalpern.com>;
> wrote:
> >
> > Explicitly restricting the discard behavior to the management VNI takes
> care of my concern.
> >
> > Thank you,
> > Joel
> >
> > On 10/31/2019 11:48 AM, Greg Mirsky wrote:
> >> Hi Jeff,
> >> thank you for the detailed clarification of your questions. Please find
> my follow-up notes in-lined tagged GIM2>>.
> >> Regards,
> >> Greg
> >> On Wed, Oct 30, 2019 at 2:14 PM Jeffrey Haas <jhaas@pfrc.org <mailto:
> jhaas@pfrc.org>>; wrote:
> >>    Greg,
> >>    On Wed, Oct 30, 2019 at 01:58:30PM -0700, Greg Mirsky wrote:
> >>     > On Wed, Oct 30, 2019 at 1:27 PM Jeffrey Haas <jhaas@pfrc.org
> >>    <mailto:jhaas@pfrc.org>> wrote:
> >>     >
> >>     > > Greg,
> >>     > >
> >>     > > From the updated text:
> >>     > >
> >>     > > "At the same time, a service layer BFD session may be used
> >>    between the
> >>     > > tenants of VTEPs IP1 and IP2 to provide end-to-end fault
> >>    management. In
> >>     > > such case, for VTEPs BFD Control packets of that session are
> >>     > > indistinguishable from data packets.  If end-to-end defect
> >>    detection is
> >>     > > realized as the set of concatenated OAM domains, e.g., VM1-1 -
> >>    IP1 --
> >>     > > IP2 - VM2-1, then the BFD session over VXLAN between VTEPs
> SHOULD
> >>     > > follow the procedures described in Section 6.8.17 [RFC5880]."
> >>     > >
> >>     > > In the case that two VMs are running BFD to each other as a user
> >>     > > application
> >>     > > rather than as part of the virtualized environment, it's
> >>    unlikely that
> >>     > > they'd be treated as concatenated domains.  To do so, the
> >>    tenant VMs would
> >>     > > have to have a sense that they are indeed virtual.
> >>     > >
> >>     > > Is your intent in this text that BFD implementations on the
> >>    server should
> >>     > > detect BFD sessions between servers and change them to a
> >>    concatenated
> >>     > > session?
> >>     > >
> >>     > GIM>> No, we do not suggest that the concatenation of BFD
> sessions be
> >>     > automagical. That may be controlled via the management plane
> though.
> >>    Then my suggestion is we may not want this text.
> >>    It's fine to say "if tenants want to run BFD to each other, and that
> is
> >>    standard BFD (RFC 5881) from the perspective of those tenants" if
> that's
> >>    your intent.  Leave automagic out of the spec. :-)
> >> GIM2>> I'd take the passage referring to the concatenated path out.
> That will leave it as:
> >>    At the same time, a service layer BFD session may be used between the
> >>    tenants of VTEPs IP1 and IP2 to provide end-to-end fault management.
> >>    In such case, for VTEPs BFD Control packets of that session are
> >>    indistinguishable from data packets.
> >>     > > Section 5 comment:
> >>     > >
> >>     > > :   The UDP destination port and the TTL of the inner IP packet
> >>    MUST be
> >>     > > :   validated to determine if the received packet can be
> >>    processed by
> >>     > > :   BFD.  BFD Control packets with unknown MAC address MUST NOT
> be
> >>     > > :   forwarded to VMs.
> >>     > >
> >>     > > I'd suggest pushing the second sentence into the prior section
> >>    since it
> >>     > > deals with MAC addresses rather than the UDP procedures.
> >>     > >
> >>     > GIM>> Could you please clarify your suggestion - move to Section
> >>    4 or to
> >>     > the preceding paragraph? I think it is the latter but wanted to
> >>    make sure.
> >>    Full section 5 from your draft-8 candidate:
> >>    : 5.  Reception of BFD Packet from VXLAN Tunnel
> >>    :
> >>    :    Once a packet is received, the VTEP MUST validate the packet.
>    If the
> >>    :    Destination MAC of the inner Ethernet frame matches one of the
> MAC
> >>    :    addresses associated with the VTEP the packet MUST be processed
> >>    :    further.  If the Destination MAC of the inner Ethernet frame
> >>    doesn't
> >>    :    match any of VTEP's MAC addresses, then the processing of the
> >>    :    received VXLAN packet MUST follow the procedures described in
> >>    :    Section 4.1 [RFC7348].
> >>    It's not clear what that procedure is, with respect to BFD.  Section
> 4.1
> >>    basically says is that when a mapping is discovered, deliver it to
> >>    that VM
> >>    with headers removed.
> >>    Section 4.1 really doesn't discuss dropping behavior.
> >>    :
> >>    :    The UDP destination port and the TTL of the inner IP packet
> MUST be
> >>    :    validated to determine if the received packet can be processed
> by
> >>    :    BFD.
> >>    This is fine.
> >>    :    BFD Control packets with unknown MAC address MUST NOT be
> >>    :    forwarded to VMs.
> >>    This appears to be clarifying the missing point in the prior
> >>    paragraph.  If
> >>    that's the case, why is this sentence not part of the prior
> paragraph?
> >> GIM>> So I thought. Moving the sentence to the first paragraph
> highlighted the contradiction others had pointed earlier:
> >> On the one hand:
> >>    If the Destination MAC of the inner Ethernet frame doesn't
> >>    match any of VTEP's MAC addresses, then the processing of the
> >>    received VXLAN packet MUST follow the procedures described in
> >>    Section 4.1 [RFC7348].
> >> To which we add:
> >>    BFD Control packets with unknown MAC address
> >>    MUST NOT be forwarded to VMs.
> >> But the unknown MACs are treated as BUM according to the last paragraph
> in Section 4.2 of RFC 7348:
> >>    Note that multicast frames and "unknown MAC destination" frames are
> >>    also sent using the multicast tree, similar to the broadcast frames.
> >> In light of that, can this draft require that BFD packets with unknown
> MAC be dropped and not flooded over the corresponding to the VNI domain? I
> think that in addition to moving the sentence up the statement must be
> updated:
> >> OLD TEXT:
> >>    BFD Control packets with unknown MAC address
> >>    MUST NOT be forwarded to VMs.
> >> NEW TEXT:
> >>    If the BFD session is using the Management VNI (Section 6),
> >>    BFD Control packets with unknown MAC address
> >>    MUST NOT be forwarded to VMs.
> >>  Comments? Suggestions?
> >>    -- Jeff
>
>