[aodvv2-discuss] Re: metric comments
- From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
- To: aodvv2-discuss@xxxxxxxxxxxxx
- Date: Wed, 04 Mar 2015 14:08:52 -0800
Hello Lotte,
The metrics are not in any predetermined order, but as with any
Address Block TLV, they have to be associated with the proper
Address in the Address Block. I'll try to add some text to make this
clear in section 10.
We definitely are not specifying new 1-value TLVs for the
OrigAddrMetric and TargAddrMetric. Those terms are used
as AODVv2 data elements, and would be put into the Metric
Address Block TLV in the order corresponding to the same order
that OrigAddr and TargAddr are shown in the AddressList.
You should not have to make any updates to your code for this.
In fact, the whole set of recent revisions to the document have not
required code revisions (except for RREP_Ack being mandatory).
Maybe we should make more use of the list notation, for instance
AddressList := {OrigAddr, TargAddr} /* in any order */ and
MetricList := {OrigAddrMetric, TargAddrMetric }
/* in the
corresponding order */
Then "<null>" means the absence of a corresponding
data element in an Address Block TLV list...
I'll be pretty damned glad when we hit on an unambiguous and
generally acceptable incantation for this extraordinarily simple
requirement...!
Regards,
Charlie P.
On 3/3/2015 1:52 AM, Lotte Steenbrink wrote:
Hi all,
I know I'm super late to the party, and you can ignore my e-mail at
will, but I still wanted to put some comments that I stumbled across
while trying to finally make up my mind on the algorithms appendix on
the list.
- The MetricList mapping in section 10 says:
MetricList| Metric Address Block TLV
- OrigAddrMetric|
- TargAddrMetric|
This reads to me as “a multi-value TLV that is somehow associated with
the Address block”. If this is really a multi-value address TLV, we'd
have the discussion about dependency on address order *again* (please
not), and if it's not and the TLVs are 1-value TLVs which are
associated with one address each, imo this should be stated clearly,
for example like so:
| MetricList | Metric Address Block TLV |
| - OrigAddrMetric | Associated with the OrigAddr |
| - TargAddrMetric | Associated with the TargAddr |
Then I tried to look up the TLV type number for OrigAddrMetric and
found that there wasn't one, just a number for Metric, which is 10.
And now I have no idea how to update my code.
- I still don't get why MetricType is an optional Message TLV instead
of an extension type. I'm only reiterating because I've said this many
times before, but I'd like to stress it again since I can't recall
that we've reached some kind of conclusion in the past:
* Putting it in an entirely different location than the actual Metric
value is counterintuitive to me (and I fear that it's going to cause
headaches bloaty code from an implementation perspective)
* making it an optional Message TLV saves bytes if we're operating
under the conclusion that the default metric (Hop Count) is going to
be used in a very big majority of deployments, but the draft itself
says: “It is well known that reliance on HopCount can cause selection
of the worst possible route in some situations. ”, so I'm not sure if
that assumption holds and we're just adding implementational bloat
(“Is there a MetricType TLV? No? Ok, then it's hop count. Oh, there
is? Let's see...” instead of “which metrictype is this? foo? okay,
then I'll handle it like this) as well as increased packet sizes for
everyone who is straying from hop count (extension types are cheaper
than complete TLVs, byte-wise, iirc).
Regards,
Lotte
Other related posts:
