Subject: [manet] AODVv2 reivew

From: Justin Dean <[email-masked]>
Date: Tue, 1 Mar 2016 23:18:50 -0500

I've completed my review of the draft 13 of AODVv2.  Attached is my updated
with comments (marked JWD) and various inline fixes draft/review.   I've
also included a diff to illustrate the inline fixes.  I did not review the
security section.  I did have a few major comments which are marked with
JWD!

Justin
--- C:\Users\Justin\Desktop\draft-ietf-manet-aodvv2-13.txt
+++ C:\Users\Justin\Desktop\draft-ietf-manet-aodvv2-13 (2).txt
@@ -179,8 +179,13 @@
    protocol (formerly named DYMO) enables on-demand, multihop unicast
    routing among AODVv2 routers in mobile ad hoc networks (MANETs)
    [RFC2501].
-
-   Compared to AODV [RFC3561], AODVv2 makes some features optional,
+(We jumped right in here would prefer some intro to AODV and how AODVv2 is derived from that work. JWD)
+
+
+   Although AODVv2 is closely related to AODV [RFC3561], and shares some
+   features of DSR [RFC4728], AODVv2 is not interoperable with either of
+   those protocols.
+   Compared to AODV, AODVv2 makes some features optional,
    notably intermediate route replies, expanding ring search, and
    precursor lists.  Hello messages and local repair have been removed.
    AODVv2 provides a mechanism for the use of multiple metric types.
@@ -199,7 +204,7 @@
    packet from one of its Router Clients, but does not have a valid
    route to the packet's destination.  AODVv2 routers use Route Request
    (RREQ) and Route Reply (RREP) messages to carry route information
-   between the originator of the route discovery and the target,
+   between the originator of the route discovery and the target, (shouldn’t this be router responsible for target Router Client?)
    establishing a route to both endpoints on all intermediate routers.
    A metric value is included to represent the cost of the route
    contained within the message.  AODVv2 uses sequence numbers to
@@ -207,16 +212,16 @@
    to determine if advertised routes could form loops.
 
    Route maintenance includes confirming bidirectionality of links to
-   next hop AODVv2 routers before considering discovered routes to be
-   valid, issuing Route Error (RERR) messages if link failures
-   invalidate routes, reacting to received Route Error messages, and
+   next hop AODVv2 routers, issuing Route Error (RERR) messages, reacting to received Route Error messages, and
    extending and enforcing route timeouts.
 
-   To enable the on-demand nature of AODVv2, signals are required to be
-   exchanged between AODVv2 and the forwarding plane, to indicate when a
-   packet is to be forwarded, in order to initiate route discovery, when
-   packet forwarding fails, in order to initiate route error reporting,
-   and when a packet is successfully forwarded, for route maintenance.
+
+   The on-demand nature of AODVv2 requires signals to be
+   exchanged between AODVv2 and the forwarding plane. These signals indicate when:  a
+   a packet is to be forwarded, in order to initiate route discovery;
+   packet forwarding fails, in order to initiate route error reporting;
+   a packet is successfully forwarded, for route maintenance.
+
 
    Security for authentication of AODVv2 routers and encryption of
    control messages is accomplished using the TIMESTAMP and ICV TLVs
@@ -263,8 +268,11 @@
       A route that cannot be used for forwarding but still contains
       useful sequence number information.
 
-   LocalRoute
-      An entry in the Local Route Set.
+
+   Local Route
+      An entry in the Local Route Set. (Local Route Set should have an entry, something simple and pointing to the section JWD)
+(Later in the document LocalRoute is used pick one JWD)
+
 
    MANET
       A Mobile Ad Hoc Network as defined in [RFC2501].
@@ -346,9 +354,8 @@
 
       An address or address range configured on an AODVv2 router, on
       behalf of which that router will initiate and respond to route
-      discoveries, so that devices configured to use these addresses can
-      send and receive IP traffic to and from remote destinations.
-      These addresses may be used by the AODVv2 router itself or by non-
+      discoveries.
+      These addresses may be from  the AODVv2 router itself or by non-
       routing devices that are reachable without traversing another
       AODVv2 router.
 
@@ -405,16 +412,12 @@
       Route Reply on behalf of TargAddr.
 
    Valid route
-      A route that can be used for forwarding, which has been confirmed
-      as having a bidirectional link to the next hop, and has not timed
-      out or been made invalid by a route error.
+      A route that can be used for forwarding. (the deleted part should be defined in Route Error Generation section JWD)
+
 
    Unreachable Address
-      An address reported in a Route Error message, either the address
-      on a LocalRoute which became Invalid, or the destination address
-      of an IP packet that could not be forwarded because a valid
-      LocalRoute to the destination is not known, and will not be
-      requested.
+      An address reported in a Route Error message. (the deleted part should be defined in Route Error Generation section JWD)
+
 
    Upstream
       In the direction from destination to source (from TargAddr to
@@ -438,14 +441,15 @@
 
 3.  Applicability Statement
 
-   The AODVv2 routing protocol is a reactive routing protocol.  While
-   proactive routing protocols send frequent messages and determine
-   routes in advance of them being used, a reactive protocol only sends
+
+(Wireless properties of the network is not mentioned at all and this is quite important as I’m pretty sure AODVv2 for used in a wired network would be a bad idea JWD)
+
+
+   The AODVv2 routing protocol is a reactive routing protocol.  A reactive protocol only sends
    messages to discover a route when there is data to send on that
    route.  Therefore, a reactive routing protocol requires certain
-   interactions with the forwarding plane, for example, to indicate when
-   a packet is to be forwarded, in order to initiate route discovery,
-   route error reporting, or route maintenance.  The set of signals
+   interactions with the forwarding plane (for example, to indicate when
+   a packet is to be forwarded, in order to initiate route discovery).  The set of signals
    exchanged between AODVv2 and the forwarding plane are discussed in
    Section 6.4.
 
@@ -461,7 +465,8 @@
    AODVv2 is designed for stub or disconnected mobile ad hoc networks,
    i.e., non-transit networks or those not connected to the internet.
    AODVv2 can, however, be configured to perform gateway functions when
-   attached to external networks, as discussed in Section 9.
+   attached to external networks, as discussed in Section 9. (some mention of limitations of the provided approach is required.  No default gateways, drawbacks/overhead of using AODVv2 network to connect to the Internet using provided approach JWD)
+
 
    AODVv2 handles a wide variety of mobility and traffic patterns by
    determining routes on-demand.  In networks with a large number of
@@ -470,12 +475,16 @@
    of other AODVv2 routers in the network.  In this case fewer routes
    are needed, and therefore less control traffic is produced.
 
-   Providing security for a reactive routing protocol can be difficult.
+
+
+
    AODVv2 provides for message integrity and security against replay
    attacks by using integrity check values, timestamps and sequence
    numbers, as described in Section 13.  If security associations can be
    established, encryption can be used for AODVv2 messages to ensure
    that only trusted routers participate in routing operations.
+(There is an issue with trust being limited to single hops and no way to verify information more than one hop away JWD)
+
 
    Since the route discovery process aims for a route to be established
    in both directions along the same path, uni-directional links are not
@@ -484,9 +493,7 @@
    router, and the return path may not be the optimal route.
 
    AODVv2 is applicable to memory constrained devices, since only a
-   little routing state is maintained in each AODVv2 router.  In
-   contrast to proactive routing protocols, which maintain routing
-   information for all destinations within the MANET, AODVv2 routes that
+   little routing state is maintained in each AODVv2 router. AODVv2 routes that
    are not needed for forwarding data do not need to be maintained.  On
    routers unable to store persistent AODVv2 state, recovery can impose
    a performance penalty (e.g., in case of AODVv2 router reboot), since
@@ -494,8 +501,7 @@
    router can resume full operations.  This is described in Section 6.1.
 
    AODVv2 supports routers with multiple interfaces and multiple IP
-   addresses per interface.  A router may also use the same IP address
-   on multiple interfaces.  AODVv2 requires only that each interface
+   addresses per interface.   (this should be disallowed as it can form non valid routes with uni-directional links JWD) AODVv2 requires that each interface
    configured for AODVv2 has at least one unicast IP address.  Address
    assignment procedures are out of scope for AODVv2.
 
@@ -515,12 +521,10 @@
 Internet-Draft                   AODVv2                     January 2016

-   Although AODVv2 is closely related to AODV [RFC3561], and shares some
-   features of DSR [RFC4728], AODVv2 is not interoperable with either of
-   those protocols.
-
-   The routing algorithm in AODVv2 MAY be operated at layers other than
-   the network layer, using layer-appropriate addresses.
+ (This should go in the intro JWD)
+
+
+
 
 4.  Data Structures
 
@@ -530,8 +534,14 @@
    AODVv2, a list of the interfaces MUST be configured in the
    AODVv2_INTERFACES list.
 
+
+(AODVv2_INTERFACES isn’t defined before now it should be. Also what does this configuration consist of? Also is the list empty if there is  only one interface? JWD!)
+
+
 4.2.  Router Client Table
 
+
+What’s the difference between a table and a list why are we using one over the other?JWD)
    An AODVv2 router provides route discovery services for its own local
    applications and for other non-routing devices that are reachable
    without traversing another AODVv2 router.  The addresses used by
@@ -555,12 +565,14 @@
    RouterClient.Cost
       The cost associated with reaching this Router Client.
 
-   The Router Client Table for an AODVv2 router is never empty, since an
-   AODVv2 router's interface addresses are always configured in Router
-   Client entries.
-
-   In the initial state, an AODVv2 router is not required to have
-   information about the Router Clients of any other AODVv2 router.
+
+
+
+
+
+
+
+

@@ -573,9 +585,9 @@

    A Router Client address SHOULD NOT be served by more than one AODVv2
-   router at any one time.  To shift responsibility for a Router Client
+   router at any one time. (do things break when a Router Client is served by more than one AODVv2 Router?  My guess is yes and therefore SHOULD be a MUST. JWD) To shift responsibility for a Router Client
    to a different AODVv2 router, correct AODVv2 routing behavior MUST be
-   observed.  The AODVv2 router adding the Router Client MUST wait for
+   observed;  The AODVv2 router adding the Router Client MUST wait for
    any existing routing information about this Router Client to be
    purged from the network, i.e., at least MAX_SEQNUM_LIFETIME since the
    last SeqNum update on the router which is removing this Router
@@ -614,6 +626,8 @@
       MAX_BLACKLIST_TIME.  When the value of Neighbor.State is not
       Blacklisted, this time is set to INFINITY_TIME.
 
+
+(How does one know which outgoing interface is the neighbor associated with?  This seems like a very LARGE missing piece of required information JWD!)
 4.4.  Sequence Numbers
 
    Sequence numbers enable AODVv2 routers to determine the temporal
@@ -643,13 +657,9 @@
    that the sequence number is unknown.
 
    An AODVv2 router MUST only attach its own sequence number to
-   information about a route to one of its configured Router Clients.
-   All route messages regenerated by other routers retain the
-   originator's sequence number.  Therefore, when two pieces of
-   information about a route are received, they both contain a sequence
-   number from the originating router.  Comparing the sequence number
-   will identify which information is stale.  The previously stored
-   sequence number is subtracted from the incoming sequence number.  The
+   information about a route to one of its configured Router Clients, all route messages regenerated by other routers retain the
+   originator's sequence number.   To determine staleness the previously stored
+   sequence number associated with the originator, is subtracted from the incoming sequence number.  The
    result of the subtraction is to be interpreted as a signed 16-bit
    integer, and if less than zero, the information in the new AODVv2
    message is stale and MUST be discarded.
@@ -666,10 +676,11 @@
 
    All AODVv2 routers MUST maintain a Local Route Set, containing
    information about routes learned from AODVv2 route messages.
-   Implementations MAY choose to modify the Routing Information Base.
-   Alternatively, the Local Route Set is stored separately, and the
-   Routing Information Base is updated using information from the Local
-   Route Set.
+   Implementations MAY choose to modify the Routing Information Base directly, (this is the first this term is used and it should be defined I assume it’s the forwarding planes routing table JWD)
+   or alternatively, the Local Route Set MAY be stored separately, and the
+   Routing Information Base can be externally updated using information from the Local
+   Route Set.  (I’m assuming this is here to hint at the possibility of a unified router with multiple routing protocols playing nicely together JWD)
+
 
    Routes learned from AODVv2 route messages are referred to in this
    document as LocalRoutes, and MUST contain the following information:
