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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Mon, 21 Dec 2020 03:19:22 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-bess-mvpn-fast-failover-13: No Objection

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 and for addressing my previous
comments. My previous position is kept below ***ONLY FOR ARCHIVE*** as the
authors have proposed text to fix those issues.

-éric

===FOR ARCHIVE ONLY===

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 ?

== 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"

-- 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 ?

== 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 ;-)