Subject: [manet] [Technical Errata Reported] RFC6130 (3677)

From: RFC Errata System <[email-masked]>
Date: Thu, 4 Jul 2013 09:27:58 -0700 (PDT)

The following errata report has been submitted for RFC6130,
"Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6130&eid=3677

--------------------------------------
Type: Technical
Reported by: Christopher Dearlove <[email-masked]>

Section: App. B p. 65

Original Text
-------------
   o  L_HEARD_time MUST NOT be greater than L_time.

Corrected Text
--------------
  o  L_HEARD_time MUST NOT be greater than L_time, unless L_lost = true.

Notes
-----
The case currently indicated as a constraint failure, but not by the relaxed constraint, can occur - and correctly - in normal operation of the protocol.

Instructions:
-------------
This errata 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 (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6130 (draft-ietf-manet-nhdp-15)
--------------------------------------
Title               : Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)
Publication Date    : April 2011
Author(s)           : T. Clausen, C. Dearlove, J. Dean
Category            : PROPOSED STANDARD
Source              : Mobile Ad-hoc Networks
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 7 Jul 2013 04:56:52 +0200

IMHO for principles of knowledge, the L_HEARD_time cannot be greater
than L_time when link is lost, only if the protocol is doing something
different with its information. If we lose link then we lost to hear.

The errata change can mean;
o  L_HEARD_time MAY be greater than L_time while L_lost equals true.

Not true hearing while lost the link, but you mention below that can
happen from the protocol. How many times that can occur per router or
per network? if it does happen then there is something wrong, then the
information in L-HEARD_time cannot be trusted because the link may be
lost. However, I prefer to suggest:-

AB> amend errata> RFC6130> section 14.3>
If L_status != PENDING, and L_quality < HYST_REJECT, then the
corresponding Link Tuple is modified by:
1. If L_lost = false, then:
o L_lost := true;
o L_time := min(L_time, current time + L_HOLD_TIME).
o L_HEARD := L_time.

AB

On 7/4/13, RFC Errata System <[email-masked]> wrote:
> The case currently indicated as a constraint failure, but not by the relaxed
> constraint, can occur - and correctly - in normal operation of the
> protocol.
>
> Instructions:
> -------------
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Christopher Dearlove <[email-masked]>
Date: Sun, 7 Jul 2013 07:31:59 +0100

I'm afraid you have demonstrated that you don't understand what's going on.

The point about the state in question is that L_lost is true because the link quality is poor. But it might get better again, and if it does we need to have retained the information about what state is then is. So L_HEARD_time is retained for possible restoration, but actually isn't being used. Because of that, it can be greater than L_time, because we keep updating L_HEAD_time in case of restoration, but we don't keep updating L_time, because we only want to advertise the link as lost for a finite time.

It's there and it works. It is just overlooked in the constraints. Your suggestion would break this.

Furthermore, modifying the constraints is painless. They only come into play when the internal state is modified by an external process. Mostly they can be ignored. But modifying the actual protocol is not painless. It is also not just unnecessary, but wrong.

I have implemented RFC 6130, as well as being an author. Have you?

This counter-proposal must be rejected.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 8 Jul 2013 09:08:34 +0000

My previously posted comment doesn't seem to have arrived here. In short
- The erratum is right. The proposal; below is wrong, both in its original assumption and suggested resolution. It must be firmly rejected.
- This arises from behaviour in the L_lost = true state, which is doing two things, recording the state as lost for a fixed period, but also retaining what the state is should the link quality recover.
- The erratum changes only the constraints, and to relax them. This is a safe change, it will not impact on any implementation. (The constraints are formally about what is allowed to be done by another process. Fundamentally they are class invariants of the information repository. The erratum essentially makes them match those invariants - which are also good for implementation testing - correctly.) That would not be true of anything changing section 14.

I would recommend to the poster that if he has a case that doesn't seem right, the sensible reaction would be something like "Allowing L_HEARD_time to be greater than L_time appears surprising, could you explain that?" rather than jumping in with a proposal that demonstrates a lack of understanding.

(I did incidentally work through a detailed case and checked with a couple of other NHDP/OLSrv2 authors I hadn't missed something before submitting this. Or in other words I followed a version of my own advice above.)

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Abdussalam Baryun
Sent: 07 July 2013 03:57
To: manet
Subject: Re: [manet] [Technical Errata Reported] RFC6130 (3677)

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

AB

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 13 Jul 2013 21:06:39 +0200

On 7/7/13, Christopher Dearlove <[email-masked]> wrote:

> Because of that, it can be greater than L_time, because we keep
> updating L_HEAD_time in case of restoration, but we don't keep updating
> L_time, because we only want to advertise the link as lost for a finite
> time.

L_HOLD_Time is the one for advertsing not L_time (i.e. is time period
for remove link-tuple).

> suggestion would break this.

is the *this issue* a requirement or applicability.

>
> Furthermore, modifying the constraints is painless. They only come into play
> when the internal state is modified by an external process. Mostly they can
> be ignored. But modifying the actual protocol is not painless. It is also
> not just unnecessary, but wrong.

the appendix B is mentioned in specification pages: 14, 17, 52, 53,
and 55. So I think it can be painfull to change as your errata is
doing. Only 52 and 53 are external process concerns not other pages.

I will do my rfc6130 implementation and make my comment into the IETF,
but busy with others. Was 6130 implementation discussed on the list
before, I don't think much, only announcements.

AB

---

From: Christopher Dearlove <[email-masked]>
Date: Sat, 13 Jul 2013 22:36:33 +0100

If you think the change is painful then you do not understand. It is not.

--  
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)