Subject: [manet] Stuff from review of aodv-11 page 1-22 that are still not folded into -12

From: [email-masked]
Date: Tue, 1 Dec 2015 20:21:19 +0100

All,

I am working through the revised I-D to see what comments that I made previously have been addressed, and which still do apply. 

As I sent my original review piecemeal, I’ll send my refresher in matching pieces (in part, in recognition that it is hard to get time to sit down and review the whole document in one go, and I do want to reply to the authors as quickly as possible)

In doing so, I am noticing additional things (notably, but not exclusively, to section 7 and beyond, which I didn’t get through reviewing last time around) which needs attention. I’ll gather that in separate emails a bit later, once I’ve worked through the complete, updated spec.

So onwards... 

Abstract:
	I made the following comment, which still applies:

		“This is a little over-stating the applicability: these statements may 
		 be true in some scenarios (for example, when there are few 
		 concurrent traffic flows, and therefore few routes to repair, and 
		 therefore few flooding operations to contend for channel access).
		 As a general statement, this last sentence is incorrect””

Overview (and elsewhere):

	I made a comment previously that “Router client” is a poorly chosen
	term, and have proposed alternatives. I’ve seen some attempts on the list
	at rather than change the term, explain it — some of which is in this document.
	The “Overview” still talks about “a router…one of its clients” - which is no less
	confusing than last time Iw went through it.

	I reiterate, why not use “Local Attached Network Set”, which is the term used
	by other documents from this WG? 

Overview:
	The term “confirming adjacency” is gone, and is now replaced by
	“confirming bidirectionality” - which, alas, still sounds like there is some active
	monitoring (HELLO message exchange) going on. Unless that is the case,
	then please be more specific here. 

	I note that the term adjacency is used through and through the document, btw.

	I suggested in my last review:

		The overview must also include a paragraph on the intersections 
		between this protocol and the forwarding plane — this, as it is 
		different (and more invasive) from that which is typically seen in 
		routing protocols.

		Specifically, as a reactive protocol, it is required (at least) that the 
		forwarding plane is modified :

		1) A “miss” when looking up a next hop for a data packet to be 
		   forwarded, is signalled to the AODVv2 process so as to permit 
		  that route discovery be launched;

		2) A “miss” when attempting to deliver a data packet to a next hop, 
		   which was recorded in the routing table, is signalled to the AODVv2 
		   process so as to permit that a route repair be initiated and/or a Route 
		   Error be generated.

		3) A “hit” when looking up a next hop for a data packet to be forwarded 
		    to a destination is signalled to the AODVv2 process so as to permit 
		    maintenance of “active route” Route State, timers and such.

		Note that these things are necessary to call out in the “overview” and in 
		the “applicability statement”, both: it is not that they are negatives per se, 
		but that they are important factors governing the applicability of this protocol: 
		will a given platform permit such access to the forwarding plane, for example? 
		Important to understand if for that platform this protocol is apple

	I see that this was not addressed in the overview, nor in the applicability other than
	by a forward reference to section 6.4. While it is positive that there is a section 6.4,
	this does not exonerate the overview and the applicability statement for being
	honest about the requirements (notably to the platform/os) that this protocol has 
	for being applicable 

	I suggested in my last review:
		
		“It is important to do more than this: 7182 does only provide “containers” 
		 for ICVs and timestamps, and does not specify how to use them to obtain 
		 specific security properties. RFC7182 may be a tool that can be used, but 
		 *how* that tool is used is what determines the security properties.

		Therefore, saying that “security is dealt with by using RFC7182” is either an
		incomplete statement, or is indicative of insufficient security considerations.”
	
	The actual sentence in the I-D has been changed, now it explicitly names the
	two TLVs from 7182 that it uses. That is, alas, still not sufficient.

	Making the aside that was discussed recently on the list, that (i) control messages 
	are not forwarded, and that (ii) they are modified in transit, the security/trust model
	is somewhat different from that of 7181 and consequently for what 7182 was initially
	written for. I think that  calling out the trust model, and how 7182 actually is used here,
	might be what is called for.

	Continuing with the aside, this *especially* as the applicability statement says:

		"Providing security for a reactive routing protocol can be difficult”

