Specification of optional features

[charliep@…]

(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).