Hello Stan,
It says the protocol is not to be used for MANETs. That doesn't say
that every component part of the protocol is inappropriate for MANETs.
Realistically, a metric is a metric regardless of how it is used.
I know you are not the one I need to convince.
Regards,
Charlie P.
On 4/13/2016 8:23 AM, Stan Ratliff wrote:
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 <mailto: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 <mailto:ratliffstan@xxxxxxxxx>>:
Sent from my iPhone
On Apr 4, 2016, at 6:52 PM, Victoria Mercieca
<vmercieca0@xxxxxxxxx <mailto:vmercieca0@xxxxxxxxx>> wrote:
In line...
On 4 Apr 2016 18:37, "Ratliff, Stanley" <sratliff@xxxxxxxxxxx
<mailto:sratliff@xxxxxxxxxxx>> wrote:
>
>
>
> Sent from my iPhone
>
> On Apr 4, 2016, at 6:32 PM, Victoria Mercieca
<vmercieca0@xxxxxxxxx
<mailto:vmercieca0@xxxxxxxxx><mailto:vmercieca0@xxxxxxxxx
<mailto:vmercieca0@xxxxxxxxx>>> wrote:
>
>
> Hi all,
>
> On 4 Apr 2016 18:08, "Stan Ratliff" <ratliffstan@xxxxxxxxx
<mailto:ratliffstan@xxxxxxxxx><mailto:ratliffstan@xxxxxxxxx
<mailto:ratliffstan@xxxxxxxxx>>> wrote:
> >
> >
> >
> > Sent from my iPhone
> >
> > > On Apr 4, 2016, at 5:34 PM, John Dowdell
<john.dowdell486@xxxxxxxxx
<mailto:john.dowdell486@xxxxxxxxx><mailto:john.dowdell486@xxxxxxxxx
<mailto:john.dowdell486@xxxxxxxxx>>> wrote:
> > >
> > > Yes, post to show progress :)
> > >
> > > OK looking at some TODOs now
> > >
> > > 1. The ones in the definitions; is it worth linking from
the definition to where the explanatory text is?
> > > 2. Applicability statement. Sigh. Wireless networks. We
discussed keeping that rabbit hole shut, and I’d rather not
open it again. Yes it is 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.
> > > 3. Page 9: yes there is an issue with hop-by-hop trust.
Correct. Does anyone know how to fix that yet? No. We kicked it
around again in DTN 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.
> > > 4. Page 17, maximum single hop metric value. The current
IETF favourite appears to be two bytes worth, think this is the
same in DLEP (Stan can you confirm please?). Can we go with that?
> >
> > DLEP tends to go with 8-octet data items. We followed the
notion that if you make everything as big as possible ( a long
long), then nobody will ask you to make it larger... ;-)
> >
> > But in this application, I'd think 2 bytes is sufficient.
> >
>
> That comment was where we said a route has a maximum cost
metric allowed, and Justin said to consider adding a maximum
cost per link.
>
> Since we only defined hopcount...
> Section 11.6. MetricType Allocation says that the hopcount
metric value uses 1 octet, hence why the maximum route metric
allowed is 255. For hopcount obviously the maximum single hop
cost is 1.
>
> The maximum route cost for other metric types depends on the
number of octets used to represent that metric. We don't have
any defined yet. Are 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?
>
> For route cost, I'd go with a 32-but value. But I'm also
convinced anything we pick will be deemed to be wrong... ;-) So
let's pick 32 bits 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.
> Stan
>
>
> Kind regards,
> Vicky.
>
> > Stan
> >
> >
> > > 5. RREP_Ack timeout. I’d expect to get an Ack back pretty
quickly since it’s only coming from one hop away. Is there a
short time value we can re-use from somewhere else in this spec?
> > > 6. Check RREP_Ack in MRMT. Why isn’t this the right
place, thought this was now the working space for routes before
they go live into the kernel?
> > > 7. (What does this mean? How would one determine a link
to a neighbor to be broken….suggest removing it JWD TODO) need
some clarification. We do discuss how to detect links are
broken, and what is it that he is asking to be removed?
> > > 8. Page 24 sect 6.6 the table for waiting routes is the
MRMT, is it not?
> > >
> > > That’s all for now. Lotte, you are owed a very
significant number of beers.
> > >
> > > Cheers
> > > John
> > >
> > >
> > >> On 4 Apr 2016, at 20:59, Ratliff, Stanley
<sratliff@xxxxxxxxxxx
<mailto:sratliff@xxxxxxxxxxx><mailto:sratliff@xxxxxxxxxxx
<mailto:sratliff@xxxxxxxxxxx>>> wrote:
> > >>
> > >> Go!
> > >>
> > >> Regards,
> > >> Stan
> > >>
> > >> Sent from my iPhone
> > >>
> > >> On Apr 4, 2016, at 4:56 PM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx
<mailto:lotte.steenbrink@xxxxxxxxxxxx><mailto:lotte.steenbrink@xxxxxxxxxxxx
<mailto:lotte.steenbrink@xxxxxxxxxxxx>><mailto:lotte.steenbrink@xxxxxxxxxxxx
<mailto:lotte.steenbrink@xxxxxxxxxxxx><mailto:lotte.steenbrink@xxxxxxxxxxxx
<mailto:lotte.steenbrink@xxxxxxxxxxxx>>>> 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
> > >>
> > >>
> > >> <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 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.
> > >> _____________________________________________________
> > >
> > >
> >
>
> _____________________________________________________
> 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.
> _____________________________________________________
>
>
