Subject: Re: [manet] I-D Action: draft-ietf-manet-aodvv2-05.txt

From: Justin Dean <[email-masked]>
Date: Mon, 10 Nov 2014 15:24:27 -0500

Having briefly looked over the updated draft, I've a few comments. This is
not meant to be a comprehensive review of the draft.

In no particular order.

The definition of Originating Node (OrigNode) (and TargNode) are self
referencing and incomplete.  They should at least reference AODVv2 Router.
Also the terms OrigNode and TargNode are later used as what seems like
addresses in an AODVv2 message.  I suggest separating the definition of a
node (an AODVv2 Router?) from an address of that node/router (suggest
OrigNodeAddr)

The term "invalid" is used a few times when a more specific reference to
the defined term "broken" and/or "expired" should be used.

In the "RteMsg Structure" section the list says that the OrigNode should be
included in the message header, the packet diagram doesn't include this
information as it doesn't expand the message header.  This would be fine
but then the OrigNode is then included again the address block which is
confusing.  Later it's described that OrigNode should indeed be included in
the address block but it happens after the diagram.  Also, is there a
reason the OrigNode is included twice?

It's not clear to me the difference between the states "broken" and
"expired" (other than how they reached that state)  They are both invalid
states and regardless of how the state was obtained the routes shouldn't be
used.  The only difference I could find is that "expired" routes MAY be
expunged while there is no such text regarding "broken" routes.  Broken is
also used in reference to broken link and later BrokenRoute without the
terms being defined in the document definitions.  It may make sense to
unify these states regardless of how they are obtained into a single term
and reduce the number of states a route can have (unless there is something
operationally different that should be done that I'm missing)

The addition of the "timed" state requires updating in a few other places
in the document when route state is referenced.  The "Route Table Entry
Timeouts" section for example may need to be updated.

Orig.Tail and Targ.Tail should be Orig.Mid and Targ.Mid as the tail term is
used for common bits of an address among the addresses listed.

Justin

On Mon, Oct 27, 2014 at 6:03 PM, <[email-masked]> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the Mobile Ad-hoc Networks Working Group of
> the IETF.
>
>         Title           : Dynamic MANET On-demand (AODVv2) Routing
>         Authors         : Charles E. Perkins
>                           Stan Ratliff
>                           John Dowdell
>         Filename        : draft-ietf-manet-aodvv2-05.txt
>         Pages           : 67
>         Date            : 2014-10-27
>
> Abstract:
>    The revised Ad Hoc On-demand Distance Vector (AODVv2) routing
>    protocol is intended for use by mobile routers in wireless, multihop
>    networks.  AODVv2 determines unicast routes among AODVv2 routers
>    within the network in an on-demand fashion, offering rapid
>    convergence in dynamic topologies.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-manet-aodvv2/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-manet-aodvv2-05
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-aodvv2-05
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 12 Nov 2014 19:37:49 -0800

Hello Justin,

Here are some answers to your questions...

On 11/10/2014 12:24 PM, Justin Dean wrote:
> referencing and incomplete.  They should at least reference AODVv2 
> Router. Also the terms OrigNode and TargNode are later used as what 
> seems like addresses in an AODVv2 message.  I suggest separating the 
> definition of a node (an AODVv2 Router?) from an address of that 
> node/router (suggest OrigNodeAddr)

A node can be a host or a router, and is a fundamental
networking object that can be used to define other
objects.  There are many instances where the two terms
OrigNode and TargNode are used, and I am sure that you
are right that OrigNodeAddr and TargNodeAddr is more
accurate.  Maybe, for brevity, should we use OrigAddr and
TargAddr?  We have tried as much as possible to avoid
using names that are too long and distracting.  If this is O.K.
we will make new terminology definitions, and review
whether OrigNode and TargNode are still needed.

I did not see which definitions were circular.

>
> The term "invalid" is used a few times when a more specific reference 
> to the defined term "broken" and/or "expired" should be used.

There are four instances of the word in the draft.
But, see (*) below...

>
> In the "RteMsg Structure" section the list says that the OrigNode 
> should be included in the message header, the packet diagram doesn't 
> include this information as it doesn't expand the message header.  
> This would be fine but then the OrigNode is then included again the 
> address block which is confusing.  Later it's described that OrigNode 
> should indeed be included in the address block but it happens after 
> the diagram.  Also, is there a reason the OrigNode is included twice?

That mistake has been there a very long time (since the time when
it was not a mistake, in fact).  That's the only instance of the term
<msg-orig-addr> in the draft, and once the requirement was placed
to include OrigNode in the AddrBlk, it no longer needed to be put
in as the <msg-orig-addr>.

> "expired" (other than how they reached that state)  They are both 
> invalid states and regardless of how the state was obtained the routes 
> shouldn't be used.  The only difference I could find is that "expired" 
> routes MAY be expunged while there is no such text regarding "broken" 
> routes.  Broken is also used in reference to broken link and later 
> BrokenRoute without the terms being defined in the document 
> definitions.  It may make sense to unify these states regardless of 
> how they are obtained into a single term and reduce the number of 
> states a route can have (unless there is something operationally 
> different that should be done that I'm missing)

Thanks for this observation.  After thinking about it for a
while, I have not remembered any significant differences
between the actual use of an expired route versus a broken
route.  How about if we combine the two states into a new
state called "invalid"?

An implementer or a network operator might want to know
why a route entered such a state for diagnostic purposes,
whether because of lack of traffic, a link breaking somewhere
or because the router was administratively configured to
forcibly make the route so, and I would recommend to
implementers that the reason for the route becoming this
state be logged. We could put in some text recommending
the logging of route table entry history for such purposes.

>
> The addition of the "timed" state requires updating in a few other 
> places in the document when route state is referenced.  The "Route 
> Table Entry Timeouts" section for example may need to be updated.

O.K. I'll re-read the section with that in mind and make
appropriate modifications.  If you notice other places please
point them out.

>
> Orig.Tail and Targ.Tail should be Orig.Mid and Targ.Mid as the tail 
> term is used for common bits of an address among the addresses listed.

So I guess it's O.K. to have addresses with a Head and a Mid
without a Tail?

Regards,
Charlie P.