Subject: [manet] <re-sending> Re: DYMO review

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 22 Oct 2012 08:17:54 -0700

Hello Ulrich,

Your comments are really in depth and much appreciated.
If I don't get to all of them before the submission deadline,
I will do so very soon afterwards.

On 7/28/2010 2:28 PM, Ulrich Herberg wrote:
> Hi,
>
> First, I'd like to apologize that until now I never had the time to
> review DYMO in detail. Here is my review of the -21 draft.
>
> Overall comments:
>   - The draft is very hard/complicated to read; I would have a hard time
> implementing it.

I hope that the new organization for the draft will help.
I have also tried to simplify some of the terminology.

>   - The protocol seems to be difficult to secure for end-to-end messages.

I will look for more specifics, but I don't think it's any
more difficult than AODV was.

>   - I have doubts about the correct usage of RFC5444 in the draft

This needs to be fixed ASAP.

>
>
>
> Detailed comments: (starting with "UH> ", always immediately following
> the concerned sentence or paragraph)
> ============
>
> <SNIP>
>
> 2.  Applicability Statement
>
>    The DYMO routing protocol is designed for stub or disconnected mobile
>
> UH> ================
> UH> What is a "disconnected MANET"? Disconnected from what? Are these
> UH> terms (stub / disconnected) defined anywhere?
> UH> ================

How about:

"stub (i.e., non-transit) or
       disconnected (i.e., from the Internet)"

>
>    ...
>    routing state is maintained in each DYMO router.  Only routing
>    information related to active sources and destinations is maintained,
>    in contrast to most proactive routing protocols that require routing
>    information to all routers within the routing region be maintained.
>
> UH> ================
> UH> Is "routing region" for the context of a MANET defined somewhere?
> UH> ================

No, and it is tricky to define.  But I know one when I see it.
More seriously, if you have a good definition, or replacement
term, I'd be happy to clarify this.

>
>    DYMO supports routers with multiple interfaces participating in the
>    MANET.  DYMO routers can also perform routing on behalf of other
>    nodes, attached via participating or non-participating interfaces.
>
> UH> ================
> UH> 1) The document mixes up node / router. Is there a difference? I
> UH> would prefer to talk about routers only.

Non-routing nodes are allowed to communicate with the assistance
of AODVv2 routers.  I will try to make this clearer and avoid
mix-ups.

> UH> 2) What is a participating vs. non-participating interface? Is
> UH> that defined somewhere?
> UH> ================

I have changed this, since I don't think the terminology helps at all.

>
>    DYMO routers perform route discovery to find a route to a particular
>    destination.  Therefore, DYMO routers MUST be configured to initiate
>    and respond to route discovery on behalf of certain nodes, identified
>    by address.
>
> UH> ================
> UH> A router may have several interfaces, each of which may have
> UH> several IP(v6) addresses. Which is the address that identifies a
> UH> router? (that applies at many places within the draft)
> UH> ================

If I see anyplace in the draft where this causes a problem in
the protocol, I'll try to fix it.  Right now I don't know of
any problem, though...

>
>    When DYMO is the only protocol interacting with the
>    forwarding table, DYMO MAY be configured to perform route discovery
>    for all unknown unicast destinations.
>
>    At any time within a DYMO routing region only one DYMO router SHOULD
>    be responsible for, i.e. "own", a particular address.
>
> UH> ================
> UH> Which address is that? Of the interface? Or is it a prefix that
> UH> this router may delegate to attached hosts? What does it mean, to
> UH> "own" an address? (any citation to an RFC?)
> UH> ================

The meaning is that, for any particular node that neighbors an
AODVv2 router such that the router is responsible for routing
packets to/from that node, only one such router is configured
for that purpose.

>
>    Coordination
>    among multiple DYMO routers to distribute routing information
>    correctly for a shared address (i.e. an address that is advertised
>    and can be reached via multiple DYMO routers) is not described in
>    this document.  The router behavior for shifting responsibility for
>    an address from one DYMO router to another are described in
>    Appendix A.
>
> UH> ================
> UH> This whole previous section is unclear. Not sure it belongs in the spec
> UH> ================

Actually, I am agreeable to delete this paragraph, and Appendix A.
However, it is a valuable feature to enable non-AODVv2 nodes to
rely on particular AODVv2 routers for their connectivity in a MANET.

>
>    DYMO MUST only utilizes bidirectional links.  In the case of possible
>    unidirectional links, either blacklists ( see Section 7.2) or other
>    means (e.g. adjacency establishment with only neighboring routers
>    that have bidirectional communication as indicated by NHDP
>    [I-D.ietf-manet-nhdp]) of ensuring and monitoring bi-directionality
>    SHOULD be used.  Otherwise, persistent packet loss may occur.
>
> UH> ================
> UH> Not clear how NHDP interoperates with DYMO (in particular using
> UH> several DYMO processes on the same router)
> UH> ================

If NHDP establishes neighborhood information, then AODVv2 could
presumably make use of that information as needed.  I don't remember
why one would need several AODVv2 processes on the same router,
but if that happens, then presumably they would be configured to
operate over separate network interfaces.  Does that cause any
conflict with the way NHDP operates over several interfaces?

>
>
>    The routing algorithm in DYMO may be operated at layers other than
>    the network layer, using layer-appropriate addresses.  For operation
>    at other layers DYMO's routing algorithm likely will not need to
>    change.  Although, modification of the packet/message format may be
>    required.
>
> UH> ================
> UH> I did not understand this previous section. It seems that
> UH> the whole draft is based on IP/UDP only.
> UH> ================

Well, if you change to a new layer and packet header, then
you presumably aren't using the same IP protocol or UDP port.
To my understanding, AODVv2 is really just specified for IP
and UDP.

> 3.  Terminology
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].
>
>
>
> Chakeres & Perkins      Expires January 27, 2011                [Page 5]
>
> Internet-Draft                    DYMO                         July 2010
>
>
>    Additionally, this document uses some terminology from [RFC5444].
>
> UH> ================
> UH> Which terminology of RFC5444 is used? "some" is imprecise.
> UH> ================