Terminology:

	My last review suggested:
		“This has been brought up on the list several times in the past, without having 
		 been addressed.

		There are “hosts” and there are “routers” — whose roles are well defined. 
		“Node” not so much — which is clear from looking at the definition here: “either 
		AODVv2 routers or router clients” (with “router clients” being defined as “an 
		AODVv2 router is also its own router client”).

		This is very much related to the use of “Router Client”, and both that term, 
		and “node” indicative that some clarity is needed here.

		All a router cares about is “an address”. If that address is of a network, or 
		a router, or an interface (and, if said interface is installed in a router or a host) 
		doesn’t matter.

		So, “an address” is something that the routing protocol should care about
		finding paths to. Which means that each address that should be made 
		reachable by the routing protocol should be advertised by (at least) one router 
		in the network.

		One way of doing that would be to simply talk about “Attached Networks” as 
		is done in RFC7181, wherein an address included in the “Attached Network Set” 
		is advertised by an OLSRv2 router....in this case, the equivalent would be “for each 
		address in the Attached Network Set of an AODVv2 router the router MUST 
		respond authoritatively to a RREQ, and MUST maintain the corresponding sequence number”.

		The text, as it currently is, is really hard to read, and a re-edit along these lines would go a long way.”

	I note that the terms “Node” and “Router Client” are still used, in their original form, 
	and that other than some slight wordsmithing this comment has not been addressed in the document.

	I reiterate that the need to use router, host, node, and router client in and by itself should
	be an indicator that tightening up of terminology is required.

	I made the following comment to Routable Unicast IP Address:

		“Are there any technical reason why not simply *any* address could be 
		 considered by the routing protocol?

		 My understanding, but correct me if I am wrong, is that all that is required is 
		 that all interfaces in a given AODVv2 routing domain has an unique address.

		 That some of these addresses (by an IP addressing architecture document) 
		 has special semantics associated (such as are link locals, or are for private 
		 use, or are for example use only, or are for multicast) is out of scope here?

	I see nothing has changed on the above, so let me be more explicit: the routing protocol itself 
	(probably) should not care about what kind of addresses are filled into it. Is an 192.16./16 address
	appropriate? Not across the internet, but it may be in somebody’s private deployments. Should
	the routing protocol be “address police” and is implementation of a “I refuse to route these addresses…”
	a requirement for claiming conformance? Suggest simply stating what the requirements are under
	which the routing protocol will work — and leave “address assignment politics” aside.

	I also continued:

		 Now, with that being said also, the WG wanted that RFC7181 supports not 
		 just multiple interfaces, but also the same address used on multiple interfaces 
		 of the same router. There were good reasons for that, and while it was not trivial 
		 to implement, it turned out to be the right thing to support. If there are technical 
		 reasons why this is not supported in AODVv2 (for example, if this cannot be 
		 made work because of <reason>) then that should be called out in the 
		 applicability statement also?

		Conversely, if it is possible in AODVv2, then I do not believe that it is clearly 
		specified how (at least, in the “naive” on paper examples I drew up, something 
		ended up not working). So either the protocol as-is does not support it (but 
		could be made to?) or it is supported (but just need to be spelled out), or is 
		not possible (and need to be disclaimed in the applicability statement).

		Stan Ratliff was a driving force in holding the WG’s collective feet to the fire 
		in getting this support included in RFC7181, and would likely be the right 
		person to consult on this matter?

	I actually have not seen changes, or comments, on this. In OLSRv2, the WG was making it
	a strong requirement that it should be possible to use the same IP address on different
	interfaces of a router. It was somewhat tedious to design around, but it was worked out, and
	the conditions under which that was possible were defined and documented.

	I would like to see the same done for this protocol.

	I also note that this is not unrelated to RFC6621-discussions. For example, when selecting
	S-MPRs on a multi-interface and multi-address-per-interface router, care must be taken
	least things won’t work. So, if (and this links back to previous mails) RFC6621 is a
	requirement or desire for this protocol, then there are some considerations required here.

	I see that the definition of “Router Client” has changed to be 

		“An address or address range…the AODVv2 router’s interface addresses 
		 are also configured as router clients”

	Better than before, but still missing the target. The term “Router Client” is, as I indicated
	numerous times before, odd.

	But the second part of the sentence, does that mean (what it says) that the interfaces 
	must be configured specially, so as to be able to be “router clients”? That can’t be true.

	What you likely mean is:

		“An AODVv2 router is configured so as to consider its own interfaces as part of
		 the locally attached network set” ? 

	You configure the router, right? No special “interface configuration properties” are required
	for an interface to be announcable by  an AODVv2 router?
	(And, getting rid of node would actually make the definition shorter and nicer)

	Now, snipping out from the applicability statement:

		"Multi-homing of an IP address is not supported by AODVv2, and therefore a
		  Router Client, i.e. an IP Address,  … "
	
	…evidence to there being some redundant terminology here to weed away.

	The below is a little bit of a meta-comment, I am not quite sure what I think here.
	The definitions for Target Node and such were confusing before. They still are, somewhat. 

	I think that it may be because the definitions now used are simply copy-pasted out from the 
	tables in the previous version, for example:

		An AODVv2 Data Element containing the destination address of the
		IP packet triggering route discovery.

	OK, I can trace back and see that a Data Element is something that exists inside a 
	protocol message. To me, however, that’s not really general terminology as such, but
	part of the specification of a packet format - or rather, it is the notation that you use 
	when describing an algorithm. By the way, why are some notations in CamelCase 
	whereas others have a space in them, e.g. “Target Node” and “TargMetric”, both of which
	are Data Elements? Would be good with a consistent approach here.

	I *think* that it would be better to take all those “Data Element” bits and move to a separate
	section (or subsection) to the terminology, and then keep all the “other stuff” (Neighbor, …)
	in its own section.

	I’m a great fan of calling this section “Terminology and Notation” and then having two
	subsections, one which is “Terminology” and one which is “Notation”, with the 
	TargMetric and Target Node being firmly in the latter.

	I made a comment:
		"Second, should “valid route” not be qualified by “to a specific address”?”

	Which was not addressed.

	I also made a comment on "Unreachable Address” - I am glad I did, because I apparently
	had a different understanding than what was intended. I now see that an Unreachable Address
	by definition is an address listed in a RERR message, and not the same as an address to
	which no route has yet  been discovered? If yes, then please use a different term, such as
	“FormerlyReachableAddress” or something of the sort?

