From abdussalambaryun@gmail.com Wed Nov 8 05:08:43 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 CA1A9C170613 for ; Wed, 8 Nov 2023 05:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.107 X-Spam-Level: X-Spam-Status: No, score=-7.107 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, HTML_MESSAGE=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: 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 z-pyiY5EVEYI for ; Wed, 8 Nov 2023 05:08:43 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 19686C17C890 for ; Wed, 8 Nov 2023 05:08:43 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2c5039d4e88so93890651fa.3 for ; Wed, 08 Nov 2023 05:08:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699448921; x=1700053721; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+WjUl/f78/prPOAs66Kuuy3lD0M2dR7wWOPyl/nt1pM=; b=jtp9lG1TiBACDoSYxBdXpEATyIY9GU+9+uv3qQ36HiQ4gONNCbGjr3f5bdXLHQeguS WeH/T7zOjPVFN0HSJidXCMSZ61n44xMPinvhX3ylLZ1y/HNRkwox+FucmQ+PFPEENjrc WChgqlfPBcxlSwq0Xx/pKWMTRdKWOFLbtJD27y9h/E1ZX9MmFUONkOa8gi0CaqwOX1j/ X97KikKweHSrljz0gPIyLYaECB06+5PHpcVoRl1xRHKgg0DttdsiWuFqy2FoP/bYxiL6 fuvqr0E5m1wCf1nTXYC/eH6rvVqYP1fjRv4+/+WL6hDYzeCTXBTXOkw79eCTaLDZFGde SOaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699448921; x=1700053721; h=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=+WjUl/f78/prPOAs66Kuuy3lD0M2dR7wWOPyl/nt1pM=; b=Nfdb0rghTD+aFCR3+VQI8Vi7qiq7lYCKvmVrBVNy4tHJdsaQJIgWwzK0REcAMIesFq L2D4BGVY8E/kQ3DKIFIwe29Pk4WheMceoSjsS62O4qN5FmjgkGOKYiZrRkSpUmFXtHdh VX34ET0R0S9LOq9Wm6qeWJacQQuxSUV8rZ/MNXzQPlS8MgHyjmrxskqqJv7v7bKgXM2F +ljRbukeoI5WqqkNjXMjvTL5ZjGYZVPmMP7UQl01u45M5zicjGeabkkhBcrz7Lpi/8wV dm1UHEFxohnDHfvzksu71X1sS7ru7v4dD5WnSy5LbWHZ07s29ACCEtJol9BL3J53SnqF IdkQ== X-Gm-Message-State: AOJu0YzswMWfEvlz7oLFupWIvKGnC0uIELyvE+9PLeegW4NDXL3Vfc5l 0GkS52mAJ26jvjw0fRLKlYoHfIQ6P6HxtFWY26S5zafW X-Google-Smtp-Source: AGHT+IGWNP/9JWlgNTUcQco7nXL17nlvyKIHmrIlXzs8n4rtI4d2wOqDU0R6voHc73RGxa7nMcWYTUUDSZ8DM7qhrWM= X-Received: by 2002:a2e:a312:0:b0:2c5:1542:6147 with SMTP id l18-20020a2ea312000000b002c515426147mr1745147lje.15.1699448920800; Wed, 08 Nov 2023 05:08:40 -0800 (PST) MIME-Version: 1.0 References: <2DF36343-1777-49D2-92B5-DECA6EE87F8F@gmail.com> In-Reply-To: <2DF36343-1777-49D2-92B5-DECA6EE87F8F@gmail.com> From: Abdussalam Baryun Date: Wed, 8 Nov 2023 14:56:47 +0200 Message-ID: To: Christopher Dearlove Cc: MANET IETF Content-Type: multipart/alternative; boundary="0000000000003d04b50609a3c915" Archived-At: Subject: Re: [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 13:08:43 -0000 --0000000000003d04b50609a3c915 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 8, 2023 at 2:55=E2=80=AFPM Christopher Dearlove < christopher.dearlove@gmail.com> wrote: > To summarise where I think things are with regard to OLSRv2, starting fro= m > 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 f= or > 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. Probabl= y end up > repeating some material. > > - An informative document that explains how OLSRv2 (including NHDP) can b= e > used in ways that allow more efficient use in some scenarios. I have note= s > somewhere that can expand on some of this. It could be considered as > rationale for many of the design decisions. A possibly non-exhaustive lis= t > 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 t= o > 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 easi= ly > defined, network properties to be suitable (density largely). > > From 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 com= mitment 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 i= s > 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 (al= so > more than one level). The full generalisation is a form of policy-based > routing. > I think the AODV algorithm is same for all just few functional changes among those versions, however, DLEP can help to trigger routers to do what is needed. AB --0000000000003d04b50609a3c915 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 8, 2023 at 2:55=E2=80=AFP= M Christopher Dearlove <christopher.dearlove@gmail.com> wrote:
To summarise where I think things are with= regard to OLSRv2, starting from the easiest - not necessarily the most imp= ortant (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 l= earning of a new router in the network (on adding an entry to the Advertisi= ng 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 the= re=E2=80=99s a standards track/informative mismatch. Probably end up repeat= ing 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 ration= ale for many of the design decisions. A possibly non-exhaustive list of the= se features and use is:
=C2=A0 + The ability to work responsively, only sending messages when the s= ituation changes. (This might need the first point above for ideal use.) As= sumes a stable network, other than joiners/leavers and the changes they off= er/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 ex= ponential backoff in stable circumstances, with reversion when changes occu= r. Similar to the above in some regards.
+ Different parameters on different routers and different interfaces. The f= ormer is potentially useful when e.g. some routers are moving rapidly. Idea= lly some modelling would support this.
+ The ability to set multiple TC interval times at different distances, imp= lementing the concept of fisheye/HSLS routing. Requires some, not easily de= fined, network properties to be suitable (density largely).

>From 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 waiti= ng for timeout of its previous messages. Ranked lower than the above becaus= e 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 n= eighbour for fast full joining. There are lots of questions here - solicite= d or unsolicited, message format (and how to make 5444 compatible when it e= xpresses the relationship between two addresses, not a characteristic of on= e address), in HELLO message?

And a long way down, and I don=E2=80=99t think there=E2=80=99s enough commi= tment from the WG, or even real use cases openly demonstrated:

- Adding reactive features (RREQ/RREP messages) to OLSRv2. In principle thi= s wants a reactive protocol, but as so much would need re-engineering, know= ledge of AODV/AODVv2/LOADng might suffice. Although the technical problems = with AODVv2 remain issues to be solved here. The basic concept is routers n= ot prepared to do what=E2=80=99s needed proactively (though this has more t= han 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 rou= ting.

I think the AODV algorithm is sam= e for all just few functional changes among those versions, however, DLEP c= an help to trigger routers to do what is needed.

A= B
--0000000000003d04b50609a3c915--