At some point after tomorrow I can try to make this more precise.

>
>    This document defines the following terminology:
>
>    Adjacency
>       A relationship between selected bi-directional neighboring routers
>       for the purpose of exchanging routing information.  Not every pair
>       of neighboring routers become adjacent.  Neighboring routers may
>       form an adjacency based several different pieces of information or
>       protocols; for example, exchange of DYMO routing messages, other
>       protocols (e.g.  NDP [RFC4861] or NHDP [I-D.ietf-manet-nhdp]), or
>       manual configuration.  Similarly, loss of a routing adjacency may
>       also be based upon several pieces of information, and monitoring
>       of adjacencies where packets are being forwarded is required (see
>       Section 5.5.1).
>
> UH> ================
> UH> This is only used in section 5.5.1. Seems to be unnecessary to
> UH> define it for the whole document.
> UH> ================

Point noted.

>
>    Distance (Dist)
>       A metric of the distance a message or piece of information has
>       traversed.  The minimum value of distance is the number of IP hops
>       traversed.  The maximum value is 65,535.
>
> UH> ================
> UH> What metrics is the distance based on? Only Hop count? Can that
> UH> be more than 255 (in IP networks)?
> UH> ================

No, the hop count shouldn't be more than 255.

>
>    DYMO Identifier (DID)
>       A DID is maintained for each DYMO routing process (ThisNode.DID),
>       and the default value is zero (0).  Each routing message is tagged
>       with its associated DID (MsgTLV.DID), unless zero (0).  Upon
>       receipt of DYMO protocol message a DYMO routing protocol process
>       SHOULD only attend to messages with a matching DID value.
>
> UH> ================
> UH> Using DID is unclear to me. How does a router process know which
> UH> DID it runs? Often, in the spec. it is unclear whether the "DYMO
> UH> router" or the "DYMO routing process" does something (see later in my
> UH> comments for examples). How do the different routing processes
> UH> interact? If NHDP is used, is there a single NHDP instance per process
> UH> or per router?
> UH> ================

I think this matter of DID was an attempt to get a unique identifier
for an AODVv2 router even if the router had several network interfaces
and IP addresses.  I am hoping that it is O.K. for me to have deleted
the DID parts of the specification.  I will put them back if needed.

>
>    DYMO Sequence Number (SeqNum)
>       A DYMO Sequence Number is maintained by each DYMO router process.
>       This sequence number is used by other DYMO routers to identify the
>       temporal order of routing information generated and ensure loop-
>       free routes.
>
> UH> ================
> UH> Sometimes confusing whether the seqnum is used per router or per
> UH> router process. That's not consistent in the spec.
> UH> ================

Maybe it would be better to just have one AODVv2 process per
AODVv2 router.  If, in the future, it is required to support
virtual routers we could go back and re-think the matter of
which data can be shared between virtual router processes.

>
>    Forwarding Route
>       A route that is used to forward data packets.  Forwarding routes
>       are generally maintained in a forwarding information base (FIB) or
>       the kernel forwarding/routing table.
>
>    Multihop-capable Unicast IP Address
>       A multihop-capable unicast IP address is a unicast IP address that
>       when put into the IP.SourceAddress or IP.DestinationAddress field
>       is scoped sufficiently to be forwarded by a router.  For example,
>       site-scoped or globally-scoped unicast IP addresses.
>
> UH> ================
> UH> Site-scoped is deprecated. Unclear previous section. Is that term
> UH> defined in some other RFC? IP.SourceAddress and
> UH> IP.DestinationAddress have not been defined until this
> UH> point in the spec (comes only later)
> UH> ================

Circular definitions are nasty, agreed.  I am in favor of eliminating
the "multihop-capable" terminology anyway, since I'm not sure why it
would be different in meaning than a "routable address", at least
within the context of AODVv2.

>    Originating Node (OrigNode)
>       The originating node is the source, its DYMO router creates a DYMO
>       control message on its behalf in an effort to disseminate some
>       routing information.  The originating node is also referred to as
>       a particular message's originator.
>
> UH> ================
> UH> What is the difference to ThisNode?
> UH> ================

ThisNode is the node handling a message, perhaps soon to retransmit
the message.  OrigNode is the node which "originated" the message.

>
>    Route Error (RERR)
>       A RERR message is used to indicate that a DYMO router does not
>       have a forwarding route to one or more particular addresses.
>
>    Route Reply (RREP)
>       A RREP message is used to disseminate routing information about
>       the RREP OrigNode to the RREP TargetNode and the DYMO routers
>       between them.
>
> UH> ================
> UH> TargetNode not yet defined
> UH> ================

I changed the order, but now it's not alphabetical ( :-(  ).

>
>    Route Request (RREQ)
>       A RREQ message is issued to discover a valid route to a particular
>       destination address, called the RREQ TargetNode.  When a DYMO
>       router processes a RREQ, it learns routing information on how to
>       reach the RREQ OrigNode.
>
>    Target Node (TargetNode)
>       The TargetNode is the ultimate destination of a message.
>
>    This Node (ThisNode)
>       ThisNode corresponds to the DYMO router process currently
>       performing a calculation or attending to a message.
>
>    Type-Length-Value structure (TLV)
>       A generic way to represent information, please see [RFC5444] for
>       additional information.
>
>    Unreachable Node (UnreachableNode)
>       An UnreachableNode is a node for which a forwarding route does not
>       exist.
>
>
> 4.  Data Structures
>
> 4.1.  Route Table Entry
>
>    The route table entry is a conceptual data structure.
>    Implementations may use any internal representation that conforms to
>    the semantics of a route as specified in this document.
>
>    Conceptually, a route table entry has the following fields:
>
>
>
>
>
> Chakeres & Perkins      Expires January 27, 2011                [Page 7]
>
> Internet-Draft                    DYMO                         July 2010
>
>
>    Route.Address
>       The (host or network) destination address of the node(s)
>       associated with the routing table entry.
>
> UH> ================
> UH> Interface address? Originator address? Including prefix notation
> UH> or just the address(es)?
> UH> ================