Applicability statement

	First, I would like to recognize the efforts made to improve this since last review. Thanks

	Second, the document states:

		"AODVv2 supports routers with multiple interfaces, as long as each
		   interface configured for AODVv2 has a unicast IP address.  A router
		   may use the same IP address on multiple interfaces.  Address
		   assignment procedures are out of scope for AODVv2.”

	Is that true? Granted, I have not worked this through in detail, but I can present a counter-example:
	the use of RFC6621 means that there certainly are some constraints that must be respected least
	various flooding optimizations may not work.

	Secondly, if the multiple-interfaces-with-same-address are on the same L2, and this is what I
	have not worked through, are there any situations that will not work?

	The immediately previous version of this specification read:

		"AODVv2 supports routers with multiple interfaces, as long as each
		   interface configured for AODVv2 has its own unicast routable IP address"

	So what changed that means that each interface no longer needs its *own* unicast address?

	I pointed out to the Applicability Statement:

		I think that appendix B needs to be removed. Essentially, it makes claims that it is 
		possible to do multi-homing — but neither specifies how it is done, nor gives 
		pointers to documents that justify the claim.

		AODVv2 does not support multi-homing — that’s clear, and it is fine that it is 
		called out here. Thank you for that.

		Now, with that being said, I am torn between being satisfied that it is called out on 
		one hand, and wanting to have “multi homing” on the other hand. RFC7181 supports 
		multi-homing, FWIW.

		I believe that this also would merit some explicit discussion by the WG, in order to 
		understand if this design decision is acceptable?

	I see that Appendix B still is in the document, and I do not recall having seen this discussed
	on the mailing list. Simply removing the reference from the Applicability Statement to Appendix B
	does not address the issue that I raised in my previous review.