@@ -733,6 +744,9 @@
       been confirmed as bidirectional.  It is not able to be used for
       forwarding IP packets, and therefore it is not referred to as a
       valid route.
+(I noticed that Unconfirmed is the only state that uses Route Request message instead of route message, is that intended?  Can unconfirmed route state only be reached through Route Request messages? JWD)
+
+

@@ -764,7 +778,8 @@
    When the Local Route State is stored separately from the Routing
    Information Base, routes are added to the Routing Information Base
    when LocalRoute.State is valid (set to Active or Idle), and removed
-   from the Routing Information Base LocalRoute.State becomes Invalid.
+   from the Routing Information Base when LocalRoute.State becomes Invalid.
+
 
    Changes to LocalRoute state are detailed in Section 6.9.1.
 
@@ -780,6 +795,8 @@
    valid entry.  Any others will be Unconfirmed, but may offer
    improvement to the existing valid route, if they can be confirmed as
    valid routes (see Section 6.2).
+(There wasn’t any text above and it’s not clear how this is enforced.  I have an idle route and an unconfirmed route, the unconfirmed route is updated to confirmed, I now have two valid route entries and no way to demote/decide or otherwise purge one of them but I’m not allowed to do that.  Setting the worse and previously idle route to unconfirmed seems wrong and broken. JWD!)
+
 
    Multiple valid routes for the same address and prefix length but for
    different metric types may exist in the Local Route Set, but the
@@ -814,7 +831,7 @@
    contains information about previously received multicast route
    messages, so that incoming route messages can be compared with
    previously received messages to determine if the incoming information
-   is redundant, and the router can avoid sending redundant control
+   is redundant or stale, and the router can avoid sending redundant control
    traffic.
 
    Multicast Route Message Table entries MUST contain the following
@@ -839,6 +856,8 @@
       The prefix length associated with RteMsg.TargAddr, originally from
       the Router Client entry on RREP_Gen which includes
       RteMsg.TargAddr.
+(this seems like an entry that would always be full 1s on a route request if true that should be stated to make things more clear JWD)
+
 
    RteMsg.OrigSeqNum
       The sequence number associated with the route to OrigAddr, if
@@ -847,6 +866,11 @@
    RteMsg.TargSeqNum
       The sequence number associated with the route to TargAddr, if
       present in the RteMsg.
+(would this ever be in a RREQ?  If no then I suggest using words similar to “if RteMsg is an RREP JWD)
+
+
+
+

@@ -918,18 +942,15 @@
    install a route back toward TargAddr.
 
    Assuming link metrics are symmetric, the cost of the routes installed
-   in the Local Route Set at each router will be correct.  The route
+   in the Local Route Set at each router will be correct.  (This is a huge and often incorrect assumption. It may be possible to mention that calculating incoming/outgoing metric data is outside of scope of this document and leave it at that JWD) The route
    discovered is optimised for the requesting router, and the return
    path may not be the optimal route.
 
    AODVv2 enables the use of multiple metric types.  Each route
    discovery attempt indicates the metric type which is requested for
    the route.  Only one metric type may be used in each route discovery
-   attempt.  However, routes to a single destination might be requested
-   and created in the Local Route Set for multiple metric types.  The
-   decision of which of these routes to install in the Routing
-   Information Base to use for forwarding is outside the scope of
-   AODVv2.
+   attempt.   (Already said this no need to say it again. JWD)
+
 
    For each MetricType, AODVv2 requires:
 
@@ -941,6 +962,8 @@
       AODVv2 cannot store routes that cost more than
       MAX_METRIC[MetricType].
 
+
+(consider adding a maximum single hop value JWD)
    o  A function for incoming link cost, denoted Cost(L).  Using
       incoming link costs means that the route learned has a path
       optimized for the direction from OrigAddr to TargAddr.
@@ -1008,6 +1031,8 @@
 
    Until MAX_SEQNUM_LIFETIME after its sequence number is reset, the
    router SHOULD NOT create RREQ or RREP messages.
+(Just to be clear one MUST wait 5 mins before starting to request any route without a persistent store of the seq num, yes? JWD)
+
 
    During this wait period, the router is permitted to do the following:
 
@@ -1032,21 +1057,13 @@
 
 6.2.  Next Hop Monitoring
 
-   AODVv2 routers MUST NOT establish routes over uni-directional links.
-   Consider the following.  An RREQ is forwarded toward TargAddr, and
-   intermediate routers create a LocalRoute entry in the Local Route Set
-   for the addresses represented by OrigAddr and OrigPrefixLen.  If, at
-   one of the intermediate routers, this route was used to forward data
-   traffic, but the link to the next hop toward OrigAddr was uni-
-   directional, the data packets would be lost.  Further, an RREP sent
-   toward OrigAddr using this link would not reach the next hop, and
-   would therefore never reach RREQ_Gen, so end-to-end route
-   establishment will fail.
-
-   AODVv2 routers MUST verify that the link to the next hop router is
+
+(needless, obvious and hard to follow JWD)
+   To ensure AODVv2 Routers do not establish routes over uni-directional links, AODVv2 routers MUST verify that the link to the next hop router is
    bidirectional before marking a route as valid in the Local Route Set.
    If link bidirectionality cannot be verified, this link MUST be
-   excluded from the route discovery procedure.  AODVv2 routers do not
+   excluded from the route discovery procedure. (It isn’t clear what the previous sentence means as the link was already part of the route discovery procedure if I know about it yes? JWD)
+ AODVv2 routers do not
    need to monitor bidirectionality for links to neighboring routers
    which are not used as next hops on routes in the Local Route Set.
 
@@ -1065,7 +1082,7 @@
       confirmation of bidirectionality, since a Route Reply message is a
       reply to a Route Request message which previously crossed the link
       in the opposite direction.
-
+(previous bullet points are a bit wordy consider using upstream and downstream and just list, route request, route reply to confirm downstream and route reqeust, route reply , route reply ack for upstream JWD)
    To assist with next hop monitoring, a Neighbor Table (Section 4.3) is
    maintained.  When an RREQ or RREP is received from an IP address
    which does not already have an entry in the Neighbor Table, a new
@@ -1106,29 +1123,17 @@
 
    If such an external process signals that the link to a neighbor is
    bidirectional, the AODVv2 router MAY update the matching Neighbor
-   Table entry by changing the value of Neighbor.State to Confirmed.  If
+   Table entry by changing the value of Neighbor.State to Confirmed, e.g. receipt of a Neighborhood Discovery Protocol HELLO message with the receiving router listed as a neighbor.  If
    an external process signals that a link is not bidirectional, the the
-   value of Neighbor.State MAY be changed to Blacklisted.  If an
-   external process signals that the link might not be bidirectional,
-   and the value of Neighbor.State is currently Confirmed, it MAY be set
-   to Unknown.
-
-   For example, receipt of a Neighborhood Discovery Protocol HELLO
-   message with the receiving router listed as a neighbor is a signal of
-   bidirectional connectivity.  The AODVv2 router MAY update the
-   matching Neighbor Table entry by changing the value of Neighbor.State
-   to Confirmed.
-
-   Similarly, if AODVv2 receives notification of a timeout, for example,
-   from TCP or some other protocol, this may be due to a disconnection.
-   The AODVv2 router MAY update the matching Neighbor Table entry by
-   setting the value of Neighbor.State to Unknown.
+   value of Neighbor.State MAY be changed to Blacklisted, e.g. notification of a TCP timeout.  (I can’t see how the above would be helpful at all JWD)
+   
+
 
 6.3.  Neighbor Table Update
 
    On receipt of an RREQ or RREP message, the Neighbor Table MUST be
    checked for an entry with Neighbor.IPAddress which matches the source
-   IP address of the message.  If no matching entry is found, a new
+   IP address of the packet containing the AODVv2 message.  If no matching entry is found, a new
    entry is created.
 
    A new Neighbor Table entry is created as follows:
@@ -1151,14 +1156,16 @@
 
    If the message is an RREP which answers a recently sent RREQ, or an
    RREP_Ack which answers a recently sent RREP, the link to the neighbor
-   is bidirectional.  When the link to the neighbor is determined to be
+   is bidirectional.  
+(The valid entry in the Multicast Route Message Table must be identified this is too wishy washy for me to understand what is meant by recently sent JWD!) When the link to the neighbor is determined to be
    bidirectional, the Neighbor Table entry is updated as follows:
 
    o  Neighbor.State := Confirmed
 
    o  Neighbor.ResetTime := INFINITY_TIME
 
-   If an RREP_Ack is not received within the expected time, the link is
+
+   If an RREP_Ack is not received within the expected time (what is the expected time? list the entry we are checking assuming in the Multicast Route Message Tablet? outline it. JWD), the link is
    considered to be uni-directional.  When the link to the neighbor is
    determined to be uni-directional, the Neighbor Table entry is updated
    as follows:
@@ -1172,21 +1179,28 @@
 
    o  Neighbor.State := Unknown
 
-   When a link to a neighbor is determined to be broken, the Neighbor
-   Table entry SHOULD be removed.
+
+ (What does this mean?  How would one determine a link to a neighbor to be broken….suggest removing it JWD)
+
 
    Route requests from neighbors with Neighbor.State set to Blacklisted
    are ignored to avoid persistent IP packet loss or protocol failures.
-   However, Neighbor.ResetTime allows the neighbor to again be allowed
-   to participate in route discoveries after MAX_BLACKLIST_TIME, in case
+   Neighbor.ResetTime allows the neighbor to again be allowed
+   to participate in route discoveries in case
    the link between the routers has become bidirectional.
 
 6.4.  Interaction with the Forwarding Plane
 
-   A reactive routing protocol reacts when a route is needed, i.e., when
-   an application tries to send a packet and the forwarding plane has no
-   route to the destination of the packet.  The fundamental concept of
-   reactive routing is to avoid creating routes that are not needed.
+
+(This has already been said in different words in the intro and applicability sections not needed again here JWD) 
+These are conceptual signals, and can be implemented in various ways.
+   Conformant implementations of AODVv2 are not mandated to implement
+   the forwarding plane separately from the control plane or data plane;
+   these signals and interactions are identified simply as assistance
+   for implementers who may find them useful.
+
+
+
 
    AODVv2 requires signals from the forwarding plane:
 
@@ -1201,13 +1215,13 @@
 
    o  A packet cannot be forwarded because a route is unavailable:
       AODVv2 needs to know the source and destination IP addresses of
-      the packet, to determine if the source of the packet is configured
-      as a Router Client, in which case the router should initiate route
-      discovery.  If it is not a Router Client, the router should create
+      the packet. If the source of the packet is configured
+      as a Router Client, the router should initiate route
+      discovery to the destination.  If it is not a Router Client, the router should create
       a Route Error message.
 
    o  A packet is to be forwarded: AODVv2 needs to check the state of
-      the route to deal with timeouts to ensure the route is still
+      the route to ensure it is still
       valid.
 
    o  Packet forwarding succeeds: AODVv2 needs to update the record of
@@ -1220,6 +1234,8 @@
 
    o  A route discovery is in progress: buffering might be configured
       for packets requiring a route, while route discovery is attempted.
+(This is the first mention of buffering.  It should be included in the applicability section as well along with a reference to text on how they are managed JWD)
+
 
    o  A route discovery failed: any buffered packets requiring that
       route should be discarded, and the source of the packet should be
@@ -1227,15 +1243,17 @@
       Destination Unreachable message).  Route discovery fails if an
       RREQ cannot be generated because the control message generation
       limit has been reached, or if an RREP is not received within the
-      expected time.
+      expected time. (reference the section detailing the behavior of what defines expected time JWD)
+
 
    o  A route discovery is not permitted: any buffered packets requiring
       that route should be discarded.  A route discovery will not be
       attempted if the source address of the packet needing a route is
       not configured as a Router Client.
 
