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

Greg Mirsky <gregimirsky@gmail.com> Fri, 09 November 2018 01:51 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 437111252B7; Thu, 8 Nov 2018 17:51:16 -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 JOES5JlH9CVs; Thu, 8 Nov 2018 17:51:13 -0800 (PST)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 DCD6F124D68; Thu, 8 Nov 2018 17:51:12 -0800 (PST)
Received: by mail-lf1-x133.google.com with SMTP id f23so167773lfc.13; Thu, 08 Nov 2018 17:51:12 -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=bpPX8orBwszJN7FMmMoi4z6SpatbOzqWzbiTt5q8gvc=; b=IetMboJxExZREsjFaXAzGPnFvRUl+zp+MLi+ONWtPKYLEykyatFF2EzwYLeRDXbcvc pRLdkhBK+mu78zFEQIW8hnvNZMIeU7aUf+elc4Gw0mwtUbEAB3xr1jJsL+1O5j5apauR u8+3j800gyQ2TNHlM8ebG3c4l7Wu93E/gIE7FlAo0zKu3oChF0dZrBZTKCE7mblsZ2/1 0g/+OMfiBaCWznQQSvxW4cSACUvEuiCrIL7kuY7Hpmw/vnVZjrRpxIt7zCoIYtmsoHJm baatTSoSI6tgOgyj5BjFDAaWxpyHeH5ELKxG2SLfXAPOnYjEn5SFrt/Db/8HbsvFsUUH AuNg==
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=bpPX8orBwszJN7FMmMoi4z6SpatbOzqWzbiTt5q8gvc=; b=tE7cxsgZhsGySuDVCZ7nJdnhXp1P8kpQKOnCz2D8YBpbQFKapnRpZi7C2L/URmM0vg Txk27NfP5ZUb61ID6lkJ+GPrcCxxQ8DOZwojLn6nh8u48/y6/jUuyhtcGYjEKrsVK/UJ t/uaXurmAfByMv5TVUNhPt6jZAgNDyt/1CgoQqATRqeWueVpZtF/nGooZ3aPGT3P7kKo pV0Ex7uvC4/IsAWxDyC0kI87sE4/RRhAD4EV1l5UU9QsuDzrTG729Chusy5sP4p7OaxJ 6hB9BWqfOB2aOIDSuHUa9AO3aIkqLAyDgwzdka2tOF/yuV/E4zgLtgSqmPNM6jvbe8jI ttuw==
X-Gm-Message-State: AGRZ1gKtXb6VkzBodsakMuBA2KLooTUu2tgs02wjqpOVDHEtiFmv0r0I STfkqhRF/wnUb44mn5TvlHAZbrFrOYurXCADGAw5Bl4T
X-Google-Smtp-Source: AJdET5f8QlrVXuTAcpw1eOdfUxh2btYBvRpE7+xxOAQiNHRCeucIH+jW4xxoDeEjSPY/D0g6DJ2dmJbWvM52boBnTGQ=
X-Received: by 2002:a19:4c02:: with SMTP id z2-v6mr4038052lfa.48.1541728270842; Thu, 08 Nov 2018 17:51:10 -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, 9 Nov 2018 08:50:59 +0700
Message-ID: <CA+RyBmWPgVRudUkP2KBZ17-LpCB=pR2cYd-rt_GDWhiZZ+3KZQ@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="000000000000ec80a1057a3195dd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/m5GkFRFyOhl2VrnH40BaI8HhOrI>
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:51:16 -0000

Hi Anoop,
thank you for your thorough review and the comments you've shared. Please
find my answers below tagged GIM>>.

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
>
>