Hi Charlie,
I've had a look through this tonight.
A few comments:
Definition of iRREP_Gen in terminology says iRREP twice where I think you
mean uRREP the second time.
Definition of Originating Node has "The" twice.
Definition of Unsolicited Route Reply (uRREP) is a bit awkward. I'd say:
"An unsolicited RREP message is a RREP originated by an AODVv2 router
to a router which did not send a RREQ."
Also, is there a reason it's also known as gratuitous? Having just one term
would be preferable.
For consistency with a couple of changes I've made to the AODVv2 draft,
refer to OrigMetric and TargMetric instead of MetricList, also ValidityTime
but not ValidityTimeList, and rename OrigAddrMetric and TargAddrMetric to
OrigMetric and TargMetric. I will send you the updated versions of RREQ and
RREP tomorrow.
Your first description of DestOnly seems to be repeated in the very next
sentence.
"(namely, Route[OrigAddr] and
Route[TargAddr] respectively)" I think this sentence doesn't need both
namely and respectively. My personal preference is "respectively".
Route[TargAddr].SeqNum >= TargSeqNum should make it clear that it means
TargSeqNum from the RREQ, maybe use RREQ.TargSeqNum?
The line above that, where you say it needs a route to TargAddr, it should
be a route of the same MetricType as is being requested.
In iRREP generation section you mention setting prefix length list twice.
Also since recent mailing list discussion I removed the route.Timed flag,
so you should test if route.ExpirationTime is not MAX_TIME. (That is, if I
dont revert back to using route.Timed flag - recent emails mentioned that
validity time is not a strict limit on the usage of the route, it's an
indication that the route is only guaranteed for that time - so should we
still make the route invalid after ExpirationTime? If we dont make the
route invalid though, there's no point in having a validity time. Unless we
would choose to favor a route with no validity time over a route with a
validity time. We haven't mentioned that in AODVv2 route decision
procedures. Anyway I've started rambling... Just note that if we do choose
to go with removal of the Timed flag, this specification should match).
I'm happy with the idea of uOrigAddr and uTargAddr since this makes it look
just like the RREP we already know and love.
"RREQ.OrigAddr fulfills the role of the
TargAddr in the uRREP." This sentence confused me, whereas the next
sentences explain clearly what you mean. I'd suggest removing this
sentence. If there's still confusion I'd suggest using the fictional RREQ
to explain, with the uRREP being the response.
The comments above about route.Timed in the iRREP section also apply to the
uRREP generation section. It should probably also refer to route to
uTargAddr rather than route to OrigAddr since you are using uOrigAddr and
uTargAddr in this section to avoid confusion. Also the second paragraph
about prefix length in this section should be removed.
In the Message TLV Type Specification section, maybe this could mention
that its defining a RFC 5444 TLV and maybe mention IANA, a bit more like
the AODVv2 section?
Hope that helps!
Regards,
Vicky
On 29 Apr 2015 07:30, "Charlie Perkins" <charles.perkins@xxxxxxxxxxxxx>
wrote:
Hello John,
First, thanks for having a look at the document.
On 4/28/2015 5:24 AM, John Dowdell wrote:
Hi Charlie
Maybe I misunderstood but it's this text in section 5 that caught my eye:
"The sense of the addresses in the uRREP has to be reversed;
RREQ.OrigAddr fulfills the role of the TargAddr in the uRREP."
John
The point is to enable uRREP to be processed by any node receiving it, in
the
same way as such a node would process a "regular" RREP.
But the terminology is confusing. Better terminology is needed for this.
Regards,
Charlie P.