This is supposed to be like a generic route table entry.
So it is an IP address of the destination.  That's often
not the next hop, or the outgoing interface.

>
>
>    Route.Prefix
>       Indicates that the associated address is a network address, rather
>       than a host address.  The value is the length of the netmask/
>       prefix.
>
> UH> ================
> UH> So what is the value for a host entry? (32 or 128)?
> UH> ================

Yes.

>
>    Route.SeqNum
>       The DYMO SeqNum associated with this routing information.
>
>    Route.NextHopAddress
>       The IP address of the adjacent DYMO router on the path toward the
>       Route.Address.
>
>    Route.NextHopInterface
>       The interface used to send packets toward the Route.Address.
>
>    Route.Forwarding
>       A flag indicating whether this Route can be used for forwarding
>       data packets.  This flag MAY be provided for management and
>       monitoring.
>
> UH> ================
> UH> Purpose of the Forwarding flag is unclear
> UH> ================

I eliminated it, because it's practically the opposite of Route.Broken
except in case some administrative agent intervened to temporarily
disable a forwarding entry.  In an ad hoc network that seems very
unlikely, and I don't remember any discussion in the working group
to motivate such an administrative feature.

>
>    Route.Broken
>       A flag indicating whether this Route is broken.  This flag is set
>       to true if the next-hop becomes unreachable or in response to
>       attending to a RERR (see Section 5.5.4).
>
>    The following field is optional:
>
>    Route.Dist
>       A dimensionless metric indicating the distance traversed before
>       reaching the Route.Address node.
>
>    Not including optional information may cause performance degradation,
>    but it will not cause the protocol to operate incorrectly.
>
> UH> ================
> UH> Having optional fields sounds dangerous in a database.
> UH> ================

I need to study this matter much more closely.  I think it will
be better to have all mandatory fields but with default values.
Plus, AODVv2 needs to be enabled to use other route metrics, now
that the specification exists for that.

