[Tsv-art] Tsvart last call review of draft-ietf-bfd-vxlan-07

Olivier Bonaventure via Datatracker <noreply@ietf.org> Fri, 31 May 2019 19:38 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: tsv-art@ietf.org
Delivered-To: tsv-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3516120189; Fri, 31 May 2019 12:38:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Olivier Bonaventure via Datatracker <noreply@ietf.org>
To: tsv-art@ietf.org
Cc: rtg-bfd@ietf.org, draft-ietf-bfd-vxlan.all@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.97.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Message-ID: <155933149484.6565.7386019489022348116@ietfa.amsl.com>
Date: Fri, 31 May 2019 12:38:14 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/v3BdAYX3osz-YHX8nXjJObZzAHg>
Subject: [Tsv-art] Tsvart last call review of draft-ietf-bfd-vxlan-07
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 May 2019 19:38:15 -0000

Reviewer: Olivier Bonaventure
Review result: Ready with Issues

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

I have only limited knowledge of VXLAN and do not know all subtleties of BFD.
This review is thus more from a generalist than a specialist in this topic.

Major issues

Section 4 requires that " Implementations SHOULD ensure that the BFD
   packets follow the same lookup path as VXLAN data packets within the
   sender system."

Why is this requirement only relevant for the lookup path on the sender system
? What does this sentence really implies ?

Is it a requirement that the BFD packets follow the same path as the data
packet for a given VXLAN ? I guess so. In this case, the document should
discuss how Equal Cost Multipath could affect this.

Minor issues

Section 1

You write "The asynchronous mode of BFD, as defined in [RFC5880],
 can be used to monitor a p2p VXLAN tunnel."

Why do you use the word can ? It is a possibility or a requirement ?

NVE has not been defined before and is not in the terminology.

This entire section is not easy to read for an outsider.

Section 3

VNI has not been defined

Figure 1 could take less space

Section 4

I do not see the benefits of having one paragraph in Section 4 followed by only
Section 4.1

Section 4.1

The document does not specify when a dedicated MAC address or the MAC address
of the destination VTEP must be used. This could affect the interoperability of
implementations. Should all implementations support both the dedicated MAC
address and the destination MAC address ?

It is unclear from this section whether IPv4 inside IPv6 and the opposite
should be supported or not.

Section 5.

If the received packet does not match the dedicated MAC address nor the MAC
address of the VTEP, should the packet be silently discarded or treated
differently ?

Section 5.1

Is this a modification to section 6.3 of RFC5880 ? This is not clear

Section 9

The sentence " Throttling MAY be relaxed for BFD packets
   based on port number." is unclear.