Subject: Re: [manet] AODVv2 comments

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 20 Aug 2015 11:36:59 -0700

Hello Chris,

Some of the AODVv2 authors are still on vacation, and so have not been 
able to review all of your recent comments.  Nevertheless, I hope this 
follow-up will begin to resolve your comments.

On Thu, Jul 23, 2015 at 11:56 AM, Dearlove, Christopher (UK) 
<[email-masked]> wrote:

    “Version 2” doesn’t appear in the draft title. (Not sure why only
    just noticed that.)

How about "Ad Hoc On-Demand Distance Vector Routing Version 2 (AODVv2)"?

    Section 1, what’s the difference between loop avoidance and loop
    freedom?

Loop freedom is the state of having no loops. Loop avoidance is how you 
ensure that. I guess this bit :

AODVv2 compares route metrics in a way that ensures loop avoidance.
    AODVv2 also uses sequence numbers to assure loop freedom, enabling
    identification of stale routing information so that it can be
    discarded.

can be reworded to:

To ensure loop freedom, AODVv2 uses sequence numbers to identify stale 
routing information, and compares route metrics to determine if 
advertised routes could form loops.

Does that sound ok?

    Section 2 is missing IAR. (Haven’t checked this section in detail,
    just noticed that.)

Added this into the Terminology section:
"Internet AODVv2 Router
     An AODVv2 router with an interface to the Internet."

But the IAR should also be allowed to interface to other external 
networks that are not "the Internet", so the name should be changed to 
External Network Access Router (ENAR).

    Throughout: inconsistency in using RFC 5444 and [RFC5444].

Changed to a reference throughout - will display as [RFC5444], except in 
section headings and in algorithm names in the appendix.

>     Section 3. AODVv2 doesn’t support some things that OLSRv2 was
>     required to support, in particular using same address on multiple
>     interfaces (with a limitation that made that practical) as some
>     wanted unnumbered interfaces (Stan IIRC).
>

As best I can tell, this seems to be a consequence of OLSR's requirement 
to know the complete topology. I don't see that this is a requirement 
for AODVv2.

>     Section 3 para 4 says route requests that can’t be confirmed
>     bidirectional should be ignored. Why should and not must?
>

Changed to MUST.

    Throughout: Much inconsistency in use of SHOULD vs should and MUST
    vs must. (Former in normative sections, latter or avoid otherwise.)
    Haven’t noticed for MAY/may but worth checking.

We have fixed some of these but specific suggestions would be very helpful.

> Section 4.2 last paragraph. I would have thought this was a MUST NOT.

Has been changed accordingly...

    Section 4.3 second paragraph should (SHOULD) or MUST? I would have
    thought latter, and I think some later text assumes latter. Also
    later in section.

Proposed new text:

    "Neighboring routers which cannot confirm adjacency when requested
    MUST be marked as blacklisted. Route Request messages received from
    a blacklisted router SHOULD be ignored to avoid unnecessary
    processing and generation of control traffic when it is known that
    the return path does not exist.  "

> Section 4.4 para 3 can probably should be a 2119 word.

Done.

    Section 4.4 sequence numbers wrap, so at the least a comment that
    indicates greater/less is according to that should be included. (An
    algorithm that properly handles the 0 omission would help implementers.)

Here's what RFC 3561 says:

>     In order to ascertain that information about a destination is not
>     stale, the node compares its current numerical value for the sequence
>     number with that obtained from the incoming AODV message.  This
>     comparison MUST be done using signed 32-bit arithmetic, this is
>     necessary to accomplish sequence number rollover.  If the result of
>     subtracting the currently stored sequence number from the value of
>     the incoming sequence number is less than zero, then the information
>     related to that destination in the AODV message MUST be discarded,
>     since that information is stale compared to the node's currently
>     stored information.

We have used that, except to replace "32-bit" by "16-bit". I am 
mystified why this was omitted from AODVv2, but no one ever noticed it 
before.