>
>
>    In addition to a route table data structure, each route table entry
>    may have several timers associated with the information.  These
>    timers/timeouts are discussed in Section 5.2.3.
>
> 4.2.  DYMO Messages
>
>    When describing DYMO protocol messages, it is necessary to refer to
>    fields in several distinct parts of the overall packet.  These
>    locations include the IP header, the UDP header, and fields from
>    [RFC5444].
>
> UH> ================
> UH> Until now, no mentioning whether the protocol runs on UDP/IP
> UH> (which version of IP? The spec never says that it both supports IPv4
> UH> and IPv6 (or I haven't seen it)). Is DYMO limited to run on IP?
> UH> ================

AODVv2 as specified in the current document is limited to run on IP
(or UDP).  There is text in the current draft specifying that both
address families are supported.

>
> This document uses the following notation conventions.
>
>
>
> Chakeres & Perkins      Expires January 27, 2011                [Page 8]
>
> Internet-Draft                    DYMO                         July 2010
>
>
>    Information found in the table.
>
>              +---------------------------+-------------------+
>              |    Information Location   | Notational Prefix |
>              +---------------------------+-------------------+
>              |         IP header         |        IP.        |
>              |         UDP header        |        UDP.       |
>              |   RFC5444 message header  |      MsgHdr.      |
>              |    RFC5444 message TLV    |      MsgTLV.      |
>              |   RFC5444 address blocks  |      AddBlk.      |
>              | RFC5444 address block TLV |      AddTLV.      |
>              +---------------------------+-------------------+
>
>                                   Table 1
>
> UH> ================
> UH> This table and the hierarchical notation which is used in the
> UH> following section is unclear
> UH> ================

I'll look for more guidance about how to make it clearer, and
also see if I can think of a way to improve the presentation.
Right now I do not have a good idea about it, but I am really
open to suggestion.

>
> 4.2.1.  Generalized Packet and Message Structure
>
>    DYMO messages conform to the generalized packet and message format as
>    described in [RFC5444].  Here is a brief description of the format.
>    A packet is made up of messages.
> UH> ================
> UH> Imprecise (and no a scientific language style, "made up of
> UH> messages").  Rather something like "A packet formatted according to
> UH> RFC5444 contains zero or more messages"
> UH> ================

Thanks, I used that text.

>
>    A message is made up of a message
>    header, message TLV block, and zero or more address blocks.
> UH> ================
> UH> Same comment as the previous one
> UH> ================

Also fixed.

>
>    Each of
>    the address blocks may also have an associated address TLV block.
>
>    For interoperability with other DYMO routers, all DYMO messages
>    specified in this document SHOULD sent using the IP protocol number
>    (138) reserved for manet protocols [RFC5498]; or the UDP destination
>    port (269) reserved for manet protocols [RFC5498] and IP protocol
>    number for UDP.
>
> UH> ================
> UH> I would not include the protocol/port numbers here. Citation is enough.
> UH> ================

I left the numbers there for now.  Isn't there some value in having
the numbers handy?  I don't think there is much downside to doing so.

>
>    Most DYMO messages are sent with the IP destination address set to
>    the link-local multicast address LL-MANET-Routers [RFC5498] unless
>    otherwise stated.  Therefore, all DYMO routers SHOULD subscribe to
>    LL-MANET-Routers [RFC5498] for receiving control packets.  Note that
>    multicast packets MAY be sent via unicast.  For example, this may
>    occur for certain link-types (non broadcast mediums), improved
>    robustness, or manually configured router adjacencies.
>
>    Unicast DYMO messages (e.g.  RREP) unless otherwise specified in this
>    document are sent with the IP destination set to the
>    Route.NextHopAddress of the route to the TargetNode.
>
> UH> ================
> UH> How would a router send a unicast RREQ? It would need to know at
> UH> least one IP address per adjacent neighbor. This assumption is never
> UH> specified.
> UH> ================

I think the intention is to use multicast in the typical case, but
still to allow the use of unicast for cases when an AODVv2 router
does happen to have additional information enabling that use case.
I reckon you are aware of some use cases for this; there were some
papers published out of UC Santa Cruz about it years back.

>
>    The IPv4 TTL (IPv6 Hop Limit) field for all packets containing DYMO
>    messages is set to 255.  If a packet is received with a value other
>    than 255, it is discarded.  This mechanism helps to ensures that
>    packets have not passed through any intermediate routers
>
> UH> ================
> UH> 1) That sounds wrong (mixing RFC5444 packet and IP datagram in the
> UH> first sentence). The (RFC5444) packet does not contain an IPv4
> UH> TTL/IPv6 Hop Limit.
> UH> 2) You cannot discard a (RFC5444) packet (maybe "ignore it"). It
> UH> may contain messages intended for other processes (like NHDP/OLSRv2).
> UH> ================

I changed the specification so that any such message is
ignored by AODVv2.  Thanks for catching this!

> ...
>    The aggregation of multiple messages into a packet is not specified
>    in this document, but if aggregation does occur the IP.SourceAddress
>    and IP.DestinationAddress of all contained messages MUST be the same.
>
> UH> ================
> UH> I don't understand. The contained messages do not have any IP
> UH> header fields. Also, isn't the IP.SourceAddress always the originator
> UH> address of the router or one IP address of the interface the packet is
> UH> sent from? (unclear from the spec)
> UH> ================

IP.SourceAddress should always be the address in the IP header.

>
>    Implementations MAY choose to temporarily delay transmission of
>    messages for the purpose of aggregation (into a single packet) or to
>    improve performance by using jitter [RFC5148].
>
> UH> ================
> UH> Unclear how jitter is applied in the whole spec.
> UH> ================

Doesn't RFC 5148 specify that?

>
>    DYMO control packets SHOULD be given priority queuing and channel
>    access.
>
> UH> ================
> UH> Does that apply to "packet" as in RFC5444 or in IP datagram?
> UH> ================

Here, it means IP datagram.  I tried to make this clearer.

>
> 4.2.2.  Routing Messages (RM) - RREQ & RREP
>
>    Routing Messages (RMs) are used to disseminate routing information.
>    There are two DYMO message types that are considered to be routing
>    messages (RMs): RREQ and RREP.  They contain very similar information
>    and function, but have slightly different handling rules.  The main
>    difference between the two messages is that RREQ messages generally
>    solicit a RREP, whereas a RREP is the response to RREQ.
>
>    RM creation and handling are described in Section 5.3.
>
>    A RM requires the following information:
>
>    IP.SourceAddress
>       The IP address of the node currently sending this packet.
> UH> ================
> UH> Which IP address?
> UH> ================

Are you asking about what happens if an AODVv2 router has several
IP addresses?

>
>      This
>       field is generally filled automatically by the operating system
>       and should not require special handling.
>
>    IP.DestinationAddress
>       The IP address of the packet destination.  For multicast RREQ the
>       IP.DestinationAddress is set to LL-MANET-Routers [RFC5498].  For
>       unicast RREP the IP.DestinationAddress is set to the
>       NextHopAddress toward the RREP TargetNode.
>
>    IP.ProtocolNumber and UDP.DestinationPort
>       The IP Protocol Number 138 (manet) has been reserved for MANET
>       protocols [RFC5498].  In addition to using this IP protocol
>       number, DYMO may use the UDP port 269 (manet) [RFC5498] in
>       conjunction with the IP Protocol Number 17 (UDP).
>
>
> UH> ================
> UH> Mentioning IP fields here seems to be mixing up RFC5444-layer and IP-layer
> UH> ================

The hope is that even when using RFC 5444, the IP address fields
will retain their usefulness.  Are you suggesting that the IP
header field information should be replicated as RFC 5444 fields?

>
>    MsgHdr.HopLimit
>       The remaining number of hops this message is allowed to traverse.
>
> UH> ================
> UH> What about the other msg headers? MUST/SHOULD/MAY they be contained?
> UH> ================

If an AODVv2 message has exhausted its hop limit, then it should
be removed from the packet.

>
>
>
> Chakeres & Perkins      Expires January 27, 2011               [Page 10]
>
> Internet-Draft                    DYMO                         July 2010
>
>
>    AddBlk.TargetNode.Address
> UH> ================
> UH> This hierarchical notation has never been defined.
> UH> ================

It was supposed to be somewhat intuitive.  I'll formulate
a way to fix this problem.

>
>       The IP address of the message TargetNode.  In a RREQ the
>       TargetNode is the destination address for which route discovery is
>       being performed.  In a RREP the TargetNode is the RREQ OrigNode
>       address.  The TargetNode address is the first address in a routing
>       message.
>
> UH> ================
> UH> The first address? So my (imaginary) routing protocol extension
> UH> cannot add addresses at will (at any position), as it is possible in
> UH> RFC5444? I would associate a TLV with it to guarantee extensibility of
> UH> the protocol.
> UH> What if there are several address blocks? First address if the
> UH> first address block?
> UH> ================

This is the way DYMO did initially make the design.  In order to
realize the full functionality you suggest, I believe a new
type of address block will have to be allocated, that otherwise
has the same features as the existing address block.

>
>    AddBlk.OrigNode.Address
>       The IP address of the originator and its associated prefix length.
>       In a RREQ the OrigNode is the source's address and prefix.
> UH> ================
> UH> Unclear.. prefix or address seems to be mixed here and throughout the spec
> UH> ================

Will try to make that clear.

>
>
>       In a
>       RREP the OrigNode is the RREQ TargetNode's address and prefix for
>       which a RREP is being generated.  This address is the second
>       address in the message for RREQ.
>
>    OrigNode.AddTLV.SeqNum
>       The DYMO sequence number of the originator's DYMO router.
> UH> ================
> UH> DYMO router or router process?
> UH> ================

This is the same confusion as you have noted previously.

>
>    A RM may optionally include the following information:
>
>    TargetNode.AddTLV.SeqNum
>       The last known DYMO sequence number of the TargetNode.
>
>    TargetNode.AddTLV.Dist
>       The last known Distance to the TargetNode.
>
>    AddBlk.AdditionalNode.Address
>       The IP address of an additional node that can be reached via the
>       DYMO router adding this information.  Each AdditionalNode.Address
>       MUST include its prefix.  Each AdditionalNode.Address MUST also
>       have an associated Node.SeqNum in the address TLV block.
> UH> ================
> UH> Never defined before what an AdditionalNode is. Which address is that?
> UH> ================

An AdditionalNode is a node other than the first node address as you
discussed earlier.

Functionality for AdditionalNode insertion has been moved into the
section for Optional Features of AODVv2.

>
>    AdditionalNode.AddTLV.SeqNum
>       The DYMO sequence number associated with this routing information.
>
>    OrigNode.AddTLV.Dist
>       A metric of the distance to reach the associated OrigNode.Address.
>       This field is incremented by at least one at each intermediate
>       DYMO router.
>
>    AdditionalNode.AddTLV.Dist
>       A metric of the distance to reach the associated
>       AdditionalNode.Address.  This field is incremented by at least one
>       at each intermediate DYMO router.
>
>    Example IPv4 RREQ
> UH> ================
> UH> I don't know which fields are mandatory, which are optional. The
> UH> example could be moved into the appendix.
> UH> ================

When I inherited the document, these examples were commented
out.  I need to proofread them according to whatever has been
changed in the meantime.  Anyway, the optional fields and
the mandatory fields must be clearly specified.
...
> 4.2.3.  Route Error (RERR)
>
>    A RERR message is used to disseminate the information that a route is
>    not available for one or more particular addresses.
> UH> ================
> UH> Unclear sentence. For which addresses?
> UH> ================

I have added text for this.

>
>    RERR creation and handling are described in Section 5.5.
>
>    A RERR requires the following information:
>
>    IP.SourceAddress
>       The IP address of the DYMO router that sent this packet.
> UH> ================
> UH> Which address? Interface address (if so, which address if several
> UH> iface addresses are used?)
> UH> ================

Unless I am missing something, this would be the IP address of
the sender.

>
>       This
>       field is generally filled automatically by the operating system
>       and should not require special handling.
>
>    IP.DestinationAddress
>       For multicast RERR messages, The IP address is set to LL-MANET-
>       Routers [RFC5498].  For unicast RERR messages, the IP address is
>       set to the NextHopAddress.
>
>    IP.ProtocolNumber and UDP.DestinationPort
>       The IP Protocol Number 138 (manet) has been reserved for MANET
>       protocols [RFC5498].  In addition to using this IP protocol
>       number, DYMO may use the UDP port 269 (manet) [RFC5498] in
>       conjunction with the IP Protocol Number 17 (UDP).
>
>    MsgHdr.HopLimit
>       The remaining number of hops this message is allowed to traverse.
>
>    AddBlk.UnreachableNode.Address
>       The address of an UnreachableNode and its associated prefix
>       length.
> UH> ================
> UH> Which address? Originator?
> UH> ================

This is supposed to be the IP address of the destination that's no
longer reachable.  I have clarified that in several places.

> ...

> 5.  Detailed Operation
>
> 5.1.  DYMO Sequence Numbers
> UH> ================
> UH> This whole section is unclear. Why start with the sequence
> numbers? There is no motivation why sequence numbers are important in
> the beginning of the section.
> UH> ================
>
>    DYMO sequence numbers allow DYMO routers to judge the freshness of
>    routing information and ensure loop freedom.

Well, one has to start somewhere, and sequence number operation was
really the main innovation of AODV compared to previous distance-vector
routing approaches (well, that plus on-demand operation).

I'd be very happy to get suggestions for improvement though.
Where would be a better place to put this?

>
> 5.1.1.  Maintaining A Node's Own Sequence Number
>
>    DYMO requires that each DYMO router in the network maintain its own
>    DYMO sequence number (OwnSeqNum) on behalf of the addresses for which
>    it is responsible.
>
> UH> ================
> UH> Sequence number per router or router process? The "on behalf of
> UH> the addresses" part is unclear.
> UH> ================

It seems pointless to discuss the "other addresses" here, so
I deleted that phrase.

>
>    OwnSeqNum a 16-bit unsigned integer.  The
>    circumstances for ThisNode to increment its OwnSeqNum are described
>    in Section 5.3.
>
> 5.1.2.  Numerical Operations on OwnSeqNum
>
>    When ThisNode increments its OwnSeqNum it MUST do so by treating the
>    sequence number value as an unsigned number.
> UH> ================
> UH> This sentence is redundant with the second sentence of section 5.1.1
> UH> ================

Good point.  I have deleted the redundant sentence.  Part of my purpose
is to get rid of redundancy, since it really does make the specification
more difficult to read, and way more tedious.

>
> 5.1.3.  OwnSeqNum Rollover
>
>    Incrementing an OwnSeqNum whose value is the largest largest possible
>    number representable as a 16-bit unsigned integer (i.e., 65,535),
>    SHOULD be set to one (1).  In other words, the sequence number after
>    65,535 is 1.
>
> 5.1.4.  Actions After OwnSeqNum Loss
>
>    A DYMO router SHOULD maintain its sequence number in persistent
>    storage.
>
>    If a DYMO router's OwnSeqNum is lost
> UH> ================
> UH> How can a sequence number be lost?
> UH> ================

Power fail, basically.

>
>
>    , it MUST take certain actions to
>    avoid creating routing loops.  To prevent this possibility after
>    OwnSeqNum loss a DYMO router MUST wait for at least
>    ROUTE_DELETE_TIMEOUT before fully participating
> UH> ================
> UH> What does that mean, "fully participate"? What is the opposite then?
> UH> ================

I got rid of that terminology also.

>
>    in the DYMO routing
>    protocol.  If a DYMO control message is received during this waiting
>    period, the DYMO router SHOULD handle it normally
> UH> ================
> UH> What does "handle it normally" mean?
> UH> ================

It means to update relevant route table entries.

> 5.2.  DYMO Routing Table Operations
>
> 5.2.1.  Judging Routing Information's Usefulness
>
>    Given a route table entry (Route.SeqNum, Route.Dist, and
>    Route.Broken) and new incoming routing information for a particular
>    node in a RM (Node.SeqNum, Node.Dist, and RM message type - RREQ/
>    RREP), the quality of the new routing information is evaluated to
>    determine its usefulness.  Incoming routing information is classified
>    as follows:
>
>    1. Stale
>       If Node.SeqNum - Route.SeqNum < 0 (using signed 16-bit arithmetic)
>       the incoming information is stale.  Using stale routing
>       information is not allowed, since doing so might result in routing
>       loops.
>
>       (Node.SeqNum - Route.SeqNum < 0)
>           using signed 16-bit arithmetic
>
> UH> ================
> UH> "using signed 16-bit arithmetic" is unclear. Better cite RFC or
> UH> explain wrap-around of sequence numbers.
> UH> ================

I have reformulated this.  But do you really think it's unclear?
Most computer programming courses teach about signed arithmetic,
don't they?

>
>    2. Loop-possible
>       If Node.SeqNum == Route.SeqNum the incoming information may cause
>       loops if used; in this case additional information MUST be
>       examined.  If Route.Dist or Node.Dist is unknown or zero (0), then
>       the routing information is loop-possible.  If Node.Dist >
>       Route.Dist + 1, then the routing information is loop-possible.
>       Using loop-possible routing information is not allowed, otherwise
>       routing loops may be formed.
>
>       (Node.SeqNum == Route.SeqNum) AND
>       ((Node.Dist is unknown) OR
>        (Route.Dist is unknown) OR
>        (Node.Dist > Route.Dist + 1))
> UH> ================
> UH> What is this pseudocode for? Unclear when and where to use it.
> UH> ================
>
>    3. Inferior or equivalent
>       In case of known equal SeqNum, the information is inferior in
>       multiple cases:
> UH> ================
> UH> That sentence sounds strange: "inferior/superior information". How
> UH> can information (=data with semantics) be inferior?
> UH> ================

I agree that the language used sounds unnatural.  I have made many
changes to this section that I hope will resolve this problem.

>    4. Superior
>       Incoming routing information that does not match any of the above
>       criteria is loop-free and better than the information existing in
>       the routing table.  Information is always superior if Node.SeqNum
>       - Route.SeqNum > 0 (using signed 16-bit arithmetic).  In the case
>       of equal sequence numbers, the information is superior in multiple
>       cases: (case i) if Node.Dist < Route.Dist; (case ii) if Node.Dist
>       == Route.Dist + 1 AND Route.Broken == true (a broken route is
>       being repaired); (case iii) if Node.Dist == Route.Dist AND it is a
>       RREP (RREP with equal distance are forwarded) OR Route.Broken ==
>       true (a broken route is being repaired).  For completeness, we
>       provide the following (optimized) pseudo-code.
> UH> ================
> UH> Why "optimized" pseudo-code? What is optimized?
> UH> ================

I eliminated that.  It certainly was not clear.

>    If a previous value of the TargetNode.SeqNum is known (from a routing
>    table entry using longest-prefix matching), it SHOULD be placed in
>    TargetNode.AddTLV.SeqNum in all but the last RREQ attempt.  If a
>    TargetNode.SeqNum is not included, it is assumed to be unknown by
>    handling nodes.  This operation ensures that no intermediate DYMO
>    routers reply, and ensures that the TargetNode's DYMO router
>    increments its sequence number.
>
>    Next, the node adds
> UH> ================
> UH> Which node? "the"...
> UH> ================
>
>    AddBlk.OrigNode.Address, its prefix, and the
>    OrigNode.AddTLV.SeqNum (OwnSeqNum) to the RM.
>
>    The OrigNode.Address is the address of the source for which this DYMO
>    router is initiating this route discovery.  The OrigNode.Address MUST
>    be a unicast address.  This information will be used by nodes to
>    create a route toward the OrigNode, enabling delivery of a RREP, and
>    eventually used for proper forwarding of data packets.
>
>    If OrigNode.Dist is included it is set to a number greater than zero
>    (0).
>
> UH> ================
> UH> Which exact value does the router put into that field?
> UH> ================

This might be used when OrigNode is more than one hop away from
the AODVv2 router (ThisNode) creating the RREQ.  It might be
considered an optional feature.

>
>    The IP.DestinationAddress for multicast RREQ is set to LL-MANET-
>    Routers.  For links that do not support multicast or situations in
>    which unicast messaging is preferred, the IP.DestinationAddress for
>    unicast RREQ is set to the NextHopAddress.
> UH> ================
> UH> Where does the router (or router process?) get the NextHopAddress
> UH> from in an initial RREQ? From NHDP?
> UH> ================

Here, the idea for unicast RREQ is that ThisNode has some information
available to it that would enable unicast to be used beneficially.

> 5.3.2.  RREP Creation
>
>    First, the AddBlk.TargetNode.Address is added to the RREP.  The
>    TargetNode is the ultimate destination of this RREP; the RREQ
>    OrigNode.Address.
>
>    Next, AddBlk.OrigNode.Address and prefix are added to the RREP.  The
>    AddBlk.OrigNode.Address is the RREQ TargetNode.Address.  The
>    AddBlk.OrigNode.Address MUST be a unicast IP address.  ThisNode
>    SHOULD advertise the largest known prefix containing
>    AddBlk.OrigNode.Address.
> UH> ================
> UH> "advertise" where?
> UH> ================

I think "advertise" simply means "include".

...
>
> 5.3.3.  Intermediate DYMO Router RREP Creation
>
>    Sometimes a DYMO router other than the TargetNode's DYMO router (call
>    it an "intermediate DYMO router") has routing information that can
>    satisfy an incoming RREQ.  An intermediate DYMO router can issue a
>    intermediate DYMO router RREP on behalf of the TargetNode's DYMO
>    router.
> UH> ================
> UH> That makes any end-to-end security of control messages tricky.
> UH> ================

