On Wed, Aug 12, 2015 at 8:20 PM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
Hello Vicky,
Follow-up below. I will omit huge portions of the email to avoid
obscuring my comments...
On 8/12/2015 11:01 AM, Victoria Mercieca wrote:
Hi Charlie,
I've just made my way through Thomas Clausen's comments, but I wanted to
follow up on yours before summing up...
For the "Router Client" definition, how is this...?:
"An address or address range corresponding to one or more nodes which
require an AODVv2 router to initiate and respond to route discoveries on
their behalf so that they can send and receive IP traffic to and from
remote destinations. The AODVv2 router's interface addresses are also
configured as Router Clients."
This is good. The AODVv2 router also forwards data to/from its clients.
I don't know if you can work that into the definition.
In the Router Client section, we have a statement:
"An AODVv2 router MUST provide route discovery services for its own local
applications and for other non-routing nodes that are directly reachable
via its network interfaces."
But...is "directly reachable via its network interfaces" misleading, given
your comment below...?:
"Notably, a Router Client is not required to be a single hop away from the
AODVv2 router, for instance if the client is on a connected subnetwork with
multiple links and non-AODVv2 routers providing local connectivity. This
has been a feature of AODV design since long before RFC 3561."
Well, how about "reachable without traversing other AODVv2 routers"? Or
something similar?
done.
appendix saying to complement with an IP address, or if there was some
I'm O.K. with keeping Table 1. The descriptions from Table 1 could be
imported into the definitions. Who knows why it is so incredibly
frustrating? Maybe it's a language issue, and frustrating means something
else in this critique.
I've moved them into the Terminology section and removed the table.
O.K.
“one of the sequence numbers maintainedIP address.
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 ______”
I'm O.K. to restrict AODVv2 routers to maintaining a single Sequence
Number for all of their addresses, but I believe we were previously
requested not to do this. I don't know what "complemented" means in this
comment.
I think in our Appendix we say something about complementing it with an
Well, then this comment is simply wrong. The appendix suggests a way to
*expand* the specification to support a currently unsupported feature.
That is drastically different than saying that "the sequence number is not
enough"!!
Yeah, not sure then, whether that comment came about from the Multi-homing
of, we'd send a RERR. That's because the route hasnt been requested (via
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”.
I would prefer to keep it that unreachable means that something is
broken, not that Route Discovery simply has not yet been attempted.
Well, if someone forwarded us a packet for an address we had never heard
us)... but we wouldnt be responsible for requesting that route. The
sender's local router would, so I think you are right here.
Unreachable Address
An address reported in an RERR message, either the destination address of
an IP packet that could not be forwarded because a valid route to the
destination is not known, or the address on a route which became Invalid.
This is O.K. with me. A possible change might be to delete the first
clause; the address is reported in the RERR message *because* it's
unreachable, not the other way around. You could add another sentence: "An
Unreachable Address is reported in an RERR message.", but that starts to be
specification instead of definition.
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?
No problem to change instances of "List" to "Set".
I thought this initially, but then I remembered that we have an
AddressList, and then a PrefixLengthList, and then a SeqNumList, and
although in the RFC5444 representation, the order doesnt matter, for AODVv2
data elements, it does, because AddressList[1] and PrefixLengthList[1] and
SeqNumList[1] all are linked. If we just called it a "set" instead, then
how do we ensure that this info will be grouped together? Or do we need to
define something different which has all those elements grouped into one
structure, so we'd have something like OrigAddrInfo (address, prefix,
metric, seqnum, validityTime, etc), and TargAddrInfo (address, prefix,
metric, seqnum, validityTime, etc), rather than AddressList (Orig then
Targ) then PrefixLengthList(Orig then Targ) then SeqNumList (Orig then
Targ)?
I think you are right. Anyway, perhaps it should be discussed more on the
[manet] mailing list after Last Call.
Yes.
I strongly disagree with the assertion that inmay or MAY?
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.
We could change it to say "may be more important".
"might be more important"
done.
"On routers unable to
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.
Right now our security is hop-by-hop and so the above doesn't apply.
Plus, I think we did have something about encryption providing
confidentiality.
so i think the comment here is that we should point out how this affects
applicability so people can determine if it's applicable to their situation?
I'm not sure how to do that... Perhaps the effect would be that
hop-by-hop security needs more power and more code and maybe more
administrative control for the key establishment.
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?
It matters about whether the sequence number is stored across reboots.
The penalty is waiting for longer if the sequence number is lost. The
document used to have language for that purpose. In the interest of time
(new version tomorrow!) I will look that up later.
The document can explicitly say "sequence number information" at the point
where it mentions persistent state. However, I think that information
belongs elsewhere in the draft, because it is a small bit of specification,
not applicability. If you can find a good place to put it, so much the
better.
In Applicability currently we have:
Also, I recommend to not say “subnet” —I tried to use "address range" - I dont know if that really helps, but I
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.”
This would O.K., except a lot of people understand the term "subnet" and
I would have thought we should appeal to that intuition.
tried to make some of the wordier bits simpler in later sections where we
mentioned "subnet" before.
As long as it reads well, the alternate language is O.K. However, I still
think that "subnet" carries with it important connotations which are in
fact relevant here.
There’s no “cost”, distance, metric,
associated with these attached networks?
I’d think that that’d seriously hamper some
deployments..
Actually, we should allow assignment of costs to Router Clients. This
would be done by having RREP_gen initialize the cost field to something
nonzero before transmitting the RREP. That was done in RFC 3561. I don't
remember why someone complained about it in AODVv2 and I got tired of
arguing about it. Vicky, if you want to specify that RREP_gen can
initialize the cost field to something nonzero (easy to do for hop count),
please feel free. Or I can do it when I get the editorial pen.
Should the cost be set differently for each router client? ie in the
router client table? or just some global value that the router uses for
every client?
That is a matter for discussion. We could augment the AODVv2_INTERFACES
list with per-interface metrics. We could allow the AODVv2 router to refer
to any other information it has in its route table for its clients.
people think of protocols where that is the case.
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?
AODVv2 does not require knowing all neighbors.
I guess the use of the terms "neighbor table" and "adjacency" makes
There are only so many words in the English language...
that there is just one seqnum per router. the other alternative would have
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 …
I don't think we have to do this before Last Call, but (a) I am happy to
do it and (b) text is always appreciated.
on the topic of seqnums, from a previous email, i decided we should say
been one seqnum per router client (but then that could mean an awful lot of
seqnums). we could revert to a seqnum per interface, but need to make it
clear that the seqnum is from the interface on which the router client is
connected? how does this work if the router client is the AODVv2 router
itself? which interface would it choose? the message might go out on
several interfaces...
Let's go with a single seqnum and worry about multiple seqnums later if
there turns out to be use cases for that.
OK.
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).
Again, AODVv2 can be implemented by operations directly on the route
table. We did it.
I dont know much about the details of this. How did you deal with the
route states? which ones did you install directly into the route table,
when did you add and remove them?
We changed <sys/route.h> to do exactly what we wanted. We added and
removed entries according to lazy evaluation, not keeping any timeout
queues. In early implementations, we did do kernel timeouts but that has a
significant cost.
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?
If only.
they can be now, when using the unconfirmed route to OrigAddr to forward a
RREP. maybe he didnt read that far yet?
As you know, I think this is wrong. I am not saying we need to do
anything about it for the upcoming revision.
What is that? Specifically, “the IP address”
— assuming a “node” can have multiple
interfaces, each with multiple addresses?
Can change to say "application" instead of "node".
is this clear enough?:
"An IP address of the originating node, i.e., the source address of the IP
packet triggering the route request. "
The application doesnt really have the IP address.
That's fine with me. But an application DOES have an IP address when it's
running.
Yeahh ok, will see what feedback comes in but we could update to say IP
address used by the application.
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”?
Could say "an address"
currently says:
"An address of a node or address prefix of a network. "
or is that dangerously close to subnet?
maybe:
"An address, which, combined with the Prefix Length, describes the set of
destination addresses this route includes"?
The latter is a worthwhile bit of verbal virtuosity which is fine with me.
updated to the latter.
Vicky.
This is all fine information to have, but Ito mention things without explaining. Sometimes the explanation seems
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”.
Text is always appreciated.
Teasing apart all such descriptions might take a long time, and so we
could discuss it after issuing revision 12 (i.e., during Last Call). I am
not sure what exactly is being requested here. In general, collecting
together relevant information is a good idea, and to the extent that
placing a textual firewall between processing, state transitions, and data
structure descriptions detracts from that, we would need to assess the
impact on clarity.
I do aim to look at this separation, but as I said above, it can be hard
necessary.
The top priority is clarity, for sure. It would be nice to see the doodle
diagrams, but I'm not asking.
Regards,
Charlie P.
Regards,