-   o  A route discovery succeeded: install a corresponding route into
-      the Routing Information Base and begin transmitting any buffered
+
+   o  A route discovery succeeded: install the corresponding route into
+      the Routing Information Base and begin transmitting buffered
       packets.
 
    o  A route has been made invalid: remove the corresponding route from
@@ -1244,9 +1262,9 @@
    o  A route has been updated: update the corresponding route in the
       Routing Information Base.
 
-   These are conceptual signals, and can be implemented in various ways.
-   Conformant implementations of AODVv2 are not mandated to implement
-   the forwarding plane separately from the control plane or data plane;
+
+   
+

@@ -1256,8 +1274,10 @@
 Internet-Draft                   AODVv2                     January 2016

-   these signals and interactions are identified simply as assistance
-   for implementers who may find them useful.
+
+
+   (moved to the beginning of the section so this is understood upfront JWD)
+
 
 6.5.  Message Transmission
 
@@ -1300,10 +1320,14 @@
       newly invalidated routes, since the invalidated routes may not
       still be in use, and if there is an attempt to use the route, a
       new RERR message will be generated.
+(So is this 4th or second? It’s not clear and it should be. JWD)
+
 
    o  Lowest priority SHOULD be given to RERR messages generated in
       response to RREP messages which cannot be regenerated.  In this
       case the route request will be retried at a later point.
+(It’s not clear to me how this priority works.  Do the messages just get dropped when tsome threshold for max number of messages is reached?  Is there some queuing method because if their isn’t I don’t see how priority would work at all, as the choices are drop or send.  This whole section seems out of place as we have’t talked about generating messages. I’d suggest moving or removing JWD)
+

@@ -1314,23 +1338,25 @@

    Messages may travel a maximum of MAX_HOPCOUNT hops.
+(Messages don’t really travel though do they as they are regenerated at each hop. JWD)
+
 
 6.6.  Route Discovery, Retries and Buffering
 
    AODVv2's RREQ and RREP messages are used for route discovery.  RREQ
-   messages are multicast to solicit an RREP, whereas RREP is unicast
+   messages are multicast to solicit an RREP, whereas RREP  are unicast
    where possible.  The constants used in this section are defined in
    Section 11.
 
    When an AODVv2 router needs to forward an IP packet (with source
    address OrigAddr and destination address TargAddr) from one of its
    Router Clients, it needs a route to TargAddr in its Routing
-   Information Base.  If no route exists, the AODVv2 router generates
-   and multicasts a Route Request message (RREQ) containing OrigAddr and
+   Information Base.  If no route exists, the AODVv2 router (RREQ_Gen) generates
+   and multicasts a Route Request message (RREQ), on all configured interfaces, containing OrigAddr and
    TargAddr.  The procedure for this is described in Section 7.1.1.
    Each generated RREQ results in an increment to the router's sequence
-   number.  The AODVv2 router generating an RREQ is referred to as
-   RREQ_Gen.
+   number.  
+
 
    Buffering might be configured for IP packets awaiting a route for
    forwarding by RREQ_Gen, if sufficient memory is available.  Buffering
@@ -1339,11 +1365,13 @@
    buffered and subjected to delays, but TCP connection establishment
    will benefit if packets are queued while route discovery is performed
    [Koodli01].  If packets are not queued, no notification should be
-   sent to the source.  Determining which packets to discard first when
+   sent to the source. (What notification is sent to the source when packets are queued? JWD) Determining which packets to discard first when
    the buffer is full is a matter of policy at each AODVv2 router.
+(This doesn’t specify with any detail what buffer methods should be used or even some that might be appropriate. Mentioning that different buffer methods doesn’t affect interoperability should be done JWD)
+
 
    RREQ_Gen awaits reception of a Route Reply message (RREP) containing
-   a route toward TargAddr.  If a valid route to TargAddr is not learned
+   a route toward TargAddr. (is there some table that lists routes that are being waited on? JWD) If a valid route to TargAddr is not learned
    within RREQ_WAIT_TIME, RREQ_Gen will retry the route discovery.  To
    reduce congestion in a network, repeated attempts at route discovery
    for a particular target address utilize a binary exponential backoff:
@@ -1372,17 +1400,13 @@
 
    route to TargAddr (and other addresses as indicated by
    TargPrefixLen), regenerates the RREP and sends toward OrigAddr.
-
-   Links which are not bidirectional cause problems.  If a link is
-   unavailable in the direction toward OrigAddr, an RREP is not received
-   at the next hop, so cannot be regenerated, and it will never reach
-   RREQ_Gen.  However, since routers monitor bidirectionality to next
-   hops (Section 6.2), the loss of the RREP will cause the last router
-   which regenerated the RREP to blacklist the router which did not
-   receive it.  Later, a timeout occurs at RREQ_Gen, and a new RREQ is
-   generated.  If the new RREQ arrives via the blacklisted router, it
-   will be ignored, enabling the RREQ, if also received from a different
-   neighbor, to discover a different path toward TargAddr.
+(seems like a good overview paragraph but not sure what it adds here. Should be moved further up in the document or removed. JWD)
+
+
+   
+  Through the use of bidirectional link monitoring and blacklists (Section 6.2) uni-directional links on initial selected route will be ignored on subsequent route discovery attempts.
+(Seems like a more direct way of saying the same thing JWD)
+
 
    Route discovery is considered to have failed after
    DISCOVERY_ATTEMPTS_MAX and the corresponding wait time for an RREP
@@ -1393,8 +1417,8 @@
    route.  Any IP packets buffered for TargAddr are also dropped and a
    Destination Unreachable ICMP message (Type 3) with a code of 1 (Host
    Unreachable Error) is delivered to the source of the packet, so that
-   the application knows about the failure.  The source might be an
-   application on RREQ_Gen itself, or on a difference device.
+   the application knows about the failure.  (we know this already. JWD)
+
 
    If RREQ_Gen does receive a route message containing a route to
    TargAddr within the timeout, it processes the message according to
@@ -1428,7 +1452,8 @@

    Section 6.7.1.  The Local Route Set MAY then be updated according to
-   Section 6.7.2.
+   Section 6.7.2.  (MAY not MUST? Why wouldn’t one update it according to section 6.7.2? JWD)
+
 
    In the processes below, RteMsg is used to denote the route message,
    AdvRte is used to denote the route contained within it, and
@@ -1451,6 +1476,8 @@
 
    o  AdvRte.NextHop := RteMsg.IPSourceAddress (an address of the router
       from which the RteMsg was received)
+(surely this must be an address of the sending interface of the router from which the RteMsg was received. JWD)
+
 
    o  AdvRte.MetricType := RteMsg.MetricType
 
@@ -1502,6 +1529,8 @@
        *  If LoopFree(AdvRte, LocalRoute) returns FALSE, AdvRte MUST NOT
           be used to update the Local Route Set because using the
           incoming information might cause a routing loop.
+(does processing stop here?  It seems like it hsould be that isn’t stated. JWD)
+
 
        *  If LoopFree(AdvRte, LocalRoute) returns TRUE, continue to Step
           4.
@@ -1521,6 +1550,8 @@
        *  If AdvRte is worse and LocalRoute is valid, AdvRte MUST NOT be
           used to update the Local Route Set because it does not offer
           any improvement.
+(does processing stop here?  It seems like it hsould be that isn’t stated. JWD)
+
 
        *  If AdvRte is not better (i.e., it is worse or equal) but
           LocalRoute is Invalid or Unconfirmed, AdvRte SHOULD be used to
@@ -1529,8 +1560,9 @@
           existing Unconfirmed route.
 
    If the advertised route is to be used to update the Local Route Set,
-   the procedure in Section 6.7.2 MUST be followed.  If not, non-optimal
-   routes will remain in the Local Route Set.
+   the procedure in Section 6.7.2 MUST be followed. 
+
+

@@ -1619,7 +1651,7 @@
    5.  If a new LocalRoute was created, or if the existing
        LocalRoute.State is Invalid or Unconfirmed, update LocalRoute as
        follows:
-
+(this is ambugious as there may be more than one unconfirmed LocalRoute unless I’m missing something.  JWD)
        *  LocalRoute.State := Unconfirmed (if the next hop's
           Neighbor.State is Unknown) or Idle (if the next hop's
           Neighbor.State is Confirmed)
@@ -1631,13 +1663,15 @@
    7.  If this update results in LocalRoute.State of Active or Idle,
        which matches a route request which is still in progress, the
        associated route request retry timers can be cancelled.
-
+(can? not SHOULD or MUST? JWD)
    If this update to the Local Route Set results in multiple LocalRoutes
    to the same address, the best LocalRoute will be Unconfirmed.  In
    order to improve the route used for forwarding, the router SHOULD try
    to determine if the link to the next hop of that LocalRoute is
    bidirectional, by using that LocalRoute to forward future RREPs and
    request acknowledgements (see Section 7.2.1).
+(we seem to be missing when the Route Information Base should be updated based on the new Local Route Set.  JWD)
+
 
 6.8.  Suppressing Redundant Messages Using the Multicast Route Message
       Table
@@ -1658,7 +1692,9 @@
    Each AODVv2 router stores information about recently received route
    messages in the AODVv2 Multicast Route Message Table (Section 4.6).
 
-   To create a Multicast Route Message Table Entry:
+
+   Multicast Route Message Table Entries consist of:
+
 
    o  RteMsg.MessageType := RREQ or RREP
 
@@ -1684,6 +1720,8 @@
    o  RteMsg.Timestamp := CurrentTime
 
    o  RteMsg.RemoveTime := CurrentTime + MAX_SEQNUM_LIFETIME
+(This information is repeated later in this same section. Suggest making this just a list and updating the later section with the assignments as the later is incomplete. JWD)
+
 
    Entries in the Multicast Route Message Table SHOULD be maintained for
    at least RteMsg_ENTRY_TIME after the last Timestamp update in order
@@ -1707,8 +1745,7 @@

 Perkins, et al.           Expires July 21, 2016                [Page 30]
--
+ 
 Internet-Draft                   AODVv2                     January 2016

@@ -1758,6 +1795,10 @@
    o  RteMsg.Timestamp := CurrentTime
 
    o  RteMsg.RemoveTime := CurrentTime + MAX_SEQNUM_LIFETIME
+(this list is incomplete and should be replaced with the one presented earlier. JWD)
+
+
+

@@ -1769,15 +1810,18 @@
 Internet-Draft                   AODVv2                     January 2016

-   Where the message is determined not redundant before Step 3, it MUST
-   be regenerated or responded to.  Where the message is determined not
+
+
+   When a message is determined to be not redundant before Step 3, it MUST
+   be regenerated or responded to.  Whena message is determined to be not
    redundant in Step 3, it MAY be suppressed to avoid extra control
    traffic.  However, since the processing of the message will result in
    an update to the Local Route Set, the message SHOULD be regenerated
    or responded to, to ensure other routers have up-to-date information
-   and the best metrics.  If not regenerated, the best route may not be
-   found.  Where necessary, regeneration or response is performed using
-   the processes in Section 7.
+   and the best metrics.  If the message is not regenerated, the best route may not be
+   found.  Regeneration and response is to be performed using
+   the processes outlined in Section 7.
+
 
 6.9.  Local Route Set Maintenance
 
@@ -1820,35 +1864,49 @@

+
+
+
 Perkins, et al.           Expires July 21, 2016                [Page 32]
  
 Internet-Draft                   AODVv2                     January 2016

-      functions using a new sequence number, and that their messages
-      will not be classified as stale and ignored.  A LocalRoute with
+
+
+      functions using a new sequence number.  A LocalRoute with
       LocalRoute.State set to Active or Idle can remain in the Local
       Route Set after removing the sequence number, but if
       LocalRoute.State is Invalid, or later becomes Invalid, the
       LocalRoute MUST be expunged from the Local Route Set.
+(it’s not clear to me what the use case of removing the sequence number while the route is still active will achieve. suggest removal or some small explination JWD)
+
 
    LocalRoutes can become Invalid before a timeout occurs:
 
    o  If a link breaks, all LocalRoutes using that link for
       LocalRoute.NextHop MUST immediately have LocalRoute.State set to
       Invalid.