To 4.1, I made the following comment:

	"Is this a should, or a SHOULD? If the latter, should it be a MUST?

	  In general, there are a lot of such “maybe normative language” through the 
	 document, and I would much like to see an editorial pass — essentially all 
	 may/should/ must and friends carefully evaluated as if they should become 
	 2119-terms, and ... more importantly (it has been called out before, fwiw) 
	 quite a bit of should/SHOULD which ought to be transformed into MUST.

	Generally, aiming for a very a low number of SHOULD is a good design metric for a document”

Aside from the general comment on 2119-language, why is this a SHOULD?

To 4.2, I made the following comment:

	As indicated earlier, I believe that the term “Router Client” is ill chosen. 
	I believe that it is more appropriately an “Attached Network Set” since — 
	as indicated previously — the term “Router Client” is ambiguous. I am pleased 
	to see, though, that this “Router Client List” in reality is an “Attached Network Set” 
	and so that change should be (relatively) easy.

The above comment still is applicable to this revision,

To 4.2, I made the following comment:

	Also, I recommend to not say “subnet” — how about rephrasing to “If a prefix 
	is included in the attached network set of an AODVv2 router, then that AODVv2 
	router MUST provide connectivity for, i.e. answer to RREQs and maintain 
	sequence numbers for, all addresses from within that prefix.”

I note that while the term has been removed from section 4, there’re 4 lingering instances of this term in the document, that could easily be removed.

I Also made a comment about Appendix B in my previous review, which is referenced here. That comment still applies.

To Section 4.3, I noticed:

	Does section 6.2 describe how to monitor an established adjacency 
	only, or how to discover neighbouring AODVv2 routers? Looking in 6.2, I see

		“Not every pair of neighboring routers will necessarily form an adjacency,” — 
		 so it likely isn’t 6.2 that tells me how to maintain this table?

	In short, “A neighbour table MUST be maintained” — where can I find information on how to do this?

	Section 6.2 states:

		“The default approach for monitoring bidirectional connectivity to the next hop toward 
		 OrigAddr is to request acknowledgement of Route Reply messages.”

		That certainly will tell me if a link over which an RREP is sent is bi-directional, 
		but will not maintain a “neighbor table”.

	So how is this done? Or, is the “Neighbor Table” not supposed to contain the 
	complete set of neighbours? What information “...MUST be maintained” then, in this table?

	This is very unclear, I would not know how to implement a mechanism that populates this 
	“Neighbor Table” with the needed information here.

I see no (relevant) changes to 6.2 nor to 4.3 so I assume that this comment has not been addressed

I am throwing this in here, as I am sure that I commented on that in the previous review, but I do not see that addressed: is Appendix C normative, or not? It represents “ a second specification of the protocol, in a different language” from the main part of the specification. I have not walked through and made 200% sure that both are perfectly aligned and that there are no ambiguities, but having two different specifications of a protocol is a recipe for disaster.  Please either make 2000% sure that they are specifying the same thing without ambiguities, or remove one.

