Re: WGLC comments on draft-ietf-bfd-vxlan

Greg Mirsky <gregimirsky@gmail.com> Fri, 09 November 2018 01:50 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 25D20124D68; Thu, 8 Nov 2018 17:50:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_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 jopMkb5D0WFR; Thu, 8 Nov 2018 17:50:40 -0800 (PST)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 4AA9F1252B7; Thu, 8 Nov 2018 17:50:40 -0800 (PST)
Received: by mail-lj1-x230.google.com with SMTP id x85-v6so249827ljb.2; Thu, 08 Nov 2018 17:50:39 -0800 (PST)
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=838sm7dRYMIPmzEaK/0Ix+SGyvN8cyrweqOHpODnXdY=; b=JNkB7QZHtgCLRwbRDJ9FgULFOG7pU4XRb9bKEjT9sqfg6B21GpoqBxMKq3gxrWKNo5 NLMYbPsa5BcUpMMZFh3E9Yqwd5HPuDdJXb/bXVE8qkxw/n0p9swqxG8FYZ8P4AtrjdH3 tIuOS5yLrlCKkJEVeTC/cTfVer6m9qcN4aerzjGwnwtnBaigirEIV4Pamy8mwBET4hhY qAzdhM3/qliWFvSjbCODXxlsfo3szQga8K5PQkMPnXQPYL8RKycpYAWehEJ7N7sWtxTP xLDyk0xvVzyxusQqDkFITKqm4sgUy+Ljp0gQm0ie1jTuxbk5LRTzCiWg0hSaUZbfBQ9+ C4lg==
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=838sm7dRYMIPmzEaK/0Ix+SGyvN8cyrweqOHpODnXdY=; b=idi32E6fq9M33VPfZDT/Gyct0tzVKWlGjcz9NxJQwuXWT2C3E1QhtYKpawVOVmfsKy npUji4bFCav1ETOmeq7cb1ELX3E01wY9xv8BkxDxI70lewj/l8WnfZnsbmVUV49M3RMb eFA4cxQrwffHADargm6Fico62FHQUeXN7PVrr7OPnuXYKHWTp8/TOZytmplShqXGv78u pGqfwIRu9Z4Vl5gGpsQ25MhJHNbBvIdvIANYAO0zGx90WDjDNVXjYCL5OfHL4ggaPGz8 rIz2FfO9Hz4hGLYG4rLkJq0vlvnXJkRtd0rtPsuuwoktdbRs3qeHMOulAM/ODVGTJtxZ B84Q==
X-Gm-Message-State: AGRZ1gJqzGrbn29em0Psd6DK/qYwjSHTOASIwDTfp+1gTsiPq5kI1kXf mWJ58L2LXjsJmprxVKnYhAlBTQcE30PScdikXF0=
X-Google-Smtp-Source: AJdET5f7ctjaZ74gEf0qJcEcmRs8HdrX7Gk3Mr2SamOCsA+oHqUPpRtn42vlKvCe7iPQUamfjf4AONhUXj41Q2NNYng=
X-Received: by 2002:a2e:484:: with SMTP id a4-v6mr4235402ljf.27.1541728237697; Thu, 08 Nov 2018 17:50:37 -0800 (PST)
MIME-Version: 1.0
References: <CA+-tSzxFxtVo6NbfSw4wzb--fSuN4zsSvX7R58iiYFgVF5cA6Q@mail.gmail.com>
In-Reply-To: <CA+-tSzxFxtVo6NbfSw4wzb--fSuN4zsSvX7R58iiYFgVF5cA6Q@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Fri, 09 Nov 2018 08:50:27 +0700
Message-ID: <CA+RyBmXwym7u27P2=hPZ0LhGHFQmOOfwDjJAjdbVq01yLBL3Fg@mail.gmail.com>
Subject: Re: WGLC comments on draft-ietf-bfd-vxlan
To: Anoop Ghanwani <anoop@alumni.duke.edu>
Cc: rtg-bfd WG <rtg-bfd@ietf.org>, NVO3 <nvo3@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f2c156057a3193d2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/A5xDp1-1MqK8JnO8JDyP1ShEke0>
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, 09 Nov 2018 01:50:43 -0000

