Re: Genart last call review of draft-ietf-bfd-vxlan-07

Greg Mirsky <> Tue, 04 June 2019 20:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 72F5812060F; Tue, 4 Jun 2019 13:40:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vnPAFzNv4eL9; Tue, 4 Jun 2019 13:40:40 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6E8D912061B; Tue, 4 Jun 2019 13:40:40 -0700 (PDT)
Received: by with SMTP id 16so7446873ljv.10; Tue, 04 Jun 2019 13:40:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OdnKdaJngQuot7pZALiG+PqQxJnthSeCa3nTqhA4Amw=; b=SN//33rSkjThjoUPmYs0sB5rcRUbhm61KQZZZuCVMp6Lxik4tOQA7F+ZJ1lHy2yZNx dkHYURiHNYUC2xLnLcBRHNCmdywuUszA/YepM+ma3VBQ8w6rrIH+Epb2QV6CTfrm0Vlr d2gO6rsjfoRrBWtPpz+INusnSWgaZfbREA5xobR8ekCCZrtceUTyN5wgZfiOCCWcUy6C BfYZLP13A9PsI9auZBwr+OQYKGgIPDFq78VQv4f8GcsLtsApVy1WXLMP/bM8pCNwUnNR 8KqYH3VJsJyF/vDDVtPq+VzOPKEG+Y6ViZZB3RU3frCarYjsJ/XZy0j48jW5syk95OwT P+AQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OdnKdaJngQuot7pZALiG+PqQxJnthSeCa3nTqhA4Amw=; b=nkdxhcB7MIuzyCF6P0z9nFmwLQxLymKRQ7XbwrN5T8n6+kcaeQl36bA0SAt7To2GLy 100KZ+0iuQu4H1mF4L/SlNC+PuNnl6EDG10wXkJ428eSzTTfjNfhwHv5UStkiJt6P0Fg msuH6IgXs3CGys4ug3yvYfJrDBcH9KnrtaYMcm74uRKCnc+aFK6xzGzqs7o+G7zmqwXR YPcq/Bca3p9PY5G5/6n1fZttZ5695jlenJa4B9tz7P6D1rmTZuRQremaEyjwak6nX+U4 fNehBvfJmFXv9uMbPGrTM243a3uOHzpz0Ojoyx9PCYci3MpB2z28KPENXs4bEU1Hzhig RvsA==
X-Gm-Message-State: APjAAAVvlnSFLJSTwSbwUyTIensvagOKDLbX/mudMSiIl4h7Mpekcble lHzA6DIlvOxHE+u24jmqHXHFO3nhxOiI56wyxH7mHLz9
X-Google-Smtp-Source: APXvYqwvu7NiBWRB5nRpl9cBh6sFPQA+9z5z5rwbjsKGIk2QXm8bexHuX9jkW0xtGyqaaY9EMG88AGpK07QM3fHvECo=
X-Received: by 2002:a2e:874b:: with SMTP id q11mr18164523ljj.48.1559680838656; Tue, 04 Jun 2019 13:40:38 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Tue, 4 Jun 2019 13:40:26 -0700
Message-ID: <>
Subject: Re: Genart last call review of draft-ietf-bfd-vxlan-07
To: Erik Kline <>
Cc:, rtg-bfd WG <>,, IETF list <>
Content-Type: multipart/alternative; boundary="00000000000059e711058a857e91"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Jun 2019 20:40:53 -0000

Hi Erik,
thank you for your review, pointed questions, and helpful suggestions.
Please find responses in-lined tagged GIM>>.


On Mon, May 27, 2019 at 1:35 PM Erik Kline via Datatracker <>

> Reviewer: Erik Kline
> Review result: On the Right Track
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> For more information, please see the FAQ at
> <>.
> Document: draft-ietf-bfd-vxlan-07
> Reviewer: Erik Kline
> Review Date: 2019-05-27
> IETF LC End Date: 2019-05-31
> IESG Telechat date: Not scheduled for a telechat
> Summary:
> If my understanding is correct (which it may well not be), this document
> places restrictions on the inner Ethernet and IP layer deployment that
> previously may not have been present.
> My reading if this document is that the outer IP header and the inner IP
> header have the same VTEP src and dst IPs.  The outer and inner Ethernet
> headers have the same source MAC and may have the same dst MAC. Is this
> correct?
GIM>> I think that you're right in regard to IP headers. Because the VXLAN
packet is routed at the Layer 3 and not switched on the Layer 2, the DA MAC
of the outer Ethernet header is the MAC of the Next Hop underlay router,
not of the VTEP.

> If so, this would mean that the VTEP's MAC address (or the special dest
> MAC)
> cannot be used within the VXLAN network (or at least not on the same host.
GIM>> The dedicated MAC is to be used only as of the DA MAC in the inner
Ethernet frame that includes a BFD control message.

> Similarly, it appears that the VTEP's IP addresses are no longer free to
> be used within the encapsulated VXLAN VNI. Do I understand this correctly?
> Was this always the case?
GIM>> I believe that this specification does not add any new restrictions
on how VTEPs IP addresses may be used.

> If there is a document defining restrictions that VTEPs place on the
> inner VXLAN segment, that might be good to reference.
> Failing that, I think I would like to see some discussion of alternatives
> that were rejected with reasons behind their rejection.
GIM>> Alternative encapsulations of BFD control message in VXLAN? I don't
recall such discussions because the presented encapsulation of a BFD
control message in VXLAN is pretty much the only possible way to do that
given that VXLAN supports only Ethernet frames as its native payload. Thus
anything must be Ethernet-encapsulated in VXLAN tunnels.

> One possible solution might be to use "impossible" Ethernet addresses and
> "impossible" IP addresses in the inner packet.  For example, a source
> IP address of all ones or all zeros would be very unlikely to ever be a
> valid IP packet.  I'm not 100% sure, but I suspect that a source MAC of
> all ones would also never really be treated as valid.  Clever use of
> multicast IP and Ethernet addresses in the source fields might also be
> sufficient to render the inner packet "invalid" in the sense that it would
> never collide with legitimate traffic.
GIM>> Not using the real source IP address in the encapsulation of a BFD
control message in VXLAN may create an attack vector and require an
additional mechanism to bootstrap a BFD session between two VTEPs.

> If I have misread this document, or VTEPs are already placing constraints
> on the inner VXLAN environment similar to those above, then this review
> should instead be treated as "Ready with Nits".
> Major issues:
> Only my concern/misunderstanding described above.
> Minor issues:
> None.
> Nits/editorial comments:
> * The document generally does a really good job of Expanding Acronyms
>   At First Use (EAAFU) -- very much appreciated. In section 1 though,
>   NVE is used without accompanying expansion, I think.
GIM>> Thank you. Updated the working version with the added expansion
as Network Virtualization Endpoint.

> * There is no 4.2 so maybe sections 4 and 4.1 could just be section 4.
GIM>> Agreed. Minor editorial changes to the first paragraph of Section 4.