[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [manet] Default metric in OLSRv2
I agree with almost all of Thomas's message (I might have one
small nitpick, but it's not important right now) and that
definitely includes the conclusion, that an ETX draft would
be valuable - and actually not just in an OLSRv2 context.
--
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 Fax: +44 1245 242124
BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687
-----Original Message-----
From: Thomas Heide Clausen [mailto:thomas at thomasclausen.org]
Sent: 14 October 2009 11:25
To: Dearlove, Christopher (UK)
Cc: Henning Rogge; manet at ietf.org
Subject: Re: [manet] Default metric in OLSRv2
*** WARNING ***
This message has originated outside your organisation,
either from an external partner or the Global Internet.
Keep this in mind if you answer this message.
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