+(how would one know if a link breaks? Assuming some external process or notification. 
+JWD) 
+
 
    o  If a Route Error (RERR) message containing the route is received,
       either from LocalRoute.NextHop, or with PktSource set to a Router
       Client address, LocalRoute.State MUST immediately be set to
       Invalid.
+(it’s not clear to me how the RERR’s are identified consider rewording to make it more clear. JWD)
+
 
    LocalRoutes are also updated when Neighbor.State is updated:
+
 
    o  While the value of Neighbor.State is set to Unknown, any routes in
       the Local Route Set using that neighbor as a next hop MUST have
       LocalRoute.State set to Unconfirmed.
+(Shouldn’t they also be removed from the Route Information Base? JWD)
+
 
    o  When the value of Neighbor.State is set to Confirmed, the
       Unconfirmed routes in the Local Route Set using that neighbor as a
@@ -1874,6 +1932,10 @@
    routers.  However, subsequent data packets will cause a new route
    discovery attempt to be initiated by the router with the source
    address of the data packet configured as a Router Client.
+(This will only occur when a target starts sending packets to an originator address when only part of the reverse path has been confirmed, in the middle of a route request from originator to source? Am I correct?  If so then the route request would have been sent normally and I see no issue. JWD)
+
+
+

@@ -2026,22 +2088,28 @@
 
 7.1.1.  RREQ Generation
 
-   An RREQ is generated when an IP packet needs to be forwarded for a
+
+   A RREQ is generated when an IP packet needs to be forwarded for a
    Router Client, and no valid route currently exists for the packet's
    destination in the Routing Information Base.
 
-   Before creating an RREQ, the router SHOULD check if an RREQ has
+
+   Before creating a RREQ, the router SHOULD check if a RREQ has
    recently been sent for the requested destination.  If so, and the
    wait time for a reply has not yet been reached, the router SHOULD
    continue to await a response without generating a new RREQ.  If the
    timeout has been reached, a new RREQ MAY be generated.  If buffering
    is configured, incoming IP packets awaiting this route SHOULD be
    buffered until the route discovery is completed.
+(perhaps I’m missing a table or something but I don’t remember any RREQ table or list being described which i can check if a RREQ has been recently sent with associated timers. If there is such a table then it should be mentioned here. If there isn’t aon there should be. JWD!)
+
 
    If the limit for the rate of AODVv2 control message generation has
    been reached, no message SHOULD be generated.  If approaching the
    limit, the message should be sent if the priorities in Section 6.5
    allow it.
+(There is no defined behavior here. Approaching the limit? Section 6.5 outlines which messages are more important but now how to decide to allow them to be transmitted or not. JWD)
+
 
    To generate the RREQ, the router (referred to as RREQ_Gen) follows
    this procedure:
@@ -2159,6 +2227,8 @@
        *  If so, generate an RREP as specified in Section 7.2.1.
 
        *  If not, continue to RREQ regeneration.
+(this was good JWD)
+

@@ -2183,6 +2253,8 @@
    AODVv2 control message generation has been reached.  If approaching
    the limit, the message should be sent if the priorities in
    Section 6.5 allow it.
+(this again doesn’t describe a defined behaivor.  approaching athe limit? and 6.5 doesn’t disalow anything JWD)
+
 
    The procedure for RREQ regeneration is as follows:
 
@@ -2207,6 +2279,8 @@
        *  The ValidityTime is either the time limit the previous AODVv2
           router specified, or the time limit this router wishes to
           impose, whichever is lower.
+There might be a problem with very short validity times on very low metric routes in that they will be selected regardless of the time. Not a problem but something that could cause issues. Perhaps some minimum time should be mandated. JWD)
+
 
    This AODVv2 message is used to create a corresponding [RFC5444]
    message (see Section 8) which is multicast, by default, to LL-MANET-
@@ -2220,8 +2294,7 @@

 Perkins, et al.           Expires July 21, 2016                [Page 39]
--
+ 
 Internet-Draft                   AODVv2                     January 2016

@@ -2313,6 +2386,8 @@
    A Route Reply message is generated when a Route Request arrives,
    requesting a route to an address which is configured as a Router
    Client of the AODVv2 router.
+(please specify what in the message matches the configured Router Client. JWD)
+
 
    Before creating an RREP, the router SHOULD check if the corresponding
    RREQ is redundant, i.e., a Route Reply has already been generated in
@@ -2320,6 +2395,8 @@
    message generation has been reached.  If so, the RREP SHOULD NOT be
    created.  If approaching the limit, the message should be sent if the
    priorities in Section 6.5 allow it.
+(same as before JWD)
+
 
    The RREP will follow the path of the route to OrigAddr.  If the best
    route to OrigAddr in the Local Route Set is Unconfirmed, the link to
@@ -2362,6 +2439,8 @@
    3.  If the link to the next hop router toward OrigAddr is not known
        to be bidirectional, include the AckReq with the address of the
        intended next hop router
+(please include section describing AckReq formating JWD)
+
 
    4.  Set Address List := {OrigAddr, TargAddr}
 
@@ -2439,7 +2518,7 @@
 
    6.   If the AckReq is present, check the intended recipient of the
         received RREP
-
+(please specify how one determines how to check the intended recipient.  What data element in the AckReq matches what ?  JWD)
         *  If the receiving router is the intended recipient, send an
            acknowledgement as specified in Section 7.3 and continue
            processing.
@@ -2482,7 +2561,7 @@
         *  If not, a Route Error message SHOULD be transmitted to
            TargAddr according to Section 7.4.1 and the RREP SHOULD be
            discarded and not regenerated.
-
+(again mostly good here JWD)
 7.2.3.  RREP Regeneration
 
    A received Route Reply message is regenerated toward OrigAddr.
@@ -2494,11 +2573,17 @@
    the RREP, in the same way it MAY choose not to regenerate an RREQ
    (see Section 7.1.3), though this could decrease connectivity in the
    network or result in non-optimal paths.
+(This seems like a bad idea to do on the reverse path.  It would be a good way to attack a network Forward RREQ and drop all RREP.  JWD)
+
 
    The RREP SHOULD NOT be regenerated if the limit for the rate of
    AODVv2 control message generation has been reached.  If approaching
    the limit, the message should be sent if the priorities in
    Section 6.5 allow it.
+(The undefined approaching the limit thing again JWD)
+
+
+

@@ -2510,14 +2595,11 @@
 Internet-Draft                   AODVv2                     January 2016

-   If the link to the next hop neighbor on the LocalRoute to OrigAddr is
-   not yet confirmed as bidirectional (as described in Section 6.2), the
-   RREP MUST include AckReq set to the intended next hop address, in
-   order to perform next hop monitoring.  If bidirectionality is already
-   confirmed, the AckReq can be omitted.  The AckReq indicates that an
-   acknowledgement to the RREP is requested in the form of a Route Reply
-   Acknowledgement (RREP_Ack) from the intended next hop router, within
-   RREP_Ack_SENT_TIMEOUT.
+
+
+ 
+(All of the above is redundant. JWD)
+
 
    The procedure for RREP regeneration is as follows:
 
@@ -2532,6 +2614,8 @@
    4.  If the link to the next hop router toward OrigAddr is not known
        to be bidirectional, include the AckReq with the address of the
        intended next hop router
+(THere needs to be some sort of table which is updated  with timer associated with this AckReq JWD)
+
 
    5.  Set AddressList, PrefixLengthList, TargSeqNum and MetricType to
        the values in the received RREP
@@ -2595,6 +2679,8 @@
 
        *  If the sender has Neighbor.State set to Blacklisted after the
           update, ignore this RREQ for further processing.
+(Shouldn’t this check come before updating?  The only way the Neighbor.State is set to Blacklisted is that its already Blacklisted and there is no need to update the Neighbor Table. JWD)
+
 
    2.  Check if the RREP_Ack was expected from the IP source address of
        the RREP_Ack, in response to an RREP sent previously by this
@@ -2604,6 +2690,8 @@
           timeouts.
 
        *  If it was not expected, no actions are required.
+(What are we checking! What table or timer is there to check? JWD!)
+
 
 7.4.  Route Error (RERR) Message
 
@@ -2681,21 +2769,21 @@
 Internet-Draft                   AODVv2                     January 2016

-      Routing Information Base for its destination, the source of the
+
+
+      Routing Information Base for its destination. The source of the
       packet needs to be informed that the route to the destination of
       the packet does not exist.  The RERR generated MUST include
       PktSource set to the source address of the IP packet, and MUST
       contain only one unreachable address in the AddressList, i.e., the
       destination address of the IP packet.  RERR_Gen MUST discard the
-      IP packet that triggered generation of the RERR.  The prefix
-      length and sequence number MAY be included if known from an
-      Invalid LocalRoute entry to PktSource.  The MetricTypeList MUST
-      also be included if a MetricType can be determined from the IP
-      packet or an existing Invalid LocalRoute to the unreachable
-      address.
+      IP packet that triggered generation of the RERR.  The prefix length,
+      sequence number and metric type SHOULD be included if known from
+      an Invalid LocalRoute to the unreachable address.
+
 
    o  When an RREP message cannot be regenerated because the LocalRoute
-      to OrigAddr has been lost or is Invalid, RREP_Gen needs to be
+      to OrigAddr has been lost or is Invalid. RREP_Gen needs to be
       informed that the route to OrigAddr does not exist.  The RERR
       generated MUST include PktSource set to the TargAddr of the RREP,
       and MUST contain only one unreachable address in the AddressList,
@@ -2720,11 +2808,15 @@
    router SHOULD determine whether an RERR has recently been sent with
    the same unreachable address and PktSource, and SHOULD avoid creating
    duplicate RERR messages.
+(How is this done?  There is no table with recently sent RERR messages to check. There needs to be though. JWD!)
+
 
    The RERR SHOULD NOT be generated if the limit for the rate of AODVv2
    control message generation has been reached.  If approaching the
    limit, the message should be sent if the priorities in Section 6.5
    allow it.
+(The undefined approaching the limit thing again. JWD)
+
 
    Incidentally, if an AODVv2 router receives an ICMP error packet to or
    from the address of one of its Router Clients, it forwards the ICMP
@@ -2831,14 +2923,14 @@
        *  If the prefix length is different, create a new LocalRoute
           with the unreachable address, and its prefix length and
           sequence number, and set LocalRoute.State to Invalid.
-
+(it’s not clear to me what the point of this invalid route is. It doesn’t get used and doesn’t remove any existing routes. JWD)
        *  Update the sequence number on the existing LocalRoute, if the
           reported sequence number is determined to be newer using the
           comparison technique described in Section 4.4.
 
    3.  Check if there are unreachable addresses which MUST be reported
        in a regenerated RERR
-
+(How do we check? It’s not at all clear how this is done. JWD!)
        *  If so, regenerate the RERR as detailed in Section 7.4.3.
 
        *  If not, take no further action.
@@ -2858,6 +2950,8 @@
    the rate of AODVv2 control message generation has been reached.  If
    approaching the limit, the message should be sent if the priorities
    in Section 6.5 allow it.
+(Approaching the limit thing again JWD)
+
 
    The procedure for RERR regeneration is as follows:
 
@@ -2869,8 +2963,9 @@
    3.  If PktSource was included in the original RERR, and PktSource is
        not a Router Client, copy it into the regenerated RERR
 
+
    4.  For each LocalRoute that needs to be reported:
-
+(it’s not clear how we know which localroutes need to be reported JWD!)
        *  Insert LocalRoute.Address into the AddressList.
 
        *  Insert LocalRoute.PrefixLength into PrefixLengthList, if known
@@ -2984,6 +3079,8 @@
 8.1.2.  Message TLV Block
 
    An RREQ contains no Message TLVs.
+(this ins’t mandatory, right? Just AODVv2 doesn’t define any message TLVs for use with RREQ JWD)
+
 
 8.1.3.  Address Block
 
@@ -3083,6 +3180,8 @@
 8.2.2.  Message TLV Block
 
    An RREP contains no Message TLVs.
+(This isn’t mandatory is it? just none are defined by AODVv2. JWD)
+
 
 8.2.3.  Address Block
 
@@ -3174,14 +3273,24 @@
 8.3.2.  Message TLV Block
 
    An RREP_Ack contains no Message TLVs.
