From nobody Mon May 1 05:55:25 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 A54B8C151996 for ; 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 ; 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 ; Mon, 1 May 2023 05:55:20 -0700 (PDT) Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-94f910ea993so406310366b.3 for ; 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 In-Reply-To: Date: Mon, 1 May 2023 13:55:06 +0100 Cc: "manet@ietf.org IETF" 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> <6F5AB9FE-5869-42AB-8311-8ED4BA83C8ED@gmail.com> To: Henning Rogge X-Mailer: Apple Mail (2.3731.500.231) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=E2=80=99t adjust the link metric value in TC messages, because = (a) you don=E2=80=99t 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 wrote: >=20 > I was talking about Link Metric... >=20 > 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. >=20 > And having a link (as reported in the TCs) staying on the same metric > until it times out can be less than optimal. >=20 > Henning Rogge >=20 > On Mon, May 1, 2023 at 12:34=E2=80=AFPM Christopher Dearlove > wrote: >>=20 >> Link quality or link metric? And in the latter case, incoming or = outgoing? >>=20 >> 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 >>=20 >> o For any Link Tuple, L_in_metric MAY be set to any representable >> value by a process outside this specification at any time. >>=20 >> So that case is covered. >>=20 >> In the case of link quality - section 4.4 of RFC 6130 - this is = something only used locally. While there isn=E2=80=99t text directly = equivalent to the above, as it's just local, nothing you do can cause an = interoperability issue. >>=20 >>> On 1 May 2023, at 10:38, Henning Rogge wrote: >>>=20 >>> Great... now we have spam in IETF Erratas??? >>>=20 >>> 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? >>>=20 >>> Henning Rogge >>>=20 >>> On Fri, Apr 28, 2023 at 9:44=E2=80=AFPM Don Fedyk = wrote: >>>>=20 >>>> Several chairs are reporting spam Erratta in their working groups. = If you see more of these that don=E2=80=99t make any sense no need to = address them. >>>>=20 >>>> Thanks >>>>=20 >>>> Don >>>>=20 >>>>=20 >>>>=20 >>>> From: manet On Behalf Of Justin Dean >>>> Sent: Friday, April 28, 2023 10:39 AM >>>> To: Christopher Dearlove >>>> Cc: RFC Errata System ; manet@ietf.org = IETF ; 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) >>>>=20 >>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>> Justin (not a co-author of 7466) >>>>=20 >>>>=20 >>>>=20 >>>> On Fri, Apr 28, 2023 at 10:17=E2=80=AFAM Christopher Dearlove = wrote: >>>>=20 >>>> I feel that as a mere author, I can only make suggestions to the = RFC editor. But, yes, as suggestions go, it=E2=80=99s quite a strong = one. >>>>=20 >>>>=20 >>>>=20 >>>> (Incidentally Justin, I think you=E2=80=99ve got this one confused = with another one - this one just has Thomas and I as authors.) >>>>=20 >>>>=20 >>>>=20 >>>> On 28 Apr 2023, at 15:10, Justin Dean wrote: >>>>=20 >>>>=20 >>>>=20 >>>> "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. >>>>=20 >>>> Justin Dean (also Co-author of this RFC.) >>>>=20 >>>>=20 >>>>=20 >>>> On Fri, Apr 28, 2023 at 9:04=E2=80=AFAM Christopher Dearlove = wrote: >>>>=20 >>>> There appears to be a problem here. First, there is no Section = 7466. Second, the original and corrected texts are the same. >>>>=20 >>>> (Also, were this to be an erratum, the notes would be entirely = inadequate.) >>>>=20 >>>> I suggest rejecting this erratum. >>>>=20 >>>> Christopher Dearlove >>>> (Co-author of this RFC.) >>>>=20 >>>>> On 28 Apr 2023, at 13:02, RFC Errata System = wrote: >>>>>=20 >>>>> The following errata report has been submitted for RFC7466, >>>>> "An Optimization for the Mobile Ad Hoc Network (MANET) = Neighborhood Discovery Protocol (NHDP)". >>>>>=20 >>>>> -------------------------------------- >>>>> You may review the report below and at: >>>>> https://www.rfc-editor.org/errata/eid7477 >>>>>=20 >>>>> -------------------------------------- >>>>> Type: Technical >>>>> Reported by: Rajeev Kumar Surroach >>>>>=20 >>>>> Section: 7466 >>>>>=20 >>>>> Original Text >>>>> ------------- >>>>> 7466 >>>>>=20 >>>>> Corrected Text >>>>> -------------- >>>>> 7466 >>>>>=20 >>>>> Notes >>>>> ----- >>>>> Solve the issue >>>>>=20 >>>>> 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. >>>>>=20 >>>>> -------------------------------------- >>>>> 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 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20