Re: [babel] Martin Duke's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS)

Juliusz Chroboczek <> Thu, 05 November 2020 16:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C83C3A17F1; Thu, 5 Nov 2020 08:26:10 -0800 (PST)
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 eIiXLQFIr56g; Thu, 5 Nov 2020 08:26:03 -0800 (PST)
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 6AAC33A1349; Thu, 5 Nov 2020 08:26:01 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4/relay1/82085) with ESMTP id 0A5GPxDe030582; Thu, 5 Nov 2020 17:25:59 +0100
Received: from (localhost []) by (Postfix) with ESMTP id 630BBC2D78; Thu, 5 Nov 2020 17:25:59 +0100 (CET)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by ( []) (amavisd-new, port 10023) with ESMTP id ESF77J-IvVey; Thu, 5 Nov 2020 17:25:57 +0100 (CET)
Received: from ( []) (Authenticated sender: jch) by (Postfix) with ESMTPSA id 32B3CC2D70; Thu, 5 Nov 2020 17:25:57 +0100 (CET)
Date: Thu, 05 Nov 2020 17:25:53 +0100
Message-ID: <>
From: Juliusz Chroboczek <>
To: Martin Duke <>
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 ( []); Thu, 05 Nov 2020 17:25:59 +0100 (CET)
X-Miltered: at korolev with ID 5FA42797.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5FA42797.000 from<>
X-j-chkmail-Score: MSGID : 5FA42797.000 on : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: <>
Subject: Re: [babel] Martin Duke's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS)
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: Thu, 05 Nov 2020 16:26:10 -0000

I've done some minor reordering to your comments.  Hopefully this doesn't
change their meaning.

> I am concerned about the congestion implications of this architecture. If there
> are P prefixes in the network, the number of TLVs exchanged potentially goes
> from P to P^2.

Source-specific routes don't arise ex nihilo: they are injected into the
routing domain through redistribution, just like ordinary, destination-only
routes.  There is no way for Babel to exchange P² prefixes unless the
network administrator has explicitly selected P² prefixes for redistribution.

> But are there any safeguards in the protocol against this happening

There are no safeguards in the protocol against a network administrator
redistributing unreasonable numbers of source-specific routes into a Babel
domain, just like there are no safeguards in the protocol against
redistributing the full BGP routing table.

> Or ought there to be some operational guidance to be somewhat selective
> about source prefixes?

Source-specific routing is a mechanism, which, as you rightly note, has
a worst-case quadratic cost.  We currently know of three applications for
source-specific routing, outlined in [SS-ROUTING] Sections II.B and II.C,
and none of the three known applications lead to the worst-case quadratic
explosion that you fear.  Interestingly, two of these applications have
the potential to reduce the amount of routing data propagated globally in
the Internet, at a moderate cost in the amount of data propagated locally.
This seems to me like an excellent tradeoff.

As source-specific routing becomes widely available and well-known, people
will hopefully find new and exciting applications for this mechanism.
Each of these new applications will need to be studied carefully, and its
complexity understood.  It is not the role of the mechanism, however, to
prohibit future applications just because they might turn out to be too costly.

-- Juliusz