+(Mandatory or just not defined? JWD)
+
 
 8.3.3.  Address Block
 
+
    An RREP_Ack contains no Address Block.
-
+(Mandatory or just not defined? Guessing mandatory on this one. JWD)
 8.3.4.  Address Block TLV Block
 
    An RREP_Ack contains no Address Block TLV Block.
+(Mandatory or just not defined? Guessing mandatory on this one. JWD)
+
+
+
+
+
+

@@ -3216,6 +3325,10 @@
 8.4.2.  Message TLV Block
 
    An RERR contains no Message TLVs.
+(Mandatory or just not defined? JWD)
+
+
+
 
 8.4.3.  Address Block
 
@@ -3292,7 +3405,7 @@
    As in any externally-attached network, AODVv2 routers and Router
    Clients that wish to be reachable from the external network MUST have
    IP addresses within the ENAR's routable and topologically correct
-   prefix (i.e., 191.0.2.0/24 in Figure 4).  This AODVv2 network and
+   prefix (e.g.., 191.0.2.0/24 in Figure 4).  This AODVv2 network and
    networks attached to routers within it will be advertised to the
    external network using procedures which are out of scope for this
    specification.
@@ -3333,14 +3446,14 @@
    route toward an address on the external network, it uses the normal
    AODVv2 route discovery for that IP Destination Address.  The ENAR
    MUST respond to RREQ on behalf of all external network destinations,
-   i.e., destinations not on the configured 191.0.2.0/24 network.  RREQs
-   for addresses inside the AODVv2 network, i.e. destinations on the
+   e.g.., destinations not on the configured 191.0.2.0/24 network.  RREQs
+   for addresses inside the AODVv2 network, e.g. destinations on the
    configured 191.0.2.0/24 network, are handled using the standard
    processes described in Section 7.
 
    When an IP packet from an address on the external network destined
    for an address in the AODVv2 MANET reaches the ENAR, if the ENAR does
-   not have a route toward that exact destination in its Routing
+   not have a route toward that destination in its Routing
    Information Base, it will perform normal AODVv2 route discovery for
    that destination.
 
@@ -3350,7 +3463,7 @@
 10.  Optional Features
 
    A number of optional features for AODVv2, associated initially with
-   AODV, MAY be useful in networks with greater mobility or larger
+   AODV, may be useful in networks with greater mobility or larger
    populations, or networks requiring reduced latency for application
    launches.  These features are not required by minimal
    implementations.
@@ -3386,7 +3499,8 @@
    destination can be sent unicast to these precursors instead of
    multicast to all AODVv2 routers.
 
-   Since an RERR will be regenerated if it comes from a next hop on a
+
+   Since a RERR will be regenerated if it comes from a next hop on a
    valid LocalRoute, the RERR SHOULD ideally be sent backwards along the
    route that the source of the traffic uses, to ensure it is
    regenerated at each hop and reaches the traffic source.  If the
@@ -3444,6 +3558,10 @@
 
    When a LocalRoute is expunged, any precursor list associated with it
    MUST also be expunged.
+
+
+(I feel like this is underspecified and would be better served in a separate document like Intermediate RREP.  Is there anything wrong with leaving the behavior required a MAY and describing that behavior in another draft? JWD)
+
 
 10.3.  Intermediate RREP
 
@@ -3523,6 +3641,12 @@
    at any AODVv2 router using a greater value for MAX_SEQNUM_LIFETIME.
    This would delay route discovery from and to the re-initializing
    router.
+(is MAX_SEQNUM_LIFETIME the only parameter which MUST be configured the same across the network?  JWD)
+
+
+
+
+

@@ -3904,6 +4028,10 @@
    defined in [RFC7182] to protect against replay attacks, using SeqNum
    from RERR_Gen as the value in the TIMESTAMP TLV.
 
+
+(I did NOT review the security section JWD)
+
+
 14.  Acknowledgments
 
    AODVv2 is a descendant of the design of previous MANET on-demand

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 2 Mar 2016 10:02:38 +0000

Obviously (if you consider time zones) I haven’t done more than skim through Justin’s extensive comments.

But I noticed one thing. (The text is the draft, the parenthesis is Justin’s comment.)

   AODVv2 supports routers with multiple interfaces and multiple IP
   addresses per interface.   (this should be disallowed as it can form non valid routes with uni-directional links JWD)

I don’t know what case Justin is suggesting, it would be useful to have an example to determine if this is a problem or not. Or which of the two cases (multiple interfaces or addresses) there’s a suggested problem with.

Multiple interfaces are really an essential, and multiple addresses per interface highly desirable. The latter might introduce inefficiencies (searching again for a destination because using a different address).

On the inefficiency, I’ve wondered if couldn’t be handled by an RREP reporting not just the searched for address, but also any other addresses that are supported. I’ve also wondered if this would help with the gateway issue (e.g. you search for a.b.c.d and get an RREP saying a.b.c.d because supporting 0.0.0.0/32 (how to report that and not break maximum prefix matching would be needed, a.b.c.d/0 is really want you would want to say - whether that’s allowed is something I’ve never got a definitive answer to). But note that my use of “wondered” is because this is speculative, it may well break. Especially as I don’t know what Justin’s case is.

In NHDP, we added (following requests from the WG, Stan in particular IIRC) the more tricky case of the same address used on different interfaces. We had to limit that, so any receiving interface would only ever receive one or the other (which otherwise is not a requirement in NHDP) - which might in a real case be e.g. different frequencies (timeslots, codes, etc.) I have no idea whether this is easy or hard in AODVv2 (the devil is in the details). I don’t know if Stan (for example) still has this requirement.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

From: manet [mailto:[email-masked]] On Behalf Of Justin Dean
Sent: 02 March 2016 04:19
To: [email-masked]
Subject: [manet] AODVv2 reivew

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

I've completed my review of the draft 13 of AODVv2.  Attached is my updated with comments (marked JWD) and various inline fixes draft/review.   I've also included a diff to illustrate the inline fixes.  I did not review the security section.  I did have a few major comments which are marked with JWD!

Justin
********************************************************************
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: "Ratliff, Stanley" <[email-masked]>
Date: Wed, 2 Mar 2016 14:17:47 +0000

Chris,

The use case comes from routers implementing ip unnumbered. It can cause the same address to be placed on multiple interfaces. From what I recall, its especially prevalent with PPPoE interfaces, as they are virtual; cloned from a common template.

Regards,
Stan

--

************************

_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________

---

From: Justin Dean <[email-masked]>
Date: Wed, 2 Mar 2016 09:18:16 -0500

On Wed, Mar 2, 2016 at 5:02 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

>    addresses per interface.   (this should be disallowed as it can form
> non valid routes with uni-directional links JWD)
>
>
>
> I don’t know what case Justin is suggesting, it would be useful to have an
> example to determine if this is a problem or not. Or which of the two cases
> (multiple interfaces or addresses) there’s a suggested problem with.
>
>

The issue arises when two routers have two interfaces, and those interfaces
are given the same address on each router, and those links are
uni-directional.  I'll attempt to illustrate.

              InterfaceA (192.168.1.1) --------------> InterfaceA
(192.168.1.2)
YRouter
ZRouter
              InterfaceB (192.168.1.1) <-------------  InterfaceB
(192.168.1.2)

YRouter sends a RREQ on both interfaces for 192.168.1.2.  ZRouter gets the
message on InterfaceA from 192.168.1.1. ZRouter response is a RREP
multicast (as there is not yet a confirmed route) with an Ack request.
YRouter receives the message on interface B from 192.168.1.2 and installs
the route to 192.168.1.2 on interfaceB. This is broken.  The ack reply,
from YRouter, will be sent unicast to Zrouter on InterfaceB  but will not
get there.  There is no way to know which interface a message was received
on when both interfaces have the same address. This is what should be
disallowed. As far as I can tell multiple addresses per interface is fine.

Justin

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Wed, 2 Mar 2016 15:19:56 +0000

Chris,

To answer a question with a question – Will anyone want to run AODVv2 over a collection of PPPoE links? I doubt it.  I don’t have any great issues with disallowing it. That would also resolve Justin’s uni-directional failure case, since the common addresses wouldn’t be assigned to multiple interfaces in the first place.

Other thoughts?

Regards,
Stan

From: Christopher Dearlove [mailto:[email-masked]]
Sent: Wednesday, March 02, 2016 9:52 AM
To: Ratliff, Stanley <[email-masked]>
Cc: Dearlove, Christopher (UK) <[email-masked]>; Justin Dean <[email-masked]>; [email-masked]
Subject: Re: [manet] AODVv2 reivew

The question is, is that important for AODVv2? Should it allow it? Are there any problems?

As I've just said in another post, the step beyond that of routers sharing an address is a problem, but I don't expect it to be relevant as people shouldn't do it (it could be explicitly said). Though what I didn't address there is the impact on gateways. We resolved that in OLSRv2 with two different kinds of advertised address, one shareable among routers, not tied to an interface, one shareable among interfaces but only on the same router and only if not commonly hearable.

--
Christopher Dearlove
[email-masked]<mailto:[email-masked]> (iPhone)
[email-masked]<mailto:[email-masked]> (home)

On 2 Mar 2016, at 14:17, Ratliff, Stanley <[email-masked]<mailto:[email-masked]>> wrote:
Chris,

Regards,
Stan

--

************************

_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________
_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Wed, 2 Mar 2016 16:02:31 +0000

Chris,

I’m digging deep into the memory banks here… ;-) But from what I remember, there were discussions at my old employer about the possibilities of implementing & running OLSRv2 in the router. Our implementations at the time were based on RFC5578 – a collection of PPPoE links, running over an RF net. For that, “ip unnumbered” would have been a requirement.  Since DLEP is *not* PPPoE based, it pretty much mitigates the requirement.

Regards,
Stan

Sent: Wednesday, March 02, 2016 10:55 AM

I'm not sure why the case was insisted on for OLSRv2 (though we were happy to oblige to the maximum extent possible) and isn't required for AODVv2, but it wasn't my requirement.

As for the different addresses on different platforms, I think we are agreed, it was the point I made. (Gateways may be a related but different issue.)

--
Christopher Dearlove
[email-masked]<mailto:[email-masked]>

On 2 Mar 2016, at 15:19, Ratliff, Stanley <[email-masked]<mailto:[email-masked]>> wrote:
Chris,

Other thoughts?

Regards,
Stan

From: Christopher Dearlove [mailto:[email-masked]]
Sent: Wednesday, March 02, 2016 9:52 AM
To: Ratliff, Stanley <[email-masked]<mailto:[email-masked]>>
Cc: Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>>; Justin Dean <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [manet] AODVv2 reivew

Regards,
Stan

--

************************

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 2 Mar 2016 20:03:19 +0100

A question and a comment:

1) I thought this was about AODVv2, not DLEP, so I fail to see 
     why it is relevant to bring DLEP into this discussion?

2) I think that the argument bring made here is the logical fallacy called
          "moving the goal posts". 
  
There are use cases for "same IP address on multiple interfaces" and I believe they should be supported (as Chris wrote that we did for OLSRv2 "to the maximum extend possible"), also by this protocol.

Thomas

> On 02 Mar 2016, at 17:02, Ratliff, Stanley <[email-masked]> wrote:
> 
> Chris,
>  
> [email-masked]
> 
> On 2 Mar 2016, at 15:19, Ratliff, Stanley <[email-masked]> wrote:
> 
> Chris,
>  
> [email-masked] (iPhone)
> [email-masked] (home)
> 
> On 2 Mar 2016, at 14:17, Ratliff, Stanley <[email-masked]> wrote:
> 
> Chris,
>  
> [email-masked]
> [email-masked]

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 2 Mar 2016 14:22:50 -0500

On Wed, Mar 2, 2016 at 2:03 PM, Thomas Heide Clausen <[email-masked]
> wrote:

>      why it is relevant to bring DLEP into this discussion?

I was asked, implicitly, why *I* was pushing (since I was repeatedly named)
for a set of requirements *then*, and not so *now* - specifically, support
of ip unnumbered on interfaces. It's relevant to explain that it was based
on companion technology - technology that I no longer require. I would
think that was self-evident. Apparently not.