> Section 4.5 Is this table conceptual like that in 4.6? (Later in 
> section uses word comparable that wouldn’t be my choice.)

Yes, the table is conceptual.  Comparisons can be done on conceptual 
table entries as well.  Nevertheless, the wording has been changed to 
avoid use of that word.

> 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.)

It can be overwritten as long as LoopFree() returns TRUE. How about the 
following text as a clarification?

    "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 to a broken route."

    Section 4.6 has a broken paragraph. (Could easily be fixed in -11,
    haven’t checked.)

Fixed now, not in 11.

    Section 5, para 2, use of “or” seems wrong.

removed reference to RFC6551 since this is in 12.3 anyway.

> Section 5.1. I don’t like that non-hop-count metrics aren’t described 
> (as hop count really isn’t good enough in reality) and that adding a 
> new metric type means adding code. The latter is a design issue, so 
> there is no right/wrong here.

I agree it's time to develop new metrics, but those should be in 
separate documents.  I'll try to make one before the next IETF.

    Section 6.2 is where I think bidirectionality becomes MUST, so
    earlier SHOULDs may be wrong.

    Section 6.2 states that if some other mechanism is present routes
    can be known to be bidirectional. That’s OK (I think). But then to
    say that RREP_ACKs can be omitted is wrong, given that various
    places describe consequences of missing RREP_ACKs, without
    considering this case. I think anything other than always sending
    RREP_ACKs is not appropriate.

Better: "in that case, *requesting *acknowldegment of a RREP ... is 
unnecessary".
It's not that we wouldn't send the RREP_Ack, it's that we wouldn't 
request it.

> 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.

I don't really see what's wrong with it.  Using some method (e.g., 
maintaining a connected dominating set for message regeneration) to 
reduce multicast flooding overhead is clearly an excellent way to 
improve performance as the size of the network grows.  AODV does not 
have to specify which method should be used.  As long as the messages 
can reach all of the multicast receivers, interoperability will be 
maintained no matter which method is chosen. There are some methods 
identified in RFC 6621 which would work, and yet we should not make a 
normative reference to that document.

If you agree with value of the performance improvement, and that the 
choice of method would not affect interoperability, then do you have any 
suggestion about how to improve the wording?

    Section 6.4 page 23 para 2 (ignoring incomplete). I can see “(albeit
    usually positive)” being challenged.

"albeit usually positive" has been removed.  "The packet buffer is 
configured" should be "The packet buffer MAY be configured".  This does 
not affect interoperability.

> Section 6.4 page 23 para 3 why fixed buffer? And as this is supposed 
> to be IP’s job, why specify?
>

IP never had to do this before, because IP never had to work with 
reactive route establishment.

> Section 6.4 page 23 para 4 using [RFC 3561] in this way as a SHOULD 
> makes it a normative reference, which is a downref, and it’s buried 
> somewhere in that reference without an indication. Should be pulled 
> out and included in this document.

We are rewording to avoid the apparent downref:

    "To reduce congestion in a network, repeated
        attempts at route discovery for a particular target address SHOULD
        utilize the binary exponential backoff as follows.  If the
        requested route is not learned within RREQ_WAIT_TIME of sending the
        first RREQ, RREQ_Gen sends a new RREQ.  The wait time for the RREP
        corresponding to the second RREQ is 2 * RREQ_WAIT_TIME. If the
        requested route is not learned within this time period, another RREQ
        MAY be sent, up to a total of DISCOVERY_ATTEMPTS_MAX. For each
        additional attempt, the waiting time for the RREP is multiplied
    by 2,
        so that the time conforms to a binary exponential backoff.  This
    is the
        same exponential backoff as used in [RFC3561]."

    Section 6.4 penultimate para last line, why SHOULD and not MUST?

Check.  Good catch!

    Section 6.5.2 made me realise a major omission. This is all 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.)

