Subject: [manet] Review of draft-dearlove-manet-nhdp-olsrv2-tlv-extension-01

From: Ulrich Herberg <[email-masked]>
Date: Tue, 16 Jul 2013 14:56:54 -0700

Hi,

some comments on draft-dearlove-manet-nhdp-olsrv2-tlv-extension-01

- I think this is a good draft and important for extensibility of OLSRv2

- Section 4: It starts out with some descriptive text, and then the
normative "An implementation MUST NOT reject a message because it
contains such a TLV.". I had to go back in the descriptive text to get
the meaning of "such a TLV". I think it would be better to repeat
exactly which kind of TLV is meant in the normative part. Also, the
sentence "This specification removes that latitude:" confused me,
because actually the following sentence is not removed, but added.
Since this draft updates RFC6130 and OLSRv2, where exactly would that
be added in each of the drafts?

- "[RFC5444] defines a multi-value TLV"; the link is not active in the
html view.

- "(An implementation must still be able to recognize whatever pattern
of TLVs the sender chooses to use.)". Is that a normative must?

- paragraph starting with "It should be stressed that this is not a ".
At this point of reading the draft, I am not sure if that could not
cause an interoperability problem with non-updated implementations. If
I send a multi-value LINK-STATUS TLV with unknown values, what would
happen to a non-updated implementation? I think that is my major
comment about the draft, maybe add a section that summarizes
whether/how this new draft would affect interoperability with
implementations not using it (from what I understand, there would not
be any interop problems).

 - "any test of (for example) Value = 1 or Value = 3
   MUST be converted to a test of (for example) Value bitand 1 = 1,
   where "bitand" denotes a bitwise and operation."

Would that affect interoperability?

- Maybe add some example messages in the appendix, e.g., for multi-TLV
LINK_STATUS?

 Best regards
Ulrich

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 17 Jul 2013 09:08:46 +0000

Some comments >>> below.

-- 
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: Ulrich Herberg [mailto:[email-masked]] 
Sent: 16 July 2013 22:57
To: [email-masked]; Dearlove, Christopher (UK); Thomas Clausen
Subject: Review of draft-dearlove-manet-nhdp-olsrv2-tlv-extension-01

----------------------! 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.
--------------------------------------------------------

Hi,

>>> The purpose here is that this is an update to OLSRv2. A fully compliant
>>> will have to do what is described here. If an implementation is not
>>> updated then with regard to e.g. LINK_STATUS then it's not certain
>>> what will happen, it depends on what assumptions the implementer
>>> has made about e.g. LINK_STATUS = 42. That it can't happen and the
>>> whole message is rejected is a permitted possibility that this draft
>>> unpermits. Beyond that, we're in unknown territory. I think I would
>>> argue that - rejection aside - you should ignore LINK_STATUS = 42
>>> because you are told what to do if it is SYMMETRIC, HEARD, or LOST,
>>> but not otherwise, Except that (and I have not checked) there may
>>> be places in the protocol pseudo-code that  use "otherwise" implicitly
>>> assuming only those three cases exist. If anyone wants to do a rigorous
>>> trawl through the drafts to check this out, that could be useful.

>>> Note that (apart from the rejection)

>>> It could. But the purpose here is to force the change. At the moment
>>> there are few implementations of OLSRv2, and probably everyone with
>>> one is reading this. And very likely is already doing this. Let's not get
>>> ourselves trapped without thsi change.

>>> This is the sort of thing to be considered once we get this accepted.
>>> (I do however have some software that would make such examples
>>> relatively straightforward to create.)

 Best regards
Ulrich

********************************************************************
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.
********************************************************************