►
From YouTube: IETF109-PIM-20201116-0900
Description
PIM meeting session at IETF109
2020/11/16 0900
https://datatracker.ietf.org/meeting/109/proceedings/
A
B
B
C
B
D
Okay,
yeah,
okay,
just
got
it
working
here:
okay,
I'll
start
sharing.
D
B
B
Just
out
of
curiosity,
stick
are
you
on
a
pc
or
mac,
and
what
browser
are
you
using.
D
This
is
yeah.
This
is
windows
with
a
crap.
D
E
F
D
D
B
D
Okay,
all
right,
so
it's
okay
right
now!
Okay,
let's
try
this
okay.
So
this
is
the
agenda
so
we'll
get
to
this
draft
scene.
For
that
we'll
look
at
the
current
working
group
status.
D
D
That's
great
news
and
we
got
some
more
young
models
coming
both
the
pygmyang
model
and
models,
the
sleeping
and
models
should
be
published
soon.
I
think
it's
mostly
a
matter
of
waiting
for
references,
so
that's
the
good
news.
The
bad
news
is.
We
have
a
couple
of
drafts
that
we
requested
publication
for,
but
the
eddy
returned
them
to
us.
D
So
there
were,
I
think
there
are
various
editorial
things
or
things
that
needed
to
be
clarified
also
in
part.
One
particular
thing
was
the
relationship
between
this
and
the
backup,
dr
draft,
so
we
yeah
there
is
some
text
to
try
to
address
that,
but
it
seems
like
we
may
need
some
more
discussion
or
clarification,
so
we
don't
have
an
update
just
yet.
D
D
D
All
right,
then,
we
have
some
more
drafts.
We
have
the
point
to
multipoint
bfd
draft
that
is
in
working
with
last
call
right
now,
so
that
ends
on
friday,
since
the
responses
on
the
list
already,
but
please
yeah,
please
keep
them
coming
and
also
lots
of
people
saying
you
know
let
it
support
it,
but
it's
also
great.
If
people
can,
you
know,
provide
comments
on
the
text.
That
is
something
that
can
be
improved
or
yeah.
D
What
any
issues
you
might
have
draft
the
igp
mld
proxy
yang
model
will
be
discussed
today,
also
the
imp,
mld
extension.
D
D
D
D
D
D
B
Your
audio
is
still
struggling.
Pretty
bad
stick.
Oh
it's
good!
It's
going
to
go
in,
but,
okay
now
it
sounds
great
right
now,
but
it
just
every
30
seconds
or
so
it
just
tanks.
D
D
Let's
see
okay,
so
hopefully
it
will
be
fine
now
so
yeah.
So
I
don't
want
to
repeat
all
of
this,
but
basically
we
have
this
draft
with
a
survey
report
you
can
see
at
the
bottom
of
the
slide.
D
So
please
have
a
look
at
that
and
we
want
people
that
can
help
to
work
on
progressing
the
rgmp
and
mld
specs
to
internet
standard
I'll,
send
an
email
to
the
list
with
some
more
details,
but
we
discussed
this
in
the
past.
So
basically
you
want
to
not
like
add
new
protocol
stuff,
but
basically
take
some
stuff
out
if
it's
not
implemented
or
used
and
fixed
imperability
issues
and
so
on.
D
D
H
D
We
see
it,
though
yeah
all
right,
great,
okay,
so
yeah
I've
been
presenting
this
a
few
meetings
now
so
basically
want
some
generic
way
of
extending
rgmp
and
mld,
adding
some
tlvs.
D
So
what
this
draft
does
is
talk
about
how
to
extend
the
protocol
defining
the
tlv
formats
on
well,
not
exactly
not
the
tlvs
themselves,
but
basically
how
the
tlv
approach
works
and
also
it
talks
about
backwards,
compatibility
and
things
that
new
documents
well
any
documents
that
define
your
types,
what
they
need
to
specify.
D
So,
for
instance,
you
need
to
and
any
document
defining
a
new
type
needs
to
have
some
discussion
about
backwards,
compatibility.
What
if
some
some
hosts
or
routers
on
the
subnet
supports
the
new
tlb
and
some
downtime
and
various
other
things.
So
it
calls
out
what
those
documents
need
to
need
to
support.
D
Let's
see
for
the
the
format
itself,
it's
the
same
as
a
presented
the
last
meeting.
So
it
is,
we
are
using
the
additional
data
section
of
igmp
and
mld.
So
basically,
we
have
a
restart
bit.
The
e
you
can
see
in
blue
here
that
indicates
that
this
extension
is
being
used,
and
then
the
blue
at
the
bottom
is
where
the
additional
data
is
that
will
contain
these
tlbs
and
the
tlv
format
is
like
this.
So
this
comes
basically
at
the
end
of
comes
after.
D
What
is
currently
in
the
imp
or
mld
message?
So
it's
just
a
list
of
tlbs.
There
is
some
restored
bits
and
a
total
extension
length,
and
then
there
is
like
each
tle.
Maybe
I
shouldn't
go
too
much
into
this
because
we
discussed
this
the
last
meeting.
But
one
reason
for
the
total
extension
length
is
that
we
can
just
like
current
rgmp
and
mld
protocols.
D
So
they
can
be
any
additional
data
for
future
protocol
enhancements.
So
last
itf.
The
main
comment
was
that
there
should
be
some
more
discussion
in
the
draft
about
how
to
use
this
and
compatibility
and
so
on,
and
I
tried
to
address
that
so
and
most
of
that
is
basically
saying
what
what
the
drafts
that
actually
define.
Specific
types
need
to
need
to
specify.
D
Yeah,
so
personally,
I
feel
that
I'm
pretty
much
finished
with
this
draft.
At
least
I've
done
what
I
I
I
can
think
of
adding
to
it
so
to
make
any
progress,
I
feel
either
I
need
some
comments
or,
or
maybe
everyone
is
happy
with
it
we'll
see,
but
I
think
it
would
be
good
to
the
working
group
last
call
if
the
chairs,
the
working
group
are
happy
with
that.
D
Yeah,
what
I
maybe
should
add
is
the
motivation
for
this
right
now
is
a
beer
overlay
or,
I
should
say,
igmp
mld
overlay
for
beer,
where
we
want
to
pass
some
additional
beer
info,
but
this
is
generic,
so
we
you
can
use
it
for
to
add
anything
else
in
the
future,
but
any
extensions
need
to
go
through
the
working
group.
The
way
it's
specified
now,
so
it's
not
like
everyone
can
just
go
and
extend
whatever
they
want.
B
Yeah
all
right:
well,
we've
got
six
response
of.
H
D
D
B
All
right,
hanji's,
next
yeah,
are
you
done
yeah?
Let
me
bring.
I
Hi
hi
max
hear
me
yeah.
Okay,
do
I
need
to
share
my
desktop
or.
B
D
Want
to,
we
can
run
the
slides
too,
but
yeah
you're
welcome
to
do
it
yourself.
D
Yeah,
it's
it's
about
to
start.
D
G
D
D
I
I
Here
we
talked
about
how
about
two
updates
about
this
draft.
First
one,
we
change
the
feature
name
from
the
feature:
itmp
proxy
to
hmp
proxy,
because
we
have
checked
some
related
young
modules
and
this
keyword
feature
always
doesn't
use
the
in
the
teacher
name.
So
we
made
this
change
next
piece.
I
I
Okay,
okay.
Similarly,
we
also
renamed
the
feature.
The
feature
node
policy
to
mld
proxy
as
similar
as
the
agmt
plus
next
piece.
I
The
second
update
we
renamed
the
leaf
version
in
the
hmt
proxy
tree
to
hmp
version,
so
because
we
think
the
this
keyword,
igmp
version
is
more
accurate
below
is
the
whole
identifier
tree
now
a
nice.
Please.
I
I
G
D
Yeah,
so
I
think
we
we
can
request
the
review
in
the
data
tracker.
D
Yeah,
okay,
yeah
yeah,
okay
yeah-
I
can
one
of
us
can
start
the
yeah
at
least
request
the
review.
B
D
All
right
and
well,
it
would
be
great
if
people
can
read
the
draft
and
see
if
they
have
any.
D
D
Let's
see,
oh,
I
should
I
need
to
stop
mine.
I
think
there
you
go
yeah.
K
B
B
B
K
K
K
So
compared
to
the
previous
version,
we
we
just
have
some
updates.
First,
we
have
some
kind
of
editorial
changes
and,
secondly,
and
mostly
we
add
some
details
about
behaviors
on
the
english
node
and
the
transient
node
next
page.
K
So
we
have
a
segment
list
for
the
sub
3
from
p1
to
p2,
p3
and
l1,
l2
and
pp4
and
l3
and
l4.
So
so
this
segment
is
because
this
is
for
multi
p2mp
pass
so
inside
this
segment
list
is
the
multicast
s
ids
for
each
of
this
node.
K
K
K
That
next
vlog
will
be
the
subject
of
the
the
root
of
the
snap
trees
and
then
use
this
use.
This
new
segment
list
for
that
subtree
and
then
the
packet
packet
at
zero
as
a
payload.
K
K
On
a
transitional,
p1
p1
will
receive
a
package
packet
package
m,
prime,
which
is
sent
from
the
english
node,
so
this
package
will
contain
as
segment
list.
So
this
second
release
we
have
destination,
which
is
a
p1
so
from
this
p1
p1
and
p1
m,
which
is
a
multicast
id.
This
modicus
id
has
information
about
how
many
branches
or
subjects
do
we
have
so
here.
The
information
indicates
that
we
have
two
branches.
K
K
K
K
Page
yeah,
I
think
that's
all
about
this
update.
So
basically
we
update
get
more
details
about
behaviors
on
the
english
node
and
the
traditional.
So
I
would
like
to
request
requests
for
adoption,
so
any
comments.
A
Here,
let's
say
c
line
of
cisco
systems.
Is
this
I'm
I
I
I
don't
know
this
for
sure,
but
is
this
the
first
time
that
this
behavior
for
this
forwarding
behaviors
being
described
for
the
sr
I
mean
for
the
point
to
multi-point
tree
sr?
Is
that
described
someplace
else.
K
I
think
in
the
first
version
in
zero
version
we
also
describe
the
phone
behaviors,
but
this
one
I
just
will
give
more
details.
L
A
This
is
yeah,
so
this
is
new.
Okay,
that's
what
I
thought.
A
J
B
Yeah
this,
the
the
pim
working
group,
has
already
adopted
a
draft
to
do
something
similar
and
it
does
create
state
in
the
network,
which
is
fine.
We
think
it's
a
good
solution
and
what
we're
presenting
here
is
just
another
solution,
specifically
for
srv6.
That
is
more
sr
like
where
you're
not
having
to
create
like
a
replication
segment
and
you're
you're,
making
it
very
similar
to
segment
routing,
at
least
we
think
so.
B
D
Yeah,
so
as
the
working
group
participant,
I
think
the
main
main
thing
I'm
wondering
about
with
this
is
basically
how
you
know:
how
efficiently
can
you
do
this?
K
Yeah,
I
think
so
because
srv6
we
have
a
lot
of
the
code
of
programming
and
then
those
you
see
those
ids
each
each
type
of
id
is
with
a
support
associated
with
a
part
of
a
code
pursuit
code,
so
don't
pursue.
The
code,
I
think,
is
a
we
have
flexibilities
to
do
to
do
the
those
kind
of
work
or
procedures
or
behaviors
we
described
in
this
document.
K
Yes,
I
think,
last
time
we
were
someone
also
request
the
maybe
the
size
of
the
those
at
least
is
big.
I
think
that
we,
I
think
there
are
some
solutions.
For
example,
we
can
use
a
sub
tree
for
each
we
even
better
segment.
This
is
too
big
and
then
we
can
split
to
into
sub
trees.
K
That's
one
one
solution,
another
solution,
because
right
now
people
working
on
comparisons
of
of
sids,
so
that
may
also
reduce
these
concerns.
G
Okay,
ian.
J
I
I'm
skeptical
even
with
the
application
of
microsit.
This
is
going
to
be
something
that
is
generally
amenable
to
being
implemented
across
a
decent
range
of
existing
hardware.
I'm
not
I'm
not
saying
it
can't
I'm
just
skeptical.
I
can't
imagine
the
the
the
manipulations
required
it's
it's
the
the
way
the
document
is
laid
out,
it's
very
abstract,
so.
B
J
List
size,
absolutely
and
and
the
operations
required
in
a
given
point
of
multicasting.
K
Yeah,
I
think,
from
my
point
of
view,
I
think,
because
those
structure
is
very
fixed,
for
example,
the
number
of
branches-
that's
a
fixed
field,
then
from
that
fixed
field
we
can
get
the
those
sub
trees.
K
You
see
the
for
example
when
trying
to
know
to
receive
a
package
and
then
the
second
second
list
we
can
access.
Those
second
releases
in
in
the
header
and
also
destination,
is
in
the
oh.
We
can
also
in
the
this
header
we
have
destination.
Those
one
will
process
for
each
of
our
hardware
can
process
those
destinations
so
in
these
destinations,
because
segment,
routing
id
six
v6
ids,
they
have
argument
argument
functions.
K
J
K
J
D
F
There
you
go
sorry
about
that.
I
was,
I
thought,
you'd
unmute
me
yeah.
I
want
to
just
second
everything.
We've
said
about
in
terms
of
you
know,
examples
of
scale
processing
the
examples.
Let
me
help,
maybe
articulate
a
bit
look
at
a
real
network,
see
what
the
distribution
scale
really
is.
Let's
take
a
look
at
what
the
transport
tax
is
in
a
real
deployment
and
see
what
we're
really
talking
about
here
in
scale,
because
I
recall
an
ietf
wow
late
90s
in
pim,
where
we're
kind
of
doing
the
same
thing.
Each
member
join.
F
We
just
add
to
the
header
its
destination
ip
address
until
the
thing
just
got
massive,
so
it
becomes
unbounded
at
some
point
right
and
this
idea
of
making
a
subtree.
If
your
header
is
too
big,
you
send
two
packets,
I
mean
we
already
are
at
a
point
where
transport
tax
is
massive.
So
again
we
can
speculate.
You
can
speculate.
We're
asking
for
examples,
show
us
what
a
real
network
would
look
like
operating
on
this,
and
we
can
see
what
the
packer
really
looks
like
and
get
an
idea
of.
K
F
K
Yeah
another
thing
that,
because
right
now
there's
a
work
going
on
in
the
spring
group,
they
propose
comparisons
of
sick
ids
sids,
so
that
also
will
re
resolve
this
complete
problem
partially.
I
think.
F
K
Yeah,
I
think
that's
the
binance
of
either
we
put
those
information
or
space
in
the
package
or
in
the
network.
I
think
that's
the
beauty
of
a
second
routine,
so
sigma
routine,
put
a
whole
path
in
the
package,
and
then
we
we
get
rid
of
the
states
in
the
network
right.
F
Well
that
that's
one
view
I
mean
we
can
argue
that
today
I
don't
think
it's
the
right
place,
but
you
can
say
you're
overloading
something
or
it's
beautiful
because
you
put
it
in
one
place,
but
there's
also
service
separation.
If
you
think
about
the
history
of
how
these
technologies
evolved
oftentimes,
they
come
out
of
the
gate
all
smashed
together
and
we
realize
how
complex
that
is,
and
we
break
it
up.
So
we
can
bound
these
problems
into
sets
and
have
them
work
in
nice
layers,
and
then
this
comes
around
again.
B
B
Exaggerates
that
the
the
list
size,
but
it's
it's
kind
of
a
philos
philosophical
discussion,
about
segment
routing
in
general.
It's
kind
of
what
you're
saying
yes
exactly,
but
your
points
taken
and
we'll
we'll
we'll
do
our
best
to
include
some
of
that
information
in
the
draft.
D
Yeah
another
thing
that
I've
been
wondering
about
is
mtu
size
and
it
would
be
good
to
know
basically
how
much,
how
much
space
do
you
need
to
store
this?
I
guess
I
can
figure
it
out
from
the
draft,
but
it'd
be
nice
to
have
some
examples.
G
D
D
Yeah,
this
is
pretty
nice
compared
to
the
humming
that
we
actually
can
see
the
numbers,
I
think
so
yeah
right
now
we
have
four.
We
have
out
of
20.
We
have
four
people
raising
their
hand
and
seven
people
not
raising
their
hand.
Basically
for
again,
four
four
people
think
we
should
adopt
it
now
and
and
eight
people.
I
think
we
should
not
adopt
it
at
this
moment
so
yeah.
I
think
we
we
should
take
it
to
the
list.
D
So
basically
it
would
be
nice
to
get
and
a
new
version
that
addresses
some
of
the
comments
we
got
already,
maybe
with
some
examples
and
also
get
some
discussion
on
on
on
the
list
about
this.
We
should
not
wait
until
the
next
meeting.
We
need
to
get
some
activity
on
the
on
the
mailing
list.
D
So
yeah
great
great,
if
the
authors
can
send
an
email
to
the
list
and
start
some
discussion.
D
D
Okay,
so
let's
look
at
the
agenda
again,
so
yeah
so
ramki
was
supposed
to
present
already
start
packing,
but
he
has
tried
the
multiple
laptops
now
and
it
basically
just
gets
the
blue
screen
when
it
echo
is
supposed
to
pop
up.
I
don't
know
if
that's
a
known
problem,
so
I
think
I'll
I'll
present
it
for
him.
D
D
D
Yeah
all
right
yeah,
so
we
requested
publication.
Oh
this
draft
a
couple
of
months
back,
I
think,
and
and
our
ad
reviewed
the
draft
and
found
several
issues
with
it.
Several
those
we
should
have.
We
should
have
found
them
in
the
working
group
as
our
as
part
of
our
review.
So
we
need
to
do
better
at
that,
both
as
a
working
group
and
also
chairs
and
shepherds.
D
Yeah
yeah
by
the
way,
yeah
alvaro.
If
you
are
here,
I
have
any
comments.
Please
yeah,
let
me
know,
but
yeah
we
need
to
do
better.
We
also
had
the
dr
improvement
draft.
That
was
not
good
enough,
so
yeah
all
right.
So
for
this
draft
it
was
returned
to
the
working
group
and
since
then
the
the
author
has
has
has
worked
hard
and
posted
a
new
version,
and
I
also
provided
some
review
comments
on
the
previous
version.
D
So
hopefully
it's
in
a
better
shape
this
time,
so
version
6
should
hopefully
address
the
80
comments
and
concerns,
so
the
changes
were
mostly
editorial.
D
D
So
I
think
the
document
is
in
much
better
shape
now,
but
we
yeah.
If
you
need
someone
some
review
and
we
need
to
decide,
do
we
need
to
do
another
working
group
last
call
or
or
what
do
we
do
any
thoughts
on
that
mic
or
anyone
has
any
comments.
B
D
D
D
E
You
can
hear
me
right:
yeah
yeah,
so
I'm
not
volunteering
to
read
the
draft.
E
But
yes,
I
want
you
to
last
call
it
and
I
want
to
see
actual
discussion.
That
was
one
of
the
things
that
I
didn't
see
last
time
and
you
know
there
were
a
lot
of
issues,
including
things
as
you
mentioned,
that
should
have
been
caught
like
no
security,
considered
considerations
section
in
the
draft
at
all
and
a
bunch
of
other
stuff.
So
yes,
you
know.
If
we're
going
to,
you
know,
push
things
through
the
working
group.
E
We
need
the
working
group
to
look
at
them
right,
yeah,
but
so
before,
just
really
quick.
So
if
you
have
noticed
there
are
some
issues
with
the
chat
in
miraco,
so
I
was
told
that
we're
going
to
reboot
the
vm,
maybe
in
a
minute
or
so
so
I'm
not
sure
we're
going
to
actually
lose
the
whole
thing
or
just
the
jabber
chat.
E
So
just
so,
you
know
right
if
we
go
away
come
back
in
a
minute
or
two,
maybe.
E
Yeah,
I'm
still
here,
I
didn't
have
anything
else
to
say
just
to
give
you
a
heads
up
that.
D
Yeah
yeah,
so
we
really
need
more
more
review
and
we
can
do
a
working
room
plus
call,
but
we
need
to
make
sure
that
some
people
actually
respond
to
that
and
read
the
document.
So
it'd
be
really
great.
If
we
could
find
some
volunteers
to
to
review
the
documents,
is
anyone
here
willing
to
to
review
it.
D
I
J
D
D
D
One
okay,
so
I
guess
we
have
to
take
it
to
the
list.
Okay,
we
have
a
yeah.
C
Learning
volunteer
I'll
give
it
a
shot
awesome
review.
D
I
appreciate
that
so
yeah,
so
I
think
we'll
maybe
wait
for
the
two
of
you
to
review
it
first
in
case
you
have
substantial
comments
and
then
we'll
do
a
working
group
last
call
once
you
have
done
that
and
either
we
have
addressed
the
issues
you
find
or
if
there's
no
major
issues
we
can
do.
The
last
call
before
we
revise
the
draft.
D
But
yeah
I
would
say
in
general,
we
struggle
to
get
enough
people
to
review
documents
and
we
may
have
to
basically
not
not
publish
documents
if
you
don't
get
enough
reviewers
and
if,
if
a
document
is
useful
and
and
and
people,
think
it's
good
then
worth
doing,
then,
hopefully
there
will
be
some
people
willing
to
review
it
as
well.
D
But
yeah,
I
really
appreciate
getting
these
two
people
to
review
this
document
this
time.
So
that's
great.
D
All
right,
I
think
we
can
move
on
to
the
last
presentation,
then
mike
right.
B
F
B
B
So
this
was
presented
an
hour
and
a
half
ago
in
embondi
for
many
of
you
that
were
there
you'll.
This
will
be
a
bit
of
a
repeat
I'll,
try
to
quickly
go
through
it,
but
this
is
a
draft
that
we
have
presented
in
both
mbo
and
d
and
pim
in
the
past
about
a
year
or
so
ago.
I
think
it's
a
draft
that
we've
been
pursuing
in
ippm
working
group,
ip
performance
measurement
working
group
and
it
being
that
it's
multicast,
specific
and
oem
specific.
B
It's
had
a
hard
time
getting
any
traction
in
ippm,
ippm
working
group,
and
we,
as
I
mentioned
previously,
it's
something
that
we
discussed
with
warren
and
we
tried
to
get
some
advice
from
him
and
and
this
these
kind
of
drafts
do
have
a
hard
time.
So
we
we
could
either
have
it
addressed
in
the
ops
area,
working
group,
mbondi
or
pym.
B
B
If
we're
to
do
this,
but
I
would
suspect
that
they
would
be
happy
to
have
it
done
somewhere
else.
So
the
background
is
that
multicast
traffic
monitoring
is
important.
B
The
I
om
draft
is
something
that
has
been
it's
nearing
the
end
of
its
getting
through
the
standards
process
in
that
working
group.
There's
some
other
ones
that
have
not
been
adopted
in
the
working
group,
yet
that
are
being
worked
on,
but
they
all
have
to
do
with
adding
telemetry
data.
In
the
packet
itself,
in
band,
so
in
suto,
oem
in
ban
iom
in
band
oam
is
being
is
worked
on
and
so
there's
some
problems
with
those
techniques.
However,
they
do
have
some
flaws
for
multicast
with
inbound
oem.
B
Every
packet
can
tears,
it
contains,
carries
the
entire
trace
data,
the
entire
point
of
multi-point
data
trace,
and
so
there's
a
lot
of
data
redundancy,
because,
when
you're
collecting
that
data
capturing
and
collecting
it
sending
it
to
where
you
want
to
analyze
that
data,
it's
just
a
lot
of
redundant
data,
and
so
I
think
we
can
do
better
and
then
there's
some
other
solutions
like
postcard
based
trees
that
make
it
so
that
there's
not
as
much
redundant
data
but
there's
no
branch
identifier,
and
so
we
propose
a
way
that
you
can
add
a
branch
identifier
to
build
to
properly
recreate
the
trees
and
correlate
those
postcards.
B
B
B
A
postcard
is
add
a
branch
node
that
sends
a
postcard
to
the
the
collector
of
the
telemetry
data
of
the
status
of
the
the
packet
at
that
point,
and
so
we
add
a
branch
identifier
in
this
draft
to
the
instruction
header
to
be
able
to
help
reconstruct
a
tree,
because
that's
something
that
is
not
able
to
be
done
right
now
with
existing
solutions.
B
You
can
have
these
postcard
based
solutions,
but
there's
not
a
way
to
properly
reconstruct
a
tree
when
you're
looking
at
this
telemetry
data,
and
so
this
is
something
that
we're
proposing
to
be
added
to
it
and
then
there's
another
way
that
using
per
section
postcard,
where
you've
got
the
data
for
a
particular
section
that
is
collected
and
then
correlated
and
we're
able
to.
B
Make
a
similar
adjustment
to
the
packet
to
build
to
provide
that
at
the
branch
node
as
well,
and
so.
B
Again,
what
we're
trying
to
accomplish
is
being
able
to
make
telemetry
data
efficient
for
multicast,
and
we
naturally
just
repeat
myself,
naturally
something
that
we
would
want
to
be
doing
in
ippbm,
because
that's
where
this
telemetry
data
is
being
worked
on,
but
being
that
it's
not
exciting,
there's
not
the
expertise
with
multicast,
as
I
explained
before,
it's
similar
to
what
we've
done
in
the
spring
working
group,
where
we've
taken
the
point
to
multi-point
drafts
and
we
are
working
on
them
in
pim
at
least
one
of
them
right
now
and
the
spring
chairs
were
happy
to
have
us.
B
Do
so,
and
it's
a
similar
situation.
We
think
with
multicast
telemetry
data
and
so
we're
proposing
to
either
have
a
problem
statement
draft
in
mbd
and
then
have
protocol
modifications
done
in
pim
or
just
have
it
all
be
done
in
pim
and
just
keep
it
as
one
draft
as
we
have
right
now.
B
So
first,
are
there
any
questions
and
then
second
we,
my
final
request,
would
be
to
you
just
to
pull
the
working
group
to
see.
If
this
is
something
that
we
think
that
needs
to
that
should
be
done
here
and
if
it
is,
then
we
will
I'll
need
to
have
you
stig
king,
the
ippm
chairs
kind
of
like
we
did
with
spring
and
then
ask
them
if
they're,
okay.
G
Yeah
yeah,
let's
see
lenny,
has
some
comments.
C
Yeah
mike
so
it
went
by
quickly
in
mbondi,
so
I
didn't
get
a
chance
to
ask,
but
so
what?
What
exactly
was
the
experience
so
you've
taken
this
first
to
ippm
and
they
were
not
interested
or
zero.
B
Yeah
yeah
great
question,
so
we've
had
we've
sent
a
couple
emails
and
we've
had
zero
response,
and
so
just
nothing,
it's
a
very
busy
working
group,
and
so
they
they're
busy
working
on
things
that
they're
interested
in
and
they
just
don't
have
interest
in
in
this
type
of
multicast
oem
and
we,
but
we
didn't,
we
received
zero
response,
we
did
privately
email,
frank
brockner's,
who's,
leading
the
iom
data
draft
and
he
gave
us
some
advice,
and
so
we
kind
of
modified
it
further.
B
We
paint
the
chairs
of
ippm
and
they
said
yeah,
you
know,
keep
you
know
you
feel
free
to
keep
trying.
Basically,
and
so
it's
a
it
it's
you
know
this,
isn't
the
only
draft
that
I've
had
that
over
the
years
of
working,
the
itf
you
have
to
rally
interest
at
times,
but
particularly
for
multicast.
As
you
know,
it's
just
some
people,
just
don't
care
or
don't
know
about
multicast
enough
to
want
to
do
anything
about
it.
C
So
so
you
wouldn't
anticipate
them
taking
umbrage
with
it
being
the
work
being
done
elsewhere.
No.
B
C
D
Right
yeah,
so
one,
I
guess
one
question
is
whether
it's
in
a
charger
or
not,
but
I
think
I
would
have
to
double
check,
but
I
think
it
should
be
in
the
charger
because
it
is
multicast
protocols
at
least
I
would
think
away
that
way,
but
you
would
definitely
have
to
check
with
the
chairs
and
ads
I
guess
about
where
this
work
should
be
done,
but
but
yeah
we
should
find
out
first,
if
there's
interest
in
doing
this
and.
D
So
should
I
just
ask
the
question
or
yeah:
please.
D
Yeah,
let's
see
so
we're
not
talking
about
the
specific
draft
now,
but
basically
huge
future
drafts
right.
B
C
K
D
D
D
D
G
D
Yeah,
well
I
mean
we
can
say
already
that
at
least
there
are
several
people
that
think
they
should
do
this
kind
of
work.
So
that's
that's
good!
That's
like
a
quarter
of
the
people
on
on
the
yeah
that
are
on
here.
So.
D
Okay,
let's,
let's
go
back
to
the
queue
yeah.
Let's
see,
I
can
leave
this
running.
I
guess,
while
we
do
that,
all
right,
I'm
not
sure
who
was
first.
I
guess
lenny
is
first
looks
like.
C
Yeah,
so
without
having
I,
I
didn't,
do
the
homework
and
haven't
read
this
it
is.
Is
it
making
changes
to
the
protocol
of
pim
it's
adding
branch
ids?
What
what?
What
is
the
what's
it
actually
doing
to
the
protocol,
then
so.
B
To
allow
for
efficient
multicast
tree
reconstruction,
so
so
it's
the
the
changes
would
be,
for
instance,
to
there's
a
couple
protocols
that
are
telemetry
specific
protocols
like
there's
postcard
based
trees.
This
hybrid
two-step
greg
mursky
wrote
that
draft
he's
involved
with
multicast
as
well
as
ippm
related
stuff.
There's
an
iom
draft
that
I
mentioned
there'd
be
a
modification
to
that
draft
as
well.
So
we're
only
talking
about
telemetry
data
here
and
modifying
those
protocols
unrelated
to
multicast
writing
protocols
to
allow
for
efficient
collection
of
multicast
data.
J
C
Almost
yeah,
I
would
almost
think
that
that
you
know
without
it's
in
the
middle
of
the
night,
and
I
haven't
really
thought
through
it
that
much,
but
I'm
thinking
you
know
this.
This
would
seem
more
embownish
embondish
than
than
pim,
because
pim
is
usually
just
you
know,
changes
to
the
actual
multicast,
routing
and
group
membership
protocols,
whereas
him,
whereas
mbondi,
is
more
focused
on
troubleshooting
and
operational
and
you
know
maintenance.
So
I
think
it
might
be
a
better
fit
there.
D
B
E
Yeah,
I
sort
of
agree
with
lenny
there
on
you
know,
sort
of
the
division
there
of
labor
and
you're.
Looking
at
the
charters,
yeah
mbondi
specifically
talks
about
extending
protocols
to
provide
tools
and
stuff
like
that,
so
that
may
work
there.
I
I
think
that
you're
still
very
premature
to
talk
about
adoption
or
actually
doing
the
work
anywhere
without
knowing
exactly
what
the
work
is,
and
maybe
others
actually
wrote.
E
The
draft
I
haven't,
but
I
think
you
know
that's
that's
an
important
step
and,
as
you
said
already
before,
you
know
talk
to
the
ippm
guys
to
make
sure
they're.
Okay,
lack
of
interest
is
not
the
same
for
a
working
group.
I
mean
we're
used
to.
Unfortunately,
in
pim
I
mean
we
have.
People
are
interested
in
multicast,
but
there's
not
a
lot
of
excitement
a
lot
of
the
time
we
get
two
and
three
people
and
we're
really
happy
about
something,
so
that
doesn't
always
translate
to
the
same
thing
in
other
working
groups.
E
E
If
it
is
just
that
you
know
they
don't
understand,
multicast,
you
know
whatever
or
if
they
think
it
means
something
else.
It
probably
just
means
that
they
don't.
You
know
they
were
just
too
excited
and
that's
it.
Nothing
necessarily
bad,
but
it'll
be
a
good
question
to
ask
them
and
just
one
more
announcement.
I
said
before
that
we
were
going
to
reboot
the
whole
mid-echo
thing
for
some
miracle.
Our
session
didn't
stop,
but
the
chat
is
back.
If
you
want
to
go
back
to
the
chat
you
can,
but
you
need
to
reload
the
page.
E
So
that's
it.
We're
probably
almost
done
anyways,
but
if
you
want
to
go
chat
with
someone
thanks.
B
Yeah,
thank
you
very
much.
Just
to
conclude
that
comment,
then,
is:
I
think
what
I'll
do
stig
and
lenny
is
as
an
individual
contributor,
since
I'm
aware
of
what's
going
on
here
is,
I
think
I
will
email
the
ippm
chairs
copy
you
and
then
just
tell
them
what
we're,
considering
that
we're
evaluating
this
potentially
being
work
done
in
these
working
groups
and
wanted
to
get
their
feedback.
D
Okay,
I
guess
either
way,
though,
even
if
they
are
interested,
it's
probably
good
to
have
some
draft,
maybe
an
mbondy
talking
about
the
the
need
for
this
right
and
how
it
could
be
used.
B
I
think
so
I
think
a
general
telemetry
draft
and
either
way
I
I
think,
you're
absolutely
right
either
way.
I
think
a
telemetry
multicast
telemetry
draft
needs
to
be
done
in
mbod.
I
think
you're
right.
D
Yeah,
thanks
all
see
you
in
well
see
you
online
all
right
thanks.