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

Mirja Kuehlewind <ietf@kuehlewind.net> Tue, 17 December 2019 17:13 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D4C120B2E; Tue, 17 Dec 2019 09:13:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvYa2IqIljRk; Tue, 17 Dec 2019 09:13:48 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [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 ietfa.amsl.com (Postfix) with ESMTPS id 9537F120220; Tue, 17 Dec 2019 09:13:48 -0800 (PST)
Received: from host109-105-dynamic.8-87-r.retail.telecomitalia.it ([87.8.105.109] helo=[192.168.1.11]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ihGPp-0001a9-Es; Tue, 17 Dec 2019 18:13:45 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <87lfra9a2s.wl-jch@irif.fr>
Date: Tue, 17 Dec 2019 18:13:43 +0100
Cc: David Schinazi <dschinazi.ietf@gmail.com>, draft-ietf-babel-rfc6126bis@ietf.org, babel-chairs <babel-chairs@ietf.org>, Babel at IETF <babel@ietf.org>, Alvaro Retana <aretana.ietf@gmail.com>, The IESG <iesg@ietf.org>, Donald Eastlake <d3e3e3@gmail.com>, Martin Vigoureux <martin.vigoureux@nokia.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <35766A70-6E3D-4216-B559-811F6B3FB46F@kuehlewind.net>
References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> <B3A7583A-B4DE-4CE5-A74D-0D4C22FABD83@kuehlewind.net> <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net> <CAPDSy+6c_WxJ+KoT5uJZG=xCMomDgOukLXHdseQ10yL_+MGyiA@mail.gmail.com> <89C41AAF-B019-4872-9AED-278D6FE7EE0E@kuehlewind.net> <87lfra9a2s.wl-jch@irif.fr>
To: Juliusz Chroboczek <jch@irif.fr>
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1576602828;9b4770b8;
X-HE-SMSGID: 1ihGPp-0001a9-Es
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/8_voBejeErQ1vldUtCv3lsArrp8>
Subject: Re: [babel] Mirja Kühlewind's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Dec 2019 17:13:51 -0000

Hi Juliusz,

Please see below.

> On 17. Dec 2019, at 17:43, Juliusz Chroboczek <jch@irif.fr> wrote:
> 
> Dear Mirja,
> 
>> I keep pointing at RFC8085 because that’s what the IETF agreed to be
>> “safe” in the general case.

You are citing this sentence out of context. I didn’t say that you have to stick to these values but (if you don’t want to do that) you have to provide reasonable values in the spec and discuss when it is safe to use low values.

> 
> I refer you to my mail of 9 August 2019, where I reply to almost exactly
> the same statement.  RFC 8085 discusses what is considered recommended for
> protocols that run over the Internet.  To witness:
> 
>   Internet paths can have widely varying characteristics, including
>   transmission delays, available bandwidths, congestion levels,
>   reordering probabilities, supported message sizes, or loss rates.
>   Furthermore, the same Internet path can have very different
>   conditions over time.
> 
> In Babel, like in OSPF, there is no "Internet path" involved -- there is
> just an association between two direct neighbours (from the point of view
> of layer 3).  It is therefore my opinion -- already stated in my mail of
> August 9 --, that obeying the recommendations in RFC 8085 is not required
> for Babel to become PS.

Yes it’s  not an Internet path but you still want to design a protocol that is safe to deploy, as you say, in various scenarios and therefore you should build some safety measures to not overload the network.

> 
> In the same mail of 9 August 2019, I make the claim that there is no
> mechanism related to RFC 8085 in RFC 5340.  In other words, it would
> appear that you are holding Babel to a much higher standard than OSPFv.
> 
> 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.

> 
>> Currently the document proposes some values but it does not discuss in
>> which scenario these values are appropriate to use (or when they are not
>> appropriate to use anymore).
> 
> Appendix B gives values that are suggested for implementations.
Yes but it doesn’t discuss for with _deployment_ scenarios these values are suitable.

> 
>> If you have that experience it should be possible to e.g. to describe
>> the network scenario that you used babel in and give the values that
>> have been used in that scenario. What are those scenarios?
> 
> The first set of parameters in Appendix B gives the values that are used
> by recent versions of babeld (the reference implementation of Babel) and
> that have been used in production for many years in a wide range of
> networks, including wifi meshes, wired networks, and large community
> networks consisting of a complex mixture of wireless and wired links.
> These scenarios are described in the Applicability statement.

First it would be helpful to then provide a pointer to that document. I assume you means draft-ietf-babel-applicability right? Then it would be nice to be more concrete. 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"? And what does e.g. a small unmanaged network means? How many devices do you usually have in such a network to call it “small”? Is that network connected to the Internet or not?

> 
> -- Juliusz
>