►
From YouTube: IETF114-MANET-20220729-1400
Description
MANET meeting session at IETF114
2022/07/29 1400
https://datatracker.ietf.org/meeting/114/proceedings/
A
A
All
right,
good
day
welcome
to
the
joint
session
of
babel
roll
and
man
a
on
multicast
routing
next
chart.
Please.
A
You've
probably
all
seen
this,
but
just
to
highlight
the
note
well
again,
and
so
you
agree
to
follow
the
itf
processes
and
policies
and
you're
aware
of
the
patent
policy
and
you
as
a
participant.
You
agree
to
work
respectfully
with
others
and
please
take.
If
you
have
any
questions
or
concerns
about
this,
you
can
take
that
up.
All
right
next
chart.
A
So
the
meeting
tips
everybody
here
should
know
how
to
to
sign
in
and
track
the
attendance
and
remote
people
as
well
make
sure
your
audio
and
video
is
off.
Unless
you
are
are
speaking
and
if
you're
a
speaker,
a
headset
is
recommended,
but
we
did
the
audio
test
with
some
people
that
didn't
have
that
so
you're,
okay.
A
A
The
resources
for
this
session
have
all
been
uploaded,
the
usual
places,
and
if
you
would,
we
could
use
some
help
with
the
take
note-taking
when
people
are
speaking.
If
you
could
do
that
next,
all
right,
I'm
going
to
pass
this
over
to
ronald
who's,
going
to
talk
about
the
the
agenda
part
here.
B
B
Yeah
we
have
a
joint
session
with
a
topic,
multicast
and
I'll
give
a
short
introduction,
and
then
we
go
into
a
number
of
presentations.
B
After
that
we
have
some
time
for
discussion
and
we
try
to
reach
some
form
of
a
conclusion
after
that
and
see
if
there
needs
to
be
any
follow-up
activity
to
this
and
what
form
that
may
take
so
after
the
presentations
are
done,
you're
all
invited
to
voice
opinions,
point
out
deficiencies,
whatever
you
want
to
do,
and
then
we
wrap
up
the
the
multicast
part
of
this
session
and
as
a
by
the
way
by
the
way
of
desert.
B
B
B
The
routing
ids
have
seen
that
multicast
was
discussed
in
various
forms
in
all
three
of
the
working
groups,
but
that
not
much
progress
was
made
now.
Whether
all
of
you
agree
with
that,
I
think
it's
true
for
monet,
but
I
cannot
judge
for
the
other
groups,
but
that's
also
something
that
can
come
up
in
the
discussion.
B
Today's
presentations,
given
by
participants
in
all
of
the
three
working
groups,
should
make
clear
what
the
challenges
are
why
this
is
not
multicast,
as
we
know
it
in
the
maybe
in
the
wired
network
and
what
can
be
done
about
it
and
if
there's
anything
that
the
three
groups
have
in
common
that
they
can
work
on.
B
So
the
last
time
that
monet
working
group
was
recharged
was
in
2016.
A
B
Justin
dean
at
the
time
the
chair
of
the
my
neighbor
group
gave
at
itf
96.
B
B
It's
not
really
a
full
protocol
description.
It
basically
describes
mechanisms
for
duplicate
packet
detection.
Why
that
is
needed.
We
will
see
later.
It
also
has
three
different
so-called
relay
set:
selection,
algorithms
or
really
set
reduction.
Algorithms,
if
you
want,
which
are
described
in
appendices
and
these
make
use
of
information-
that's
already
available
from
a
unicast
routing
protocol
monet
rather
than
protocol
to
reduce
the
number
of
nodes
that
are
retransmitting
packets.
B
There
was
also
some
other
work
that
has
been
abandoned,
the
only
multicast
routing
protocol-
and
it
was
worked
on
by
brian
adamson,
from
naval
research
lab
on
elastic
multicast
routing,
and
this
was
a
protocol
that
tried
to
have
multicast
group
membership
awareness
in
the
routers
at
certain
points
in
the
network
in
mobile
networks
that
were
somewhat
more
stable,
where
there
was
not
that
much
topology
change
and
there
it
could
be
more
effective
to
use
that
this
was
presented
only
once
during
itf
88
in
vancouver.
B
This
has
some
implications
for
some
existing
multicast
protocols
or
mechanisms
that
do
not
allow
to
have
the
incoming
interface
in
the
outgoing
interface
list
or
that
try
to
do
a
reverse
path.
Forwarding
check
based
on
interface
and
then
there's,
of
course,
the
node
mobility.
That
leads
to
frequent
topology
changes,
and
it's
thought
that.
B
Maintaining
group
membership
on
all
the
intermediate
nodes
causes
too
much
turn
because
it
has
to
be
updated
all
the
time
and
hence
smart
flooding
approaches
are
used,
but
this
is
for
me
an
important
slide
because
it
shows
most
general
link
model.
B
We
have
a
host
where
transport,
layer
and
application
layer
protocols
are
running,
we
have
a
router
and
we
have
a
radio
separate
entities
possibly
connected
by
ethernet.
Of
course
you
can
collapse
this.
B
Of
course
you
can
have
a
single
laptop
running
your
routing
protocol
in
software
and
using
wi-fi
as
your
radio,
but
this
is
the
most
general
model
and
this
should
be
supported
by
our
solutions,
and
you
can
see
here
the
note
in
the
middle
relays
node
b
and
if
it
does
that
for
an
a
packet
that
started
this
live
somewhere
in
node
a
node.
A
is
also
going
to
hear
the
retransmission
again
next
slide.
Please.
B
B
A
B
C
So
I
caution
us
to
be
careful
with
this
assumption.
C
B
So
a
question
that
has
come
up
a
couple
of
times:
do
we
actually
need
multi-hope
multicast
at
the
ip
layer
and
in
some
of
the
previous
monet
sessions
at
previous
itfs,
particularly
rick
taylor
has
commented
on
this.
B
There's
another
technique,
synchronized
collaborative
broadcast
roughly
equivalent
to
so
this
is
something
called
barrage
relay,
but
that's
a
trademark
of
a
company
called
trellisware,
and
that
that's
true,
of
course,
but
what
if
you
have
an
ip
overlay
over
heterogeneous
radio
technology
or
what,
if
you
want
to
federate
monet
networks
that
use
different
technologies
next
slide?
Please!
B
Well,
then,
you
get
into
things
like
this
here:
the
nodes,
a
and
e
both
have
two
radios,
so
they
have
one
lag
in
one
of
the
radio
technologies
and
another
lag
in
the
other
radio
technologies,
and
you
can
see
that
this
can
lead
to
interesting
forwarding
complications
where
things
go
looking
around
and
again,
a
solution
should
be
able
to
deal
with
this
next
slide.
Please.
B
B
For
instance,
the
linux
kernel
doesn't
really
support,
multicast
forwarding
and
over
the
same
interface
and
all
sorts
of
this,
but
that's
really
hennig's
presentation.
That's
coming
next,
that's
going
into
that
packets
are
disseminated
to
the
entire
monet,
there's
no
knowledge
of
group
membership
because
that's
considered
too
much
turn
the
relay
set.
Selection,
algorithms-
and
this
goes
back
to
the
previous
slide-
do
not
support
multiple
interfaces.
B
There
also
some
some
circumstances
where
it
does
not
very
well
work
very
well.
If
you
have
multiple
interfaces.
B
They
they
sort
of
stepped
away
from
the
itf
and
the
money
working
group,
but
they
have
been
continuing
their
work.
B
B
However,
this
has
been
outside
the
visibility
of
the
monet
working
group
for
for
some
time
and.
A
B
A
We
have,
we
have
a
person.
Thank
you.
E
D
E
Or
jeffrey
from
juniper,
okay
cindy
is
going
to
present
beer
in
babel
networks.
Later
looking
at
the
properties
of
monet,
you
talk
about.
It
seems
that
beer
would
be
a
good
fit
for
this
as
well,
especially
when
you
talk
about
multicast
ip
layer
over
heterogeneous
hydrogen,
generous
radio
types.
B
B
I
hope
that,
during
the
discussion,
david
will
come
up
to
the
microphone
and
give
his
opinion,
but
thanks
yeah,
it's
something
that
I
personally
don't
know
enough
about.
At
the
moment,
I'm
trying
to
wrap
my
head
around
a
beer,
but
others
have
looked
at
it
and
seemed
to
think
that
it
might
be
a
solution,
so
we
need
to
need
to
do
some
work
at
least
there.
Thank
you.
A
F
It's
not
something.
We
talk
about
a
lot
in
the
ietf,
but
we
are
talking
about
protocols
the
control
plane,
but
one
of
the
problems
of
ip
multicast
is
always
the
data
plane
is.
It
has
always
been,
and
I
think
this
is
the
reason
why
we
don't
have
that
much
work
for
multicast.
So
next
slide,
so
I
will
be
talking
only
about
ip
multicast
routing
on
linux.
I
don't
know
enough
about
bsd
and
especially
about
windows,
so
this
is
linux
only
at
the
moment.
F
Next,
what
we
have
been
doing
over
the
years
yeah,
we
have
been
doing
multicast
forwarding
in
user
space.
Next
raw
sockets,
everybody
loves
rock
circuits.
At
least
everybody
uses
raw
sockets,
as
I
think
I
know
three
smf
implementations.
All
of
them
are
using
to
some
kind
raw
socket.
Next,
the
good
thing
is
it
works.
You
can
do
multicast
forwarding
with
raw
sockets,
but
it
doesn't
play
nice
with
the
other
complicated
stuff
of
the
linux
networking
code,
some
raw
sockets,
don't
like
firewalls
and
ignore
them.
Some
raw
sockets
have
trouble
with
policy
routing.
F
So,
yes,
we
have
a
solution.
So
next
one
time,
tab,
interface,
that's
always
if
someone
says
raw
sockets,
I
normally
say
use
tun
tap.
Next,
the
advantage
is
it's
a
real
interface.
It's
easy
to
integrate.
The
disadvantage
is
how
to
get
the
traffic
into
the
ton
tab
interface.
So
we're
talking
again
about
how
to
do
some
multicast
forwarding,
which
makes
everything
more
complicated
and
it's
still
user
space.
So
it's
not
that
much
better
and
it's
more
work
to
do.
D
F
What
we
want
to
do
is
doing
multicast
forwarding
in
kernel
space.
It's
a
matter
of
performance,
especially
if
we
have
not
that
much
hardware
lifting
up
everything
into
user
space
is
really
not
that
great.
We
would
like
to
do
it
with
like
unicast
traffic.
Just
let
the
corner
do
its
stuff.
Next
and
yes,
ip
multicast
routing,
it
has
been
part
of
linux
forever.
It
works
it's
fast.
It's
integrated,
it
plays
nice,
but
it
doesn't
work
for
our
use
case.
F
It
has
been
done
for
multicast
routing
between
ethernet
segments,
and
so
it's
not
the
solution
we
are
normally
looking
for
next,
so
is
it?
Has
someone
looked
into
the
linux,
multicast
routing
and
the
new
new
shiny
stuff?
We
got
over
the
last
decade
or
something
like
this.
I
must
admit:
I've
looked
into
it
not
for
years
and
then
last
last
week
I
started
looking
to
it
again.
So
next,
what
what's
trouble?
F
There
are
four
points
that
making
multicast
are
difficult
for
us,
re-transmission
on
the
same
interface,
selective
forwarding,
local
traffic
and
suppressing
duplicates
next,
so
re-transmission
on
the
same
interface
I
tested
this
a
week
ago.
It
seems
to
work.
I
don't
know
when
they
changed
the
kernel
code,
but
I
used
a
static,
multicast,
forwarding
daemon
and
I
could
send
out
multicast
traffic
kernel
based
on
the
same
interface
again
earlier
kernel
versions
years
ago.
Just
said:
no,
that's
not
allowed,
so
it
seems
at
least
this
problem
was
solved
a
long
time
ago.
F
So
yeah
depend
sometimes
we
don't
want
to.
We
want
to
deal
with
incoming
multicast
differently,
depending
on
what
was
the
last
node
who
sent
us
so
to
improve
the
efficiency
of
the
forwarding
a
little
bit.
F
F
F
The
idea
is
that
the
local
application
should
know
which
interface
to
use,
which
is
bad
if
you
have
multiple
radio
interfaces
so,
but
we
could
change
this
today,
there's
something
called
virtual
ethernet
devices.
So
it's
just
like
a
pair
of
interfaces
you
put
in
all
local
traffic
into
one
end
and
it
comes
out
of
a
real
interface.
So
you
move
the
problem
from
local
traffic
to
interface
to
interface.
Hey
that's
easy
done!
Next!
F
Suppressing
duplicates
yeah
because
of
radio
transmissions
and
this
non-transitivity
we
often
get
the
same
packet
multiple
times,
because
it's
transmitted
from
multiple
neighbors
and
we
need
to
filter
this
out.
So
we
need
custom
code
in
the
kernel
and
nobody
likes
to
write
or
even
maintain
a
linux
kernel
module.
This
is
hard
work
really
hard
work
yeah.
So
what
can
we
do
next
wait
a
moment
what
was
about
new
toys?
F
There's
something
called
ebpf
for
a
number
of
years
extended
or
enhanced
berkeley
packet
filters.
It's
some
kind
of
virtual
machine
in
the
linux
kernel.
You
can
push
for
some
functions.
You
can
push
code
into
the
kernel
and
do
some
custom
custom
stuff.
Without
writing.
Kerner
module
and
there's
xdp
express
data
path.
We
don't
need
to
express
paths,
but
xdp
can
be
attached
to
interfaces
and
do
some
logic
based
on
an
ebpf
program,
for
example,
deciding
to
drop
packets
that
are
incoming
or
maybe
modify
them
or
redirect
them
to
a
different
interface.
F
F
F
So
this
could
be
a
way
to
completely
do
the
whole
forwarding
chain
inside
the
linux
kernel
without
writing
new
kernel
code
because,
from
my
point
of
view,
writing
a
new
kernel
module
just
for
marnet.
I
don't
think
this
is
feasible.
Most
likely
the
module
will
either
be
not
accepted
or
will
age
badly.
G
Davilan
potter
things
so
first
there
is
specific
reasons:
the
linux
kernel,
multicast,
routing
api.
H
G
Not
suited
for
magnets
because
it's
designed
to
deal
with
consistent
broadcast
domains,
so
it
was
never
intended
to
deal
with
cases
where
you
have
a
disjoint
network
like
this,
and
the
fact
that
you
can
now
use
it
for
a
money,
because
the
iif
equals
oaf
restriction
was
removed,
doesn't
make
it
a
good
tool
that
restriction
was
there
for
a
purpose
in
the
beginning,
because
if
you
have
actual
broadcast
domains,
the
only
thing
that
that
will
ever
achieve
is
create
loops
and
I'm
missing
considerations
here.
G
What
else
will
break
by
transferring
this
tool
that
was
designed
for
broadcast
networks
to
this
new
scenario
that
it
very
much
was
not
designed
for
that's
the
one
thing.
The
other
thing
that
I'm,
that
we
kind
of
skipped
over
in
in
the
sequence
of
discussion
here
is
duplicate.
Detection
may
sound
necessary,
but
it
is
in,
in
my
opinion,
fundamentally
never
the
correct
thing
to
do
so.
Not
only
will
you
run
into
scaling
problems
as
soon
as
you
get
larger
amount
of
multicast
traffic.
G
It
becomes
a
question
of
timers
relative
to
to
each
other.
If
your
duplicate
detection
is
faster
in
quotation
marks
than
the
protocol
using
it,
then
it
works,
but
that's
ip
forwarding
is
not
supposed
to
remove
duplicates
in
in
general,
and
this
also
applies
to
multicast
routing
I'm
I
I
very
strongly
would
would
argue
that
the
solution
should
not
cannot,
must
not
contain
duplicate
elimination,
and
I
think
that's
it.
For
now.
I
have
more
comments
later
so
yeah.
F
I
G
F
B
Okay,
julius.
C
D
C
C
If
we
have
a
good
idea,
if
we
know
what
we
want
the
kernel
to
do,
and
if
that
is
something
that
does
not
depend
on
the
rooting
protocol
and
can
get
into
the
kernel,
it
will
no
longer
be
custom
code,
it
will
be
general
code,
and
our
problem
here
is
that
we
currently
I
mean
david,
hinted
to
the
opposite
of
what
I'm
going
to
say.
But
our
problem
is
that
we
don't
have
a
good
idea
of
what
it
is
that
we
want
the
what
general
forwarding
the
kernel
needs
to
do
for
our
needs.
F
Yes,
it
would
be
nice
to
have
some
better
user
plane
in
the
kernel.
I
definitely
agree,
but
I
vary
that,
depending
on
what
kind
of
network
we
are
talking
about,
we
need
different
solutions.
We
will
need,
for
example,
if
we
have
a
high
data
rate,
wi-fi
network,
we
might
deploy
something
very
differently
than
when
we
have
a
vhf
uhf
network
that
has
two
different
interfaces,
with
two
orders
of
magnitude:
different
capabilities.
F
So
at
the
moment
we
don't
really
know
that
well
what
we
need,
which
will
will
make
it
difficult
to
go
to
to
propose
a
new
kernel,
module,
write
it
and
get
it
accepted,
because
maybe
a
few
years
later
we
say:
oh,
we
need
something
else
again.
C
F
D
J
Donald
east
lake
future
weight
technology,
just
a
real,
quick
thing
that
obviously
duplicate
detection
can't
just
be
based
on
the
packet
but
has
to
be
based
on
where
it
entered
the
mesh
and
a
sequence
number
applied
at
that
point,
so
that
you
can,
if
you
sometimes
you're
supposed
to
have
two
packets
that
are
binary,
identical.
K
I
think
it'd
be
really
helpful
to
talk
about
how
not
only
end
hosts
fit
into
the
solution
being
discussed,
but
also
routers,
and
how
you
fit
into
a
wider
routed
network,
and
you
know,
looking
at
I've
been
I'm
coming
at
this
from
like
the
raw
perspective
and
in
there
the
wireless
network
is
just
part
of
a
larger
network
and
one
of
the
things
I've
been
grappling
with
is
how
do
you
integrate
your
your
all
your
routing
information
and
make
it
so
that
the
the
unique
properties
of
your
manet
are
like
constrained
to
the
man
a,
but
you
can
also
pass
through
your
transit
routes
and
on
in
this
discussion
in
this
presentation
and
I'm
willing
to
bet
in
the
future
ones,
although
it'll
be
interesting
to
hear
in
the
future
ones
really
interested
in
how
you
fit
into
a
routed
network,
as
opposed
to
just
the
routed
monet
that
connects
hosts
thanks
and
if
you
want
to
talk
about
that,
for
what
you've
presented
that'd
be
useful.
F
Yes,
I
I
would
say
we
are
the
transit
routes,
always
for
unicast
and
for
multicast
get
things
more
complicated
and
we
don't
even
know
how
to
deal
within
the
radio
domain
with
the
multicast.
We
should
not
forget
external
networks,
both
just
attach
networks
and
transit,
but
if
we
don't
have
a
date,
a
good
data
plane
to
experiment
with,
then
we
have
trouble
even
finding
out
what
we
need.
L
Rick
rick
taylor.
Thanks
for
the
presentation
henning,
I
I
I
do
like
your
research,
it's
very
interesting,
a
big
fan
of
ebpf
and
the
cool
stuff
you
can
do
with
the
linux
kernel,
and
it's
just
a
small
question.
I
have
is
it's
great,
that
these
are
tips
and
tricks
that
can
help
us
build
a
data
plane
in
order
to
prototype
and
work
out
some
of
the
protocols.
I
I
actually
kind
of
think
here
in
manet
we
have
the
bandwidth
really
to
look
at
what
those
protocols
should
be.
L
Following
on
from
lou's
comment,
I
need
a
multicast
domain
that
spans
some
of
my
fixed
infrastructure.
That
may
be
not
just
that
one
laptop
connected
to
the
router
connected
to
the
radio,
but
that
might
actually
be
a
small
sub-area
network.
I
there
will
be
backhaul
into
the
fixed
infrastructure
that
heterogeneous
network,
of
which
some
segment
is
one
or
more
radio
systems
going
back
to
ronald's
original
diagram
earlier
on,
I
think,
is
probably
more
relevant
for
the
working
group
than
how
do
we
beat
linux
into
submission.
L
Don't
get
me
wrong
it's
great
stuff,
but
I
just
want
to
pull
it
back
to
a
bit
more
of
an
idea.
Focus
sorry
talking
about
duplicate.
L
L
They
are
doing
a
lot
of
duplicate
packet,
elimination
anyway,
based
on
information.
They
have
from
the
from
the
radio
subsystem
and
I
think
it,
the
naive
approach
of
not
deduplicating
is
actually
the
correct
way
to
go.
So
I'm
a,
I
say
naive,
but
it's
actually
the
right
thing
to
be
doing.
If
l,
if
the
lower
layer
says
I've
got
two
packets
that
are
as
far
as
you're
concerned
are
identical,
what
is
the
ip
layer
to
do?
L
F
I
don't
think
layer
2
can
help
us
there
just
as
a
personal
command,
because
you
can
push
everything
we
do
down
to
layer,
2.
Of
course,
then
we
need.
Then
someone
else
needs
to
solve
the
problem,
but
that's
not
always
helpful,
especially
with
my
radios.
L
My
quick
response
and
then
I'm
going
to
shut
up
and
sit
down.
This
has
always
been
the
problem
with
the
with
the
many
working
group
we
we
live
within
the
ietf,
we're
supposed
to
be
layer,
3
ip
focused,
but
many
problems
often
exist
at
layer
2
as
well,
and
I'm
really
interested
in
what
donald's
going
to
tell
us
about
what's
happening
in
80
to
11,
because
for
the
link
there
really
that
shouldn't
be
in
the
scope,
but
we
all
try
and
solve
these
many
problems
in
as
a
general
thing.
J
Hi
there
I'm
donald
eastlake
with
future
way
technologies.
I
was
actually
chair
of
the
80211
mesh
task
group
for
the
first
half
of
its
existence
next
slide.
So
I
I'll
try
to
go
through
these.
The
first
slides
are
pretty
quick
that
you
can
read
them
at
your
leisure,
but
basically
eleven
is
very
complex.
Standard
got
all
kinds
of
stuff
in
it.
Get
your
own
copy
read
all
four
thousand
pages.
If
you
feel
like
it,
it's
very
widely
deployed.
J
It's
got
all
kinds
of
things:
you've
probably
never
heard
of
and
operates
in
all
kinds
of
different
spectrums
and
different
control
paradigms
and
stuff
like
that
it
huge
number
of
chipsets
per
year.
So
it's
worth
doing
the
effort
to
make
improvements
in
them,
because
the
cost
of
the
engineering
gets
spread
over
a
large
number.
J
J
It's
got
fragmentation
and
aggregation,
multiple
levels
of
aggregation
and
mostly
talk
about
the
infrastructure
mode
and
mesh
next
slide.
Please
now
skip
some
of
this,
so
this
is
what
a
data
frame
looks
like
in
80,
11.
8211
believes
in
a
complex
header
with
extensions
rather
than
layering.
J
It's
it's
all
layer,
two
in
a
sense,
but
you
could
still
imagine
ways
of
doing
this
with
nested
stuff
over
there
on
the
right.
The
next
to
the
last
thing
is,
there's
actually
some
data
there's
a
frame
body-
I
don't
know
and
then
there's
the
frame
checksum,
but
there's
space
for
lots
of
addresses,
and
these
are
all
48-bit
mac
addresses
and
the
left
hand
is
the
frame,
control
and
the
bottom
shows
frame
control.
J
They
all
have
a
version
type
and
subtype,
but
what
the
raining
bits
are
depends:
there's
data
type
data
frames
and
control
flames
and
management
frames
and
action
frames
and
multi-hop
management
frames,
and
on
and
on
and
on
matter
of
fact,
the
ran
out
of
types
and
subtypes.
So
there
are
things
with
protocol
version
zero,
one,
not
because
it's
really
a
new
protocol
because
they
ran
out
of
types
and
subtypes.
J
Next
frame
the
next
slide,
so
this
is
the
classic
infrastructure.
Ess
you
got
a
it's
just
called
the
distribution
system
in
the
standard
it's
very
vaguely
described,
so
you
can
instantiate
it
in
many
different
ways.
Access
points
stations
associated
with
that
extended
service
set,
as
this
whole
thing,
where
the
stations
can
all
talk
to
each
other
as
if
they
were
local
to
each
other
within
the
same
ssid
next
slide.
J
So
the
ap
is
beacon
periodically.
It
could
be
any
time,
but
actually
it's
always
100
milliseconds
for
normal
cases,
and
that
includes
their
capabilities.
Ssid
and
the
stations
associated
with
the
access
point,
negotiate,
pairwise
keying
and
the
access
point
pushes
down
a
group
key,
so
the
access
point
can
send
multicast
are
broadcast
and
all
the
associated
stations
will
be
able
to
receive
it.
J
There
are
these
four
logical
addresses
the
real
source
of
original
source
final
destination
and
the
actual
transmitter
and
receivers
address
and
I'll
skip
over
the
the
unicast
case,
but
for
multicast
at
the
bottom
there.
If
it's,
the
multicast
source
is
actually
the
ap
itself
is
sending
it
or
behind
the
ap.
Then
the
ab
you
can
just
multicast
it
because
it
can
set
the
receiver
address
to
be
the
same
as
the
multicast
destination
address
and
all
the
stations
will
happily
listen
to
that.
J
If
you
send
them
multicast
from
a
individual
station,
it
gets
unicast
to
the
access
point
which
then
so
it
has
in
at
the
multicast
destination,
but
it
uses
the
access
points
receiver
address
and
then
it
gets
multicast
by
the
access
point
down
to
the
stations,
and
that
means
the
station
does
get
the
multicast
that
it
sent
back
to
itself.
It
receives
it
again,
but
it
can
tell
because
it
has
its
own
address
as
the
source
address
in
that
frame.
J
So
it
doesn't
have
any
problem,
because,
even
though
this
is
something
that's
a
violation
of
the
ethernet
axiom
that
when
you
send
a
packet
a
frame,
you
never
get
it
back,
but
as
long
you
can
tell
when
it'll
drop
it.
It's
easy
enough.
Next
slide,
please!
J
So
how
does
it
get
reliability?
Unicast
stuff?
It
usually
uses
link
level
acknowledgment
and
retransmission,
but
of
course
things
go
wrong.
Acts
are
lost,
you
might
re-transmit
when
you
didn't
need
to,
and
so
on
and
so
forth,
so
there's
a
sequence
number
and
when
it's
fragmented
as
a
fragment
number
as
well,
so
you
can
always
tell
if
you
got
something
more
than
once
and
of
course,
eight
or
two
eleven
is
you're,
talking
a
single
hop
and
it's
there's
a
goal
is
a
maximum
distance
of
100
meters
and
stuff.
J
The
timing
is
sort
of
constrained,
so
you
can
figure
out
a
reasonable
number
range
and
stuff
for
multicast.
There's
got
all
kinds
of
things
in
there.
People
frequently
complain
about
the
unreliability
of
multicast
native
211,
but
really
anything
you
can
think
of
as
a
reasonable
way
to
make
multicast
more
reliable
has
probably
already
been
put
into
the
standard.
Now
whether
it's
implemented
and
widely
deployed
is
a
whole
other
question,
but
sometimes
people
say
multicast
is
always
sent
at
the
lowest
possible
rate.
That's
not
true.
You
can
tell
the
access
point.
J
Whatever
rate
you
want
to
send
it
at.
If
it's
discovery
you
might
want
to
send
it
at
a
pretty
low
rate,
but
it's
for
data.
You
could
send
it
at
just
the
what
rate
you
think
is
necessary
for
the
most
remote
station
or
something
like
that.
You
can
have
unsolicited
re-transmissions,
where
the
the
thing
gets
transmitted
multiple
times,
and
you
just
depend
on
the
duplicate
detection
and
that
more
likely
to
get
through.
You
can
go
through
and
pull
every
station
to
see
if
it
received
that
multicast
frame.
J
Of
course,
this
uses
up
a
lot
of
air
time
and
kind
of
loses
a
lot
of
the
advantage
of
multicast.
But,
of
course,
there's
a
feature
where
you
can
send
a
bunch
of
multicast
frames
and
then
pull
the
stations
for
a
block
of
acknowledgements
and
see
which
stations
missed.
What
and
because
the
receiver
address
and
the
destination
address
are
separate.
You
could
go
through
and
serially
unicast,
which
also
eliminates,
of
course,
a
lot
of
the
advantage
of
multicast
and
is
useless
if
you're
trying
to
do
discovery
next
slide.
J
And
that
way,
all
this,
that
all
the
stations
beacon
and
they
they
just
send
directly
to
each
other
and
in
some
weird
mode
you
might
think
of
it
as
a
one-hop
meshes
and
in
in
that
case,
you
really
sort
of
only
need
two
addresses,
because
in
every
case
the
source
address
and
the
transmitter
address
are
the
same
and
the
receiver
address
the
receiver
address
and
the
destination
address
are
the
same,
but
the
header
still
has
three
fields
and
the
third
field
is
this
basic
service
set
id,
which
is
how
the
ad
hoc
network
kind
of
is
identified
and,
of
course
it
may
not
be
full
connectivity,
it's
not
very
reliable,
but
if
you
want
to
send
multicast,
it's
easy,
you
just
send
multicast
and
everybody
can
hear
you
gets
it
and
those
that
happen
not
be
able
to
hear
you
don't
next
slide.
J
So
there
is
this
fourth
address
in
the
header
which
is
optional.
So
why
is
that?
There
there's
been
various
proprietary
uses.
The
current
starting
they're
sort
of
two
standardized
uses,
one
is
the
general
link
feature
and
the
other
is
mesh.
The
general
link
basically
has
the
idea
you're
sending
something
through
a
station
across
an
8
or
2
11
linked
through
another
station,
and
so
the
source
transmitter,
receiver
and
destination
address
are
all
separate
and
they
could
all
be
there.
It
would
all
typically
be
different.
J
So
if
you
go
back
one
slide
for
just
a
sec,
you
can
in
fact
under
the
in
the
standard.
You
can
do
this
ad
hoc
thing
and
you
can
make
all
those
radio
links
be
general
links
and
if
you
did
that
there
could
be
arbitrary
networks
behind
each
of
these
stations.
Of
course,
the
connectivity
in
the
middle
would
still
have
this
flaky
one-hop
pseudo-mesh
thing
so,
but
if
you
you
could
do
that.
J
Anyway,
you
can
also
use
general
link
in
the
infrastructure
white
case,
in
which
case
you
have
an
access
point
and
associated
stations,
and
you
can
have
a
network
behind
the
station
anyway.
So
the
initial
idea
for
mesh
was,
it
was
just
going
to
be
used
for
wireless
backhaul
people
like
to
limit
the
charter
scope
initially,
so
all
the
mesh
points
mesh
stations
would
be
access
points
might
not
actually
have
any
stations
associated
with
them.
J
So
it's
somewhat
of
a
pointless
restriction,
but
it
might
look
something
like
this,
where
some
access
points
can
only
get
back
to
the
distribution
system
through
other
access
points
next
slide,
but
fairly
soon,
the
mesh
gut
idea
got
generalized
and
people
decided.
It
really
should
be.
Look
like
more
of
a
a
disc.
It
looks
like
a
link
from
the
outside,
so
the
idea
here
is
this:
this
packet,
our
frame,
actually
goes
through
the
mesh
along
the
solid
line
and
the
dotted
lines
or
other
radio
pairings
between
mesh
stations.
J
So
in
mesh
all
the
stations
send
beacons
periodically
and
there's
they
included
that
their
mesh
profile,
which
is
a
mesh
id.
It's
like
the
ssid
but
different.
They
also
indicate
what
protocol,
what
path
selection
protocol,
otherwise
known
as
routing
protocol
they're
using
the
path,
metric,
cipher,
suites
et
cetera,
et
cetera,
and
they
appear
it's
an
equal
pair
of
equals
between
them
and
negotiate.
Pairwise
keying
and
each
station
distributes
to
its
peers.
J
The
group
key
that
it
uses
if
it
wants
to
transmit,
multicast
or
broadcast
and
from
the
outside
world
that
the
whole
mesh
just
looks
like
a
layer
two
link.
So
you
generally
have
six
addresses
the
original
source,
the
final
destination,
the
mesh
source,
which
is
where
the
frame
entered
the
mesh
or
or
where
it
where
it
originated.
If
it
starts
inside
the
mesh
mesh
destination,
which
is
where
it
exits
the
mesh
or
terminates
in
the
mesh
and
then
the
actual
transmitter
and
receiver
on
the
particular
op
next
slide.
J
So
here's
a
a
connection
from
a
station
to
on
an
ethernet
lan
on
the
left
to
a
mesh
station
that
has
this
there's
a
device
and
a
component
called
a
gate
which
you
need
to
get
out
of
the
mesh
and
then
there's
a
mesh
links
and
over
on
the
right.
We
have
a
co-located
mesh
station,
an
access
point
and
a
station
that's
associated
with
that
access
point.
The
station
at
the
far
right
has
no
idea.
There's
any
mesh
involved.
J
J
Mesh
flags
has
a
ttl
four
byte
sequence
number
and
can
have
zero
one
or
two
additional
addresses,
because
in
certain
cases
where
the
destination
is
multicast,
you
don't
need
additional
addresses,
so
the
secret,
the
source
address
and
the
sequence
number
as
a
pair
is
cached
at
the
mesh
nodes
and
used
for
duplicate
detection
and
there's
nothing
very
definitive
in
the
802.11
mesh
standard
about
how
long
it
needs
to
be
cached
for,
or
things
like
that
so
unicast
as
this
routing
is
determined
by
this
past
selection
protocol,
the
mandatory
to
implement
one
is,
has
both
reactive
aodv
like
features,
and
it
also
has
a
proactive
part
which
builds
a
tree
from
configured
roots.
J
So
you
can
always
use
that
tree,
but
you
may
get
more
efficient
paths
with
the
hybrid
with
the
reactive
mode,
next
slide
so
multicast,
so
it's
they're,
sent
with
just
with
the
destination
address
the
multigas
that
wrestle.
J
8211
has
always
had
multicast
that
worked
in
this
fashion,
since
it's
been
standardized
11s
next
slide.
This
is
my
last
slide
to
the
question.
Well,
okay,
this
is
all
all
layer
two
and
it's
all
like
that,
and
you
can
have
these
gates
that
connect
to
the
outside
world
and
this
duplicate
elimination
may
solve
things
inside
the
mesh
and
the
ttl
is
a
sort
of
extra
backup.
So
you
can't
really
have
you
know,
looping
and
stuff
like
that
inside
the
mesh
that
would
be
problematic,
but
what
about
loops
in
the
external
networks?
J
But
since
everything
is
layer
two,
it
just
uses
a
spanning
tree
and
disables
gateways
and
such
that
you
don't
have
loops
by
the
typical
spanning
tree
method.
J
So
I
I
you
know,
I
think
the
the
flooding
and
duplicate
elimination
has
got
obviously
some
some
bad
aspects
and
sort
of
a
burden
and
storage
of
the
nodes
and
so
forth.
But
it's
a
pretty
general
and
powerful
technique
for
getting
multicast
to
actually
work
in
in
meshes
and
things
like
that.
B
J
G
J
B
F
I
have
worked
a
little
bit
with
82211s
and
in
my
opinion,
it
was
not
working
well
in
anything
beyond
a
couple
of
nodes,
but
even
then
because
this
aodv
with
proactive,
beaconing
didn't
scale
well,
811
ls
might
be
the
best
mode
to
use
your
wi-fi.
If
you
want
to
do
layer,
3
routing
over
it,
because
you
can
just
switch
off
the
mesh
protocol
below
it,
and
then
you
have
a
fully
bridgeable
single
hop
wi-fi
ad
hoc
mode,
because
the
original,
I
don't
know,
doesn't
work
well
on
newer,
wi-fi
versions.
F
J
I
would
like
to
say
that
I
I
am
not
supporting
the
current
path
selection
protocol
in
802.11s.
Originally
there
were
gonna
be
two
of
them.
One
got
dropped
at
the
last
minute
and
I
think
there
are
could
be
better
alternatives
for
the
for
the
routing
inside
80-11
mesh.
B
C
Could
you
please
go
one
slide
back
slide
16,
please
so
here
you're
saying
that
you
can
do
a
conversion
of
multicast
to
unicast
right
right.
C
J
Yeah
by
the
way,
so
you
don't-
wouldn't
you
don't
just
send
general
multicast
frames
for
the
purpose
of
discovery
in
80211.
Mesh
discovery
happens
because
the
first
these
stations
send
beacons
and
then
they
peer.
So
when
you're
actually
sending
data,
it
never
worries
about
getting
them
to
anything,
but
a
peer
that
it
already
knows
about.
J
So
you
can
just
serially.
You
have
that
list
of
peers
and
you
can
serially
unicast
to
them
quite
easily
and
actually.
J
B
Yeah,
can
you
have
the
microphone
at
a
greater
distance
from
your
mouse.
I
B
A
I
I
At
first,
let's
see:
what's
beer
here
is
the
acronym
of
beer
index
explicit
replication.
Here
is
a
new
multicast
technology.
It
can
achieve
multicast
forwarding
without
explicit
multicast
distribution,
trees
building
and
it
doesn't
require
intermediate
nodes
to
maintain
any
per
flow
state
pure
introduces
a
layer
architecture
to
decode
the
multicast
packet
and
multicast
the
transportation.
I
I
I
There
is
the
beer
layered
architecture,
the
multicast
for
wording
is
decoupled
from
the
multicast
package.
The
multicast
package,
which
has
the
ipv4
or
ipv6
multicast
destination
address,
is
recognized
in
the
ingress
router
and
the
egress
routers
the
intermediate
nodes
forward.
The
packet
depend
on
the
their
header.
Only
the
multicast
destination
address
of
the
package
doesn't
have
been
seen
in
the
intermediate
nodes.
I
I
The
egress
router
removes
removes
the
beer,
header
and
associated
outer
encapsulation
forwards.
The
multicast
package
to
receiver
or
the
next
hop
router
the
beer
layer
is,
is
the
core
part
of
beer.
The
node
forwards,
the
package.
According
to
the
beer
header,
only
the
outer
encapsulation,
as
we
mentioned,
can
be
changed
by
each
node.
That
means
the
whole.
I
hope
that
is
no
multicultural
trees
in
the
beer
domain.
The
details
of
beer
forwarding
and
the
beer
header
is
described
in
the
fc
we
mentioned
above.
I
The
routing
underlay
is
extending
the
routing
protocols
to
build
their
layer.
The
forwarding
table
used
in
the
layer
is
generated
by
the
routing.
Only
protocols
such
as
isis,
ospf
or
bdp,
and,
of
course
payable
and
the
only
protocol
is
extended
to
advertise
the
node's
peer
information
and
compute
the
specific
beer
for
wording
table.
That
means
bift
gift.
I
From
above,
we
know
that
when
we
use
beer
there
is
no
multicast
tree
signaling
and
the
multicast
state
in
the
network.
Beer
can
work
with
any
routing
protocol
for
secondary
beer.
Information
used
for
dipped
calculation,
for
example,
sis
or
spf
btp
and
babel,
and
the
other
routing
protocol
can
do
it
as
well.
D
I
I
Let's
see
the
beer
signaling
in
apple
protocol
paper
route
advertisements
for
vr,
router
roofback
addresses
carrier
trvs
for
their
information
used
for
beef
calculation.
Beer
traffic
can
be
tunneled
over
via
incapable
nodes
by
any
kind
of
tunnels,
because
bevel
is
a
distance
vector.
Protocol
like
bdp
methods
used
being
brbgp.
Segmenting
can
also
be
used
here
for
babel.
This
part
will
be
added
in
next
version.
Next
piece.
I
E
Jeffrey
from
juniper,
I
just
want
to
add
that
the
beer
it
can
achieve
efficient,
broadcast
replication
without
building
a
tree.
That's
why
it's
a
it's
the
best
multicast
protocol.
I
have
seen
the
there
is
one
cache
in
other
scenarios
where
it
it
requires
new.
We
use
a
new
encapsulation,
a
new
folding
algorithm,
so
in
when
you
need
to
to
use
hardware
based
forwarding,
then
you
either
need
a
new
a6
or
a
programmable
chips,
and
that
has
been
hindering
its
deployment
to
some
extent.
E
E
So
I
I
yeah
I
I
I
just
emphasis
also
emphasized
that
the
fact
that
it's
a.
E
C
Yeah
just
two
quick
comments,
so
I
don't
have
an
opinion
yet
of
whether
beer
is
a
good
or
a
bad
idea.
I
sincerely
don't
know,
but
what
I
am
ready
to
claim
is
that
beer
does
not
suffer
from
the
duplicate
problem.
C
Okay,
so
beer
does
not
need
duplicate
detection
and,
as
far
as
I
can
tell
just
by
reading
the
specs,
I
haven't
checked
that
formally
as
far
as
I
can
tell,
it
does
not
suffer
from
the
problems
that
ronaldo
described
in
his
talk
at
the
beginning.
G
Dublin
putter
this
is
going
to
be
a
bit
of
a
longer
well
comment:
slash
additional
notes.
I
first
would
like
to
point
out
a
few
things
about
babel's
functioning
as
it
would
apply
to
money.
G
G
If
so,
multiple
mesh
nodes
in
this
case
means
that
there's
multiple
paths
for
the
traffic
to
progress
that
traffic
in
current
beer
designs
is
always
unicast,
so
you
always
have
the
the
replication
into
unicast
on
the
single
mesh
hop
level,
whether
that
is
a
good
thing
or
a
bad
thing
depends
on
the
actual
mesh
properties,
but
you
do
only
send
it
once
so.
G
If
you
have
a
thousand
receivers
behind
one
mesh
node,
then
it's
only
forwarded
once
to
that
mesh
node,
and
this
is
not
necessarily
something
about
beer
that
needs
to
stay
this
way.
It's
only
so,
if
you
look
at
the
problems
with
using
multicast
for
labels,
multicast
propagation,
on
lower
levels
in,
for
example,
mldp,
the
problem
was
always
that
you
are
moving
from
assigning
the
labeling
and
control
from
the
receiver
to
assigning
that
function.
G
I
believe
this
is
a
very
solvable
problem
which
just
needs
a
bunch
of
additions
to
beer,
so
this
protocol,
so
in
in
itself,
beer
will
start
out
with
only
unicast
packets
on
the
lower
layer
and
if,
if,
if
we
want
to
use
multicast
capabilities
of
the
radios,
then
that
will
be
additional
beer
work,
but
it
can
be
done.
G
G
If
you,
if
you
look
at
it
sideways
kind
of,
then
11s
is
also
an
additional
layer
of
encapsulation,
because
you
have
this
the
six
address
frame
and
if
you
look
at
adding
extension,
headers
with
sequence
numbers,
that's
a
very,
very
simple
kind
of
added
encapsulation,
but
still
you're
you're
tacking
additional
data
into
the
packet.
That
is
kind
of
the
one
important
takeaway
for
me
here.
G
The
way
to
avoid
all
the
trying
to
duplicate
things
is
to
add
a
layer
and
that
layer
also
tends
to
allow
better
routing,
behavior-
and
I
think,
that's
taken
at
this
point,
and
we
should
focus
on
figuring
out
what
the
best
encapsulation
is
rather
than
trying
to
make
it
work
without
encapsulation.
I
I'd
like
to
make
a
clarification,
beer,
ipv6
encapsulation.
That
means
the
director
adopted
in
their
working
group
is
bare
insects.
It's
not
encapsulated
in
beer
in
ipv6
extension
header.
It's
just
a
protocol
follow
ipv6
header,
so
we
needn't
to
do
the
check
of
extension
header
for
bearing
6.
We
just
read
the
ip
protocol
or
next
header
field.
In
the
package.
We
can
know
that
there
is
a
verb
header
followed
me.
We
need
to
do
the
extension
header.
G
Check
yeah,
sorry,
I
was
a
bit
unclear
about
that
that
that
is
what
I
meant.
I
did
forget
another
thing
in
in
the
beer.
Pable
work,
there's
one
very
important
thing
that
is
completely
missing
at
this
point,
which
is
there
needs
to
be
some
way
to
dynamically
or
within
the
mesh
assign
the
actual
identifiers
for
the
beer
nodes.
I
either
the
bit
position,
and
that
is
the
actual
difficulty
that
that
doing
beer
in
monet
will
need
to
solve
in
some
way.
F
B
F
Quick,
we
would
just
need
deduplication
for
dense
mode
flutters
multicast
customs,
not
for
sparse
mode
that
follow
a
tree.
If
I
understand
this
right,
beer
is
just
following
a
joint
tree
that
is
made
out
of
the
unicast
roots
and
use
the
explicit
bits
to
keep
track,
which
part
of
the
already
split
traffic
is
still
having
to
travel
to
multiple
nodes.
B
I
don't
know
how
to
pronounce
his
name.
Oh.
E
It's
you
or
jeffrey
from
juniper.
I
I
want
to
add
one
thing
that
I
forgot
to
say
earlier.
It's
related
to
the
earlier
point
point
about
income
interface.
Not
it
cannot
be
the
same
as
I'll
go
interface
in
the
traditional
multicast
folding
with
beer,
as
david
pointed
out,
is
even
online
interface.
It's
a
neighbor
based,
so
you
you
don't.
We
do
not
have
this
problem,
you
can
receive
traffic
on
an
incoming
lane
and
you
can
go
out
of
the
same
lane
again
to
a
different
neighbor.
K
Hi
luberger
I'm
new
to
beer,
so
I'm
new
to
beer,
so
I
may
have
it
wrong,
but
I
think
the
really
interesting
point
here
is
is
by
adding
beer
is
adding
a
new
forwarding
layer
or
an
additional
forwarding
layer
and
that
separates
out
sort
of
the
ip
semantics
from
the
forwarding
semantics,
which
I
think
is
really
good
for
solving
the
router
to
router
problem
that
I
asked
about
before.
So
I
think
david
talked
about
the
question
for
the
group
is
what
encapsulation
mechanisms
should
be
thinking
about.
B
N
Cool,
did
you
give
me
the
amp,
or
will
you
move
the
slides.
N
Well,
we
can
start
already
so
so
ripple
is
a
world.
It's
the
working
group
that
defines
the
ripple
routine
protocol
and
ripple
is
a
distance
vector.
That's
optimized
for
a
mesh
that
is
using
one
or
several
routes
to
reach
the
outside.
So
most
of
the
traffic
is
supposed
to
be
from
that
route
or
to
that
route,
and
this
is
designed
to
operate
in
a
constrained
network,
low
power,
llc
network.
N
So
we
we
did
extensive
optimizations
to
limit
the
knowledge
of
topology
and
the
routes
and
address
that
that
you
need
to
have
inside
the
network
and
for
that
basically,
what
we
are
doing
is
we
are
routing
mostly
from
the
perspective
of
the
root,
so
think
about
a
distance
vector,
but
instead
of
doing
any
to
any,
you
will
do
root
20,
and
for
that
the
first
thing
that
happens
is
you:
you
build
a
tree
which
is
not
really
a
tree.
N
It's
a
directly,
a
cyclic
graph
that
is
rooted
at
the
root
and
that
basically
points
the
destination
of
that
geodag
is
the
root,
so
that
gives
you
a
loopless
path
for
any
node
for
the
default
routing.
If
you
just
want
to
do
collection,
that's
enough
and
and
you're
dead.
If
you
want
to
be
able
to
route
down
this
geodac
towards
the
devices,
then
you
will
have
to
establish
the
watts
path,
and
for
that
you
have
two
modes.
One
is
what
we
call
storing
mode
and
the
other
one
is
non-storing
mode.
N
So
in
non-storing
mode,
basically
the
each
node
advertises
its
potential
parrots.
So
since
it's
a
deodorant,
it's
not
just
one
parent,
it's
multiple
parents
so
advertise
its
parents
to
the
roots.
So
each
note
says:
I'm
here
and
my
potential
parents
have
those
guys
and
with
this
the
root
is
capable
of
rebuilding
the
whole
structure
of
the
geoduck
in
memory
and
then
use
that
for
source
routing.
So
that's
that's
the
non-storing
mode
in
storing
mode.
You
will
use
this
duo,
dag
and
basically
tell
your
potential
parents
about
your
addresses
and
recursively.
N
The
potential
parents
will
tell
their
own
addresses,
plus
all
their
children
to
to
the
to
the
grandparents
etc.
So
so
you
you
end
up
knowing
every
route
downwards
and
using
only
the
default
route
upwards
so
that
that's
the
very
basic
of
of
ripple.
So
it
is
anisotropic,
it
has
a
sense
of
up
and
down,
which
was
inherited
by
rift
basically
to
extend
the
model
to
multiple
roots,
and
basically
the
top
of
fabric
and
left
is,
is
like
a
root,
but
you
have
many
of
them.
N
What
else
we
have?
We
have
extended
ripple
for
a
neodv
model
and
for
a
centralized
routing
model.
So
a
lot
of
what
you've
seen
in
donald's
slides.
You
know
the
the
tree
that
that's
possibility
or
iodv
that's
a
possibility.
We
have.
We
have
pretty
much
the
same
thing,
so
that's
the
basic
of
it
and
we
have
different
modes
of
operation
in
different
instances.
I
need
to
talk
about
that
a
little.
N
So
if
you
basically
want
to
make
different,
optimization
or
or
build
different
dags
then
ripple
allows
you
to
to
build
multiple
of
those
geodex
and
each
one
will
that
the
node
participates
to
will
translate
into
a
different
verb.
So
we
need
to
signal
in
the
packet
which
verb
which
routing
table
you're
using
which
corresponds
to
the
ripple
instance
that
installed
that
route.
So
we
have
the
hub
by
hub
option.
So
it's
not
there
by
operating
here,
but
we
have
a
hub
by
hub
option
in
the
packets
to
signal
which
ripple
instance,
we
are
using.
N
So
it's
an
alternative
like
of
source
destination,
routing,
to
go
to
a
particular
route.
If,
if
you
have
multiple,
if
your
monthly
home,
you
can
build
one
instance
per
exit
point
and
then
you
route
along
that
instance
and
you
will
exit
the
the
expected
place
in
the
network,
so
the
one
the
mode
of
operation,
one
is
non-starting
mode
mode,
operation,
two
historic
mode
model,
profession,
three
mode,
three
is
storing
mode
with
multicast.
What
it
means
is
inside
the
geodec.
N
There
is
what
we
call
the
preferred
parent
tree
and
we
use
that
tree
as
the
multicast
tree.
Basically,
so
the
leaves
inject
their
multicast
addresses
as
they
would
inject
any
cast
address
or
unicast
addresses
it's
just
that
the
parent,
instead
of
keeping
the
freshest
one
using
what
we
call
the
past
seconds.
N
That's
how
we
do
mobility
in
ripple.
Instead,
we
we
just
keep
them
all
and
let
the
lifetime
expire
and
as
we
keep
them
all,
then
we
basically
unicast
copy
typically,
but
we
could
also
broadcast
copy
a
packet
going
down
the
tree
to
every
every
child.
That's
interested
so
compared
to
what
was
said
before.
It's
not
a
flood
right.
We
still
register
the
multicast
addresses
they
are
injected
and
aggregated
as
they
go
up.
The
tree
us
in
traditional
space
and
they
are
the
packets-
are
then
routed
basically
down
that
path.
N
So
you
really
have
to
do
the
two
traditional
modes
where
either
you
you
send
a
multicast
packet,
all
the
way
to
the
root,
and
then
it
will
go
down
the
tree,
in
which
case
you
don't
have
to
have
this
duplicate,
elimination,
prime
or
you
can
optimize
and
say.
Let
me
pass
it
to
when
it's
when
it's
sourced
anywhere
in
the
tree.
N
If
you
don't
want
to
have
to
care
about
where
you
receive
this
packet
or
if
you
already
received
it,
then
basically,
yes,
you
can
leverage
the
tree
and
and
pass
the
packet
to
the
root
and
let
the
the
packet
go
down
down
that
tree
next
slide.
Please!
Oh
no!
It's
me
now.
Yes,
it's
me.
N
Okay,
so
now
that
that
was
the
the
mob
screen
report
now,
the
role
has
has
done
another
piece
of
work
which
is
completely
independent
and
and
completely
that
doesn't
need
any
form
of
of
geodac
installed
or
anything.
So
you
have
a
big
crash
and
you
need
to
to
flood
some
information.
N
The
thing
you
want
to
avoid
is
every
node
trying
to
relay
this
packet,
so
you
basically
want,
in
another
fashion
to
to
create
islands
where
one
will
stand
and
the
rest
will
receive,
and
when
you're
at
the
border
of
that
island,
then
someone
will
stand
again
and
that
will
propagate
that
way,
and
so
there
is
an
algorithm
which
is
three
core
rfc
6206,
which
is
used
by
ripple
anyway
to
console
excessive
flooding
and
which
is
there
leveraged
as
the
main
as
the
base
of
the
multicast
operation.
N
Basically,
what
it
does
is
if
there
is
an
information
that
you
want
to
synchronize
on
every
node,
a
certain
knowledge
also,
then
packet,
someone
sends
it
and,
and
everyone
runs
a
timer
and
in
a
certain
portion
of
timer
you
just
listen
and
the
second
portion
of
the
timer.
You
have
a
random
piece
where
you
still
listen
and
then
you
send,
but
you
only
send
if
you
have
not
received
more
than
a
certain
constant
number
of
packets.
N
So
if
enough,
packets
of
this
same
knowledge
were
transmitted
around
you,
then
basically
you,
you
assume
that
everyone
around
you
had
that
packet
and
you
don't
need
to
resend.
On
the
other
hand,
if
you
did
not
receive
enough
copies
of
this
thing,
then
you
will
retransmit
it
now.
The
efficiency
is
is
what
it
is
right.
You
have
no
guarantee
that
everyone
will
get
it.
N
It's
a
little
bit
problematic
at
the
edge
of
the
network
because
you
might
receive
many
copies
from
the
inside
of
the
network
and
there
might
be
path
nodes
beyond
you
on
the
edge
of
the
network
and
just
because
you
received
enough
from
one
side
doesn't
mean
that
everybody
on
the
other
side
got
it.
So
there
are
a
few
corner
cases
with
it.
It's
not
quite
efficient,
but
it's
it's
much
better
than
flooding
in
a
very,
very
dense
radio
environment.
N
Okay
and
then
we've
got
extension
work
for
meepo,
but
I
won't
spend
time
on
that
one.
The
new
work
that
we
have
started
at
six
lupine,
actually,
six
low
end
and
raw,
is
based
on
the
fact
that,
most
of
the
time
we
don't
use
the
storing
mode,
and
so
we
don't
have
this
tree.
N
So
we
have
also
designed
something
which
leverage
the
non-storing
mode
in
non-storing
mode.
There
is
a
source
route
by
the
root,
and
so
what
we'll
do
in
that
case
is
we'll
exploit
the
source
route.
Basically,
the
the
nodes
use
the
extensions
that
we've
made
to
ipv6
network
discovery
to
register
unicast
address.
Now
we
are
also
enabling
the
registration
of
multicast
address,
which
is
maybe
of
interest
for
you
guys
actually,
because
the
first
thing
before
you
you
distribute
traffic
is
to
know
who
the
listeners
are
and
and
mld
is
a
poor
model.
N
That
is
not
necessarily
the
one
you
want.
You
might
want,
actually
the
devices
to
register
the
addresses
that
that
they
listen
to
and
that's
the
model
we
use
in
iot,
because
low
power
devices
might
not
be
listening
to
multicast
queries
from
from
dmld
routers.
So
we
want
the
devices
to
be
able
to
sleep
and
tell
the
routers
hey,
I'm
interested
in
that
multicast
flow.
If
there
is
something
that
comes
on
that
flow.
N
Well,
you
know
I
I
want
it
so
when
I
wake
up,
I
will
come
and
see
if
you've
got
one,
so
basically
the
the
sleep
proxy
model,
so
so
the
the
sixth
version
is
always
to
avoid
having
to
do
multicast
and
having
the
design.
The
the
devices
register,
the
unicast
and
now
any
cast
and
multicast
addresses
they
care
about
and
to
make
that
work.
Now
the
root
will
do
ingress
replication.
So
basically
the
root
will
tunnel
to
every
edge
router
and
the
edge
routers
will
distribute
of
our
unicast
or
multicast.
N
Since
we
talked
about
beer,
I
will
speak
a
little
bit
more.
We
have
two
variations
of
the
beer
idea,
the
working
group
now
for
the
lack
of
interest.
This
this
work
is
pretty
much
stalled,
doesn't
mean
it's
abandoned,
but
it
means
that
we,
we
did
not
get
strength
and
interest
and
and
consumers
for
the
those
work.
This
piece
of
work,
so
one
is
constraint,
cast
and
constraint,
cast
uses
bloom
filters.
So
it's
a
bit
like
beer.
I
see
it
as
beer
family,
but
it's
not
exactly
beer
and
with
the
bloom
filter.
N
What
you
can
do
is
is
encode
in
a
bit
map,
not
the
bit
of
the
destination
or
something
like
beer,
but
more
a
few
bits
which
basically
represent
the
azure
use
for
an
address
that
you
care
about.
So
blooms
are
used
for
finding.
If
something
is
there
basically,
and
if
you
have
a
match,
I'm
not
sure
it's
there,
but
if
you
don't
have
a
match,
you're
sure
it's
not
there.
What
it
does
is
for
each
address,
for
instance,
that
that
you
you
have
in
the
network.
N
It
will
compute
a
three
four
bit
position
using
a
function,
hash
functions
and
then
to
know
everybody
who's
there,
you
basically
or
all
those
bits.
So
now
you've
got
the
map
of
everybody
use
here.
Now,
if
you
want
to
see,
if
somebody
is
here,
you
take
your
ash's
address
and
you
you
see
if
all
the
bits
of
this
ash
are
present
in
the
in
the
aggregate
big
map.
If
it
is
then
there's
a
chance,
the
guy
is
not
there.
If
it's
not,
then
you're
sure
he
is
not
there.
N
Brte
actually
will
signal
bits
for
the
hops,
and
so
you
can
specify
which
route
you're
going
to
take
by
following
the
bits.
The
bits
are
not
the
destination.
The
bits
are,
the
hops
c
cast
has
bloom
for
the
hops,
but
it
could
have.
I
think
it
would
have
been
optimized
to
to
basically
just
bloom
filter
the
destinations,
and
so
basically
what
you
would
do
in
your
case,
I
don't
think
you're
going
to
use
this,
but
if
you
were
to
consider
it,
you
would
probably
look
at
all
the
subscribers
to
your
multicast
and
compute.
N
You
know
have
the
bits
for
them
and
when,
when
you
have
something
to
distribute,
you
basically
distribute
it
to
the
the
aggregate
bloom
filter
of
all
this
destination,
and
when
you
want
to
forward
that's
what
is
done
in
this
draft,
you
just
match
the
aggregate
of
your
next
stop
to
see.
If
all
the
bits
that
you
want
for
to
asset
and
if
they
are,
then
you
fall
to
him.
N
I'm
not
sure
my
expectation
went
that
great,
but
think
about
using
bloom
filter,
as
opposed
to
to
just
exact
bits
in
beer.
The
advantage
of
that
is
that
you're
not
limited
drastically
by
the
exact
size
of
your
bitmap
like
like
effectively.
If
you
store
more
stuff
in
your
bloom
filter,
then
then
it's
it's
normal
capacity.
Then
you
will
have
more
false
positives,
but
you
will
still
rot.
N
You
would
just
rot
down
the
graph
a
little
bit
too
much
some
copies,
and
then
you
realize
that
that
effectively
some
of
the
bits
were
coming
from
the
left,
some
from
the
right,
so
the
mesh
does
not
exist
further
down,
but
that
avoids
this
hard
limitation
of
what
size
did
you
use
for
your
bitmap?
Oh,
I
have
one
more
node.
Now,
I'm
screwed.
N
Okay,
so
I'm
almost
done
so.
The
other
thing
we
have
is
effectively
beer
for
repo.
So
then
again,
we
have
this
tree
right,
starting
at
the
root,
and
so
what
we
care
about
in
repo
is
is
compression
right.
We
don't
want
to
have
to
to
have
a
lot
of
state
and
a
lot
of
on
big
advertisements
and
what
is
very
cool
with
beer.
Knowing
that
we
have
the
same
promise
everybody
to
assign
bits,
it's
not
so
right.
N
We
have
same
question,
the
bits
must
be
assigned
but
say
the
bits
are
assigned
and
we
have
see
it
as
a
tree,
even
if
it's
a
diode
when,
instead
of
advertising
your
address
and
all
the
address
of
your
children
to
your
parent
in
storing
mode,
what
you
could
do
is
send
a
single
bitmap
for
you
and
your
children
with
all
the
bits
that
represent
you
and
your
children
set.
N
So
basically,
when
you
do
that,
the
parent
receives
the
bids
for
one
child
for
another
child
for
another
child.
What
you
will
do
is
it
will
or
the
different
bitmaps
that
he
gets
for
all
his
children
and
that
odd
aggregate
bitmap
that's
what
he
will
pass
to
his
own
parent
and,
as
you
go
up
the
tree
to
the
root,
then
at
the
end
all
the
bits
should
be
set
for
for
every
destination
and
the
root
knows
that
this
bit
is
via
this
particular
children.
N
So
every
node
will
keep
the
bitmap
it
got
from
its
children
and
now
a
packet
that
you
want
to
forward.
You
will
basically
set
the
bits
that
you
want
to
reach
and,
and
it
will
be
ended
with
by
each
hop
to
all
his
children
and
if
one
children
matches
that
mean
you
know
the
the
the
one
of
the
bits
that
that
you
care
for
is
effectively
said.
Then
you
forward
to
that
children
to
the
chat.
N
So
the
cool
thing
is
instead
of
maintaining
in
your
database
one
and
three
for
every
descendant
for
every
ip
address
of
every
destiny
and
down
the
tree.
You
just
keep
one
bitmap
for
every
direct
child
and
and
you
forward
along
the
bitmap
and
that's
pretty
much
it
that
that's
that's
all
I
had
for
you.
So
I
guess
I'm
okay.
B
D
A
A
A
C
So,
okay,
well,
the
slides
are
being
put
up,
I'm
julius
croblocheck,
and
so
I
had
nothing
to
say
about.
I
had
nothing
interesting
to
say
about
multicast,
so
I
asked
the
chairs
for
the
opportunity
to
to
show
the
monet
group
whether
what
we
have
been
doing
recently
in
the
babel
group
and
well,
it
was
worth
trying.
I
was
expecting
the
chance
to
say
no
that's
off
topic
and,
to
my
great
surprise
they
said
yes,
so
thank
you
very
much
to
the
chairs.
Next,
please.
C
So
most
of
you
hopefully
have
heard
about
babel,
for
those
who
haven't
dabbled
is
a
traditional
rooting
protocol,
which
originally
was
designed
for
hybrid
or
heterogeneous
networks.
So
I
was
seeing
at
the
time
people
struggling
with
putting
mesh
networking
protocols
and
networks
that
were
mostly
wired,
so
that
had
a
wired
backbone
with
some
meshy
bits
at
the
edges,
and
that
did
not
necessarily
work
very
well
when
most
of
the
network
was
traditionally
structured,
and
so
I
tried
to
design
a
protocol.
C
C
So
babel
became
an
its
standard
track
protocol
in
january
2021
about
two
years
later
than
I
expected
that
will
be
familiar
to
everyone
here.
I
think,
and
since
then
we've
done
a
number
of
useful
extensions
and
a
number
of
useless
extensions
that
we've
abandoned
and
I
would
like
to
quickly
mention
four
of
them:
their
authentication
source,
specific
routing,
v4
via
v6
and
rtt
sensitive
metrics,
and
I
would
like
to
point
out
that
all
of
those
have
two
independent
implementations
that
they
interoperate
to
the
extent
possible.
C
With
the
base
protocol
and
the
important
point
we've
been
trying
to
design
protocol
agnostic
extensions.
They
are
implemented
in
babel,
but
there
is
nothing
in
principle
that
would
prevent
them
from
being
generalized
to
other
protocols,
and
my
goal
here
is
to
have
people
steal
our
ideas
thanks.
Please.
C
So
mac
authentication
we've
done
a
minimalistic
and
easy
to
implement
authentication
protocol.
We
have
another
authentication
protocol
for
when
you
need
more
features
and
what
is
original
in
this
protocol
is
that
it
is
provably
invulnerable
to
replace
so
most
of
the
authentication
protocols.
If
you
look,
for
example,
at
ospf,
they
do
not
deal
with
replay
in
the
general
case,
then
just
rely
on
properties
at
the
rooting
protocol
so
that
the
replay
attacks
are
not
useful
and
that
that
makes
reasoning
about
the
security
properties
uselessly
complicated.
C
C
Source
specific
routing,
it's
sometimes
called
asdr
for
source
address
dependent
routing,
is
an
extension
that
allows
routing
packets
depending
on
their
source,
and
it
allows
a
cheap
form
of
network
multi-homing.
So
you
have.
Your
network
is
connected
to
two
isps
and
you
want
packets
to
be
directed
to
one
isp
or
the
other
isp,
depending
on
their
source
address,
or
in
other
words
the
source
node
controls
which
edge
router
is
reached
by
using
by
setting
the
source
address
of
the
packet.
C
C
C
Only
nodes
well
v4
via
v6,
allows
sending
the
v4
traffic
through
the
v6
nodes
the
go
being
here
to
reduce
the
amount
of
administrative
overhead,
and
there
is
no
translation.
There
is
no
tunneling,
there
is
no
overhead.
So
usually
I
always
try
to
work
out.
What
are
the
trade-offs
and
in
the
case
of
v4
via
v6,
I
cannot
see
any
trade-offs.
C
It's
to
me.
It
looks
just
like
magic,
it's
so
we've
enabled
by
it
by
default.
Expecting
our
user
base
to
complain,
it's
been
deployed
for
a
couple
of
months.
Nobody
seems
to
be
complaining.
We've
had
some
comments,
saying
it's
pretty
cool
to
have
more
roots,
but
other
than
that
everything
seems
to
work.
It
does
require
kernel
changes.
The
kernel
changes
for
ip
were
done
in
linux,
5.2
and
turkey
hail
and
jorgensen
implemented
the
changes
for
icmp
and
linux
5.13,
so
the
implementation
will
disable
it.
C
C
And
finally,
that's
something
that
I'm
feeling
very
ill
at
ease
with
ronald
has
been
pushing
me
to
push
it
forward.
So
it's
an
extension,
that's
extremely
useful.
It
allows
computing
automatically
metrics
by
looking
at
roots
rtts
and,
at
the
same
time,
it
does
not
suffer
with
major
stability
issues,
which
is,
if
you
do
rtt
naively.
C
C
So
the
draft
has
been
adopted,
but
it's
been
in
a
state
in
which
I
don't
manage
to
finish
it
for
a
long
time.
It's
widely
deployed
in
production,
because
it
is
extremely
useful
and
the
fact
that
the
draft
is
not
ready
yet
didn't
prevent
a
completely
independent
implementation
again
by
turkey,
hail
and
jergensen
in
bird.
C
C
Well,
okay,
so
we
have
implementations
of
at
least
four
useful
extensions
that
are
deployed
in
production
and
that
are
mostly
protocol
agnostic.
You
should
consider
stealing
the
ideas
behind
them
for
your
favorite
routine
protocol.
I
promise
we
won't
get
offended
to
the
upper
contrary,
we'll
take
it
as
a
compliment.
Thank
you
for
your
attention.
D
F
D
C
B
F
G
Dublin
potter
again,
this
actually
a
little
bit
ties
into
the
the
babel
presentation,
but
also
beer
for
multicasting
and
mayonnaise
the
hardest
problem
that
I
I
see,
which
I've
already
noted,
is
assigning
the
the
identifiers
for
using
beer.
And
I
would
like
to
note
two
things
about
solving
that.
So
either
the
mesh
becomes
its
own
beer
domain,
which
is
a
perfectly
fine
thing
to
do.
G
Even
if
other
parts
of
the
network
also
use
beer,
there's
no
problem
with
having
the
edge
of
the
mesh
just
be
a
transition
between
two
different
beer
domains
which
allows
limiting
the
scope
of
the
assignment
of
identifiers
for
beer
to
inside
the
mesh,
but
also
if
the
signaling
mechanisms
for
this
can
be
designed
in
a
suitable
protocol.
Agnostic
way.
G
Then
there's
no
problem
with
having
this
work
inside
of
babel
to
assign
identifiers
inside
of
the
mesh
and
then
transition
into
isis
or
ospf
or
bgp
at
the
boundary
of
the
mesh
and
just
continue
in
the
same
kind
of
signaling,
whether
that's
actually
desirable
and
or
whether
people
are
actually
going
to
implement
it.
For
bgp
isis
or
spf
is
a
different
question.
But
both
of
those
are
fundamentally
viable
approaches.
F
We
have
talked
quite
a
bit
about
that.
We
need
something
in
the
forwarding.
Plane
dear
talked
about
it
because
it
needs
some
bits
and
must
send
it
somewhere.
I
talked
about
this
and
someone
mentioned
mpls.
Has
someone
experienced
how
well
mpls
works
in
marned
environments
because
does
wi-fi
do
most
wi-fi
chips
supported?
Well
because
at
least
some
of
the
more
esoteric
radios
that
like
to
do
marnet
thing
tend
to
be
a
little
bit
conservative,
what
they
accept
as
over
the
layer.
Two.
E
Jeffrey
here
I
my
tool,
onsite
tool
does
not
allow
me
to
raise
my
hand
or
something
I
couldn't
find
it
so
I'll.
Just.
E
Mpos
is
it
was
it
it's
probably
mentioned
in
the
context
of
beer
following
mgos.
However,
beer
does
not
require
mpos
at
all.
It
can
work
with
mpos.
It
can
work
with
any
layer,
2
header
or
tunnel
header,
so
you
can
use
beer
without
mpls
at
all.
Now,
also
going
back
to
the
question
of
rounding
beer
in
a
man
8
network
itself,
not
at
the
ip
layer.
E
It
works
very
well,
and
then
I
realized
that
in
my
network,
it's
I
assume
it's
mostly
a
radio
network
and
quite
often
you'll
want
to
reach
multiple
destinations
over
the
same
radio,
and
in
that
case
beer
itself
may
not
be
a
very
good
fit
because
beer
folding
is
labor-based
it's
you
can
only
send
it
one
by
one,
but
if
you
don't
consider
that
part,
then
the
beer
itself,
the
the
architecture,
even
though
it
currently
is
based
on
the
ip
layer,
it's
for
the
it's
over
ipa
routing
underneath,
but
the
beer,
encapsulation
and
beer
folding
algorithm
connect,
is
actually
not
limited
to
to
ip
to
layer.
E
B
C
Yeah,
I'd
like
to
come
back
to
the
point
that
david
made
earlier
so
david
made
two
two
points
that
I
fully
agree
with.
So
he
said
that
the
protocol
that
work
well
for
multicast
or
protocol
that
use
extra
encapsulation
and
that's
basically
the
alternative
to
encapsulation-
is
to
have
duplicate
suppression
and
if
you
have
duplicate
suppression,
you're
doing
two
things
that
are
very
evil.
C
So
there
is
one
protocol
that
does
that
and
that
you're
using
all
the
time
that's
dhcp
v4,
so
duplicate
suppression
needs
to
handle,
especially
dcp
v4,
which
is
a
horrible
layer,
violation
and,
and
the
other
thing
it
does
is
that
it
puts
in
potentially
unbounded
amounts
of
states
in
the
forward
and
plane.
If
I'm
correct,
that's
essentially
what
mpl
does
so.
It
looks
like
we
have
two
things,
one
which
we
definitely
dislike:
that's
duplicate
suppression,
the
other
one
which
is
not
very
elegant,
which
is
to
encapsulate
all
of
our
packets.
C
This
is
the
beer
isn't
done
in
802.11s
and
so
on,
and
I'm
wondering
whether
anyone
that's
not
I'm
not
expecting
an
answer
now,
but
does
anyone
have
any
ideas?
Is
there
a
third
possibility
that
allows
to
exclude
both
of
those
places?
If
we
find
a
third
possibility,
then
we
could
have
a
nice
diagram
with
a
triangle:
we'd
call
it
lampertur's
triangle
and
david
would
be
famous.
So
I'd
like
to
encourage
everyone
to
think
about.
Is
there
a
third
possibility.
K
So
a
couple
of
comments.
First,
on
mpls,
you
know
mpls
is
a
data
plane,
it's
also
a
control
plane
or
has
lots
of
control
plane
protocols
associated
with
it
from
a
data
plane
perspective.
It
has
a
nice
property
of
being
these
stackable
labels.
So
you
know
maybe
there's
a
way
to
use
or
abuse
the
data
plane
for
the
layering
that
we
talked
about
earlier.
K
But
I
would
I
wouldn't
try
to
say
that
any
of
the
mpls
control
protocols
are
at
all
appropriate
for
men
a's,
and
I
don't
think
anyone
suggested
that
I
didn't
hear
that
and
you
know
if
someone
suggested
it.
I
would
agree
with
the
comment
that
it's
not
a
good
idea.
So
that's
on
mpls.
The
other
comment
was
actually
in
response
to
the
the
prior
to
the
third
leg
of
the
triangle.
K
To
the
lampeter
triangle
is,
one
option
is,
is
to
leveraged
ethernet
header
and
there's
a
lot
of
radios
out
there
like
wi-fi
that
have
an
ethernet
header,
and
maybe
we
can
use
and
abuse
the
addressing
that's
going
on
there
by
and
allow
for
not
carrying
extra
bits
on
the
wire
or
not
adding
extra
headers.
So
I'd
like
to
just
add
that
in
as
that
third
leg.
B
M
I
was
already
pointing
out
on
the
on
the
mailing
list
that
we
did
have
a
lot
more
in-depth
starting
evaluation
of
using
beer,
beer
or
beer-like
technologies
in
role
specifically
where
it.
M
The
goal
was
not
only
to
do
multicast
with
it,
but
also
as
an
actually
more
efficient
way
to
steer
the
traffic
hop
by
hop
through
the
network,
so
that
you
don't
have
to
have
the
this
expensive
routing
state
in
a
road
network,
and
I
think
the
way
I'm
intonating
that
may
already
show
you
that
there
may
be
good
differences
to
other
use
cases
where
you
have
more
energy
and
where
you
love
to
have
routing.
And
you
would,
for
example,
rather.
M
Rely
on
them,
so
one
of
the
technologies
that
we've
done
in
the
beer
working
group
also,
which
is
the
north
48,
is
brte,
and
that
is
basically
allowing
you
to
hop
by
hop
steer
the
packet
through
the
network
with
for
a
steering
solution,
probably
the
most
compact
encoding-
and
that
was
exactly
the
the
brte
thing-
was
what
what?
What.
M
Role
would
very
much
benefit
from,
as
opposed
to
relying
on
hop
by
hop
using
the
igp
routing
information.
So
now,
obviously
that
requires
you
to
have
a
topology
information
on
the
the
router
that
sends
it
so
that
you
can
calculate
that
path.
Hop
by
hop
there,
like
we've
done
in
mpls
networks
with
the
rsvpt
and
eros.
M
So
pretty
much
same
thing,
just
a
very
much
more
compact
encoded,
and
there
probably
wouldn't
be
something
you
want
to
do
with
barbell
and
unless
you
start
disseminating
topology
information
sufficiently
well
like
we
do
it
in
isis
or
ospf.
M
I
would
assume
normally
you
don't
have
that
information
so
yeah.
I
I'm
rambling
a
lot
of
hopefully
funny
details,
but
I
think
it
shows
that
the
solution
environment
is
is
a
lot
wider
and
it
shows
also
that
the
different
worlds
that
we
have
here
with
barbell
roll
and
many
may
not
necessarily
need
one
and
the
same
option
out
of
all
these
multicast
things
that
we
have
in
the
end.
L
Rick
rick
very
quick
comment
about
putting
topology
information
out
into
mayonnaise.
The
churn
for
most
many
use
cases
is
so
high
that
you
just
absorb
all
your
bandwidth,
keeping
the
topology
consistent.
So,
let's
not
drift
off
into
that.
Just
a
quick
comment
about
duplication
of
packets
or
deduplication
of
packets.
There
are
two
reasons
for
having
duplicate
packets
in
your
in
your
system.
One
is
because
it's
meant
to
be
there.
Dhcp
v4
is
a
classic
example.
You
know
the
application.
There
is
saying.
Actually
I
need
duplicate
packets.
L
The
other
reason
is
because
your
multicast
system
can't
remove
them
or
accidentally
create
them,
and
I
think
there
needs
to
be
a
real
separation
of
these
two
things.
Generic
deduplication
of
packets
within
a
manet
is
not
something
we
want
to
pursue
smf
due
to
the
way
it
works,
creates
duplicates
by
accident
and
therefore
must
clean
them
up.
Other
systems
may
not
create
duplicates.
G
Yeah,
I'm
slightly
confused
that
earlier
thank
david
lampotter
again,
but
I
I
have
something
other
to
well
ask
here
with
beer
being
suggested
in
role
already.
I
don't
have
the
history
on
on.
Why
that
fizzled
out
or
anything
if
there's
any
and
oh
apparently
it
fizzled
out,
didn't
do
the
pandemic.
If
there's
any
actual
technical
reasons,
we
should
totally
dig
them
up
and
not
repeat
the
same
mistakes.
B
So
so
my
my
takeaway
is
that
beer
is
definitely
something
that
we
should
look
into
for
monet,
maybe
also
for
for
role
where
it
was
already
on
the
to-do
list.
B
Really
something
really
important.
I
I
closed
the
queue
because
we're
out
of
time
actually
so,
but
do
do.
Please
continue
this
discussion
on
the
mailing
list
and
the
mailing
lists.
I
would
say
I
mean
people
don't
like
cross-posting,
but
to
keep
this
crowd
together.
We
we
cannot
escape
that.
I
think
for
the
moment
and
overall,
any
final
words
of
wisdom
from
you.
H
Sure
so,
yes,
let's
continue
this
question.
I
would
hope
that
that
there
are
commonalities.
We
all
understand
that
lens
and
mesh
networks
and
networks
and
all
that
stuff
are
different
and
some
have
different
needs.
H
But
what
I
would
like
to
what
I
would
really
love
to
see
is
some
type
of
of
of
more
sharing
right.
Instead
of
going
back
and
saying,
oh,
we
learned
about
stuff.
Let's
keep
working
and
roll
or
dominate
you
know
whatever
something
else
to
try
and
keep
the
discussion
going.
Maybe
that
means
we
meet
more
often
like
this,
because
I
think
this
will
be
very
productive.
H
Maybe
it
means
we
on
purpose,
think
about
any
common
building
blocks
that
could
be
used
for
different
things
and
we
work
on
that
in
some
place.
You
know
one
of
the
working
groups,
whether
the
system
working
groups-
maybe
we
spin
up
on
your
effort,
you
know
whatever
it
is,
but
if
we
can
figure
out
those
building
blocks,
then
maybe
we
can.
We
can
make
more
progress
than
just
you
know
going
off
and
then
coming
back
every
other
atf
to
share
what
we
did
and
it's
great
for
learning.
H
But
you
know
I
would
really
like
to
given
the
interest
that
we
take
advantage
of
this
and
keep
building
on
it,
but
thank
you,
everyone
for
participating,
thank.