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

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
>