Re: [bess] Éric Vyncke's Abstain on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)

Greg Mirsky <gregimirsky@gmail.com> Mon, 21 December 2020 00:55 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455623A0940; Sun, 20 Dec 2020 16:55:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.855
X-Spam-Level:
X-Spam-Status: No, score=-0.855 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 lch65Ckc2clz; Sun, 20 Dec 2020 16:55:51 -0800 (PST)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 07D3A3A0936; Sun, 20 Dec 2020 16:55:50 -0800 (PST)
Received: by mail-lf1-x12b.google.com with SMTP id o19so19760753lfo.1; Sun, 20 Dec 2020 16:55:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3p/9pcvcDJKUVmNaeA/laVGQgSsVwiy2yBYzpPPrrRA=; b=EEtU/6RoCmMhYy8tLv9TcW3s/FnbL02lMdKlBGz9oooljDloTmn2uLYdnVg5mFC4Ze 4XSw9gjQaGaL9YcJnfQxEonFxC8ByYXAgI8xXgINnc4X7tcph/UfUhvZ5pxy+yOdUEUD tmPujSGIKg7XgQhV07uSst/mlgoBKpyCqCGCxzaN/ozekr5JMlVS1Op4qEv7kuo8NL5D R8DqMJGOHMQltPm0g9u3wHJWoXo00eue4iaPnHVwiBAT9H0lN4nsdDVX1zLCnsSALNoX GiEe9TWX6IWfBCuzK0DSYmq6ysWbFo4BzR86jh7gTwckxpj2IXh/P7hwxwWj5dP+qcaW kdzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3p/9pcvcDJKUVmNaeA/laVGQgSsVwiy2yBYzpPPrrRA=; b=EdfXNCtkMKBT1kPKDPiRF2NIwrnvU8Xeap2ciRu1zHrdjkMC3acStgLgTYH3f/fEu5 p2tr7cXXeCcBA7OEOPwAXP5//+L51HhyJqtf8IarNApKmvy4WqeoRGuXmQO4UEhFF+aW vomc+xREHBiuL0f0GX/+EcWcb9AO9sCcBHDkMtAMAwHiPTDThimsIxGeGAYwPGXrNd8R PreDrfawcXmxIKOIm5pRJuQsfXtmgXjw+NlEgMpUeiz/PRT9SAYxPlGJwY3/9UvRCZXK ej8OuBjkW0157kwrd9ft+mZTW6dgKyfVPgFu5bAAvSzB+aDu2BA/ERHYhrrMWgRW6EoR reqA==
X-Gm-Message-State: AOAM530PeJaG5jyQ+vaQNCTIPx2PVIA0VwBE1bm63/T1UiXwV7bEbkdJ M5zeEmAQ2FR0fK6O5BkkQhMEvsesp8fz2UiMmL8=
X-Google-Smtp-Source: ABdhPJxE1hg1FHXNei+MySNU/zvJXYKRdLHBKN5apnLt2T4UgfdVgiXNcESTngG9lGcY21v/nV3Ox1jgBGWPabMODHw=
X-Received: by 2002:a2e:b6d0:: with SMTP id m16mr6149729ljo.133.1608512148703; Sun, 20 Dec 2020 16:55:48 -0800 (PST)
MIME-Version: 1.0
References: <160811313040.11139.1045340773390281334@ietfa.amsl.com>
In-Reply-To: <160811313040.11139.1045340773390281334@ietfa.amsl.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sun, 20 Dec 2020 16:55:36 -0800
Message-ID: <CA+RyBmX=PYcM4hbf7CrBCG3j3xKOnNNXpy3oaLo+wVdruHUBfw@mail.gmail.com>
To: Éric Vyncke <evyncke@cisco.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-bess-mvpn-fast-failover@ietf.org, bess-chairs@ietf.org, BESS <bess@ietf.org>, Stephane Litkowski <slitkows.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000003d8f2f05b6eeeb83"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/gFeFTJ6r-yiLz4G7gqCQ-7t8yM0>
Subject: Re: [bess] Éric Vyncke's Abstain on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Dec 2020 00:55:53 -0000

Hi Eric,
apologies for the belated response. Please find my answers below in-lined
tagged by GIM>>.

Regards,
Greg

On Wed, Dec 16, 2020 at 2:05 AM Éric Vyncke via Datatracker <
noreply@ietf.org> wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-bess-mvpn-fast-failover-13: Abstain
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for the work put into this document.
>
> I have balloted 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."
> because
> of the use outside of a node of the IPv4-mapped IPv6 addresses in section
> 3.1.6.1. A reply on this topic will be welcome.
>
> Stéphane in his doc shepherd's write up states that no implementation is
> known
> for a document born in 2008... Does the IETF really want to have this on
> the
> proposed standards track ?
>
> Please find below my ABSTAIN point, some non-blocking COMMENT points (but
> replies would be appreciated), and one nits.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> == ABSTAIN ==
> -- Section 3.1.6.1 --
> I appreciate that the BFD WG relies on "::ffff:127.0.0.0/104" but those
> IPv4-mapped IPv6 addresses are assumed to never leave a node and should
> never
> be transmitted over the Internet (see
> https://tools.ietf.org/html/rfc5156#section-2.2). This is the cause of my
> ABSTAIN. As the inner packet is sent over a tunnel, why not using the a
> link-local address or the ff02::1 link-local multicast group ?
>
GIM>> This text has been updated. Please let me know if the new text is
acceptable:
NEW TEXT:
   o  when transmitting BFD Control packets MUST set the IP destination
      address of the inner IP header to the internal loopback address
      127.0.0.1/32 for IPv4 [RFC1122].  For IPv6, it MUST use the
      loopback address ::1/128 [RFC4291].

>
> == COMMENTS ==
>
> -- Section 2.3 --
> The use of "upstream" and "Upstream" could be confusing... The latter could
> have been "Upstream PE/ABSR" (often used later in the document) or "ingress
> node"
>
GIM>> We've tried to clarify the difference in the Terminology section. As
I can see from grepping the document, it consistently uses "Upstream PE"
(Upstream ASBR is used once).

>
> -- Section 3.1.6 --
> Could the "BFD Discreminator" attribute be used for other purpose than this
> document? If so, then why not specifying it in *another* document?
>
> Should this document clearly state that it does not define any TLV ?
>
GIM>> Added a note in Section 7.3 BFD Discriminator Optional TLV Type:
NEW TEXT:
No optional TLV types defined at the creation of the registry.

>
> == NITS ==
>
> As I am probably not the only reader have difficulties to remember RFC
> contents
> by their number, may I suggest to prefix the RFC numbers with their titles
> ?
> Esp in the introduction ;-)
>
GIM>> I understand the challenge that manner of using references might
present. In the Abstract RFC 8562 is referenced by both number and its full
title. I'm concerned that doing that in the body of a document might
inflate the size. I use HTMLized version that conveniently links the
reference and the referenced document.