IETF Logo Mail Archive

Re: [manet] SMF in Manet and MPR

Christopher Dearlove <christopher.dearlove@gmail.com> Tue, 30 January 2024 11:43 UTC

Return-Path: <christopher.dearlove@gmail.com>
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 D987CC014563 for <manet@ietfa.amsl.com>; Tue, 30 Jan 2024 03:43:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 N2QqQ8_ynnVA for <manet@ietfa.amsl.com>; Tue, 30 Jan 2024 03:43:23 -0800 (PST)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 63ADFC014565 for <manet@ietf.org>; Tue, 30 Jan 2024 03:43:23 -0800 (PST)
Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-55a9008c185so6707878a12.1 for <manet@ietf.org>; Tue, 30 Jan 2024 03:43:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706615002; x=1707219802; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=frXwY9rhWXKnjWwYNWv7OQpv/8+2p7LhMwveYmzlIPk=; b=Iv7+fshlyv8LpId0k3IASx/bVNgKeskyMIFqWSFh9aRzJuPJNDIQglJNHl/gpEk5Yh 8MK1jRTjL6xR6tBQGodfsvOM9jCJhKDaQnnzmpOnwzn5YiB6a7pLRDgzpu09IZjLwkgL UZS8La2jsKChlE8eu8v9e7+kii8uA895WsNcTBUXgnDzHpEpz6EoVQdnrpn1IXkG6h+3 yMVoF7LHoNmcksX3N0Eylds8dxZlqvne6p79tE/5YdMY2jlj4Gu20gBQmPE+nii1TDxL SXFFGuWQUWI7vTVG9sAHmcvMywNhQur4woDeM6TzGhlvDgCvsL7QRRS6yqm5NQgrygic EQzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706615002; x=1707219802; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=frXwY9rhWXKnjWwYNWv7OQpv/8+2p7LhMwveYmzlIPk=; b=EJLCvVW8KgaH6Mvj6mbyk8rehsplcfSvqdZZ+/27v3QzVrNxF6mYqOXIj8qEXd8PRX uQalWqtoiOSV1SdhhbqCeNnfXKWqsxNXQBiRsM40U/BxTHB/+lQ3G5AhbnZuz+LCQZb1 nTCno0xFiOpADjf8CuXINvDVq0fqBR/AQlE68j6QgzqQvB7LsWt881CYvgqJRCgUecqf z2rI6u6Sbr3NX2yAR2MM/VjUuYQvXQRbQCRfbA8+LXmZcrDp0+pvdIClwqpR4Bo4gPin YbwXrLKsd8wg5ztB3+OdXEJaoXzYDHeSvBFOjZsrQRxMt5S71/XKWI2XdMhdyjfeLodj QZAg==
X-Gm-Message-State: AOJu0YzyxOTtASY5O8zZIXPm3yMl1k+FZ2edwI6LKgna7bmGoxDAiptA p2QNm+2bndH+1FWW7wZLrzx8VjpO1oTx+nh/ttNw0LybksocfIAP
X-Google-Smtp-Source: AGHT+IHezJBBMjebiD1ssOoNGglcNQs++sO2Koxs3407z32xqxoRUhXXWF+TQVKiWyaoR3zzBdnqIw==
X-Received: by 2002:a05:6402:2cf:b0:55c:a9f0:214d with SMTP id b15-20020a05640202cf00b0055ca9f0214dmr1312895edx.10.1706615001383; Tue, 30 Jan 2024 03:43:21 -0800 (PST)
Received: from smtpclient.apple (82-132-226-203.dab.02.net. [82.132.226.203]) by smtp.gmail.com with ESMTPSA id fi5-20020a056402550500b005583e670df7sm4793927edb.73.2024.01.30.03.43.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jan 2024 03:43:21 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\))
From: Christopher Dearlove <christopher.dearlove@gmail.com>
In-Reply-To: <CAGnRvupq+NYGg07AcM4Mvm3wKrocEyVDChGnXeVXV4g5MP8jPA@mail.gmail.com>
Date: Tue, 30 Jan 2024 11:43:09 +0000
Cc: Abdussalam Baryun <abdussalambaryun@gmail.com>, "Robert B CIV USN NRL (5522) Washington DC Adamson (USA)" <brian.adamson=40nrl.navy.mil@dmarc.ietf.org>, MANET IETF <manet@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <514800B1-D65A-4352-B5A4-88CEB429E04E@gmail.com>
References: <CAGnRvuoAdGeuzESf4VgYVB2xkEBX=t+3Vm4BMn0q37OKx9_jAQ@mail.gmail.com> <34F68A6F-F4A3-4B9C-A4DD-549246154F67@nrl.navy.mil> <CADnDZ8_kDp__Gx8aCBdCmnH_5z9zq6yRSjnkUJB7bYyFs7FvtA@mail.gmail.com> <CAGnRvurt6R1y=ZSMNOmOEPF+FY4GYGzroek3ntt3024ASpVJuw@mail.gmail.com> <86A7B91A-E3E6-4DBF-9D0F-2E2C58229237@gmail.com> <CAGnRvupq+NYGg07AcM4Mvm3wKrocEyVDChGnXeVXV4g5MP8jPA@mail.gmail.com>
To: Henning Rogge <hrogge@gmail.com>
X-Mailer: Apple Mail (2.3774.300.61.1.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/yYzIrBYG3LPQFstdvpIzKiKHTBs>
Subject: Re: [manet] SMF in Manet and MPR
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, 30 Jan 2024 11:43:27 -0000

That none of us even wrote an ID suggesting it is fairly indicative of that we all - independently I think - thought of this as a hack. Not even an experiment as IETF uses the word (though an experiment in the broader use of the word).

(An informational ID describing it could have been written, but clearly no one thought that worthwhile.)

> On 30 Jan 2024, at 09:43, Henning Rogge <hrogge@gmail.com> wrote:
> 
> On Tue, Jan 30, 2024 at 9:51 AM Christopher Dearlove
> <christopher.dearlove@gmail.com> wrote:
>> RFC 5444 is mandated for use on the MANET UDP port (and IP protocol) by RFC 5498 and repeated in RFC 8245. Any other use is optional, but there’s no good reason to use it on the data plane.
>> 
>> There was an (or possibly more than one) experimental - I don’t believe it even made it to an ID, but was implemented and reported in at least one paper - use of OLSR for an SMF-like approach to multicast, intercepting the data packets in the IP stack, encapsulating them as a new OLSR message type, flooded using OLSR, then converted back to IP data plane at destinations. This was rather a hack and the SMF approach was to supersede that, keeping data in the data plane where it belongs.
> 
> the OLSR (v1) implementation of olsr.org had a "BMF" plugin that did
> exactly that... encapsulating IP traffic into OLSR messages to forward
> them.
> 
> It wasn't a nice thing, good that we did not standardize this.
> 
> Henning Rogge

v2.23.0 | Report a Bug | By Email