Hello Vicky,
Follow-up below... In a couple of places you have asked for text.
Depending on further discussion, if no one else makes text, I will try
to do it tomorrow.
Thanks for staging the email for these comments.
On 12/2/2015 6:15 AM, Victoria Mercieca wrote:
Hi all,
Pasting Thomas' latest comments and my own comments are in line marked "Vicky"...
Hopefully we can address these quickly before the next lot appears.
We should give a "blow by blow" response this time (my fault we didnt last time, I apologise, I know Charlie did want to).
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””
Vicky: Any suggestions?
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?
Vicky: Tired of arguing about this. Someone tell me what to do.
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.
Vicky: thats been updated since version 12, and i made a small change to the bit where it says "confirming bidirectionality":
"confirming bidirectionality of links to next hop AODVv2 routers on discovered routes"
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
Vicky: I added some extra text to both Overview and Applicability to mention these examples, and Applicability still references section 6.
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”
Vicky: Anyone like to volunteer some text?
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.
Vicky: So currently we have router, router client, or device (which could be either). Only Router and Router Client are defined in terminology. Hopefully using the word "device" is not going to cause too many complaints. It is not used often.
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.
Vicky: Any reason to keep this?
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.
Vicky: Draft 12 does say in the Applicability Statement that "A router may use the same IP address on multiple interfaces." I thought we had discussed this and determined that there were no issues with this. Hearing that for OLSR it was "tedious to design around" makes me wonder if I'm missing something. How does it relate to RFC 6621?
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)
Vicky: The wording we use says: "The IP Addresses of the router's interfaces will appear in the Router Client Table." and in the Terminology: "The AODVv2 router's interface addresses are also configured as Router Clients." Both statements say that ...interface addresses are configured as router clients.....not sure why Thomas has misunderstood. Perhaps the first one quoted is clearer.
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.
Vicky: That was there as a reminder that a router client is one IP address, even though the device with that IP address may have other IP addresses too....should I update this bit of text somehow?
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.
Vicky: Thomas' comment from draft 11 where we had data elements in a separate table, says:
"Also suggest abolishing this table and folding the definitions in with the other definitions in the terminology section."
My suggestion on this is to remove the bits that say "An AODVv2 data element" before defining what they mean. Also to reduce the usage of the term "Data Element" throughout the draft and just refer to the names themselves (AddressList, SeqNum, OrigAddr, ValidityTime, AckReq etc), rather than "an AckReq Data Element" each time... any objections?
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?
Vicky: "formerly reachable" is inaccurate... we send a RERR if another router forwards a packet via us, and we dont have a route. We might never have had a route. If someone erroneously chose to route traffic through us, we would report the lack of a route to them. In this case, the address may not have been "formerly reachable". Also, I think "FormerlyReachableAddress" is a really ugly term. Unreachable means "we dont have a route and we arent going to request one" or "we lost this route". It doesnt mean "we didnt request one yet" and it would be wrong to class that address as unreachable before trying. Should we try "ErrorAddress"?
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?
Vicky: well.......we thought about it and decided it would probably work, and took out the text that had been there for ages? Were we wrong to think it would work fine? I never considered multiple interfaces with the same IP address being on the same L2.
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.
Vicky: Should we remove it (now Appendix A)?
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?
Vicky: well section 6.5 says, on the topic of message transmission in general: "When multiple interfaces are available, an AODVv2 router transmitting
a multicast message to LL-MANET-Routers MUST send the message on all
interfaces that have been configured for AODVv2 operation, as given
in the AODVv2_INTERFACES list (Section 4.1)."
What should it be, and why?
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,
Vicky: Anyone care to respond?
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.
Vicky: all mentions of "subnet" are in the ENAR section. I've updated them to say network, or "networks attached to the routers"
I Also made a comment about Appendix B in my previous review, which is referenced here. That comment still applies.
Vicky: This is now Appendix B and used to be Appendix C. Should we move that text into the main draft as Thomas suggests?
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
Vicky: I added a new section on how to update the neighbour table. And between 11 and 12 there was a lot of changes to section 6.2. Its been updated again since then too so hopefully the current version (13f/g - not yet created) will address this...
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.
Vicky: The pseudo-code appendix.....which we have not verified to be correct for quite some time. My vote is to remove it. Make it available elsewhere if necessary.
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.
Vicky: why store it as anything other than what it needs to be when it goes into a message? We could say "MUST report its own sequence number as a 16 bit....whenever it creates a RREQ or RREP message"?
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?
Vicky: I tried to start discussion on that point, and at the same time we reverted to having 1 seqnum per router. I think the text is clear... we refer to "the routers sequence number" or "its sequence number" - never hinting that there could be multiple seqnums per router (as far as I'm aware).
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.
Vicky: it was sets rather than lists which Thomas preferred...and I explained this in responses to the MANET list which we never received comments on.....
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.
Vicky: change made as suggested, same for TargAddr. Will be in version 13.
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.
Vicky: Done in version 13.
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?
Vicky: It can include the prefix associated with OrigAddr by adding a prefix length! But it only has one destination. Probably the RREP will contain a prefix length and RREQ_Gen will learn the route to TargAddr's subnet.
Actually, when I first got involved with AODVv2 this confused me a little. We use OrigAddr as being the source IP address of the IP packet but really it should be the corresponding Router Client entry info - address and prefix. Same for TargAddr in the RREP. I dont think this is clear. Perhaps we should try to address this. Every time I think about it, the terminology gets confusing. To resolve this the minimum we need to do is: be clearer which prefix length is given in the RREQ and RREP, how it corresponds to a Router Client entry, and also that when we install the route contained in the message, we should take care to install a route to the subnet, not the IP address itself (if a prefix length is given).
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
Vicky: So we should say "the source IP address of the IP packet containing the message advertising...."?