Hello Vicky,
I have attempted to address all of the comments posted today, so that
you might have a chance to resolve as many of them as possible in the
upcoming revision. That was a pretty huge task, unfortunately. It's
pretty much unfair to post such voluminous comments on the very last day
before our deadline, and I think we will be forgiven for not handling
every last one of them, especially where a lot of text would be
required. In those latter cases, I have simply stated "Text is always
appreciated".
Again, my comments can be modified and forwarded to the list for more
discussion, but please take my name off before doing so.
“Revised” — how? Would be good to call
out any new features introduced, major
bugs addressed, or unused/inappropriate
features from the predecessor eliminated?
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.
This issue has been brought up several
times in the WG before, but has not been
addressed so far.
What are the clients of a router? I believe
that this is a confusing and inappropriate
term (and, fortunately, furthermore is an
unnecessary term).
In the terminology “router client” is defined
as something akin to “someone requiring
the services of a router” — which matches
“the whole world”: the service provided by
a router includes “forwarding an incoming
data packet so as to bring it closer to the
destination”. Consequently, the source of a
datagram is the “client” of a router 10 hops
away that happens to be on the path
towards the destination? I believe that this
is not the intention.
Also, when I see “client” the next word that
pops into my mind is “server” — two
entities running (typically) distinct parts of a
protocol: a DHCP server and a DHCP
client, for example. I believe that this is not
the intended association either.
So….If either of the two interpretations
above are actually intended, then the
document is incomplete. On the other
hand, if either or both of these two
interpretations is not intended then the term
“router client” or “client” must be removed
from the document — which must be
reworked to use a more appropriate (i.e.,
less confusing) terminology.
What I believe that the document is trying
to say is “the set of addresses, for which
this router is able to provide authoritative
routing information” — in RFC7181-terms,
that would (for example) be the content of
the “Local Attached Network Set”. I would
like to suggest perhaps using that as
inspiration for how this issue could be
resolved.
“Confirming adjacencies” sounds like there
is a sort of HELLO message exchange, or
other local signalling, in use — at least, to
someone used to reading OSPF and related
protocols, that would be the immediate
understanding.
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.
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.
This is incredibly frustrating to read and
use: all the “interesting concepts” are
defined as “An AODVv2 Data Element” with
a forward reference to a Table 1
somewhere.
Why is the content from that “Table 1” not
simply included where it belongs: below
each of the terms in the hangText? The
existence in a table does not really
contribute anything (other than space in a
printed document).
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”.
Is 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?
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?
Repeat of comment from introduction:................... etc. ..................
This issue has been brought up several
times in the WG before, but has not been
addressed.
“one of the sequence numbers maintained
by an AODVv2 router to ….”
That’s a little vague and ambiguous:
apparently that sequence number is not
enough — but we’re not told with what it
must be complemented in order to be
enough to determine if a route is fresh or
not.
Could that be written:
“SeqNum is the sequence number, which
does ______”
Target Node is confusing me, and the
definition given is only making that worse.
What does it mean to be “hosting the IP
address”?
A RREQ is flooded through the network,
and I assume that a RREQ contains the
TargAddr.
Some *router* (not node!) is
configured to (i) respond to RREQs for
TargAddr, and (ii) maintain sequence
numbers associated with TargAddr.
So is “TargNode” that *router* ?
In that
case, simply saying “TargRouter” would
make me happier, as would I be happier if
including the description above.
Of course, if this is not the correct
understanding of TargNode, then that’s a
good indicator that the concept is
confusing.
This is probably putting the cart before the
horse quite a bit. I must confess, I cheated
and read the specification end-to-end
before starting this review — so I kinda
understood what was meant.
I’d first put “Valid route” before
“unreachable address”, since the latter
uses the former. [And yes, that would mean
that terms would not come in alphabetic
order — I do prefer clarity over adherence
to the alphabet, though]
Second, should “valid route” not be
qualified by “to a specific address”?
Third, is an “unreachable address” then not
“an address to which a valid route is not
known — either because no route to that
address has been discovered yet, or
because it is not possible to discover a
route to that address”.
By the way, I note that you distinguish
“node” and “address” here; that does mean
that if a given end-point has two addresses,
“IP1” and “IP2” (possibly, on the same
interface), then you will need two RREQ/
RREP cycles to discover paths to both of
these?
Also, will a remote device be able to learn
that IP1 and IP2 really are “the same
device” (or even, “the same interface”)?
Given that RFC5444 does not ensure
ordering of addresses (or, of elements in a
TLV block), would it not be possible to talk
about an “AddressSet” (and similar for
MetricTypeList and PrefixLengthList, and
…) so as to not risk (unintentional)
misunderstandings for the reader?
Generally, unless there’s a really good
reason for assuming (or requiring) ordering,
I’d prefer talking about “set” and then leave
an implementer to figure out which precise
data structure is suitable?
Actually, this is not really a set of “data
elements” but rather the “protocol data
units” that AODVv2 routers exchange —
correct?
I.e., they are defining the content of the
messages, and not the data elements used
by the routing algorithm? Suggest changing
the name and adding an explanation.
Also suggest abolishing this table and
folding the definitions in with the other
definitions in the terminology section.
I strongly disagree with the assertion that in
emergency and disaster relief scenarios
“the ability to communicate is more
important than being assured of secure
operations” — I think that that’s an
unfortunate and incorrect claim to make.
I understand the complexities of providing
security of a reactive routing protocol. I
believe that it would be orders of magnitude
better to call those out, and then describes
the limits of what can be done (securitywise)
than to claim a set of scenarios not
needing security (especially since…they do
…)
To give a simple example, given that
RREQs are mutable (notably the “metric”
field) in transit, and is manipulated by all
intermediaries, then obviously a simple e2e
signature (inserted using the RFC7182
format) would require that field to be
“zeroed out” for calculation/verification —
which would open an attack vector on the
protocol. Calling that out, presenting the
consequences hereof, and presenting the
conditions wherein — despite that —
AODVv2 would be applicable (For example,
always run over a L2 providing hop-by-hop
security, preventing an uninvited intruder
from overhearing and participating in the
protocol), that would be particularly
valuable.
I think that the statement “AODVv2 will not
make use of” and then “…cannot confirm
bidirectional connectivity should be
ignored” are slightly conflicting.
Does this paragraph intend to say:
“AODVv2 cannot work when faced with unidirectional
links, and must not be deployed
on networks wherein such are possible”
Or, does it intend to say:
“AODVv2, faced with uni-directional links,
will detect and exclude those from use for
forwarding data packets”.
I am curious on the last sentence; requiring
persistent state….could you elaborate on
what you would store? and on what, and
how, a performance penalty would incur?
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.
Given that this was required by the WG, I
wonder 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, also?
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 am wondering “why just the Internet”?
Can any external network (which is not
0::0/0) be interfaced to an AODVv2-routed
domain?
Can multiple such external networks (which
are not 0::0/0) be interfaced to an AODVv2-
routed domain?
I can see clear use-cases for “a MANET,
connected to two external networks, neither
of which are 0::0/0”, and I would like to
make sure that that configuration is
supported by AODVv2.
Is this a should, or a SHOULD? If the latter,
should it be a MUST?
Generally, aiming for a very a low number of
SHOULD is a good design metric for a
document ;)
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.
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.”
There’s no “cost”, distance, metric,
associated with these attached networks?
I’d think that that’d seriously hamper some
deployments..
Stepping away from the “multi-homing”
discussion (which we should have in
isolation) even without discussing multihoming
I envision deployments where I’d
connect to “external service A” if I know
that the delay is below XX — but if it is
above XXX then I’d rather connect to
“external service B”…and where the major
impact on the delay could be “from the
MANET router through the external
network” rather than “within the MANET”.
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.
“Neighboring routers which cannot confirm
adjecency…” — do you mean “Neighboring
routers for which an adjacency cannot be
confirmed”?
But also, from the terminology, it is not
actually clear what it means to “confirm
adjacency”:
“Adjacency
A bi-directional relationship between
neighboring AODVv2 routers
for the purpose of exchanging routing
information.“
If I was to interpret this exactly as written,
then this text tells me to “black-list any
neighbor, from which a RREQ followed by
an RREP has not been received”
I am afraid that I do not understand what
you mean here….is “adjacency” simply “bidirectionality
has been verified”?
And, is “blacklisted” then not rather “we
tried to verify bi-directionality, but failed” —
it certainly is not “bi-directionality has not
been confirmed” since that also captures
situations where no attempt at verification
were made.
What would such an “indication of
adjacency” be?
Also, is it mandatory to represent the
information in the formats that you give (in
this, and other sections)?Specifically, must
it be in forms of tables? Your use of
“should” here indicate that yes, if so, why?
I am very confused by the use of “neighbor”
and “adjacency”. — for example
“Neighbor.State: the state of the adjacency
…”
And then below “Before a neighbor is
confirmed” — but “confirmed was a “state
of the adjacency?….and that paragraph
continues [but see below for that]
I do not understand that.
I do not understand that. “When neighbor
state is set to confirmed, the unconfirmed
routes using the neighbor as a next hop can
transition to Idle”
1) Please do not mix the description of data
structures, with the description of the state
machine / processing — it makes it hard to
read [this comment applies through this
section 4, fwiw]
2) With that said, what does “before a
neighbor is confirmed” mean in the
preceding sentence? What state does that
correspond to?
3) It is not clear if there is a difference
between “neighbor state” and “state of the
adjacency”; the terminology lead to believe
that a subset of neighbors were
adjacencies, but this section mixes that up.
Please clarify.
4) on the processing sentence (that does
not belong here), what does it mean that a
“route…can transition to idle”?
5) there’s a lower-case can — does that
mean that it is *not* 2119-language? in that
case, what is the rule here?
I note a lower-case “should”, so I infer that
this is not 2119-language either? what is,
then, normative behavior here?
I note a lower-case “should”, so I infer that
this is not 2119-language either? what is,
then, normative behavior here?
I 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.
“it can maintain different sequence
numbers for each interface IP address, but
MUST NOT use … ”
This needs clarification.
First, “can” is not a 2119-word.
Second, what are the consequences of “a
single sequence number per router” vs. “a
single sequence number per interface”?
Third, this paragraph is written as-if each
interface has one and only one IP address;
that is unlikely to be the case. How would
this impact things?
Fourth, an AODVv2 router that is answering
to RREQs for addresses in an “attached
network set”, is that router maintaining and
using a seq# for each address?
Or just one
sequence number?
Note that these
addresses are *not* associated to an
interface of the AODVv2-router (not
necessarily, at least) and so this text is not
entirely clear.
Fifth, assuming that one wanted to consider
multi-homing [possibly as an interoperable
extension], would mandating a specific
choice of which sequence numbers are
used for what here be more or less
advantageous?? I have a hunch that it
would …
How about saying RREQ, RREP or RERR?
I am picking this point to dig in here.
I think that the choice of phrasing is
unfortunate, and I saw that Christopher
Dearlove made a similar comment on the
list - which I am going to agree with.
The routing protocol implementation
operates on an “internal data structure”; in
RFC7182 that’s called a “routing set”. Such
a set may contain a lot of information, so as
to permit routing protocol internal
functioning.
At appropriate times, a subset of the
“routing set” is reflected into the “routing
table” / FIB, for use for data forwarding.
To take but a simple example, the routing
set may contain the “reverse routes”
installed by forwarding RREQs and which
have not been confirmed as bi-directional:
such should be kept around for forwarding
RREPs, of course, but certainly should not
be considered for use for forwarding data
traffic. Adding this “reverse route” directly
to the “routing table” could be catastrophic,
consider this example: a valid, working
route from a to b might exist via c — but if a
receives a RREQ directly from c, adding an
entry reflecting that reverse route to the
routing table of a would “overwrite” (or, at
least, provide a lower-cost, alternative to) a
perfectly valid route.
I would like to see three things done to the
document to this end (note, this comment
does not just address this paragraph):
1) Be consistently clear that protocol
operations are on a “routing set only” and
that said data structure is different from the
routing table / FIB.
2) Use said “routing set” as appropriate for
protocol operations — for example, for
finding next-hop information for forwarding
RREPs
3) Provide a clear discussion somewhere as
to when the content of the routing set is to
be reflected into the routing tale / FIB —
and, in doing so, what information should
be reflected, and how (noting “removal of
entries” as well as adding of entries).
must -> MUST ?
I would remove the two last sentences.
While I do know of good ways of unicasting
RREQs, and do not know of any good
reasons why multicast RREPs would be a
good idea, there’s no need to explicitly say
“future extensions MAY enable …”
something, nor saying “RREQ messages
are usually multicast” to leave the door
open for extensions — just make sure that
this specification does not explicitly prohibit
something should suffice [and remove the
cruft a bit].
I note, though, that this section heading is
“Multicast Route Message Table” yet it talks
about RREPs (which are not multicast).
Suggest that the title is wrong?
What is that? Specifically, “the IP address”
— assuming a “node” can have multiple
interfaces, each with multiple addresses?
Incidentally, this is an instance of why
“node” is not a helpful term, and where its
use leads to imprecision.
“a packet” and “the packet” and such are
used a little scattered through this.
In RFC5444-terms, “packet” are welldefined.
I think that this section is not
referring to that “packet” but to “application
data packets” that trigger route discovery
— right?
2119-language?
If a “node” can be a router, a host, or both,
then a “node” can have multiple addresses
— on multiple interfaces. In that case, what
is “the address or address prefix of such a
node”?
I think that, again, the answer here is to rid
the specification of “node” and work
through it “routing to addresses”.
“An IP address…” — any address, that is?
I think that it is a little more tricky than that:
if router A has two interfaces A1 and A2,
and router B has two interfaces B1 and
B2…and that (for example, due to different
media/frequencies/channels) bidirectional
connectivity exists only between A1 and B1
exists, then for B to use A as a “meaningful
next hop” it would need to have A1 as
Route.NextHop — recording A2 would be
useless.
So it’s, almost definitely, not “an IP Address
of the AODVv2 router” but rather a
*specific* address of that router — which
must be carefully determined and recorded
by the processing.
In general in the multiple-interface-multipleaddress
case, there’re a lot of subtleties to
work through to make sure that things don’t
break. This “An IP address …” is an
indicator that it’s worth taking a good and
careful look to verify that all these subtleties
have been worked through.
How is this different from the information
stored in the “Route Message Table”? It
would seem that the sequence number for
a route is the sequence number for the
router generating the RteMsg that installed
that route — and which therefore should be
in the Route Message Table?
I would suggest that it would be more
“logical” to keep this information in the
“Route Message Table”, and not keep
“Invalid” routes around in the Routing Set?
I assume that you mean “application data
packets” here?
Is this a 2119-may?
This is all fine information to have, but I
would like to see this expressed apart from
the data structures, as part of the state
machine and processing description.
Embedding processing, state transitions,
into the data structure description does
make it much more likely to accidentally
overlook it. There’s a few of these “set
entries which have state transitions” and I
did have to doodle diagrams to keep it
straight in my head whilst reviewing. This is
especially needed if not able to “read it
through in one sitting”.
