On Fri, Apr 15, 2016 at 4:15 PM, Victoria Mercieca <vmercieca0@xxxxxxxxx>
wrote:
I don't believe this was exactly Justin's issue to begin with but now
we've spent so long arguing about it, it needs an answer :-)
Options I see are:
1) There have been suggestions that metric fields should use 32 bits,
should we adopt this in AODVv2 and define the simple Metric TLV kinda like
our current one, with a Type, Type Extension for indicating MetricType,
Length = 32 bits, and Value? Overkill for a hopcount metric, suitability
for others varies.
2) There have been suggestions we re-use the LINK_METRIC TLV used by
OLSRv2 (but defined as a MANET parameter at
http://www.iana.org/assignments/manet-parameters/manet-parameters.xhtml#address-block-tlv-types).
It has a value length of 16 bits total. We mentioned the idea of using this
back at draft 9 (found an email from Fri, May 8, 2015 mentioning it), and
other people on MANET have suggested it, and I think Lotte likes the idea
too? If we do use that, I believe we could still use extension type to
indicate MetricType like we are currently with our own TLV. I don't believe
its a big change to the draft. Wouldn't it just be in the 5444
representation section? There's 4 bits in the value field to indicate kind
(link/neighbor) and direction (incoming/outgoing) so we would need define
what to set these as for AODVv2. However (really rambling now), on the
other hand, it is called LINK_METRIC, whereas we would be using it for an
accumulated route metric, so maybe that doesn't sit neatly. Although it can
be used by OLSRv2 for link or neighbor so I guess it's not a problem that
it is named LINK_METRIC TLV.
We have conflicting suggestions. I vote lets take this decision to MANET.
Kind regards,
Vicky.
On Thu, Apr 14, 2016 at 6:50 PM, Ratliff, Stanley <sratliff@xxxxxxxxxxx>
wrote:
Charlie,
And how long is this supposed to take? Will it impact getting to WGLC on
AODVv2? Will AODVv2 now *require* this brand-new, protocol-independent
registry?
This looks suspiciously like a rat-hole to me. Remember what I said in
Buenos Aires? "It's April. I don't want to be doing this in May. And if it
gets to June, it won't be our decision."
We're losing focus here. I know you hate the notion of a 32-bit metric
that represents hop count. However, I now call for consensus amongst the
editing team - I believe the implementation of a 32-bit metric for AODVv2
is the best way to go. I want to hear opinions from my co-editors.
Regards,
Stan
-----Original Message-----some
From: aodvv2-discuss-bounce@xxxxxxxxxxxxx [mailto:aodvv2-discuss-
bounce@xxxxxxxxxxxxx] On Behalf Of Charlie Perkins
Sent: Thursday, April 14, 2016 1:45 PM
To: aodvv2-discuss@xxxxxxxxxxxxx
Subject: [aodvv2-discuss] Metric type registry
Hello folks,
The situation is not yet clear. I am asking various people and getting
unexpected answers. I will craft a registry for protocol-independentMetric
Types. I did not find one for OLSR or OLSRv2, but if there is oneplease let me
know. One way or another we will have an answer within a day or two,metrics.
perhaps awaiting a better answer.
I'll be honest. I am more than surprised about this. Routing uses
Where are they? It's amazing.
More later.
Regards,
Charlie P.
_____________________________________________________
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.
_____________________________________________________