To section 4.4, I wrote:

	"would like to nit-pick that: the router can maintain this sequence number in whatever 
	 format it pleases — but, when it includes it in control messages, it must be 
	 representable in a specified format, respecting certain rules.”

I see that there were no changes following this comment.

To section 4.4 I asked for clarification as to if sequence numbers were per interface or per router, as the specification was unclear on that. The words has changed, but it still is unclear: how many sequence numbers does a router maintain? One? One per interface?

In my previous review, I expressed that it would be preferential to use “a notation of Sets” rather than tables. I see that this has not changed.

I made a comment on node and address, let me pick this up again. The following:

	RteMsg.OrigAddr
	      An IP address of the node which requires the route, i.e., the
	      source address of the IP packet triggering the route request.

would be more compact and clear if getting rid of the term “node” and said:

RteMsg.OrigAddr
	The source address of the IP packet triggering the route request.

To section 4.6, and I (and others) have commented on this before:

   All AODVv2 routers MUST maintain a route table.  The route table
   entry is a conceptual data structure.  Implementations MAY use any
   internal representation but MUST contain the following information:

In order to avoid confusion, rename this to “Routing Information Base” or “Routing Set” — a Routing Table is an operating system construct, whereon operations directly influence packet forwarding. What you are defining here is a RIB/an RS.

The confusion that I pointed out in my previous review on “IP address” and “Address” being used a bit haphazardly persists, fwiw. It makes me think, can a router send an RREQ for a prefix?

I also called this out in my previous review as incorrect, and despite wordsmithing it still is:

	Route.NextHop
	      The source IP address of the message advertising the route to
	      Route.Address, i.e. an IP address of the AODVv2 router used for
	      the next hop on the path toward Route.Address.

If that “message” is an RFC5444 entity, then it does to have a “source IP Address” — the encapsulating IP datagram containing the packet containing the message does. And the message MAY have an Originator Address

As I indicated, I am walking through my previous review and retaining those comments that I still think need attention — and this is “crossing off from part 1 of my previous review” only. More to follow.

Thomas

---

From: Victoria Mercieca <[email-masked]>
Date: Wed, 2 Dec 2015 14:24:49 +0000

Hello Thomas,

Thank you again for your time spent reviewing AODVv2. I apologise that we
did not give a "point by point" response to your comments on draft 11 - I
felt that since most of the comments were around a few major topics, it
made sense to address the topic across the whole draft, rather than respond
to every single comment in order. I did also try to start a discussion on
the MANET list based on your comments from draft 11, but did not see any
responses.

Thank you again, we will discuss and intend to respond soon.

Kind regards,
Victoria.

On Tue, Dec 1, 2015 at 7:21 PM, <[email-masked]> wrote:

> All,
>
> I am working through the revised I-D to see what comments that I made
> previously have been addressed, and which still do apply.
>
> As I sent my original review piecemeal, I’ll send my refresher in matching
> pieces (in part, in recognition that it is hard to get time to sit down and
> review the whole document in one go, and I do want to reply to the authors
> as quickly as possible)
>
> In doing so, I am noticing additional things (notably, but not
> exclusively, to section 7 and beyond, which I didn’t get through reviewing
> last time around) which needs attention. I’ll gather that in separate
> emails a bit later, once I’ve worked through the complete, updated spec.
>
> So onwards...
>
> Abstract:
>                 The text, as it currently is, is really hard to read, and
> a re-edit along these lines would go a long way.”
>
> I note that while the term has been removed from section 4, there’re 4
> lingering instances of this term in the document, that could easily be
> removed.
>
> I Also made a comment about Appendix B in my previous review, which is
> referenced here. That comment still applies.
>
> I am throwing this in here, as I am sure that I commented on that in the
> previous review, but I do not see that addressed: is Appendix C normative,
> or not? It represents “ a second specification of the protocol, in a
> different language” from the main part of the specification. I have not
> walked through and made 200% sure that both are perfectly aligned and that
> there are no ambiguities, but having two different specifications of a
> protocol is a recipe for disaster.  Please either make 2000% sure that they
> are specifying the same thing without ambiguities, or remove one.
>
> To section 4.4, I wrote:
>
> To section 4.4 I asked for clarification as to if sequence numbers were
> per interface or per router, as the specification was unclear on that. The
> words has changed, but it still is unclear: how many sequence numbers does
> a router maintain? One? One per interface?
>
> In my previous review, I expressed that it would be preferential to use “a
> notation of Sets” rather than tables. I see that this has not changed.
>
> In order to avoid confusion, rename this to “Routing Information Base” or
> “Routing Set” — a Routing Table is an operating system construct, whereon
> operations directly influence packet forwarding. What you are defining here
> is a RIB/an RS.
>
> The confusion that I pointed out in my previous review on “IP address” and
> “Address” being used a bit haphazardly persists, fwiw. It makes me think,
> can a router send an RREQ for a prefix?
>
> If that “message” is an RFC5444 entity, then it does to have a “source IP
> Address” — the encapsulating IP datagram containing the packet containing
> the message does. And the message MAY have an Originator Address
>
>
> As I indicated, I am walking through my previous review and retaining
> those comments that I still think need attention — and this is “crossing
> off from part 1 of my previous review” only. More to follow.
>
> Thomas
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 2 Dec 2015 15:56:47 +0000

I made an observation (that RFC 6621 is completely inapplicable) on -12, but based in part on that, I’m waiting to review the next draft, rather than this one. (Time I can make I’m looking at DLEP, which appears closer to final, though there’s a couple of open questions on IPv6 and TLS.)

Observing this discussion (of AODVv2) there seems to be a significant issue on hop by hop versus end to end bidirectionality. As I’ve commented before, I’ve found enough in the “outside” parts of the specification, that I haven’t got stuck into the actual core protocol, so I don’t yet have a view on this. (I have a view that bidirectionality needs ensuring works, and to be interoperable, but that’s as far as I’ve got.) But it’s a bit concerning that this still isn’t clear – and I’ve seen no reports of an implementation of either. Is there one?

From: manet [mailto:[email-masked]] On Behalf Of Victoria Mercieca
Sent: 02 December 2015 14:25
To: [email-masked]
Cc: manet
Subject: Re: [manet] Stuff from review of aodv-11 page 1-22 that are still not folded into -12

*** 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.

Hello Thomas,
Thank you again for your time spent reviewing AODVv2. I apologise that we did not give a "point by point" response to your comments on draft 11 - I felt that since most of the comments were around a few major topics, it made sense to address the topic across the whole draft, rather than respond to every single comment in order. I did also try to start a discussion on the MANET list based on your comments from draft 11, but did not see any responses.
Thank you again, we will discuss and intend to respond soon.
Kind regards,
Victoria.

On Tue, Dec 1, 2015 at 7:21 PM, <[email-masked]<mailto:[email-masked]>> wrote:
All,

So onwards...

Abstract:

Overview:

Terminology:

        I also continued:

        What you likely mean is:

        I made a comment:

        Which was not addressed.

Applicability statement

        Section 6.2 states:

To section 4.4, I wrote:

        RteMsg.OrigAddr

RteMsg.OrigAddr

        Route.NextHop

Thomas

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

********************************************************************
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: [email-masked]
Date: Thu, 3 Dec 2015 15:48:14 +0100

Dear Victoria,

> On Dec 2, 2015, at 15:24, Victoria Mercieca <[email-masked]> wrote:
> 
> Hello Thomas,
> 

I saw the mail, but it seemed more of a “summary of my comments”, which was a fine initiative — but, I did not really have anything to contribute beyond my initial review.

Best,

Thomas

> On Tue, Dec 1, 2015 at 7:21 PM, <[email-masked] <mailto:[email-masked]>> wrote:
> All,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
>