For any such conditions as this, kernel implementation is better.  But 
user space implementation has other advantages so that many people will 
prefer to not worry about it.

    Section 6.6 point 3, the equal case. I think it’s obvious, but
    should say “equal or better”. (If that’s wrong, it’s not obvious.)
    May occur in other places.

change to say "equal or better"

    Section 6.7.1 Active the do A or B at the least should indicate
    preference.

The preference should be determined by memory requirement.  If there's 
no problem with storage, it's better to keep the route table 
information.  Now that passage says:

    "remains Active until its expiration time, after which it MUST
    become Invalid. "

This is true. Then, when it's invalid, it MAY be expunged...the memory 
constraint bit is in a lower paragraph now, not to confuse things.

    Section 6.7.1 about using idle and active routes to forward packets,
    this is also where that is done by IP, so it should be about idle
    and active routes being in IP’s table.

    Section 6.7.1 there’s a mention of inferior matching routes. Not
    sure what’s meant.

changed to "any matching routes with metric values worse than this route"

    Figures are described as message structure. They are message
    content. Structure is 5444. (As worded there’s a sort of suggestion
    of an alternative structure, but this isn’t that, as there’s no
    indication how optional fields would be handled.)

Changed to "contents".

> Section 7.1.3, that situations where RREQs are not regenerated are not 
> declared makes me very uneasy.
>

Section 7.1.3 is about regeneration.  We could add something like  "A 
router may avoid regenerating a RREQ, for instance if it is heavily 
loaded or low on energy and therefore unwilling..."

> 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. If needed 
> here, put in another section.

This is a reasonable comment, and the IANA text is being restructured 
accordingly.  For instance, mention of VALIDITY_TIME TLV will be removed 
from the IANA section.

> 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.

Not sure about what "COMPLETE" means, but the suggestion to use an 
existing sequence number TLV is reasonable.  Notably, there was not such 
a TLV back when the AODVv2 SEQ_NUM TLV was specified.  I think that 
Address Block TLV type 6 with type extension 0 will work, at some 
additional expense per message.

> Section 13, para 4, what’s said is true, but it’s not as simple as 
> this makes it appear. (And there are issues of information leakage in 
> other layers.)

I didn't really understand this.  Could you say more?

> Section 13, specifying TIMESTAMP data, suggest indicate algorithm number.

Do you mean for the comparison?

> I think Section 13 means that RFC 7182 should be a normative reference.

Yes, I think that would be very appropriate.

> Appendix A I think should be about two way interaction with IP, and is 
> missing IP routing table update. It’s also very underspecified. For 
> example the ability to queue packets has requirements to add packet to 
> queue, to flush queue. Is it IP’s responsibility to release queue when 
> a route appears?

That's one way to do it, for sure.  Did you want separate itemized 
bullets for the two queuing operations you mentioned?

> Appendix D needs to have its normativeness indicated. Is the 
> description in the main body (which as I note I haven’t reviewed) 
> complete and normative, and this is example? (That would handle if 
> there’s any mismatch.) Otherwise things get messy.

The title of the appendix indicates that they are examples, but we will 
add a statement that the appendix is non-normative.  We could even say 
"Example (Non-Normative) Algorithms for AODVv2 Operations".

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 21 Aug 2015 10:26:28 +0000

Comments CMD> below. In short, I’m not happy with IP, but will take that up separately, and there are a couple more points I’m happy with in a lesser way. I have postponed detailed protocol issues (again).

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

From: manet [mailto:[email-masked]] On Behalf Of Charles E. Perkins
Sent: 20 August 2015 19:37
To: Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] AODVv2 comments

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
*** WARNING ***
This message originates from outside our organization, either from an external partner or the internet. Consider carefully whether you should click on any links, open any attachments or reply. For additional information about Spearphishing, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Pages/SpearphishingTips.aspx>. If you feel the email is suspicious, please follow this process.<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>

Hello Chris,

Some of the AODVv2 authors are still on vacation, and so have not been able to review all of your recent comments.  Nevertheless, I hope this follow-up will begin to resolve your comments.

On Thu, Jul 23, 2015 at 11:56 AM, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:

“Version 2” doesn’t appear in the draft title. (Not sure why only just noticed that.)

CMD> I noticed it, and this makes sense to me, but up to WG (and all the way to the RFC Editor, who does have views here, but I think would accept that) what it wants here.

Section 1, what’s the difference between loop avoidance and loop freedom?

Loop freedom is the state of having no loops. Loop avoidance is how you ensure that. I guess this bit :

   discarded.
can be reworded to:

To ensure loop freedom, AODVv2 uses sequence numbers to identify stale routing information, and compares route metrics to determine if advertised routes could form loops.

Does that sound ok?

CMD> Down to one term, so that’s better. But actually I’d remove the first four words, and then put another clause or sentence on the end that introduces the term loop freedom (that this reduces loops to occasional and transient, or whatever the case is).

Section 2 is missing IAR. (Haven’t checked this section in detail, just noticed that.)

But the IAR should also be allowed to interface to other external networks that are not "the Internet", so the name should be changed to External Network Access Router (ENAR).
CMD> Seems reasonable.

Changed to a reference throughout - will display as [RFC5444], except in section headings and in algorithm names in the appendix.

CMD> Seems reasonable.

Section 3. AODVv2 doesn’t support some things that OLSRv2 was required to support, in particular using same address on multiple interfaces (with a limitation that made that practical) as some wanted unnumbered interfaces (Stan IIRC).

As best I can tell, this seems to be a consequence of OLSR's requirement to know the complete topology. I don't see that this is a requirement for AODVv2.

CMD> Not really. The requirement came from people who wanted nodes that were only allocated one address, even for more than one interface. (This might be taken from a subnet allocation otherwise available on the node, but that was another requirement, not the only case. Just one address for the interface(s) and the host was also required.) So we did that, because (a) it was required by WG participants (Stan in particular IIRC) and (b) we worked out how to do it (with a restriction – which may or may not be specific to OLSR – about simultaneous visibility not being allowed).

The key questions are (a) do we still have the requirement? and (b) if not, why not?

Section 3 para 4 says route requests that can’t be confirmed bidirectional should be ignored. Why should and not must?

Changed to MUST.

CMD> OK.

Throughout: Much inconsistency in use of SHOULD vs should and MUST vs must. (Former in normative sections, latter or avoid otherwise.) Haven’t noticed for MAY/may but worth checking.

We have fixed some of these but specific suggestions would be very helpful.
CMD> My only suggestion is search for all non-capitalised and decide why it isn’t – because not normative – and whether better reworded.

CMD> OK.

Section 4.3 second paragraph should (SHOULD) or MUST? I would have thought latter, and I think some later text assumes latter. Also later in section.
Proposed new text:
"Neighboring routers which cannot confirm adjacency when requested MUST be marked as blacklisted. Route Request messages received from a blacklisted router SHOULD be ignored to avoid unnecessary processing and generation of control traffic when it is known that the return path does not exist.  "

CMD> I’m not sure why SHOULD is good enough. But that needs a more careful consideration of what the overall state of unidirectional link avoidance, and its interoperability, is after all changes.

Done.
CMD> OK.

Section 4.4 sequence numbers wrap, so at the least a comment that indicates greater/less is according to that should be included. (An algorithm that properly handles the 0 omission would help implementers.)

   stored information.

We have used that, except to replace "32-bit" by "16-bit". I am mystified why this was omitted from AODVv2, but no one ever noticed it before.

CMD> I would need to check whether this is correct, taking into account the omitted zero, and how it handles two numbers 2^31 apart. Not done that so far. (Anyone else, please pre-empt me!)

Section 4.5 Is this table conceptual like that in 4.6? (Later in section uses word comparable that wouldn’t be my choice.)

Yes, the table is conceptual.  Comparisons can be done on conceptual table entries as well.  Nevertheless, the wording has been changed to avoid use of that word.

