Hello Vic,
Follow-up below...
On 8/6/2015 6:03 AM, Victoria Mercieca wrote:
It is a conceptual table because it never appears as a data
element in a protocol message. I don't think use of the word
"comparable" affects this determination. The specification says
something like that "if these protocol messages are comparable"
then "do this to the conceptual table".
I updated to say that it is conceptual, and also removed the word comparable so the paragraph under the list of fields now says:
"The RteMsg Table is maintained so that no two entries have the same MessageType, OrigAddr,
TargAddr, and MetricType. See [](#suppress) for details on updating this table. "
In Suppressing Redundant Messages, it now says:
" * If there is an entry, update the timestamp field, since matching RteMsgs are still
traversing the network, and continue to Step 2."
matching instead of comparable.
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 :)
If you include that, then someone else could very well complain
that it's completely unnecessary to include it.
I've tried to slightly re-word. This is the paragraph now:
"The LoopFree function for the HopCount metric is derived from the fact that route cost
increases with number of hops. Therefore, an advertised route with higher cost than the
corresponding stored route could include the stored route as a sub-section. Replacing the
stored route with the advertised route could form a routing loop. LoopFree returns FALSE to
indicate that an advertised route with higher cost is not to be used to update a stored
route. In the case where the stored route is Invalid, it is possible that the advertised
route includes the stored route and came from a router which did not yet receive notification
of the route becoming Invalid, so the advertised route should not be used in case it forms
a loop."
----
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?
We should not address it. We do need to allow for multicast to be
transmitted over multicast backbones that are not brute force.
Is this comment about reducing multicast overhead?
Section 6.4 page 23 para 3 why fixed buffer? And as this isCP: Because IP did not have to deal with reactive route
supposed to be IP’s job, why specify?
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?
Here I am not sure. I don't see the problem with leaving the
paragraph. If we leave implementation details vague, then someone
could complain that the implementation is vague.
However, I think that we should replace "The packet buffer is
configured" by "The packet buffer SHOULD be configured" or maybe
even "The packet buffer MAY be configured". This does not affect
interoperability, but it DOES affect proper operation of data
transmission (i.e., the purpose of having a routing protocol in
the first place).
changed to "SHOULD be configured"
Section 6.5.2 made me realise a major omission. This is allLotte: Yes, I think as part of the discussion that ended in
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...
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?
I don't have any useful text to suggest. We already have the
feature listed in Appendix A. That should be enough.
OLSR says this:
"It is intended that the Routing Set can be used for IP packet routing, by using its contents to update the IP routing table. That update, and whether any Routing Tuples are not used when updating the IP routing table, is outside the scope of this specification."
and
"The state of the Routing Set SHOULD, however, be reflected in the IP routing table by adding and removing entries from that routing table as appropriate. Only appropriate Routing Tuples (in particular only those that represent local links or paths to routable addresses) need be reflected in the IP routing table."
This decision affects performance, not interoperability. You
could reword to avoid "full set" perhaps.
And, yes, if all the routers in the network decide to avoid
regenerate RREQs, it is going to impact the ability to establish
routes. Just like if they all decide to do something else horrible...
I think the point Chris was making is that we are leaving it open for people to decide their own reasons not to regenerate. We're not locking it down enough?
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?
I don't think it's needed before Last Call, but it wouldn't hurt,
if only for the reason that it shows that AODV author team is
responsive to comments.
for metric types:
Note: This section does not require any IANA action since it refers to metric types
identified according to the assignments in [](#RFC6551).
Although does this mean any future metric types would have to go through 6551?
for address types:
Note: This section does not require any IANA action, as the required information is included in
the descriptions of the [](#RFC5444) formatting. The values used in the Address Type TLV used
in [](#represent) are given in the table below:
----
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?
There isn't an existing sequence number TLV that predates the
AODVv2 specification.
RFC7182 says :
"A timestamp is essentially "freshness information". As such, its setting and interpretation are to be determined by the MANET routing protocol, or MANET routing protocol extension, that uses the timestamp and can, for example, correspond to a POSIX timestamp, GPS timestamp, or a simple sequence number. "
Do you think Chris could mean to use the TIMESTAMP TLV?
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?
Yes, IP does need to enable route table update. You could put
that in there.
added:
* the ability to install, update, and delete routes
The concept of releasing a queue is an implementation detail that
we do not have to specify.
didnt add anything else about queuing.
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." ?
That would be O.K. to add, as long as it would not engender
another long discussion. If you add it, make it SHOULD.
altered this bit:
RouterClient.IPAddress
: <vspace/>The IP address of the client node or subnet that requires routing services
from the AODVv2 router. A client node with multiple IP addresses MAY cause the AODVv2
router to be configured with multiple Router Client entries. A Router Client of one
AODVv2 router can not be configured as a Router Client on another AODVv2 router using
the same Router Client IP address.