Hi Anoop,
thank you for your thorough review and the comments. I'm traveling over the
weekend and will respond in details later next week.

Regards,
Greg

On Thu, Nov 8, 2018 at 4:58 PM Anoop Ghanwani <anoop@alumni.duke.edu> wrote:

>
> Here are my comments.
>
> Thanks,
> Anoop
>
> ==
>
> Philosophical
>
> Since VXLAN is not an IETF standard, should we be defining a standard for
> running BFD on it?  Should we define BFD over Geneve instead which is the
> official WG selection?  Is that going to be a separate document?
>
> Technical
>
> Section 1:
>
> This part needs to be rewritten:
> >>>
> The individual racks may be part of a different Layer 3 network, or they
> could be in a single Layer 2 network. The VXLAN segments/overlays are
> overlaid on top of Layer 3 network. A VM can communicate with another VM
> only if they are on the same VXLAN segment.
> >>>
> It's hard to parse and, given IRB, the last sentence above is wrong.
>
> Section 3:
> >>>
>  Most deployments will have VMs with only L2 capabilities that
> may not support L3.
> >>>
> Are you suggesting most deployments have VMs with no IP
> addresses/configuration?
>
> >>>
> Having a hierarchical OAM model helps localize faults though it requires
> additional consideration.
> >>>
> What are the additional considerations?
>
> Would be useful to add a reference to RFC 8293 in case the reader would
> like to know more about service nodes.
>
> Section 4
> >>>
> Separate BFD sessions can be established between the VTEPs (IP1 and IP2)
> for monitoring each of the VXLAN tunnels (VNI 100 and 200).
> >>>
> IMO, the document should mention that this could lead to scaling issues
> given that VTEPs can support well in excess of 4K VNIs.  Additionally, we
> should mention that with IRB, a given VNI may not even exist on the
> destination VTEP.  Finally, what is the benefit of doing this?  There may
> be certain corner cases where it's useful (vs a single BFD session between
> the VTEPs for all VNIs) but it would be good to explain what those are.
>
> Sections 5.1 and 6.1
>
> In 5.1 we have
> >>>
> The inner MAC frame carrying the BFD payload has the
> following format:
> ... Source IP: IP address of the originating VTEP. Destination IP: IP
> address of the terminating VTEP.
> >>>
>
> In 6.1 we have
> >>>
>
> Since multiple BFD sessions may be running between two
> VTEPs, there needs to be a mechanism for demultiplexing received BF
>
> packets to the proper session.  The procedure for demultiplexing
> packets with Your Discriminator equal to 0 is different from[RFC5880 <https://tools.ietf.org/html/rfc5880>].
>
> *For such packets, the BFD session MUST be identified*
>
> *using the inner headers, i.e., the source IP and the destination IP
> present in the IP header carried by the payload of the VXLAN*
>
> *encapsulated packet.*
>
>
> >>>
> How does this work if the source IP and dest IP are the same as specified
> in 5.1?
>
> Editorial
>
> - Terminology section should be renamed to acronyms.
> - Document would benefit from a thorough editorial scrub, but maybe that
> will happen once it gets to the RFC editor.
>
> Section 1
> >>>
> "Virtual eXtensible Local Area Network" (VXLAN) [RFC7348
> <https://tools.ietf.org/html/rfc7348>]. provides an encapsulation scheme
> that allows virtual machines (VMs) to communicate in a data center network.
> >>>
> This is not accurate.  VXLAN allows you to implement an overlay to
> decouple the address space of the attached hosts from that of the network.
>
> Section 7
>
> VTEP's -> VTEPs
>
>