Re: Genart telechat review of draft-ietf-bfd-vxlan-09

Greg Mirsky <> Tue, 17 December 2019 23:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1668A120100; Tue, 17 Dec 2019 15:17:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.596
X-Spam-Status: No, score=-0.596 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ngnugUXhOaHV; Tue, 17 Dec 2019 15:17:36 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B92E1120058; Tue, 17 Dec 2019 15:17:35 -0800 (PST)
Received: by with SMTP id k8so1506883ljh.5; Tue, 17 Dec 2019 15:17:35 -0800 (PST)
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=Eqi9KULFSJUdhCgpIf9sGiBMeHnThYSS0FbK0DUiqQo=; b=NwPusRW/TzMxDrBnoUHv//UHzpNcvf+dIWiZSvep2UrB0Lmk2zCCvTi2SZrrH1s8mC VsUQVFEHTxAUgQ7czUbjPjGFgfdEbxTSfP1MdFn0+YAQhdKu+NWXal1PkCb15axt2gd/ NfGDCWhmzlsSZXBwg7gV4dO9Nc2G4vI1aKukv1bIEE8QdfzqFboJPHNzwqi5xI3shIv3 JFbCcoofqWugxF9uVxF2KLAInVDsn/HBU+ngZOgOzdwMz2yS8RS6WHGTA3GDfEBMi7yn ToMj/gWu+D/2iUiym2tXimx61FVEGxwrtGCPHOL+P1iyzatIjZtWDvPeZmUo1kwG38K2 EOhg==
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=Eqi9KULFSJUdhCgpIf9sGiBMeHnThYSS0FbK0DUiqQo=; b=rRaAntcI0QxQUqn9HjjD4IL7R3CVeWnRfFeh1j/lwCO56gDos3NxlL6uVZGAj9ap0E n2W0OaFN3hFoEriM2Jn+5E9T0NjBbPIG0FoJZ+Y96G4g2qsdLXOT8rXrqbXkVsz9Pgq7 5tIadFXF85S5+y8kqa5HE8wSes4mI8aoD74KStyNVt8ceeoBRbrNgYAoogqj9OUGFSZu bt+bDFdUWrQa+1hmR10ZEeQ54dVpYcRl5t7QmISGrSpPmtv1tA4yHmBv3KROcgR448of my980A+LjzmSS5BZBXkRK2Hwl3F5QymrKP9tNlvHxhgmufCT1z5JcbHFD+ZweI21/su4 oGbg==
X-Gm-Message-State: APjAAAX5Q/pwbf9IxuL5U9cCfpGkyRln7oo9osOYO45svoOeJv/WKDHP 9SfKTO/I2SolGdqHopMiQKrSyWOsfINolhuvJnE=
X-Google-Smtp-Source: APXvYqyZyI0d5hMDD8JANtGFJkMotYoFRlamNgi2eKVFuKYTFUPb5L2HL7lTYZ/DSJgyZeJTSiz6kb1c1te9MX46+pY=
X-Received: by 2002:a2e:6c06:: with SMTP id h6mr214313ljc.246.1576624652876; Tue, 17 Dec 2019 15:17:32 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Tue, 17 Dec 2019 15:17:21 -0800
Message-ID: <>
Subject: Re: Genart telechat review of draft-ietf-bfd-vxlan-09
To: Erik Kline <>
Cc:,, rtg-bfd WG <>,
Content-Type: multipart/mixed; boundary="000000000000611e8d0599ee88ef"
Archived-At: <>
X-Mailman-Approved-At: Wed, 18 Dec 2019 06:31:13 -0800
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, 17 Dec 2019 23:17:39 -0000

Hi Erik,
thank you for your reviews and for sharing thoughts on the selection of the
destination IPv6 address. Following recommendations from Adam, I've updated
the document to use the proper representation of IPv6 addresses and refer
to them as "IPv4-mapped IPv4 loopback addresses". These updates are in the
attached diff. Adam also noted that RFC 8504 doesn't have a similar wording
regarding the handling of packets addressed to an address from 127/8
network as RFC 1812 (of course, referring to IPv4-mapped 127/8 addresses):
      A router SHOULD NOT forward, except over a loopback interface, any
      packet that has a destination address on network 127.  A router
      MAY have a switch that allows the network manager to disable these
      checks.  If such a switch is provided, it MUST default to
      performing the checks.
I'd note, that the egress BFD system is expected to accept a BFD packet
with the destination IP address from the specified range without being
provisioned for the specific address from that range. Perhaps that makes
the use of this range possible even though its special handling is not
explicitly documented.

Best regards,

On Mon, Dec 16, 2019 at 9:19 PM Erik Kline via Datatracker <>

> Reviewer: Erik Kline
> Review result: Ready with Nits
> 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 wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> For more information, please see the FAQ at
> <>.
> Document: draft-ietf-bfd-vxlan-??
> Reviewer: Erik Kline
> Review Date: 2019-12-16
> IETF LC End Date: None
> IESG Telechat date: 2019-12-19
> Summary:
> -09 addresses my concerns from -07.  Thank you for this.
> The one "nit" is that it seems to have introduced a recommendation to use
> ::ffff:7f00:0/104 as an IPv6 loopback prefix.  (a) This document should
> follow
> the format recommendations of RFC 5952 section 4.3 and lowercase the
> "F"s.  But
> (b) more importantly, I'm not sure how implementations may treats this
> space.
> The use of an RFC4291 section- mapped v4 address doesn't necessarily
> make the packet a part of an IPv6 connection.  Nevertheless, I'm not sure I
> have a strong feeling about this as it may still exercise enough of the
> IPv6
> stack in a VTEP.
> I definitely do think that in the case of BFD on the management VNI
> targeting
> an IPv6 link-local address of the VTEP would be better.  However, I expect
> that
> if ::ffff: does prove to have some issues in the future a -bis
> can be
> written quickly with a recommendation.
> Also, Suresh may have ideas for a solution.
> Major issues:
> Minor issues:
> Nits/editorial comments: