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

Mirja Kuehlewind <> Mon, 06 January 2020 14:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66BD4120818; Mon, 6 Jan 2020 06:09:23 -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 QuyVBLvbYHei; Mon, 6 Jan 2020 06:09:21 -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 74480120815; Mon, 6 Jan 2020 06:09:21 -0800 (PST)
Received: from ([2001:16b8:2435:5000:4499:ccf7:8e58:80e6]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ioT4I-00068q-Tv; Mon, 06 Jan 2020 15:09:18 +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: Mon, 6 Jan 2020 15:09:18 +0100
Cc: David Schinazi <>,, babel-chairs <>, Babel at IETF <>, Alvaro Retana <>, The IESG <>, Donald Eastlake <>, Martin Vigoureux <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Juliusz Chroboczek <>
X-Mailer: Apple Mail (2.3445.104.11)
X-HE-SMSGID: 1ioT4I-00068q-Tv
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: Mon, 06 Jan 2020 14:09:23 -0000

Hi Juliusz,

I didn’t talk about pacing in that mail but only about defining default values for the interval parameters you already have defined in the draft.

If all deployed scenarios use the first set of values and these value are well applicable for all different scenarios that are defined in the use case doc, such as “small unmanaged network" as well as in a "large overlay network”, why don’t you just specify these values as normatively default value in the spec?


> On 17. Dec 2019, at 20:04, Juliusz Chroboczek <> wrote:
>>> If that is the case, then I request that you state explicitly why you
>>> think that Babel must be held to a much higher standard than OSPFv3.  If
>>> that is not the case, then please clear your discuss.
>> In OSPFv3 as far as I can see (and I am really not an expert here) all
>> values that define intervals are in seconds which leads to a minimum
>> value of 1 seconds. This is not the case for babel and therefore we need
>> to be more carful here.
> After a change of topology, OSPF executes the procedure described in
> Section 4.5.2 of RFC 5340 (Section 13.3 of RFC 2328).  At this point,
> a potentially unbounded number of LSAs are flooded out every active
> interface (point 5 in Section 13.3 of RFC 2328).  This flooding is not
> regulated by any timer -- all that the protocol says is that the LSAs must
> go out through a certain subset of the router's interfaces.
> I could be wrong, but I am fairly confident that nothing in RFCs 5340 and
> 2328 specifies congestion control, flow control or packet pacing for this
> flooding procedure.  My interpretation is that since OSPF is designed to
> be deployed on local links, congestion caused by OSPF is not likely to
> endanger the Global Internet, and therefore packet pacing (if required) is
> left to the implementation.
> I also don't recall any discussion of flow control in Moy's and Gredler's
> books, but they have a lot of pages (especially Gredler's), so, again,
> I could be wrong.
> Where you are right, Mirja, is that packet pacing is a very difficult
> problem in OSPF, where incorrectly delaying flooding could lead to
> microloops; since Babel has a loop-avoidance mechanism built-in, it can
> safely perform packet pacing should the need to do so be demonstrated in
> a particular topology.
> In summary, while I agree that packet pacing for Babel would be an
> interesting research project, I maintain that by requiring packet pacing
> as a condition for publication as PS, you are requiring an unreasonably
> high standard, certainly a standard that neither OSPF nor IS-IS are held to.
>>> Appendix B gives values that are suggested for implementations.
>> Yes but it doesn’t discuss for with _deployment_ scenarios these values
>> are suitable.
> As far as I am aware, all current production deployments use the first set
> of constants.  The one exception is an experimental testbed used for
> mobility research, that uses the (more aggressive) second set of constants.
>> Did you deploy the same parameters in all of the discussed scenarios.
> Yes.
>> Does it actually makes sense to use the same parameters in a "small
>> unmanaged network" as well as in a "large overlay network"?
> Yes.
>> Is that network connected to the Internet or not?
> Yes, but that's irrelevant -- the Babel traffic is link-local, and does
> not go outside the local routing domain.
> -- Juliusz