[babel] Éric Vyncke's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS and COMMENT)

Éric Vyncke via Datatracker <noreply@ietf.org> Thu, 05 November 2020 07:49 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: babel@ietf.org
Delivered-To: babel@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 068543A0A16; Wed, 4 Nov 2020 23:49:00 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-babel-source-specific@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake <d3e3e3@gmail.com>, d3e3e3@gmail.com, david@opensourcerouting.org, as@cisco.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <160456253967.7318.72519100069215705@ietfa.amsl.com>
Date: Wed, 04 Nov 2020 23:49:00 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/QO6zJYp7FqL-vAnP_wNGlEoRTkM>
Subject: [babel] Éric Vyncke's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS and COMMENT)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Nov 2020 07:49:00 -0000

Éric Vyncke has entered the following ballot position for
draft-ietf-babel-source-specific-07: Discuss

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-babel-source-specific/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work put into this document. The document is easy to read
albeit not always clear and specific (see later). The topic of source address
dependent routing is really critical for IPv6 deployment, so, I really
appreciate your work on the topic

Please find below one blocking DISCUSS point (trivial to fix), some
non-blocking COMMENT points, and some nits.

I also second Warren's DISCUSS on the lack of clarity in the section 4 example

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

Please update IPv6 reference from RFC 2460 to RFC 8200: I told you that this
was an easy to fix DISCUSS point


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

== COMMENTS ==

Generic comment: did the author read draft-ietf-rtgwg-dst-src-routing ? It is
an expired RTG WG adopted document and is not even cited as informative
reference.

Same for reference to RFC 8678.

-- Section 3.1 --
Is the first "prefix" the "destination prefix" in the following text? If so,
then I suggest to write "destination prefix" or explain what is this "prefix":
   "The source table is now indexed by triples of the form (prefix,
   source prefix, router-id)."

-- Section 4 --
May I suggest to add another example with 2 entries have the same destination
prefix but different source prefixes ?

-- Section 6 --
May be my lack of knowledge in Babel is the reason why I do not understand the
loop avoidance description... As written in the text, a single non-source-aware
router in the network could be enough to introduce loop (in specific
configurations). Writing the following text appear to me as a little hand
waving because how can this be ensure (I was about to file a block DISCUSS on
this but I am trusting the routing AD on this topic): "  Consequently, this
extension MUST NOT be used
   with routers implementing RFC 6126, otherwise persistent routing
   loops may occur."

-- Section 6.2 --
The last paragraph is also a little hand waving where it is assumed that
network topology/configuration is specific to avoid a route starvation.

-- Section 7.1 --
Should the text state the obvious by stating that the prefix (non 8 multiple)
is padded with bits set to 0 on transmission and those bits are ignored on
reception ?

== NITS ==

-- Section 4 and possibly others --
Please use RFC 5952 to write IPv6 addresses.

-- Section 5.2 --
Please introduce the "AE" acronym at first use (even if guessable in the
context).