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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [209.85.217.50]) (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.

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