Updates in line:
On Mon, Aug 3, 2015 at 7:28 PM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
Hello folks,
If no objection, I could forward this email to the [manet] mailing list as
well.
Regards,
Charlie P.
go for it, shows we are responding to comments
-------- Forwarded Message -------- Subject: Re: [manet]
draft-ietf-manet-aodvv2-11 review Date: Mon, 3 Aug 2015 11:27:46 -0700 From:
Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
<charles.perkins@xxxxxxxxxxxxx> To: Marc.Mosko@xxxxxxxx
Hello Mark,
Here are some follow-up comments to your observations.
On 7/24/2015 12:57 PM, <Marc.Mosko@xxxxxxxx>Marc.Mosko@xxxxxxxx wrote:
- 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.
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!
- Comparing sequence numbers. Section 4.4 says you wrap from 65535 to 1,
but all the sections that I saw comparing sequence numbers just use “>” or
“<“ or “=“. For example, Sec 6.5.1 bullet #2 “Compare sequence numbers”
does not address wrap-around. How do you handle comparing wrap-around?
The old aodv spec had a section on that. Is it RFC 1982? If it’s defined
somewhere and I missed it? I think sec 4.4 should define this.
Yes, I agree that the specification of this comparison needs to be in the
current document. This was apparently just noticed recently, or anyway
nobody complained until recently and I somehow mistakenly assumed that the
comparison was specified since it had been in previous versions.
Added as described in my other email today
- Section 6.3 says “In its default mode of operation…” what’s the other
mode besides RFC5444?
That remains to be specified. Probably we don't need to say that here;
the language has been in there since Ian made the first attempts to conform
to RFC 5444.
removed "In its default mode of operation"
- Section 6.3 says “When multiple interfaces are available, a node…” This
should be clarified if it means both a router and client or just router
(see comments on clarifying multi-homing).
It just means the router; the word "node" could be replaced by "AODVv2
router" for more clarity, although the rest of the paragraph really only
applies to routers.
done.
- Section 7.1.2 bullet #2 says “Verify the message hop count, if included,
hasn’t exceeded MAX_HOPCOUNT.” However, D.2.2 does not include that
check. It’s done in D.2.3 Regenerate_RREQ (which is described in 7.1.3).
added into d.2.2 and equivalent for received RREP.
- Section 7.2.2 bullet #2 on MAX_HOPCOUNT for RREP has parallel
inconsistency with D.3.2 and D.3.3.
Good Catch!
if (msg_hop_limit < 0)
- D.2.3 Regenerate_RREQ decrements the inRREQ.HopLimit, but I did not see
in Receive_RREQ that is assures the inRREQ.HopLimit is positive.
Well-behaving nodes should never send a RREQ with a 0 hop limit due to
rules in Regenerate_RREQ, but if a misbehaving node does it will cause a
math issue possibly wrapping around to some large positive number.
- D.3.3 Regenerate_RREP probably has the same issue.
added
Thanks much for these comments.Vicky.
Regards,
Charlie P.
Regards,