CMD> Will need to see draft.

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.)

It can be overwritten as long as LoopFree() returns TRUE.  How about the following text as a clarification?
"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 to a broken route."

CMD> I’m going to postpone any comment until I look more carefully at the whole actual protocol part (time permitting).

Section 4.6 has a broken paragraph. (Could easily be fixed in -11, haven’t checked.)

Fixed now, not in 11.

CMD> OK.

C<D> Not checked this, but sounds OK.

Section 5.1. I don’t like that non-hop-count metrics aren’t described (as hop count really isn’t good enough in reality) and that adding a new metric type means adding code. The latter is a design issue, so there is no right/wrong here.

I agree it's time to develop new metrics, but those should be in separate documents.  I'll try to make one before the next IETF.

CMD> I think this is a topic the WG should agree on.

Section 6.2 is where I think bidirectionality becomes MUST, so earlier SHOULDs may be wrong.

Section 6.2 states that if some other mechanism is present routes can be known to be bidirectional. That’s OK (I think). But then to say that RREP_ACKs can be omitted is wrong, given that various places describe consequences of missing RREP_ACKs, without considering this case. I think anything other than always sending RREP_ACKs is not appropriate.

Better: "in that case, requesting acknowldegment of a RREP ... is unnecessary".
It's not that we wouldn't send the RREP_Ack, it's that we wouldn't request it.

CMD> As above, need to look at this area as a whole.

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.

I don't really see what's wrong with it.  Using some method (e.g., maintaining a connected dominating set for message regeneration) to reduce multicast flooding overhead is clearly an excellent way to improve performance as the size of the network grows.  AODV does not have to specify which method should be used.  As long as the messages can reach all of the multicast receivers, interoperability will be maintained no matter which method is chosen. There are some methods identified in RFC 6621 which would work, and yet we should not make a normative reference to that document.

If you agree with value of the performance improvement, and that the choice of method would not affect interoperability, then do you have any suggestion about how to improve the wording?

CMD> No, I’m not happy here. If some routers use one approach (e.g. MPRs) and some another (for example CDS) we will have a horrible mess and messages won’t arrive everywhere they should go. You need a common mechanism that all can use, that is standardised, and works. Then what about alternatives? Best is if there’s something that is guaranteed to work, because of its properties, or because you’ve designed and standardised a mechanism. Note that having a mixture of blind and MPR flooders won’t work (one might think it would, as don’t the blind flooders just do more? – but, no, they don’t select MPRs, and so their messages won’t be MPR flooded). Possibly acceptable (WG participants may agree or not) is specifying administrative means to ensure all are using the same. But we still need the baseline.

Section 6.4 page 23 para 2 (ignoring incomplete). I can see “(albeit usually positive)” being challenged.

"albeit usually positive" has been removed.  "The packet buffer is configured" should be "The packet buffer MAY be configured".  This does not affect interoperability.

CMD> Depends on point below.

Section 6.4 page 23 para 3 why fixed buffer? And as this is supposed to be IP’s job, why specify?

IP never had to do this before, because IP never had to work with reactive route establishment.

CMD> That sounds a great big warning to me. But rather than my comments being possibly lost down in the details here, I think I’ll post separately about that (when I get the time). But no, not satisfied here.

Section 6.4 page 23 para 4 using [RFC 3561] in this way as a SHOULD makes it a normative reference, which is a downref, and it’s buried somewhere in that reference without an indication. Should be pulled out and included in this document.

   additional attempt, the waiting time for the RREP is multiplied by 2,
   so that the time conforms to a binary exponential backoff.  This is the

CMD> That the text is now included without reference (downref, but any reference wasn’t good) is good. The details I’ll postpone checking.

Check.  Good catch!

CMD> OK.

Section 6.5.2 made me realise a major omission. This is all 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.)
For any such conditions as this, kernel implementation is better.  But user space implementation has other advantages so that many people will prefer to not worry about it.
CMD> That’s part of the IP issue.