This feature was pulled out of AODVv2 previous to IETF 83.  However,
your point is well taken.  It would appropriate to specify that
when end-to-end security is required, an intermediate node is not
allowed respond unless it can satisfy the security requirement.

> 5.3.4.  RM Handling
> UH> ================
> UH> This whole section 5.3.4. is extremely long and complicate to
> UH> read. I suggest to better structure in a pseudo-code manner:
> UH>   e.g.    1) If BLA then
> UH>                    doFoo
> UH>              2) otherwise....
> UH> ================

Thanks for this suggestion.  If I don't get to work on this before
the draft submission deadline tomorrow, I will do it soon afterwards.

>    For each address (except the TargetNode) in the RM that includes
>    AddTLV.Dist information, the AddTLV.Dist information MAY be
>    incremented.  If the resulting Distance value for the OrigNode is
>    greater than 65,535, the message is discarded.  If the resulting
>    Distance value for another node is greater than 65,535, the
>    associated address and its information are removed from the RM.  The
>    updated Distance value will influence judgment of the routing
>    information (Section 5.2.1).
> UH> ================
> UH> Can the distance be > 255?
> UH> ================

As far as I know, the distance cannot be more than 255.

In fact, in practice I doubt it could be more than 100.

>
>
>    After handling the OrigNode's routing information, then each address
>    that is not the TargetNode MAY be considered for creating and
>    updating routes.  Creating and updating routes to other nodes can
>
>
>
> Chakeres & Perkins      Expires January 27, 2011               [Page 22]
>
> Internet-Draft                    DYMO                         July 2010
>
>
>    eliminate RREQ for those IP destinations, in the event that data
>    needs to be forwarded to the IP destination(s) now or in the near
>    future.
>
>    For each of the additional addresses considered, ThisNode first
>    checks the that the address is a multihop-capable unicast address.
>    If the address is not a unicast address, the address and all related
>    information MUST be removed.
> UH> ================
> UH> Makes end-to-end security impossible
> UH> ================

