This is a carry-on from the "metrics discussion". If we get backing from
Pascal, Alvaro, et. al. on using the RPL metrics, I don't see a need to
make the change Lotte has ready. On the other hand, it is a fall-back
position if those discussions collapse.
The fall-back notion is to standardize the metric size at 32-bits. I heard
a lot of discussion in Buenos Aires along the lines of "Routing protocols
should have a 32-bit metric. Even though the number space is used
differently for a specific protocol, just standardize on 32-bits and be
done with it." From a high-level perspective, it makes sense.
So again, this is linked to the discussion/nagging (for Alvaro) of whether
or not we can specify using metrics from a protocol (RPL) that states in
its abstract "This is not to be used for MANETs".
Regards,
Stan
On Wed, Apr 13, 2016 at 11:03 AM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
Hello folks,
I don't think we should have a 32-bit hop count!!
Why??
Regards,
Charlie P.
On 4/13/2016 7:56 AM, Lotte Steenbrink wrote:
Hi all,
Am 05.04.2016 um 00:22 schrieb Stan Ratliff <ratliffstan@xxxxxxxxx>:
Sent from my iPhone
On Apr 4, 2016, at 6:52 PM, Victoria Mercieca < <vmercieca0@xxxxxxxxx>
vmercieca0@xxxxxxxxx> wrote:
In line...
On 4 Apr 2016 18:37, "Ratliff, Stanley" <sratliff@xxxxxxxxxxx> wrote:
<mailto: ;<vmercieca0@xxxxxxxxx>vmercieca0@xxxxxxxxx>> wrote:
Sent from my iPhone
On Apr 4, 2016, at 6:32 PM, Victoria Mercieca <vmercieca0@xxxxxxxxx
ratliffstan@xxxxxxxxx<mailto: ;<ratliffstan@xxxxxxxxx>ratliffstan@xxxxxxxxx>>
Hi all,
On 4 Apr 2016 18:08, "Stan Ratliff" < <ratliffstan@xxxxxxxxx>
wrote:
<mailto: ;<john.dowdell486@xxxxxxxxx>john.dowdell486@xxxxxxxxx>> wrote:
Sent from my iPhone
On Apr 4, 2016, at 5:34 PM, John Dowdell <john.dowdell486@xxxxxxxxx
definition to where the explanatory text is?
Yes, post to show progress :)
OK looking at some TODOs now
1. The ones in the definitions; is it worth linking from the
keeping that rabbit hole shut, and I’d rather not open it again. Yes it is2. Applicability statement. Sigh. Wireless networks. We discussed
very likely that AODVv2 will be used on wireless networks, but given that a
very high proportion of mesh and point to point wireless networks operate
some proprietary or closed standard protocol (apart from the usual 802.11
and .15 ones), I’d really rather not get into a protracted discussion of
what could and could not be done here.
Does anyone know how to fix that yet? No. We kicked it around again in DTN3. Page 9: yes there is an issue with hop-by-hop trust. Correct.
this morning and still no nearer a workable solution. IMO best left as an
exercise for the reader, or text to that effect. If I was building such a
network today, I would probably pre-load key material into each node with a
lifetime of the mission plus a bit, maybe with a spare set of keys in case
of compromise. In the future when technology has moved on to be able to
properly negotiate trust without reference to a central PKI server, I would
do something fancier.
favourite appears to be two bytes worth, think this is the same in DLEP4. Page 17, maximum single hop metric value. The current IETF
(Stan can you confirm please?). Can we go with that?
if you make everything as big as possible ( a long long), then nobody will
DLEP tends to go with 8-octet data items. We followed the notion that
ask you to make it larger... ;-)
allowed, and Justin said to consider adding a maximum cost per link.
But in this application, I'd think 2 bytes is sufficient.
That comment was where we said a route has a maximum cost metric
uses 1 octet, hence why the maximum route metric allowed is 255. For
Since we only defined hopcount...
Section 11.6. MetricType Allocation says that the hopcount metric value
hopcount obviously the maximum single hop cost is 1.
octets used to represent that metric. We don't have any defined yet. Are
The maximum route cost for other metric types depends on the number of
you saying that when these metrics are defined, their values should be
limited to 2 bytes? Also (what i think Justin meant) is it also useful to
define a maximum link metric?
anything we pick will be deemed to be wrong... ;-) So let's pick 32 bits
For route cost, I'd go with a 32-but value. But I'm also convinced
and "get corrected". At least we'll get it over with.
Max link metric? Don't know. I'll defer to you.
So in messages when we report the accumulated metric, the field in the TLV
should have length of 32 bits? There's no point in having the table in 11.6
define the number of bytes used to represent the value of each metric type.
Yes. Again, let's just pick that - we'll "get corrected", and we can move
on.
So the gist of this discussion is that
11.6. MetricType Allocation
should be changed from
+---------------------+----------+--------------------+
| Name of MetricType | Type | Metric Value Size |
+---------------------+----------+--------------------+
| Unassigned | 0 | Undefined |
| Hop Count | 3 [TBD] | 1 octet |
| Unallocated | 9 - 254 | TBD |
| Reserved | 255 | Undefined |
+---------------------+----------+--------------------+
to
+---------------------+----------+--------------------+
| Name of MetricType | Type | Metric Value Size |
+---------------------+----------+--------------------+
| Unassigned | 0 | Undefined |
| Hop Count | 3 [TBD] | 4 octets |
| Unallocated | 9 - 254 | 4 octets |
| Reserved | 255 | Undefined |
+---------------------+----------+--------------------+
?
I think I’m a bit lost, sorry :(
Best regards,
Lotte
Regards,
Stan
Kind regards,
Vicky.
Stansince it’s only coming from one hop away. Is there a short time value we
Kind regards,
Vicky.
Stan
5. RREP_Ack timeout. I’d expect to get an Ack back pretty quickly
can re-use from somewhere else in this spec?
this was now the working space for routes before they go live into the6. Check RREP_Ack in MRMT. Why isn’t this the right place, thought
kernel?
neighbor to be broken….suggest removing it JWD TODO) need some7. (What does this mean? How would one determine a link to a
clarification. We do discuss how to detect links are broken, and what is
it that he is asking to be removed?
not?8. Page 24 sect 6.6 the table for waiting routes is the MRMT, is it
beers.
That’s all for now. Lotte, you are owed a very significant number of
<mailto: ;<sratliff@xxxxxxxxxxx>sratliff@xxxxxxxxxxx>> wrote:
Cheers
John
On 4 Apr 2016, at 20:59, Ratliff, Stanley <sratliff@xxxxxxxxxxx
lotte.steenbrink@xxxxxxxxxxxx<mailto: ;<lotte.steenbrink@xxxxxxxxxxxx>
Go!
Regards,
Stan
Sent from my iPhone
On Apr 4, 2016, at 4:56 PM, Lotte Steenbrink <
lotte.steenbrink@xxxxxxxxxxxx><mailto: ;<lotte.steenbrink@xxxxxxxxxxxx>
lotte.steenbrink@xxxxxxxxxxxx<mailto: ;<lotte.steenbrink@xxxxxxxxxxxx>
lotte.steenbrink@xxxxxxxxxxxx>>> wrote:
decided to publish asap, I thought I'd give you a quick status update and
Hi all,
since we're allowed to submit Drafts again now (I think) and we
wait for your Go/"Wait a minute, let's fix this first" signals.
copy of Justin's review if you want to look for the remaining 26 TODOs,
DONE:
----
* All JWD!s are resolved now
* out of 90 JWD and JWD! comments, 64 are done (I've attached my
it's the file called "draft-ietf-manet-aodvv2-13 (2).txt")
JWD) We decided to add a separate* 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?
text for that, but every time I set out to do that,RREP table that lists them and I've volunteered to write
amount of tables AODVv2 needs by now, andI got more confused... I'm starting to worry about the
that info without having to add another table,I've been picking Vickys brain on how to achieve storing
"[aodvv2-discuss] Re: Justin's review"but it's an ongoing process.
+ the approaching the limit thing we're currently discussing in
multiplexer wording, so that hasn't changed yet* some TODOs in security considerations (see github)
* still waiting for Chris' feedback regarding the revised 5444
for prefixes to make Thomas happy (I'm planning to do that tomorrow* Make it more clear that AODVv2 currently doesn't support RREQs
afternoon)
individual
What do you think?
Regards,
Lotte
<draft-ietf-manet-aodvv2-13 (2).txt>
<draft-ietf-manet-aodvv2-14d-from-c.diff.html>
<draft-ietf-manet-aodvv2-14d.txt>
_____________________________________________________
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
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
in error, please delete it and immediately notify the sender.
_____________________________________________________
_____________________________________________________
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.
_____________________________________________________