Subject: [manet] draft-ietf-manet-dymo-10 open questions

From: Christoph Sommer <[email-masked]>
Date: Fri, 03 Aug 2007 09:40:25 +0200

Hello All,

Updating a draft-06-implementation of DYMO to draft version 10, some 
points were not immediately clear to me after reading the latest 
specification.

In some cases, DYMO implementations interpreting the draft differently 
could lead to interoperability issues. But while most of the time, one 
alternative way of implementing DYMO is clearly superior to the other, I 
list these points anyway, as I might just have missed something.

4.2.2. Routing Messages (RM) - RREQ & RREP

Other than entries associated with "TargetNode" or "OrigNode", both of 
which have been defined in the section on terminology (as well as 
"AdditionalNode", which is explained later on), the list of elements 
associates entries with a generic entity called "Node".
If this intended as a superclass of TargetNode and OrigNode, 
Node.AddTLV.Dist is a duplicate of TargetNode.AddTLV.Dist. If it is not, 
OrigNode.AddTLV.Dist seems to be missing.
In any case, it would probably make things much clearer, if the complete 
set of properties was given for each of TargetNode, OrigNode and 
AdditionalNode.

Also, the list seems to be missing IP.SourceAddress, which is referenced 
in "5.2.2. Creating or Updating a Route Table Entry with New Routing", 
"5.5.2. Updating Route Lifetimes During Packet Forwarding" and "5.5.4. 
RERR Processing".

IP.SourceAddress is also missing in the list of section "4.2.3. Route 
Error (RERR)".

5.1.4. Actions After OwnSeqNum Loss

Should a node assume OwnSeqNum loss when starting up for the very first 
time?

5.3.1. RREQ Creation

The statement "If this DYMO router is performing route discovery on 
behalf of an attached node ... it MUST advertise it's address and prefix 
that contain the source address.", leaves it a bit unclear exactly which 
node’s address and prefix have to be advertised.

5.3.2. RREP Creation

This section should probably not be relevant to the case described in 
"5.3.3. Intermediate DYMO Router RREP Creation", because the requirement 
"If ... TargetNode.SeqNum from the RM is less than OwnSeqNum, OwnSeqNum 
SHOULD be incremented" doesn’t seem to make much sense if the TargetNode 
is not ThisNode.

Also, in the sentence "If ... TargetNode.SeqNum from the RM is less than 
OwnSeqNum, OwnSeqNum SHOULD be incremented", the comparison of SeqNums 
here should probably also be based on signed integer arithmetics, not 
just a comparison. Section "5.3.4. RM Processing" also uses "greater 
than" for comparison where signed integer arithmetics should make more 
sense.

It might prove beneficial to only once state that SeqNums are to be 
compared by the special method given later on, then only use the terms 
"newer" and "older" instead of "greater than" and "smaller than" in the 
remaining text.

5.3.3. Intermediate DYMO Router RREP Creation

The draft seems to be unclear about whether to increment OwnSeqNum when 
creating intermediate RREPs.

5.3.4. RM Processing

In this section, it is allowed that to a RREQ "ThisNode responds with a 
RREQ flood (a RREQ addressed to oneself) or a RREP to the RREQ 
OrigNode". If a node always chooses to start an RREQ flood rather than 
send a RREP, couldn't intermediate node RREP creation completely stop 
the RREQ flood from ever reaching the node that is searching for a route?

5.5.4. RERR Processing

Setting a Route.Broken flag here does not seem to trigger the 
ROUTE_DELETE timer to be started, which seems to be required in other 
cases.

Also, it might be beneficial to update UnreachableNode.SeqNum with more 
recent information during processing. The original RERR sender will 
often not know  UnreachableNode.SeqNum because it deleted the route, 
while a node relaying the RERR will probably still know about the SeqNum.

Also, after processing, MsgHdr.HopLimit should probably be decreased. 
This section does not seem to require this, but checks MsgHdr.HopLimit 
anyway.

Regards,

   Christoph

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Ian Chakeres" <[email-masked]>
Date: Thu, 16 Aug 2007 17:41:35 +0530

Christoph, thank you very much for the detailed comments. I've
integrated them into the xml and they will be included in the next ID
we submit.

Thanks.
Ian Chakeres

On 8/3/07, Christoph Sommer <[email-masked]> wrote:
> node's address and prefix have to be advertised.
>
>
> 5.3.2. RREP Creation
>
> SHOULD be incremented" doesn't seem to make much sense if the TargetNode
> is not ThisNode.
>