Well, not necessarily, but it does make the design a little
more challenging.

>    For added addresses (and their prefixes) not controlled by this DYMO
>    router, Route.Dist can be included if known.  If Route.Dist is not
>    known, it MUST NOT be included.
>
>    The VALIDITY_TIME of routing information for appended address(es)
>    MUST be included, to inform routers about when to delete this
>    information.  The VALIDITY_TIME TLV is defined in Section 7.3.
> UH> ================
> UH> What is the default value of VALIDITY_TIME?
> UH> ================

It is listed as 1, but I think that is way too short.

>    To reduce congestion in a network, repeated attempts at route
>    discovery for a particular TargetNode SHOULD utilize an exponential
>    backoff.
> UH> ================
> UH> Is there any jitter involved? The exp. backoff is not exactly
> UH> specified, just explained with an example.
> UH> ================

I specified binary exponential backoff, which is pretty well
understood so that additional specification isn't needed.
I removed the example since as far as I can tell it does not
really add to one's understanding.

>    If a route discovery attempt has failed (i.e. an attempt or multiple
>    attempts have been made without receiving a RREP) to find a route to
>    the TargetNode, any data packets buffered for the corresponding
>    TargetNode are dropped and a Destination Unreachable ICMP message
>    SHOULD be delivered to the source.
> UH> ================
> UH> What parameters are set in the ICMP message (e.g. which code?) On
> UH> which interface(s) is the ICMP sent?
> UH> ================