Section 6.6 point 3, the equal case. I think it’s obvious, but should say “equal or better”. (If that’s wrong, it’s not obvious.) May occur in other places.

CMD> OK.

Section 6.7.1 Active the do A or B at the least should indicate preference.

The preference should be determined by memory requirement.  If there's no problem with storage, it's better to keep the route table information.  Now that passage says:
"remains Active until its expiration time, after which it MUST become Invalid. "
This is true. Then, when it's invalid, it MAY be expunged...the memory constraint bit is in a lower paragraph now, not to confuse things.
CMD> Postpone until look at draft and details.

Section 6.7.1 about using idle and active routes to forward packets, this is also where that is done by IP, so it should be about idle and active routes being in IP’s table.

Section 6.7.1 there’s a mention of inferior matching routes. Not sure what’s meant.
changed to "any matching routes with metric values worse than this route"

CMD> OK.

Figures are described as message structure. They are message content. Structure is 5444. (As worded there’s a sort of suggestion of an alternative structure, but this isn’t that, as there’s no indication how optional fields would be handled.)
Changed to "contents".

CMD> OK.
Section 7.1.3, that situations where RREQs are not regenerated are not declared makes me very uneasy.

Section 7.1.3 is about regeneration.  We could add something like  "A router may avoid regenerating a RREQ, for instance if it is heavily loaded or low on energy and therefore unwilling..."

C<D> Will wait for proposal.

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. If needed here, put in another section.

This is a reasonable comment, and the IANA text is being restructured accordingly.  For instance, mention of VALIDITY_TIME TLV will be removed from the IANA section.

CMD> OK.

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.

Not sure about what "COMPLETE" means, but the suggestion to use an existing sequence number TLV is reasonable.  Notably, there was not such a TLV back when the AODVv2 SEQ_NUM TLV was specified.  I think that Address Block TLV type 6 with type extension 0 will work, at some additional expense per message.

CMD> There is an existing 16 bit sequence number TLV, or rather two of them. One is called CONT_SEQ_NUM (COMPLETE) and the other is called CONT_SEQ_NUM (INCOMPLETE). Putting the name aside for a second, either does exactly what you want, so why not reuse? Might as well reuse (COMPLETE) as it has the preferable extension zero. The name? When first used I’d say something like “all uses of CONT_SEQ_NUM mean CONT_SEQ_NUM (COMPLETE) as specified in [reference]” and thereafter use CONT_SEQ_NUM.

Section 13, para 4, what’s said is true, but it’s not as simple as this makes it appear. (And there are issues of information leakage in other layers.)

CMD> Right now I’m going to skip this as I’d have to dig up more. I hope to get back to this at some point.

CMD> I mean that if you look in RFC 7182 the TIMESTAMP TLV has an algorithm number, offering various options like POSIX time, sequence number etc. You should pick one as the must implement, and whatever you are saying about use.

CMD> OK.

Appendix A I think should be about two way interaction with IP, and is missing IP routing table update. It’s also very underspecified. For example the ability to queue packets has requirements to add packet to queue, to flush queue. Is it IP’s responsibility to release queue when a route appears?

That's one way to do it, for sure.  Did you want separate itemized bullets for the two queuing operations you mentioned?
CMD> Again, I’ll get back to IP.
Appendix D needs to have its normativeness indicated. Is the description in the main body (which as I note I haven’t reviewed) complete and normative, and this is example? (That would handle if there’s any mismatch.) Otherwise things get messy.

The title of the appendix indicates that they are examples, but we will add a statement that the appendix is non-normative.  We could even say "Example (Non-Normative) Algorithms for AODVv2 Operations".

CMD> OK. Not sure if happy with appendix, but getting status right is necessary. (I know at least one WG participant wants it gone. I currently haven’t formed a view, except a little unease.)

Regards,
Charlie P.

--

Regards,