>          * "moving the goal posts"*.
>

You are correct in that there is a logical fallacy in play here. Yours. All
I've said is (and I quote): "I don’t have any great issues with disallowing
it." That's an *opinion*, not an *edict*; nor does it connote moving of
goal posts, or any other associated hardware. At least I believe that,
according to IETF rules, I still get to express opinions, as a WG
participant... or did some RFC slip past that I'm not aware of?

Stan

>
> There are use cases for "same IP address on multiple interfaces" and I
> believe they should be supported (as Chris wrote that we did for OLSRv2 "to
> the maximum extend possible"), also by this protocol.
>
> Thomas
>
>
> I’m digging deep into the memory banks here… ;-) But from what I remember,
> there were discussions at my old employer about the possibilities of
> implementing & running OLSRv2 in the router. Our implementations at the
> time were based on RFC5578 – a collection of PPPoE links, running over an
> RF net. For that, “ip unnumbered” would have been a requirement.  Since
> DLEP is **not** PPPoE based, it pretty much mitigates the requirement.
>
>
>
> Regards,
>
> Stan
>
>
>
>
>
> *From:* Christopher Dearlove [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Wednesday, March 02, 2016 10:55 AM
> *To:* Ratliff, Stanley <[email-masked]>
> *Cc:* Dearlove, Christopher (UK) <[email-masked]>; Justin
> Dean <[email-masked]>; [email-masked]
> *Subject:* Re: [manet] AODVv2 reivew
>
>
>
> I'm not sure why the case was insisted on for OLSRv2 (though we were happy
> to oblige to the maximum extent possible) and isn't required for AODVv2,
> but it wasn't my requirement.
>
>
>
> As for the different addresses on different platforms, I think we are
> agreed, it was the point I made. (Gateways may be a related but different
> issue.)
>
> --
>
> Christopher Dearlove
>
> To answer a question with a question – Will anyone want to run AODVv2 over
> a collection of PPPoE links? I doubt it.  I don’t have any great issues
> with disallowing it. That would also resolve Justin’s uni-directional
> failure case, since the common addresses wouldn’t be assigned to multiple
> interfaces in the first place.
>
>
>
> Other thoughts?
>
>
>
> Regards,
>
> Stan
>
>
>
>
>
> *From:* Christopher Dearlove [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Wednesday, March 02, 2016 9:52 AM
> *To:* Ratliff, Stanley <[email-masked]>
> *Cc:* Dearlove, Christopher (UK) <[email-masked]>; Justin
> Dean <[email-masked]>; [email-masked]
> *Subject:* Re: [manet] AODVv2 reivew
>
>
>
> As I've just said in another post, the step beyond that of routers sharing
> an address is a problem, but I don't expect it to be relevant as people
> shouldn't do it (it could be explicitly said). Though what I didn't address
> there is the impact on gateways. We resolved that in OLSRv2 with two
> different kinds of advertised address, one shareable among routers, not
> tied to an interface, one shareable among interfaces but only on the same
> router and only if not commonly hearable.
>
>
> --
>
> Christopher Dearlove
>
> The use case comes from routers implementing ip unnumbered. It can cause
> the same address to be placed on multiple interfaces. From what I recall,
> its especially prevalent with PPPoE interfaces, as they are virtual; cloned
> from a common template.
>
>
>
> Regards,
>
> Stan
>
>
>
>
>
>
>
> In NHDP, we added (following requests from the WG, Stan in particular
> IIRC) the more tricky case of the same address used on different
> interfaces. We had to limit that, so any receiving interface would only
> ever receive one or the other (which otherwise is not a requirement in
> NHDP) - which might in a real case be e.g. different frequencies
> (timeslots, codes, etc.) I have no idea whether this is easy or hard in
> AODVv2 (the devil is in the details). I don’t know if Stan (for example)
> still has this requirement.
>
>
>
> *-- *
>
> ************************
>
>

---

From: Justin Dean <[email-masked]>
Date: Wed, 2 Mar 2016 14:27:10 -0500

To me this isn't a big deal (unless it isn't fixed).  Two ways to fix it.
Disallow different interfaces to have the same address.  Two mandate any
interfaces with the same IP address MUST be bridged into a single logical
interface (i.e. both interfaces send and receive the same traffic).  Either
way fixes the issue.

Justin

On Wed, Mar 2, 2016 at 2:22 PM, Stan Ratliff <[email-masked]> wrote:

>
>
> On Wed, Mar 2, 2016 at 2:03 PM, Thomas Heide Clausen <
> [email-masked]> wrote:
>
> I was asked, implicitly, why *I* was pushing (since I was repeatedly
> named) for a set of requirements *then*, and not so *now* - specifically,
> support of ip unnumbered on interfaces. It's relevant to explain that it
> was based on companion technology - technology that I no longer require. I
> would think that was self-evident. Apparently not.
>
>
>>
> You are correct in that there is a logical fallacy in play here. Yours.
> All I've said is (and I quote): "I don’t have any great issues with
> disallowing it." That's an *opinion*, not an *edict*; nor does it connote
> moving of goal posts, or any other associated hardware. At least I believe
> that, according to IETF rules, I still get to express opinions, as a WG
>> I’m digging deep into the memory banks here… ;-) But from what I
>> remember, there were discussions at my old employer about the possibilities
>> of implementing & running OLSRv2 in the router. Our implementations at the
>> I'm not sure why the case was insisted on for OLSRv2 (though we were
>> happy to oblige to the maximum extent possible) and isn't required for
>> AODVv2, but it wasn't my requirement.
>>
>>
>>
>> To answer a question with a question – Will anyone want to run AODVv2
>> over a collection of PPPoE links? I doubt it.  I don’t have any great
>> issues with disallowing it. That would also resolve Justin’s
>> uni-directional failure case, since the common addresses wouldn’t be
>> assigned to multiple interfaces in the first place.
>>
>>
>>
>> Other thoughts?
>>
>>
>>
>> Regards,
>>
>> Stan
>>
>>
>>
>>
>>
>> As I've just said in another post, the step beyond that of routers
>> sharing an address is a problem, but I don't expect it to be relevant as
>> people shouldn't do it (it could be explicitly said). Though what I didn't
>> address there is the impact on gateways. We resolved that in OLSRv2 with
>> two different kinds of advertised address, one shareable among routers, not

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 2 Mar 2016 20:30:44 +0100

...but one of the two ways limits applicability. 

For what it is worth, I have been bringing this very issue up for many, many review cycles (I think, as far as a year back). I guess I should be glad that it is finally being discussed. 

> On 02 Mar 2016, at 20:27, Justin Dean <[email-masked]> wrote:
> 
> To me this isn't a big deal (unless it isn't fixed).  Two ways to fix it.  Disallow different interfaces to have the same address.  Two mandate any interfaces with the same IP address MUST be bridged into a single logical interface (i.e. both interfaces send and receive the same traffic).  Either way fixes the issue.
> 
> Justin
> 
>>> On Wed, Mar 2, 2016 at 2:03 PM, Thomas Heide Clausen <[email-masked]> wrote:
>> I was asked, implicitly, why *I* was pushing (since I was repeatedly named) for a set of requirements *then*, and not so *now* - specifically, support of ip unnumbered on interfaces. It's relevant to explain that it was based on companion technology - technology that I no longer require. I would think that was self-evident. Apparently not. 
>>  
>>> 
>> You are correct in that there is a logical fallacy in play here. Yours. All I've said is (and I quote): "I don’t have any great issues with disallowing it." That's an *opinion*, not an *edict*; nor does it connote moving of goal posts, or any other associated hardware. At least I believe that, according to IETF rules, I still get to express opinions, as a WG participant... or did some RFC slip past that I'm not aware of? 
>> 
>> Stan
>> 
>>  
>>>

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 2 Mar 2016 19:36:46 +0000

I'm not set on including the case. It's one that should be discussed here, but the answer could go either way. It just needs to be documented. I think it's clear that the non-reuse of addresses between routers needs a comment - but what about gateways?

> On 2 Mar 2016, at 19:03, Thomas Heide Clausen <[email-masked]> wrote:
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 2 Mar 2016 20:37:41 +0100

> On 02 Mar 2016, at 20:22, Stan Ratliff <[email-masked]> wrote:
> 
> 
> 
> You are correct in that there is a logical fallacy in play here. Yours. All I've said is (and I quote): "I don’t have any great issues with disallowing it." That's an *opinion*, not an *edict*; nor does it connote moving of goal posts, or any other associated hardware.

Saying "supporting X is an unequivocal MUST", then (when it suits him, as a document author) saying "disallowing X is fine by me" is very much "moving the goal posts".

> At least I believe that, according to IETF rules, I still get to express opinions, as a WG participant... or did some RFC slip past that I'm not aware of? 

Of course you get to express opinions.
But you do not get to shut down discussion, including calling out when you move the goal posts.

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 2 Mar 2016 19:41:45 +0000

This appears to be going backwards. The example you gave if a problem was different routers with the same address. Not surprising that's a problem. But your original comment and this are suggesting a problem even when on the same router. Of course broadcast messages such as RREQs need to go out on all participating interfaces.

There's an address model (regarding the relationship of addresses, interfaces and routers) in NHDP. Which parts of it couldn't be reused?

> On 2 Mar 2016, at 19:27, Justin Dean <[email-masked]> wrote:
>

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 2 Mar 2016 14:52:17 -0500

On Wed, Mar 2, 2016 at 2:37 PM, Thomas Heide Clausen <[email-masked]

> moving of goal posts, or any other associated hardware.
>
>
> Saying "supporting X is an unequivocal MUST", then (when it suits him, as
> a document author) saying "disallowing X is fine by me" is very much
> "moving the goal posts".
>

"... when it suits him, as a document author".... Your tin-foil hat is too
tight, and needs adjusting. And again, I merely said "I don't have any
great issues with disallowing it". Different than "it's fine by me".

>
> At least I believe that, according to IETF rules, I still get to express
> opinions, as a WG participant... or did some RFC slip past that I'm not
> aware of?
>
>

Nobody has shut down discussions. No goal posts have been moved. To state
so is fallacious.

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 2 Mar 2016 19:58:13 +0000