The code is 1 (Host unreachable error).  The ICMP is sent over
the interface from which the source sent the packet to the AODVv2
router.  Thanks for catching this!

>
> 5.5.  Route Maintenance
>
>    A RERR SHOULD be issued if a data packet is to be forwarded and it
>    cannot be delivered to the next-hop because no forwarding route for
>    the IP.DestinationAddress exists; RERR generation is described in
>    Section 5.5.3.
> UH> ================
> UH> Which assumptions are made of the underlying L2? (ACKs, timeout, NUD, etc.)
> UH> ================

Do you mean to ask how it is that the forwarding AODVv2 router
can determine whether or not the packet was forwarded to the
next hop?

>
>    Upon this condition, an ICMP Destination Unreachable message SHOULD
>    NOT be generated unless this router is responsible for the
>    IP.DestinationAddress and that IP.DestinationAddress is known to be
>    unreachable.
> UH> ================
> UH> Is that known terminology "a router is responsible for an address?"
> UH> ================

Well, the terminology is supposed to be well defined somewhere in
the draft.

> 5.7.  Unknown Message & TLV Types
>
>    If a message with an unknown type is received, the message is
>    discarded.
> UH> ================
> UH> I think it should be ignored, not discarded. It may be an
> UH> NHDP/OLSRv2 messages for example.
> UH> ================

I have made this change -- thanks.

