►
From YouTube: IETF110-BABEL-20210309-1430
Description
BABEL meeting session at IETF110
2021/03/09 1430
https://datatracker.ietf.org/meeting/110/proceedings/
A
A
Oops
this
is
the
babel
working
group,
donald
eastlake,
with
future
way.
Russ
white
jennifer
is
our
co-chair
and
martin
vigorous
our
ad
on
the
line
here.
So
this
is
the
note.
Well,
people
have
probably
seen
this
before,
but
basically,
if
you're
contribute
something
to
the
ietf
and
you're
aware
of
intellectual
property
like
patent
rights
in
what
you're
contributing
in
any
form
or
venue,
including
speaking
or
presidenting,
then
you
need
to
declare
that
it's
a
little
reminder.
A
A
A
A
B
A
A
So
for
seating
on
the
status,
there's
two
drafts
through,
I
usually
discuss
with
icsd,
tell
chat,
which
discusses
being
resolved.
The
information
model
which
barbara's
going
to
talk
about
and
source
specific,
which
julius
is
going
to
mention
in
his
slides
there's
a
publication
request
for
the
yang
model,
which
is
that
I
think
it's
been.
The
idea
is
to
get
the
information
model
nailed
down.
Yang
model
is
kind
of
based
on
that
draft.
In
the
working
group
we
have
the
v4
via
v6,
julius
will
also
talk
about.
A
There
is
a
one
expired
horton
group
draft
on
the
rtt
extension,
which
there's
significant
interest
in,
but
in
terms
of
using
it
or
something,
but
there's
nothing.
None
to
revive
that
draft,
specifically
and
in
home
that
there's
the
babel
profile,
which
is
still
in
the
rfc
editor's
queue
basically
pending
source
specific.
A
A
A
A
A
One
can
be
discussed
on
the
there's
no
presentations
on
that
today,
but
we
discussed
on
the
mailing
list
and
I
can
mention
how
802.11
mesh
does
it,
and
if
we're
going
to
do
this
211
the
vehicle
freighter,
211
mesh,
we
probably
need
to
send
a
liaison
to
8
or
2
11.
To
ask
their
permission.
I
talk
about
that
in
my
slides.
A
C
D
A
D
D
The
documents
are
not
exactly
fortunate.
In
particular,
there
are
two
shoots
that
are
impossible
to
implement.
They
were
requested
by
the
isg,
so
I'm
not.
I
don't
want
to
give
the
impression
that
they
behave
badly.
Most
of
their
numbers
were
extremely
helpful,
cut
quite
a
few
titles
and
fix
the
documents
they
didn't
catch,
all
of
them.
By
the
way
we
had
to
make
a
last-minute
technical
change
to
mac
authentication
in
os48,
but
they
were
pretty
helpful
with,
I
would
say,
two
exceptions
and
since
I
don't
believe
in
protecting
the
ability
to
mention
their
names.
D
And
so
they
said
that
we
need
to
solve
problems
that
nobody
knows
how
to
solve.
I
tried
arguing
that
nobody
knows
how
to
solve
and
ask
in
the
bible.
Working
order
to
solve
them
is
too
much.
So
the
result
is
that
there
are
too
short
in
the
document
that,
quite
simply,
nobody
in
the
world
knows
how
to
implement.
They
should
manage
to
keep
them
at
the
ship
level.
D
D
Which
barbara
is
going
to
speak
about
they're,
so
specific
and
v4
via
v6,
that
I'm
going
to
speak
about
now
and
two
documents
that
we're
probably
not
going
to
publish
as
rfcs,
which
are
diversity?
One
that
I
forgot
to
put
on
this
slide,
which
is
rtt
diversity,
is
probably
not
useful.
I
have
never
managed
to
build.
C
D
Experiment
that
showed
that
diversity
is
useful,
so
it
sounds
like
something
that's
a
very
good
idea,
but
doesn't
help.
Much
and
rtt
is
extremely
useful.
It's
deployed
in
production,
but
we
don't
understand
why
it
works.
It's
not
supposed
to
work
as
well
as
it
does
so.
More
research
is
necessary.
We're
not
ready
to
publish
it
as
an
rfc,
perhaps
an
experimental,
but
I
don't
know
if
it's
worth
it.
D
D
now
the
draft,
we
wrote
a
draft
at
the
same
time
as
we
read
the
paper
now
that
we
are
done
with
the
base
specification,
we've
submitted,
the
drive
to
isg
and
the
iog
was
fairly
friendly
and
I
would
say
too
much
so
because
I've
lifted
the
document
after
it
came
back
from
the
asg.
I
read
it
carefully
again
and
I
have
found
that
it's
technically
correct.
I
haven't
found
any
mistakes
in
the
document
that
it's
technically
complete.
It
contains
all
the
required
data,
but
it
is
perfectly
illegible.
The
problem
is
that
you
cannot
read.
D
It
contains
all
the
information,
but
you
need
to
read
the
2015
paper
in
order
to
understand
the
draft,
so
I
have
decided
that
it's
not
worthwhile
trying
to
address
the
individual
isg
comments,
but
what
needs
to
be
done
is
to
rewrite
it
so
that
it
can
be
made
legible.
It
should
not
be
too
difficult
because
the
technical
content
is
there,
make
it
into
a
legible
document
and
resubmit.
D
D
D
And
red-
and
they
have
ipv6,
addresses
labeled
alpha
and
on
again
green
and
the
idea
of
v4
via
v6
is
to
avoid
having
to
configure
ipv4
addresses
inside
the
network.
In
fact,
if
you
think
about
it,
the
ipv4
addresses
of
routers
inside
the
network
never
appear
on
the
wire.
The
packet
goes
from
a
to
zeb
and
the
addresses
of
the
intermediate
router
don't
appear.
The
only
reason
for.
D
D
So
what
you
do
is
that
you
configure
an
ipv6
bubble
network
and
plan
ipv4
router
works
out
of
the
box.
You
don't
need
to
configure
intermediate
routers,
you
don't
have
any
encapsulation.
You
have
no
translation,
you
don't
have
any
of
the
bad
features.
This
looks
completely
mentioned,
so
some
people
might
argue.
Why
are
you
still
working
on
a
pv4
and
the
reason
for
that
is
that
we
think
that
doing
something
like
that
encourages
paradoxically
ipv4
to
ipv6
translation
transition.
D
So
right
now
there
is
no
good
reason
to
build
an
ipv6
network.
The
users
are
requesting
ipv4
because
they
want
to
access
their
favorite
ipv4
websites.
So
if
you
build
an
ipv4
network,
your
users
are
happy.
If
you
build
an
ipv6
network
they're
unhappy-
and
here
what
happens
is
that
just
by
building
an
ipv6
network,
you
get
ipv4
for
free.
So
suddenly
it
becomes
worthwhile
to
build
an
ipv6
network
next,
please,
and
so
it
was
implemented
by
twofield
in
this
in
during
last
spring.
D
D
First
of
all,
she
said
the
main
e4
and
v6
implies
that
there
is
encapsulation
going
on,
which
is
when
we
relate
it
to
v4
via
v6,
and
she
noticed
that
there
is
a
big
technical
issue.
It
breaks
icmp
next,
please,
okay,
so
my
understanding
with
icnp
is
that
initially
it
was
a
separate
protocol
from
ip
that
icmp
will
use
for
debugging
networks
for
fault
isolation.
D
It
was
not
required
by
the
protocols
themselves
and
then
something
happened.
People
decided
that
network
layer
fragmentation
is
a
bad
idea
and
they
started
using
icmp
packet
to
bid
messages.
They're
called
something
different
in
ipv4
in
ipv4
they're
called
fragmentation
needed
messages
from
the
network
is
part
of
tcp
itself.
So
what
happens
here
on
this
picture?
I
have
a
end
host
on
the
left
and
then
host
on
the
right,
and
the
end
host
on
the
left
is
sending
data
to
them
host
on
the
right.
D
D
D
D
D
And
an
ipv4
address
is
required
in
order
to
send
an
icmp
packet,
so
I've,
given
that
quite
a
bit
of
thought
over
the
last
months,
so
possible
solutions
include
one
requiring
that
every
router
have
an
ipv4
address
two
cheating
by
having
a
single
ipv4
address
for
all
routers,
defining
the
way
to
say
I
need
to
send
icmpv4
without
ipv4
addresses
or
do
the
right
thing
and
give
up
on
icmp.
Next,
please.
D
D
Where
you
put
the
address
on
the
logback
interface
and
the
linux
file
configuration
in
which
you
put
the
address
on
any
one
of
your
interfaces
and
when
we
want
to
send
an
icmp
packet,
you
borrow
the
address
from
another
interface,
so
I
feel
that
doing
that
sort
of
misses
the
point
of
v4
via
b6,
because
suddenly
you
require
manual
operator
configuration,
you
cannot
just
build
all
of
your
routers
configure
them
with
ipv6,
put
them
in
your
network
and
have
everything
work.
It's
still
less
bad
than
you
would
have.
D
Otherwise,
because
you
have
only
one
address
per
router
and
one
address
per
interface,
so
dormant
has
suggested
that
berman
says
that
he's
not
sure
that
he's
the
one
who
suggested
it
originally.
So
I'm
giving
credit
to
donald
here
that
this
ipv4
address
could
be
drawn
randomly
that
you
can
just
auto
generate.
Let's
use
the
zero
count
procedures
to
do
that.
B
Just
on
the
xeroconf
addresses,
I
think
you're
referring
to.
I
forget
the
rfc
number
for
ipv4
link,
local,
the
oh
wait,
I
was
gonna
say
those
aren't
routable
multiple
hops,
but
as
a
source
address
they
might
be.
I
I
have
to
go
double
check
that
because
you
definitely
can't
use
it
as
a
destination
across
routers,
but
force
might
be
okay
anyway.
A
D
Am
I
saturated
is
my
audio
wrong.
Sorry,
for
that
is
my
audio
better.
Now,
yes,
yeah,
okay,
okay!
So
the
second
solution-
and
I
don't
remember
whether
it
was
me
or
david
who
suggested
that
is
to
do
the
same
thing
but
use
just
one
address
so
pick
your
favorite
address,
say
10.42.42.42
and
put
it
on
the
loopback
interface
of
all
routers.
D
This
sounds
horrible,
but
actually
the
address
is
only
used
as
the
source
of
icmp
packets.
So
either
you
have
special
handling
in
the
os
or
you
firewall
it
away
and
you're
only
allowing
it
as
the
source
address
of
icmp
packets.
So
suddenly
you
have
no
per
router
configuration.
You
have
just
the
static
configuration
of
the
one
ipv4
address
used
for
icmp.
D
D
Okay,
as
is
suggested
by
d
who's
d.
That's
you!
Okay,
as
suggested
by
donald
for
the
dummy
ipv4
address
in
rfc
7600,
which
I
haven't
read
yet
it's
a
big
rfc
and
it's
a
shared
address
now
shared
addresses
are
used
in
two
cases.
Usually
reusing
ipv4
addresses
when
using
that
or
for
using
anycast,
but
this
is
neither
of
the
two
we're
not
doing
that
we're
not
using
any
anycast
because
we're
using
it
as
a
source
address.
D
D
This
third
part
problem
that
the
lack
of
fate
sharing
here
is
going
to
be
even
worse,
because
you're
going
to
be
mixing
ipv4
and
ipv6
and
anyway,
I
feel
that
it's
out
of
scope
for
this
working
group
next,
please-
and
finally,
there
is
what
I
consider
as
being
the
right
solution
is
that
icmpv4
icmp
should
not
be
used
as
part
of
the
protocol.
Icmp
should
be
reserved
as
a
debugging
and
fault
isolation.
Protocol
and
tcp
should
not
be
relying
for
it.
D
So
there
are
some
solutions
that
use
that,
for
example,
there
is
an
rfc
called
packetization
layer
path,
mtu
discovery
which
uses
implicit
signals
from
the
network
ex
instead
of
the
explicit
icmp
signals.
In
order
to
do
pmtu
discovery,
I
would
prefer
something
more
explicit,
perhaps
something
that
is
inspired
by
ecn,
that
does
explicit
signaling
while
following
the
data
path
and
avoiding
introducing
a
third
path.
So
I
think
that's
an
interesting
direction
for
research,
but
it
seems
to
me
like
it's
out
of
scope
for
this
working
group.
Next,
please
so.
D
I've
been
thinking
about
what
to
put
in
the
draft
and
what
I'm
tempted
to
do
right
now
is
to
say
that
every
ipv4
router
must
have
at
least
one
ipv4
address,
because
giving
up
on
icmp
v4
does
not
seem
like
a
good
like
a
reasonable
option
in
the
long
in
the
short
term
and
saying
that
sharing
a
single
address
between
routers
is
something
that
we'd
really
like
to
do,
but
we
don't
have
enough
enough
experience
to
recommend
it
and
use.
You
know
some
weasel
word
and
like
more
experimentation
is
needed.
B
B
So
I
I'm
gonna
propose
something
that
might
be
heresy,
so
you
know
feel
free
to
yell
it.
It
is
possible
to
send
an
ipv4
packet
without
having
an
ipv4
address
in
theory,
you're
not
supposed
to
do
that,
but
at
the
end
of
the
day,
you're
just
sending
bits
on
a
wire.
So
what
I'm
saying
is
what
I
might
my
proposal.
I
guess
is
these
routers
should
support
icmp
v4
and
should
be
sending
these
pack.
Sorry
must
support
ipv4.
It
must
send
these
packets
for
things
to
work.
B
C
Yeah,
I
just
wanted
to
mention
that
the
rfc
3927
the
dynamic
configured
auto
ip
addresses
those
are
those
169
addresses.
Those
are
pretty
well
universally,
already
supported
in
most
operating
systems,
well
universal
at
most
yeah,
but
I
know
it's
in
linux
and
I
know
it's
in
microsoft
and
I'm
guessing
it's
probably
in
the
apples.
So
you
know
that
should
already
be
there
and
be
easy
to
experiment.
C
A
D
D
A
A
A
A
C
A
C
C
And
you
know
this
is
one
that
we
run
round
on
twice
and
right.
Now.
We've
got
this
statement
about
being
between
zero
and
the
block
size
of
the
underlying
hash,
and
so,
let's
move
on
to
the
next
slide,
and
so
what
ben
katic
was
pointing
out.
So
I
I
mentioned
to
him
some
of
the
discussion
about
how
you
know.
C
Ospf
and
rfc
20
104
differed
on
how
to
calculate
the
cryptographic
key
from
the
long
authentication
key
and
what
was
considered
long,
but
ben
said
that,
in
fact
you
know
we
what
the
language
we
have
won't
solve
it,
because
I
guess
the
block
size
is
bigger
than
the
l
size
and
so
e
anyway,
or
maybe
it's
the
other
way
around.
I
get
so
confused
and
so
that
it
won't
work,
and
there
was
also
discussion
about
conversion
of
ascii
input,
but
I
think
we're
fine
on
the
ascii
input.
C
My
question
is
what
is
the
right
requirement
and
I
think
we're
fine
actually
on
the
blake
2s
with
the
32
limit,
because
blake
very
nicely
didn't
bother
trying
to
create
some
weird
algorithm
for
rehashing
long
things
so
that
you
end
up
with
the
right
size,
cryptographic
key,
and
so
you
know
for
blake.
I
think
we're
fine
restricting
it
to
the
32
octets,
but
on
the
h
max
shaw,
256,
I'm
kind
of
curious
what
others
think.
So
let
me
open
it
up.
What
do
y'all.
D
That's
not
helpful,
so
the
situation
is
that
keys
have
the
block
size.
People
are
getting
confused
between
the
block
size
and
the
digest
size
so
keys.
Naturally,
if
I'm
getting
it
right,
I'm
not
a
cryptographer.
I'm
trying
to
summarize
keys
have
the
natural
size
of
keys
is
the
block
size,
and
there
are
two
things
that
happen.
One
is
that
people
tend
to
confuse
block
size
and
digest
size,
and
the
other
thing
that
happens
is
that
people
tend
to
want
the
user-friendly
feature
of
having
arbitrary
size
keys
and
they
develop
ad-hoc
hashing
mechanisms
right.
D
D
C
A
D
A
D
Well,
it's
the
recommended
input.
Okay,
eight,
nine,
six,
seven!
I
cannot
find
it
right
now,
but
we
say
at
one
point
that
the
recommended
input
is
a
random
key
and
that
if
user-readable
passphrases
are
necessary,
they
should
be
processed
on
a
central
host
and
only
the
resulting
hashed
keys
should
be
distributed.
D
D
Okay-
and
it
says
in
that
case
only
the
derived
key
should
be
communicated
to
the
routers.
The
original
path
trace
itself
should
be
kept
on
the
host
used
to
perform
the
key
generation
eg
and
administrator
secure
laptop
computer.
So
that's
section
seven,
the
one
two
three
four
fifth:
paragraph
of
the
security
conver
section:
seven.
C
B
C
B
F
F
B
F
Yeah,
so
I
had
made
the
promise
to
ben
that
I
wouldn't
approve
before
the
problem.
The
discuss
is
effectively
resolved,
so
I
would
have
to
break
my
promise,
but
I
can
I
can
have
a
chat
with
ben
a
rapid
chat
to
make
sure
that
me
approving
doesn't
hurt
his
feelings
and
he's
okay
to
continue
the
discussion.
Even
if
the
document
is
approved.
B
F
B
C
B
So,
okay,
another
proposal
could
be
barbara.
You
just
remove
that
recommendation,
because
removing
text
is
always
easier
than
adding
text
like
you
do
that
today
you
submit
a
new
version
of
the
draft
and
then
tomorrow
martin
can
approve
it
and
that
way,
ben's
happy
martin's
happy.
The
working
group
is
happy,
we're
all
happy.
We
can
have
more
drinks.
B
C
C
C
C
I
think
I
have
a
path
forward
that
I
can
work
with
ben
because
he
also
said
that
some
of
what
he
wanted
was,
if
you
have
justification
for
the
recommendations,
you
can
provide
that
and
that'll
make
it
easier.
But
right
now
it's
not
understood
why
there
are
restrictions,
and
so
I
think
I
can
come
up
with
maybe
some
text
about
why
there
are
restrictions
and
what
the
restrictions
are,
and
I
can
point
to
the
rfc
8967
to
help
me
with
that.
So
I
think
I.
E
D
A
C
A
A
A
Okay,
so
I'm
going
to
go
through
this
presentation
pretty
quickly.
You
can
examine
the
slides
at
your
leisure
and
have
less
time
than
I'd
planned.
So
I
chaired
the
80
to
11
mesh
task
group
for
part
of
its
existence,
but
I
probably
don't
remember
everything
because
it
was
a
while
ago.
The
80211
standard
is
pretty
big.
You
can
download
it
yourself
and
peruse
all
4
377
pages
of
the
2020
version.
A
If
you
wish-
and
I'm
speaking
entirely
for
myself
personally
here
so
talk
a
little
bit
about
the
background,
innovator,
211
and
mesh
a
fair
amount
of
information
about
existing
wi-fi
mesh,
you
can
sort
of
see
how
it's
a
big
framework
that
they
will
produce.
Protocol
can
fit
into
and
a
little
bit
about,
process
and
stuff.
A
A
So
you
get
a
lot
of
stuff
with
fuse
wi-fi.
You
know:
there's
lots
about
adjusting
and
negotiating
data
rates
and
for
advanced
versions.
It
can
do
beam
forming
it
can
switch
between
different
channels.
It
knows
about
different
spectrum,
different
nations
and
stuff,
and
although
the
normal
frequencies
used
are
license
exempt
and
unlicensed,
there
are
wi-fi,
there
are
frequencies.
You
can
use
wi-fi
protocols
in
that
have
various
licensing
regimes,
that's
all
in
the
standard.
A
It
has
lots
of
things
to
do
with
aggregation,
so
you
can
get
really
high
data
rates
because
inquiring
the
channel
wearing
the
air
interface
is
considered
expensive.
So,
if
you're
doing
a
high
bit
rate,
then
once
you
acquire
it,
you
want
to
pump
a
whole
bunch
of
bits
through.
On
the
other
hand,
there
can
be
very
slow,
noisy
channels,
and
things
like
that,
and
you
don't
want
to
send
things
for
too
long,
because
you'll
get
errors
and
so
there's
fragmentation
features
it
improved
reliability.
A
It
has
a
link
level,
one-half,
acknowledgement
and
re-transmission
and
has
like
counters
and
things
to
avoid
getting
duplicates.
Due
to
that,
you
can
defeat
that
if
you
want
turn
off
turn
a
bit
on
the
header,
it
has
the
the
security
the
encryption
and
authentication
it
has
is
essentially
almost
always
built
into
the
hardware
firmware
and
the
chipsets,
because
everybody
assumes
that
everybody's
almost
everybody's
always
going
to
want
to
secure
their
their
radio
links.
So
it
doesn't.
A
The
cost
of
making
the
protocol
more
sophisticated
and
putting
in
these
fancy
features
can
be
amortized
over
a
huge
number
of
chips
and
experience
that
the
goal
for
wi-fi
was
always
100
meters
for
its
range,
so
it's
10
meters
for
bluetooth
and,
lastly,
80211
believes
in
a
single
unified,
complex
header,
rather
than
trying
to
sort
of
nest
headers.
It
just
puts
more
stuff
and
flags
and
options
in
this.
This
one
unified
header,
which
is
kind
of
an
interesting
approach,
so
8011
mesh,
was
originally
designed
just
to
provide
wireless
backhaul
for
access
points.
A
Here's
the
schedule
it's
all
been
rolled
into
the
current
standard,
there's
a
list
of
some
implementations.
I
don't
know
if
it's
complete
in
wikipedia,
so
here's
a
typical
bunch
of
access
points
and
stations
for
an
80211
extended
service
that
it's
called
technically
and,
as
you
see
you
know,
I
said
ssid
server-side
identifier,
which
identifies
this,
and
the
idea
with
the
original
version
of
mesh
was
just
to
be
able
to
have
mesh
links
between
the
access
points
and
have
access
points
that
were
not
connected
to
the
with
their
wireless
infrastructure.
A
So
about
80211
mesh
there's.
The
links
are
obviously
appear
to
appear.
Every
mesh
station
in
our
native
211
mesh
has
a
profile
and
they
don't
appear
unless
the
profile
is.
The
same
includes
a
mesh
id
a
path,
selection
protocol,
identifier,
a
path
selection,
metric
identifier
and
congestion,
synchronization
and
authentication
protocols,
and
if
you
have
authentication
turned
on
that,
they
won't
appear
until
they've
authenticated
each
other
to
a
pair
of
stations
that
are
trying
to
cure.
A
So
the
ssid
is
not
used,
there's
always
an
ssid
field
there,
which
is
set
to
the
wildcard
value.
I
think
it's
just
a
single
asterisk,
but
there
is
a
mesh
id
element
which
is
the
same
as
ssid.
Ssids
are
almost
always
readable
but
in
fact
technically
it's
just
a
0
to
32
octet,
binary
string.
I
don't
know
how
you
know:
8
or
2
11
user
interfaces
work
very
well.
If
you
make
it
use
the
unprintable
ssid,
but
that's
what
it
is
so
interval
of
mesh.
A
A
So
in
8
11
mesh,
it's
an
802
thing.
802
is
you
know,
mac
kind
of
place,
so
its
routing
is
based
on
mac
addresses
and,
in
the
most
general
form,
a
data
frame.
Unicast
data
unicast
frame
in
the
80211
mesh
has
six
mac
addresses
in
the
header
I
told
you,
it
has
a
unified,
complex
header,
there's
the
transmitter
and
receiver
and
the
radio
link
there's
the
mesh
source
and
mesh
destination,
and
that
might
be
it
if
it
was
coming
from
a
node
in
the
mesh
to
a
node
in
the
mesh.
A
But
it
was
coming
from
from
outside
the
mesh
and
destined
outside
the
mesh,
and
you
also
have
the
original
source
and
the
final
destination
mac
address.
Of
course,
these
could
be
like
ip
routers
that,
were
you
know
just
right
outside
the
mesh
or
something
like
that
they
have
a
ttl
and
they
have
a
four
octet
mesh
sequence
number,
so
duplicates
of
the
same
mesh
source
and
sequence
number
are
dropped.
So
basically
the
way
you
multicast
and
broadcast
works
in
eight
or
to
11
meshes
it
just
sort
of
floods.
A
A
It
doesn't
actually
reference
rfc
30.
Well,
it
there's
a
reference,
but
you
don't
need
to
look
at
rfc
3561.
The
specification
in
the
80211
standard
is
entirely
complete.
You
can
fully
implement
it
without
looking
at
the
rfc,
but
it
is
based
on
the
our
the
idea
of
the
rfc
there's,
also
a
tree
building
mode.
A
If
you
declare
a
route
or
more
than
one
route,
you
can
build
a
tree,
so
you
can
have
things
like
you
can
always
get
a
packet
from
a
frame
from
one
station
to
another
by
going
up
to
the
free
route
and
back
down
again,
even
if
they're
in
different
branches
or
maybe
a
smaller
portion
of
the
tree.
But
you
can
start
doing
that
and
then
you
can
use
the
on
ad
ad-hoc,
on-demand
stuff,
to
try
to
find
a
more
efficient
direct
route
between
the
two
stations.
A
A
It's
called
the
air
time
metric
and
you
basically
it's
the
overhead
plus
the
the
the
number
of
bits
in
your
test
frame,
which
they
recommend
you.
You
calculate
this
using
a
one
k,
octet
frame
the
data
rate
and
the
error
rate.
So
if
I
have
a
fifty
percent
error
rate,
you
assume
it
takes
twice
as
long
as
it
is
the
average
you'd
have
to
retransmit
it
and
that
enough
to
cause
it
to
take
twice
as
much
time.
A
So
if
you
ever
have
to
do
a
presentation
to
8
or
211
as
a
hint,
it's
good
to
include
an
equation
in
your
presentation,
80
to
11
likes
equations,
so
there's
one
so
there's
some
other
stuff
about
it.
The
811
quality
of
service
features
are
theoretically
optional,
which
they
basically
allow
higher
priority
data
packets
to
be
given
preference
in
acquiring
a
radio
channel.
It's
all,
there's
a
whole
bunch
of
really
detailed
timing.
Controls
that
the
aircloth
mesh
has
its
own
power.
Save
stuff.
A
A
It's
got
a
be
conclusion.
Avoidance
feature
to
avoid
collisions
due
to
hidden
nodes
where
one
node
can't
see
another
for
some
reason:
congestion
avoidance-
you
can
have
a
channel
switching,
they
can
switch
the
whole
mesh
from
one
radio
channel
to
another.
So
it's
in
the
way
rush
is
defined.
It's
kind
of
assumes
a
single
radio
crustation
which
isn't
really
an
effective
way
of
doing
mesh,
but
really
people
extend
that
and
almost
always
have
multiple
radios
and
even
emergency
services
support
for
certain
applications
in
certain
areas.
A
Somebody
might
attempt
to
be
making
a
voice
call
to
emergency
number.
You
have
to
allow
them
to
do
that.
Legally,
so
you
know
when
you
do
a
appearing
open,
you
can
say
I
need
the
emergency
service
and
he
can
has
to
let
you
in,
but
it
may
restrict
your
bandwidth
and
only
route
you
to
a
emergency
service
access
point.
A
A
Mesh
f811
metric,
based
on
etx,
for
example,
and
I
think
I
only
have
one
more
slide
here:
yeah
yeah
so
I'll
just
give
this
a
julius.
So
although
influence
is
clearly
designed
to
be
extensible
in
this
fashion-
and
you
can
even
vendors
can
extend
it
without
even
talking
to
80211
by
using
their
using
the
vendor
extension
feature.
Nevertheless,
experience
indicates
to
me
that
the
iesg
and
ietf
will
want
a
explicit
liaison
from
80
to
11,
saying
it's
fine
for
us
to
do
this.
A
I
don't
believe
that
will
be
hard
to
get
and
in
fact
having
that
might
be
useful
because
it's
possible,
although
theoretically
we
only
need
a
fast
selection
protocol,
identifier
and
possibly
a
pass
selection
metric
identifier.
We
might
want
other
other
numbers
from
there
equivalent
to
viana
there.
The
80211
working
group
has
one
equivalent
and
it's
possible.
There
might
need
to
be
a
a
mesh.
D
Okay,
so
think
about
the
default
route.
You
can
announce
a
default
route
at
two
points
in
a
barbell
network
and
the
two
routers
that
announce
the
default
route.
Don't
need
to
have
synchronized
sequence
numbers
now,
if
you're
working
at
player
2,
you
no
longer
have
this
problem
because
a
different
mac
address
you
announce
at
only
one
place
in
your
mesh
right.
A
D
That's
not
normal,
that's
not
the
normal
behavior,
while
in
the
case
of
a
90
network
having
the
same
ip
at
ip
prefix
announced
at
two
places
is
completely
natural
and
we
don't
want
to
have
synchronized
sequence.
Numbers
sequence:
numbers
are
not
clocks,
they
are
not
synchronized.
So
if
you
do
babble
at
layer,
two
then
becomes
much
simpler.
D
So
that
leads
to
the
point
that
if
you
do
babel
at
layer
2,
you
don't
want
to
use
babel.
You
want
to
use
the
simplified
protocol
that
no
longer
needs
to
carry
router
ids,
so
the
distinction
between
ip
prefix
and
router
id
is
due
exactly
to
this
problem,
but
once
you're
working
with
mac
addresses,
you
can
give
up
on
the
router
ids
and
you
have
the
mac
addresses
both
as
the
prefix,
both
of
the
destination
of
traffic
and
the
router
id.
A
Supplement,
yes,
the
other
was
the
other,
was
kind
of
a
link
status,
kind
of
thing
olsr.
I
think,
and
it
basically
there's
tremendous
pressure
in
nato's
eleven
well
in
ieee
working
802
working
groups
to
simplify
things
and
basically,
although
a
lot
of
work
was
put
into
specifying
that
it
was
removed.
D
A
A
Well,
I
think
babel
would
be,
could
easily
be
better
than
hwmp
so
yeah
I
don't
know,
do
you
really
believe
that
there's
only
one
ecological
niche
or
something
I
I
think
that
the
the
level
the
you
know,
basically
a
distance
vector
with
the
additional
features
bevel
has
to
avoid
problems
with
the
naive.
This
distance
vector
is,
would
be
a
good
option
for
80211
mesh.