[aodvv2-discuss] Comments left to address before rev 12
- From: Victoria Mercieca <vmercieca0@xxxxxxxxx>
- To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
- Date: Wed, 5 Aug 2015 11:19:20 +0100
Hi all (although I'm guessing only Charlie is around to read this!)
I wanted to sum up the status of comments left to address without everyone
having to wade through the previous emails.
Also Charlie, if you would like to chat about these later I would be happy
to have a teleconference.
We had "2 weeks" to do the next revision, I guess that means Thursday
(tomorrow) really?
Starting with Chris Dearlove's comments:
----
SHOULD/should etc. I've also updated uses of MAY/may but this is the one I
have left which I'm not sure about:
"AODVv2 does not specify which method
should be used to restrict the set of AODVv2 routers that have the
responsibility to regenerate
multicast messages. "
Not sure if I should change that one to capital SHOULD?
----
"Section 4.5 Is this table conceptual like that in 4.6? (Later in section
uses word comparable that wouldn’t be my choice.)"
----
"Section 5.1. I don’t like that non-hop-count metrics aren’t described (as
hop count really isn’t good enough in reality) and that adding a new metric
type means adding code. The latter is a design issue, so there is no
right/wrong here."
----
CD: "Section 5.3. I don’t understand why a stored invalid route can’t be
overwritten by a new higher metric route. (Sequence number, that I
understand.)"
VM: This is the loopfree section... well... if we have a newer seqnum, the
route is automatically seen as not forming a loop. so we dont check
loopfree... so if we look at a case when we do check loopfree, the seqnum
of the advertised route must have been the same as the seqnum of our
existing invalid route. If AdvRte has a worse metric than current Route, we
cant guarantee it's loop free and shouldnt use it. It doesnt matter if our
route is invalid... we could be installing a route which formed a loop, now
assuming its a valid route, and send traffic down that route, only for it
to go round and round.
CP: I agree with this explanation.
VM:This makes me wonder again if the LoopFree statement should include the
seqnum test.
i.e. "loopfree is true if seqnum is newer OR if the metric comparison says
so".
Or should I just try to include this explanation in the "default metric
type section"?
Lotte: I think it would make sense to send this explanation back to the
mailing list :)
----
Section 6.2 is where I think bidirectionality becomes MUST, so earlier
SHOULDs may be wrong.
Anyone see which ones?
----
Section 6.3 para 3 is I think unsupportable, to say that it’s outside
AODVv2 who regenerates messages. This is essential for compatible
interoperability.
How should we address this?
----
Section 6.4 page 23 para 3 why fixed buffer? And as this is supposed to be
IP’s job, why specify?
CP: Because IP did not have to deal with reactive route establishment
before. Side comment: I thought Chris had been around long enough to
understand this... interesting that he is asking...
VM: Should we just remove it? just leave the paragraph beginning "Data
packets awaiting a route MAY be buffered by RREQ_Gen. " and leave the
implementation details vague?
----
Section 6.5.2 made me realise a major omission. This is all about AODVv2’s
tables. But at some point those need copying to IP’s routing table (as
additions/updates/removals) and that’s not discussed, and it’s not listed
in Appendix A. Also all the text in the document uses the AODVv2 tables,
which is fine when within AODVv2, but of course any IP packet unicast (I
think multiple unicast is noted as an alternative to multicast – and
there’s a comment on future use of unicast) would use the IP table, so
would need to get that timing right. (Futureproofing in the latter case,
but the multiple unicast may need thought.)
This cropped up in a previous discussion on this list...
Lotte: Yes, I think as part of the discussion that ended in Multicast RREP.
Do we need to add additional text for this? Also, I'm not quite sure what
he means by “get the timing right”– if we add/modify a routing table and it
is Active or Idle, the IP table should be modified accordingly as well
(i.e. add route or extend its lifetime). When a route becomes Invalid,
remove it from the IP routing table immediately. Or am I missing
something?CP:Discussed in other email. For any such conditions as this,
kernel implementation is better. But user space implementation has so many
other advantages that many people will prefer to not worry about it.
CP: It has to be allowed to make conformant AODVv2 by modifying the IP
route table directly. In fact, this would be the preferred implementation
for many platforms (e.g., IoT) that need small footprints.
So, making requirements about when to update the IP route table to match
AODVv2's internal route table information is out of scope, and even worse
would be cause IP internal route table implementations to be out of spec.
Lotte:This may be my lack of experience talking, but I'd figured that with
most IP routing tables, it is not possible to add things like route state
or sequence number to the entries.
But I can add some perspective on the IoT aspect: When I initially
implemented AODVv2 for RIOT, we didn't have *any* other routing table– the
network stack would simply ask AODVv2 for the next hop, and AODVv2 would
look it up in its own table and answer (or start a route discovery). Now we
have a flashy new FIB, and the guy who implemented it and I discussed a lot
about possibilities for other routing tables to add their own attributes to
FIB entry (which would obsolete the need for a dedicated AODVv2 table)...
We decided not to do this in the end, so AODvv2 is still maintaining its
own table internally and updating the FIB when relevant changes occur.
I agree that it would be bad to make it a MUST, but adding an “If you have
to fill an outside routing table, do it on these occasions” could be done
imo if it is considered useful.
VM:So should we add any text regarding this?
----
Section 6.7.1 about using idle and active routes to forward packets, this
is also where that is done by IP, so it should be about idle and active
routes being in IP’s table.
again, difference between AODVv2's route table and IP's version
----
Section 7.1.3, that situations where RREQs are not regenerated are not
declared makes me very uneasy.
CP:I do not understand this comment... This section is about
regeneration. "not regeneration" is described in other sections... What
is wanted?
VM:Well, we said "The full set of circumstances under which a router may
avoid regenerating
a RREQ are not declared in this document, though examples include the
router being heavily
loaded or low on energy and therefore unwilling to advertise routing
capability for more
traffic. "
I guess Chris is concerned that some implementations may decide not to
regenerate a RREQ and therefore the whole network will fall over. If
implementations can decide their own reasons not to regenerate, this could
cause issues. Should we re-word it to say "A router may avoid regenerating
a RREQ if it is heavily loaded or low on energy and therefore unwilling..."
and get rid of the bit about "full set of circumstances"? Is that an
improvement? I'm not sure...
----
CD:
Section 12. I’m not sure it’s up to this document to specify TBD numbers. I
also know from experience that IANA won’t be happy with this presentation.
They need it spelled out in detail, add this entry to this table, and so
on. Look at the various OLSRv2 documents for details (especially later
ones).
Already existing TLVs shouldn’t be in the IANA section – this is
instructions to IANA what to do.
VM:so looking at OLSR, it says "This specification defines four Address
Block TLV Types, which have been allocated from the "Address Block TLV
Types" namespace defined in [RFC5444]." so I've tried to do similar. Also,
from OLSR:
24.6. NBR_ADDR_TYPE and MPR Values
Note: This section does not require any IANA action, as the required
information is included in the descriptions of the MPR and
NBR_ADDR_TYPE Address Block TLVs allocated in Section 24.5. This
information is recorded here for clarity and for use elsewhere in
this specification.
should we mimic this for the address types and the metric types?
----
Also why allocate a new SEQ_NUM TLV, I think the existing sequence number
TLV (the version named (COMPLETE) – I’d just say that once somewhere) will
do.
CP:SEQ_NUM TLV is used in RERR. I don't know about "COMPLETE"...?
VM: So there's an existing sequence number TLV we could re-use? I dont know
what COMPLETE means either, unless it was Chris' note to himself to lookup
what the existing TLV is called before he sent in his comments?
----
Section 13, para 4, what’s said is true, but it’s not as simple as this
makes it appear. (And there are issues of information leakage in other
layers.)
I don't know what to make of this.
We need to ask what Chris means and how we can address this.
----
Section 13, specifying TIMESTAMP data, suggest indicate algorithm number.
CP:It's Message TLV number 6. I'm not sure what indication is requested.
VM: Take a look at
https://tools.ietf.org/html/rfc7182#section-13.10 - the
algorithm number looks like it is relevant to the ICV TLV actually, but
looks like type extension is relevant to TIMESTAMP.
We say "Sequence numbers can be used as timestamps to protect
against replay, since they are known to be strictly increasing." ...So I
guess type extension zero is the one? And we have to make sure we say how
to interpret it? Do we need that detail in this document?
Do we have an algorithm preference for the ICV?
----
Appendix A I think should be about two way interaction with IP, and is
missing IP routing table update. It’s also very underspecified. For example
the ability to queue packets has requirements to add packet to queue, to
flush queue. Is it IP’s responsibility to release queue when a route
appears?
Route table update, if discussed, should be another appendix. The
responsibility for sending queued packets depends upon where they are
queued. Our previous buffering implementations did operate at the IP
layer, which makes sense conceptually.
Well, we've called Appendix A "Features Required of IP" so route table
update could come under this. What text should we add to address Chris'
comment?
----
Appendix D needs to have its normativeness indicated. Is the description
in the main body (which as I note I haven’t reviewed) complete and
normative, and this is example? (That would handle if there’s any
mismatch.) Otherwise things get messy.
These ought to be examples and not normative.
Appendix D is entitled "Example Algorithms for AODVv2 Operations" - what
should we say to avoid confusion?
----
Section 3. AODVv2 doesn’t support some things that OLSRv2 was required to
support, in particular using same address on multiple interfaces (with a
limitation that made that practical) as some wanted unnumbered interfaces
(Stan IIRC).
CP:This is another consequence of OLSR's requirement to know the complete
topology.
VM: not sure how to address this then...? also related to comment from Marc
Mosko, see below.
----
Comment from Marc Mosko:
- multi-homing: Is this implying that a Router Client can only have 1
network interface and only 1 IP address? What happens if it has, say 2
radios, but is not willing to forward packets for another node? It would
help to have a strong definition of what “multi-homing” means or maybe say
a bit more in the definition of a Router Client.
CP:It means that a Router Client can only be a client of one AODVv2
router. That restriction could be lifted, but it would take additional
specification. There should be no restriction on a Router Client having
other interfaces as long as the same IP address is not served as the client
of multiple AODVv2 routers.
We could sharpen this up a bit without too much damage to the current
specification. But I would like to avoid if possible the requirement to
specify how an AODVv2 router might "partition" its AODVv2_INTERFACES into
separate "lists" of AODVv2_INTERFACES that have separate SEQ_NUMs. At
least, not have to do it this week!
VM: what can we do, if anything, to address this comment now?
I've put in Appendix B:
"Multi-homing is not supported by the AODVv2 specification. A Router Client
can only be served by
one AODVv2 router at any time. The coordination between multiple AODVv2
routers to distribute
routing information correctly for a shared address is not defined. See
Appendix C
for information about how to move a router client to a different AODVv2
router. "
In the Router Clients section, should we have something like "If a router
client has multiple IP interfaces, each of those interfaces should be
served by only one AODVv2 router." ?
A router client is an IP address. Thinking if the router client node had 2
interfaces, and therefore 2 IP addresses, and was attached to a different
AODVv2 router on each, then the routers wouldnt both have the same router
client entry for that node. Not sure which interface the router client node
would try to use though, and therefore which AODVv2 router would end up
requesting a route. If they tried to send on both interfaces, both routers
would send RREQs, but for different OrigAddrs. Is that a problem?
----
Kind regards,
Vicky.
Other related posts:
