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, 09 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 > >
- WGLC comments on draft-ietf-bfd-vxlan Anoop Ghanwani
- Re: WGLC comments on draft-ietf-bfd-vxlan Greg Mirsky
- Re: WGLC comments on draft-ietf-bfd-vxlan Greg Mirsky
- Re: WGLC comments on draft-ietf-bfd-vxlan Greg Mirsky
- Re: WGLC comments on draft-ietf-bfd-vxlan Anoop Ghanwani
- Re: WGLC comments on draft-ietf-bfd-vxlan Greg Mirsky
- Re: WGLC comments on draft-ietf-bfd-vxlan Anoop Ghanwani
- Re: WGLC comments on draft-ietf-bfd-vxlan Greg Mirsky
- Re: WGLC comments on draft-ietf-bfd-vxlan Anoop Ghanwani
- Re: WGLC comments on draft-ietf-bfd-vxlan Greg Mirsky
- Re: WGLC comments on draft-ietf-bfd-vxlan Anoop Ghanwani
- Re: WGLC comments on draft-ietf-bfd-vxlan Greg Mirsky
- Re: WGLC comments on draft-ietf-bfd-vxlan Anoop Ghanwani
- Re: WGLC comments on draft-ietf-bfd-vxlan Greg Mirsky
- Re: WGLC comments on draft-ietf-bfd-vxlan Anoop Ghanwani
- Re: WGLC comments on draft-ietf-bfd-vxlan Greg Mirsky