Re: [manet] OLSRv2 futures

Henning Rogge <> Wed, 08 November 2023 14:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2A55C1705FF for <>; Wed, 8 Nov 2023 06:48:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Status: No, score=-7.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f6uB1c6kDiWq for <>; Wed, 8 Nov 2023 06:48:14 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id F161AC16F414 for <>; Wed, 8 Nov 2023 06:48:13 -0800 (PST)
Received: by with SMTP id a640c23a62f3a-9d2e7726d5bso1051490866b.0 for <>; Wed, 08 Nov 2023 06:48:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1699454892; x=1700059692;; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=vLbqxE9h70uMjRJsUFE3zU49Ai/8Y7GWkm6McnsKimI=; b=e5EEMc5AV8JKOlKF/hlOa1NT8vS9XlfPrrWOh7yHyu52JY7Va/158HfHKqX95mhyYl sjy4G4csMEyvyJX9VzjVFPBkWQxgpLsYIs9kNWspdQYm7wwe2zCkZSLJGin64DaJf0/P CSY9S9w79pjIEN94/hoo9f8k4642qfvGmgtT1nqk859x0tq6UBGrK/DcLasryUfC4zbs Gh4ANqanEy+mPXSteDtU5Pj47JDWSGqBWLtJ750CQeEYj468Plekib414N7FCSmnAW7t e0Gd4zMI54IIv8hOQ/zhEbTxyrgPDrGsQD++V4YPVy7i8gZ07ikk+GNBzW5F2HTIn3c0 2CXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1699454892; x=1700059692; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vLbqxE9h70uMjRJsUFE3zU49Ai/8Y7GWkm6McnsKimI=; b=E2VRBP4vNCGhBndlAQBZjg1u3cU7/v1bQNudMFnaMC7Erxj5M8L9r4sohkVqXrovOL uBMhQ0XMAiCP9gMELdZLpF6UGXeHeIJ0bbAjF+Ogx85m0UtQQ8QdQmjsvQVJUECtdTZ1 +g7UcAuifRhCVqwd+i0caEmD+1PGCrjsZFvwn1SfERxakpFjQtQTuDhyVqI8gSR5X7If SEfusNP+Z9FqymIAo4FtoCmWi5MeksNgTfuOVeoQ3ERirL8wXrikiVDRVU+D/dXC/LEg sdM3twtPMzFAnHN2cYan/IfVMzLe2hojLjLS5lQnitNIN7QflSwXtJwA7py0ItJir7JT eaEg==
X-Gm-Message-State: AOJu0YxlzR0lCISNO391mghTDkxoh2/fj+gWJB060ZvzdcPzXyxT0VTj jo38zb0hROpbjbe1+VwoUiF7BD0QyTCHzbQU88TdKeVn
X-Google-Smtp-Source: AGHT+IGKSC592QudmprjHB9ff1+PjJAbfzKM3f2Pt43ltfDWRw/ERvd1FJdWGJtT9ccmJNCkGChdnyzrHeNeUXbqEZo=
X-Received: by 2002:a17:907:26c4:b0:9da:fd18:1fdc with SMTP id bp4-20020a17090726c400b009dafd181fdcmr1519682ejc.44.1699454892146; Wed, 08 Nov 2023 06:48:12 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Henning Rogge <>
Date: Wed, 08 Nov 2023 15:47:46 +0100
Message-ID: <>
To: Christopher Dearlove <>
Cc: bebemaster <>, MANET IETF <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [manet] OLSRv2 futures
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Mobile Ad-hoc Networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Nov 2023 14:48:14 -0000

On Wed, Nov 8, 2023 at 2:34 PM Christopher Dearlove
<> wrote:
> I’m fairly sure we considered that, but decided against that. The issue is that TC messages are forwarded, and don’t stay on the sent interface (if that’s even a meaningful concept). So if we sent TC messages at a different rate on different interfaces, that would only apply for one hop, thereafter the interface and the interval would be decoupled. So now we need to know why the idea, in order to decide what the point is.

Yes, that makes "per interface" TC rates/validities quite useless.

> So if we say we forward always, what are we achieving by sending at two rates? And if we want a split topology, we already have (experimental still) MT-OLSRv2 to use.

I have implemented MT-OLSRv2 twice, it works well enough... I am not
sure the "metric per topology" is always the best option, but it

> Looking at RFC 7722, it doesn’t have message intervals per topology. I was going to suggest it could - and changing an experimental protocol is easier than changing a standard - but there are some issues there I think. But again, rationale.

This would also remove quite a bit of aggregation that you get by
combining data from all topologies into one TC.

Henning Rogge