Re: [babel] Mirja Kühlewind's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT)

Mirja Kuehlewind <> Wed, 08 January 2020 09:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A1CD1200D5; Wed, 8 Jan 2020 01:54:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KwFUIsV9Npgv; Wed, 8 Jan 2020 01:54:47 -0800 (PST)
Received: from ( [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3995D12006D; Wed, 8 Jan 2020 01:54:47 -0800 (PST)
Received: from ([2001:16b8:2ce1:a400:5104:9816:3492:ee5]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ip82x-0000Er-Ho; Wed, 08 Jan 2020 10:54:39 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <>
In-Reply-To: <>
Date: Wed, 8 Jan 2020 10:54:38 +0100
Cc: "" <>, Babel at IETF <>, Alvaro Retana <>, The IESG <>, Martin Vigoureux <>, "STARK, BARBARA H" <>, Teco Boot <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Juliusz Chroboczek <>
X-Mailer: Apple Mail (2.3445.104.11)
X-HE-SMSGID: 1ip82x-0000Er-Ho
Archived-At: <>
Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?=
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, 08 Jan 2020 09:54:49 -0000

Hi Juliusz,

Just recommending default value doesn’t mean that anybody has to use the same values and it still conserves the benefits that babel works with a brought set of values. However, you already said that all deployed implementation use the same set of values, so what’s the point of not recommending these?

You made several times the point that babel is based on implementation and testing. Given all deployed implementations use the same values that actually is the only set that is really tested and therefore the only one that should be recommended.

You said:
"Interoperability is about different implementations interoperating without
endangering the integrity of the network.”

The smaller the time interval are that you use, the higher is the load on the network. That means certain configuration would endanger the integrity of the network if the network capacity is below the load that is generated by the updates and hello. 

This is not discussed in appendix B. Appendix B only talks about e.g. "networks with little mobility, and where occasional outages of up to 14 seconds are acceptable” but it doesn’t say anything about load. The effect of the chosen configuration on the network load/integrity needs further discussion and it needs this discussion in the body of the spec and not only in the appendix with relation to the concrete parameter values or a certain range of values.


> On 8. Jan 2020, at 07:52, Teco Boot <> wrote:
>> Op 8 jan. 2020, om 01:26 heeft Juliusz Chroboczek <> het volgende geschreven:
>> Hi Teco,
>>> This is in line with for example the OSPF RFCs.
>>> But for unmanaged networks, good advice from an authority is almost mandatory.
>> The advice is already there, it's in Appendix B, and it's referenced at
>> all the relevant points in the document.  However, Babel is designed so
>> that the exact values don't matter, so it's merely advice, not a recommendation.
>> That the exact values don't matter is the whole point of Babel -- it's
>> designed to interoperate in the presence of asymmetric configuration,
>> which is why it's useful in community and unmanaged networks.  If we start
>> recommending a default set of values, we obfuscate this fact, at which
>> point we're no longer communicating clearly why Babel might, in some
>> deployments, be a good alternative to OSPF.
>> I've repeatedly explained this back in August, but apparently wasn't clear
>> enough.
> I know and I agree.
> So please try to finish this work.
>>> For Homenets, this could be draft-ietf-homenet-babel-profile.
>> Homenet-babel-profile goes further than that -- it defines the set of
>> extensions required in order to implement Homenet routing (MUST IPv6,
>> SHOULD IPv4, MUST source-specific routing), and it defines the
>> interactions between HNCP and Babel.
> There is nothing on timers. OK, the rfc6126bis suggested timers make sense. 
> But how can a homenet device vendor know to select one of the use cases? 
> I also think the guidance for link costs for homenets has too much freedom.
> IMHO, for Homenets, all of this needs strict rules.
> But this is out of topic here.
> I only wanted to suggest that there are other and better places to define the protocol 
> parameters. This could help to close this discussion.
> Teco
>> -- Juliusz