All,
Can I make a couple of rush observations and a suggestion here, without taking side in this discussion just yet?
Observations:
o We agree that additive metrics should be in OLSRv2.
=> They will be, we've got consensus on that,
the metrics I-D contains that and it will be
(I believe that I can safely engage all the authors)
folded into the OLSRv2 specification as the WG
has decided.
o ETX is a valuable example of a metric. There are existence
proofs (plural) hereof from operational networks. It's hard
to argue against that. It's also hard to argue that ETX is the
be-all-end-all metric (but I think that nobody has suggested
that either).
o Regardless of if ETX is to be included in the OLSRv2 spec
or published as an independent spec (and I see and recognize
arguments for and against both of these options), there's no
current (IETF) specification of ETX. Consequently:
=> It's difficult for the WG to pronounce itself on the
issue
=> There's no ETX-text to propose folding in to any
specification, or to advance as a supplementary
document (i.e. for the WG to adopt and to advance
for publication).
Suggestion:
o Someone with experience in ETX and OLSR(v2) produce
an individual I-D (short is good, shorter is better), and post
to manet at ietf.org for further discussion.
Informally, as I know that Henning and Aaron have significant operational experience with ETX in OLSR(v2) networks, I'd think it interesting and a good idea if you were to produce such a document. I'd be happy [as OLSRv2 co-author] to help out, as will Emmanuel (he just confirmed this, as he's next to me) -- and I am sure that so will others.
I am sure that once a document exists, it will be a lot easier to understand what it is that we're discussing, what the right path for the content is etc.
Thoughts?
Thomas
On Oct 14, 2009, at 11:48 AM, Dearlove, Christopher (UK) wrote:
I don't think this will work well for OLSRv2. Most people using OLSRv2for
research (instead of doing research on OLSRv2) will continue to usethe "basic
RFC implementation" of OLSR... if the basic RFC does only containhopcount
That is not the proposal. See what's written in the metrics draft.
(I agree what you indicate would not be acceptable. But that's why
that isn't it.)
The proposal is that the default is an additive metric of unspecified
"real world" meaning. But it's still a metric, and not just hopcount.
It's just not a specific ETC/delay/whatever metric. At least not
specified as such. In a given deployment if you agree in advance that
this is ETX, fine. But if you definitely want ETX then get an allocation
of one of the reserved metric code points specifically for that purpose
and use that.
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
_______________________________________________
manet mailing list
manet at ietf.org
https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet at ietf.org
https://www.ietf.org/mailman/listinfo/manet