►
From YouTube: IETF106-MBONED-20191121-1550
Description
MBONED meeting session at IETF106
2019/11/21 1550
https://datatracker.ietf.org/meeting/106/proceedings/
A
C
C
C
C
F
C
F
F
F
I've
asked
a
couple
of
times
on
list
and
I
haven't
seen
any
other
suggestions
on
where
this
could
possibly
cause
a
problem
and
also
I
haven't
seen
very
many
updates.
So,
and
this
is
some
really
compelling
argument
made
soon,
I
don't
see
that
it
makes
sense
to
deprecate
the
current
RFC
and
publish
a
new
one
saying
you
know
this
is
exactly
the
same
just.
What
number
is
different,
of
course
feel
free
to
try
and
convince
me
otherwise.
C
G
And
stick
with
us
so
much
if
I
remember
correctly,
but
I
thought
that
this
would
always
happen.
If
the
router
is
like
one
hop
away:
yeah,
that's
alright!
It's
the
first
hop,
but
if
you're
tracing
a
destination
further
away,
it
doesn't
happen.
Where
doesn't
that
what
happens?
Just
for
the
obvious
for
the
first,
you
probably
get
like
a
star
for
your
first
hop
and
then
it
starts
working
for
the
further.
F
Hops
so
traceroute
starts
at
a
port
number
and
increments
it
on
every
hub,
actually
increments
it
for
every
packet
it
since
three
to
the
first
three,
you
know
increments
one,
two,
three,
what
four
five
six,
so,
unless
your
trace
routing
to
the
device
that
has
that
is
it's
your
first
hop,
that's
the
only
time
that
that
port
number
would
be
used
for.
Second
half
that
would
be,
you
know,
put
that
starting
number
plus
4/3
hop
would
be
starting
number
plus
7.
F
So
it
was
only
if
your
trace
robbing
to
an
increase
to
capable
router,
and
it's
your
first
hop
and
what
you
get
is
one
drop
packet,
so
you'll
see
one
star
and
then
everything
will
work.
This
is
the
same
behavior
that
you
often
see
like
afar,
peasant,
fully
finished,
sorting
its
life
out
or
similar.
So
I,
don't
really
see
it
causing
confusion
to
anyone.
I
can
draw
it
out
on
paper,
because
I
could
took
me
a
while
to
work
my
way
through
it.
Okay,.
G
F
So,
no
it's
not
it's,
not
wonderful,
but
to
get
a
new
port
we'd
have
to
deprecate.
The
current
document
write
a
whole
new
document,
saying
this
document
deprecates
the
old
RFC
and
here's
a
new
RFC
which
does
the
same
thing.
Just
this
is
different
and
it
causes-
or
you
know
we
could
do
that.
The
I
didn't
see
very
many
responses
to
the
email
thread.
I
I,
don't
think
we
sent
a
couple
being
like.
Is
this
okay?
Is
this
okay
and
didn't
see
an
update?
F
If
the
working
group
really
wants
to
do
this
and
is
willing
to
push
on
it,
I
will
be
happy
to
change
my
mind
but
I'm,
not
sure.
If
that's
what
the
working
group
wants,
Jimmy
it,
the
failure
mode
is
sufficiently
unusual.
It's
very
seldom
that
I
would
trace
route
to
my
first
top
router
and
if
it
doesn't
work,
I
see
one
star
and
I
can
probably
figure
out
what
it
is.
I'm
not
gonna,
be
like.
Oh,
my
God,
my
routers
down
I'll
just
be
slightly
confused.
F
If
I'm
trace
routing
to
my
first
top
router,
which
seems
like
an
unusual
thing
for
people
to
be
doing
it's
on
the
same
subnet,
so
if
I'm
trace
robbing
to
rabbits
on
my
same
subnet,
that
seems
unlikely,
maybe
I'm
wearing
that
poorly.
You
know
if
I'm
181,
6,
8,
5,
5
and
I'm
trace
routing
to
182
once
it's
a
1-1.
F
H
Think
that
is
try
to
be
a
problem,
even
though
the
you
can
trace
the
unicast.
Try
so
I'm
trace.
Finally,
but
always
in
the
same
situation,
always
the
first
roadblock
I
just
dropped
a
packet
or
ignored
pocket,
and
always
you
see
s
star
this.
For
me,
it's
a
strange
so
and
the
that
kind
of
situation
can
be
addressed.
If
we
change
the
port
number,
then
why
don't
we
don't
change
the
port
number
so
the
program
currently
the
program
is
ionic
self
doesn't
want
to
just
sorry
for
saying
this,
but
doesn't
want
to
accept
the
offender.
I
H
That's
why
this
is
a
problem.
They
say
it's
not
a
failure.
It's
a
implementation
problem.
It's
a
linux
unicast
trace
implementation
problem,
so
there
is
no
variation
with
empty
specifications.
There
is
no
problem
of
iron,
a
specification
huai,
an
assignment.
Only
the
problem
is
a
existing
Linux
unicast
race
round.
So
everyone
said
we
don't
have
any
problem,
but,
honestly
speaking,
if
the
Ayana
accept
that
kind
of
a
situation
and
then
they
assigned
a
new
port
number,
then
everything
become
a
crime
and
it
looks
beautiful.
H
So
my
personal
opinion
is
that
Ayana
I'd
like
to
ask
them
to
redefine
the
new
port
number
for
M
tries
to
and
the
new
emirate
race
to,
LEC
will
be
published.
As
with
the
statement
that
we
had
a
some
conflict
of
the
poll
number
them,
there
is
no
specification
change
and
we
don't
say
it's
it's
not
it's
due
to
the
I
on
evolution
assessor.
This
is
just
a
problem
of
the
existing
implementation.
That's
why
we
publish
the
new
RFC,
that's
all
and
then
the
finally
everything
looks
good.
F
If
the
working
group
wants
to
send
me
a
new
document
that
says
that
and
the
working
group
Grady
wants
to
push
for
it,
as
I
said,
unless
you
know
the
discussion
happened
a
while
back
it
kind
of
stopped,
so
I
thought
people
didn't
care.
If
the
working
group
really
wants
to
push
for
it.
Iron
has
said:
they're
happy
to
change
it.
Oh
some
people
and
I
on
a
happy
Joe
touches.
A
little
Joe
Joe
touch
is
pushing
back
he's,
not
part
of
Vienna.
F
We
I
mean
I'm
sure
we
can
make
it
happen
if
the
working
group
is
willing
to
push
for
it.
I
should
point
out
that
the
only
time
that
the
shows
up
it's
not
for
the
first
top,
rather
it's
only
when
you're
traced,
routing
to
the
first
hop
router.
If
you
trace
your
up
through
the
router
it
you
never
see
this
and
that's
the
common
case.
F
You
know.
Working
last
call
is
G
review.
Blah
blah
blah,
it
sounds
like
a
lot
of
work
for
a
situation
which,
to
me
seems
very,
very,
very
uncommon
but
I'm,
yet
the
working
group.
So
if
that's
what
the
working
group
one
so
we
can
try
it,
but
the
working
group
is
gonna
have
to
decide.
It's
not
my
decision.
Yeah.
F
C
G
Get
just
one
other
thing,
though,
so
so
if
I
Anna
does
nothing,
that
means
that
you
know
the
next
time
someone
asked
report
number
you
might
give
that
you
know
just
like
a
whole
range
of
port
numbers
right
and
if
I
Anna
now
at
this
point
we're
Baptists
where
they
start
handing
out
port
numbers
to
people,
you
will
start
having
this
problem
several
times
in
the
future
for
other
protocols.
So
have
you
thought
about
that?.
G
So
yeah,
so
it's
not
really
relevant
for
this
working
group,
but
I.
Just
wonder
if
there's
you
know
more
bigger
problem
here
that
will
show
up
and
if
it's
more
mr.
gets
the
next
port
number,
maybe
you
will
always
get
the
failure
when
you're
trace
writing
the
second
router
away
from
or
something
like
that,
yeah.
F
The
next
port
number
is
going
to
be
annoying
forever,
gets
it
and
the
one
after
that
and
yeah.
So,
yes,
I
Anna,
is
aware
of
the
problem
and
I
think
is
going
to
try
and
not
use
those
ports.
I
think
they're,
making
sort
of
a
note.
Part
of
the
problem
is
the
person
who
somebody
would
need
to
convince
Joe
touch
because
he's
the
port
registry
person
and
Joe
touch
seems
to
not
be
convinced
that
this
is
a
problem,
so
I
think
what
it
is
is
for
now.
F
Iana
is
gonna,
try
and
assign
from
other
sets
of
numbers,
but
Joe
seems
opposed
to
marking
all
of
these
ports,
as
you
know,
known
in
use
by
other
applications.
From
what
I
understand
he
said,
UNIX
implementations
should
all
just
replace
their
trace
route.
I
think
that
that's
what
he
said,
I'm
not
going
to
comment
on
that
yeah.
G
C
I
I
E
I
J
I
The
laser
pointer,
yeah
and
I
don't
need
this,
but
so
that,
with
that
particular
draft,
I
just
had
a
meeting
with
Erik
I,
don't
know
his
last
name
from
Cisco
ad
guy
and
what
I
see
it.
Thank
pinkie,
okay,
either
way,
and
so
that
particular
draft
is
under
his
review.
It's
been
sent
back
to
us,
the
author's
worn,
an
ID
or
they
Charlie
and
others
to
address
a
few
other
comments
and.
B
I
Of
those
comments
are
pretty
extensive.
Unfortunately,
even
though
we
just
are
kind
of
done
with
the
draft,
so
I've
been
kind
of
busy
updating
the
draft
and
we'll
continue
to
do
so.
So
just
make
a
note
for
the
notes
that
the
Wi-Fi
theta
2
to
11
multicast
considerations
draft
is
still
in
being
it's
in.
It's
an
ad
review,
I'm
gonna
get
to
these
dress,
so
this
is
these
drafts
are
just
an
advertisement
just
wanted
to
make
sure
that
M
bode
were
aware
of
this
work,
since
we
do
Oh
a.m.
I
types
multicast
work
here,
Greg
mirskiy
this
in
IP
PM
a
couple
days
ago.
I
ppm
is
IP
performance,
multi,
k5p
performance
measurement,
and
it's
only
been
focusing
on
unicast
up
until
now.
There's
solutions
such
as
I
ôm
that
many
of
you
may
be
familiar
with
inbound
in
band
o
a.m.
type
mechanisms
where
you
do
om
in
the
packet
instead
of
out
it
out
at
bound
out
of
band,
and
so
with
these
solutions
there
haven't
been
a
consideration
for
multicast,
so
multicast
traffic
monitoring
is
important.
I
I
presented
this
in
pim
ITF
or
two
ago,
and
there
were
some
interest
from
the
operator.
So
the
kind
of
the
purpose
of
me
presenting
this
draft
these
drafts
to
you
is
just
to
see
if
there's
any
interest,
if
there
is,
please
join
us
in
this
draft,
it's
being
worked
on
in
AI
ppm,
and
so,
let's
see
there
are
current
problems
with
the
existing
Toma
tree
techniques.
They
have
issues,
there's
not
a
branch
identifier
which
I'll
talk
about
in
just
a
moment,
and
there
is
unnecessary
application
right
now,
with
IO
am
techniques
for
unicast.
I
I
So
there
is
something
that's
called
postcard,
postcard
based
trees
and
it's
a
proposal
to
on
each
branch,
you're
sending
up
the
data
to
a
collector
along
the
path
and
so
that
until
now
also
hasn't
been
something
that
supported
multicast
until
recently,
and
so
with
this
draft.
What
we've
done
is
we've
added
a
branch
identifier
to
the
instruction
header
to
provide
a
indication
that
this
is
a
unique
branch
along
floo,
so
you're
able
to
send
up
that
data
to
a
collector
along
the
branch
and
these
different
branches
have
different
identifiers.
I
The
next
slide
so
greg
Mirsky
has
this
hybrid
2-step
solution.
It's
also
something
that
is
being
modified
to
be
able
to
support
multicast,
and
so
the
branch
node
fords
that
hybrid
to
step
over
the
first
branch
and
then
originates
follow-up
packets
downstream,
and
so
that's
something
that
he's
leading
I'm
not
on
that
draft
next
slide.
I
So,
there's
also
a
way
to
do
it.
Instead
of
per
node,
you
can
do
a
per
segment
in
coast
guard
base
telemetry,
and
so
your
a
post
card
is
sent
at
each
sections
end
node,
and
that
post
guard
contains
the
data
for
the
entire
section,
and
yes,
next
slide.
So
this
is
the
last
slide.
So
again,
your
participation
is
welcome.
Encouraged,
particularly
operators.
I.
I
I
L
M
So
hi
I'm
Dino
I
actually
have
two
presentations.
I
gave
this
in
the
list
working
group
in
Montreal
it.
So
it's
this
mobile
node,
which
is
running
lisp
on
a
mobile
platform
like
android
or
iOS
system,
and
this
was
a
unicast
demo
and
what
I
did
in
here
in
Singapore
coolest
working
group
is
give
a
multicast
demo.
So
I
asked
if
I
could
give
the
multicast
demo
here
and
thought
that
this
showing
unicast
first
may
give
some
good
background.
M
So
what
we're
demoing
is
this
iPhone
there's
a
iOS
implementation.
We
have
our
TRS,
which
are
a
little.
How
many
I
think
some
people
here
know
list,
but
it's
a
recap:
sleighing
tunnel
routers
are
deployed
in
google
cloud
in
AWS
and
the
list
mobile
node
to
list
correspondent
node
can
talk
to
each
other.
Behind
Nats
as
well
of
lismo,
will
know
to
non-lisp
correspondent
notes
behind
nets,
so
to
lisp
entities
are
on,
the
overlay
can
talk
to
each
other.
That's
what
the
third
bullet
is.
The
fourth
bullet
is
a
list.
M
M
So
some
magic
sauce
is
lisp
is
not
running
a
list
movin
those
not
running
a
control
plane.
That's
the
whole
point
of
this
effort
was
to
build
a
really
small
scale:
small
footprint
implementation
of
it.
So
basically
it's
configured
to
have
a
default
route
that
points
to
a
set
of
encapsulating
routers,
either
proxy
ETRS
or
RT
RS,
and
that's
something
that's
configured
in
the
implementation
user
would
have
to
configure
it
and
the
RT
R's
are
configured
to
glean
xtr
mappings.
M
So
unless
we
have
an
ant
traversal
proposal,
but
that
requires
control,
plane
messaging,
which
we
are
trying
not
to
do
here.
So
basically
the
NAP
proposal,
NAT
traversal
proposal,
uses
control,
plane
mechanisms,
but
this
gleaning
is
using
a
data
plane
mechanism.
So
all
the
logic
occurs
at
the
data
plane
and
this
isn't
an
effort
to
implement
a
lightweight
XDR
and
there's
a
use
case
that
we're
looking
at
to
do.
Traffic
reporting
using
h3
grids
that
that
Mexicans
doing
to
be
able
to
put
lisp
and
dash
cams
in
existing
automobiles.
M
So
here's
the
demo
topology
we
have
an
iphone
over
there
on
the
left
that
has
an
e
idea
of
13
and
a
docker
container.
That
was
that's
running
on
my
laptop,
that's
a
ID
14
and
then
we
have
two
non-lisp
notes
that
are
labeled
red
once
the
Google's
DNS
server
and
then
just
WW
disappears.
That
net
is
where
my
website
is
hosted,
but
it's
just
a
non-lisp
site.
Okay,
where
you
see
green,
that's
those
are
the
guys
that
are
part
of
the
overlay.
Where
you
see
red,
that's
the
underlying
routing
stuff.
M
M
L
M
K
M
Now
what
I'm
doing
is
I
switched?
Oh
I
switched
to
LTE,
in
other
words,
turn
Wi-Fi
off
in
the
connection.
Still
the
pings
are
still
happening.
If
you
look
in
the
RTR,
you
see
13
and
14
we're
talking
to
each
other
that
dark,
green
packet
counts
means
packets
have
been
forwarded
within
the
last
second.
M
These
have
been
forward
in
the
last
minute,
and
so
the
connections
happen,
the
phone's
going
through
166,
that's
my
AT&T
link
and
96
is
happening
in
the
container
on
my
laptop
sitting
at
my
house
using
Comcast
and
let's
see,
I
am
I,
going
back,
yeah
I'm,
going
back
to
Wi-Fi
now
and
then
you'll
see
that
the
arlok's
gonna
change
to
the
same
96.
Of
course
it's
using
a
different
port
number
because
we're
adding
through
my
house
and
that's
what
the
demo
is
supposed
to
show
cool.
M
Q
It
seems
that
the
new
list-
parts
I,
don't
know-
are
kind
of
to
make
the
staff
on
the
phone
smaller
a
lot
more
lightweight
and
support
net
and
so
on.
Right
is
that
just
true,
so
basically
the
phone
is
just
the
demo
thing.
The
the
actual
device
it
would
be
is
a
smaller
lightweight
IOT
device
like
a
dashcam
or
whatever.
Whatever
is
them
all
enough
just
to
have
the
radio
but
not
I.
Q
M
M
Okay,
so
next
thing
is
we
then
I
tried
basically
a
load
split
ping
test,
which
was
really
easy
from
the
container
2ww
lispers
net,
and
the
idea
here
was
is
that
let's
use
all
the
our
TRS
and
mode
split
traffic
and
what
this
is
showing,
that
is
on
the
container,
there's
a
0/0
that
goes
through
all
four,
our
pr's,
all
four
Artie
ours
that
are
in
one
in
Google
three
in
AWS
and
their
load
splitting
traffic
across
it.
So
that
was
another
thing,
meaning
we
could
do.
L
M
M
So
what
happens
was
when
I
was
sitting
at
Pete's
I
was
connected
to
Pete's
Wi-Fi,
and
you
know
you
always
see
Xfinity
Wi-Fi
all
over
the
place,
and
so
what
happened
was
as
I
was
drunk
as
I
was
at
at
Pete's
and
moving
around
I
was
switching
between
those
and
then
I
decided
to
get
in
the
car
and
start
driving
away
from
those
on
a
signal
from
those
guys
and,
of
course
ATT
AT&T
LTE
was
up.
You
know
it's
at
five.
M
R
Karl
Rossum
not
super
convinced
by
that,
because
don't
these
players,
just
you
know
like
buffer
stuff,
to
make
sure
that
there
is
enough
available
in
case
there's
a
temporary
connectivity
loss
I
mean
I'm,
not
saying
it
doesn't
work.
Yeah
I'm
just
saying
this
may
not
be
a
convincing
demonstration
of
that
yeah.
M
M
Okay,
so
some
caveats
about
what's
going
on
here
in
the
design
is
the
list
mobile
notes
must
send
before
it
can
receive.
Since
the
RTR
is
gleaning,
our
local
information
from
it
returned
packets
cannot
go
back
unless
it's
sent.
So
if
we
have
the
silent
source
problem,
we
have
this
in
so
many
designs
right.
This
is
the
problem,
so
mobile
knows
wanted
to
talk
to
each
other.
They
would
have
to
send
somewhere
else.
M
This
is
really
not
a
problem
because
soon,
as
I
bring
Lisp
up
on
the
phone,
it's
trying
to
talk
the
iPhone
with
all
the
applications
are
running
are
trying
to
talk
to
so
many
non
list
notes
that
they
are
able
to
send.
But
there
is
some
latency
associated
with
it
because
you
have
to
discover
the
source
you
have
to
punt
it
out
of
the
data
plane
and
then
put
it
into
your
map
cache
before
a
return
packet
comes
and
then
there's
also
the
asymmetry
problem
where
the
mobile
node
1.
M
Since
the
RTR
one
and
the
return
traffic
comes
through
our
TR
2.
Then
the
gleaned
information
is
not
an
RT
R
2,
so
that
asymmetry
causes
a
problem
but
and
they
they
must
do
that.
They
have
to
use
the
same
five
tuple
hash
on
both
sides
and
be
configured
with
the
same.
Our
TRS
on
both
sides
and
then
there's
symmetric
forwarding,
go.
G
M
G
M
M
So
we
want
to
be
able
to
figure
out
if
from
the
or
our
point
of
view
on
the
phone,
if
the
RTR
is
are
reachable
versus
not
and
when
they're
not
reachable,
they
use
the
other
ones
that
they
have
configured
and
we
want
to
be
able
to
use
list
crypto,
which
is
data
plane
encryption.
So
the
our
log
probing
has
to
contain
key
exchange
and
we
have
an
RFC
for
that
that
that
is
used,
but
we
want
to
increase.
M
We
want
to
change
the
implementation,
to
support
that
and
then
maybe
support
multiple
Eid
and
instanceid
support.
So
if
you
have
professional
vert,
you
know
it's,
it's
a
work
phone
or
is
it
a
personal
phone
and
you
want
to
run
separately?
You
could
be
able
to
do
that.
So
multi-tenancy
support
is
what
that
is,
and
then
I.
Of
course,
I
said
in
Montreal
we
got
a
new
multicast
that
completes
a
picture
and
show
that
at
this
IETF,
and
so
that's
what
I'm
about
to
show
you
now
yeah
go
ahead.
R
R
Know
the
only
reason,
women
why
I'm
asking
is
you
don't
run
into
this,
isn't
limited
to
working
on
certain
kinds
of
Nats
right?
You
don't
run
into
the
problems
that,
like
the
stunner
turn,
people
did
it's
just
once
you
make
an
outbound
connection
in
that
port
assignment
on
the
NAT
is
stable
and
you
use
it
for
everything.
On
the
correct.
Okay,.
S
R
M
M
R
M
A
dynamic
encapsulating
tunnel
in
uni,
P,
yep,
okay,
so
multicast
we
can
go
through
this
quick.
So
what
are
we
doubling
here
again?
Let's
mobile
node
on
the
iPhone,
the
RT
R,
is
deployed
in
GCP
and
we're
only
talking
list
to
list
spawn
here,
because
it
was
difficult
to
do
non
list,
but
I
have
a
surprise
at
the
end
that
will
you
guys
might
enjoy
so
all
multicast
sources
and
receivers
are
on
the
list.
Overlay
is
basically
what
the
demo
is.
M
M
So
this
mobile
node
is
a
multi.
You
ask
multicast
receiver.
Well,
when
you
bring
up
the
application
on
the
phone,
it
will
send
an
IGMP
report.
Of
course
the
IGMP
report
is
just
in
capsular
like
any
other
packet,
so
the
RTR
contract
group
memberships
from
all
the
IGMP
reports
it
received,
and
then
the
RTR
just
replicate
the
packets
to
all
the
group
members,
no
matter
where
they
were
where
they
could
be.
M
So,
basically,
the
demo
is
showing
that
the
list
mobile
mobile
node
can
maintain
multicast
session
continuity
by
switching
between
Wi-Fi
and
LTE,
either
as
a
receiver,
a
multicast
receiver
or
as
a
multicast
source.
Okay.
So
so
the
demo
setup
is
pretty
much
the
same
as
last
time
we
have
thirteen
running
low
R
and
you
have
twenty
five
and
fourteen
as
two
containers
running
and
we're
gonna
do
two
types
of
sub
demos.
M
M
You
could
almost
hear
it:
okay,
I'm
about
to
tap
that.
Oh,
maybe
I'm
gonna
tell
you
about
who's
who's
receiving
first
yeah,
that's
I'm,
going
to
show
you
so
the
two
things
are
joined
to
the
group.
24
2.
The
way
they
do
that
is,
they
register
to
the
mapping
system
and
this
replication
list
entry
is
added.
So
these
are
the
our
looks
for
Eid,
25
and
14,
and
now
the
the
pea
is
the
ping
is
going
and
you
see
it
appearing
there.
M
I'm
showing
you
two
packets
are
moving
now
I.
Think
I'm
gonna
switch
I'm
about
to
switch
sorry
about
my
hands
and
there's
an
interesting
filming
problem.
Here.
I
dropped
the
camera
it's
sitting
on
an
easel
and
I
smash
it.
So,
let's
see,
if
you
actually
noticed
it,
I
was
pretty
quick
picking
it
up.
So
now
it's
LTE
and
you
see
the
pings
go
and
then
I'm
gonna
show
you
how
the
gleaning
changed
from
the
73
Comcast
address,
there's
13,
but
we're
not
sending
any
packets
of
13,
even
though
that
was
updated.
M
I'm
starting
there,
it
is
so
VLC
I'm
starting
VLC
as
a
source
here
on
25
and
then
I'm
going
to
join
VLC
on
me
as
a
receiver
on
the
phone.
That's
what's
happening
right
now,
so
that
source
is
false.
Starting
up,
it's
going
to
be
a
waterfall,
so
you'll
hear
some
static.
That's
the
actual
Falls
coming
down
in
the
video
there's
VLC
coming
up
and
when
I
tap
on
to
24
1
1
1.
M
That's
when
the
IGMP
report
is
going
to
be
to
the
RTR
and
once
I
do
that
we'll
show
the
RTR
to
see
that
224
one
one
one
was
joined,
oh
I,
don't
know!
If
you
can
hear
there's
the
Falls,
you
can
see
the
Falls
moving
and
stopping
I'll
tell
you
that
why
bat,
in
this
case
there's
224
one
one
one
and
thirteen
joined
to
it.
When
it's
our
look
note
it's
a
166,
our
look,
which
means
it's
LTE
still.
G
M
Of
audio
but
now
note
this,
this
is
actually
all
the
receivers
and
sources
are
at
my
house
going
all
the
way
deep
into
GCP
and
back
and
that's
why
you
see
these
delays,
because
because
the
RTR
everything's
hair
pinning
right
because
it's
it's
a
long
path,
so
the
RTR
is
not
placed
in
the
best
spot
where
all
the
sources
and
receivers
are
and
that's
always
been
a
problem.
We've
had
with
you,
know,
rendezvous
points
and
amt
relays
and
stuff
like
that.
So
now
I
switch
back
to
Wi-Fi.
You
see
the
73
address.
M
So
some
observations,
glean
latency
does
not
exist
as
it
does
for
unicast.
So
that
means
that
the
reason
it
doesn't
exist
is
because
it's
a
unidirectional
flow
going
from
the
phone
to
the
receivers.
The
gleaning
information
for
unicast
would
only
be
useful.
Unicast
packets
were
coming
back
so
since
the
source
is
just
sending
to
the
RTR
gleaning
as
a
source
is
not
important,
but
of
course
it
is
important
as
a
receiver.
However,
you
can't
get
the
multicast
data
until
you
send
the
IGMP
record.
M
So
when
you
send
the
IGMP
report,
the
group
membership
is
added
and
the
gleaning
happens
at
the
same
time.
This
is
where
multicast
has
an
advantage
of
your
unicast.
Now
the
problem
is
is
if
members
are
spread
across
our
TRS,
the
list
mobile
node,
needs
to
sense
all
our
tiaras,
and
so
we
have
a
draft
called
this
replication
engineering
that
shows
how
to
put
layers
of
replication
engines
in
since
this
is
an
overlay
replicating
multicast
packets
in
unicast
packets.
We
have
two
Eaton
doing
head
end
replication
at
various
spots.
M
M
D
G
M
Answers
yes,
and
that's
also
segue
into
the
next
slide.
Okay,
so
the
RT
are
typically
d
caps
and
Riaan
capsule
eighths,
if
it
just
D
caps
and
needs
to
place
it
on
an
interface
that
would
go
into
an
e
TR
function.
But
it's
just
a
matter
of
that.
The
the
e
TR
knows
not
to
do
another
map.
Cache
look
up
to
try
to
re
encapsulate
it,
because
it's
at
the
end
of
its
thing
right.
Good,
good
question,
though:
how
am
I
doing.
E
M
An
IgM
PV
to
join
on
the
group.
Ok,
and
what
I
decide
to
store
in
the
mapping
system
is
a
0,
slash,
0,
comma
225,
1
1
1,
so
that
is
a
source
specific
join
kind
of,
but
it's
really
star
G,
because
it
means
everything
and
the
reason
I'm
doing.
That
is
because
I
don't
want
to
inundate
the
mapping
system
with
Eskimo
G's.
So
it's
really
a
star
comma
G
design
without
an
RP
purposely
done
that
way.
Okay,.
Q
M
Q
M
M
D
Q
M
M
It
may
go
beyond
the
demo,
so
I,
don't
yeah
you
yeah
well,
I
mean
I.
Could
a
quick,
really
quick
answer?
You
can
access
control
by
limiting
whoever
sends
map
requests
to
the
mapping
system.
You
can
say
who
who
gets
answers
versus
not
so
now
in
this
lightweight
control
mechanism,
a
map
request
is
never
sent
by
the
phone
because
it
always
matches
0/0.
M
Yeah,
okay,
so
we
just
started
this
a
couple
weeks
ago.
This
is
kind
of
work
in
progress,
but
Lenny
wanted
to
try
some
stuff
where
he
said:
can
we
source
some
packets
from
a
mobile
phone
and
Lisp
and
then
bring
it
into
the
AMT
cloud?
And
actually,
just
this
morning
we
got
it
working
what
we
got
working
as
a
when
at
the
list
working
group
I
said
I.
K
M
I
really
want
to
do
it
to
work
as
I
wanted
to
show
you
guys
an
EM
buddy
what's
going
on
here,
so
the
idea
is,
we
were
just
using
ping
as
a
source
from
the
phone
and
of
course
we
had
to
list
receivers,
and
then
we
have
this
et,
and
so
so
basically,
the
the
GRT
are.
One
was
replicating
the
three
places
now
what's
really
interesting,
we
did
this
at
the
Olympics
as
well.
What's
really
interesting
here
is
that
packet
is
being
sourced
by
13
to
224
333.
M
M
L
M
Pf
works
all
the
way
through
the
cloud,
so
the
packet
actually
makes
it
through
that
native
multicast
cloud
and
the
ante
that
relay
then
picks
it
up
and
replicates
it
to
the
gateways
that
have
been
joined,
2
to
24,
3,
3
3.
So
the
all
ours
running
on
the
phone
list
first
met
on
the
our
tyranny.
T
are
in
a
Juniper,
as
the
AMT
relay
so
did.
I
answer:
stick
in
Jake's
question.
G
T
D
D
Okay,
so
the
goal
here
is
to
receive
multicast
in
Java
their
JavaScript.
This
is
a
you
know,
and
the
goal
behind
that
goal
is
to
port
receivers
to
web
assembly
and
distribute
them
over
web
pages.
I
want
to
I
specifically
want
to
include
here
proprietary
players
and
downloaders,
because
well,
I
have
one,
and
there
are
something
like
six
at
least
others
out
there
and
plus
BBC's
thing
and
I
would
like
all
of
them
to
work.
D
So
we
can
just
sort
of
fight
those
protocols
out
in
production
and
see
what
actually
performs
the
best,
and
the
goal
is
my
main
two
use
cases
are
playing
video
and
downloading
files.
There
may
be
other
things,
but
those
are
the
things
I.
Actually,
the
second
goal
is
to
do
so
safely,
so
that
well
so
that
it
can
be
accepted
into
the
browser,
check-ins
sort
of
ecosystem.
D
D
D
D
To
provide
the
information
necessary
to
authenticate
per
packet
that
the
data
that's
being
received
by
the
browser
or
even
by
a
sort
of
multicast
firewall,
you
can
think
of
it.
So
you
can
put
one
in
the
network
to
prevent
injection
from
outside
it.
For
example,
an
angel
point
with
your
EMT
campaign
and
then
sivak
is
another
different
usage.
D
Extending
the
metadata
is
such
that
you
can
detect
whether
you're
going
to
be
over
subscribed
so
that
you
can
maintain
your
safety
thresholds
about
how
much
traffic
you're
willing
to
be
subscribed
to
and
avoid
joining
the
the
flow.
If
you
would
have
exceeded
that
threshold,
there
have
been
some
suggestions
about
about,
maybe
providing
a
way
to
trim
it
I'm
totally
open
to
that.
This
is
still
very
early
work,
but
these
are
the
general
outlines
of
what
this
is
trying
to
accomplish.
D
The
way
that
it's
implemented
or
the
way
that
it's
it
would
move
forward.
Is
that
the
there's
this
JavaScript
over
on
the
left
and
it's
just
gonna-
create
a
multicast
receiver
object
and
pass
it
a
callback
for
receiving
data.
So
you
just
issue
a
join
and
you
start
receiving
authenticated
payloads.
If
you
are
indeed
successful,
this
can
do
the
tunneling
with
the
Dryad
that
we've
that
we
they've
been
the
is
I
guess
just
gone
to
last
call
I.
Think,
and
the
idea
is
that
inside
the
browser
you
can
provide
all
the
guardrails.
D
So
all
these
all
these
pieces
that
are
trying
to
provide
safety
to
the
network,
even
if
the
JavaScript
is
malicious.
It's
it's
limited
in
what
it
can
accomplish,
because
the
browser
is
going
to
notice
that
oh,
you
tried
to
join
something.
That's
too
big
that'll
blow
out
the
network
or
the
blow
out
the
thing,
and
it's
also
going
to
be
able
to
monitor
the
loss.
D
If
it
turns
out
that
this
is
even
worse
than
me,
then
we
thought
for
whatever
reason,
in
addition
to
the
browser
providing
safety
checks,
the
network
also
can
access
the
same
meta
data
and
you
can
operate
a
sort
of
empath,
a
network
firewall
that
can
that
can
do
the
same
kinds
of
operations
using
the
same
metadata
which
I'll
go
over
again
in
a
moment.
Now,
then
the
the
authentication
and
loss
detection
is
you
may
or
may
not
that
you
choose
to
run
it
in
your
browser.
D
This
is
a
written
it,
as
in
my
router,
but
I
think
of
it
in
practice,
probably
more
than
in
jest
point
or
at
a
you
know,
joke
point
of
some
sort
for
your
network,
so
dorms
dorms
is
discovery
of
rest.
Comp
metadata
for
SSM,
I've
defined
a
very
small,
very
simple
yang
model
for
and
the
intent
is
to
limit
in
a
restaurant
server
and
to
use
this
to
publish
indexable
metadata,
/
SG,
so
that
you
can
provide
that
the
so
as
a
sender
as
a
source
of
traffic
I
can
put
up
my
my
dorm
server.
D
I
can
seed
it
with
the
metadata
about
my.
My
streams
and
I
can,
and
then
anybody
who's
trying
to
join
traffic
that
I'm
that
I've
provided
would
have
access
to
fetch
it.
From
from
my
from
my
dorm
servers
using
these
nicely
well-defined
web
api
is
essentially
that
the
that
specified,
the
the
format
and
the
meaning
of
the
various
fields
within
the
within
the
the
the
HTTP
requests
are
going
back
and
forth.
D
D
You
know
when
the
browser
is
going
to
require
access
to
the
metadata,
then
from
the
from
the
server
side,
you
can
check
the
origin
header
and
refused
refused
to
allow
browser
that
you
know
like
malicious
ads,
that
came
from
the
wrong
kind
of
paid
to
join
there
to
join
a
stream
from
an
inappropriate
source
just
by
refusing
to
provide
the
metadata
to
the
browser
right,
so
it
there's
a
viable
threat
model.
That
is
that
is
prevented
from
from
executing.
D
So
it
looks,
like
is
as
find,
is
just
you're
going
to
issue
a
a
yet
for
the
metadata
it
has
the
SG
provided,
and
then
you
get.
You
know
the
the
dorms
substrate
for
passing.
The
metadata
is
very
stupid
and
has
almost
no
useful
information.
It
just
has
the
structure
of
where
the
SG
is,
but
when
you
put
metadata
into
it,
it's
done
as
an
augment
of
the
of
the
dorms
metadata.
D
D
The
idea
here
is
that
you
are
going
to
provide
an
authenticated
stream
of
out-of-band
manifests.
The
manifests
contain
hashes
of
all
the
packets,
so
that
when
you
are
receiving
your
multicast
packets,
now
you
can.
You
have
an
authentication
stream
which
is
provided
authenticated
through
an
out-of-band
mechanism,
and
you
just
cross
check
your
manifests
with
your
hashes,
so
that
so
that
you
can
decide
the
things
that
you've
received
are
the
things
that
the
sender
actually
sent.
D
You
and
the
the
you
know
the
things
you
did
not
receive
were
the
sender
thinks
he
sent
them
to
you,
so
they
must
have
been
lost.
Okay,
the
things
one
looks
roughly
like
this:
you've
got
the
receivers
down
on
the
bottom
right
and
they
you
know.
If
you
get
a
pack
up
without
hash,
it
was
moved
or
correct.
Hash
without
a
packet
is
lost.
D
D
So
in
phase
2,
we've
talked
about
this
a
little
bit
before,
but
the
goal
is
to
turn
it
into
something.
That's
going
to
have
that's
going
to
have
signatures
inside
the
multicast
data
streams
so
that
you
can
authenticate
by
listening
to
the
multicast
stream,
and
then
you
will
not
have
1
2
3
percent
of
unicast
data
overhead,
but
you'll
have
this
similar.
It
might
be
a
little
higher.
It
might
be
like
5%
overhead,
but
it'll
be
inside
the
multicast
stream.
R
Rose
yeah,
just
to
the
point
about
the
hash
length,
I
think
we
we
expect
to
have
a
fight
with
the
security
Directorate
over
how
long
the
hashes
need
to
be
relative
to
how
timely
the
data
is.
Basically,
you
know
if
you're
the
data
is
only
valid
for
two
minutes.
Then
do
you
really
need
a
32-bit
hash,
not
clear
yeah?
D
C
D
I
D
As
far
as
I
see
okay,
so,
let's
see
back
the
idea
is
that
you,
the
the
metadata,
provides
a
max
bitrate
for
the
stream
and
the
you
know
the
the
place
at
which
the
the
controller
is
operating,
which
would
be
in
the
browser,
certainly
and
also
perhaps
in
the
network.
I
think
this
is
more
useful
in
the
network
than
the
authentication,
probably
as
opposed
to
the
browser.
But
regardless
you
can.
We
can
operate
it
anywhere
that
can
cut
off
the
multicast
stream
or
trim
it.
D
But
the
idea
is
that,
with
the
max
bitrate
information
that
you've
got
inside
the
inside
the
metadata,
you
have
enough
information
to
decide
whether
the
bit
rate
that
you're
subscribing
to
is
safe
for
the
context
you're
operating
all
right,
so
the
so
that
you
know
the
other.
The
extreme
that's
going
to
South
Korea
will
not
be
going
into
the
you
know.
World
Indiana.
D
If
there's,
if
there's
too
much
loss
happening
and
provides
some
kind
of
an
event
based
back-and-forth
with
the
with
the
JavaScript
to
notify
them
that
they're
about
to
be
cut
off
and
let
them
respond
gracefully
and
then
cut
them
off
they
don't
and
and
to
notify
them
about
the
loss
their
that
they're
experiencing,
and
to
maintain
that
within
the
browser
context,
regardless
of
what
the
JavaScript
does
in
the
router
case,
it's
I.
Imagine
it
being
a
more
sort
of
managed
case.
D
That's
that's
up
to
the
network
to
implement
how
much
multicast
traffic
you're
going
to
permit
in
your
network.
And
you
know:
what
percentage
are
you
going
to
put
on
which
interfaces
and
that's
just
sort
of
up
to
you
to
configure
or
let
your
you
know
your
systems
automatically
configure,
but
the
goal
is
that
any
place
that
needs
to
even
when
there's
a
broken
link
downstream,
something
that's
misbehaving,
an
agent,
that's
not
a
browser
say,
can
join
these.
D
These
things
also
I
would
like
the
networks
to
be
able
to
provide
the
multicast
service
and
when
they
are
providing
multicast
service,
they
have
to
have
some
kind
of
same
protections
against.
You
know
how
this
works.
Now
there
is
a
ping
population
count
RFC.
That
I
think
is,
is
work
well
and
interesting,
so
that
yeah
is
that
yours,
yeah
thanks.
So
this
is
a
this
is
a
really
helpful
if
it's
implemented
way
to
sort
of
decide
with
you
know
from
an
upstream
router,
which
are
the
things
that
are
worth
cutting
off.
D
D
Implementation
is
early
days,
but
but
we
do
have
some
pieces
of
this
that
are
starting
to
come
together.
So
the
intent
here
is
a
published,
a
a
a
multicast
received
library,
that's
SSM
oriented
and
my
intent
is
to
add
all
this
functionality
into
that
library.
Over
time
now,
I've
taken
this
library
and
I
put
it
into
into
the
PI
taps.
Implementation
and
I've
also
run
a
prototype
running
inside
chromium
to
receive
the
data
and
pass
it
into
a
JavaScript
API.
D
It
does
not
yet
implement
all
the
bells
and
whistles
that
I
talked
about
here,
but
the
you
know
just
to
make
sure
that
it
kind
of
works.
Those
those
pieces
are
together
and
then
this
time
attacked
on
with
the
help
max
attack,
we
put
a
Python
implementation
of
ambe's
so
that
we
can
send
the
manifests,
validate
the
data.
That's
received
and
check
it
before
passing
it
into
the
application
that
that
would
be
using.
So
this
is,
you
know,
a
food
concept.
We
didn't
run
into
any
trouble.
D
Obviously,
there's
put
the
actual
dorm
servers
up
and
and
do
some
some
work
on
C
back
expect
to
iron
out
some
some
of
the
pieces
there
and
add
tunneling
to
the
to
the
received
library.
Probably
certainly
the
DNS
SD
find
the
local
aunty
relay
idea,
and
perhaps
optionally
also
the
the
Dryad
based
remote
tunnel.
D
So
I
was
thinking
about
asking
for
adoption.
I
kind
of
would
like
to
for
for
the
three
ITF
drives
and
I
want
to
report.
That
I
spoke
briefly
with
Ben,
get
it
he's,
secure,
EAD
and
also
with
with
David
black,
the
ETS
V
W
Jeter,
and
about
the
appropriateness
of
adopting
things
like
C
back
which
might
properly
live
in.
I
D
If,
if
the,
if
the
working
group
believes
that
this
is
worthwhile
and
useful
and
I
think
that
with
the
intent
to
make
this
a
sort
of
inter
domain
multicast,
you
know
in
this
case
to
make
that
realistic
that
the
ammonia
is
the
appropriate
place
to
do
this.
But
I
leave
that
to
to
the
chairs
in
the
group
to
consider.
J
D
Now,
there's
a
there's
a
little
bit
of
a
caveat
on
that,
because
which
I've
called
out
in
the
in
the
proposal
in
the
explainer
of
the
proposal,
which
is
that
the
privacy
guarantees
are
in
many
cases,
the
browser's
are
very
concerned
about
privacy
guarantees
and
some
of
these
privacy
guarantees
are
not
going
to
be
possible
with
the
multicast
receive
functionality,
because
if
you
have
an
adversary,
that's
your
next
hop
router.
They
are
going
to
be
able
to
determine
what
that
multicast
stream
represents
pretty
much
when
you
join
it.
D
You
have
to
assume
that
this
is
that
this
is
possible
for
them
to
do
regardless
of
whether
you're
encrypting,
your
S&I
or
what
right.
So
you
know
if
you,
if
you
need
to
hide
that
from
them,
for
whatever
reason
you're
gonna
have
to
beat
the
end
of
somewhere,
that
you
trust
and
then
turn
a
little
over
that,
because
you
know
so
I
think
that's
not
a
showstopper
for
this.
D
It
might
constrain
the
kinds
of
things
that
should
be
distributed
over
this
kind
of
protocol
because
the,
but
it
should
be
it-
should
match
up
pretty
well,
because
the
intent
is
to
do
things
they're
so
popular
that
many
people
are
doing
it
right.
That's
where
you're
getting
gained
by
doing
anything
with
multicast
receive.
D
So
so
that's
one
caveat,
but
it
it
seems
to
be
okay
on
that
front
as
well
outside
that,
like
the
the
reason
that
they
took
you
to
be
out
of
out
of
chromium
was
like,
because
sending
is
a
terrible
idea
to
let
javascript
to
write
all
that
big
isn't
malicious
right
so,
but
this
is
a
receive
only
API.
So
that's
not
that's,
not
an
issue.
Okay,
so
any
questions.
That's
that's.
All
I
have
comments.
D
There
Xena
yeah
so
I'm,
the
only
one,
that's
done
anything
with
it
yet
I
mean
max,
has
has
participated
with
me
in
the
hackathon
project
and
that
was
built
on
top
of
this
we've
integrated
it
into
PI
taps.
So
that
is
there's
a
dependency
there
that
C
no
established
now,
but
but
that's
not
actually
used
by
anybody
except
our
own
little
project.
So
this
is
yeah,
it's
not
really
widely
deployed
and
it
doesn't
really
do
anything.
Yeah
I.
G
D
D
Yeah,
so
when
I
the
way
I
envisioned
it
working
is
I
mean
the
way
I
intend
to
use.
It
is.
Is
that
now
that
this
JavaScript
API
is
there
once
it's
there?
Then
all
I
have
to
do.
Is
port
my
existing
player
to
webassembly
and
plug
this
in
as
the
receives
path
for
the
for
the
multicast
traffic,
and
then
the
browser
provides
these
guardrails
as
such
as
it
is,
and
then
my
my
behavior
as
long
as
it
can
live
within
these
guardrails.
U
Hi,
thank
you
very
much.
Craig
Taylor
as
an
individual,
the
point
about
the
pervasive
monitoring
and
the
joins,
etc.
Is
own
I
think
it's
just
a
note
for
security
considerations.
I
gave
this
a
lot
of
thought
previously
and
you
need
significance
orchestration
within
the
environment,
to
centralize
the
joins
in
some
manner
to
you
know
you
know.
U
D
Okay,
if
there's
nothing
else,
thank
you
very
much.
Please
do
read
the
drafts.
If
you
get
a
chance
said
that
I
want
to
thank
Morton,
Peterson
I
believe
he's.
He
did
apparently
do
so
and
send
a
note
to
the
list
and
in
support
any
feedback,
any
commentary
any
support
order.
This
is
terrible
because
X
would
be
most
welcome.
C
D
D
D
Yes,
I
would
like
to
request
all
three
I
think,
based
on
my
conversations
with
with
Ben
and
David
I.
Believe
all
three
are
appropriate,
I
think
I'm
making
claim
myself
the
dorms
is
appropriate
and
without
without
any
otherwise
review
yeah.
My
my
concern
here
is
that
I'm
skeptical
enough
people
already
proven
wrong.
That
would
be.
C
Read
them
each
twice
right:
you've
guilted
me
into
a
night:
we
went
through
the
slides
and
I.
Let
him
again
so
excellent,
whose
read
any
combination
of
these
is
a
start
anywhere
in
okay,
excellent
who's,
read
all
three
of
them
are
the
same
same
group.
Who
thinks
is
the
stuff.
We
should
adopt
an
M
Bundy
yeah,
but
the
notes
say
we
need
to
do
this
work
fantastic.
Thank
you.
So
much
Clark
pardon.