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

Juliusz Chroboczek <> Tue, 17 December 2019 19:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49E1E120C9F; Tue, 17 Dec 2019 11:04:52 -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 mDJ6pRPbr0ks; Tue, 17 Dec 2019 11:04:49 -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 93CFB1208C8; Tue, 17 Dec 2019 11:04:05 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4/relay1/82085) with ESMTP id xBHJ40I0001286; Tue, 17 Dec 2019 20:04:00 +0100
Received: from (localhost []) by (Postfix) with ESMTP id 686B1A90AA; Tue, 17 Dec 2019 20:04:03 +0100 (CET)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by ( []) (amavisd-new, port 10023) with ESMTP id 9iw4YMXPKvrS; Tue, 17 Dec 2019 20:04:01 +0100 (CET)
Received: from (unknown []) (Authenticated sender: jch) by (Postfix) with ESMTPSA id DAF5BA90A6; Tue, 17 Dec 2019 20:04:00 +0100 (CET)
Date: Tue, 17 Dec 2019 20:04:00 +0100
Message-ID: <>
From: Juliusz Chroboczek <>
To: Mirja Kuehlewind <>
Cc: David Schinazi <>,, babel-chairs <>, Babel at IETF <>, Alvaro Retana <>, The IESG <>, Donald Eastlake <>, Martin Vigoureux <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 ( []); Tue, 17 Dec 2019 20:04:00 +0100 (CET)
X-Miltered: at korolev with ID 5DF926A0.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5DF926A0.001 from<>
X-j-chkmail-Score: MSGID : 5DF926A0.001 on : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: <>
Subject: Re: [babel] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ie?= =?iso-8859-1?q?tf-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: Tue, 17 Dec 2019 19:04:52 -0000

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


> Does it actually makes sense to use the same parameters in a "small
> unmanaged network" as well as in a "large overlay network"?


> 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