Re: [babel] Benjamin Kaduk's No Objection on draft-ietf-babel-source-specific-07: (with COMMENT)

Juliusz Chroboczek <jch@irif.fr> Wed, 21 April 2021 14:30 UTC

Return-Path: <jch@irif.fr>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 164A03A29F2; Wed, 21 Apr 2021 07:30:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 s5aawmWbTUSQ; Wed, 21 Apr 2021 07:29:55 -0700 (PDT)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2833A29F9; Wed, 21 Apr 2021 07:29:51 -0700 (PDT)
Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 13LETm3x022676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Apr 2021 16:29:48 +0200
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 13LETlwm002280; Wed, 21 Apr 2021 16:29:47 +0200
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id BDC8FEF148; Wed, 21 Apr 2021 16:29:47 +0200 (CEST)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id GWNNMucnUSg9; Wed, 21 Apr 2021 16:29:45 +0200 (CEST)
Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id A2520EF144; Wed, 21 Apr 2021 16:29:45 +0200 (CEST)
Date: Wed, 21 Apr 2021 16:29:45 +0200
Message-ID: <875z0faexy.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: "The IESG" <iesg@ietf.org>, draft-ietf-babel-source-specific@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake <d3e3e3@gmail.com>
In-Reply-To: <160410817933.20181.137158173131306726@ietfa.amsl.com>
References: <160410817933.20181.137158173131306726@ietfa.amsl.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 21 Apr 2021 16:29:48 +0200 (CEST)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 21 Apr 2021 16:29:48 +0200 (CEST)
X-Miltered: at korolev with ID 608036DC.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-Miltered: at potemkin with ID 608036DB.005 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 608036DC.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/<jch@irif.fr>
X-j-chkmail-Enveloppe: 608036DB.005 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@irif.fr>
X-j-chkmail-Score: MSGID : 608036DC.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Score: MSGID : 608036DB.005 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
X-j-chkmail-Status: Ham
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/F5VAwyWx6bZCFTTIfP2skHT6WlA>
Subject: Re: [babel] Benjamin Kaduk's No Objection on draft-ietf-babel-source-specific-07: (with COMMENT)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Wed, 21 Apr 2021 14:30:00 -0000

Thanks for your comments.

> Section 3.1

>    Note that the route entry contains a source (see sections 2 and 3.2.5
>    of [BABEL]) which itself contains a source prefix.  These are two
>    very different concepts that should not be confused.

> I appreciate having this note; thanks.  I wonder if it is worth
> reiterating that the stock [BABEL] "source prefix" is the prefix of the
> source of the routing information, to jog the reader's memory.

Clarified in a slightly different way from what you suggest.

> Section 5.1

>    Prefix sub-TLV.  When a node receives a source-specific Update
>    (prefix, source prefix, router-id, seqno, metric) from a neighbour
>    neigh, it behaves as described in [BABEL] Section 3.5.4, except that

> It looks like some section renumbering has occurred, as §3.5.3 of
> draft-ietf-babel-rfc6126bis-20 looks much more relevant than §3.5.4
> does.

Done (two counts).

>    the entry under consideration is indexed by (prefix, source prefix,
>    neigh) rather than just (prefix, neigh).

> [The two prefix lengths are implicit now, though were explicit in
> [BABEL]?]

Fixed, thanks.

> Section 5.2

> We should probably expand "AE" on first use.

Done.

> Section 6.2

>    A simple yet sufficient condition for avoiding starvation is to build
>    a connected source-specific backbone that includes all of the edge
>    routers, [...]

> I'm not sure I understand what "connected backbone that includes all of
> the edge routers" is intended to mean.

Hopefully clearer now.  It's now Section 6.1.

> Section 7.1

> If I recall correctly, Babel sub-TLVs do not admit sub-sub-TLVs, so we
> would treat a sub-TLV "length" that indicates more bytes of payload than
> indicated by the "source plen" as an encoding error and reject the
> sub-TLV, right?

Added wording to that effect.

>    Source Plen  The length of the advertised source prefix.  This MUST
>              NOT be 0.

> Please use "length in bits" to match 6126bis.

Done.

> Section 7.3

> Should we consider being consistent about the use of parentheses around
> "route" in the section heading and section body?

Fixed.

> Section 7.4

> Just to check my understanding: we do not expect issues where (e.g.) a
> source-specific seqno request is sent to a non-source-specific node and
> thus dropped, because seqno requests are supposed to be sent only to
> nodes that are or in the past were advertising a (possibly non-feasible) route
> for that prefix.  Such a source-specific advertisement would only be sent
> by a source-specific node, that would accordingly not drop the seqno request.

That's one case (forwarding a request).  The other case is when a router
originates a request, in which case it will send the request over
multicast, and so non-source-specific requests will be received by
non-specific routers, and silently ignored due to the mandatory sub-TLV.

> Section 9

> I was surprised to see in a quick check of 6126bis that there did not
> seem to be a prominent mention in the security considerations of "make
> sure your parser handles TLVs that indicate a length larger than the
> size of the packet".  Should there be one?

Perhaps.  That ship has sailed, though.

> Section 11.1

> We cite BCP84 as part of the line "which is compatible with [BCP84]".
> That in and of itself does not necessarily seem like enough to justify a
> normative relationship, though perhaps there are other reasons why it is
> needed.

This section has been completely rewritten, it is now Section 1.1.  I hope
it is clearer now.

Thanks again,

-- Juliusz