>
>    For handling of messages that contain unknown TLV types, the default
>    behavior is to leave the information in control messages unmodified.
>    Although, this behavior (UNKNOWN_TYPES) MAY be administratively
>    controlled.
>
> 5.8.  Advertising Network Addresses
> UH> ================
> UH> I don't understand this section. Of course, any hosts attached to
> UH> the router (on it's non-MANET interface) are unaware of the routing
> UH> protocol. That's true for any routing protocol, it does not run on the
> UH> hosts.
> UH> ================
>
>    DYMO routers specify the prefix length for each advertised address.
>    Any nodes (other than the advertising DYMO router) within the
>    advertised prefix MUST NOT participate in the DYMO protocol directly.
>    For example, advertising 192.0.2.1 with a prefix length of 24
>    indicates that all nodes with the matching 192.0.2.X are reachable
>    through this DYMO router.

I'm not sure what exactly to do about this right now.
The section is short and mostly O.K. I think.

>
> 5.9.  Simple Internet Attachment
> UH> ================
> UH> Unclear why this section is needed. Is this an example deployment?
> UH> ================
>
>    Simple Internet attachment consists of a stub network of DYMO routers
>    connected to the Internet via a single Internet DYMO router (IDR).
> UH> ================
> UH> What does "connected to the Internet" mean? How the routers know?
> UH> Why introducing another acronym (IDR), just for an example?
> UH> ================

I think it is mostly an example, except that the attachment point
can't possibly have specific routes to every host in the Internet.

>
>    DYMO routers, and hosts behind these routers, wishing to be reachable
>    from hosts on the Internet MUST have IP addresses within the IDR's
>    routable and topologically correct prefix (e.g. 192.0.2.0/24).
> UH> ================
> UH> That's true for routing in general, not just for DYMO
> UH> ================

True.  I have added a clause to indicate this is not specific to AODVv2.

>          /--------------------------\
>         /          Internet          \
>         \                            /
>          \------------+-------------/
>                       |
>        Routable &     |
>        Topologically  |
>        Correct        |
>        Prefix         |
>                 +-----+------+
>                 |  Internet  |
>          /------|  DYMO      |-------\
>         /       |  Router    |        \
>        /        |192.0.2.1/32|         \
>        |        |Responsible |         |
>        |        |  for       |         |
>        |        |DYMO Region |         |
>        |        |192.0.2.0/24|         |
>        |        +------------+         |
>        | +--------------+              |
>        | | DYMO Router  |              |
>        | | 192.0.2.2/32 |              |
>        | +--------------+              |
>        |              +--------------+ |
>        |              | DYMO Router  | |
>        |              | 192.0.2.3/32 | |
>        \              +--------------+ /
>         \                             /
>          \---------------------------/
>
>                Figure 3: Simple Internet Attachment Example
>
>    When a DYMO router within the DYMO Region wants to discover a route
>    to a node on the Internet, it uses the normal DYMO route discovery
>    for that IP Destination Address.  The IDR is responsible for properly
>    responding to RREQ on behalf of the Internet destination.
>
>    When a packet from a node on the Internet destine for a node in the
>    DYMO region reaches the IDR, if the IDR does not have a route to that
>    destination it will perform normal DYMO route discovery for that
>    destination.
>
> UH> ================
> UH> How would that work for multi-homing?
> UH> ================

This part, as you mentioned before, does not work differently than
for other Internet-attached networks.

> 5.10.  Multiple Interfaces
>
>    DYMO may be used with multiple interfaces; therefore, the particular
>    interface over which packets arrive MUST be known whenever a packet
>    is received.  Whenever a new route is created, the interface through
>    which the Route.Address can be reached is also recorded in the route
>    table entry.
>
>    When multiple interfaces are available, a node transmitting a
>    multicast packet with IP.DestinationAddress set to LL-MANET-Routers
>    SHOULD send the packet on all interfaces that have been configured
>    for DYMO operation.
>
>    Similarly, DYMO routers should subscribe to LL-MANET-Routers on all
>    their DYMO interfaces.
>
> UH> ================
> UH> It seems to be more complicated than just a small section like
> UH> this. A large part of the complexity of, e.g., NHDP is due to multiple
> UH> interfaces.

It's been a long time since I looked at NHDP.  My bit of participation
wasn't very productive; I thought the protocol was too verbose as you
probably remember.  But I will take another look.  It could be that
something more needs to be said here, but up until now I didn't find
any fault with the more simple formulation.

> UH> Just some thoughts: On which interfaces are RM sent to? Which
> UH> addresses are used as originator of a message? Is loop-detection more
> UH> difficult with several interfaces?
> UH> ================

The multicast RM is sent over all interfaces whose IP addresses
belong to the multicast group.  The message originator, e.g. OrigNode,
depends on the message.  Loop detection should work the same way
with multiple interfaces, and as best I remember from all the cases
handled by AODV this was never a problem.

>
> 5.11.  DYMO Control Packet/Message Generation Limits
>
>    To ensure predictable control overhead, DYMO router's rate of packet/
>    message generation SHOULD be limited.  The rate and algorithm for
>    limiting messages (CONTROL_TRAFFIC_LIMITS) is left to the implementor
>    and should be administratively configurable or intelligently
>    controlled.  DYMO control messages SHOULD be discarded in the
>    following order of preferences RREQ, RREP, and finally RERR.
> UH> ================
> UH> I think that this is too vague. I would prefer to have a basic
> UH> mechanism explained how to do that (e.g. having MIN_INTERVAL
> UH> parameters)
> UH> ================

Work to do...  contributions greatly appreciated.

...
>    In situations where routing information or router identity are
>    suspect, integrity and authentication techniques SHOULD be applied to
>    DYMO messages.  In these situations, routing information that is
>    distributed over multiple hops SHOULD also verify the integrity and
>    identity of information based on originator of the routing
>    information.
>
> UH> ================
> UH> That seems impossible in DYMO, since intermediate routers can (i)
> UH> cache target destinations and (ii) modify forwarded messages.
> UH> ================

This was discussed earlier in this email.

> <SNIP>
>
>
> Appendix A.  Shifting Responsibility for an Address Between DYMO Routers
> UH> ================
> UH> Section is unclear to me.
> UH> ================
>
>    Only one DYMO router within a routing region SHOULD be responsible
>    for a particular address at any time.  If two DYMO routers
>    dynamically pass responsibility of an address correct DYMO routing
>    behavior must be observed.  The DYMO router adding the new address
>    must wait for any exiting routing information about this address to
>    be purged from the network.  Therefore, it must wait at least
>    ROUTER_SEQNUM_AGE_MAX_TIMEOUT after the previous DYMO router for this
>    address stopped participating and advertising routing information on
>    its behalf.
>
> <SNIP>

I agree that this needs to be made much clearer.

Thanks again for the detailed review.  I have made revisions according
to the comments above.  I agree that more work needs to be done
especially to improve clarity and proper handling of RFC 5444 messages
when bundled with non-AODVv2 messages.

Regards,
Charlie P.

-- 
Regards,
Charlie P.