WGLC comments on draft-ietf-bfd-vxlan

Anoop Ghanwani <anoop@alumni.duke.edu> Thu, 08 November 2018 09:58 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 3753B130E46; Thu, 8 Nov 2018 01:58:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id EaKBdb77ztfw; Thu, 8 Nov 2018 01:58:28 -0800 (PST)
Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com []) (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 B8B9E130E2E; Thu, 8 Nov 2018 01:58:27 -0800 (PST)
Received: by mail-vs1-f50.google.com with SMTP id g68so7897474vsd.11; Thu, 08 Nov 2018 01:58:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yqvVOqiL+VLyLZQG0BnaHgiayZ1B7olom0J0by1RU2c=; b=fKf3aRYJ6+oLdvfRZ2bfNhEflhQdl66l9/UPA20VW1U01W+cPJ9+tYOy6b5aZB1oAF q0QLVt7HyT42Ekq7yqIjZBjH6FdN8yFQBFX/Mv9io7J9lUxoti2gmrHCQxyV47v73bX/ 3tgdWrjz4V6g9vtVLcsvUmE0tlx+PAePSpzVWGEKd4snl6YMDkLraqD6XUQgNJ6t59dP nI6XSX4Iv7JYDgFiU4q5+TLp40KeKD46/MwRZuDlelrDv57O8nMCpDUYvev1peX3zVz3 bEn06IWR+SAgPkjMGZNPeSIgkQGR2mmxEdEjxPiQUfvjdKMiR19tYJH+d04EzWdIW1lc /UyQ==
X-Gm-Message-State: AGRZ1gIBhSVBErW13T6qUIlmVBM6oS7UDZcyep8SKIWJ4eSD7RiYhYK4 uBSp7ZsIfZxwOQ0wxEkmZkSx0bg5qV31vkAXiYqmnTxn
X-Google-Smtp-Source: AJdET5d+nnGQLDm6sdT2u1ihdUe+9yJu8MIebFJfcUY+/lTlqpcCY/Wzr1+7rN7KgC8dg9+tWpHWQ1Rj0HmSsewCphM=
X-Received: by 2002:a67:741:: with SMTP id 62mr1482222vsh.228.1541671106471; Thu, 08 Nov 2018 01:58:26 -0800 (PST)
MIME-Version: 1.0
From: Anoop Ghanwani <anoop@alumni.duke.edu>
Date: Thu, 8 Nov 2018 01:58:12 -0800
Message-ID: <CA+-tSzxFxtVo6NbfSw4wzb--fSuN4zsSvX7R58iiYFgVF5cA6Q@mail.gmail.com>
Subject: WGLC comments on draft-ietf-bfd-vxlan
To: rtg-bfd@ietf.org, nvo3@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a96d41057a2446bd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/GWdd4jcd-J6g_7Lu4ZNe8gZ4ErA>
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, 08 Nov 2018 09:58:30 -0000

Here are my comments.




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?


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

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

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


- 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