►
From YouTube: IETF111-BABEL-20210726-2130
Description
BABEL meeting session at IETF111
2021/07/26 2130
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
A
A
A
A
A
There
is
a
shared
writing
area
that
everybody
can
get
at,
so
people
can
cooperate
on
that
sort
of
thing
and
help
out
with
the
minutes,
but
the
current
proposal
is
that
there's
a
status
of
muslim
chairs
report
and
there's
one
slide
in
there
on
the
current
state
of
the
yang
model,
which
mahesh
is
on
the
call.
So
he
can
speak
to
that
one
slide
in
that
presentation.
A
I
then
have
presentation
on
reviving
babel
rtt
by
julius,
and
we
have
time
available.
I've
put
together
a
presentation
which
may
have
interested
people
it'll,
say
somewhat
layer.
Two
oriented
about
addressing
in
wi-fi
transit
link
is
supposed
to
be
transit,
as
it
says,
trams
that
should
be
supposed
to
be
an
n
right
there
into
typo,
multicast
and
stuff
and
then
we'll
wrap
up.
So
anybody
have
any
suggestions
for
additions,
deletions
or
changes
or
the
like.
A
A
The
next
item,
let's
see,
would
be
bad
taste,
ask
agenda
bashing
removed
from
the
from
the
agenda.
Well,
you
know
it's
like
tradition,
so
I
don't
know
I
mean
if
somebody
wants
to
change
the
agenda.
They're
certainly
entitled
to
make
that
request
and
speak
up
so
but
in
any
case
document
status
we
have
five
rfcs
that
are
the
output
of
this
working
group,
including
the
babel
routing
protocol,
these
replace
the
previous
experimental
ones,
and
they
also
now
include
the
babel
information
model.
A
A
A
A
There
is
the
expired
rtt
extension
which
julius
will
be
speaking
to
and
there's
the
home
net
label
profile
is
currently
waiting
on
the
source
specific.
So
when
source
specific
goes
through,
then
that
should
eliminate
the
block
on
that
neck,
which
is
in
miss
ref,
and
there
has
been
a
beer
extensions
draft
published.
A
B
Good
so
as
the
dollar
status
said
that
that
the
babel
young
model
document
isn't
hopefully
not
discussed,
we
should
have
addressed
most
of
the
discuss.
There
are
some
comments,
though,
that
are
still
there,
so
it
is
an
issue
review
and
most
of
the
comments
have
been
addressed.
There
is
one
outstanding
set
of
comments
from
ben,
which
I
am
in
the
process
of
reviewing,
and
I
will
respond
to
probably
right
after
this
meeting,
at
which
point
I
think
we
will
publish,
I
said,
dash
10,
but
maybe
dash
11..
B
A
A
Not
hearing
anything
one
more
status
slide,
which
is
on
milestones.
So,
despite
my
best
efforts,
we
still
have
all
of
our
milestones
completed,
as
I
suggested,
adding
some
and
after
discussion.
We
added
one
for
the
ipv4
by
ipv6
submission
to
the
iesg,
but
we've
done
that
now.
So
it's
still
the
case
that
there
are
no
official
milestones
for
the
group
that
haven't
been
accomplished.
A
A
C
Can
you
hear
me
I
can
good
okay,
so
hello,
I'm
like
to
say,
tell
you
a
few
words
today
about
babylrtt,
but
before
I'd
like
to
thank
donald,
I
was
at
the
mountains
this
morning
just
packing
to
take
my
train
back
to
paris.
When
I
received
the
reminder
from
donald
telling
me,
you
didn't,
send
your
slides
yet
so
thanks
a
lot
for
the
reminder,
donald,
you
saved
me
from
having
egg
on
my
face,
and
so,
let's
hope
it
goes
well.
I
prepared
the
slice
today
next,
please
next
slide,
please.
C
So
in
this
working
group
we
have
had
a
policy,
and
I
think
we
can
all
be
proud
of
this
policy.
We
have
had
a
policy
of
having
of
implementing
everything
we
did
that
allowed
us
to
catch
quite
a
few
things
that
seemed
obvious
but
turned
out
to
be
difficult
to
implement.
We
didn't
make
these
mistakes,
and
the
other
advantage
is
that
we
know
which
of
the
things
that
we've
been
working
on
are
useful.
C
So
all
of
the
extensions
that
we've
made
to
the
core
babble
protocol
have
either
are
in
the
process
or
have
been
standardized
or
are
not
actually
used
in
production.
So,
for
example,
there
is
one
pro
one
extension
that
I'm
very
keen
on
which
sounded
like
an
excellent
idea
and
that
turned
out
not
to
be
useful.
That
was
the
radio
diversity
extension,
it's
still
in
the
babel
d
code,
but
it
doesn't
improve
things
in
any
reasonable
topology.
C
It's
a
big
surprise.
I
want
to
understand
why
I
don't
currently
understand
why
this
is
just
not
useful,
so
we're
not
standardizing
it.
Another
example
is
tos
specific,
so
having
different
routes
for
different
types
of
service.
Intuitively
sounds
like
something
useful,
but
in
fact
nobody
has
requested
the
features.
So
there
is
code
somewhere
in
the
bld
branch,
I'm
waiting
for
people
to
request
that
nobody
is
requesting
it
we're
not
normalizing.
C
There's
one
exception:
that's
babel,
rtt
babel
rtt
has
been
used
in
production
for
seven
years
now
it's
been
requested
is
remote
here
today,
yeah
I
s
yeah.
I
see
with
pleasure
that
ronald
is
in
the
room,
so
ronald
has
been
telling
me
that
it
needs
to
be
standardized
and
I
think
he's
right,
because
people
are
actually
using
it
in
production
and
it's
only
described
in
an
expired
itf
draft
and
a
paper
that
got
a
scientific
paper
that
got
rejected,
and
you
know
people
always
give
you
long
explanations.
C
The
referees
didn't
get
it,
and
so
I'm
the
author,
I'm
the
main
author
of
this
paper,
and
I
can
tell
you
on
authority
that
it
was
not
a
very
good
paper
and
it
was
rejected
for
good
reasons.
Next,
please,
okay,
so
quick
history,
it
solves
a
problem
that
I'm
going
to
remind
you
of
in
that
nexidi
noticed
a
company
that
is
using
babel
in
their
overlay
network
in
early
2014.
C
So
I
spent
part
of
the
spring
of
2014
designing
the
solution.
Then
I
find
that
I
found
a
rather
bright
student
that
is
jean-glasa
and
betty
jumples
implemented
and
wrote
it
up
together
with
me
in
the
summer
of
2014,
so
that
was
the
original
internet
draft
and
the
the
paper
that
got
rejected
it
got
deployed
in
production
during
the
autumn
of
2014.
C
And
finally,
after
ronald
prodded
me
a
few
times,
I
think
donald
also
insisted.
I
presented
it
to
the
working
group
on
in
march
2019,
but
the
main
point
is
that
it
has
been
continuously
deployed
in
production
for
seven
years,
and
here
are
the
references
of
the
two
places
where
it's
described
next,
please,
okay,
so
I've
already
told
that
back
in
2019
I'll
be
very
quick.
Nexidi
are
running
a
global
overlay
network.
They
have
a
few
hundred
data,
small
data,
centers
and
they're
running
tunnels
between
them
and
they
use
babel
to
root
over
them.
C
Now
this
is
a
typical,
typical
topology.
They
have
four
data:
centers
lil,
paris
and
marseille,
all
of
those
in
france
and
one
in
tokyo.
Now
in
this
topology,
what
happens
when
the
lil
marseille
link
goes
down?
Well,
babel
sees
two
hops
between
lille,
paris
and
marseille,
and
two
hops,
lil
tokyo
and
marseille
and
non-deterministically.
C
Once
in
two
cases
it
will
root
the
packets
through
tokyo,
so
you
might
say,
but
we
thought
that
babel
was
able
to
use
flexible
metrics.
Yes,
but
here
the
links
are
lossless,
so
babel
just
sees
two
hops.
In
every
case
and
nick
said,
you
were
not
happy
with
having
their
traffic
go
through
tokyo
whenever
there
was
a
failure.
Next,
please,
so
my
initial
idea
would
be
to
put
a
gps
in
every
data
center
so
that
we
would
use
real-world
distance
and
apparently
that's
not
practical.
The
problem
is
not
the
cost
of
the
gps.
C
The
problem
is
that
you
need
a
technician
to
maintain
the
gps's,
and
that
makes
the
cost
prohibitive.
Another
suggestion
was
to
use
geolocation,
but
there
are
two
problems
with
that:
first
geo
location
is
not
very
reliable
and
second,
you
have
a
bad
mixture
of
layers
when
you
use
geolocation
to
do
routing
and
you
have
layering
violations,
and
that
makes
everyone
nervous.
So
the
idea
was
to
measure
the
rtt,
the
two-way
delay
and
the
arrival
network
from
that,
and
if
you
do
it
now,
it
seems
like
a
simple
idea.
C
But
the
first
point
is
that
the
natural
way
to
measure
rtt
requires
an
asymmetric
and
synchronous
interaction.
Now
babel
is
a
peer-to-peer
completely
symmetric
protocol
as
asynchronous
you
can
always
delay
sending
of
a
packet
by
up
to
a
few
seconds,
and
the
other
thing
is
that
if
you
use
rtt
as
input
to
a
rooting
network,
if
you're
not
careful
you're
going
to
have
a
negative
feedback
loop
and
when
you
have
a
feedback
loop,
you
end
up
with
oscillations
next,
please,
okay,
so
the
naive.
So
now
I'm
coming
to
the
first
part.
C
What
is
wrong
with
mirroring
rtt
in
the
naive
manner,
the
natural
way
to
measure
rtt
is
to
send
a
ping
packet
in
the
client
to
server
direction
and
the
server
replies
pong
as
fast
as
possible,
and
you
measure
the
difference
between
the
time
at
which
the
ping
has
been
sent,
which
I
note
t
o
for
origin
and
t
the
time
at
which
the
pong
is
answered.
Okay,
that's
what
you
do.
That's
very
simple,
but
this
is
a
asymmetric
protocol.
It's
client
server
and
it's
synchronous.
C
C
So
what
you
can
notice
in
this
formula
is
that
you
only
subtract
either
the
clocks
on
the
left,
hand,
side
or,
on
the
right
hand,
side,
and
so
that
means
that
the
clocks
don't
need
to
be
synchronized,
and
the
other
thing
is
that
you
can
dwell
as
long
as
you
want
between
tr
and
tt
as
long
as
the
clocks
don't
drift
too
much
from
each
other.
So
it's
a
symmetric,
asynchronous
algorithm.
It
doesn't
require
clocks
to
be
synchronized,
it's
something
that
fits
well
with
babel.
C
C
Next,
please,
okay,
here's
the
packet
format,
it's
pretty
obvious.
We
use
a
sub
tlv
in
hello
and
a
sub
dlv
in
ihu.
In
hello.
We
have
just
one
timestamp
in
ihu
have
two
timestamps:
they
are
not
the
same,
and
there
is
one
thing
that
bothers
me
about
this
encoding.
Is
that
you
we
use
type
three
for
both
and
we
disambiguate
by
looking
at
the
type
of
the
enclosing
tlv.
The
question
I'd
like
to
ask
to
the
group
is:
should
be
we
switch
to
using
distinct
types
for
the
two
kinds
of
timestamps.
Next,
please.
C
Okay,
so
quickly,
if
you
use
rtt
as
a
rooting,
metric
you're
going
to
have
oscillation.
So
here
a
is
sending
traffic
to
b
and
the
traffic
goes
through
d,
and
then
the
a
d
link
gets
congested.
The
rtt
goes
up,
so
an
rtt
based
implementation
of
variable
is
going
to
switch
to
the
root
going
through
through
c
now.
C
At
this
point,
the
process
reverts
the
route
from
a
to
c,
the
link
from
a
to
c
gets
congested,
so
the
rtt
increases
and
we
switch
back
to
ad
we're
going
to
have
oscillations
now
babel
doesn't
care,
it
still
maintains
loop
free
pass.
However,
when
you
have
oscillations,
you
might
have
packet
reordering
and
that's
going
to
destroy
the
performance
of
tcp
or
of
your
video
conferencing
application
next,
please.
C
C
C
You
apply
some
hysteresis
to
the
metric
in
order
to
get
root
selection
and
with
all
of
this
it
works
pretty
well,
but
we
don't
have
a
theoretical
understanding.
Basically,
we've
hacked
this
together.
It
works
beautifully
well,
even
in
the
worst
cases
that
we
try
to
design
in
the
lab,
but
we
don't
have
a
theoretical
understanding.
We
don't
know
which
of
the
bits
here
are
necessary
and
which
are
just
to
make
us
comfortable.
Next,
please.
C
Okay,
so
babel
rtt
right
now
is,
to
my
knowledge,
the
only
widely
deployed
bible
extension
that
is
not
in
the
process
of
being
standardized.
There
are
good
reasons
for
that.
It
is
a
simple
algorithm,
but
it's
another.
It's
a
simple
extension,
but
it's
difficult
to
design
the
algorithm
that
make
it
work
well
and
we
don't
understand
the
algorithm
that
we've
designed.
C
A
C
C
C
So
I
really
I'm
not
saying
I'm
playing
devil's
advocate
here.
So
yes,
I
agree
with
you.
On
the
one
hand,
it
makes
me
uneasy
to
use
the
same
to
overload
the
same
type.
At
the
other
hand,
there
are
some
technical
reasons
to
do
the
opposite.
A
name
I
mean
I've.
Had
I
keep
oscillating
between
the
two
opinions.
C
C
A
A
A
A
All
right,
so
this
is
something
I
thought
might
be
of
interest
to.
People
in
this
group
ended
up
being
kind
of
a
fairly
general
presentation
on
802.11
frame
formats
and
addressing
and
transit
links
which
are
fully
fairly
recent
feature
and
mesh
and
touches
a
bit
on
multicast
and
mesh
in
8
to
11,
which
is
wi-fi,
so
it's
very
complicated.
A
I
know
I'm
just
going
to
forge
ahead
people
who
want
to
interrupt
a
question
whatever
just
you
know,
raise
your
hand
whatever
or
or
turn
on
the
mic
and
speak
it's
a
very
complicated
standard.
You
can
get
a
full
copy,
it's
over
four
thousand
pages.
Almost
every
option
you
can
think
of
and
many
extensions
are
all
available.
A
I'm
just
speaking
for
my
opinions
on
things
I
did
was
involved
in
some
811
work,
but
that
was
a
little
while
ago.
So
I
could
be
wrong
on
some
things.
I
won't
go
into
detail,
but
this
is
listing
some
of
the
general
features,
including
aggregation,
multiple
levels
for
data
frames
for
higher
speed
and
when
you
have
a
less
noisy
link,
higher
speed,
link
and
fragmentation.
A
So
I'm
just
going
to
initially
talk
a
bit
about
the
infrastructure
mode.
Probably
everybody's
familiar
with
this
is
kind
of
what
it
people
think
about
or
what
it
looks
like.
So
you
got
like
stations
that
are
associated
with
an
ap,
an
access
point,
and
maybe
there's
some
wired
infrastructure,
so
that
set
of
things
is
called
a
basic
service
set
that's
identified
by
a
bss
id
which
is
48
bits.
This
is
all
kind
of
layer,
two
or
so
it's
usually
the
am
address
of
the
ap.
A
It
could
be
something
else,
and
you
frequently
have
several
aps
with
the
same
ssid,
maybe
even
just
in
your
house,
if
you've
configured
them
with
or
at
a
business
or
something-
and
you
can
roam
seamlessly
between
these
different
things.
What's
called
an
extended
service
set,
and
normally
they
all
have
the
same
ssid
or
service
head
identifier,
so
looking
at
it
a
little
bit
more
from
the
point
of
view
of
the
logical
structure
in
the
standard,
it
really
looks
more
like
this.
A
A
So
when
you,
when
a
frame
comes
in
from
the
outside
world,
it
logically
at
least
goes
through
this
portal
thing,
and
the
distribution
system
is
what
knows
where
all
these
different
stations
are
knows
where
the
mac
addresses
are
and
stuff
and
or
if
you
send
a
frame
between
two
stations
that
are
either
on
the
same
ap
or
on
different
aps.
It's
distribution
system.
That
knows
how
that
works.
A
A
Normally,
a
multicast
is
not
acknowledged
and
unicast
has
acknowledgements
and
retransmissions
by
default,
sort
of
on
the
single
link,
but
multicast
doesn't.
But
if
you
want
to
you
can
there's
a
scheme
where
you
can
have
block
acknowledgements
the
problem
with
having
acknowledgements.
Is
you
if
you?
If
an
access
point,
has
100
stations
associated
with
it
and
it
sends
multicast?
You
don't
want
to
have
100
acknowledgements
smashing
back
in
so
you
can
have
the
acknowledgements
be
accumulated
and
the
access
point
can
pull
for
the
acknowledgments.
A
So
you
have
frame
control
and
this
is
sort
of
oriented
towards
data
frames
and
there's
a
whole
bunch
of
fields
in
a
bunch
of
address
fields,
notice
that
a
lot
of
these
have
a
potential
length
and
octets
of
zero
means.
They
may
not
be
there
and
sequence
control
and
so
forth
and
I'll
say
what
these
are.
Then
there's
the
actual
frame
body
and
it
ends
with
a
frame
checksum
as
a
standard,
ethernet,
32-bit
checksum,
so
oops
all
right.
A
So
going
back.
What
are
these
fields?
So
the
protocol
version
is
zero,
so
you
might
think
hey.
Wi-Fi
hasn't,
really
radically
changed
their
protocol,
so
that
would
always
be
zero,
but
no
there's
actually
a
because
they
sort
of
ran
out
of
types
and
subtypes
there's
actually
a
protocol
version,
one
which
is
really
the
same
protocols
just
other
extensions
in
terms
of
control,
flame
frames
and
management
frames
and
other
sorts
of
things
like
that.
There's
lots
of
types
and
subtypes.
So
this
is
really
for
data
frame
notice.
A
The
more
data
bit
is
only
used
for
certain
special
modes.
Protected
frame
indicates
that
you
have
an
encrypted
frame
body
and
that's
a
hop
by
hop
basis
of
encryption,
of
course,
and
htc
is
a
high
throughput.
Control
means
there's
more
other
fields
following
this
that
have
information
about
how
the
high
throughput
is
happening.
So
what
are
these
to
and
from
distribution
system
bits
if
they're
both
zero?
A
If
it's
has
the
from
distribution
system
mode
and
not
two,
it
means
that
the
access
point
is
sending
something
to
a
station
there.
The
other
way
around.
It
means
the
station
is
sending
something
to
an
access
point
and,
if
both
are
on,
you
have
a
transit
link
and
that's
kind
of
a
really
new
four
address
mode.
A
So
that
way,
if,
for
example,
the
link
level
acknowledgement
is
lost
and
you
re-transmit
it
when
you
didn't
have
to
so
the
other
end
gets
two
copies
and
I
can
see
the
sequence
number
has
been
duplicated
within
that
priority
class
and
we'll
know
to,
and
if
it
only
had
this
missing
sequence
number,
you
could
tell
something:
wasn't
there,
but
there's
no
actually
no
way
to
explicitly
request
re-transmission.
In
that
case,.
A
Let's
see
so
these
are
what
the
various
address
fields
are
in
these
various
cases
and
you'll
notice
that
the
first
address
and
the
addresses
one
fields,
one
two
and
three
are
always
present,
and
the
first
address
is
always
the
radio
receiver
in
some
cases,
that's
the
station.
In
some
cases,
it's
the
access
point
necessarily
and
the
second
address
is
actually
always
the
radio
transmitter
and
in
some
cases
that's
also
the
access
point
to
the
station.
A
In
fact,
it's
a
range
course
with
802
addresses
such
that
the
very
first
bit
you
get
of
the
receive
address
is
the
bit
which
indicates
whether
it's
unicast
or
multicast,
so
absolutely
as
early
as
possible.
You
have
information
as
to
how
to
handle
this
frame
because
frequently
unicast
and
multicast
are
handled
by
significantly
different
different
methods.
A
So
I
want
to
talk
a
bit
more
about
this
for
address
transit
mode,
which
allows
you
to
use
a
connection
as
a
through
link
in
a
more
general
network.
So
here's
an
example.
So
here
in
the
middle,
we
do
have
an
infrastructure
of
an
access
point
and
some
stations
associated
with
it,
but
we
can
send
frames
from
a
source,
that's
sort
of
behind
the
access
point,
which
is
normal
there's
normally
the
network,
or
at
least
the
whole
internet
may
be
behind
the
access
point.
A
We
can
send
that
over
this
infrastructure
link
to
some
destination,
that's
behind
the
station,
so
you
can
have
a
whole
general
network
and
the
the
mac
addresses
are
all
visible.
This
is
all
layer
two,
so
you
can
have
the
source
transmitter,
receiver
and
destination
address
be
different
or
it
could
be
between
a
source
behind
one
station
associated
with
the
access
point
to
a
destination
behind
another
station
associated
with
that
access
point.
A
A
And
looking
at
it
again,
essentially
the
distribution
system
that
existed
before
when
you're
using
this
for
address
mode.
What
you
really
have
is
a
a
bridging
conformant
network,
since
all
the
mac
addresses
are
visible
and
everything
in
this,
these
links
are
essentially
looking
like
they're
they're
ethernet
links
in
the
for
address
mode
transit
through
links
you
really
just
need.
The
distribution
system
is
replaced
by
a
bridging
conformant
network
and
you
have
one
of
those
behind
any
four
address
supporting
aps
and
also
behind
any
stations
that
support
four
addresses.
A
You
can
also
have
classic
aps
tied
in
or,
and
they
can
have
you
know,
multi-crop
links
or
single
end
stations.
Then
you
can
also
have
classic
aps
associated
with
the
four
address
ap.
So
the
four
address
ap
has
also
has
a
backward
compatibility,
so
it
will
support
classic
stations
that
don't
understand
the
four
address
mode.
All
this
shows
everything
is
kind
of
tree-like.
In
fact,
there
could
be
networks
at
the
bottom
of
this
interconnecting
these
various
behind
the
bridge
state
network.
So
you
have
a
whole
other
network
down
there.
A
So,
looking
a
little
more
closely
at,
what's
going
on
between
an
access
point
in
the
stations,
this
four
address,
transit
link
mode
tries
to
treat
the
connect,
the
associations
between
an
access
point
and
various
stations
as
much
as
possible
as
if
they
were
separate
point-to-point
connections.
Even
though
physically
you
have
the
ap
as
a
radio
transmitter
and
an
antenna,
and
when
it
sends
something
out
with
highway
radio,
it
gets
to
all
the
stations.
A
A
It
ends
up
inhibiting
a
port
so
effectively
turns
off
one
of
the
links
by
inhibiting
a
port,
and
unless
you
do
a
lot
of
further
monkeying
around
which
wasn't
done
for
this
standard
spanning
tree
might
cause
the
access
point
to
want
to
inhibit
one
of
these
links
or
more
or
more
of
these
links
down
to
the
stations.
So
it
has
to
sort
of
be
able
to
treat
them
as
separate
ports.
A
So,
for
this
point,
this
transit
link
mode,
even
if
it's
being
used
on
infrastructure
links
like
this,
there
is
a
special
mode
for
multicast.
If
it's
unicast,
it's
pretty
easy.
You
need
to
treat
these
things
because
they
really
are
effectively
point
to
point
with
the
transmitter
redress
and
the
receiver
address
things
just
go
between
between
a
particular.
You
know
antenna
one
antenna
and
another,
so
that
speed
and
the
other
stations
will
ignore
unicast
frames
that
are
not
addressed
to
them.
A
But
if
the
ap
is
sending
a
broadcast
frame
or
multigas
frame,
there's
actually
a
special
form
of
receiver
address,
called
a
synthetic
receiver
address
or
synra
where
it
can
basically
create
a
bitmap
of
which
stations
it
wants
to
go
now.
Of
course,
this
is
a.
This
is
a
encoded
into
a
48-bit
mac
address,
so
there's,
obviously
not
enough
room
in
there
to
actually
have
a
full
bitmap.
If
you
have
enough
stations,
you
have
100
stations
associated
with
an
ap
which
is
certainly
possible.
A
You
can't
do
that,
so
you
either
have
to
have
multiple
synthetic
receiver
address
transmissions
for
different
parts
of
the
bitmap
space,
which
is
essentially
the
space
of
association
identifiers
or
you
can.
You
can
also
use
serial
unicast,
but
that
would
take
a
long
time
if
there
were
a
lot
of
stations.
A
So
that's
how
that
gotten
to
work,
and
similarly
you
could
have
you
know
you
can
have
complicated
cases.
There
could
be
a
multi-destination
source
in
the
network
on
the
right
here
and
it
could
send
when
it
sends
a
frame
out.
It
could
end
up
depending
on
where
the
loop's
been
broken,
either
going
upwards
and
through
the
ap
or
it
can
go
down
at
the
bottom
or
it
could
go
both
ways
and
the
loop
has
to
be
broken
somewhere
along
here
and
to
make
sure
that
the
frame
never
gets
back
to
it.
A
A
Where
you
don't
have,
you
just
have
regular
frames,
the
stations
are
endpoints,
there's
nothing
behind
them,
because
in
that
case,
when
a
station
sends
a
multi-destination
frame
to
the
ap,
the
ap
just
blasts
it
out
to
all
the
stations
and
when
that
station
gets
it
back,
it
does
get
it
back.
But
in
this
case
it's
okay
because
it
can
recognize
itself
as
the
source
address.
A
But
when
you
have
possible
sources
behind
that
station,
it
can
no
longer
use
that
and
it
doesn't
even
doesn't
even
help
to
try
to
remember
them
and
and
discard
an
identical
frame,
because
the
frame
there
can
be
reconfigurations
of
the
network
that
occur
between
sequential
identical
frames.
So
you
can
get
the
same
frame
from
different
directions
and
really
the
ap
just
has
to
know
the
ap
is
what
knows
what's
going
on
and
it
has
to
be
able
to
decide
not
to
send
it
to
certain
stations.
A
So
let
me
talk
a
bit
about
mesh
and
then
all
the
things
we're
talking
about
I
talked
about
before
concentrating
on
infrastructure
mode.
The
the
links
were
not
particularly
symmetric.
I
mean
the
ap
and
the
station
are
really
different
in
a
variety
of
ways.
So
with
a
mesh,
that's
not
particularly
true.
A
They
are
peer-to-peer
and
all
the
mesh
stations
that
can
see
each
other
and
that
have
matching
mesh
profiles
and
appearing
with
each
other
and
mesh
profiles
identified
by
a
mesh
id
which
is,
but
in
binary
the
same
sort
of
thing
as
an
ssid,
both
mesh,
ids
and
ssids
are
just
strings
which
are
32
octets
of
arbitrary
binary
junk.
Of
course,
ssids
are
normally
printable
characters,
but
in
the
protocol
they
can
be
anything
binary,
but
the
ssid
is
not
used
for
mesh,
but
the
mesh
id
is
used
instead.
A
So
it
turns
out
that,
because
of
mesh
came
along
later,
all
mesh
data
frames
are
required
to
be
what
are
called
qos
frames.
So
qos
frames
basically
means
you
support
this
priority
feature
in
nato,
211
and
stuff
like
that,
which
really
almost
all
modern
uses
do.
This
is
one
of
those
things
people
argue
about
in
80-11
is:
when
can
the
support
of
non-qos
frames
that
don't
support
this
be
removed
from
the
standard
and
someday?
A
So
that's
this
extension
fuel
tone
here
which
this
is
number
of
octets
across
the
bottom,
and
this
is
really
sort
of
more
of
the
header.
It
comes
right
after
the
header
I
was
talking
about
and
showing
you
previously,
but
it's
logically
considered
to
be
part
of
the
frame
body
and
the
only
real
difference
that
makes
is
that
it's
a
subject
to
this
hoppy
hop
encryption
over
the
air,
which
is
just
easier
to
implement
that
way.
So
what
are
these
different
fields
in
here?
A
The
mesh
flags
are
really
just
used
to
indicate
whether
the
addressing
extension
fields
are
there
or
not.
Ttl
is
as
a
true
ttl
within
the
mesh,
and
this
is
unusual.
802
generally
does
not
have
ttls
they've
added
an
optional
one
in
ethernet
and
even
an
optional
ethernet
header
recently,
but
at
least
it
used
to
be
the
attitude
nato
too,
that
if
your
protocol
needs
a
ttl,
it's
broken,
that's
that's
what
they
thought.
A
So
that's
kind
of
their
particular
thinking,
but
mesh
has
mesh
in
it.
Wi-Fi
has
always
had
a
ttl
from
the
start
and
then
there's
this
mesh
sequence
number,
so
the
first
mesh
node.
If
it's
sourced
inside
the
mesh,
then
it's
the
the
place
where
the
frame
is
sourced.
If
it
comes
from
outside
of
the
mesh
go
through
the
mesh
and
the
first
mesh
node,
it
hits
adds
a
sequence
number
to
it.
A
So
these
these
this
address
extension
column
on
here.
Fourth
column.
Is
these
bits
in
the
mesh
flags?
And
so
the
simplest
case?
Let's
say
we
have
a
mesh
data
frame.
A
unicast
frame
is
all
internal
to
the
mesh,
so
as
it
hops
along
in
the
general
case,
there's
the
receiver
and
transmitter
there's
also
the
source
of
destination
in
the
source
destination
in
the
mesh.
You
don't
need
anything
else.
It
uses
four
addresses
to
hop
along
there
somewhat
like
the
transit
link
case,
but
this
is
the
peer-to-peer
mesh
case
the
other
hand.
A
If
the
frame
originated
or
terminates
outside
of
the
mesh,
then
you
need
more
some
more
information.
It
has
the
receiver
and
transmitter
on
each
hop.
It
also
has
the
the
mesh,
the
final
mesh
node,
the
mesh
destination
address
and
the
first
mesh
node
the
mesh
source
address,
but
if
these
are
out
from
or
to
outside
the
mesh,
there's
also
the
true
original
destination
source
outside
the
mesh
and
the
final
ultimate
destination
outside
the
mesh.
A
So
in
this
case,
the
receiver
addresses
can
be
the
ultimate
destination
address,
because
it's
this
really
a
multicast
group.
You
just
delete
the
transmitter
and
the
source,
so
if
it
is
originated
inside
the
mesh
and
the
next
to
the
bottom
line
case,
and
actually
in
that
case
you
can
actually
omit
the
fourth
address.
A
It
just
needs
three
addresses
in
that
case,
and
if
it's
originated
from
outside
of
the
mesh,
then
you
need
to
have
a
not
just
only
a
mesh
source
address,
which
is
the
first
node
in
the
mesh
that
the
frame
hit,
but
also
on
the
ultimate
source
address
so
in
in
the
general
case,
these
mesh
frames
have
six
addresses
in
them
all
mac
addresses
all
48
bitmappings,
all
layer.
Two,
so
you
know
here's
some
ones.
I
don't
know
that
I
want
to
go
through
these
all
in
detail,
it'll
be
a
little
tedious.
A
So
in
this
case,
if
you
have
one
going
from
14
to
four
it's
14
to
one,
this
is
the
wired
ethernet
and
doesn't
I
don't
have
a
line
for
that,
but
from
one
to
four
it
says
a
source
address
outside
the
mesh,
but
the
mesh
source
is
one,
and
in
this
case
the
transmitter
is
also
one
and
then
you
have.
Everything
else
is
four
for
the
receiver
and
the
last
case
is
one
going
from
14
to
12.
A
So
it
goes
through
the
mesh
and
it
shows
via
some
via
three
and
six,
and
this
shows
all
the
different
states
it
goes
through.
So
you
have
to
it's
a
loop
prevention
sort
of
handled
in
somewhat
different
ways
in
different
regimes.
If
you
have
this
mesh
in
the
middle
layer,
two
mesh
and
whether
you
have
a
the
outsides
are
connected
into
one
larger
network,
then
this
is
all
layered
too.
I
assume
they're
no
intervening
ip
routers.
Then
that's
the
first
two
points
here.
A
This
multicast
distribution
by
this
sort
of
flooding
it
and
discarding,
duplicates
as
it
goes
along
if
you're,
considering
a
larger
layer,
two
which
incorporates
the
mesh
the
mesh
will
just
appear
to
be
a
simple
link
in
it.
So
in
this
larger
network,
their
standard
short
loop
prevention,
algorithms,
expanding
trees
alike
will
break
the
loops
and
of
course,
if
you
get
further
out
to
ip
routers
like
that,
terminates
the
layer
two
fabric,
so
to
speak
whatever.
A
A
A
A
A
A
A
A
C
A
C
C
A
C
A
C
Configuring,
a
ethernet,
switch,
compare
configuring
an
ethernet
switch,
an
unmanaged
ethernet
switch
with
configuring,
an
ip
router.
So
I
think
that
the
original
sin
of
us
layer,
3
people,
is
that
we
made
configuration
uselessly
complicated
and
that's
how
I
got
interested
in
the
helmet
project
in
the
whole
networking
group.
So
the
reason
I'm
at
itf
today
is
that,
10
years
ago
some
wise
people
told
me
go
and
look
at
helmet.
It's
interesting.
C
Unfortunately,
helmet
appears
to
be
morobund
now,
but
I
still
think
that
the
basic
idea
of
preventing
of
allowing
people
not
to
root
at
layer
three
at
layer
two
by
giving
them
easier
configuration
at
layer.
Three
is
a
sound
one
and
the
other
reason
why
people
want
to
do
routing-
and
that's
very
relevant
for
wi-fi-
is
that
if
you
do
your
routing
at
layer
2,
then
you
get
mobility.
You
get
roaming
between
access
points
for
free,
okay,
one
thing
that.
C
A
C
C
C
C
A
A
Come
calling
in
and
people
should
comment
on
the
mailing
list
whatever,
and
you
know
we
can
see
you
at
the
next
ietf
meeting.
I
guess
and
we
if
we
have
a
topic
for
which
we
want
to
make
more
rapid
progress
in
discussions
in
the
interim.
We
can
can
schedule
interim
meetings
before
then,
but
so
thanks
everybody
and
talk
to
you
later
and
see
you
on
the
mailing.