Re: [manet] [Technical Errata Reported] RFC7466 (7477)

Christopher Dearlove <christopher.dearlove@gmail.com> Mon, 01 May 2023 12:55 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 A54B8C151996 for <manet@ietfa.amsl.com>; Mon, 1 May 2023 05:55:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 5D5zGvMEAC50 for <manet@ietfa.amsl.com>; Mon, 1 May 2023 05:55:20 -0700 (PDT)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 77F77C15155B for <manet@ietf.org>; Mon, 1 May 2023 05:55:20 -0700 (PDT)
Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-94f910ea993so406310366b.3 for <manet@ietf.org>; Mon, 01 May 2023 05:55:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682945718; x=1685537718; 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=245Gwu//TpXAyNzvR1XMmpaz20eHzhYMvM8y4ojdVJo=; b=If1CzcYedOLMYrdeWMJdh98IvN5zqYYXj082+lKBqJdEhPq1q8J/9ZF0icWdRlQDUl hnDPWW6E4mw8mvHsmEs5GByZzZadxj0d2FiKjCEESVkKQ+HFwDGNSnml5dGK2249Bslu IDqlruCWXzCo9tpjAulbjVD89fEWirLHCBLZk7ITswJXz2i0ZUiuoUuZ4Vw+wnPFvUzO WbyRaOuwNX/EQQxdElHVR9Giu7VrTaOt1khxPqhuJhX9j9KHfM7LeMIKtgIRZngvuRCO j1klKzLLmeixggPPQMKypHKxjGMBVQtyYvvtjQcFmfpTZNFC5SqlfeUBPcci3hEDUeCJ piHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682945718; x=1685537718; 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=245Gwu//TpXAyNzvR1XMmpaz20eHzhYMvM8y4ojdVJo=; b=V8EsipwsBrSJP3evReGf6rnb2pB54gB1RW6ppm6vSLo+YeDuotbxWEqIU2ALqSCBXN FXPkAO4DCQaP7lOxt5DnB9GLydUpRhXMKpyIXlwpJYyIT7alml6vT+FKBs1Ly/+OqWXA Zk4wMcpnKCRFYl3oXT9bqZunV90aU7Hy1a4days+35HVjFCSqhz0vt9+OqmckVAeyVwR 8zcmXqqtZ/O8X0qTw+zjDw5yb6iUji6gj8IuRJbjBPUmdm3DOs6Nsxn7us6JDJ2tFMeL EB0QbbhNvCRHmNaD7uJwNlnGHLrmF39UzBCiLZCeC7wvDVDfJVTD5geDS55iHvVdvfQn IOdw==
X-Gm-Message-State: AC+VfDygk9UQIjE7GGmfCqWiNKmAAXtX4Mk05viQJH9bLcoQaxyw+ixn rwEIgI9MO628LqTurvaoLAR1SCL0KQ8=
X-Google-Smtp-Source: ACHHUZ7XJMCjPrfoWmAuAPQ0Cu+gVl/lph5X2ucNWWtuBU22kDf4OZqgnrZ07i3h8x6ZXU8tgvVtcw==
X-Received: by 2002:a17:907:7f27:b0:94e:1764:b09b with SMTP id qf39-20020a1709077f2700b0094e1764b09bmr14119345ejc.45.1682945718157; Mon, 01 May 2023 05:55:18 -0700 (PDT)
Received: from smtpclient.apple (82-132-226-212.dab.02.net. [82.132.226.212]) by smtp.gmail.com with ESMTPSA id k18-20020a1709060cb200b0094ed72b6552sm14846157ejh.98.2023.05.01.05.55.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 May 2023 05:55:17 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\))
From: Christopher Dearlove <christopher.dearlove@gmail.com>
In-Reply-To: <CAGnRvuozUHVztKOzuiz4KtU89wen7z7X0t+GZCDvh8o13kt-JQ@mail.gmail.com>
Date: Mon, 01 May 2023 13:55:06 +0100
Cc: "manet@ietf.org IETF" <manet@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3712F167-8859-4D69-B67C-2FAB2404DAD4@gmail.com>
References: <20230428120229.2CD1A55D5E@rfcpa.amsl.com> <6A3011F2-D55B-40E3-9156-A5DCEF5A763F@gmail.com> <CA+-pDCdO=YmS_fbzziNj5F5XeMSdT697umREnwxa1aHj3k5wkA@mail.gmail.com> <D0522646-3C68-43D0-80E6-C137D610199E@gmail.com> <CA+-pDCe19yjsHBo7qgnx9Cm2LQVqcs7qzWo=1Nd6D8pyNZp4Cg@mail.gmail.com> <PH7PR14MB536898987E33ECE1F49F6C5ABB6B9@PH7PR14MB5368.namprd14.prod.outlook.com> <CAGnRvuqYCcioyKOYC96Rsro9QLMHQu293Zd+pi9mduoPD=W6BQ@mail.gmail.com> <6F5AB9FE-5869-42AB-8311-8ED4BA83C8ED@gmail.com> <CAGnRvuozUHVztKOzuiz4KtU89wen7z7X0t+GZCDvh8o13kt-JQ@mail.gmail.com>
To: Henning Rogge <hrogge@gmail.com>
X-Mailer: Apple Mail (2.3731.500.231)
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/W_7-1zE-Yh5ns6f8UTsqNN1Lbzo>
Subject: Re: [manet] [Technical Errata Reported] RFC7466 (7477)
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: Mon, 01 May 2023 12:55:24 -0000

If you know that the kink is cut off you would use the link quality mechanism to stop that link being considered symmetric, and thus would stop reporting it in TC messages (among other changes). Using link quality as a binary good/bad state is a perfectly reasonable approach.

You can’t adjust the link metric value in TC messages, because (a) you don’t know what it should be, and (b) you will create inconsistencies that could lead to looping. Just stopping reporting (updating sequence number) is the best you can do. And using link quality does that.


> On 1 May 2023, at 13:47, Henning Rogge <hrogge@gmail.com> wrote:
> 
> I was talking about Link Metric...
> 
> The problem as far as I can see is that the Metric algorithm only
> calculates incoming metric, but TCs are filled with outgoing metric.
> Which means that if your link is cut off, the metric algorithm cannot
> influence the TCs content anymore because this would need a successful
> Hello transmission.
> 
> And having a link (as reported in the TCs) staying on the same metric
> until it times out can be less than optimal.
> 
> Henning Rogge
> 
> On Mon, May 1, 2023 at 12:34 PM Christopher Dearlove
> <christopher.dearlove@gmail.com> wrote:
>> 
>> Link quality or link metric? And in the latter case, incoming or outgoing?
>> 
>> In the case of incoming link metric - which is the link metric this router is responsible for defining - there is this text in section 15.3.2.1 of RFC 7181
>> 
>>   o  For any Link Tuple, L_in_metric MAY be set to any representable
>>      value by a process outside this specification at any time.
>> 
>> So that case is covered.
>> 
>> In the case of link quality - section 4.4 of RFC 6130 - this is something only used locally. While there isn’t text directly equivalent to the above, as it's just local, nothing you do can cause an interoperability issue.
>> 
>>> On 1 May 2023, at 10:38, Henning Rogge <hrogge@gmail.com> wrote:
>>> 
>>> Great... now we have spam in IETF Erratas???
>>> 
>>> By the way, I think I identified a 'problem' with how the combination
>>> of NHDP and OLSRv2 reacts to a suddenly breaking link... A coworker of
>>> mine identified during a test that the metric algorithm can NOT change
>>> the quality of a link when it suddenly breaks, which is quite annoying
>>> if you have a long Hello Validity time. Anyone interested in details?
>>> 
>>> Henning Rogge
>>> 
>>> On Fri, Apr 28, 2023 at 9:44 PM Don Fedyk <dfedyk@labn.net> wrote:
>>>> 
>>>> Several chairs are reporting spam Erratta in their working groups.  If you see more of these that don’t make any sense no need to address them.
>>>> 
>>>> Thanks
>>>> 
>>>> Don
>>>> 
>>>> 
>>>> 
>>>> From: manet <manet-bounces@ietf.org> On Behalf Of Justin Dean
>>>> Sent: Friday, April 28, 2023 10:39 AM
>>>> To: Christopher Dearlove <christopher.dearlove@gmail.com>
>>>> Cc: RFC Errata System <rfc-editor@rfc-editor.org>; manet@ietf.org IETF <manet@ietf.org>; T.Clausen@computer.org; rajeevsurroach11@gmail.com; ronald.intvelt@tno.nl; andrew-ietf@liquid.tech; jgs@juniper.net
>>>> Subject: Re: [manet] [Technical Errata Reported] RFC7466 (7477)
>>>> 
>>>> 
>>>> 
>>>> Ah you are correct as nearly always, I just saw the MANET and NHDP and thought NHDP.  The RFC number didn't seem right but it's been too long.
>>>> 
>>>> Justin (not a co-author of 7466)
>>>> 
>>>> 
>>>> 
>>>> On Fri, Apr 28, 2023 at 10:17 AM Christopher Dearlove <christopher.dearlove@gmail.com> wrote:
>>>> 
>>>> I feel that as a mere author, I can only make suggestions to the RFC editor. But, yes, as suggestions go, it’s quite a strong one.
>>>> 
>>>> 
>>>> 
>>>> (Incidentally Justin, I think you’ve got this one confused with another one - this one just has Thomas and I as authors.)
>>>> 
>>>> 
>>>> 
>>>> On 28 Apr 2023, at 15:10, Justin Dean <bebemaster@gmail.com> wrote:
>>>> 
>>>> 
>>>> 
>>>> "Suggest" rejecting seems a little too permissive.  Unless there was some issue with the reporting and there is more that just didn't get included it should be rejected.
>>>> 
>>>> Justin Dean (also Co-author of this RFC.)
>>>> 
>>>> 
>>>> 
>>>> On Fri, Apr 28, 2023 at 9:04 AM Christopher Dearlove <christopher.dearlove@gmail.com> wrote:
>>>> 
>>>> There appears to be a problem here. First, there is no Section 7466. Second, the original and corrected texts are the same.
>>>> 
>>>> (Also, were this to be an erratum, the notes would be entirely inadequate.)
>>>> 
>>>> I suggest rejecting this erratum.
>>>> 
>>>> Christopher Dearlove
>>>> (Co-author of this RFC.)
>>>> 
>>>>> On 28 Apr 2023, at 13:02, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
>>>>> 
>>>>> The following errata report has been submitted for RFC7466,
>>>>> "An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)".
>>>>> 
>>>>> --------------------------------------
>>>>> You may review the report below and at:
>>>>> https://www.rfc-editor.org/errata/eid7477
>>>>> 
>>>>> --------------------------------------
>>>>> Type: Technical
>>>>> Reported by: Rajeev Kumar Surroach <rajeevsurroach11@gmail.com>
>>>>> 
>>>>> Section: 7466
>>>>> 
>>>>> Original Text
>>>>> -------------
>>>>> 7466
>>>>> 
>>>>> Corrected Text
>>>>> --------------
>>>>> 7466
>>>>> 
>>>>> Notes
>>>>> -----
>>>>> Solve the issue
>>>>> 
>>>>> Instructions:
>>>>> -------------
>>>>> This erratum is currently posted as "Reported". If necessary, please
>>>>> use "Reply All" to discuss whether it should be verified or
>>>>> rejected. When a decision is reached, the verifying party
>>>>> can log in to change the status and edit the report, if necessary.
>>>>> 
>>>>> --------------------------------------
>>>>> RFC7466 (draft-ietf-manet-nhdp-optimization-04)
>>>>> --------------------------------------
>>>>> Title               : An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)
>>>>> Publication Date    : March 2015
>>>>> Author(s)           : C. Dearlove, T. Clausen
>>>>> Category            : PROPOSED STANDARD
>>>>> Source              : Mobile Ad-hoc Networks
>>>>> Area                : Routing
>>>>> Stream              : IETF
>>>>> Verifying Party     : IESG
>>>> 
>>>> _______________________________________________
>>>> manet mailing list
>>>> manet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> manet mailing list
>>>> manet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/manet
>>> 
>>> _______________________________________________
>>> manet mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>>