Meanwhile, back at the issue. OLSRv2 was requested/required (I don't care which) to support the case. There is a use for it, but it's possibly narrower than it was. Does anyone have a use? If not, does anyone else think it should be included because it might. And importantly, is it actually trivial or hard? Would it need the NHDP caveat on no common reception?

> On 2 Mar 2016, at 19:52, Stan Ratliff <[email-masked]> wrote:
> 
> 
> 
>> On Wed, Mar 2, 2016 at 2:37 PM, Thomas Heide Clausen <[email-masked]> wrote:
>> 
>> 
> "... when it suits him, as a document author".... Your tin-foil hat is too tight, and needs adjusting. And again, I merely said "I don't have any great issues with disallowing it". Different than "it's fine by me". 
>  
>> 
> Nobody has shut down discussions. No goal posts have been moved. To state so is fallacious.
>  
>> 
>> 
>>> Stan
>>> 
>>>  
>>>>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 2 Mar 2016 21:22:11 +0100

I think that I have stated that I know of an use for it.

-- 
Thomas Heide Clausen
http://www.thomasclausen.org

"Today's scientists have substituted mathematics for 
  experiments, and they wander off through equation 
  after equation, and eventually  build a structure 
  which has no relation to reality."
 - Nikola Tesla, 
    Modern Mechanics and Inventions, July, 1934

> On 2 mars 2016, at 20:58, Christopher Dearlove <[email-masked]> wrote:
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 2 Mar 2016 21:37:11 +0100

> On 2 mars 2016, at 20:52, Stan Ratliff <[email-masked]> wrote:
> 
> ".... Your tin-foil hat is too tight, and needs adjusting.

....

> Nobody has shut down discussions.

Two statements from the same email, which are rather difficult to reconcile.

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 2 Mar 2016 15:47:52 -0500

On Wed, Mar 2, 2016 at 3:37 PM, Thomas Heide Clausen <[email-masked]

> Two statements from the same email, which are rather difficult to

Not at all difficult to reconcile. In fact, the continued existence of this
email thread counters the "discussion shut down" meme.

But to echo Christopher - "Meanwhile, back at the problem"...

>From your email, I do not see an elaboration, other than the phrase "There
are use cases for "same IP address on multiple interfaces" and I believe
they should be supported (as Chris wrote that we did for OLSRv2 "to the
maximum extend possible"), also by this protocol."

My use case, from 7 years ago, was "I'm thinking about deploying the
protocol attached to RF devices that present themselves as a collection of
PPPoE links, and thus require a routing protocol supporting implementation
of ip unnumbered interfaces."

Would you please elaborate on your use case?

---

From: Henning Rogge <[email-masked]>
Date: Wed, 2 Mar 2016 21:59:56 +0100

> of ip unnumbered interfaces."

"Same IP on every intertface" is a good alternative to "linklocal IP
on interface, routeable IP on loopback".

Traceroute does strange things when your interfaces are just linklocal.

Henning Rogge

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 4 Mar 2016 20:31:29 -0800

Hello Justin,

I have devised some text for an expanded introduction.  Please take a look:

>    The Ad hoc On-Demand Distance Vector (AODVv2) protocol enables
>    dynamic, self-starting, multihop routing between participating mobile
>    nodes wishing to establish and maintain an ad hoc network. The
>    basic operations of the AODVv2 protocol are route discovery and
>    route maintenance.  AODVv2 does not require nodes to maintain routes
>    to destinations that are not in active communication.  AODVv2 allows
>    mobile nodes to respond to link breakages and changes in network
>    topology in a timely manner.  The operation of AODVv2 is loop-free,
>    and by avoiding the Bellman-Ford "counting to infinity" problem
>    offers quick convergence when the ad hoc network topology changes
>    (typically, when a node moves in the network).  When links break,
>    AODVv2 causes the affected set of nodes to be notified so that they
>    are able to invalidate the routes using the lost link.
>
>    One distinguishing feature of AODVv2 is its use of a destination
>    sequence number for each route entry.  The destination sequence
>    number is created by the destination to be included along with any
>    route information it sends to requesting nodes.  Using destination
>    sequence numbers ensures loop freedom and is simple to program.
>    Given the choice between two routes to a destination, a requesting
>    node is required to select the one with the greatest sequence number.
>
>    Compared to AODV [RFC3561], AODVv2 makes some features optional,
>    Message formats have been updated and made compliant with [RFC5444].
>    AODVv2 control messages are defined as sets of data, which are mapped
>    to message elements using the Generalized MANET Packet/Message Format
>    defined in [RFC5444] and sent using the parameters in [RFC5498].
>    Verification of link bidirectionality has been substantially 
> improved, and
>    additional refinements made for route timeouts and state management.

On 3/1/2016 8:18 PM, Justin Dean wrote:
>     The Ad Hoc On-demand Distance Vector Version 2 (AODVv2) routing
> (We jumped right in here would prefer some intro to AODV and how AODVv2 is derived from that work. JWD)
>

Regards,
Charlie P.

---

From: Justin Dean <[email-masked]>
Date: Sun, 06 Mar 2016 17:54:44 +0000

Looks good. I'd add a bit about MANET but looks better. OLSRv2 apparently
didn't mention wireless either so I'll not press. My point there was not
that it's restricted to those networks but designed for them.  MANET will
suffice.

Justin.

---

From: Lotte Steenbrink <[email-masked]>
Date: Tue, 8 Mar 2016 22:37:45 +0100

Hello Justin,
thank you very much for your thorough and helpful review. We've adopted most of your editorial changes and are currently mulling over the larger ones.
Some questions & comments for clarification:

From  2. Terminology:
------------------------------------

   Local Route
      An entry in the Local Route Set. (Local Route Set should have an entry, something simple and pointing to the section JWD)
(Later in the document LocalRoute is used pick one JWD)

LocalRoutes are not the same as the Local Route set, as they're actually entries of the Set, which is explained in section 4.5.  Local Route Set. Since LocalRoute is used before its explanation (in the     RERR (Route Error) definition of section 2), I can see how this is confusing. If my co-authors don't protest, I guess we can just eliminate that mention by changing "a valid LocalRoute" to "a valid route". Would that resolve this issue?

From  3.  Applicability Statement:
--------------------------------------------------

 (This should go in the intro JWD)

Which paragraph(s) are you referring to here?

From  4.5.  Local Route Set:
------------------------------------------

	(I’m assuming this is here to hint at the possibility of a unified router with multiple routing protocols playing nicely together JWD)

Yup. Should we be more explicit there?

	(I noticed that Unconfirmed is the only state that uses Route Request message instead of route message, is that intended?  Can unconfirmed route state only be reached through Route Request messages? JWD)

Yes. Until a route learned through a RREQ is validated by a RREP/RREP_Ack exchange, it is marked as unconfirmed (so that it can't erroneously be used until we know it is useful)

	(this seems like an entry that would always be full 1s on a route request if true that should be stated to make things more clear JWD)

I'm not sure I understand what you mean here, I'm assuming that prefixlength == address length with RREQs?

From 4.6.  Multicast Route Message Table:
---------------------------------------------------------------

	(would this ever be in a RREQ? If no then I suggest using words similar to “if RteMsg is an RREP JWD)
 
It would. RREQs can include the last known sequence number associated with TargSeqNum. see 7.1.1.  RREQ Generation:

   6.  For TargSeqNum:

       *  If an Invalid route exists in the Local Route Set matching
          TargAddr using longest prefix matching and has a valid
          sequence number, set TargSeqNum := LocalRoute.SeqNum.

From 5.  Metrics:
-----------------------

	AODVv2 enables the use of multiple metric types.  Each route
	discovery attempt indicates the metric type which is requested for
	the route.  Only one metric type may be used in each route discovery
	attempt.   (Already said this no need to say it again. JWD)

I don't quite understand this one– with the exception of “Only one metric type may be used in each route discovery attempt”, yes,
the rest of the information in this paragraph may be puzzled together using bits and pieces spread across the document– but previous criticism
(also from me) has been that this is very confusing, tiresome and error-prone... Or did I misunderstand your comment here?

From 6.1.  Initialization:
-------------------------------

	Until MAX_SEQNUM_LIFETIME after its sequence number is reset, the
	router SHOULD NOT create RREQ or RREP messages.
	(Just to be clear one MUST wait 5 mins before starting to request any route without a persistent store of the seq num, yes? JWD)

Yes... That mini paragraph is a bit redundant & contradictory, isn't it? I've taken it out and the "must" in "must wait for MAX_SEQNUM_LIFETIME before it creates any messages" was changed to a MUST.

From 6.2.  Next Hop Monitoring:
------------------------------------------

	(I can’t see how the above would be helpful at all JWD)

I'm assuming that "the above" refers to the text you've deleted, not the general idea of leveraging external mechanisms to monitor connectivity, correct?

From 6.6.  Route Discovery, Retries and Buffering:
------------------------------------------------------------------

	(is there some table that lists routes that are being waited on? JWD)

Currently not, we're reshuffling things in order to make it more clear how to do all of that.

From 6.7.  Processing Received Route Information
--------------------------------------------------------

	(MAY not MUST? Why wouldn’t one update it according to section 6.7.2? JWD)

No idea. This is a MUST now.

From 6.7.1.  Evaluating Route Information:
--------------------------------------------------------

	(does processing stop here?  It seems like it hsould be that isn’t stated. JWD)

It does, in both instances. Since the if statements following those paragraphs wouldn't match, there are nor no further processing instructions for the loop-causing AdvRte, essentially terminating the processing procedure. This pattern is employed in different places across the document; if that's desired by the WG I can add "Stop processing AdvRte" or something similar.

From 6.7.2.  Applying Route Updates:
--------------------------------------------------

	(we seem to be missing when the Route Information Base should be updated based on the new Local Route Set.  JWD)

4.5.  Local Route Set says:

   When the Local Route State is stored separately from the Routing
   Information Base, routes are added to the Routing Information Base
   when LocalRoute.State is valid (set to Active or Idle), and removed
   from the Routing Information Base LocalRoute.State becomes Invalid.

To me, the connection to the RIB is more of an issue connected to the general architecture of the Local Route Set rather than the nitty gritty of detailed update instructions, so I think that section 4.5 is the right place for this information...

From 6.9.1.  Local Route State Changes:
------------------------------------------------------

	(it’s not clear to me how the RERR’s are identified consider rewording to make it more clear. JWD)

I'm not quite sure what' s unclear here– would something like 

   o  If a Route Error (RERR) message reporting the route as broken is received,
      either from LocalRoute.NextHop, or with PktSource set to a Router
      Client address, LocalRoute.State MUST immediately be set to
      Invalid.

improve things?

	(Shouldn’t they also be removed from the Route Information Base? JWD)

No– Unconfirmed routes can't be used for forwarding, and therefore shouldn't be in the RIB in the first place.

7.1.1.  RREQ Generation:
----------------------------------

	(perhaps I’m missing a table or something but I don’t remember any RREQ table or list being described which i can check if a RREQ has been recently sent with associated timers. If there is such a table then it should be mentioned here. If there isn’t aon there should be. JWD!)

The table in question is the Multicast Route Message Table and you're absolutely right– that should be stated explicitly.  We've done so now.

7.2.3.  RREP Regeneration:
--------------------------------------

	(This seems like a bad idea to do on the reverse path. It would be a good way to attack a network Forward RREQ and drop all RREP. JWD)

Wouldn't this attack be possible no matter if we allow RREPs to be dropped or not? What am I missing here?

7.4.2.  RERR Reception:
---------------------------------

	(it’s not clear to me what the point of this invalid route is. It doesn’t get used and doesn’t remove any existing routes. JWD)
 
The point of that invalid route is to keep the Sequence Number.  One point of keeping Sequence Numbers is to avoid processing stale messages that might be received after long queuing delays.

	(How do we check? It’s not at all clear how this is done. JWD! )

The word "check" perhaps is misleading, as the check has already taken place a few paragraphs above.
I've reworded the paragraph in question to:

   3.  If there are previously Active LocalRoutes that MUST be reported,
       as identified in step 2.:

       *  Regenerate the RERR as detailed in Section 7.4.3.

, does that resolve the issue?

7.4.3.  RERR Regeneration:
-------------------------------------

	(it’s not clear how we know which localroutes need to be reported JWD!

again, missing reference here, I've changed that to

   2.  For each LocalRoute that needs to be reported as identified in
       Section 7.4.1:

, is that better?

Kind regards,
Lotte Steenbrink

Am 02.03.2016 um 05:18 schrieb Justin Dean <[email-masked]>:

> <draft-ietf-manet-aodvv2-13 (2).txt><draft-ietf-manet-aodvv2-13.diff>_______________________________________________
> manet mailing list
> [email-masked]

---

From: Justin Dean <[email-masked]>
Date: Tue, 22 Mar 2016 02:00:33 -0400

Responses inline.

On Tue, Mar 8, 2016 at 4:37 PM, Lotte Steenbrink <
[email-masked]> wrote:

> Hello Justin,
> thank you very much for your thorough and helpful review. We've adopted
> most of your editorial changes and are currently mulling over the larger
> ones.
>       An entry in the Local Route Set. (Local Route Set should have an
> entry, something simple and pointing to the section JWD)
> LocalRoutes are not the same as the Local Route set, as they're actually
> entries of the Set, which is explained in section 4.5.  Local Route Set.
> Since LocalRoute is used before its explanation (in the     RERR (Route
> Error) definition of section 2), I can see how this is confusing. If my
> co-authors don't protest, I guess we can just eliminate that mention by
> changing "a valid LocalRoute" to "a valid route". Would that resolve this
> issue?
>
> JWD: This was mostly about introduction of the terms and the difference
between Local Route Set having a space between "Local" and "Route" and an
entry being a LocalRoute with no space.  I'm happy with just adding a
reference to the section in which the Local Route Set is defined the first
time the term is used.

> From  3.  Applicability Statement:
JWD: The deleted text as seen in the diff.

Although AODVv2 is closely related to AODV [RFC3561], and shares some
   features of DSR [RFC4728], AODVv2 is not interoperable with either of
   those protocols.

   The routing algorithm in AODVv2 MAY be operated at layers other than
   the network layer, using layer-appropriate addresses.

The diff also shows that I moved/edited it to right after the (we jumped
right in here) comment.

> (I’m assuming this is here to hint at the possibility of a unified router
> with multiple routing protocols playing nicely together JWD)
>
> JWD: Yes.  Don't make it complicated just mention that other routing
protocols may also be operating on the same device and it may be a better
approach in these cases.

> (I noticed that Unconfirmed is the only state that uses Route Request
> message instead of route message, is that intended?  Can unconfirmed route
> state only be reached through Route Request messages? JWD)
>
> Yes. Until a route learned through a RREQ is validated by a RREP/RREP_Ack
> exchange, it is marked as unconfirmed (so that it can't erroneously be used
> until we know it is useful)
>
> JWD: My point was that I had to infer this add a bit making this explicit
and things are much easier for the reader.

>
> (this seems like an entry that would always be full 1s on a route request
> if true that should be stated to make things more clear JWD)
>
> I'm not sure I understand what you mean here, I'm assuming that
> prefixlength == address length with RREQs?
>
> JWD: Yes but even more forceful.  Unless you plan on allowing route
requests for networks prefixlengths (which I strongly discourage), full
prefixlengths for RREQs MUST be used.

> JWD: Okay.

> I don't quite understand this one– with the exception of “Only one metric
> type may be used in each route discovery attempt”, yes,
> the rest of the information in this paragraph may be puzzled together
> using bits and pieces spread across the document– but previous criticism
> (also from me) has been that this is very confusing, tiresome and
> error-prone... Or did I misunderstand your comment here?
>
> JWD: I deleted:
However, routes to a single destination might be requested
   and created in the Local Route Set for multiple metric types.  The
   decision of which of these routes to install in the Routing
   Information Base to use for forwarding is outside the scope of
   AODVv2.

> (Just to be clear one MUST wait 5 mins before starting to request any
> route without a persistent store of the seq num, yes? JWD)
>
> Yes... That mini paragraph is a bit redundant & contradictory, isn't it?
> I've taken it out and the "must" in "must wait for MAX_SEQNUM_LIFETIME
> before it creates any messages" was changed to a MUST.
>
> JWD: Good

> I'm assuming that "the above" refers to the text you've deleted, not the
> general idea of leveraging external mechanisms to monitor connectivity,
> correct?
>
> JWD: Yes.

> JWD: Looking forward to seeing that.

> From 6.7.  Processing Received Route Information
JWD: Good

> It does, in both instances. Since the if statements following those
> paragraphs wouldn't match, there are nor no further processing instructions
> for the loop-causing AdvRte, essentially terminating the processing
> procedure. This pattern is employed in different places across the
> document; if that's desired by the WG I can add "Stop processing AdvRte" or
> something similar.
>
> JWD: I think an explicit "Stop processing AdvRte" (or whatever applicable
message) would add clarity as there may be some more complicated steps that
don't stop right away.

> To me, the connection to the RIB is more of an issue connected to the
> general architecture of the Local Route Set rather than the nitty gritty of
> detailed update instructions, so I think that section 4.5 is the right
> place for this information...
>
> JWD I see you're point. A reminder here or reference to 4.5 would be
helpful.

> JWD: Something like....
If a Route Error (RERR) message containing a route, matching a LocalRoute
is received, either from LocalRoute.NextHop, or with PktSource set to a
Router
      Client address, the matching LocalRoute.State MUST immediately be set
to Invalid.

is close but what specifically in a RERR message matches what specifically
to a LocalRoute to give a match.

>
> No– Unconfirmed routes can't be used for forwarding, and therefore
> shouldn't be in the RIB in the first place.
>
> JWD yep.

> (perhaps I’m missing a table or something but I don’t remember any RREQ
> table or list being described which i can check if a RREQ has been recently
> sent with associated timers. If there is such a table then it should be
> mentioned here. If there isn’t aon there should be. JWD!)
>
> The table in question is the Multicast Route Message Table and you're
> absolutely right– that should be stated explicitly.  We've done so now.
>
> JWD: good.

> (This seems like a bad idea to do on the reverse path. It would be a good
> way to attack a network Forward RREQ and drop all RREP. JWD)
>
> JWD: It would be operating correctly as specified but would be hurting the
network if a router would send all RREQ messages but drop all RREP
messages. They shouldn't regenerate RREP AND RREQ messages if they aren't
willing to forward.

> (it’s not clear to me what the point of this invalid route is. It doesn’t
> get used and doesn’t remove any existing routes. JWD)
>
> The point of that invalid route is to keep the Sequence Number.  One point
> of keeping Sequence Numbers is to avoid processing stale messages that
> might be received after long queuing delays.
>
> JWD: It would be useful to have simple statement pointing this out.
Invalid routes are retained to avoid processing stale messages.

> JWD: That helps yes.  My confusion actually came from a bit further up.

If any of the above are false, a matching LocalRoute MUST NOT be
       made Invalid and the unreachable address MUST NOT be advertised
       in a regenerated RERR.
If all of the above are true, the LocalRoute is no longer valid.

change to...
If any of the above are false the address does not match a LocalRoute and
MUST NOT be processed or regenerated in a RERR.
If all of the above are true, the LocalRoute which matches the address is
no longer valid.

JWD: this is actually a really big change in terms of readability and
understanding IMO.  Please go back and check the language of RREQ and RREP
in the "to process or not to process sections" and see if the language can
be updated in a similar way.  The key part is the address along with the
checks (seqno/metric/previous hop) then matches a LocalRoute with
attributes. Refer to addresses in the message and matching LocalRoutes only
after the checks pass otherwise it should just be an ignored address.

> JWD: yep

> Thanks for the comments.

Justin

---

From: Lotte Steenbrink <[email-masked]>
Date: Mon, 28 Mar 2016 00:28:56 +0200

Hi Justin, Hi all,
again, thank you for your super helpful and detailed reply! Answers inline.

> Am 22.03.2016 um 07:00 schrieb Justin Dean <[email-masked]>:
> 
> Responses inline.
> 
> On Tue, Mar 8, 2016 at 4:37 PM, Lotte Steenbrink <[email-masked] <mailto:[email-masked]>> wrote:
> Hello Justin,
> JWD: This was mostly about introduction of the terms and the difference between Local Route Set having a space between "Local" and "Route" and an entry being a LocalRoute with no space.  I'm happy with just adding a reference to the section in which the Local Route Set is defined the first time the term is used.

Whoops, I totally missed that! Thanks for the clarification, LocalRoute is now space-free throughout the document; reference has been added.

> The diff also shows that I moved/edited it to right after the (we jumped right in here) comment.

Yes, and those changes have been adopted (I’ve assumed Intro to mean Overview?), I just wanted to make sure I understood you correctly there.

> JWD: Yes.  Don't make it complicated just mention that other routing protocols may also be operating on the same device

done.

> and it may be a better approach in these cases.
>  

with „it“ being the division between local route set and RIB?

> JWD: My point was that I had to infer this add a bit making this explicit and things are much easier for the reader. 

Done: I’ve added „This state only applies to routes learned through RREQ messages.“ to the description.

> JWD: Yes but even more forceful.  Unless you plan on allowing route requests for networks prefixlengths (which I strongly discourage), full prefixlengths for RREQs MUST be used. 

Done.

> From 4.6.  Multicast Route Message Table:

Done (deleted it too).

> From 6.1.  Initialization:

OK cool, then that one’s taken care of as well. :)

> JWD: I think an explicit "Stop processing AdvRte" (or whatever applicable message) would add clarity as there may be some more complicated steps that don't stop right away.

Done.

> JWD I see you're point. A reminder here or reference to 4.5 would be helpful. 

Done: I’ve added “For information on how to apply these changes to the Routing Information Base, see Section 4.5.”

> If a Route Error (RERR) message containing a route, matching a LocalRoute  is received, either from LocalRoute.NextHop, or with PktSource set to a Router
>       Client address, the matching LocalRoute.State MUST immediately be set to Invalid.  
>  
> is close but what specifically in a RERR message matches what specifically to a LocalRoute to give a match.  

I’ve reworded this to

   o  LocalRoute.State MUST immediately be set to Invalid if a Route
      Error (RERR) message is received where:

      *  The sender is LocalRoute.NextHop or PktSource is a Router
         Client address

      *  There is an Address in AddressList which matches
         LocalRoute.Address, and:

         +  The prefix length associated with this Address, if any,
            matches LocalRoute.PrefixLength

         +  The sequence number associated with this Address, if any, is
            newer or equal to LocalRoute.SeqNum (see Section 4.4)

         +  The metric type associated with this Address matches
            LocalRoute.MetricType

, what do you think?

> JWD: It would be operating correctly as specified but would be hurting the network if a router would send all RREQ messages but drop all RREP messages. They shouldn't regenerate RREP AND RREQ messages if they aren't willing to forward.

True. I suppose the MAYs here correspond to the priorities described in 6.5 <https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-6.5>. Message Transmission– if a router simply cannot send a RREP because it has reached CONTROL_TRAFFIC_LIMIT, there’s no point in regenerating it. So we can’t completely forbid choosing not to regenerate, can we?
I’ve reworded the paragraph(s) to

   A received Route Reply message is regenerated toward OrigAddr.  By
   regenerating a RREP, a router advertises that it will forward IP
   packets to TargAddr.

   The RREP SHOULD NOT be regenerated if CONTROL_TRAFFIC_LIMIT has been
   reached.  If approaching the limit, the message should be sent if the
   priorities in Section 6.5 allow it.  Otherwise, the router MUST
   regenerate the RREP.

for now...

> JWD: It would be useful to have simple statement pointing this out.  Invalid routes are retained to avoid processing stale messages. 

Done.

> If any of the above are false the address does not match a LocalRoute and MUST NOT be processed or regenerated in a RERR.
> If all of the above are true, the LocalRoute which matches the address is no longer valid.
> 

Done.

> JWD: this is actually a really big change in terms of readability and understanding IMO.  Please go back and check the language of RREQ and RREP in the "to process or not to process sections" and see if the language can be updated in a similar way.  The key part is the address along with the checks (seqno/metric/previous hop) then matches a LocalRoute with attributes. Refer to addresses in the message and matching LocalRoutes only after the checks pass otherwise it should just be an ignored address.

Done– I’ve checked the sections RREQ Reception, RREP Reception, Evaluating Route Information, Applying Route Updates and Processing Received Route Information and made some small changes:

in Processing Received Route Information:
---------------------------------------------------------

-to use and offers an improvement to existing information, as explained in [](#test). The Local Route Set MUST then be updated according to [](#update_rte).
+to use and offers an improvement to existing information, as explained in [](#test).
+If these checks pass, the Local Route Set MUST be updated according to [](#update_rte).

in Evaluating Route Information:
------------------------------------------

-An incoming advertised route (AdvRte) is compared to existing LocalRoutes to determine whether the advertised route is to be used to
-update the AODVv2 Local Route Set. The incoming route information MUST be processed as follows:
+An incoming advertised route (AdvRte) is compared to existing LocalRoutes to determine whether the advertised route is to be used to update the AODVv2 Local Route Set. The incoming route information MUST be processed as follows:

-    *   If no matching LocalRoute exists, AdvRte MUST be used to update the Local Route Set.
+    *   If no matching LocalRoute exists, AdvRte MUST be used to update the Local Route Set and no further checks are required.

-    *   If AdvRte is more recent than all matching LocalRoutes, AdvRte MUST be used to update the Local Route Set.
-    *   If AdvRte is stale, AdvRte MUST NOT be used to update the Local Route Set.
+    *   If AdvRte is more recent than all matching LocalRoutes, AdvRte MUST be used to update the Local Route Set and no further checks are required.
+    *   If AdvRte is stale, AdvRte MUST NOT be used to update the Local Route Set. Ignore AdvRte for further processing.

in RERR Reception:
---------------------------

     *  If the prefix length is different, create a new LocalRoute with the unreachable address,
        and its prefix length and sequence number, and set LocalRoute.State to Invalid.
+       These Invalid routes are retained to avoid processing stale messages.

Best regards,
Lotte Steenbrink