Subject: [manet] #26 (aodvv2): Specification of optional features

From: "manet issue tracker" <[email-masked]>
Date: Thu, 03 Apr 2014 21:14:06 -0000

#26: Specification of optional features

 (Thomas Clausen) Related to the above point, an awful lot of the document
 is optional, as exemplified by the below:

 {{{
         To avoid repeated failure of Route Discovery, an AODVv2 router
         (HandlingRtr) handling a RREP message SHOULD attempt to verify
         connectivity to the next upstream router towards AODVv2 router
         originating an RREQ message. This MAY be done by including the
         Acknowledgement Request (AckReq) message TLV (see Section 15.2)
         in the RREP. Any unicast packet will satisfy the Acknowledgement
         Request, for example an ICMP REPLY message.  If the verification
         is not received within UNICAST_MESSAGE_SENT_TIMEOUT,
         HandlingRtr SHOULD put the upstream neighbor in the blacklist.
 }}}

         So I have a (2119-languague) "SHOULD" telling me to "attempt to
 verify connectivity". Then a (again, 2119-language) "MAY" suggesting to
 accomplish that by sending an AckReq.

         It's a MAY - therefore, I know (as it's 2119-language) that I do
 not have to do that, send that message.  But I still SHOULD "attempt to
 verify connectivity", so how do I do that?

         It's not clear what it means that any "unicast packet will satisfy
 the Acknowledgement Request" (which I decided to not send, as that was a
 MAY), nor is it clear how the routing process will get access to any such
 unicast packet (assuming, that is, that said unicast packet isn't destined
 for that process).

         Also, I am apparently supposed to receive a "verification" before
 some timeout. Search as I may, I have not found anything indicating where
 that "verification" is generated, I see no messages defined to this
 effect, nor any processing allowing me to infer it.

 ... from section 8.2:

 {{{
                 AODVv2 routers SHOULD monitor connectivity to adjacent
                 routers along active routes.  This monitoring can be
                 accomplished by one or several mechanisms, including:

                 o  Neighborhood discovery [RFC6130]
                 o  Route timeout
                 o  Lower layer trigger that a link is broken
                 o  TCP timeouts
                 o  Promiscuous listening
                 o  Other monitoring mechanisms or heuristics

                 If a next-hop AODVv2 router has become unreachable,
                 RERR_Gen follows the procedures specified in Section
 8.3.2.

 }}}

         So, I will implement this protocol using RFC6130, since I happen
 to have an implementation of RFC6130 around.  My next-door-neighbor,
 Francois, also implements this protocol - but he doesn't have an RFC6130
 implementation around, and therefore uses "route timeout".  As Francois
 and I both are lazy, of course, we implement only one mechanism each (this
 is allowed, according to the text).

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-manet-
  [email-masked]  |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  aodvv2       |    Version:
 Severity:  Active WG    |   Keywords:
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/manet/trac/ticket/26>
manet <http://tools.ietf.org/manet/>