Hello folks,
More follow-up on John's comments...
On 11/3/2015 6:39 PM, John Dowdell wrote:
Section 4.5 Multicast Route Message Table (MRMT). This and section 4.6 could really use some introductory words on the uses of the MRMT, Local Route Set and the RIB (or other forwarding table belonging to the operating system), just to set the context for what is to be discussed. This table also needs to be mentioned in the introductory paragraph of section 6.
RREP: It would be worth explaining when RREPs would be multicast, as it is not obvious (or wasn’t to me anyway).
All through this section: would be worth tightening up on the name of the parameter when mentioned (e.g. RteMsg.OrigPrefixLen: The prefix length associated with /*RteMsg*/.OrigAddr)
RteMsg.OrigSeqNum: “The sequence number … if present …”. Why would the sequence number not be present?
RteMsg.RemoveTime: The time .. MUST be removed …”. Removed from where? Also there are two event times mentioned in this definition, which takes priority, or is it whichever is earlier or later?
Section 4.6 Local Route Set
Para starting “Note that multiple entries …” (bottom of page 15), second sentence “… but may offer improvement …”. So why is that route still Unconfirmed? Is it really up to the implementor to decide which routes to confirm and which to not? This sounds like a potential interoperability issue to me.
Section 5 Metrics
Bullet 2 “ …AODVv2 cannot store routes that cost more than MAX_METRIC(MetricType)”. Anything is possible. Surely “AODVv2 /*MUST NOT*/ store routes …”?
Section 6.3 Neighbour Table Update
Neighbour.IPAddress … where do we find this information, since it isn’t (according to the table in section 7.1) explicitly in the RREQ message? I guess it’s the source address of the RFC5444 packet. In any case, how can we assure that the neighbour IP address that RFC5444 parser uses is the same as the one that AODVv2 has allocated to the interface the message was to be sent over?
Section 6.4 Interaction with the Forwarding Plane
Second bullet in the second batch of bullets reads “A route discovery was not attempted”. Why would the router not attempt the discovery?
The sentence continues “any buffered packets requiring that the route be discarded” which should perhaps read “/*If any packets are buffered, they MUST be discarded and the source of the packet should be notified that the destination is unreachable (using an ICMP Destination Unreachable message”.*/
/*
*/
Section 6.6 Route Discovery …
....
Fourth paragraph reads "Determining which packets to discard first when the buffer is full is a matter of policy at each AODVv2 router. Routers without sufficient memory available for buffering SHOULD have buffering disabled. This will affect the latency for launching TCP applications to new destinations.” So what is the behaviour here when buffer space is constrained? Should the router discard the packets while seeking to discover the route, without sending ICMP Destination Unreachable? Whatever the behaviour is, please advise some text to put here because it’s not clear.
Section 6.7 Processing Received Route Information
“All AODVv2 route messages contain a route”. Surely the RREQ message generated by RREQ_Gen does not include any route information yet?
Section 6.8 Suppressing Redundant …
First para “… and generates unnecessary signalling traffic and interference”. Interference? How can we be sure, this will depend on the exact radio configuration used? Suggest to delete the words “and interference”.
...
Section 6.9.2 Reporting Invalid Routes
There are three conditions when an RERR SHOULD be sent. Are there no conditions when an RERR MUST be sent?
Section 7.1.2 RREQ Reception
Point 1, bullets 1 and 2; where is Remove Time defined? I couldn’t find a definition.
Point 7, suggest the words “is redundant” are replaced by “was previously received”. The word ‘redundant’ is so abused in the UK (mostly by HR departments in relation to people they can no longer afford to employ) that the meaning is now unclear.
Section 7.2.2 RREP Reception
Step 1; should the blacklisting also be revoked?
Step 7 7; what should be the action if the route to TargAddr does not match an outstanding route request? Should the RREP be discarded?
7.4.1 RERR Generation
I was just wondering if we should make an exception for ICMP messages particularly those signalling errors, and not send an RERR in those cases. We could potentially have a compound situation where the routers are trying to deliver ICMP failure messages when the user data IP packet has already triggered an RERR. Or am I chasing my tail here? This occurred to me because a router is required to discard the IP packet that triggered the RERR, and got to wondering whether we should send an ICMP message. I’m open to discussion here.
Third bullet starting “When a link breaks …”. There is a point about MTU being exceeded … we’re sending AODVv2 messages, not RFC5444 packets. How will AODVv2 know the MTU is being exceeded? In fact how do we know the MTU at all, since AODVv2 has not asked to be notified about it by the forwarding plane in section 6.4. Anyhow is that not the RFC5444 parsers problem (or maybe even the SMF parser if that is being used as well)? Perhaps we should convert that text into an advisory to the implementor.
Sending an RERR in response to an undeliverable IP packet … SHOULD be sent unicast to the next hop or /alternatively/ MUST be multicast … which is it please? I can sort of see what is being said but the logic is not clear.
Section 7.4.2 RERR Reception
Typo … Step 1 bullet 1 .. ignore this RREP … should read ignore this /*RERR*/.
I believe we need to use stronger language in the sentence “If any of the above are false …”, I propose "If any of the above are false, the LocalRoute does not need to be made Invalid and the unreachable address does not need to be advertised in a regenerated RERR.” be changed to "If any of the above are false, the LocalRoute /*MUST NOT*/ be made Invalid and the unreachable address /*MUST NOT*/ be advertised in a regenerated RERR.”
There are conflicting directives all over the second half of this section. If we have routes matching those in the RERR, SHOULD or MUST an RERR be regenerated? There is no defining logic here. The bullets in step 2 sometimes say we SHOULD, the directive at step 4 is to do it anyway. There is no clear decision tree. I propose that we MUST regenerate an RERR in all cases if the RERR passes the validity test in the first half of this section.
8. RFC5444 Representation.
Hold up. Control plane message SHOULD use RFC5444? I thought that was the whole point of AODVv2. Surely MUST?
Section 11.2 Protocol Constants / Section 11.6 MetricType Allocation
MAX_METRIC[MetricType] … just a note for the future that DLEP had a discussion on the field length of a metric. Might as well recommend that AODVv2 metric fields are compatible with DLEP.
Section 13 Security Considerations
There is a theme of reliance on ICV to show the message has integrity. That’s ok by itself, but it should also be pointed out that the messages must be robustly processed according to the steps in section 7 (which must itself be robustly specified). If there are holes in our specifications, or if there are implementation holes, or chances for common attack vectors (e.g. sending a huge RERR causing a buffer overflow), then that’s a problem, particularly for the constrained memory devices we have discussed in the past.
