Re: Éric Vyncke's Abstain on draft-ietf-bfd-vxlan-13: (with COMMENT)

Jeffrey Haas <jhaas@pfrc.org> Wed, 22 July 2020 16:19 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 DD21A3A0A80; Wed, 22 Jul 2020 09:19:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 8sxyaY0GpsDE; Wed, 22 Jul 2020 09:19:54 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 63CC93A0A6A; Wed, 22 Jul 2020 09:19:54 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 370411E2F9; Wed, 22 Jul 2020 12:30:43 -0400 (EDT)
Date: Wed, 22 Jul 2020 12:30:43 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Éric Vyncke <evyncke@cisco.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-bfd-vxlan@ietf.org, bfd-chairs@ietf.org, rtg-bfd@ietf.org
Subject: Re: Éric Vyncke's Abstain on draft-ietf-bfd-vxlan-13: (with COMMENT)
Message-ID: <20200722163042.GB6821@pfrc.org>
References: <159542089363.28188.3286555767171732447@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <159542089363.28188.3286555767171732447@ietfa.amsl.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/irNqhhr1KUokHV3TvZpT5bcZMBI>
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: Wed, 22 Jul 2020 16:19:56 -0000

Éric,

On Wed, Jul 22, 2020 at 05:28:14AM -0700, Éric Vyncke via Datatracker wrote:
> Éric Vyncke has entered the following ballot position for
> draft-ietf-bfd-vxlan-13: Abstain
> 
[...]

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for the work put into this document and its update. I have cleared
> one of my DISCUSS point about TTL = Hop Limit not being 255.
> 
> But, the authors and I are in an impasse about the use of IPv4-mapped IPv6
> addresses but I do not want to block the document. I change my ballot to
> "ABSTAIN" in the sense of "I oppose this document but understand that others
> differ and am not going to stand in the way of the others".

Thank you. This will let us continue toward broader IETF review.

> BTW, I understood that the use a prefix rather than /32 or /128 was to allow
> for entropy (to explore multiple ECMP/LAG paths).

This is one possible case, but primarily it is to let the receiving
application have something they can internally "catch" in their packet
intercept code.  Many router vendors implement unusual things in the
loopback network range.

>  BTW2, the right wording is
> "IPv4-mapped IPv6 address" and not "IPv4-mapped IPv4 address" as written twice
> in the document.

As noted in a separate thread, we'll address that correction.

> Did you (or actually the authors) also investigate the use of the:

This is my personal comment; the authors are requested to comment as well.

> - ::/0 : unspecified address

This often interacts oddly with socket libraries and likely would not be as
portable as one might want.

> - 100::/8 the discard prefix used for RTBH RFC 6666
> - or even requesting a block out of the 2001::/23 (reserved for IETF special
> use)

As you comment in your private reply, the desire is that we never see the
prefix in question in routing.  The loopback network property encodes that
semantic quite nicely - it's completely local to the box in question.

---

I believe that when this thread concludes, we will have closed on last of
the open issues.  Once Greg has done the necessary updates to pull in the
last few issues, I'll update the shepherd report and resubmit to the IESG.

Thanks for your efforts.

-- Jeff