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
>> OLSRv2
> for
>> research (instead of doing research on OLSRv2) will continue to use
> the "basic
>> RFC implementation" of OLSR... if the basic RFC does only contain
> hopcount
>
> 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