From christopher.dearlove@gmail.com Wed Nov 8 04:55:45 2023 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADAD3C16F404 for ; Wed, 8 Nov 2023 04:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: 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_DNSWL_NONE=-0.0001, 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzyTSEhNuiV5 for ; Wed, 8 Nov 2023 04:55:43 -0800 (PST) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 E3F04C16F408 for ; Wed, 8 Nov 2023 04:55:43 -0800 (PST) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-40806e4106dso4763555e9.1 for ; Wed, 08 Nov 2023 04:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699448142; x=1700052942; 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=bNmY/GoZGaiBF6UaulPtZyi7eMVr2zX03I4r2wxAYFI=; b=NGNKzyB18Zt+Ql43IJJszO8NGU6mse2cIThxk2Vzo1kvoq1kWIbkOfHetKd0jqMp54 dQ4lCxJ62R/Fw7ly/GYJv5zopVBEdcvKZlbKplKtmdbmrN4GnNG0X26bCfiuPRPwYpgp 5cVH3ufATx+VVXi9vVuPEQyYsEfttTTGHT3YScLA0YVcRzO7WDeUs7omCmYlTzRE3c39 M9HnYQ2xjAsvzV589BsigVNPd3ftYA5B929G/P0rH/1APaC0BZT7VQaTIGkqR4pY3NFF 2WIZW3sObgtunj7rmXRzd3VDTwW8+Bp99aXRJ4nF/G8nzk7WTkBydfecff48s0ct2xhV KEbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699448142; x=1700052942; 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=bNmY/GoZGaiBF6UaulPtZyi7eMVr2zX03I4r2wxAYFI=; b=Gcu+xxfweRIvvPE+/1lZ+ihDRcGhoL4Sp2+xdZQUxNRMm6MWznZ8GQwKYnBb+EbhCY YUqViT4FNmxEc+7jfrnBQjYKUNl4WI5y6DrMmjlcmAvkYhRkM2GvLcM1U5IQ37mCqj0r oPD6B2bI7bcQJyoMBzn4DmwnCoKwXRDvGEmoA69LxkARSan/82eI+ZriZSuFEvX42tLB eyqVuS+CLSh89/5KV1iv5/LuYylzzvPayGugYlETyVEnXoB2g4H7RJG27ZwS38qj8nW/ 8gO5GqYUVOykaPHCAp1ehRZ3GfrQagKwEwcDtzX3JlGGPlQouNFrWuWYeDCFvfZD3IOc xR8w== X-Gm-Message-State: AOJu0Yw4j9WW43TX/Ndn6zsVyR00dXq0wUgosFAhxCAQtCExVmEnH1aj slqDiCsM5SHm60e6NfM2Xwr3rH/0Ceo= X-Google-Smtp-Source: AGHT+IG+N5a0nRUBX5oS2VobukrscrrQZbZsMXV/WJlRgWbFM3R9VKUmWbJzluZsITDJgeQbQtKn2w== X-Received: by 2002:a05:600c:3104:b0:407:3e94:bcca with SMTP id g4-20020a05600c310400b004073e94bccamr2205943wmo.1.1699448141442; Wed, 08 Nov 2023 04:55:41 -0800 (PST) Received: from smtpclient.apple (82-132-224-241.dab.02.net. [82.132.224.241]) by smtp.gmail.com with ESMTPSA id f21-20020a7bcc15000000b0040773c69fc0sm18787698wmh.11.2023.11.08.04.55.40 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2023 04:55:40 -0800 (PST) From: Christopher Dearlove Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.100.2.1.4\)) Message-Id: <2DF36343-1777-49D2-92B5-DECA6EE87F8F@gmail.com> Date: Wed, 8 Nov 2023 12:55:23 +0000 To: MANET IETF X-Mailer: Apple Mail (2.3774.100.2.1.4) Archived-At: Subject: [manet] OLSRv2 futures X-BeenThere: manet@ietf.org 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 12:55:45 -0000 To summarise where I think things are with regard to OLSRv2, starting = from the easiest - not necessarily the most important (if anything is). - A simple standards track document that adds permission to for a router = to send one or more unscheduled TC messages (probably changing schedule) = on learning of a new router in the network (on adding an entry to the = Advertising Router Set). However, a complication is that the motivation = for this is based on the next item, so how to package the two would be = an issue, as there=E2=80=99s a standards track/informative mismatch. = Probably end up repeating some material. - An informative document that explains how OLSRv2 (including NHDP) can = be used in ways that allow more efficient use in some scenarios. I have = notes somewhere that can expand on some of this. It could be considered = as rationale for many of the design decisions. A possibly non-exhaustive = list of these features and use is: + The ability to work responsively, only sending messages when the = situation changes. (This might need the first point above for ideal = use.) Assumes a stable network, other than joiners/leavers and the = changes they offer/require, and the ability to recognise local changes. = (Or continue to use NHDP as usual.) + The ability to change parameters dynamically. Enables features such as = exponential backoff in stable circumstances, with reversion when changes = occur. Similar to the above in some regards. + Different parameters on different routers and different interfaces. = The former is potentially useful when e.g. some routers are moving = rapidly. Ideally some modelling would support this. + The ability to set multiple TC interval times at different distances, = implementing the concept of fisheye/HSLS routing. Requires some, not = easily defined, network properties to be suitable (density largely). =46rom this point down, there needs to be real motivation to consider = them. (Also true above, but I think that might exist.) - A mechanism to allow a forgetful router to rejoin a network without = waiting for timeout of its previous messages. Ranked lower than the = above because it=E2=80=99s a change, and compatibility has to be = considered. - A mechanism to allow a router to dump its topology information to a = new neighbour for fast full joining. There are lots of questions here - = solicited or unsolicited, message format (and how to make 5444 = compatible when it expresses the relationship between two addresses, not = a characteristic of one address), in HELLO message? And a long way down, and I don=E2=80=99t think there=E2=80=99s enough = commitment from the WG, or even real use cases openly demonstrated: - Adding reactive features (RREQ/RREP messages) to OLSRv2. In principle = this wants a reactive protocol, but as so much would need = re-engineering, knowledge of AODV/AODVv2/LOADng might suffice. Although = the technical problems with AODVv2 remain issues to be solved here. The = basic concept is routers not prepared to do what=E2=80=99s needed = proactively (though this has more than one level) but prepared to do = some or all of the work reactively (also more than one level). The full = generalisation is a form of policy-based routing. - Adding DTN features, with message store and forwarding. (I=E2=80=99m = aware of some IPR here.) - Routing confidentiality. (I=E2=80=99m aware of some IPR here too.)