►
From YouTube: IETF112-PIM-20211109-1600
Description
PIM meeting session at IETF112
2021/11/09 1600
https://datatracker.ietf.org/meeting/112/proceedings/
A
B
Okay,
so
yeah
here
we
go
welcome
everyone.
Itf112
here
is
the
note.
Well
you've
seen
this
many
times,
I'm
sure
it's
easy
to
just
gloss
over
this,
but
it's
it's
lots
of
good
information
here
that
I
hope
people
have
read,
especially
the
code
of
conduct.
Ecp
54
is
maybe
important.
B
B
So
one
thing
to
note
here
is
there's:
no.
We
have
had
some
presentations
recently
on
on
multicast
and
source
routing.
There's
no,
that
on
well
there's
one
draft
on
this
agenda,
but
there's
a
side
meeting
on
friday
to
discuss
those
topics.
It's
not
like
an
official
ietf
session,
but
it's
an
open
meeting
to
everyone.
C
Hey:
hey,
hey
steak,
it
might
be
just
good
if
you
sent
that
to
that
link
to
the
pim
list
as
well.
B
Right
yeah
sure
we
can
do
that
yeah.
Okay,
thank
you,
yeah!
Okay,
for
the
working
group
status,
there
is
the
the
pym
yang
model,
which
has
been
in
the
re.
Rfc
editor's
queue
for
a
few
years
it
seems
like,
but
that
should
be
published
in
a
few
days
now
from
what
I
understand.
It's
it's.
It's
like
going
through
the
final
review
right
before
publication.
D
No,
no,
I
yeah.
I
got
on
the
queue
I
got
off
because
I
I
saw
ac,
you
thought
I
wanted.
I
thought
he
wanted
to
say
something
and
I
think
maybe
we're
going
to
see
the
same
thing
or
hopefully
we're
going
to
see
the
same
thing.
Yeah.
The
ping
yang
model
is
in
the
our
mosquitoes.
It
has
been
there
for
a
while.
D
There
was
a
very
late
bug
found
not
in
the
pim
module,
but
in
the
bfd
module
that
pim
imports
and
etc.
So
that
affects
only
pim.
It
affects
ospf
and
isis,
which
are
also
in
the
editors
queue.
The
problem,
the
bigger
problem,
is
that
vfd
was
already
published
as
an
rrc,
so
we
have
been
talking
to
all
the
authors
to
see
how
well
what
is
the
best
way
to
fix
this
right
now
rob
wilton
who's.
The
op
cd
is
talking
to
the
yang
doctors,
to
figure
out.
D
What's
the
best
way
where
we
think
the
cleanest
way
is
is
to
republish
rfc
91
27,
I
think,
is
what
the
bfd
module
is
and
the
intent
would
be
to.
You
know
fast
track
that
as
much
as
possible,
because
apparently
there
are
no
implementations
and
then
and
have
the
other
documents,
including
the
pin
module
your
published
essays
or
as
they
are
right
with
with
with
no
changes
so
that
only
the
only
changes
are
in
the
bfd
module.
D
So
in
any
case,
that's
a
long
story
to
say
that
it
may
not
be
in
the
next
few
days.
It
may
be,
hopefully
the
next
few
weeks.
Hopefully
not
it,
won't
go
in
two
months
or
anything
anything
like
that,
but
but
I
think
I
sent
you
guys
an
email
at
some
point,
maybe
the
last
couple
of
days.
I
know
it's
been
busy,
but
yeah
just
take
a
look
at
that.
B
Yeah,
so
it's
not
our
fault,
it's
all
external
references
all
right,
so
we
recently
requested
publication
of
the
bfd
point
to
multi-point
use
case,
that's
being
evaluated.
Well.
Actually
it's
it's!
I
guess
right
before
last
itf
we
requested
that
then
more
recently,
we
request
requested
publication
for
rgmp
mlb
extensions.
B
B
So
for
this
we
we
really
need
to
make
some
progress
and
we've
been
thinking
about
yeah
having
you
know
how
to
have
some
good
working
with
discussion
on
this.
So
I
think
for
next
slide.
Jeff.
We
should
try
to
try
to
make
some
progress
here,
find
some
way
to
compare
the
approaches
and
have
some
discussion
about
how
to
proceed
in
the
working
group.
A
Yeah,
because
we're
at
the
authors
are
really
driving
these
efforts.
If
they're
not
driving
it,
then
it's
going
to
kind
of
fall
by
the
wayside
and
we
agreed
at
the
beginning
that
we
don't
have
to
progress
both
drafts
because
they're
similar
you
know,
we
talked
about
whether
to
merge
or
to
leave
them
separate
and
so
far
as
a
working
group,
we
decided
to
adopt
them
separately.
A
But
if
there's
not
a,
if
there's
not
progress
on
these
drafts,
then
one
of
them
or
both
of
them
are
gonna
just
kind
of
die
off
and
that's
a
good
point
alvaro.
B
Yeah,
so
ultimately
we
we
want
to
find
out.
You
know
what
what
are
the
right
technical
solutions?
Do
we
need
one
solution?
Do
we
need
two
solutions,
but
what
what
do
we
think
is
the
best
and
then
based
on
that,
we
will
decide.
You
know
how
to
progress
with
each
draft
above
drafts
or
or
a
new
draft
or
whatever.
B
The
main
thing
is
that
to
come
to
agreement
on
the
technical,
the
protocol
aspects-
okay,
let's
see
okay
yeah,
we
also
have
igp
mld
proxy
young
model.
It
passed
working
group
last
call
and
I'll
learn.
Oh
request
publications
sometime
next
week
or
so.
B
Let's
see,
we
also
have
null
register
packing.
We
had
some
issues
at
first
with
that
the
quality
wasn't
it
wasn't
good
enough?
It
had
some
shortcomings,
so
it
was
returned
to
the
working
group.
But
after
that
we
have
a
pretty
good
review
by
several
work
group
members,
some
discussions,
and
also
by
the
routing
directorate,
so
yeah
mike,
is
driving
that
well,
I
believe
we
are
about
request
publication
for
that.
B
Then
there's
an
assert
packing
draft,
so
yeah
most
worker
plus
call
comments
were
addressed.
I
had
a
few
just
a
few
minor
comments
that
I
think
should
be
addressed
before
publication.
B
So
once
those
are
addressed,
I'll
go
ahead
and
yeah
request
publication
of
that
as
well,
then
we
have
the
point-to-point
star
point-to-point,
multi-uh
point
to
multi-point
policy,
which
we
will
discuss
this
meeting
and
also
you
are
doing
some
work
on
progressing
igp
with
3ml2
to
internet
standard
and
we'll
have
a
presentational
discussion
about
that.
B
A
One
thing
we
don't
have
on
here
is
the
draft
that
you
recently
called
a
adoption
call
for
humans
point
to
multi-point
ping.
E
A
Draft
which
it
looks
like
we
are
good
to
adopt
as
far
as
consensus
is
concerned,
however,
we
did
receive
a
comment
that
it
would
be
helpful
in
that
draft
human,
if
you're
hearing
this,
that
to
specify
whether
this
is
focused
on
the
sr
mpls
data
plane
or
the
and
or
the
srv6
data
plane,
and
to
specify
that
in
the
draft-
and
it
was
also
requested
that
before
we
adopt
it-
that
we
ping
the
mpls
working
group
just
as
a
cc-
at
least
the
the
chairs,
so
that
they
know
that
we're
using
their
code
point
in
this
draft.
F
A
That'd
be
great,
if
you
can
update
that
and
then
and
then
we
will
just
stick,
and
I
will
do
the
thing
that
we
need
to
do
with
the
other
work
group
chairs
and
then
we
will
likely
make
an
adoption
yeah,
we'll.
G
A
Yeah,
so
just
good
segue
is
that
we,
as
agreed
with
the
spring
chairs
over
the
last
year
or
two,
we
are
doing
sr
point
to
multiply
work
in
pim
for
a
variety
of
reasons,
including
springs
just
very
busy,
and
they
prefer
to
have
us
do
it.
So
we
have
adopted
a
draft
and
it
looks
like
we'll
be
dropping
adopting
a
second
draft.
A
But
for
now
that
work
appears
to
be
remaining
in
those
other
working
groups,
and
it
would
be
helpful
if
we
at
least
be
aware
of
those
works
and
stig,
and
I
will
do
our
best
to
make
this
working
group
aware
of
point
of
multiplayer
work
going
on
in
other
working
groups.
So
we
can
add
our
expertise
and
comments
to
help
them
to
make
sure
it
jives
with
our
our
protocols.
A
Okay,
so
we
will
be
sending
we
were
intending
to
have
this
done
by
this
this
itf,
but
because
of
what
I
just
described,
we
were
not
able
to
to
solidify
it,
but
so
far
we
have
this
charter
update,
everything's
the
same,
except
we
did
remove
the
first
bullet
with
regards
to
management
and
yang,
and
we
removed
that
because,
as
far
as
we
know,
the
yang
work
is
basically
done.
If
that
is
that,
does
that
sound
correct
to
everybody?.
A
Okay,
so
nobody's
jumping
in
and
you'll
have
a
comment
to
opportunity
to
come
on
the
list
too.
So
we
kept
the
rest
that
is
already
in
our
charter
and
then
added
this
last
bullet,
so
remove
that
one
bullet
and
added
this
one,
which
is
to
develop
point-to-multipoint
protocols.
A
A
So
that's
really
the
main
thing
that
we
wanted
to
make
sure
that
we're
all
aware
of
that.
It's
already
been
an
understanding
that
we're
taking
on
this
work
specifically
from
spring,
but
we
wanted
to
make
it
more
formal
and
then
the
rest
of
the
charter
stands,
as
is,
which
is
to
comment
about
aligning
and
working
with
other
working
groups.
Any
comments
about
this
charter
update.
D
So
you
already,
you
mentioned
some
of
the
other
work
in
other
places
and
that
side
meeting
that's
happening
on
friday.
D
So
you
know
in
general,
the
charter
looks
fine
to
me.
I
think
that
we're
gonna
want
to
look
at
that
other
work
on
friday,
sync
with
all
the
other
chairs,
to
make
sure
that
you
know
we
all
have
all
our
ducks
in
a
row.
D
We
do
need
better
coordination
across
working
groups,
and
you
know
that's
one
item
that
I
think
we
are
seeing
very
much
right
now
with
multicast,
but
that
happens
in
other
cases
as
well,
where
we
see
multiple
types
of
work
or
multiple
work.
That,
in
this
case,
refers
to
the
architecture
being
worked
here.
We
see
work
in
idr,
we
see
working
best.
We
see
work
in
pce
and
other
places
that
all
refer
to
the
architecture,
but
that
are
different
solutions.
So
we
want
to
make
sure
that
we
coordinate
that.
D
So
as
far
as
the
charter
sure
I
mean
we
should
probably
start
discussing
that
we
probably
don't
won't
want
to.
You
know
progress
it
until
we
have
all
the
other
ducks
in
mind
so
that
we
do
this.
Just
once
right
and
not
have
to
maybe
do
it
twice
or
whatever
so
at
that
time,
and
hopefully
we
can
get
that
done
in
the
next
few
weeks
as
well,
so
that
we
are
all
in
in
agreement
on
what's
going
to
happen
and
who's
going
to
coordinate
and
and
all
those
other
things.
A
Great
thank
you
hi
june.
H
Yeah
for
for
for
sr
based
p2mt
solution.
I
I
think
the
the
sr
based
multicast
solution
is
different
from
the
team
protocol.
So
my
recommendation
is:
we
can
consider
with
the
side
media
that
will
be
held
in
friday
for
the
msr
side
meeting.
You
know
the
other
related.
All
these
are
released,
multicast
workers.
I
think
it
should
be
included
in
my
new
new
working
group.
H
D
What
stay
already
said
before,
which
is
the
site
meeting,
is
not
an
official
atf
meeting
right,
so
you
can
discuss
anything
you
want.
We
still
need
to
agree
in
the
atf
where
and
how
anything's
going
to
be
done
right.
D
Everyone
knows
here
that
we
need
to
look
at
charters,
and
you
know
everything
else
if
there
is
work
which
hasn't
been
presented
anywhere
in
the
atf
yet
to
be
done
in
a
new
working
group
sure
we
can
consider
that
if
the
work
of
course
overlaps
with
other
things,
we
can
do
it
in
in
you
know
other
places,
just
a
reminder
to
everyone.
D
This
working
group
is
called
pim,
not
because
of
the
protocol,
but
because
of
how
you
know
what
it
says
in
the
charter
here
on
the
slide,
this
is
called
protocols
for
ip
multicast,
not
protocol,
independent
multicast.
We
chartered
this
what
four
or
five
years
ago
to
on
purpose
be
able
to
increase
the
scope,
if
necessary.
Now
that
doesn't
mean
that
everything
that
has
to
do
with
multitasking
has
to
go
here
right.
D
It
just
means
that
that
we
need
to
to
discuss
that
and,
as
with
everything
you
know,
things
need
to
be
presented
in
the
atf.
We
need
to
discuss
charters,
yeah
et
cetera,
right,
it's
not
just.
Unfortunately,
not
everything
is
automatic,
as
as
it
should
be.
Okay,
thanks.
A
Yeah,
thank
you
yeah.
So
there's
been
many
comments
about
the
side
meeting.
I
think
we
should
regularly
do
side
meetings
that
just
don't
fit
within
a
working
group
time
period.
Jake
holland
had
an
interesting
one.
Last
ietf
and
I've
already
from
a
side
meeting
that
I
attended
this
week
yesterday
on
addressing.
I
already
had
an
idea
that
I
think
I
may
want
to
present
along
with
dino
on
dlts
and
an
ipa
multicast,
so
I
think
side
meetings,
hopefully
are
becoming
like
a
multicast.
B
All
right
so
yeah,
so
let's
be
one
with
the
agenda,
so
let's
see
yeah
so
just
to
remind
people.
This
is
the
agenda.
So
I'll
start
out
with
now
with
this
and
then
yeah
that
will
just
be
just
a
few
minutes
and
then
you
can
go
next
stop
for
me.
Okay,
let's
see
the
slides
here.
B
All
right,
so
this
is
the
drone
print
attributes
for
lisp
environments
using
underlay
multicast.
So
there
was
a
draft
in
the
pin
working
group
some
years
back
defining
these
attributes.
B
The
only
thing
is
that
the
attributes
could
be
used
for
to
specify
a
unicast
destination
for
like
ingress
replication,
but
as
defined
they
couldn't
be
used
for
underlay
multicast.
So
what
this
draft
is
doing
is
basically
saying
that
you
can
also
specify
a
multicast
address
as
a
destination
address
for
lisp
and
cap,
so
this
draft
was
presented
in.
Let
me
go
to
the
next
slide.
B
B
But
okay
yeah!
So,
let's
see
looking
for
okay
yeah.
I
have
a
couple
of
slides
here
that
can
remind
people
what
this
is
about,
but
I
feel,
like
I
already
said
basically
what
there
is
to
say
it's
about
getting
this
across
a
multicast
core
network.
We
need
to
specify
the
online
multicast
address
and
basically
using
that
existing
tlv,
just
specifying
that
a
multicast
group
can
be
specif
can
be
used.
B
That's
all
we
are
doing
in
this
draft,
so
yeah
we're
hoping
to
get
some
comments
review
from
the
working
group
and
you
will
work
on
the
security
considerations
and
hopefully
we
can
do
a
loss
call
soon.
A
Can
you
put
your
pen
hat
back
on
so
just
from
a
why?
Well,
while
we
were
talking
about
pen
rechartering,
do
we
need
to
add
anything
about
lisp
related
work,
or
do
you
think
this
is
just
kind
of
a
one-off
we
do
have
in
our
charter?
At
the
end,
they
we
mentioned
working
with
other
working
groups,
including
lisp.
Do
you
think
that's
good
enough
for
now.
B
Right
so
in
this
particular
case,
the
reason
we're
doing
it
in
pim
is
that
you
know
it
has
to
do
with
that
pin
joint
attribute,
and
that
is
in
our
current
charter.
B
So
I
think
you
are
good
there.
Great
there's
been
some
multicast
work
done
in
the
list
working
group
as
well,
but
it
doesn't
involve
him
in
any
way,
so
that
was
done
purely
in
the
list.
Working
group,
okay,.
B
Right,
okay,
yeah
all
right,
so
next
step
is
multi-point
policy.
F
F
By
the
way
can
can
you
guys
hear
me
clearly
yeah,
okay,
so
as
of
now,
the
replication
segment
is
obviously
adopted
by
the
sr,
and
this
working
group
has
adopted
the
point
to
multiplying
policy
I'll
give
you
a
little
bit
of
update
what
has
changed
in
that
draft?
F
I'm
not
going
to
talk
too
much
about
the
end.
There
hasn't
been
too
much
churn
on
the
yang
and
eventually,
I
think.
F
Next
itf
and
present
them
to
the
appropriate
working
group
based
on
the
the
yang.
So
that's
one
thing
we
have
talked
about.
Unfortunately,
I
haven't
done
it
so
far.
I'll
do
that
for
the
next
idea
when
it
comes
to
the
best
in
vpn
evpn
sr
point
to
multiply
policy.
F
We
can
signal
the
services
over
a
point
to
multiplying
policy
between
two
pe's
from
the
pce
point
of
view
and
nailing
down
the
point
to
multiple
point.
Three:
on
the
on
the
routers,
we
went
through
some
changes
in
the
draft.
I'm
not
going
to
get
into
the
detail.
There
was
a
adoption
call
which
was
had
a
majority.
F
A
Just
it's
not
it's
not
just
me
like
every
minute,
or
so.
Your
audio
just
disappears
for
like
10
seconds.
So
I
don't
know
if
there's
anything
you
can
do
on
your
end,
especially
since
you're
giving
another
presentation
after
this
one.
So
just.
F
A
Yeah
we
didn't
just.
We
didn't
hear
any
of
that
last
20
seconds.
A
G
A
Let's
give
him
a
second:
if
he
doesn't
come
back,
we
can
go
to
the
next
presentation.
On
extension,.
B
Yeah
yeah,
I
think
it.
A
Lee
for
ig
pmld,
yeah
extension.
I
I
Msnp
msnp
is
designed
around
the
premise
that
you
want
to
minimize
source
when
no
receiver
listening,
msnip
focus,
focus
primarily
on
dataflow
control
or
documents
aims
at
management
of
multicast
source
and
related
service,
including
control
of
multicast
source
access,
which
can
improve
the
security
of
multicast
control
of
data
flow,
which
is
consist
consistent
with
the
idea
of
ms
nip
management
of
money.
Casters
statistics
with
controller
and
other
uses
can
be
extended
based
on
source
registration.
I
I
I
I
I
I
For
multicast
source
registration
message
and
the
update
is
the
credentials
is
extended
to
16
bits.
In
addition
to
earned
timestamps
times,
stamp
is
replaced
by
three
by
the
duration,
the
start
time
and
the
duration
are
not
related
to
the
timer
mentioned
in
the
process
start
time.
Timestamps
indicates
the
start
time
when
the
multicast
source
can
prove
can
provide
a
service
for
multicast
approves
before
this
time.
Router
don't
send
the
multicast
data
notification
message
to
the
source
system.
I
I
I
B
Well,
I
can
mention
that
yeah,
I'm,
like
I
joined
as
a
co-author,
and
I
have
some
contents
that
I
plan
to
add
on
use
cases
and
yeah.
Some
more
work
to
be
done.
Okay,.
A
Last
itf
you
mentioned
m
snip.
Was
there
ever
like
a
comparison
to
see
if
the
work
done
in
the
past
applies
to
this.
B
It's
this,
at
least
from
protocol
point
of
view.
I
feel
that
the
main
thing
is
this:
you
know
basically,
that
the
source
can
notify
that
it
wants
to
be
a
wants
to
sell
multicast
and
that
there's
a
way
for
the
router
to
respond
back
to
the
source,
with
some
information
right
about
receivers
and
so
on,
and
that's
common
in
both
of
these
drafts
of
m
snip
and
this
draft.
But
the
motivation
is,
is
different
and
yeah.
I
think
we
have
several
use
cases
that
are
not
mentioned
back
in
the
m
step
draft.
B
There's
some
differences
too,
like
this
job
talks
about,
I
mean
there's
like
credentials
and
you
can
announce
like
start
time
and
someone
that
was
not
there
in
amsterdam.
H
H
I
think
we
can
cooperate
and
under
the
that
messenger
used
msnp
in
the
left
update.
So
we
also
understood
as
a
closure
to
put
for
this
job
and
we
in
the
either
can't
update
the
person.
We
have
also
adopted
the
command
from
the
from
stick
for
the
encoding
of
the
message
and
for
the
timer
timer
control
for
the
register,
timer
control,
etc.
Okay,.
C
Cisco
systems,
can
you
hear
me?
Yes,
you
can
we
can't
now
no
yeah
it.
It
asked
me
to
allow
every
time
I
turn
my
audio
on.
I
don't
know
why
the
the
primary
motivation
for
this
would
be
one
you
can
do.
Credential
validation
of
the
sources
and
number
two
you
can
tell
the
sources
to
quit.
Sending
when
there
are
absolutely
no
receivers
is
that
what
it
is
are
those
the
two
main
two
main
advantages?
H
Yeah
yeah,
I
I
think
yeah
yeah
correct
the
main
goal.
E
H
Result
is
to
the
first
thing
is
to
authenticate
the
multicultural
source
we
want
to
deploy
the
multicast
in
the
control
manner,
so
not
every
not
any
source
can
send
the
mouse
password
for
the
network.
This
is
the
first
first
thing,
the
second
name.
We
want
to
feedback
some
more
information
for
the
receiver.
H
C
C
B
F
G
J
I
didn't
leave
this
draft,
so
I
may
miss
the
point,
but
why
this
draft
wants
to
use
igmp
or
mld
for
source
discovery.
So
maybe
there
was
a
next
time.
J
I
may
clarify
the
more
difference
about
between
ms
nip
and
this
draft,
because
in
fact
I
couldn't
understand
the
clear
difference
between
ims
and
ipad,
this
draft,
but
in
any
case,
so
why
you
need
to
use
igmp
or
mle,
because
igpmla
is
usually
or
in
general,
used
for
the
receiver
protocol,
so
why
you
need
to
extend
ignp
mld
for
source
discovery
and
for
the
source
discovery.
If
we
talk
about
a
very
old
protocol,
we
already
have
sap
sap.
Of
course
sap
is
not
perfect
profitable.
J
So
that's
why
maybe
recently,
no
one
has
been
using
sap,
but
sap
itself
can
become
as
something
like
a
source
notification.
So
you
can
extend
sap,
even
if
you
want
to
enhance
some
credential
approach
for
source
discovery.
So
my
question
is
why
you
need
to
use
or
need
to
extend
or
medley.
H
Yeah
I
try
to
answer
I
I
I
I'm
not
aware
with
the.
H
The
protocol
between
the
horse
standard
and
its
first
road
router,
you
know
the
the
allies
responsible.
I
say
the
main
protocol
of
the
main
proposal
of
reserve
is
to
authenticate
the
the
multiple
source,
not
not
the
firing
source
really
in
the
network.
You
know
so
for
authenticated
resource,
it
is
a
must
depend
on
the
protocol
at
the
layers
between
the
host
and
the
first
router,
so
ignp
and
ambi
is
in
the
best
selection
for
such
control.
H
You
know
we
we
don't
want
to
solve
the
source
recovery
within
within
the
network
and
missing
the
by
finance.
Currently
we
focus
on
the
ssn
sm
ssm
scenario,
so
there
is
no
rp
in
the
network.
Okay,.
A
E
Yeah,
it
seems
like
this
idea
of
kind
of
request
to
send
where
the
sender
actually
requests
to
send
something
into
the
network.
It
feels
like
this
is
an
old
idea
and
I
remember
it
being
abandoned
a
long
time
ago,
but
I
I
remember,
m
snip
not
getting
much
traction.
I
I
think
I'm
not
old
enough
to
remember
why
rts
died.
I
think
that
might
have
been
a
little
bit
before
my
time,
but
I'd
be
curious.
E
B
Would
say
I
I
don't
remember,
but
at
least
the
main
challenge
I
see
is
you
know,
deployment
it's
very
hard
to
get
hosts
upgraded
to
support
something
like
this.
So
even
you
know
like
going
from
igp
with
two
to
three
or
seven
two
years
and
years,
but
I
at
least
I
imagine
it
could
be
useful
in
some
special.
B
I
don't
know
some
special
cases,
maybe
not
like
you
know,
like
generic
windows
through
linux,
but
maybe,
let's
say
cameras
with
ip
support
or
I
don't
know
it
could
be
more
specialized
use
cases.
Perhaps,
but
at
least
that's
a
big
challenge
is
how
do
you
get
something
like
this
into
like
host
stacks
in
general?.
E
H
I
I
think,
for
you
know,
because
we
want
to
make
the
the
smart
caster
in
one
control
manner,
so
we
think
the
source
must
be
authenticated
and
controlled.
So
it
is
different
from
the
start
point
of
the
ms9
here.
So
I
think
we
can
and
the
source
is
the
number
of
smartphones
in
limited.
So
I
think
we
can.
The
update
of
the
may
be
acceptable.
H
Okay,
it
is
not
like
the
receiver
side,
so
so
I
think
we
can
put
for
the
implementation
of
the
multiple
multiple
sources
for
such
protocol
extensions.
Okay:
this
is
our
main
aim
for
the
design
of
this
project.
A
Great
thank
you.
I
suggest
we
communicate
more
on
the
list
and
not
wait
till
the
next
itf
to
present
this
and
let's
see
what
people
think.
F
Can
you
hear
me,
okay,
all
right,
so
pim
light?
If
you
can
go
to
the
next
slide,
please
so
the
entire
idea
was
born
based
on
the
last
call
that
we
had
on
the
beer
signaling.
K
F
There's
construction
around
so
maybe
they
cut
something
or
not.
You
know
yeah,
so
the
in
the
beer
signaling
we
use
the
pim,
join
and
prunes
to
signal
them.
A
F
I
I
apologize,
I
think
I'm
just
gonna
take
away
time
from
working
group.
I.
E
F
Okay,
so
basically,
we
want
join
prunes
without
the
pim
hello
to
be
accepted
from
other
routers
other
peer
routers,
so
including
the
assert
messages.
So
this
is
what
we're
going
to
call
pim
lite.
F
F
F
Perfect
so
again,
it's
pim
with
zero
calories.
We
all
know
that
pim
is
complicated.
The
protocol,
which
some
networks
or
interface
types,
might
not
be
able
to
support
or
are
not
optimized
for
the
pim
protocol.
F
In
in
the
beer
network,
where
you
have
beer
packets
going
between
two
pim
domain,
really,
the
beer
encapsulation
is
not
optimized
for
sending
pim
hellos
and
bringing
up
full
pim
adjacency
between
the
two
pim
domains.
If
you
will
so,
this
pin
light
plays
very
nicely
with
a.
F
F
D
Thanks
mike,
but
I
haven't,
read
the
document,
but
can
we
what
you're
defining
here
is
really
a
different
type
of
interface?
Can
we
actually
call
the
draft
not
just
pim
lite
but
pim
light
interface,
or
something
like
that,
so
that
gives
the
idea
of
what
we're
really
specifying
in
it.
D
K
A
Let
me
just
chime
in
right
now
woman
and
say
that
one
thing
that
is
unique
about
this
draft
is
being
that
stig
and
I
are
both
on
it-
is
that
we
can't
call
for
adoption
of
this
draft.
So
we
would
need
to
have
a
shepherd
be
as
if
they're
a
chair
for
this
particular
draft
and
do
the
calling
for
adoptions
and
follow
this
draft
throughout
the
life
of
the
draft.
A
If
it
were
to
be
adopted
and
do
the
working
group
last
call
and
all
that
so
does,
and
we
can
pull
the
list
and
see
or
just
find
someone
and
ask
him
if
they
do
it,
but
right
now
does
anybody?
Would
anybody
be
willing
to
to
fill
that
role
for
this
draft.
A
A
Yeah,
thank
you
sandy
you're
you're.
It
appreciate
your
helping
out
with
that.
Well
stig,
and
I
will
talk
to
you
more
about
that
via
email
all
right,
so
we
have
that
volunteer
great.
B
Yeah
unleash:
are
you
interested
and
able
to
to
present.
B
G
Yeah
hi,
so
this
presentation
is
for
advancing
igmp,
v3
and
mlv2
to
internet
standard,
so
in
last
ietf
111.
We
also
presented
this
at
that
time.
We
asked
for
adoption,
and
now
it
is
a
working
group
draft,
so
we
submitted
the
first
version
with
some
changes
before
the
cut
off
and
for
both
three
three:
seven:
six
for
ignp
v3
and
three:
eight
one
zero
for
mlt
v2.
G
So
I
can
briefly
talk
about
some
of
the
changes
which
we
incorporated
so
for
3376.
One
of
the
changes
which
we
did
like
recently.
There
was
a
query
over
the
working
group,
alias
regarding
the
query
election
process,
which
was
being
seen
and
like
one
of
the
implementations
where
we
don't
have
a
clear
way
of
identifying
whether
which
query
should
be
used
for
the
election
process.
So
for
more
details,
we
can
look
at
the
emails
in
the
working
group
and
so
that
that
was
one
of
the
issues
which
got
incorporated
in
3376.
G
Second
thing
was
the
mld
messages
being
sent
with
link
local
addresses,
and
this
is
for
three,
eight
one:
zero
and
one
of
the
erratas,
which
was
filed
against
three
eight
one.
Zero
mld
v2
was
the
right
of
four
seven,
seven:
three,
where
it
talks
about
the
missing
recipe
field,
so
that
also
got
incorporated
in
version
one
and
one
of
the
older
orders,
which
was
filed
against
three
three
seven.
G
Six
is
four
three:
seven:
five,
where
the
older
version
query
present
time
of
definition
itself
has
some
discrepancy,
so
this
is
also
being
incorporated,
and
I
guess
we
there
is
another
thing
missing.
So
there
is
another
area
which
is
like
kind
of
editorial,
which
is
five
three
seven,
five
against
ignpv3376rfc.
G
G
G
Yeah,
so
some
of
the
open
issues
which
we
have
right
now
is
like
do
we
want
to
move
rfcs1112
with
igmp,
v1
and
mldv1
to
historic?
So
this
is
also
one
of
the
questions
which
will
be
asked
in
the
last
atf
as
well,
and
second
thing
is
like
rfc,
four
zero,
four,
six,
zero,
four
ssm
for
igmp
and
mlt.
G
So
do
do
we
want
to
incorporate
that
in
the
this,
while
this,
while
we
are
moving
with
the
advancement
of
this
internet
standard,
so
we
want
to
incorporate
4604
and
that
and
another
question
is
like
how
we
want
to
define
the
relationship
with
the
new
pim
igmp
mld
extension
of
this
piece.
This
drops-
and
I
guess
last
one
is
the
errada
675
which
is
recently
being
filed,
and
I
brian,
I
think,
he's
already
working
on
it.
So
I
there
there
is
some
email
communication
happening
over
the
working
group
as
well.
B
B
For
to
make
the
right
decision
on
the
first
two,
I
think
you
know
we
need
to
have
more
details.
B
I
think-
and
it's
probably
good
to
send
some
emails
to
the
working
group
mailing
list
and
basically
outline
a
bit
more
what
what
you
should
consider
like,
for
instance,
for
4604
like
what
is
the
actual
text
that
what's
the
scope
of
the
work,
you
know
what
text
do
we
want
to
actually
copy
from
4604,
so
yeah,
it's
kind
of
hard
to
without
having
all
those
details,
and
maybe
doing
some
thinking
to
to
answer
these
questions
right.
So
getting
some
discussion
on
the
list
of
big
rates.
G
Guess
for
second
one,
while
in
the
internal
meeting
we
do
identified
so
what
sections
we
would
be
borrowing
from
4604,
I
think
yeah.
It
would
be
better
if
we
put
all
those
things
in
email
and
get
along
on
the
group.