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

Éric Vyncke via Datatracker <noreply@ietf.org> Thu, 05 November 2020 09:33 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 8BD4A3A172C; Thu, 5 Nov 2020 01:33:21 -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
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: <160456880126.24423.3828288743954574173@ietfa.amsl.com>
Date: Thu, 05 Nov 2020 01:33:21 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/IilDQZlx9TTn0GnCkSjlJO0UH30>
Subject: [babel] Éric Vyncke's No Objection on draft-ietf-babel-source-specific-07: (with 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 09:33:21 -0000

Éric Vyncke has entered the following ballot position for
draft-ietf-babel-source-specific-07: 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-babel-source-specific/



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

[Dear all, please accept my apologies for the wrong DISCUSS point... a copy and
paste error done without enough coffee... There are NO DISCUSS point in my
ballot]

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

== 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"
with reference to the Bable RFC:
   "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).