Hi Vicky,
Am 08.11.2015 um 23:14 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
Hi Lotte, everyone,
just one comment below regarding the MTU discussion.
On Sun, Nov 8, 2015 at 8:56 PM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx> wrote:
Hi all, sorry for the late reply,
I'm just going to plop some comments to John's review inline and then go
through Vicky's diff :)
Cheers,
Lotte
Am 04.11.2015 um 03:39 schrieb John Dowdell <john.dowdell486@xxxxxxxxx>:
Hi all
So here’s my review of -13a. I’m aware that there is a -13b but since I’m
halfway through -13a it makes sense to carry on. Apologies if I’m raking up
stuff that’s already been addressed.
[...]
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.
Section 7.4.3 RERR Regeneration
Step 5 … again we need to advise the implementor that an RERR with lots of
addresses could break an MTU and so there needs to be a check somewhere when
the packet is to be sent to the interface. AODVv2 is not in charge of
forming the packet.
No, but it is in charge of forming the message. I hope I'm not
misinterpreting you but... At packet-level, the 5444 builder/parser can't say
"oh, this message is way too big to be sent out in one chunk, I'll split that
up" because it doesn't know how to split the message up in a way that it can
still be understood by the receiving end (i.e. the AODVv2 instance on the
neighbouring node).
So (I guess) it has to just send out its packets and pray that the underlying
layers will work their fragmentation magic and that none of the fragments get
lost, because the retransmissions would cause overhead... Since AODVv2 was
also designed for environments in which it was rather likely that fragments
could get lost, I'd just always assumed that the goal behind that step was to
convey as much information as we can with as little packets as possible. So
if an AODVv2 implementation happens to know that their RREP is going to be
too big, it makes sense to split it up into multiple RREPs, and if only half
of them reach their destination that's better than nothing. I understood Step
5 as a hint that they should to this if their system permits them to and
they're fine with the possible layer violation.
Whew, that was a lot more text on my part than I'd anticipated and I'm not
quite sure what to make of it...
Wellllll also, how can we know exactly where the limit is, based on our Data
Elements, if RFC5444 is going to move bits around and organise the message
how it likes? I'd imagined the RFC5444 parser is given chunks of information
"this address with these TLVs, this other address with these other TLVs"
which it could then arrange in a way that it doesnt include an address if the
associated TLVs cant also be added without exceeding the MTU. It doesnt need
to know how AODVv2 works, it just deals with chunks of information,
addresses+TLVs.... although I could be wrong :)
Regards,
Vicky.
Again … SHOULD be unicast or MUST be sent multicast? Which is it please?
Suggest something like "if the message cannot be unicast it MUST be sent
multicast”.
8. RFC5444 Representation.
Hold up. Control plane message SHOULD use RFC5444? I thought that was the
whole point of AODVv2. Surely MUST?
I haven’t checked the mapping to RFC5444 TLVs because my head hurts, but it
looks beautiful.
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.
Appendix C.
My page 74 is blank for some reason.
Similarly there are some text flow problems in this section, perhaps where
code blocks are included, e.g. C.2.1.3, C.2.2.
I’m, not going to check the code, not really my area!
Overall
Quite a fabulous document. Looks a whole lot better than it did a year or so
ago. Well done all.
Cheers
John
