From nobody Mon May 1 06:07:06 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 ADA2DC151B06 for ; Mon, 1 May 2023 06:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.098 X-Spam-Level: X-Spam-Status: No, score=-7.098 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 5oZ4ccMZKWba for ; Mon, 1 May 2023 06:07:02 -0700 (PDT) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 70D59C14CF12 for ; Mon, 1 May 2023 06:07:02 -0700 (PDT) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-94f3df30043so402029266b.2 for ; Mon, 01 May 2023 06:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682946420; x=1685538420; 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=/pOt8mOo5dN3R2YkTcRyLMfwsLgheL8ngBTZaebDvN8=; b=EGxw1AJyMrIw4m7XNp1n55ZXPf6q0IkF90a/j31sBWREd99+N+l8uiJBSwWLo10fES E1qR5q2oyQ+dBk9kkBoxpDLQCG9pwy6Tm/koDBNXZI0Io7UZ90mrhiE4idl3I42wDSHM KRH0z2SDV512TDZLgZ8jHQxhtezeJWLgARp+xq8TTWeT9T4pON2bg7sgka8ASWrIBSfF ljhKku3r+XXEsXowwJxgrpKfrRyrwfQ7ZDEBkaJ/EWiSI0uM5n7DqPSHoQ72hRsZS7QZ trukWdocGqOOdurNZwZESz/Qmj7GczC8DCqO/jTN/eEvw/fkvW+xT3yLEg60W0Fplqjf aBLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682946420; x=1685538420; 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=/pOt8mOo5dN3R2YkTcRyLMfwsLgheL8ngBTZaebDvN8=; b=DEc/mmpQaEE8aJhD+j3tf3wFHkzsfTlPSB/KaVgqJxK9PypJR81Epm4PLGFPIJxfmI LHNs5QRcMrxbAqzZw8tTveHofufJi5WVZnpUgqKEO81ixrn/KlziMOwWiVWkU5vrPjPq 9ynSS9gM4Ne2AwVoZN8Kiq4gyRY6xeMEmRdhtW3wbbq9T2IyOA97gWWeze/oTgIJLUaU 0w5ayaiAjpNAQrjsnPAiqj3WXpyapiQ2FiLx77uEGoRcLgJ3VuAZLO3di8dze9MNH9mV fCkWE1nGIACC4pViwhAsoAIKEKfhwpxyIzhglIx1wCUdwBeWCk7nk2+6ZUFE3/xuce+A M3Wg== X-Gm-Message-State: AC+VfDysxcEMmHOJPHWsnLgZzd0Egyk+734EoC5aLl/Pw8cKPFTsz43N tPqC0P6VAIj7CjjglIeKcnSE6HOlOkc= X-Google-Smtp-Source: ACHHUZ7AJv997RkEgT1Oa7J5CsXNhM5BttERnFeKg+b2l9BmB4td827ry0GkLcQxRgxWm1vD89ckSQ== X-Received: by 2002:a17:907:3faa:b0:94f:695e:b0c9 with SMTP id hr42-20020a1709073faa00b0094f695eb0c9mr13181343ejc.5.1682946420415; Mon, 01 May 2023 06:07:00 -0700 (PDT) Received: from smtpclient.apple (82-132-226-212.dab.02.net. [82.132.226.212]) by smtp.gmail.com with ESMTPSA id gz19-20020a170907a05300b0095076890fc1sm14806769ejc.1.2023.05.01.06.06.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 May 2023 06:06:59 -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 14:06:48 +0100 Cc: "manet@ietf.org IETF" Content-Transfer-Encoding: quoted-printable Message-Id: <003DD150-8216-4ED9-A469-F9515D7DE8B9@gmail.com> References: <20230428120229.2CD1A55D5E@rfcpa.amsl.com> <6A3011F2-D55B-40E3-9156-A5DCEF5A763F@gmail.com> <6F5AB9FE-5869-42AB-8311-8ED4BA83C8ED@gmail.com> <3712F167-8859-4D69-B67C-2FAB2404DAD4@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 13:07:04 -0000 On 1 May 2023, at 14:00, Henning Rogge wrote: >=20 > On Mon, May 1, 2023 at 2:55=E2=80=AFPM Christopher Dearlove > wrote: >>=20 >> 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. >=20 > But a little bit harsh for a link that might just have missed one/two > Hellos... it might be the only link between two parts of the network. Which is why you retain the metric information while not using the link, = ready to reinstate it if you discover it=E2=80=99s good again. And I was addressing the suggestion that you know the link is broken. = Presumably from L2 or similar. Using missing HELLO messages is one way = to use link quality, but the two are not inseparably linked. You can use = link quality based on anything you like, L2 information on/off is one = possibility. >> 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. >=20 > I can adjust the content of the TC my local router is producing... at > the moment I am experimenting with a mechanism that will (as soon as a > link is overdue based on Hello-Interval) use a similar "penalty" to > the outgoing link metric in the local database than the metric > algorithm (slightly modified DAT at the moment) does on the incoming > one based on the time interval... which means this penalty will be > instantly gone a new PacketBB packet arrives from the neighbor. >=20 > It works quite well if both ends of the link run the same metric = algorithm. Both ends need to be running the same algorithm with the same data, = which is not usually available. If it is, fine (and then actually you = don=E2=80=99t need quite a lot else). But if not, you are definitely = risking creating routing loops. (Always a danger if information is not = fresh, but increased here.) > Henning