Charlie P.
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 25 Aug 2015 10:18:27 -0700

Hello Chris,

Some follow-up below...

On 8/21/2015 3:26 AM, Dearlove, Christopher (UK) wrote:
> CMD> Down to one term, so that’s better. But actually I’d remove the 
> first four words, and then put another clause or sentence on the end 
> that introduces the term loop freedom (that this reduces loops to 
> occasional and transient, or whatever the case is).
>

Sounds reasonable to me...

> As best I can tell, this seems to be a consequence of OLSR's 
> requirement to know the complete topology. I don't see that this is a 
> requirement for AODVv2.
>
> CMD> Not really. The requirement came from people who wanted nodes 
> that were only allocated one address, even for more than one 
> interface. (This might be taken from a subnet allocation otherwise 
> available on the node, but that was another requirement, not the only 
> case. Just one address for the interface(s) and the host was also 
> required.) So we did that, because (a) it was required by WG 
> participants (Stan in particular IIRC) and (b) we worked out how to do 
> it (with a restriction – which may or may not be specific to OLSR – 
> about simultaneous visibility not being allowed).
>

What AODVv2 needs is to associate an IP address with an interface. If 
the same IP address is associated with more than one interface, I don't 
think that is a problem.  If some interfaces are unnumbered, and AODVv2 
can send and receive IP packets on that interface, then the source IP 
address for Route Discovery packets on that interface should be O.K. for 
AODVv2 to use as the Originating Address or Target Address.  I don't 
think this is a problem.

I don't think the requirements introduce difficulties for AODVv2, and 
that's what I meant to say but it came out wrong.

> MUST be marked as blacklisted. Route Request messages received from a 
> blacklisted router SHOULD be ignored to avoid unnecessary processing 
> and generation of control traffic when it is known that the return 
> path does not exist.  "
>
> CMD> I’m not sure why SHOULD is good enough. But that needs a more 
> careful consideration of what the overall state of unidirectional link 
> avoidance, and its interoperability, is after all changes.
>

SHOULD means do it unless you have a valid reason not to do it.  I can 
imagine that there might be some reason for an implementation to somehow 
take note of packets from a blacklisted router (i.e., not ignore them).

>     indicates greater/less is according to that should be included.
>     (An algorithm that properly handles the 0 omission would help
>     implementers.)
>
>
> CMD> I would need to check whether this is correct, taking into 
> account the omitted zero, and how it handles two numbers 2^31 apart. 
> Not done that so far. (Anyone else, please pre-empt me!)
>

Many many implementations of AODV, Mobile IP, and other protocols 
indicate that this algorithm is indeed O.K.  Mobile IP does something 
similar except for skipping past the initial low values (not just zero).

> CMD> That sounds a great big warning to me. But rather than my 
> comments being possibly lost down in the details here, I think I’ll 
> post separately about that (when I get the time). But no, not 
> satisfied here.
>

Many implementations of AODV and other protocols have validated this 
approach.  We have also had bicasting, etc.

> existing sequence number TLV is reasonable.  Notably, there was not 
> such a TLV back when the AODVv2 SEQ_NUM TLV was specified.  I think 
> that Address Block TLV type 6 with type extension 0 will work, at some 
> CMD> There is an existing 16 bit sequence number TLV, or rather two of 
> them. One is called CONT_SEQ_NUM (COMPLETE) and the other is called 
> CONT_SEQ_NUM (INCOMPLETE). Putting the name aside for a second, either 
> does exactly what you want, so why not reuse? Might as well reuse 
> (COMPLETE) as it has the preferable extension zero. The name? When 
> first used I’d say something like “all uses of CONT_SEQ_NUM mean 
> CONT_SEQ_NUM (COMPLETE) as specified in [reference]” and thereafter 
> use CONT_SEQ_NUM.
>

This looks O.K. to me.

