[aodvv2-discuss] Re: New Draft

  • From: Victoria Mercieca <vmercieca0@xxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Mon, 4 Apr 2016 22:23:17 +0100

Comment in line...

On 4 Apr 2016 18:19, "Ratliff, Stanley" <sratliff@xxxxxxxxxxx> wrote:




Sent from my iPhone

On Apr 4, 2016, at 6:17 PM, Charlie Perkins <charles.perkins@xxxxxxxxxxxxx
<mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:

Hello Lotte,

I'm definitely O.K. with publishing ASAP.  Some of the text in my
responses below would be quite simple to include (e.g., about whether RREQ
has Message TLVs...).

A possibly good resolution is better than nothing, unless it is
contentious amongst ourselves, because I am worried that it will look like
we aren't able to make the resolution... and Stan points out that there is
a lot of impatience.

So I would ask for people to comment on my proposed resolutions.  It's
not very much text.

Regards,
Charlie P.



On 4/4/2016 1:29 PM, Lotte Steenbrink wrote:
Hi Charlie,

Am 04.04.2016 um 22:23 schrieb Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx<mailto:charles.perkins@xxxxxxxxxxxxx>>:

Hello Lotte,

Thanks for getting this ready.  For the TODOs, partial resolutions are
O.K., right?  A bit of follow-up...


I think it’s better to fully resolve them in one go :) Also, I don’t
think we have to resolve all of them in order to publish. Let’s get what we
have out the door asap and then tackle the rest. I’ll thoroughly go through
your E-Mail tomorrow, I’ve got to log off now :/

   Valid route
      A route that can be used for forwarding. (the deleted part should
be defined in Route Error Generation section JWD TODO: why there? If you
hink it's a bit too verbose at that place, Local Route Set  {#rte} has an
in-depth definition what a valid route is and isn't )

I'm O.K. with the cross-reference.  What else is needed?

   Unreachable Address
      An address reported in a Route Error message. (the deleted part
should be defined in Route Error Generation section JWD TODO)

Actually, I don't think anything more is really needed.  This can be left
as is.


(consider adding a maximum single hop value JWD TODO)

This would be a bad idea

Why?

Stan



If you do that (a max link cost) and you also have a max route cost too,
you're effectively limiting a route to a certain number of hops. As well as
a limit on the total route metric. Is that a good idea?

Vicky.


   RREQ_Gen awaits reception of a Route Reply message (RREP) containing
   a route toward TargAddr. (is there some table that lists routes that
are being waited on? JWD TODO)

I don't see the need for such a table.  If the RREP arrives, the route is
good.  Otherwise, the discovery times out and presumably a retry happens up
to a certain limit, after which ICMP Destination Unreachable happens.

(There is no defined behavior here. Approaching the limit? Section 6.5
outlines which messages are more important but now how to decide to allow
them to be transmitted or not. JWD TODO)

As I understand it, we decided on queueing things, limiting transmission
to {1/CONTROL_TRAFFIC_LIMIT}, and discarding messages when the queue was
full.  Is there more to be done?

(this again doesn’t describe a defined behaivor.  approaching athe
limit? and 6.5 doesn’t disalow anything JWD TODO)

Similarly as the last comment, right?

There might be a problem with very short validity times on very low
metric routes in that they will be selected regardless of the time. Not a
problem but something that could cause issues. Perhaps some minimum time
should be mandated. JWD TODO)

I do not see what issues could be caused.  Under some metrics, we
absolutely DO want to pick the smallest metric even if just for long enough
to send a few bytes.  This is application dependent, not in the bailiwick
of AODVv2.

Unless you would like to start defining a socket interface for dynamic
AODVv2 parameterization.

(same as before JWD TODO)

so shouldn't be counted as increasing the total...

(THere needs to be some sort of table which is updated  with timer
associated with this AckReq JWD TODO)

What is the current status of this?  Has anything been written?  Is it
something I should do?

(this ins’t mandatory, right? Just AODVv2 doesn’t define any message
TLVs for use with RREQ JWD TODO?)

"AODVv2 does not define any Message TLVs for an RREQ message"... is this
O.K.?

   An RREP contains no Message TLVs.
(This isn’t mandatory is it? just none are defined by AODVv2. JWD TODO?)

Similarly, "AODVv2 does not define any Message TLVs for an RREP
message"... is this O.K.?

   An RREP_Ack contains no Message TLVs.
(Mandatory or just not defined? JWD TODO?)

Similarly, "AODVv2 does not define any Message TLVs for an RREP_Ack
message"... is this O.K.?

   An RREP_Ack contains no Address Block.
(Mandatory or just not defined? Guessing mandatory on this one. JWD TODO)
8.3.4.  Address Block TLV Block

   An RREP_Ack contains no Address Block TLV Block.
(Mandatory or just not defined? Guessing mandatory on this one. JWD TODO)

Aren't these the same?  Isn't the same resolution?  Someone could write
such a TLV block in the future.


Regards,
Charlie P.


On 4/4/2016 12:54 PM, Lotte Steenbrink wrote:
Hi all,
since we’re allowed to submit Drafts again now (I think) and we decided
to publish asap, I thought I’d give you a quick status update and wait for
your Go/"Wait a minute, let’s fix this first" signals.

DONE:
————
* All JWD!s are resolved now
* out of 90 JWD and JWD! comments, 64 are done (I’ve attached my copy of
Justin’s review if you want to look for the remaining 26 TODOs, it’s the
file called "draft-ietf-manet-aodvv2-13 (2).txt")
* added revised security considerations


TO DO:
————
* Most notable of the 26 JWDs that are yet to be resolved:
+ (is there some table that lists routes that are being waited on? JWD)
We decided to add a separate
           RREP table that lists them and I’ve volunteered to write text
for that, but every time I set out to do that,
           I got more confused… I’m starting to worry about the amount of
tables AODVv2 needs by now, and
           I’ve been picking Vickys brain on how to achieve storing that
info without having to add another table,
            but it’s an ongoing process.
+ the approaching the limit thing we’re currently discussing in
„[aodvv2-discuss] Re: Justin's review"
* some TODOs in security considerations (see github)
* still waiting for Chris’ feedback regarding the revised 5444
multiplexer wording, so that hasn’t changed yet
* Make it more clear that AODVv2 currently doesn’t support RREQs for
prefixes to make Thomas happy (I’m planning to do that tomorrow afternoon)

What do you think?

Regards,
Lotte












_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________


Other related posts:

  1. Home
  2. aodvv2-discuss
  3. Archive
  4. 04-2016