[manet] OLSRv2, a possible small change

Christopher Dearlove <christopher.dearlove@gmail.com> Tue, 26 September 2023 15:05 UTC

Return-Path: <christopher.dearlove@gmail.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8AAE0C1519BB for <manet@ietfa.amsl.com>; Tue, 26 Sep 2023 08:05:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Status: No, score=-2.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_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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JBm1dCgOoxM3 for <manet@ietfa.amsl.com>; Tue, 26 Sep 2023 08:05:38 -0700 (PDT)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 47689C1519BA for <manet@ietf.org>; Tue, 26 Sep 2023 08:05:38 -0700 (PDT)
Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-40566f8a093so60004855e9.3 for <manet@ietf.org>; Tue, 26 Sep 2023 08:05:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695740736; x=1696345536; darn=ietf.org; h=to:date:message-id:subject:mime-version:content-transfer-encoding :from:from:to:cc:subject:date:message-id:reply-to; bh=xehw8AllE36Z5JnTHOzBrsYEn/bJCHUqnHHWUMK3DZ8=; b=OWeqDkykSdqOhGpYcaVCZCoImWc96RtHSh+ak8398EnQw63lr4GNgNvfwU0aK2U5BK Pg4wZlUX6qoXq87CKrbQDruoHLVKP/A31s0BY93v/dT8wXfuDIJNaeP0lzNSTsPyWf0Z ZorCQTjd808lTSq3zPUPGwHkLAAi6ejNiojHqzsA49taXn9koIv1lSRGdzctRFc8UX77 66d8tHDfEYi8rOOz/hq/mFzeXfV3LI+Hrq52Zvq8F49HgKd9emTTLnDQ4+FlIC8TwNeO 1pan4UVX51xPi6qaf+TumkaBoosezDgMFI5ExhQksOYLxvgCjnrZAMUdsXFwH+1XUV1h T1IA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695740736; x=1696345536; h=to:date:message-id:subject:mime-version:content-transfer-encoding :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xehw8AllE36Z5JnTHOzBrsYEn/bJCHUqnHHWUMK3DZ8=; b=QfTfmntLUYAsSRiGMnX2jyQ0WP8ehYVU9zE39RdHvw9Dg1mTjeT/xLzHF0vZAGbcMJ 2OKX0rbBt1RfLHEzXU4odAe5IOwYJx7aAGckNkSfoQlUo4sFEh4Fs5tlNtAjvL9iyeER 2cHAYeDoW5FCdIRjxGYaT3GHOU+OTo4gFwXxSEWa+IWIMumqTVK3QHXIc6/wiyfYT1lR 7iLlINEz2nrZO6TGzsF0KvlA+3ApVZJ60pqi5zcWIb8yO1LKYeAWiwGRY5kezseEz7q0 xcMFhFm4BGlwGF9lIDl7sLkfs7JRa0kw5+D6lTeLXFB1BNtOoyiNADw1KPvekb7zRaeh Hnwg==
X-Gm-Message-State: AOJu0Yxdi6gtrLFwoj3vaWuoW5IeOZVbbE+87/JFBHm5BOiiCoUA3sfa 2j1gsM8BXCw4soMRkj/KzU+zwQLUq3o=
X-Google-Smtp-Source: AGHT+IEtJ8iZtxv6kZKUuFazve/S6l3H2v0qaVEh7SszLGVeP4DtMTsxT00AIedZIFIlJegpThSgQA==
X-Received: by 2002:a7b:cd0a:0:b0:401:8225:14ee with SMTP id f10-20020a7bcd0a000000b00401822514eemr8982414wmj.41.1695740735924; Tue, 26 Sep 2023 08:05:35 -0700 (PDT)
Received: from smtpclient.apple (82-132-225-118.dab.02.net. []) by smtp.gmail.com with ESMTPSA id y20-20020a1c4b14000000b004063cd8105csm1620519wma.22.2023. for <manet@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Sep 2023 08:05:35 -0700 (PDT)
From: Christopher Dearlove <christopher.dearlove@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
Message-Id: <E34BDEBB-F49C-4F34-BC37-A6177659DA36@gmail.com>
Date: Tue, 26 Sep 2023 16:05:18 +0100
To: MANET IETF <manet@ietf.org>
X-Mailer: Apple Mail (2.3731.700.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/-mECseZDMxSaySBmYivOEhlbACI>
Subject: [manet] OLSRv2, a possible small change
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Sep 2023 15:05:42 -0000

There is the possibility of an RFC 7466-style minor tweak to OLSRv2 that is fully backward compatible.

I don’t think I’ve overlooked a parenthetical remark about this anywhere in the existing RFCs. But that should be confirmed before taking action beyond discussion. And some might argue do we need to spell this out - it should be obvious to anyone thinking of doing it. (Although in my experience apparently obvious isn’t always that.)

We start from the idea - designed, but not fully documented - that OLSRv2 can be used responsively, meaning that routers react to changes, but do not periodically update the rest of the network. An example might be a static network where routers might be on or off, but once a link is established, it is assumed to be good. We can of course use an intermediate case where we do long period updates, but expect also to mostly use responsive updates. We might also have to allow for unreliable links, where we might use the licence to send messages more than once in quick succession.

The main part of the rest of this discussion just considers the simple case of pure responsiveness. You might note that there is no actual provision for totally non-periodic HELLO and TC messages, but if we set the period to the maximum allowed then in practice this is essentially infinite. (I have a suggestion here below.)

So when a router turns on, it sends HELLO messages that causes a flurry of HELLO and later locally generated TC messages from neighbours and itself as things change. This is almost sufficient to have a fully functioning network with the new router included. There is however an exception. These messages do not allow the new router to learn about remote routers until they send TC messages. Fine if they are sending periodic messages, but if they also are purely responsive, that won’t happen.

Such routers should (or even at least SHOULD) send a responsive TC message when they learn of a new router in the network. This would be via a received TC message - but actually this should be defined in terms of the information bases, where I think the Remote Router Set is sufficient.

That’s already not breaking any rules of OLSRv2, but it’s also not specifically allowed.

If this were taken on board, I’d see an ID, later to be RFC, and Proposed Standard would make sense, that:
- Described the use case of responsive user OLSRv2. Possibly adds new rule that defines the maximum value of any INTERVAL parameter as actually meaning infinite. This would allow other routers to better understand behaviour.
- Points out the problem that currently exists.
- Adds what I think is always a MAY, is a SHOULD if the router is acting at least partly responsively, and is a MUST if using the proposed new rule above, to send a TC message (with permission for more than one as usual, and on all interfaces) if a new entry in the Routing Set is identified.
- Repeats, just to be clear, that in this case messages SHOULD/MUST be sent in response to other changes, as described in RFCs 7181 and 6130.

Note that there are other solutions to this problem, including local topology exchange, but those are not backward compatible. And the issue of a router restart is related to this. But I think trying to include that would be the classic trying to do too much so that the simple thing is lost (and delayed).

I could probably write this - if I recall how to write IDs, and see how the technology has improved since I last did this. But I don’t see the need unless at least someone else is interested.

Christopher Dearlove