> CMD> I mean that if you look in RFC 7182 the TIMESTAMP TLV has an 
> algorithm number, offering various options like POSIX time, sequence 
> number etc. You should pick one as the must implement, and whatever 
> you are saying about use.
>

We don't need the actual time -- we just want monotonically increasing 
and the comparison specified as above.  But as mentioned I agree we 
should re-use existing standard mechanisms as appropriate.

Regards,
Charlie P.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 26 Aug 2015 08:47:42 +0000

The only comment I have is that a simple monontonically increasing number is (if I remember correctly) one of the options for TIMESTAMP in RFC 7182. I don't have a view on which option should be picked (I don't offhand recall if the default - must implement - use in RFC 7183 for a real time option was from the authors or an AD) just that one (including other options) should be.

From: Charlie Perkins [mailto:[email-masked]]
Sent: 25 August 2015 18:18
To: Dearlove, Christopher (UK); Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] AODVv2 comments

*** WARNING ***

Some follow-up below...

Section 1, what's the difference between loop avoidance and loop freedom?

   discarded.
can be reworded to:

Does that sound ok?

CMD> Down to one term, so that's better. But actually I'd remove the first four words, and then put another clause or sentence on the end that introduces the term loop freedom (that this reduces loops to occasional and transient, or whatever the case is).

Section 3. AODVv2 doesn't support some things that OLSRv2 was required to support, in particular using same address on multiple interfaces (with a limitation that made that practical) as some wanted unnumbered interfaces (Stan IIRC).

CMD> Not really. The requirement came from people who wanted nodes that were only allocated one address, even for more than one interface. (This might be taken from a subnet allocation otherwise available on the node, but that was another requirement, not the only case. Just one address for the interface(s) and the host was also required.) So we did that, because (a) it was required by WG participants (Stan in particular IIRC) and (b) we worked out how to do it (with a restriction - which may or may not be specific to OLSR - about simultaneous visibility not being allowed).

What AODVv2 needs is to associate an IP address with an interface.  If the same IP address is associated with more than one interface, I don't think that is a problem.  If some interfaces are unnumbered, and AODVv2 can send and receive IP packets on that interface, then the source IP address for Route Discovery packets on that interface should be O.K. for AODVv2 to use as the Originating Address or Target Address.  I don't think this is a problem.

I don't think the requirements introduce difficulties for AODVv2, and that's what I meant to say but it came out wrong.

CMD> I'm not sure why SHOULD is good enough. But that needs a more careful consideration of what the overall state of unidirectional link avoidance, and its interoperability, is after all changes.

SHOULD means do it unless you have a valid reason not to do it.  I can imagine that there might be some reason for an implementation to somehow take note of packets from a blacklisted router (i.e., not ignore them).

   stored information.

Many many implementations of AODV, Mobile IP, and other protocols indicate that this algorithm is indeed O.K.  Mobile IP does something similar except for skipping past the initial low values (not just zero).

Section 6.4 page 23 para 3 why fixed buffer? And as this is supposed to be IP's job, why specify?

CMD> That sounds a great big warning to me. But rather than my comments being possibly lost down in the details here, I think I'll post separately about that (when I get the time). But no, not satisfied here.

Many implementations of AODV and other protocols have validated this approach.  We have also had bicasting, etc.

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.

CMD> There is an existing 16 bit sequence number TLV, or rather two of them. One is called CONT_SEQ_NUM (COMPLETE) and the other is called CONT_SEQ_NUM (INCOMPLETE). Putting the name aside for a second, either does exactly what you want, so why not reuse? Might as well reuse (COMPLETE) as it has the preferable extension zero. The name? When first used I'd say something like "all uses of CONT_SEQ_NUM mean CONT_SEQ_NUM (COMPLETE) as specified in [reference]" and thereafter use CONT_SEQ_NUM.

This looks O.K. to me.

We don't need the actual time -- we just want monotonically increasing and the comparison specified as above.  But as mentioned I agree we should re-use existing standard mechanisms as appropriate.

Regards,
Charlie P.