►
From YouTube: IETF101-MBONED_PIM-20180320-0930
Description
MBONED PIM meeting session at IETF101
2018/03/20 0930
https://datatracker.ietf.org/meeting/101/proceedings/
A
A
A
Mike
will
be
speaking
about
his
datacenter
deployment
draft,
giving
an
update
on
that.
Tim
will
be
talking
about
the
deprecated
ASM
for,
inter
dome
inter-domain
deployments
draft.
We
have
a
very
special
presentation
on
from
William
Chang.
He
is
a
high
school
student
from
Thomas
Jefferson,
High,
School
and
he's
for
his
senior
project
he's
been
deploying
and
operating
an
AMT
public
AMT
relay
on
that's
connected
to
i2
and
the
commodity
internet.
A
Okay,
moving
along
status
of
the
active
working
group
drafts
so
first,
the
internally
and
peering
draft
has
been
when
I
had
been
around
for
a
long
time
and
since
the
last
IETF
it
has
finally
become
an
RFC.
So
congratulations
to
Percy
and
team
8313
currently
in
last
call
are
currently
at
IAS.
G
is
the
M
tres
draft,
while
it's
been
there,
it
has.
There
have
been
a
number
of
good
helpful
comments
and
discuss
issues.
A
A
No,
so
their
comments
somewhat
speak
for
themselves
last
week.
Hopefully
this
should
be
enough
to
clear
up
the
discuss
issues,
and
hopefully
we
can
move
that
along
the
since
last
ITF,
the
Wi-Fi
problems
draft
was
was
adopted
by
the
working
group
and
I
believe
it
was
merged
with
another
draft.
Mike
and
Charlie
are
going
to
provide
updates
on
that
and
there's
the
data
center
deployment
draft
Mike's
going
to
talk
about
that
today.
Other
draft
that
have
not
yet
been
adopted
is
the
yang
models.
A
Draft
sandy
will
give
us
an
update,
but
essentially
he
took
that
since
last
meeting
he
took
that
to
the
yang
doctors
and
the
yang
doctors
did
give
some
comments
and
helpful
feedback
and
he
has
updated
the
draft
I'm.
Sorry
she
and
the
the
multi-cat
the
models
draft
was
one
two
went
for.
Adoption
call
didn't
quite
get
enough
support
for
for
adoption.
A
However,
there
was
some
a
little
bit
of
confusion
as
to
what
it
was
saying.
It's
been
trimmed
down
to
just
focus
on
the
deprecation
of
a
of
ASM,
less
so
on
my
models
and
Tim's
going
to
provide
an
update
on
that
and
possibly
see
if
we're
ready
for
adoption.
After
that,
okay,
so
I
noticed,
William
has
joined
Mike.
If
you
don't
mind,
William
has
a
bus
to
catch
for
school.
A
A
E
That's
heavy
it's
much
heavier
than
it
looks
this
okay,
so
talking
about,
as
the
chair
said,
we
had
a
region
near
draft
multicast
models,
draft
and
we've
now
adjusted
that
into
a
new
focus.
So
we're
going
to
talk
about
now
is
deprecating
ASM
for
inter-domain
multicast.
We've
got
three
authors
there
from
the
previous
version
and
tallest
is
also
potentially
coming
on
board.
As
an
author
of
an
unfortunate.
E
He
can't
be
here
because
he's
over
chairing
an
America
moment
so
next
night,
so
yeah,
the
original
draft
was
by
at
Monte
Carlo
as
models,
and
it
was
quite
long
and
have
not
got
some
sort
of
messages
in
it
and
the
feedback
we've
got
from
the
past.
Two
IETF
meetings
is
basically
to
focus
on
one
of
the
key
messages
which
is
about
promoting
use
of
SSN
and
deprecating
complimentary,
deprecation
of
ASM
inter-domain.
E
So
he
posted
a
new
draft
as
a
zero-zero
covering
that
topic
next
slide,
so
reminder
of
one
of
the
the
early
drivers
for
this
or
one
of
the
drivers
just
right,
there's,
obviously
a
loss.
Others
had
a
lot
of
others
out
there,
but
as
a
rephrase
will
made
by
day
we
farm
on
the
internet
to
list
which
sort
of
captures
the
thrust
of
what
operators
are
saying,
which
is
that
running
into
domain
ASM
is
a
non-trivial
task.
It's
very
tricky
to
troubleshoot.
There's
lots
of
components
to
it.
E
It's
the
need
for
MSD
P,
which
is
still
an
experimental
protocol.
As
far
as
the
ITF
is
concerned.
So
the
idea
over
there
in
Internet
2
is
they
just
wanted
to
drop
to
using
SSM
for
inter
domain
stuff
and
I
think
the
question
there
was
they're
asking
on
their
list
as
to
what
people
thought
of
that,
and
there
is
generally
support
for
doing
so
next
slide.
So
the
new
draft,
the
structure
of
it
is
cut
down,
write
down
the
model
stuff
is
pretty
much
all
gone.
This.
E
It
reappear
on
the
difference
between
a
SM
and
SSM
brief
discussion
of
their
deployment,
how
they're
deployed
and
then
into
the
advantages
of
SSM
and
the
bulk
of
the
document.
Now
are
the
recommendations
for
what
we
should
do
and
what
we
actually
mean
when
we
say
deprecated,
inter-domain
ASM,
because
you
could
interpret
that
in
in
many
ways
and
there's
lots
of
side
questions
where
we
kind
of
me
to
nail
down
what
we
mean
and
have
agreement
on
that
some
of
these
torture
things
where
they
get
you
to
hold
a
breakout
at
arm's
length.
E
So
that
this
is
the
abstract
right
at
the
start,
so
I
guess
if
you
want
to
quickly
read
that
and
if
you've
got
anything
that
any
violent
disagreement
with.
What
we
say
here
is
the
highest
level
statement
in
the
abstract
then
come
to
the
microphone
come
to
this
microphone.
How
do
they
stand
up
and
express
your
objections?
A
little
bit
on
blue
on
the
end
is
the
bit
that
all
this
is
added.
So
if
we
bring
tourists
on
line,
we've
got
a
slightly
updated
version
that
will
post,
but
it's
basically
saying
recommended.
E
Application
of
ASM
into
domain
recommends,
use
of
SSM
for
inter
domain
and
therefore
the
host
and
Rooter
is
involved
in
inter
domain
applications
must
fully
support
SSA,
but
it
also-
and
this
is
part
of
the
pushback
we
had
from
adopting
it
before-
makes
it
very
clear
that
we're
not
saying
we're
not
precluding
continued
use
of
ASM
within
a
local
domain
for
entry
domain
use
next
slide.
So
what
mean
by
deprecating
sm4
inter-domain,
there's
a
section
4.1
on
that.
E
E
And
it's
something
that's
always
suggested.
Adding
was
a
more
inclusive
interpretation
which
might
include
devices
under
a
different
operator
control
where
the
multicast
is
sourced
from
a
different
operator.
An
important
thing
is
that
we're
not
proposing
to
make
MST
DP
historic
and
again
that
fits
with
not
precluding
the
the
use
of
ASM
within
a
single
organizational
domain.
Stick
you
might
as
well
come
up
here.
Cuz.
No
one
will
hear
you.
F
F
E
A
E
Exactly
so,
everyone's
happy
generally
with
the
points
they're
good
next
slide,
and
the
implication
here
is
network
support
for
our
GMP
b3
and
mo
db2.
So
again
we're
recommending
that
all
hosts
and
Reuters
supporting
multicast
and
also
any
security
appliances,
appliances
handling.
It
support
both
protocols,
I'm
involved
in
the
best
version
of
our
c64
34,
the
ipv6
node
requirements
and
we've
made
mo
DV
2
a
must
for
hosts
there,
where
it
previously
wasn't.
E
E
E
E
E
We
recommend
that
applications
use
SSM,
even
if
they're
in
that
intradomain
environment,
where
ASM
is
supported.
The
idea,
then,
is,
as
more
applications
get
deployed
that
use
SSM
rather
than
s/m.
You
may
be
able
to
prune
back
the
way
that
multicast
is
used
within
your
site,
so
you
may
have
no
varlets
supports
ASM
applications
and
all
the
MSTP
and
all
the
other
relative
complexities
of
that.
E
But
if
you
slowly
introduce
more
SSM
applications,
you
can
move
to
a
point
where
you're
only
using
SSM,
so
this
is
fits
in
again
with
they're,
not
precluding
use
of
I
understand,
but
we're
saying
you
kind
of
want
to
move
to
a
point
where
that's
used
less
and
less
and
yeah
the
thing
involved
at
the
bottom,
where
you're
implicitly
pushing
the
source
discovery
to
something
that
isn't
the
network
layer
above
the
network.
Let's
imagine
relative
algebra
and
thing
so
there's
still
the
complexity
of
discovering
the
sources
somewhere.
It's
just
not
in
the
network.
E
On
Oh,
Cisco
and
juniper
have
mechanisms
for
that
they've
been
around
for
a
long
time
and
not
really
standardized
methods,
those
so
the
ITF,
perhaps
defining
a
consistent,
a
common
way
of
doing
that
might
be
useful,
but
we
would
emphasize
that
it
should
be
and
you'd
as
an
interim
solution,
not
something
that
be
there
long
term
as
hinted
in
very
faint
font.
Their
interim
things
do
tend
to
stay
around
for
some
time.
E
No
one
coming
to
the
mic.
It's
kind
of
good
in
a
way
is
next
slide.
Now
we
mentioned
this
last
time.
Actually,
in
theory,
if
your
deprecating
ASM
inter-domain,
you
might
make
an
argument
to
filter
out
ASM
traffic
that
you
see
inter-domain.
But
our
view
is
that
you
shouldn't
be
doing
that,
because
if
you
have
this
mapping
mechanism
in
place,
you
could
kind
of
preclude
that
from
working
potentially.
E
Obviously
it's
intradomain
sm
is
still
very
common
in
enterprises
and
campuses
today
and
there's
some
text
I've
cut
and
pasted
from
the
document
there
to
emphasize
that.
So
if
you
want
to
have
a
quick
glance
about
and
see
whether
that's
something
you
agree
with,
that's
fine,
if
you
object,
maybe
come
to
the
mic
now.
E
Okay
next
slide,
so
that's
basically
a
sort
of
a
summary
of
what's
now
in
the
draft,
and
you
can
see
the
much
clearer
focus
on
deprecation
of
ASM,
not
precluding
use
of
a
inter-domain
and
not
computing
intra-domain
ASM,
but
also
encouraging
deployment
of
SSM
intra
well
everywhere.
Essentially,
so
that's
it.
Are
there
any
comments
feedback?
H
I
J
F
Large,
you
know
random
people
can
talk
to
each
other
and
inter-domain
in
the
sense
that
you
have
say
a
company
provide
RPM
with
an
isp
right.
So
no
in
this
draft.
If
you
want
to
call
that
out
in
particular
whether
this
applies
to
just
like
sort
of
like
two
domains
that
are,
you
know,
have
a
close
relationship
to
each
other
or
if
it's
really
just
stuck
into
the
main
asset
like
sort
of
random
people,
can't.
K
K
E
Think
I
remember
looking
at
that
internet
to
thread,
and
there
are
things
on
there
like
neither
the
the
Anna
and
essentially
offering
to
run
RP
services
for
the
sites
and
all
the
traffic
hair
pinning
around
and
there's
all
the
universities
don't
necessarily
have
any
relationship
each
other.
They
kind
of
a
relationship
at
the
end
man,
but
it's
the
nrn
saying
this
is
unnecessary
complexity
for
us
to
run.
We
believe
we're
not
seeing
much
smn2
domain
traffic.
We
would
like
to
see
things
as
the
same
for
our
simplification.
K
E
Yes,
it
is,
it
was
posted
before
the
cutter.
It's
not
called
multicast
models,
it's
called
domain
name
and
I've,
not
with
the
tallest
comments.
No
sorry,
okay,
but
those
I've
gone
through
that
with
a
fine-toothed
comb
he's
basically
pretty
sort
of
error
experienced
into
it
and
added
some
useful
little
companies
not
changed
the
thrust
of
anything.
That's
all
there
except
that
comment
about,
and
it's
what
you
raised
McHale
about.
What's
in
the
domain,
is
it
the
provider
and
the
set-top
box
operator?
Is
it
I
think
on
the
feedback?
E
A
So
it
looks
like
two
people
have
raised
their
hands
of
the
two.
Do
you
think
it's
ready
for?
Would
you
support
adoption
or
about
other
folks
in
the
room
who
haven't
read
it
but
have
been
paying
attention
for
the
last
10
minutes,
who's
been
paying
attention
yeah,
so
the
other
folks
in
the
room,
just
a
show
of
hands
who
would
support?
Who
thinks
that
this
would
support
adoption
for
this?
Just
non-binding,
alright
looks
like
about
seven
or
eight,
or
so
anybody
would
be
opposed
to
it.
A
E
I
think
at
the
moment
we
would
just
Park
the
content
of
its
basically
you'll
be
thrown
out
until
this
is
done.
Oh
Dustin
there
may
be
shifts
in
opinion
on
this.
So
get
this
one
done
and
then
move
on
from
there,
but
there's
the
other
two
potential
drafts
that
we
can
start
working
on
now
about
converting
ASM
applications
to
SSM
and
the
mapping
thing
maybe
discuss
those
on
the
list.
Yeah.
N
E
E
I
mean
it's
essentially
a
society.
We
can
progress
this
BCP
without
that
mapping
mechanism,
but
it
what
would
be
interesting
to
hear
are
people
with
applications
or
places
where,
if
the
BCP
get
advances,
they
will
say,
but
wait
and
I
can't
do
this,
because
all
my
stuff
only
talks
AIA.
So
many
talks
are
Chimpy,
v2
and
LDV,
one
for
a
song
I.
Hopefully
there
aren't
many
of
those
but
they're
Michael,
Abraham's
and
so
I.
K
K
K
E
F
F
F
E
A
A
A
M
P
P
I'm
not
seeing
the
slides
amazing,
oh
there
we
go
so
my
project
involves
deploying
the
MxA
t
as
a
public
amt
relay
I
have
the
support
of
the
school's
network
administrator,
which
is
mr.
Morasca,
Peter,
masca
and
Lenny
Juliana,
of
course,
and
they've
been
helping
me
set
this
up
and
one
of
the
things
I'm
trying
to
do
is
catalog
and
curate.
What's
already
there
on
the
mbone,
so
for
multicast
content,
we
want
to
provide
like
an
easy
way
for
internet
end-users
to
get
that
content
and
to
do
that,
I
needed
to
look
at.
P
You
know
what
what
aim
to
gateways
we
already
have,
and
I
also
needed
to
figure
out
how
to
provide
simple
guidance
to
content
owners
to
you
know,
provide
more
multicast
content,
so
next
slide
and
the
goals
I'm
trying
to
get
here
are
I
want
to
deliver
multicast
content
from
Internet
to
to
unicast
only
receivers
on
the
commodity
internet,
and
this
is
a
unicast
only
administrative
domain
to
a
multicast
enable
administrative
donate
domain
model.
You
know
described
in
eight
three
one
three
section
two
before
so.
P
P
So
you
can
see
here.
This
is
what
our
setup
looks
like.
So
we
at
TJ
are
special
because
we
have
a
10
gig
peer-to-peer
link
to
Virginia
Tech
and
we
get
native
multicast
connectivity
to
internet
to
via
that
connection,
so
we're
able
to
receive
native
multicast
from
internet
too.
As
as
many
of
you
know,
internet
2
contains
a
lot
of
and
bone
and
yeah.
P
So
our
MT
relay
sits
on
the
TJ
border
network
and
we
can
receive
native
multicast,
video
or
other
content
from
internet
too,
and
relay
building
on
a
MT
tunnel
to
the
kamati
internet
to
interested
receivers
via
Virginia
Tech.
So
we
have
a
10
gig
link
to
Virginia
Tech
and
a
1
giggling
to
the
commodity
in
it,
and
so
significance
of
this
is
that
we
potentially
have
the
first
public
aim
to
relay
on
gem
bone
and
yeah
I.
Think
that's
pretty
cool.
L
P
J
P
Ready
on
a
minute
to
internet
to
actually
does
provide
a
mini
service
called
the
Internet
to
looking
boss,
it's
hosted
by
Indiana
University
lets.
You
run
commanders
blood
interface
and
I'm
interested
in
working
yeah,
but
show
multipass
back
detail,
but
there
are
too
many
routers
human
hand
is
like
at
least
fifty
so
I,
just
read
it
Python
script
and
they
looked
at.
P
P
Representative
of
what
that
starts
is
because,
if
you
don't
have
any
interested
receivers
and
no
a
source
home
has
to
show
up
in
the
foot
so
did
about
this,
I
actually
just
ran
my
script
as
a
cron
job
for
every
two
hours
for
over
a
month,
so
I
kept
selected
like
100
blogs
and
at
the
end,
when
I
have
all
the
logs
I,
just
read
another
script,
to
just
sort
them
and
figure
out
who
is
operating.
These
sources
by
who
is
data
so.
A
Just
to
add,
the
the
five
packets
per
second
was
selected
somewhat
arbitrarily,
as,
like.
We
have
said
that
to
find
interesting
content,
there's
a
lot
of
there's
hundreds
of
streams
out
there
that
you
know
had
less
than
two
packets
per
second
most
likely,
those
were
beacons,
so
we
weren't
interested
in
seeing
beacons
so
to
kind
of
filter
that
out,
we
just
used
five.
P
So
with
this
content,
obviously
we
can
deliver
it
to
a
network.
You're
gonna
need
a
way
and
I've
been
looking
in
the
video
up
there
for
illuminations
and
the
first
one
I've
seen
was
the
implementation
for
VLC.
You
can
look
at
this.
It
works,
but
it's
updated.
Its
I'm
gonna
see
like
and
it's
windows-only,
but
it's
what
I
thought
to
work
best.
So
far,
it's
a
little
bit
ye,
sometimes
it'll
crash
I'm,
not
sure
why
but
yeah
another
implementation
I
looked
at
was
you
pipes
work?
P
They
actually
made
this
really
cool
demo
with
naku
Native
Client.
It
lets
you
run
native
code
in
the
browser
it
actually
apparently
works,
but
I
haven't
actually
been
able
to
get
it
to
work.
I've
been
told
by
the
you
PI's
that
it
works,
but
neither
mean
nor
Lenny
have
gotten
it
working.
Another
big
problem
with
this
is
that
it's
using
Knakal,
it's
chrome,
specific
chrome,
specific
and
it's
actually
no
longer
supported
by
Google.
P
They
disbanded
the
team
last
year
and
it's
also
SSM
only,
but
that
doesn't
seem
like
a
big
problem
based
on
the
previous
presentation,
since
we're
deprecating
ASM
for
domain
and
finally,
I
also
actually
know
I
have
more
but
I
looked
at
UT
Dallas
is
reference.
Implementation
I
think
Concordia
did
some
work
on
that
too.
P
It's
AMT
GWD,
it's
UNIX,
only
I've
been
able
to
get
it
to
compile
and
run,
but
it's
bundled
with
G
proxy.
It's
an
idea
me
via
proxy
implementation,
I
haven't
been
able
to
get
back
to
compile
so
I'm,
not
sure
whether
you
know
it
works
completely
or
not
so
next
slide
so
I
also
looked
at
Greg's
bum
Greg
I'm
got
nodes
work
with
js4.
Oh
man,
aside,
SDK
for
among
the
best
services
I
actually
made
my
own
fork
needed
I
just
made
a
couple
changes
to
try
to
make
it
work.
P
The
major
problem
with
that
is
that's
missing.
The
documentation
and
Greg
also
told
me
that
he
uses
something
to
make
it
I
can't
actually
run
general
me
once
I
hit.
So
that's
a
big
barrier
to
our
using
that,
but
I've
also
there's
also
very
promising.
Bye,
Jake,
ooh
I
think
this
here
and
I.
Also
it
I
just
changed
to
lose
to
get
it.
P
It
also
needs
a
93
poxy,
but
it
uses
Nick
Roxy,
which
is
actively
developed.
I,
don't
actually
know
if
you
can
use
Nick
foxy
with
the
UT
Dallas
/
Concordia
implementation,
so
I
haven't
tried
that
quite
yet
I
also
haven't
gotten
around
to
actually
testing
this
one
fully
either,
and
so
finally,
we
also
have
Cisco
SSM
AMT
tools.
This
is,
as
far
as
I
can
tell
the
only
available
anti
library
for
like
embedded
embedded
EMT
library.
So
it's
useful
for
like
building
your
own
standalone
thing.
P
P
So
with
all
these
gateways
blooming
Asians
out
there
there's
not
really
a
clear,
you
know
best
solution.
Obviously
the
VLC
mentioned
earlier
does
work,
but
it's
severely
updated
and
it's
Windows
and
it's
buggy.
So
the
logical
step
here
would
be
to
integrate
it
into
a
new
version
of
VLC
and
also
poured
it
to
all
the
other
platforms.
P
Tom
VLC,
as
many
of
you
know,
is
pretty
widely
supported
in
the
industry,
and
it's
also
I
mean
it's
fast
platform,
but
I'd
assume
you
have
to
write
specific
code
for
each
platform
anyways,
but
another
idea
I've
been
looking
at
is
web
assembly
webassembly.
If
you
guys
don't
know
it's
new
technology,
it's
meant
to
replace
Knakal,
but
it's
also
crap
bus
platform.
It's
supported
by
Google
Microsoft
Mozilla
on
all
of
their
brothers,
and
my
ideas
is
to
build
an
in-browser
implementation,
similar
to
what
you
type
did
with
their
not
cool
demo,
but
obviously
with
webassembly.
P
O
O
There
are
a
couple
of
workarounds
proposed
the
a
good
direction
to
look.
If
you
want
to
pursue
this
would
be.
There
was
a
web
RTC
datachannel
stand-alone
the
hackathon
project,
this
last
hackathons.
You
might
want
to
check
in
to
that
as
a
wrapper
for
UDP,
if
you're
desperate
enough
or
you
might
look
into
ya
right.
O
Q
Thank
you,
hi
Lucas
party,
BBC,
R&D
and
so
I
was
also
at
the
hackathon
working
with
Jake
and
part
of
that
was
to
try
and
get
to
move
our
multicast
quick
video
distribution
demonstrated
in
a
web
browser.
So
we
looked
at
some
of
this
or
not
so
much
EMT
side
of
things,
but
on
deserializing,
quick
packets
within
the
web
browser.
Q
Certain
capabilities
are
not
available
in
things
like
service
workers,
etc
and
yeah.
We,
you
can't
deliver
things
UDP
multicast
into
like
contact
so
rather
than
web
RTC.
We
chose
WebSockets
something
a
little
bit
more
straightforward,
so
we
were
able
to
demonstrate
some
of
that
at
the
hackathon
and
presented
some
slides
on
that
that
are
on
the
public,
github
repo,
and
so
you
might
want
to
have
a
look
at
that.
If
interested.
N
I
K
N
A
N
N
N
For
information
literacy
is
the
spanish
colony,
no
obvious
the
equivalent
of
interest
to
in
Spain.
As
you
make
sense,
that's
fed
interesting
project.
It
was
set
up
for
distribution
of
metrological
data
that
comes
in
by
satellite
into
Germany
and
in
spread
up
to
certainly
the
European
net
agencies.
I'm
surprised
to
see
a
popping
up
on
a
Institute
yeah.
A
N
J
A
Interesting
thing
about
EU
Mets
at
is
there
there
there
are
the
only
ones
it
seems
to
be
using
SSM
right
now
and
it's
pretty
high
bitrate,
so
yeah,
it's
so
Greg.
This
I
mean
I'm,
sorry
Mike
this
kind
of
answers,
your
question
as
to
what
is
the
state
of
you
know
the
mbone
today
there's
their
stuff
out
there,
not
a
lot.
A
One
of
the
things
that
was
disappointing
was
the
state
of
the
am
gateway
implementations.
A
lot
of
the
work
on
AMT
gateways
has
been
unic
unix-based,
with
the
plans
to
stick
it
into
routers.
You
know
which,
if
we
remember
the
original
purpose
of
AMT
was
for
end
users.
You
know
at
their
laptops-
or
you
know,
smartphones
or
before
smartphones,
but
the
goal
of
AMT
is
to
bypass,
have
end
users,
access,
multicast
content,
so
the
the
Gateway
implementations
that
exist
today,
don't
really
we're
struggling
to
get
them
to
facilitate
that
model.
So
that's
a
little
disappointing.
A
A
O
Jake
this
one
more
suggestion
of
amt
resources.
There's
a
Cisco
CSR
1000,
be
virtual.
Energy
can
download
that
has
a
AMT
gateway
support
built
in
and
then
one
last
question
about
the
data
here.
I
guess
I
can
check
off
the
line.
If
you
don't
know
offhand,
but
do
you
have
it
it
does
it
say
whether
whether
these
are
SSM,
whether
there
are
are
peas
for
the
for
the
groups?
Do
we
know
the
are
these
joinable
yeah,
SSM
or
ASM
at
the
moment,
with.
R
O
A
A
A
S
Good
morning,
everyone
I'm
ginger
from
the
EE,
and
you
can
call
me
send
me
this.
This
presentation
is
for
multicast
a
young
model.
We
had.
We
had
a
present
to
each
her
for
many
times
and
today
we
will
make
a
brief
introduction
of
the
update
of
destructive
in
this
data.
We
also
have
author
intern
from
China
Unicom.
S
Let's
see
the
brief
update
of
this
draft
and,
according
to
young
doctor
suggestion,
we
change
the
trap
name
from
information
model
to
young
model,
because
information
model
has
special
meaning
in
some
other
stos,
such
as
on
earth
or
other
organization.
So
we
changes
a
name
to
avoid
confusion
and
the
next
we
do
some.
H
S
Seo,
the
motivation
of
this
chart
somebody
has
to
see
at
home.
I
saw
it
had
many
health,
so
we
just
the
intern
use
data
briefly,
so
this
job,
this
model
is
standard
at
a
high
level
to
take
advantage
of
the
existing
fraud.
Your
motive
has
the
protocol
your
models
to
implement
as
a
motive
has
the
stories.
S
S
So
this
is
the
project
in
open
daylight.
You
can
see
either
you
can
get
more
information
from
this
link.
The
project
is
drawn
by
two
young
models.
The
first
one
is
the
holy
customer
to
define
here
and,
as
the
other
is
pure
protocol
young
model,
so
this
model
has
been
verified
in
this
project
and
the
projects
have
been
released
in
covered
worship,
so
this
model
is
available
and
a
practicable
in
the.
We
also
provide
our
our
like
class
diagram
to
make
it
more
clear
and
I
think
this
diagram.
S
S
S
T
A
L
H
H
There
may
there's
been
changes
in
data
center
architecture
over
the
last
few
years,
since
this
draft
was
created,
it'd
be
good.
To
get
some
feedback.
I
would
love
to
have
a
co-author
or
two.
So
if
anybody's
interested
the
already
working
group
draft,
you
get
an
easy
name
on
a
draft.
If
you
want
and
I'd
love
to
work
with
someone
to
to
see
how
we
can
maybe
update
it
with
most
relevant
information
on
the
use
of
multicast
in
the
data
center,
with
that,
okay.
I
U
U
So
the
issues
are
that
for
multicast
over
wireless
ends
up
really
being
constrained
by
the
slowest.
Local
recipient,
and
that
means
that
it
can
be
drastically
slower
than
unicast,
and
since
it's
slower,
it
also
occupies
the
medium
for
longer
and
increases
the
amount
amount
of
interference
and
since
also
it
needs
to
be
multicast
to
be
received
by
the
most
distant
recent
local
receiver.
That
means
it
could
require
higher
power
and
all.
J
U
If
you
have
Wi-Fi
and
wire
lengths
into
Sigma
subnet,
and
so
that
means
that
some
apps
like
Bonjour,
is
an
example
saturate
and
though
these
problems
are
not
likely
to
be
fixed
anytime
soon,
I
mentioned
that
there
was
a
parallel
effort.
An
int
area
has
been
submitted
and
this
was
actually
another
document,
so
this
one
here
it
had
co-authors
from
Dorothy,
Stanley,
JC
Zuniga
and
was
worn
here.
U
This
is
his
group
so
anyway,
so
we
got
together
and
put
together
a
lot
of
text
to
describe
the
problem
in
some
workarounds
and
some
solutions
and
what
had
been
noticed
at
conferences
like
idea
so
Dorothy
in
I,
Triple,
E
she's
a
chair
of
a
2.11.
Now
as
of
last
week
or
two
weeks
ago,
she
made
a
presentation
in
ada
3.11,
and
this
stands
for
2015.
J
U
So
here's
some
of
the
protocol,
optimizations
they're,
described
in
the
graph
there's
a
proxy-
are
on
specification
for
eyv2011
and
there's
some
party
neighbor
discovery
for
ipv6
and
address
registration
by
the
way,
there's
also
a
raft
RFC
6775
update.
It
has
some
specification
for
proxy
neighbor
discovery
and
ripple
based
systems.
U
Important
for
wireless
devices
of
battery-powered
wireless
devices
is
trying
to
save
power
and
the
way
they
do
that
is
by
going
to
sleep
for
a
while
and
that
it
can
be
inter
deck
and
interfere
with
a
proper
reception
of
multicast
residence.
If
the
access
point
is
trying
to
send
out
multicast
to
the
sleeping
devices,
well,
they
can
wake
up,
get
a
packet
that
doesn't
belong
to
their.
They
don't
really
need
it
because
they're
not
in
that
multicast
group
and
try
to
go
back
to
sleep.
U
There's
also
some
other
ipv6
support
in
the
UK
on
11
dec
2012
and
by
the
way
there's
a
new
8
or
2.11
or
roll-up
coming
out
I
think
soon,
like
it's
almost
done,
but
I'm
sure
all
this
will
still
be
in
there
at
one
time.
Honored
technique
is
well.
Let's,
just
don't
do
multicast
anyway,
if
you've
only
got
two
or
three
receivers
locally
for
the
multicast
group.
U
O
But
this
is
Jake
section
4.5
I
think
it
was
I,
would
love
to
see
filled
out
but
sounds
like
an
interesting
technique
that
just
had
the
one
sentence
that
it
happens
in
the
draft
when
it's
up
there
I
think
it
just
I
would
love
to
see
some
elucidation
of
how
that
works.
I'm,
there's
a
standard
for
it
or
what
exactly
and
find
anything
obvious,
but
I
will.
U
U
Yeah,
thank
you,
take
note
of
that
and
then
there's
a
okay,
so
basically
I
think.
It
frequently
has
just
said
that
in
some
grasshop
state,
if
you
want
to
do
multicast,
you're
allowed
to
convert
it
to
unicast
to
all
the
receivers
that
are
locally
and
they're
in
debt.
I
think
it's
been
considered
to
be
sufficient
specification.
I,
Triple
E,
as
created
several
approaches
for
this
problem.
U
One
loom
is
called
a
directed
multicast
service,
which
is
pretty
much
that,
in
other
words,
instead
of
blasting
it
out
everybody
you're
directing
it
to
these
particular
receiver
and
then
for
this
problem.
I
mentioned
before
about
the
multicast
not
being
acknowledged.
There's
something
called
group
cast
with
retries
GCR,
which
provides
a
layer
to
acknowledgment
from
multicast
next
likely
throw
some
other
workarounds
that
are
mentioned,
and
this
is
a
little
bit
more
about
the
traffic
class
idea
on
the
next
slide:
reliable
registration
and
can
help
so
the
hope.
U
The
whole
idea
reliability
in
multicast
over
Wi-Fi
and
a
2.15
you
maybe
even
especially
a
2.15
his
problematic,
because
then
in
a
case
of
15,
they
thought
this
was
all
the
responsibility
of
the
higher
layers
and
never
specified
it
in
the
case
of
dot
11
unicast,
which
is
economically
way
more
important,
and
so
we
also
could
suggest
some
new
approaches
to
help
save
battery
life
and
so
I
try
to
rage
it's
work.
You
don't
have
to
wake
up
for
every
multicast
packet.
That
would
help
a
lot
on
next
slide.
U
U
Jiggli
he
had
provided
he
had
read
both
documents
in
his
first
comment
was:
there's
no
need
for
two
different
of
documents:
okay,
so
we
merged
the
documents
and
but
he
has
motor
relevant
comments
as
well.
What's
the
audience
for
the
document
and
what
problems
are
going
to
be
solved
in
ICF
versus
I,
Triple,
E
and
and
so
on.
So
he
asked
for
specifically
for
specific
questions,
and
these
are
my
answers
currently,
but
this
group
should,
you
know,
decide
really
what
the
answers
are.
So
advise
implementers,
nothing.
U
Clearly
it
yes,
I
Triple,
E,
well,
laughter
ability
has
a
lot
to
do
with
the
specification
for
the
actual
layer,
two,
so
the
more
they
know
about
the
problems
we're.
Having
are
the
looks
like
the
mindset
of
idea,
the
better
job
they
can
do,
and
so
it's
not
targeted
targeted
towards
I
Triple
E,
but
they
will
almost
certainly
see
it
in
mossad
emphasized
that
there
is
an
accurately
ITF
coordination
committee
that
is
aware
of
this
draft
water.
Remember
I'll,
give
each
other
with
funnily
Elmo
sorry.
G
U
K
Isn't
directly
related
to
this,
but
I've
had
I've
seen
devices
where
you
turn
on
IBM
be
snooping,
it
turns
off
any
other
Ethernet
multicast,
so
b6
is,
is
doesn't
work
anymore.
Do
we
have
like
implementation
advice
for
people
implementing
those
kind
of
functionalities,
because
they're
obvious
some
of
them
are
doing
it
wrong,
like
they
turn
off
all
other?
They
turn
off.
Ethernet,
multicast
and.
A
J
U
K
So
my
point
was
not
on
this:
is
my
phone
was
not
specifically
for
why
fight
it
was.
This
is
like
a
layer,
2
switch
wired.
Has
this
problem?
I
know
these
devices
so
I
know
plenty
of
people
who
have
to
turn
off
idmp
snooping.
Otherwise,
you
know
a
lot
of
other
things
doesn't
work
so,
but
this
is
all
about
802
I
would
say
generally
do.
Do
we
want?
Is
this
another
thing
that
we
should
work
on?
It
is
not
that
specifically
for
what
you're
talking
about
well.
U
I
think
that
you
know
really
the
very
heart
of
it.
There
are
certain
things
about
physics
that
can't
be
overcome,
and
so
that's
not
specific
802.
But
my
background
is
a
lot
more
about
802
and
I.
Don't
know,
I
know
a
little
bit
about
LTE
and
so
on,
but
I
know
a
lot
more
about
that.
Ok,
I
meant
Wired
versus
all
Wireless.
U
So
I
think
the
district
really
should
concentrate
on
Wireless,
okay
and
because
the
main
problems
that
are
discussed
here
and
the
reason
in
the
motivation
for
the
craft
was
all
Wireless
and
exactly
how
it
is
I
mean
anyway,
when
multicast
was
developed
of
ipv6
was
developed
assuming
multicast,
they
were
well
aware:
the
wired
characteristics
of
multicast
one
more
minute.
Okay,
oh
so
next
slide.
Please
well.
V
Just
real
quick
in
the
slide
before
that
somewhere
else
you
had
at
the
bottom
some
question
that
I
think
Joel,
the
wonderful
Joel
asked
about
what
should
the
ATF?
Do
you
just
Bluff
so
for
that
it
would
be
really
nice
if
part
of
the
output
of
the
document,
maybe
not
necessarily
in
the
document.
The
part
of
that
output
from
the
working
group
is,
you
know
some
accommodation.
V
Is
there
another
work
item
or
something
that
we
should
be
looking
at
run
either
then
will
be
or
Pam
or
somewhere
else,
though
there
will
be
very
nice
besides,
just
because
I
saw
the
section
in
there
that
says:
oh
there's
some
writers
for
discussion.
Besides
just
putting
it
there,
it
would
be
nice
for
us
to
take
it
somewhere
for
it.
It
may
be
here,
but
yeah
well,
I.
Think.
U
This
is
the
really
great
group
for
us
to
learn
those
things
and
I.
Don't
want
to
position
myself.
As
you
know,
in
any
way,
major
authority
on
multicast
I
know
something
a
lot
better
wireless
and
so
on,
but
the
multi
best
problems,
this
disk
group
will
was
contribute
to
make
this
an
effective
document.
Okay,
I!
Guess
that's
good!
Oh!
U
So
let
me
just
want
you
more
one
more
thing,
so
there
were
some
comments
from
Joel
that
I
responded
to
on
the
list
and
did
not
incorporate
the
text
for
those
comments
and
resolutions
in
the
draft
I
was
waiting
to
see
if
there
would
be
more
commentary.
But
after
this
idea
and
also
depending
upon
any
discussion
from
this
presentation,
there'll
be
a
new
revision
of
this
document
available
within
the
site
two
or
three
weeks.
Thank
you
very
much
great.
A
H
W
J
H
F
H
F
F
Well,
hopefully,
you've
seen
this
before
this
is
the
agenda
so
we're
gonna
have
we
said
20
minutes
for
the
first
purse,
they've
got
it
a
little
bit
shorter
that'd,
be
great,
then
they
said
roughly
10
minutes
for
each
of
the
others,
but
if
you
can
do
it
in
less
than
ten,
that's
good,
because
you
don't
really
have
time
for
all
of
this
I
guess
as
quick
as
possible,
we'll
just
go
through
this,
so
this
just
a
status
or
current
working
of
documents.
So
you
have
one
document
being
published
in
a
few
days.
F
Pim
yang
got
some
comments
during
is
G
but
evaluation,
and
there
are
some
young
daughter
comments
that
need
to
be
addressed
of
multiple
upstream
requirements.
Our
ad
had
several
comments
and
that's
waiting
for
the
offers
to
respond
to
that
a
chimp
email.
The
yang
also
got
a
lot
of
young
doctor
comments
during
the
evaluation,
so
the
offers
respond
to
that
PIM,
explicit
tracking,
isn't
living
anywhere,
but
the
offer
is
saying
that
he
will
try
to
do
an
update
for
next
30
F.
F
There
were
working
with
dolphin
dr
load
balancing
that
was
brought
back
last
ITF,
so
it
went
to
Burton
rube
last
call
and
went
on
to
the
ad
a
few
years
ago.
There
were
lots
of
comments
and
no
one
responded
to
those
comments
and
then
last
night
EF
it
was
presented
again
with
with
updates,
and
the
question
is
yeah
what
we
should
do
about
that
draft.
F
F
H
H
O
Security
considerations
section
there
was
reference
to
the
nmda,
a
standard
I'm
a
little
confused
as
to
because
there
was
I
guess,
there's
been
some
changes
in
the
recommended.
Practices
for
yang
models
is
that
accurate,
I'm,
not
really
sure
I,
just
the
security,
sensations
section
seems
really
thin.
I
think
we're
gonna
get
bit.
Okay,.
F
F
F
F
J
F
F
Let's
see
how
to
resolve,
if
how
do
you
find
your
pin,
neighbor
or
RPF
neighbor?
If
you
have
an
ipv6
next
hop
and
you
only
have
ipv4
pim
neighbors,
so
that
draft
hasn't
had
any
changes
since
last
ITF
either
the
offers
believe
it's
which
includes
me
believe
it's
it's
it's
in
a
good
condition
just
want
to
see
if
they
work
to
repass
anything
more
that
should
be
added
to
that
draft,
but
we
haven't
got
any
any
feedback.
F
H
F
Y
Y
Y
In
a
nutshell,
we
originally
had
a
set
of
experimental
rfcs,
which
consisted
of
a
proactive
link.
State
routing
protocol
called
OS,
are
optimized
link
state
routing,
as
well
as
a
on-demand
distance-vector
protocol.
A
odv
many
people
were
heard
of
the
first
two,
and
there
were
also
some
other
techniques
that
also
made
experimental
RFC.
One
of
those
is
a
source
routing
protocol
called
DSR
dynamics
or,
as
well
as
another
proactive
protocol
called
TB
RPF.
Y
Where
we
stand
in
the
working
group
today
is
the
OSR
v2
protocol
was
captured
as
a
proposed
standard
and
RFC
71
81,
and
one
of
the
things
that
we
did
in
the
working
group
in
the
past
number
of
years
decade
is
from
those
original
our
experiment.
Rfc's.
We
took
a
little
more
of
an
engineering
approach
and
modulized
some
of
the
functions
of
the
protocols
using
what
we
termed
the
building
blocks,
approach
and
part
of
that
included.
Y
Y
Working
group
and
then
there's
another
effort
called
Babel,
which
is
also
its
own
working
group,
and
finally,
actually,
the
OSPF
working
group
documented
some
mayonnaise
extensions
to
OSPF
and
I
think
there
are
three
experimental
RFC's
that
basically
describe
three
different
candidates:
we're
extending
OSPF
to
work
in
a
more
mesh
networking
type
environment.
Next
multicast
routing
is
challenging.
Actually
Charlie
talked
to
a
lot
of
the
issues.
Y
Some
dwell
on
this
another
subtle
issue
is:
is
that
because
I
may
receive
a
packet
from
someone
I
can
hear
over
here,
but
need
the
forth
to
a
person
I
hear
over
here.
I
may
be
actually
receiving
and
porting
a
packet
out
the
same
wireless
interface,
which
makes
reverse
path,
boarding,
checks,
more
complicated
and
also
the
apologies
can
be
really
dynamic.
So
even
if
you
could
do
some
reverse
path,
boarding
checks-
sometimes
you
might
be
better
served.
You
treat
multicast
a
little
differently,
because
does
this
checks
mean
always
be
valid?
Y
There
were
some
concepts
were
multicasts
that
were
been
proposed,
both
in
some
academic
papers,
as
well
as
some
old
draft
I
internet
drafts.
Some
of
these
were
tethered
to
the
unicast
protocols
that
I
scribed,
like
there's
a
multicast,
a
odv
draft
that
was
proposed
quite
a
few
years
ago,
as
well
as
a
multicast
OSI
protocol,
and
then
there
was
a
different
approach,
called
OD,
MRP,
on-demand
multicast
routing
protocol
and
then
actually,
the
OSR
org
implementation
of
the
OSR
protocol
actually
had
a
mechanism
called
a
basic
multicast
forwarding.
Y
It
was
not
a
standalone
IP
packet
forwarding
mechanism,
but
rather
an
api
that
an
application
is
registered
with
to
submit
packets
that
got
flooded
over
the
same
backbone
that
the
routing
protocol
messages
got
flooded
over.
So
it's
sort
of
like
an
LSA
okay
calafate,
where
the
man
a
working
group
actually
landed.
Is
we
actually
have
an
experimental
RFC
entitled,
simplified
multicast
boarding.
Y
Basically,
we
don't
do
anything
group
specific
in
SMF
we
flood
multicast
packets
within
a
mayonnaise
outing
area
and
just
like
that
basic
multicast
forwarding
that
OSR
did
it
uses
the
same.
It
can
use
the
same
efficient
flooding
techniques
that
are
used
to
help
more
efficiently
disseminate
link
state
information
for
like
a
protocol
like
OSI,
except
we
differentiate
it
because
you
may
want
to
have
different
metrics,
by
which
you
do,
data
flooding
versus
control,
plane,
flooding
and
actually
there
are
a
number
of
different
relays
set.
Y
Y
In
addition
to
these
basic
algorithms
ourselves,
we've
done
work
looking
at
some
different
enhancements
to
the
algorithms
using
metrics
to
help
overcome
the
lossy
characteristic
of
some
of
the
layer,
two
protocols
that
we
deal
with,
particularly
when
it
comes
to
multicast,
for
example,
maybe
selecting
extra
relays
beyond
that
minimum
connected
nominating
set
to
provide
additional
redundancy
and
transmission
to
help
overcome
some
of
the
packet
loss.
That
happens.
Another
little
issue
is
the
algorithms
kind
of
are
designed
to
say
optimize
a
current
snapshot
of
topology,
but
in
a
mesh
network,
four
things
are
moving
dynamically.
Y
Y
And
RFC's,
but
there
are
some
academic
papers
out
there
on
it.
Next
couple
implementations
already
mentioned
the
OSR.
The
basic
multicast
warning
we
actually
at
NRL
have
an
open
source
implementation
called
NRL
SMS,
which
is
a
cross-platform
user
space
forwarding
daemon.
We
mostly
use
it
for
simplified
multicast
forwarding,
but
it
can
be
used
for
other
purposes
too.
In
addition,.
Y
Flooding,
which
is
also
called
dumb
flooding
where
everybody
floods
each
packet,
it
can
be
controlled
by
either
an
HDPE
daemon
such
as
RLS
our
protocol
to
do
really
set
selection
or
we've
also
integrated
with
the
quagga
OSPF,
with
mayonnaise
extensions
to
do
relays
that
selection
for
for
more
efficient
flooding
in
SMF.
It
does
the
duplicate
packet
detection,
which
the
next
slide
talks
about.
Y
Actually,
first
this,
where,
where
it
stands
in
the
world
as
a
user
space,
routing,
a
demon
or
forwarding
demon,
various
negative
packet
capture,
interface
device
or
virtual
contact
type
interfaces
to
basically
capture
or
intercept
packets
coming
into
the
operating
system.
And
you
know
from
possibly
a
radio
and
API.
The
interface
was
the
wrong
demon
to
control
the
relay.
I
Y
Selection,
one
of
the
things
that
we've
been
doing
this
is
I'm
going
to
kind
of
want
to
get
to
the
end
of
the
clock.
Here
they
talk
about
it
and
exploring
that.
How
do
we
construct
a
forwarding
information
base
that
can
support
the
needs
of
simplified
multicast
flooding,
as
well
as
possible,
multicast
routing
mechanisms
that
are
group
specific,
that
we
may
be
layer
on
top
of
the
SMS
bloody
next
line
and
that's
kind
of
what
this
slide
talks
to?
Y
We
actually,
in
the
main,
a
working
group
had
a
couple
drafts
that
were
presented
a
couple
years
ago
when
they're
both
expired.
One
was
on
an
enhancement
to
that
Odin
RP
protocol
that
also
included
support
for
asymmetries
where
I
may
have
a
link.
That's
abroad
can
Schmitt
only
interface
where
I
may
have
other
interfaces
that
I'm
receiving
loss,
so
I
have
non-reciprocal
connectivity,
and
this
document
describes
techniques
for
constructing
it.
No
problem
multicast,
routing
tree
or
mesh
it's
more
mesh
than
the
tree
over
topology
with
those
non
reciprocal
links.
Y
Also,
we've
had
a
proposal
for
a
concept
called
elastic
multicast,
which
is
more
of
a
flow
based,
multicast
routing
protocol.
It
starts
with
the
same
flooding
mesh
that
SMF
uses,
whether
it's
classical
flooding
or
one
that
uses
the
efficient
flooding
via
relay
sets,
and
then
it
actually
uses
acknowledgments
from
downstream
those
ie
nodes
that
have
joined
groups
or
or
who
have
downstream
neighbors,
who
have
joined
groups
to
keep
a
higher
rate
of
multicast
forwarding,
active
or
from
a
specific
source,
though,
when
we
say
flow,
it's
really
like
a
five
tuple
description.
Y
So
the
only
high
rate
flooding
occurs
for
flows
that
they're
actually
people
in
the
wireless
and
network
interested
in
and
would
only
go
to
the
parts
of
the
network
where
there
is
actually
interest
in
that,
in
addition
to
using
actual
low
rate
flooding
of
packets
to
sort
of
advertise
or
announce
flows.
We've
also
have
a
proposal
to
have
an
advertisement
message
which
is
kind
of
like
a
route
request
or
a
multicast
group
more
similar
to
OD
MRP
you,
basically,
an
ounce
packet
describing
a
flow,
a
source
group
to
pool
for
example,
and
then
downstream.
Y
Those
would
acknowledge
that
and
start
activating
forwarding
of
the
flow
through
a
subset
of
the
SMF
mesh.
What
I
point
out
to
that?
That
cannot
actually
be
used
to
support
gateways
to
routers,
because
you
could
have
a
basically
a
gateway
device
use
that
advertising
message
to
advertise
its
presence
to
go
to
the
maeÃn.
A
mesh
next
slide,
keep
things
going
forward
again.
Y
Essentially
in
our
NRL
SMF
implementation
to
do
duplicate
packet
detection,
we
already
keep
a
state
on
a
kind
of
a
per
flow
basis
to
help
reduce
false
duplicates.
We,
the
specification,
describes
a
combination
of
hash
based
or
and
or
identify
identify,
are
based
duplicate
packet
detection
and
for
v6
have
even
specify
as
a
header
tension
that
can
be
used
to
apply
a
specific,
unique
identifier
to
ipv6
packets.
Y
We
keep
a
limited
history
or
a
window
of
a
duplicate
packet
detection
for
flow.
It's
configurable
our
implementation
and
then
because
we
already
had
that
building
a
concept
like
elastic
multicast
on
top
of
the
SMF
warding
engine
was
relatively
straightforward.
It
has
some
additional
things
you
need
to
detect
when
you
flows,
because
now
you're
actually
concerned
about
the
redefinition,
whereas
enough
to
care
about
that.
I
also
point
out
that,
in
addition
to
multicast
protocols,
on-demand
protocols
love,
you
kind
of
have
a
similar
need.
Y
It's
not
often
easy
to
deploy
in
a
ODB
protocol
on
existing
Internet
Protocol
hosts
because
of
this
concept
of
on-demand,
rather
than
you
kind
of
need
to
know
when
I
want
a
packet
for
a
specific
source
destination
comes
into
play
so
that
route
requests
can
be
activated,
there's
probably
similar,
implementations
to
what
we've
done
to
with
SMS,
or
that
the
idea
would
be.
If
we
do
build
a
forwarding
information
based,
that's
sort
of
a
Mayon,
a
multicast,
it
could
also
possibly
have
some
support
for
similar
concepts
for
unicast
routing
as
well.
Y
Next
slide
as
an
example
when
looking
at
that
in
our
own
implementation
for
inspirationally
living
with
the
desorb
source
code
and
basically,
that's
the
data
structure
and
emirati
header
file,
next
slide
kind
of
shows,
possibly
places
where
we
would
add
additional
state
variables
to
keep
track
of
things
like
duplicate
packet,
detection
and
other
stuff.
Even
what
the
protocol
needs
like
plastic
multicast
does
a
little
more
packet
counting
for
flows
and
that
kind
of
thing
to
decide
when
to
trigger
those
acknowledgement,
messages
that
I
described
next
slide,
basically
a
mirror
of
that
M
route.
Y
D
is
we
had
the
basic
in
our
in
our
SMS
implementation,
a
concept
we
call
interface
associations
where,
basically,
my
packet
came
in
an
inbound
interface,
you
maintain
both
duplicate
packin
detection
state,
as
well
as
the
type
of
flooding
algorithm
that
was
being
used
on
a
pairwise
interface,
see
Asian
basis
next
slide,
and
we
augmented
that
for
a
protocol
like
elastic
multicast.
By
simply
extending
that
and
adding
more
state
variables
to
this-
and
this
is
kind
of
this-
isn't
showing
you
the
details
of
it,
but
this
is
where
at
least
we're
actively
looking.
Y
How
can
we
build
a
forwarding
information
base
for
main,
a
multicast
that
can
be
applied
in
the
general
way,
both
to
support
things
like
elastic
multicast
at
working
on
now,
as
well
as
potentially
other
curveballs
moving
forward
next
slide?
We
can
skip
this
one.
The
interest
of
time
conclusion
just
in
a
summary.
We
think
that
mobile
ad
hoc
networking
multicast
has
some
additional
considerations
as
compared
to
the
more
conventional
wireline
multicast
protocols,
and
we
think
that
there's
a
potential
for
some
type
of
common
fit
and
and
can
supporting
control,
plain
interface
to
support
these
protocols.
Y
U
X
The
Manning
working
group
has
had
less
and
less
participation,
so
we're
looking
for
more
people
to
participate,
and
we
think
it
has
a
larger
kind
of
a
can
have
a
larger
impact
than
just
MANET
because,
like
we
have
up
there
babel
and
role,
and
they
all
have
the
possibility
of
doing
multicast
in
these
wireless
networks,
and
we
wanted
to
make
a
way
that
there's
a
simple
interface
that
they
can
all
kind
of
talk
down
to
to
control
the
multicast.
That
could
be
disseminated.
X
H
X
Y
X
U
John
Charlie
Perkins,
so
SMF
was
really
developed
in
response
to
the
need
for
a
efficient
flooding
protocol,
and
so
it
really
tries
to
include
the
whole
network
also
connected
dominating
said.
So
this
is
exactly
what's
needed,
as
you
mentioned,
is
tough
to
deal
with
real
life
points
that
are
mobile
and
breaking
their
neighborhoods
up
and
so
on.
But
I
just
was
wondering
how
appropriate
is
it
for
actual
multicast
groups
of
may?
The
membership
may
only
be
a
small
percentage
of
the
total
number
of
devices
in
the
network
right.
J
Y
That
flooding
mesh
to
just
the
subset
of
relays
needed
to
service
those
sparse
members,
I
mean
we've
even
done
a
little
bit
of
unicast
support
of
the
elastic
multicast
idea.
Right
now
we
have
an
experimental
implementation
of
it.
I
think
it's
possible.
You
know
when
we've
done
an
internet
draft
before
that
describes
very
high
level,
the
acting
mechanism,
we
I
think
there's
a
better
document
that
could
be
written
if
we
have
interest
in
the
working
groups
in
doing
that,
and
we
also
have
some
ongoing
research
where
we're
looking
at
in
those
acknowledgement
messages.
Y
I
Y
It
was
just
a
term
picked
because
the
idea
is,
you
start
with
a
mesh,
and
then
it
hasn't
like
kind
of
like
a
rubber
band.
You
act,
acknowledgments
kind
of
expand
and
contract
that
flooding
mesh.
It's
not
really
a
tree
because
it's
really
built
on
top
of
the
relay
set
mesh
of
like
it's
more
of
a
pretty
sounding
phrase,
than
a
really
logical.
Y
X
Ads
working
group,
chair
of
the
MANET
group,
Justin
Dean,
again
I-
think
elastic
multicast
is
a
driver
for
the
work
that
would
be
being
done
in
the
FIB
yeah.
You
would
want
the
FIB
to
support
something
like
a
lasting
multicast,
but
elastic
multicast
isn't
the
only
thing
that
would
use
it.
For
example,
like.
X
On
your
deployment,
if
it
is
more
static,
you
might
want
to
use
something
different
to
control
the
FIB,
but
I
think
that
the
main
point
is
that
we
we
get
the
FIB
right
for
wireless
multicast,
so
that
you
can
control
what's
being
flooded,
whereby
different
algorithms
elastic
multicast
being
the
one
that
is
driving
us
right
now,
but
there
would
be
others
as
well.
We
want
to
capture
that
we
don't
want
to
work
so
that
it's
we,
we
have
a
standalone
protocol
and
it
does
what
it
does,
and
nothing
else
would
work
with
it.
O
H
X
Z
Z
Z
O
H
Thank
you.
Thank
you
he's
on
okay.
So
now
we
have
six
individual
drafts
being
presented
to
us.
We
cut.
We
did.
We
didn't
have
several
PIM
drafts
presented
this
time,
for
the
sake
of
time
so
was
HN
am
I,
saying
your
name
right,
you're
up
next
yep
very
good,
and
this
may
be
blasphemy,
but
we're
probably
going
to
go
over
the
noon
cutoff
time
so
Phil
at
that
time
feel
free
to
leave,
but
we
may
just
keep
going
and
it's
going
to
be
recorded
so,
but
please
yeah.
L
If
the
these
two
addresses
are
same
and
the
message
will
be
protest,
so
the
problem
is
as
long
as
there
are.
One
router
in
the
network
cannot
support
him
and
the
joint
message
will
be
discarded,
as
shown
in
the
example
below.
If
the
router
ax
has
no
support
team
SM,
the
joint
message
from
ER
three
and
the
deer
war
will
be
discarded
next.
L
L
L
They
just
aboard
the
join
myself,
a
stay
on
the
destination
advice.
Next,
these
are
some
details.
Neighbor
relationship
between
pin,
rotors
will
no
longer
be
maintained
and
the
join
phone
messages
will
no
longer
be
Matic
has
visited
r1,
they
will
be
unicast
as
below
the
destination
address
of
the
joint.
When
message
should
be
the
RP
address
for
the
address
of
the
source.
The
source
address
of
the
join
point.
Messages
should
be
the
address
of
the
join
or
poignant
daughter,
necklace.
L
This
is
the
precise
in
out
that
your
messages,
Joe
Methodist,
could
be
received
by
team
daughters
through
ACL
or
similar
means.
They
could
also
be
received
by
the
destination
of
the
messages.
That's
nice,
and
there
is
one
change
to
the
packet
for
mites.
If
SP
T
is
being
joined
or
point,
there
will
be
no
join
the
point.
A
sauce
address
field
in
the
message
and
the
number
of
joined
the
sauce
in
the
message
is
one
nexus
right.
O
L
L
I
F
AA
L
L
J
L
F
C
C
H
T
Their
problem
in
this
situation
would
be.
Is
that
if
something
happens
to
dr
then
the
other
router
which
is
capable
of
taking
under
our
role
will
find
it
out
in
by
default
in
105
seconds.
So,
even
if
we
will
change
the
default
setting
to
the
minimum
so
that
hello,
packets
to
descend
every
second,
then
it
still
will
be
single-digit
seconds,
which
is
significant
impact
on
services
that
are
running
over
the
multicast
infrastructure.
T
So
what
we're
proposing
is
that
the
dr
to
use
point-to-multipoint
VFD
and
become
a
root
of
four
into
multiple
in
BD
and
other
nodes
on
the
same
shared
segment.
Pima
Seminoles,
to
be
leaves,
and
listen
to
that.
So
that
will
allow
other
nodes
to
detect
their
problem
with
the
dr
in
sub
second
interval
and
because
team
point-to-multipoint
VFD
uses
demand
mode.
So
it's
a
unicast
distribution,
so
the
leaves
don't
send
messages
to
the
room.
So
that's
it's
very
nice
fit
with
this
scenario.
T
AB
One
of
the
reasons
for
those
timers
to
be
what
they
are
is
for
the
network
to
converge.
Have
you
tried
doing
this
in
a
real
network
and
and
see
what
instability
or
the
MCOs,
because
that
continuously
is
an
issue
like
there's
a
lot
of
state?
It
may
look
nicely
on
four
four
on
a
slide
with
four
routers,
but
if
you
have
multiple
routers
and
you
start
seeing
failures
and
if
you
start
re-establishing
the
tree
too
fast,
you're
gonna
have
instability
in
a
network.
T
T
But
again,
if
we
look
at
only
this
scenario
that
we
have
only
two
routers
on
the
segment,
then
some
will
say:
okay,
why
do
you
use
point-to-multipoint
BFD
when
point-to-point
will
suffice?
First
point
to
point
is
bi-directional
and
dr
is
not
really
interested
in
the
state
of
b,
dr,
so
that
will
be
an
overhead
at
the
same
time,
and
point-to-multipoint
will
definitely
work
for
the
case
of
two
and
another.
Is
that?
T
I
T
Again.
This
is
a
proposal.
It's
that
open
for
the
discussion.
We
appreciate
the
comments
and
thank
you
for
your
insight.
If
it
seems
that
sub-second
detection
is
too
fast
again,
nothing
precludes
to
make
it
slower,
but
still
faster
than
105
seconds
again.
Use
of
DFD
does
not
mandate
how
fast
you
detect.
It
only
tells
us
that
there
is
a
way
of
being
more
flexible
than
existing
control,
plane,
detection.
AB
Absolutely
agree:
I've
seen
that
105
was
not
was
too
fast.
That's
why
I
worried
about
going
going
too
much,
because
the
whole
thing
is
if
we,
if
we
want
to
have
a
solution
for
a
faster
convergence
of
lives
and
and
we're
gonna
I'm
more
than
open
to
to
having
it,
and
then
we
have
to
make
it
really
well
defined
in
a
scope
of
what
the
scope
was
the
size.
AB
T
F
T
F
T
That's
what
we
suggest
that
the
protocols
is
that
use
mount
of
BFD
okay,
so
what
we
are
proposing,
we're
proposing
not
only
to
use
point-to-multipoint
VFD
in
this
scenario,
but
we've
proposed
to
have
an
optional
TLV
in
the
hello
packet
to
use
dr
to
bootstrap
their
session
difference
between
point-to-multipoint
BFD
and
the
regular
BD
that
there
is
no
three-way
handshake
process.
So
thus
there
needs
to
be
a
sound
out-of-band
or
whether
it's
a
control,
plane
or
management
plane
that
will
inform
leaves
of
the
discriminator
that
their
root
is
using.
T
So
that's
what
we're
proposing
this
optional
till
via
for
that
to
be
included
in
a
hello
message,
so
the
dr
will
advertise
the
discriminator
that
being
assigned
to
this
point
to
multiple
envy
of
this
session
and
then,
when
it's
a
root,
it
should
use
the
same
ip
address
as
a
source
IP
address
as
it
uses
in
team.
Hello,
FEMA,
Sam,
hello
message.
T
I
F
F
Yeah
all
right
so
just
brought
this
draft
a
few
weeks
ago
about
reserved
bits
and
PIM,
so
I
was
discussing
with
Alvaro
and
they
did
most
reviewing
small
open
documents.
We
realize
that
there
are
some
minor
issues,
so
it
turns
out
that
several
PIM
message
types
are
using
reserved
bits
from
that
common
pin
header,
but
they
don't
update
the
base
PMRC
and
the
stuffing
really
saying
whether
those
bits
are
supposed
to
be
per
message
type
for
him
if
they're
kind
of
like
common
for
all
P
messages.
F
F
F
F
So
what
is
proposing
is
that
we
use
type
15
to
extend
the
space
and
similar
to
what
was
done
with
the
X
passages
for
body
basically
says
they
can
use
smaller
bits
like
four
other
bits,
it's
further
restored,
which
is
a
subtype.
So
basically
that
means
that
it
can
have
16
additional
messages
so
accessing
implementations
they
would
just
the
type
15
and
they
read
ignore
it.
If
you
support
any
of
the
new
message
types,
you
would
have
to
implement
551
and
know
how
to
look
into
the
subtype
field
for
an
additional
type
of
specification.
F
One
thing
we
could
consider
is,
you
could
maybe
make
the
make
it
wider.
You
think
you
might
run
out
of
those
16
additional
types.
Maybe
we
could
use
whatever
service
and
actually
have
out
the
256
possible
types.
What
it
means,
though,
is
that
any
few
messages
that
are
using
those
types
would
have
to
maybe
include
our
own
restored
field
or
something
if
they
want
to
have
some
additional
circuits
for
it
for
the
specific
effect
next
slide.
Please
I,
don't
think
there's
okay
yeah.
F
So
basically
that
question
is:
do
you
think
it's
it's
worth
extending
the
type
space?
Is
it
done
in
a
useful
way?
And
hopefully
you
agree
that
it's
good
to
document
how
we
use
this
restored
bits,
and
it's
also
by
the
way,
defines
Ayana
registry
showing
which
bits
are
used
by
which
messages
for
each
purpose
so.
U
F
F
F
AD
L
AD
Rc4
RFC,
considering
that
transition
from
an
TM
Vivian
to
Pia
I
have
been
reading
attractive
to
ram
pier
on
a
mat
cast
tree,
so
one
of
the
markets
way
is
built
by
PIM.
This
is
what
this
draft
want
to
do
to
build.
America's
tree
with
some
peer
related
information
to
support
forward
in
many
mud
cast
flow
using
a
single
tree
while
not
wasting
any
link
up
and
West,
that
is
to
say,
Matt
cast,
is
always
replicated
on
demand.
AD
AD
AD
AD
AD
So
then
the
date
planned
for
adding
began
when
a
receive
a
packet.
It
imposed
a
pier
header
to
the
packet
with
a
pitter
screen
zero
one
zero
one
to
tell
every
node
in
the
network
who
received
this
packet,
that
it
wanted
to
go
to
T
and
E.
So
T
and
E
will
get
the
packet,
but
F
will
never
get
to
this
packet
because
the
meter
screen
you
0
1
0
1.
AD
AA
AD
H
AA
AA
AD
AD
So
the
next
page
we
were
introduced,
we
were,
we
appealed
the
tray
with
being
information,
the
principle.
The
principle
is
when
a
constant
stream
node
send
a
pin
joint
to
its
upstream
node.
It
include
an
extra
joy
attribute,
which
we
called
peer
joy
attribute.
It
includes
a
sub
affaire
de
coeur
de
fpm
forward
in
math
forward
in
bitmask,
for
example,
wouldn't
be
sender
to
see
him
join.
It
include
fpm
of
Tirra
Tirra
Tirra
one
and
see.
AD
AE
AD
It's
a
compilation
of
him
and
beer.
In
fact,
ambulation
okay
in
the
fastest
lab
I
have
seven.
It
is
a
combination
of
three
paths,
him
it's
a
madhouse,
the
specific
protocol
Pia,
it's
a
madhouse,
the
specific
of
encapsulation.
Why
it's
the
protocol
in
Contra
plan?
And
why
is
the
encapsulation
yet
a
plan?
We
combine
this
tool
so.
AE
AD
AB
H
C
C
AD
So
so
that's
it
an
extension
to
here
to
build
a
tree
with
the
PA
information.
Remember
that
the
most
important
in
joy
attribute
attribute,
which
includes
an
F
p.m.
when
him
join
message'
asset,
hope,
I,
hope
toward
their
root
of
the
tree,
and
one
was
in
the
scenario.
Draft
will
be
presented
tomorrow
afternoon
that
it's
the
use
case
or
scenario.
AD
Thought
this
stuff
is
in
fact
a
protocol
that
which
is
support
that
your
case
was
the
fatality
merio
way.
Court
I
have
introduced
that
we
I
am
focusing
on
a
transition.
Pierre
transition
from
traditional
ng
ambien,
so
Pima
is
one
of
the
protocol
used
in
traditional
anti-american.
So
they
see
it's
the
scenario.
AD
AA
Minami
syrup
from
Cisco
Systems,
so
I'm
presenting
this
for
one
of
my
colleague,
didn't
come
here
to
present
this
next
slide.
Yeah
we
have
only
few
slides.
So
what
are
the
motivation
behind
this
draft?
Was
the
PIM
Naldo
just
a
packet,
so
today
we
I
think
we
send
it
individual
packet
first
so,
and
there
were
couple
of
customers
who
we're
having
complain
about
all
the
thing
is
dropping
the
packet
at
the
RP
because
of
there
were
multiple
source
active
and
their
network,
and
there
are
many
more
protocols
they
already
are
doing.
AA
Basically
they
are
going
to
their
packaging,
multiple
packets,
together
and
sending
it.
So
that's
exactly
what
we
are
proposing
here
in
this
draft
that
multiple
nerve
null
resistor
can
be
pegged
in
single
resistor
and
send
it
to
RP.
And
it's
just
it's
very
small
graph,
and
there
are
a
couple
of
factors
which
we
have
taken
care,
because
one
of
the
most
difficult
part
was
that
how
you
are
going
to
say
that
which
all
know
resistor
make
it.
AA
I
gets
need
to
be
most
together,
so
it
could
be
timer
based
because
even
if,
let's
say
your
packets
are
going
every
60
seconds,
but
if
we
are
going
to
merge
a
couple
of
them
and
some
of
them
are
reaching
within
40
seconds,
so
it
might
not
matter
much.
So
we
would
request
you
to
give
a
comment
and
review.
This
draft
is
one
more
larger
yeah,
so
the
advantage
is
basically
in
the
network.
We
are
reducing
the
resistor
packets
and
better
control
plane
with
flanges.
I
J
F
F
F
Normally
within
registers,
you
have
to
do
soft
state.
You
said
registers
every
60
seconds.
If
you
have
housing
so
ask
emojis
is
like
Austin
some
messages
and
if
one
F
one
or
a
few
others
get
dropped,
you
still
end
up
doing
these
registers,
which
just
makes
things
even
worse.
So
the
idea
with
both
the
previous
traffic
on
this
is
to
come
up
with
some
solution
for
this,
especially
about
this
is
to
make
it
reliable
and
basically
make
registers
hard
state
next,
like
this,
so.
F
While
this
kind
of
came
back
now,
it's
one
thing
is
we're
talking
about
replicating
MSTP
for
into
the
menus.
The
only
other
use
for
MSTP
really
is
any
cost
RP,
but,
and
they
also
have
a
him,
invest
any
cost
RP
solution.
The
problem
with
the
pin
base
one
is
that
it's
soft
state
again
MSTP
is
colonized
in
some
way
because
it
uses
TCP.
So
it's
hard
state.
So
some
idea
the
idea
here.
F
Do
we
really
need
them
STP?
Perhaps
we
can
do
reliable
registers
over
TCP
with
payments
that
we
already
have
import,
which
is
reliable,
selling,
John
Prine
messages
over
TCP,
and
maybe
you
can
extend
that
also
send
register
messages
and,
let's
see
on
the
next
slide,
so
I
kind
of
said
this
already
today,
it's
only
in
today
we
have
to
send
individual
messages
for
every
Eskimo
G
and
then
they'll
have
this
other
vendors
of
stuff
to
act
that
and
you're
in
trouble.
If
you
start
using
some
of
those
messages,
one
solution
can
maybe
be.
F
AE
F
F
F
F
F
F
One
thing
to
consider
is:
do
we
need
something
better
than
today
for
registers
with
the
register?
Packing
draft
be
what
they
need
to
solve
this,
or
do
we
need
something
like
this
or
maybe
we
need
both
drafts.
They
are
little
bit
different.
It's
all
slightly
different
problems,
but
basically
please
read
the
draft
them.
What
is
not
what
you
think
please
give
comments
on
the
lists
or
if
you
have
a
comment
right
now,
that's
okay,
too,.