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

Juliusz Chroboczek <> Wed, 21 April 2021 15:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E7953A2C9C; Wed, 21 Apr 2021 08:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YrPyKcuPhXmC; Wed, 21 Apr 2021 08:42:32 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id 37F1F3A2C1A; Wed, 21 Apr 2021 08:42:31 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/relay1/82085) with ESMTP id 13LFgKeG020531; Wed, 21 Apr 2021 17:42:20 +0200
Received: from (localhost []) by (Postfix) with ESMTP id 55F65F0173; Wed, 21 Apr 2021 17:42:20 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by ( []) (amavisd-new, port 10023) with ESMTP id emfzj8UH1emA; Wed, 21 Apr 2021 17:42:18 +0200 (CEST)
Received: from (unknown []) (Authenticated sender: jch) by (Postfix) with ESMTPSA id 2EA18F016A; Wed, 21 Apr 2021 17:42:18 +0200 (CEST)
Date: Wed, 21 Apr 2021 17:42:17 +0200
Message-ID: <>
From: Juliusz Chroboczek <>
To: Éric Vyncke <>
Cc: The IESG <>,,,, Donald Eastlake <>
In-Reply-To: <>
References: <>
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 ( []); Wed, 21 Apr 2021 17:42:20 +0200 (CEST)
X-Miltered: at korolev with ID 608047DC.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 608047DC.000 from<>
X-j-chkmail-Score: MSGID : 608047DC.000 on : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: <>
Subject: Re: [babel] Éric Vyncke's No Objection on draft-ietf-babel-source-specific-07: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Apr 2021 15:42:38 -0000

Dear Éric,

Thanks for your 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.

As mentioned earlier, it was cited in previous versions, but the
responsible AD requested that we not depend on an expired draft.  I have
therefore rewritten the introduction and the security considerations to
make the document more self-contained.

I have no objection to reinstating the citation should the responsible AD
change his mind.

> Same for reference to RFC 8678.

I am ashamed to say that I have not read this document.  I have just put
it on my to-do list.  Please let me know if you feel strongly that it
should be cited, and I'll move it higher in my queue.

> -- 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)."

Yes, the notations were inconsistent between this document and RFC 8966.
This has hopefully been fixed now.

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

Discussion has been added in Section 1.3.  Please let me know if you still
feel something is missing.

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

This extension interoperates with RFC 8966.  It does not interoperate with
RFC 6126. To quote RFC 8966 Appendix F:

   RFC 7557 did not define mandatory sub-TLVs
   (Section 4.4), and thus an implementation of RFCs 6126 and 7557 will
   not correctly ignore a TLV that carries an unknown mandatory sub-TLV;
   depending on the sub-TLV, this might cause routing pathologies.

   An implementation of this specification that never sends Unicast or
   unscheduled Hellos and doesn't implement any extensions that use
   mandatory sub-TLVs is safe to deploy in a network in which some nodes
   implement the protocol described in RFCs 6126 and 7557.

This extension uses mandatory sub-TLVs, and is not safe to deploy together
with implementations of RFC 6126.

The issue was debated at length by the Babel WG, and we came to the
conclusion that it was a risk we were willing to take.  There exist four
independent implementations of Babel, of which two are actually used in
production.  These two implementations have been updated to follow 8966 in
early 2018, and we have done a fair amount of work to hunt down any Babel
networks and make sure they patched their implementations of Babel.  Thus,
we believe that it is now safe to deploy extensions that break RFC 6126.

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

I've tried to clarify this paragraph.  Let me know if you feel I haven't
done enough.

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

That's also not done in RFC 8966.  Let me know if you feel strongly about it.

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



-- Juliusz