►
From YouTube: IETF102-PIM-20180717-1550
Description
PIM meeting session at IETF102
2018/07/17 1550
https://datatracker.ietf.org/meeting/102/proceedings/
B
A
C
C
C
E
This
is
Carol
Barnardo's
Kosar
of
the
draft
I've
been
discussing
with
the
court,
especially
with
wish
from
telephonic,
and
basically
we
will
provide
the
our
aim
is
to
submit
a
version
this
week.
So
maybe
we
can
also
take
some
break
to
discuss
with
our
the
the
changes
that
we
provided
through.
That's
our
goal:
yeah.
C
E
C
The
mailing
list,
we
also
have
an
IEP
MLD
young
model
that
is
waiting
for
the
ad
to
look
at,
but
hopefully
is
G
will
be
happy
with
it
and
move
forward
shortly,
and
then
we
have
explicit
tracking,
which
has
been
stuck
for
a
while
I
know
the
the
author's
is
getting
smaller
people
involved
and
looks
like
them:
they'll
move
forward.
Yeah.
Sorry,
oh.
F
Yes,
well.
F
It's
a
little
bit
complex,
so
the
requirement
for
MIDI,
as
you
know,
is
that
we
need
the
Tiffany
tree.
I
included
some
statement
about
implementation
experiences
given
by
operators
and
because
this
is
a
that
intended
status
is
experimental
treatment.
F
So
lack
of
such
kind
of
information,
so
Eddie's
I
cannot
move
as
I
expressed
it
out
of
C.
So
now
we
have
been
thinking
about
changing
of
the
intended
status,
the
informational,
but
this
is
also
there
are
several
concerns
given
by
and
let's
say,
Torres,
but
here,
because
in
a
last-minute
meeting
expressed
tracking
is
even
though
there
is
no
wire
changes.
It's
really
important
as
a
part
of
our
gem
people
comm
people
to
so
that
this
kind
of
functionality
must
be
must
not
be
maybe
informational.
F
So
this
is
something
like
his
opinion,
and
this
was
something
like
a
consensus
of
the
his
previous
meetings.
So
so,
this
is
something
like
a
listen
that
why
it's
a
little
bit
stacked
and
there
oh
well,
so
the
possibility
to
make
it
move
Ward
is
that,
as
you
said,
we
definitely
need
to
get
some
input
from
vendors
or
operators
to
become
a
good
guideline
of
dysfunctionality.
F
So
please
lead
the
document
and
if
your
vendor
were
operated,
who
has
the
implementation,
experiences
or
operational
experience?
We
are
really
happy
to
get
such
kind
of
information,
and
we
can
summarize
these
information
than
the
describes
the
summary
into
this
document
and
continuously
work
on
as
a
experimental
documentation.
F
F
A
C
All
right,
you
also
have
a
dr
load-balancing
craft,
so
it's
long
story
about
that,
but
a
lot
of
presentation
about
that
in
this
meeting
you
also
have
the
our
improvement.
There's
no
update.
This
meeting
need
people
to
review
the
draft
and
comment
on
it.
This
also
some
related
draft
that
will
be
presented
in
this
meeting.
We'll
come
back
to
that
later
for
MSTP
young.
We
had
an
the
other
working
group
last
call
and
no
one
responded.
I.
C
Did
a
review
after
that,
I
should
have
done
it
for
the
last
call
myself,
but
it
after
and
your
first
I
revised
the
document,
and
it's
probably
you
know
good
idea
to
do.
A
new
working
group
last
call
I'm
hoping
says
people
file
was
ready
for
last
call
the
last
time.
People
are
still
thinking
it's
ready
for
last
call
now.
C
C
Okay,
we
also
have
a
young
model
for
IGMP
Emily
snooping.
We
have
a
presentation
for
that
this
meeting
as
well.
That
should
be
close
to
completion
and
there's
a
graph
on
IQ
up
here
for
prefix
or
ipv6
next
top
that
also
be
presented
this
meeting,
so
that's
Estella.
So
all
the
current
working
with
documents,
any
questions
before
we
move
on
to
their
presentations.
H
H
H
I
H
Just
ii,
mainly
update,
is
that
we
had
a
example
of
the
dead
tree,
followed
by
the
adjacent
encoding,
for
example.
This
is
the
igmp
snooping
instance.
H
C
H
Yet
the
conductor
have
reviewed
that,
but
we
we
we
we
we
wanted
to
in
the
young
dar
meeting
and
it
cast
and
respond
to
the
to
the
doctor,
and
then
we
think
we
can.
We
can
start
to
the
last
of
course,
so
you
think
it'll
be
just
small.
C
Okay,
no
because,
based
on
the
review,
it
looks
to
me
like
maybe
you
know,
there
are
not
some
bigger
changes
but
yeah.
If
you
don't
need
to
do
that
them
and
that's
fine
yeah,
so
I
guess
it
should
ask
the
room,
maybe
so
yeah
how
many
people
have
read
this
draft,
the
see
about
five,
six
people,
six
people
on
me.
C
A
A
C
H
The
secondary
will
introduce
the
a
champion
Amer
de
armado
from
the
last
IGF.
We
have
made
some
updating
from
the
comments
and
the
80
and
the
chairs
comments.
Firstly,
we
update,
according
to
the
ITF
Mian
model,
rc7
six
or
eight
seven
bits,
mainly
the
part
of
the
security
considerations
and
the
reference,
the
information
and
the
understate
the
same
as
the
item.
Please
new
Pina
motto:
we
also
updated
the
range
of
the
robust
from
2
to
7
to
1
to
7.
C
C
Right
so,
if
I
remember
correctly
for
for
this
craft,
the
requested
publication,
but
then
the
young
doctor
had
some
comments
and
and
I
think
we
were
waiting
for
you
to
review
that
before
our
ad.
Would
you
know
review
the
document
further,
so
I'll
go
and
check,
but
yeah
I
believe
that
the
next
step
now
will
be
that
Alvaro
probably
will
review
the
drunk
and
determine
you
know
if
it's
ready
for
I,
but
for
the
sleeping
one
we
need
to
do.
C
I
J
K
L
So
this
is
small
update
for
the
dog,
DRL
load-balancing,
so
basically
I
think
it
got
adopted
as
a
working
group
in
IETF
82,
and
there
was
a
big
pause
in
between
and
finally
IETF
99
I
did
present
it
in
Singapore
and
IETF
100.
We
had
some
comment
from
Jack,
Holland
and
I
did
a
braid.
The
document
and
just
close
back
I
think
he
has
sent
me
some
more
comment.
But
after
addressing
his
comment,
I
think
it
is
ready
for
working
group
last
call
until
unless
there
is
any
other
comment.
A
E
A
A
A
Just
gonna
small
more
one
last
time,
because
we're
kind
of
done
with
this
job
but
I
don't
want
to
force
it.
So
is
anybody
in
this
room
feel
that
this
draft
is
ready
for
work
group
last
call
so
I
don't
see
any
hands?
Do
you
believe
it
is?
Okay,
I
got
a
hand
all
right.
We
got
alright,
so
we
will.
We
will
need
to
take
this
to
the
list.
If
we
can
get
a
couple
of
responses,
then
we'll
move
it
along
because
there's
no
fans
against
okay.
It's
just
there's
not
a
whole
lot
of
interest.
L
So
the
next
topic
to
discuss
so
I
think
we
already
have.
There
is
a
draft
which
is
MDR
improvement
and
it
talks
about
backup,
TR
mechanism,
and
so
I
am
just
trying
to
capture
once
again
here
that
what
what
is
the
problem?
The
other
draft
is
solving.
So
if
you
see
here,
we
have
a
receiver
at
the
end,
and
there
are
two
paths
to
source:
I
have
kept
it
very
simple
and
the
left
side,
the
r8
and
r9.
L
They
are
PIM
routers
on
the
land
and
r8
is
a
pim,
dr
right
now
and
all
the
pin
joints
are
going
from
r8
r,
6
r3
towards
source,
and
we
have
data
traffic
flowing
and
what
will
happen
if
there
is
a
failure
here?
So
if
there
is
a
failure,
basically
receiver
is
going
to
get
the
traffic
loss
here
and
it's
not
only
about
the
traffic
loss.
What
will
be
the
next
step?
So
basically,
now
r9
becomes
the
new
pim,
dr
and
our
line
has
to
build
the
whole
tree
again
to
receive
the
traffic
from
source.
L
So
it
sends
him
join
hop
by
hop.
Then
we
start
getting
the
traffic
and
that's
how
this
evil
starts
getting
the
traffic.
But
in
this
case,
so
there
are
certain
application,
for
example,
surveillance
camera
if
they
are
using
multicast
and
if
there
is
a
big
pause
of
3
seconds
or
whatever
time.
So
there
are
security
concerns
and
there
could
be
some
important
traffic
which
you
don't
want
to
lose.
L
So
in
this
we
are
saying
so
even
the
pim
dr
improvement
drops
talked
about
having
backup,
dr
so
in
case
of
backup,
dr.
What
exactly
we
are
doing.
R8
here
is
a
dr
+.
R9
is
backup.
They
are
both
of
them.
They
will
build
the
multi
street
towards
source.
Both
of
them
will
pull
the
traffic,
but
our
line
will
keep
dropping
it
because
it
is
in
the
backup
mode
and
r8
will
keep
following
the
traffic.
What
will
happen
now?
If
our
it
goes?
The
link
between
r8
and
receiver
goes
down.
L
In
that
case,
our
line
already
has
all
the
traffic.
It's
only
matter
of
the
time
when
it
can
detect
and
if
you
are
using
BFD
or
any
other
mechanism
to
detect
it
fast.
Our
line
can
immediately
detect
and
it
can
start
forwarding
the
traffic.
So
it
doesn't
need
to
wait
for
the
wait
for
the
new
tree
to
get
set
up.
L
So
now
the
only
what
is
the
difference
here
so
basically
the
major
difference
which
we
are,
which
I
am
proposing
here.
The
draft
Tim
Dr
improvement
talks
about
having
new
hello
option
to
have
backup
dr
election,
but
I
think
that
we
don't
need
new
opened
new
hello
option.
We
can
still
do
it
with
exact
existing
hello
option,
and
I
just
wanted
to
take
it
to
working
group
here
to
have
kind
of
discussion
and
maybe
have
analysis
that
can
we,
which
one
will
be
the
better
to
go
with,
are
both
up.
L
L
Okay,
so
in
this
I
think
it
will
be
easy
with
figure.
What
exactly?
I
am
saying
that
if
you
see
now
our
rate
and
our
line,
both
are
tim
routers
when
they
see
each
other's
hello,
what
exactly
they
are
going
to
do?
They
are
going
to
run
the
same
algorithm
of
Pym,
dr
election
and
the
first.
Whoever
is
the
best
router
will
become
the
pim,
dr,
the
second
best
router
becomes
pim
beadier
by
default,
and
when
you
are
in
the
b,
dr
mode,
you
still
send
the
PIM
join.
You
do
everything.
Whatever
tim,
dr
does.
L
Only
only
thing
is
that
you
have
to
be
in
block
state
you.
You
should
not
be
following
the
data
traffic
towards
the
last
off,
and
there
were
few
cases,
I
think
I
would
say
more
of
corner
cases
which
need
to
be
handled
that
what
will
happen
if
nuke
MDR
comes
from
the
network,
so
the
main
concern
was
that,
if,
if
it
sends
its
priority
right
away,
it
might
happen
that
the
other
router,
basically
other
router,
will
give
up
its
role
and
we
will
still
see
the
traffic
loss.
So
for
that
we
had
that.
What?
L
If
you
don't
send
your
actual
priority
right
away,
you
send
your
priority
as
a
zero,
and
you
wait
for
one
hello
interval
to
learn
about
all
of
your
neighbors.
So
after
one
hello
interval,
basically,
you
will
have
full
knowledge
of
other
PIM
routers
in
the
network
and
there
dr
priority
and
once
you
know
their
priority,
you
will
be
able
to
calculate
whether
you
are
eligible
to
be
dr.
If
you
are
eligible
to
be
dr,
you
start
building
the
tree
and
still
don't
give
your
configured
priority.
L
Basically,
you
start
sending
your
original
priority
and
you
take
over
as
a
dr,
but
if
new
team
router,
which
is
coming
up,
is
not
a,
it
cannot
be
a
dr,
so
it
will
be.
It
will
know
within
a
one
hello
cycle
that
I
am
not
eligible
to
be
p.m.
dr
anyway,
so
it
doesn't
need
to
do
anything
and
definitely
it
can
send
its
own
configured
priority,
and
there
were
some
concerns
about
the
initial
start
up
case
when
there
are,
let's
say
five
routers
coming
up
together
and
if
everyone
sends
zero.
L
Basically,
it
will
be
kind
of
more
of
everyone
is
in
waiting
on
everyone
else.
So
in
this
case,
I
think
it
is
one
of
the
definitely
Cardinal
case
that
when
all
five
routers
are
coming
up
together
and
if
we
have
to
hello
interval
traffic
laws,
I
don't
think
it
is
a
big
deal,
because,
anyway,
your
network
is
coming
up
fresh.
So
we
can
live
with
one
minute
traffic
loss.
G
Yeah,
so
it
this
strikes,
me
is
a
really
narrow
case
that
you're
really
just
solving
a
really
small
part
for
a
very
narrow
case,
so
you
still
have
the
failure.
Detection
with
or
without
this
mechanism
you
have
to
find
out
the
the
the
dr
dies.
So
you
have
that
it
takes
time
for
the
so
with
or
without
this
you
have
that
all
you're
doing
is
you're
eliminating
join
latency
on
one
path.
G
Yes,
now
and
and
you're
only
doing
this
for
one
router
meaning
what
if
r6
fails
like
what,
if
the
link
between
r8
and
r6
fails,
then
what
right,
then,
you
have
to
have
r8
convert.
You
have
the
same
exact
problem,
so
all
you're
solving
is
join
latency
for
one
hop
in
a
many.
You
know
where
any
other.
These
hops
could
also
fail,
and
this
doesn't
solve
it.
So
there's
a
thing
like
there's:
MOF:
are
that
kind
of
solves
those
problems?
So
essentially
what
this
is
is.
L
So
to
answer
your
question:
basically,
if
you
I
think
maybe
it
was
not
clear
the
problem
statement
of
this
document,
it
is
the
exact
same
problem
statement.
What
one
of
the
working
group
document
is
solving,
so
problem
statement
is
same.
Only
thing
is
I
am
trying
to
simplify
the
solution
rather
than
having
dr
and
backup
dr
using
new
hellos.
Can
we
do
it
with
existing
hello?
So
this
this
document
doesn't
solve
any
problem
apart.
G
And
then
the
other
thing
is:
do
we
even
need
to
specify
this
with
an
IETF
document,
because
this?
What
stops
an
implementation
from
just
doing
this
anyway?
That
this
seems
like
an
implementation
thing
that
you
could
do
just
have
a
backup
designated
router,
send,
joins
and
sit
and
hold
hold
that
traffic
don't
forward
or
on
the
land,
and
you
know
send
it
send
it
out.
L
N
So
I
see
a
little
bit
of
issues
on
this
diagram
like
there
is,
you
know
in
normal
production
environment,
there
is
always
a
link
between
r8
and
r9,
like
using
of
the
error
or
something.
So
it's
not
a
three
in
three
second
or
four
seconds
outages
like
a
sub
second
outage,
so
there's
no
real
problem
to
be
solved
on
a
service
for
decide.
Network.
N
We
are
seeing
a
big
issue
like
if
you
gonna
start
sending
another
traffic
on
another
path,
which
can
be
a
huge
like
versa
for
a
security
company
or
a
monitoring,
it's
a
very
small
amount
of
traffic,
but
think
about
the
video
traffic
on
a
video
path
phone
way.
We
are
running
of
4k
videos.
You
see
it
can
be
like
a
tans
of
gigs
of
traffic.
That
really
you
don't
really
necessarily
need
for
a
sub
second
outage,
once
at
least
these
scenarios
goes
into
implementation.
L
To
answer
your
question:
basically,
even
if
it
is
in
the
protocol,
it
won't
be
like
it
is
must-have.
It
is
definitely
a
need
basis,
so
it's
kind
of
trade-off.
So
there
are.
There
are
a
couple
of
customers
who
really
who
don't
care,
even
if
you
bring
three
copy
of
the
traffic
in
the
core,
but
they
need
faster
convergence.
So
definitely
it
is
nothing.
Nothing
stops
that
you
can
still
go
with
the
existing
MDR
model,
but
this
is
the
method.
This
could
be
one
of
the
method.
N
Like
one
more
thing,
we
solve
this
like
the
first
commenter
who,
even
in
commentaries,
can
be
alternative
methods.
So
we
saw
this
matter
today
by
sending
out
clockwise
and
anti-clockwise
coffee
like
using
other
methods.
So
there
is
already
a
two
two
copies
coming
to
the
receiver
side,
but
not
necessarily
doing
this
method.
Sure.
G
I'm
sorry
I
wasn't
paying
attention
closely
enough
when
the
first
draft
came
along,
so
I
I
I'd
have
to
read
that
one.
So
that's
on
me,
but
if,
if
that
draft
says
the
same
thing,
I
would
say
the
same
thing
about
that
that
this
is.
This
seems
like
a
really
really
small
optimization
for
only
for
a
one
failure
in
a
really
long
tree.
Yeah.
C
G
Vote
is
none
but
without
looking
at
the
other
one,
but
if
we
are
to
do
it,
I
think
it
should
be
something
that
doesn't
require
any
changes
to
the
protocol,
because,
like
it
shouldn't
change
any
hello,
it
should
just
work
with
the
way
it
works
and
and
an
informational
like
he
said,
if
anything
make
it
informational,
but
make
it
something
that
you
know
these
to
see.
This
feels
like
more
of
a
an
implementation,
optimization.
N
Is
that
you
know
in
a
normal
production
environment
they,
as
I,
said
the
you,
you
should
have
a
link
between
our
it
and
our
my
in
this
diagram.
You
are
assuming
that
the
past
path
for
the
r9
is
on
the
other
side,
but
it
may
or
may
not
be
true
what
what
about
if
the
art
is
best
path,
is
also
to
through
the
r8
wait,
and
in
that
case,
if
you're
re,
it
goes
down
your
router,
it
still
remains
the
same.
Regardless.
You
have
a
dr
and
a
PDR.
You.
N
L
Dr
and
again,
this
document
is
being
presented
first
time
and
we
want
to
have
more
kind
of
discussion
and
feedback
to
see
that
how
useful
this
could
be
in
real
network,
and
so
today
what
happens
when
if
Tim
dia
is
going
down,
so
it's
it
could
be
because
of
maintenance.
It's
going
down
and
new
pim
dr
is
taking
over.
This
is
one
case
second
case
could
be,
which
I
have
not
specified
here.
L
L
So,
in
summary,
what
exactly
we
are
trying
to
do
is
trying
to
see
trying
to
solve
it
using
our
hellos.
So
whoever
is
the
current
PIM
dr?
It
can
send
team
hello
with
priority
zero
and
it
will
have
new
option
of
saying
that
hey,
I
am
going
in
the
maintenance
mode
and
it
could
be
graceful
shutdown
or
any
any
info
in
that
option,
and
current
MDR
will
also
make
its
assert
matric
to
infinity
and
why
we
need
it.
I
think
it
will
come
into
the
next
slide.
L
So,
if
you
see
in
this
case,
we
have
four
pim
routers
and
I
have
specified
their
priority
and
right
now,
the
rightmost
router
is
the
tim,
dr
who
is
following
the
traffic-
and
I
am
not
showing
the
core
this
here-
to
make
this
figure
simple
and
the
router
with
priority
110.
It
wants
to
go
down
for
maintenance,
so
now
what
exactly
it
can
do.
L
So,
basically,
it
will
send
a
new
hello
and
with
priority
0
and
with
new
option
as
a
gr,
and
once
this
hello
is
received
by
each
of
the
neighbor,
they
will
process
and
they
will
do
d
re-election
and
now
between
two
routers
who
have
same
dr
priority.
The
router
and
the
leftmost
becomes
the
dr
and
it
will
start
building
the
tree
and
it
will
start
forwarding
multicast
multicast
data
traffic.
L
And
what
will
happen
if
some
of
the
router
don't
support
this
specification
in
the
network,
and
so
there
are
two
case:
if
the
router
who
doesn't
support
this
specification
is
to
be
PMD,
are
then
exact
same
step
should
be
followed,
and
if
the
router,
who
doesn't
support
this
specification,
cannot
be
a
pim
dr,
it
doesn't
need
to
worry,
because
there
is
a
there
is.
No,
there
is
a
there
is
no
change
needed
and
the
other
option
other
way.
L
G
F
L
Needed
wire,
they
needed
know
so
do
so.
That
is
the
one
option
to
basically
detect,
because
if
you
don't
do
this,
so
it's
kind
of
a
timing
mechanism.
You
have
to
do
some
kind
of
timing
right,
so
when
one
guys
leaving
and
other
guy
has
to
take
this
take
the
roll.
So
there
were
a
couple
of
other
options
which
we
thought
about
when
one
of
them
was
timing,
but
you
cannot
make
sure
that
the
one
is
leaving
at
the
same
time.
Another
one
is
picking
up
right.
L
G
Can't
a
king,
why
not
just
have
the
guy
who's
going
down
just
send
out
a
lower
metric
without
any
hello,
hello,
special
hello
mechanisms
or
anything
just
send
out
a
lower
dr
priority,
and
then
he
would
lose
the
our
ship.
Somebody
else
would
take
over
and
then
they
would
take
over
from.
There
is
the
assert
resolving
that
switch.
L
From
one
to
the
other
or
what
you
know
so
so
this
is
definitely
that
is
one
option
to
do
it,
but
this
is
to
avoid
any
traffic
loss.
So
basically
it's
kind
of
you
are
saying
that's
right
now.
You
are
dr
when
you
say
that
now
I
am
not
be,
are
you
may
be
you
lower
your
metric
to
zero?
So
you
have
to
give
other
time
other
dr,
to
build
its
own
tree
and
then
start
forwarding.
Okay,.
G
G
That
again,
this
seems
like
an
implementation
thing,
or
at
least
at
the
very
least.
If
it
is
it's,
you
know,
it's
I
think
it
could
be
specified
for
informational
purposes,
but
I
think
it's
better
than
having
a
new
hello
option
that
then
you
have
to
worry
about.
Do
implementations,
support
it
or
not,
support
it
and
I
think
it'd
be
easier
to
just
do
this
without
or
changing
the
protocol
at
all
sure,.
N
Just
just
want
to
clarify
when
the
Saudis
happening,
the
DRI,
the
other
be
other.
The
idea
is
coming
active,
so
you
are
assuming
that
the
dr
will
keep
forwarding
the
traffic
and
there
will
be
basically
two
copies
coming
for
transient
time.
Yes,
so
just
to
let
you
know
in
the
world,
if
you
go
look
at
the
receiver
side,
they
don't
take
two
copies
of
the
multicast
very
well
so
you're
going
to
end
up
having
an
outage
anyways.
N
P
C
So
again,
smith
involved
with
this
draft
myself.
So
not
as
I
share
but
as
a
offer,
so
you
basically
have
the
choice
right
when
you
transition
the
Dro
it
either.
You
accept
some
gap
in
the
packets
might
drop
some
packets
before
you
get
the
new
folder
or
you
try
to
have
make
it
smooth
like
this,
where
you
might
get
duplication
of
a
packet
or
two.
So
it's
kind
of
like
a
depends
on
what
you
prefer.
Really
it's
really
hard
to
make
sure
that
you
have
no
drops
and
no
duplication.
C
You
cannot
choose
one
or
the
other,
but
there
the
issue
with
a
source
is
basically
the
guy
that
is
becoming
the
new
dr
here.
He
adds
this
interface
to
its
of'
list.
So
if
the
old
ER
keeps
forwarding,
he
will
see
like
oh
I'm,
getting
a
packet
on
my
outgoing
interface
I
should
send
on
a
search.
Then
the
all
of
the
previous
dr.
If
you
don't
do
anything
special
will
respond
by
also
setting
in
a
search
and
might
actually
win
the
ascertain
and
to
possibly
be
the
forward
or
even
though
he
is
going
down.
C
G
G
What
would
that
work
and
then
then
he
can
prune
his
branch.
You
eliminate
duplication,
because
I
think
that's
a
great
point
that
duplicate
packets
have
proven
to
be
far
worse
than
lost
packets
for
certain
applications,
not
video.
It's
usually
the
financial
guys
have
all
kinds
of
problems
with
with
duplicate
packets.
E
G
C
C
So
you
can
do
kind
of
make
before
break.
The
thing
you
know
is
in
the
usual
scenario,
when
the
routing
changes,
the
s
word
magic
will
be
better
for
that
other
guy,
so
he
will
win
da
search.
If
you
send
a
join,
even
though
you
aren't
actually
the
best
one,
but
it's
also
not
joined
through
the
other
guy,
then
we
will
do
a
certain
people
have
the
lowest
metric.
P
C
C
So
the
problem
we
are
solving
here
is
when
you,
basically
when
you
do,
when
you
build
an
hour,
you'll
build
a
pimp
tree
or
pf3
or
they'll
call
here.
You
basically
said:
I
joined
your
RPF
neighbor,
so
you
look
up
in
the
rip,
define
who
is
the
next
stop
towards
the
source
or
RP,
and
you
send
that
join
there,
but
if
you're
using
RFC
55:49,
when
you
look
up
a
before
address
or
not
your
next
stop
is
a
v6
address.
C
Yeah,
your
next
stop
is
a
v6
address.
So
then
you
can't
expect
that
you
will
have
a
pin
six
neighbor
you
can
simply
join
to,
but
but
for
before
s,
comma
G,
you
actually
want
the
before
neighbor.
So
the
question
is
in
a
way
you
have
your
ipv4
PM
neighbors.
You
have
am
not
view
for
s
comma
G,
but
unfortunately
your
next
stop.
It's
a
v6
address
because
our
C
55:49,
so
you
want
a
way
of
finding
out
which
which
which
V
14
neighbor
has
that
v6
address.
C
We
can
sum
me
for
join
to
the
right
before
neighbor
and,
as
it
turns
out,
we
have
the
secondary
address
this
option
in
RFC
76-61
7761,
which
takes
care
of
this
problem.
The
only
thing
is
in
in
that
RFC.
It's
expected
that
the
address
list
is
the
same
address
family
as
the
base
public.
Also.
So,
if,
before
hello,
you
expected
to
be
at
least
two
before
addresses,
what
we
want
to
do
is
the
exact
same
as
that
hello
option
says
it
should
do
except
it's
a
different
address
family.
C
We
want
to
list
me
six
addresses
in
the
hello
so
that
they
can
know
which,
before
an
able
to
join
to
so
we
agreed
in
the
working
group
like
to
ITX
ago
that
this
is
useful
solution.
It
was
adopted
and
nothing
has
happened
with
a
draft
the
last
to
idf's,
because
we
haven't
got
any
further
input,
so
we
offers
basically
believe
it's
ready
for
last
call
unless
people
have
any
concerns
about
the
current
draft.
C
A
A
L
C
C
All
right
so
have
this.
This
draft
that
I've
been
working
on
with
Alvaro,
so
it
started
out
as
some
more
like
a
cross.
This
kind
of
thing
ITF
process
thing
where
we
realized
that
there's
several
and
RFC's
using
pin
wizard
bits
basically
saying
that
solar
reservists
should
not
be
actually
used
for
specific
purposes,
but
50lakh
PSR
50:59
talks
about
using
a
specific
bit
to
mean
no
forward
him
by
their
fifty
fifteen
uses
former
bits.
E
C
That
perfect
for
smaller
purpose
and
so
on,
but
those
RFC
never
updated
the
original
RFC
for
its
601.
That
says
those
bits
are
reserved.
So
we
kind
of
wanted
this
one
document
just
updates
the
PM,
sparse
mode,
RFC
and
say
all
these
its
are
not
treated
as
restored
for
these
massive
cuts.
Also,
we
figured
it's
good
to
have
some
kind
of
registry
where
people
can
go
and
see
for
which
messages
or
which
bits
used.
So
that's
one
thing
that
this
drug
does.
C
The
only
thing
that's
trapped
us
is
trying
to
expand
them,
extend
the
pin
type
space
to
see
them
here
for
13,
14
and
15
extended,
so
we're
trying
to
find
a
way
old.
It's
extending
a
type
space,
because
today
we
only
have
16
message
types
and
we
already
have
used
to
all
of
them,
and
we
think
this
could
be
one
way.
Oh,
oh,
extending
the
space,
we
get
a
lot
more
options,
so
the
proposal
is
that
this
is
the
the
tokyo.
C
The
record
came
header
that
says
that
we
have
eight
bits
that
are
reserved
and,
as
I
was
showing
so
message,
tribes
actually
used
some
of
these
bits.
For
certain
purposes
and
what
they
are
proposing
is
that
for
message,
type,
13,
14
or
15,
you
say
that
the
four
left
mouse
restore
bits
actually
is
at
5:11.
C
So
basically,
we
are
saying
that
for
those
three
message
types
you
take
some
of
these
restart
its
here
and
make
them
form
a
sub
type.
So
the
idea
is
that,
for
you
know,
it's
like
Betty
Chuck
13
would
not
be
assigned
to
one
specific
protocol.
Oh
I
should
say,
but
rather
we
would
form
message:
types
like
14.04,
teens
of
Valen,
so
each
new
user,
whatever
message
messages,
each
new
message
we
define
will
use
some
subtype,
so
30.0
13
york,
bomb
and
so
on.
C
So
that
means
that
existing
existing
implementations
they
ignore
these
types
because
they
don't
know
what
they
are
used
for
right,
but
when
you
implement
in
the
future,
some
finish
they
flirting
of
0
or
something
like
that.
That
means
that
you
will
have
to
implement
call
that
that
also
looks
at
this
field
here
to
distinguish
the
message:
types
for
13,
14
and
15,
so
that
they
can
have
a
different
papers.
This
is
exactly
what
was
done
for
timber
timber.
C
There
has
several
new
message
types,
but
instead
of
using
as
like
several
in
main
message
types,
it
just
used
like
a
subtype
to
each
other.
So
it's
basically
saying
that,
instead
of
using
just
that
four
bits,
they
have
50
message
types
today
below
four.
Thirteen
fourteen
and
fifteen
include
four
additional
bits
as
part
of
that,
so
it's
a
backwards
backwards,
compatible
way
of
adding,
basically
48
new
message,
types
or
I
should
say
adding
45.
C
C
O
O
Yeah
that
that
means
that
we
would
have
to
assign
all
three
all
the
bits
that
means
90%
of
people
in
this
room
would
have
to
stop
coming
to
pin
for
that
to
happen,
if
not
100%,
so
the
chances
of
that
are
not
high,
that
you
know,
and
and
once
we
add
this,
then
we
have
to
you
know
it.
Will
it's
a
cascading
quirk,
make
work
effort
for
us
for
future.
That
may
never
happen
it
may,
but
it
may
never.
I
A
A
R
C
C
C
O
C
N
And
why
I
sign
these
bits
or
something
there
might
be
a
better
use
case
or
a
better
problem
to
resolve
in
the
future?
If
it
becomes
an
R
see,
then
these
bits
are
gone.
This
is
right
and
I'm
coming
from
another
section.
They
are
saying
that
there's
no
undo
like
if
it
goes
and
go
drop
it.
It's
no
going
back
right,
there's
no
honor
at
all.
We
don't
do
on
and
off
right.
N
J
Our
Itano,
not
speaking
as
an
author
speaking,
it's
the
irani
ad.
The
fact
that
we
you
adopt
anything
doesn't
mean
that
you
have
to
publish
anything.
You
may
run
out
of
interest
in
whatever
you
are
not
and
never
publish
it
or
you
can
change
your
mind
and
do
something
different
right.
So,
if
I
have
its
adopted,
something
that
you're
stuck
with
anything
not
just
for
the
strap
or
for
any
other
trap
that
has
been
already
adopted
just.
S
Yeah
there
is,
for
example,
the
parking
position
for
four
drops
as
well.
That
I
saw
on
data
tracker
right,
so
they
seem
to
be
all
type
of
things,
but
you
know
what
the
the
minimum
to
do
is
you
can
even
let
it
expire
and
every
time
somebody
comes
up
with
a
new
draft
and
wants
to
take
a
coke
point
then
bring
this
really
up
again
and
then
maybe
people.
You
know
that
one
thing
you
draft
are
also
a
lot
more
interested
to
take,
looks
and
start
having
opinions,
yeah.
C
S
L
C
J
J
That
right,
I
just
wanted
to
point
that
out
as
well
that
42,
whatever
the
number
was
46
or
one
and
so
inside
of
61.
Neither
one
of
them
say
how
to
assign
these
bits
and
even
though
they
don't
say
that
15:59
15
in
83
64
actually
took
bits
from
there.
So,
yes,
theoretically,
there
is
no
way
for
anyone
to
assign
those
bits.
But
we'll
read
that
right
and
and
yes,
those
rockers
went
through
this
working
curve.
J
But
in
theory,
if
someone
else
from
say
a
different
working
group
decides
to
assign
a
bit
there
for
whatever
reason,
I
don't
know
why.
The
only
way
to
stop
it
would
be.
If
one
of
you
we've
used
a
document
and
points
that
out.
If
the
ad
me
or
someone
else
finds
that
out
and
figures
out
that
there's
no
allocation
policy
in
the
registry
and
the
sides
stopped
it
or
whatever
else
for
all
those
three
RFC's.
No
one
really
noticed
until
it
was
too
late
right
and
so
yeah.
J
C
C
Q
C
C
We
do
that,
sir.
So
so
you
know,
that's
that's
why
I'm
I
want
to
do
this
now,
because
I'm
hoping
to
avoid
that's
happening.
The
problem
is
if
an
implementation
is
not
updated,
that
doesn't
know
about
subtypes
right,
it's,
it's
all
just
ignore
them.
There
we
start
bits,
because
that
was
restored.
Bits
means
and
it
will
then
go
ahead
and
answer.
Even
if
it's
message
was
stopped,
I
guess.
Q
E
C
Type
here
says
hello,
a
router
that
was
no
the
subtypes
would
then
think.
Oh,
this
is
an
hello
and
it
isn't
but
yeah
you
could.
Would
you
potentially
could
at
least
four
messages
at
a
link-local?
You
can
have
a
new
hello
option,
saying
I
support,
extended
types
or
whatever
right
and
just
say
only.
You
use
the
new
type
of
messages.
If
all
the
routers
on
the
land
say
they
support
support
that
yeah.
C
P
K
C
C
P
Yes,
thank
you.
Okay,
so
we
presented
this
in
London
and
proposed
solution
is
to
use,
be
a
belief
or
multi-point
network
specification
with
the
head
@dr
so
that
they
are
known.
Dr
ascend
routers
can
monitor
the
well-being
and
availability
of
dr
included
in
this
proposal
is
extension
to
pin
hello
format
so
that
there
are
bootstraps
known
their
routers
by
advertising
its
discriminator.
P
That's
because
the
specifics
of
multi-point
BFD
over
multiple
networks
does
not
use
three-way
handshake,
which
is
a
part
of
point-to-point
b.
Fd
R
RFC
fifty
880,
where
there
is
no
need
to
bootstrap
over
IP,
because
each
of
the
routers
exchanges
control
messages
and
thus
knows
remotely,
are
advertised
discriminator
and
can
do
demultiplexing.
Based
on
that
information
that
is
returned
to
it
by
its
peer
in
a
packet
at
in
the
field
of
your
discriminate.
P
P
P
Source
identity,
multicast
tree
and
my
discriminator
value.
So
that's
why
it's
important
to
do
the
bootstrapping
before
their
tails
can
listen
to
the
head
on
a
VFD
session,
so
that
all
was
discussed
in
original
version
and
before
the
meeting
we
had
very
good
discussion
on
the
list,
whether
it
can
be
extended
and
used
optional
in
the
use
cases
for
other
than
monitoring.
Dr
on
the
shared
media.
P
P
P
P
C
P
Right
and
that
that
is
one
probably
benefit
you
don't
have
to
do
a
full
mesh
off
point
to
point
b
of
these
sessions,
and
another
is
that
you
don't
create
unnecessary
stake
on
dr,
because
in
this
particular
scenario,
it's
only
tails
are
non.
Vide
are
unknown.
Dr
nodes,
that
are
interested
in
a
state
of
dr
dr,
is
not
interested
in
state
of
other
nodes
on
a
shared
link.
C
C
C
A
Okay,
so,
while
Dave's
working
his
way
up
here,
I
just
wanted
to
give
a
brief
background
on
this
draft
being
presented
here
in
PIM.
So
multicast
is
not,
and
you
may
have
your
own
take
on
this
date,
but
some
multicast
is
not
currently
specified
within
the
spring
working
group
for
segment
routing.
It's
not
part
of
their
Charter.
There
was
a
recent
reach,
chartering
discussion
and,
as
far
as
I
know,
multicast
was
not
included
as
part
of
that
reach
chartering,
so
we've
agreed
for
now
to
address.
Since
we're
protocols
right
be
multicast.
A
We
agreed
to
look
at
these
types
of
drafts
that
have
to
do
with
multicast
and
segment
routing
and
there's
been
some
different.
There's
been
in
the
like
in
the
last
IETF
we
have
a.
We
had
a
presentation
with
regards
to
beer
and
segment
routing
in
this
case
day
is
going
to
introduce
another
solution
for
multicast
and
segment
routing,
and
that's
that's.
Why
he's
here?
That
is
that
about
right?
No,
okay,
yes,.
A
A
T
R
Q
T
R
Okay,
so
for
to
be
clear,
this
is
not
tree
said
okay.
So
what
is
this
draft
about?
It's
about
using
computation
to
determine
the
routing
of
a
multicast
segment,
which
I
would
say
is
probably
analogous
to
a
tree
said.
This
is
for
an
MPLS
based
SR
Network
and
how
we
can
use
tunneling
using
node
SIDS
as
part
of
the
tree
construction,
and
this
could
either
be
a
distributed
or
a
centralized
control
model
if
it's
a
distributed
control
model.
R
For
example,
the
expectation
is
this:
multicast
membership
would
be
advertised
in
the
IGP
and
when
combined
with
knowledge
of
the
topology
well,
a
multicast
tree
can
be
computed
by
a
node
and
it
can
figure
out
its
role
in
it,
including
whether
it
would
be
tunneled
over
or
not.
So.
The
draft
describes
the
couple
of
tweaks
that
terminology
that's
required
to
incorporate
this
concept
in
the
segment
routing
gives
an
overview
of
the
overall
approach
describes
how
to
do
loose
or
explicitly
routed.
R
Multicast
distribution
trees
provides
an
algorithm
for
tree
construction
and
goes
into
fib
installation
procedures,
so
the
motivations,
the
biggie
in
doing
this
was
to
reduce
the
amount
of
state
in
the
network,
because
multicast
state
can
rapidly
dwarf
unicast
State
in
a
previous
life.
I
worked
on
shortest
path,
bridging
and
in
any
sort
of
network
design
that
I
worked
on
the
amount
of
multicast
State
very
quickly
blew
out
TIA
the
in
terms
of
the
FIB
construction.
R
The
other
motivation
is
to
leverage
the
MPLS
data
plane
and
segment
routing
as
much
as
possible
and
give
this
notion
of
being
able
to
use
tunnels
as
part
of
the
tree.
Construction
is
using
the
SR
MPLS
data
plane
in
ways
that,
for
example,
PIM
or
ldml
DP
could
not,
and
the
other
motivation
is
to
be
able
to
implement
multicast
where
beer
is
not
technically
or
economically
feasible.
R
So
the
approach,
the
draft
describes
an
architecture
where
the
tree
is
a
hybrid
of
the
roots,
the
leaves
and
the
replication
points-
and
this
is
all
interconnected
with
tunnels
and
the
routing
of
the
tree
is
determined
entirely
from
information
in
the
IGP.
This
could
be
in
a
distributed
model.
This
could
be
using
an
S,
our
controller
I,
don't
particularly
care.
R
These
are
all
valid
and
solutions.
It
gives
you
a
lot
of
benefits.
First
off,
is
it's
a
minimum
amount
of
messaging
to
converge?
The
network?
If
the
node
knows
all
the
member,
the
multicast
membership
and
the
topology-
and
there
is
add
apology
change,
each
node
has
sufficient
information
to
be
able
to
fully
converge
the
network
for
both
unicast
and
multicast
forwarding.
So
it
is
only
the
topology
change
advertisements
that
are
needed
to
again
to
fully
synchronize
the
network.
I've
already
gone
into
reducing
the
data
plane
state.
R
If
you,
for
example,
if
I'm
at
a
network
with
a
large
number
of
sparse
trees,
then
most
of
the
time
a
node
or
a
a
link,
failure
will
not
actually
affect
the
forwarding
of
the
majority
of
the
trees
in
the
network
or
the
even
the
trees
that
potentially
are
transiting
or
could
be
transiting
that
unicast
convergence
will
fix
it
and
that's
another
property.
That's
taken
advantage
of
so
an
example
tree
that
we
can
sort
of
barely
fit
onto
the
screen
here.
R
R
Despite
the
fact
that
node
14
is
transited
by
that
tree,
so
the
net
result
is,
is
I've
got
a
total
of
five
nodes
that
actually
have
to
participate
in
the
tree,
because
their
leaves
or
roots
they
really
going
to
be
sending
information
or
explicitly
receiving
it,
and
to
fully
implement
that
tree.
I
only
needed
to
install
state
and
nodes,
five
and
twelve
and
all
the
rest
of
it
took
advantage
of
the
that
denotes
id's
that
already
exist
and
are
maintained
by
the
IGP
doing
the
unicast
solution.
R
So
in
the
inside
of
the
big
picture,
I
have
a
a
reasonably
sized
tree
and
the
example
a
relatively
small
Network
diameter
and
the
net
result
was.
The
converged.
Solution
only
involves
two
extra
nodes
having
to
add
state
versus,
say,
for
example,
with
the
pin
solution
or
ml
DP.
It
would
have
been
at
least
five
nodes
to
do.
That
so,
you
can
see
how
the
amount
of
state
required
starts
going
down
quite
dramatically.
R
S
S
What's
the
sorry
tell
me
if
you
would
rather
have
the
questions
at
the
end
right
so
but
other
than
that,
it's
easier
to
so,
what's
the
reason
to
call
this
that's
a
segment
routing
as
opposed
to
MPLS.
Is
there
any
particular,
you
know
functionality
that
makes
you
other
than
it
sells
better
with
the.
U
L
U
U
F
T
Just
understand:
are
you
trying
to
leverage
on
the
unicast
SR
to
make
these
threes
or
like
to
me,
looks
like
right
now
what's
happening
here?
Is
that
like
on
node
number
five,
you
have
two
unicast
tunnel
SR
tunnel
right
when
you
come
to
five,
your
traffic
will
be
ingress
replicated
into
these
two
tunnels.
Is
that
is
that
the
case
or
did
I
get
this
wrong?
It's
not.
R
T
So
so
I
think
one
common
is
yet
definitely
I
believe
that
we
do
need
a
SR
type
of
solution
for
multicast
and
you
know
segment
routing,
but
but
right
now,
I
see
two
different
methods
on
the
table
that
they're
kind
of
competing
with
each
other.
The
three
seat
were
a
seed,
ID
kind
of
represents
the
entire
tree
end
to
end,
and
then
you
have
BG
BLS
vgv
srte
that
you
know
sucks
up
the
configuration
of
the
network
and
you
program
it,
and
then
you
have
this
method.
I
would
imagine
they.
S
And
and
I
was
specifically
asking
about
MPLS
versus
sr,
because
it
would
be
lovely
to
figure
out
some
good
technical
reasons
for
one
or
the
other,
instead
of
just
the
oh
wait.
A
second
sr
is
the
best
password
today.
That's
why
we
must
use
it
right
right.
The
technical
reasons
to
make
one
choice
or
the
other
would
really
be
good
to
document
right.
You
know.
R
Okay,
so,
okay,
so
the
use
of
tunnels
would
require
either
a
minimum
cost
or
near
minimum
cost
tree
in
order
to
be
sort
of
ecmp
friendly
and
what
I
say
mean
by
ecmp
friendly
is
I'm
trying
to
avoid
making
sure
that
under
no
circumstances,
I
would
get
two
copies
of
a
packet
on
any
single
link.
So
I'm
trying
to
avoid
any
possible
requirement
for
logical
multicast.
Now
there
is
a
tree
construction
algorithm
in
the
draft
as
to
how
you
can
actually
produce
those
trees
and
do
it
with
the
relative
minimum
of
computation
and
serendipitously.
R
The
algorithm
is
also
the
source
of
improvements
in
bandwidth
efficiency,
because
it
will
tend
to
ensure
that
the
replication
points
are
shifted
towards
the
edge
closer
to
the
leaves
and
the
network,
and
that
will
actually
drive
up
the
overall
efficiency
compared
to,
for
example,
PIM
or
ml
DP,
where
it's
relatively
random,
whether
they
actually
pick
the
the
best
and
closest
point
to
to
join
the
rest
of
the
tree.
So.
R
There
is
also
the
possibility
for
loose
or
explicitly
routed
trees
where
a
loose
tree
is
composed
of
a
multicast,
a
single
multicast
segment,
with
a
SID
where
only
the
roots
and
the
leaves
have
been
specified
and
the
the
connectivity
between
them
is
filled
in
as
a
result
of
computation
on
the
database.
We
can
also
have
an
explicitly
routed
tree,
which
is
basically
a
concatenation
of
multicast
segments
where
the
roots
the
leaves
and
the
waypoints
have
been
specified
and
which
means
I
can
then
engineer
a
tree
to
any
degree
of
granularity
that
I
want.
R
It's
been
brought
back
because,
as
it
turns
out,
there
actually
was
quite
a
number
of
people
who
were
interested
in
this
work,
and
this
weren't
provided
with
the
vehicle
to
express
that
at
the
time.
So
the
current
draft,
it's
updated.
The
terminology
to
align
with
the
current
state
of
SR
MPLS,
went
through
it
and
did
some
editorial
improvements
added
a
section
to
describe
the
motivations
or
at
least
some
text.
R
There
was
some
improvements
to
the
algorithm
description,
because
I
mean
this
algorithm
was
actually
prototype
and
actually
one
interpretation
of
some
of
the
optimizations
in
the
prototype
that
were
reflected
in
the
text
actually
made
it
a
bit
confusing
and
I
cleaned
that
up,
and
it
now
offers
some
thoughts
on
sr
controller
operation.
So
it's
sort
of
a
new
improved
for
the
over
the
last
version
that
has
been
presented
for
those
of
you
who
may
remember
it
from
back
then
to
get
to
next
steps.
Of
course
we
want
to
collect
feedback.
R
We
have
some
planned
updates
to
the
draft
in
terms
of
there
was
some
improvement
to
the
installation
procedures
of
our
envisioned
I
want
to
see
if
there's
any
changes
to
the
draft
required
to
bring
it
up
to
the
current
state
of
MPLS
friendliness
in
terms
of
mapping,
block
offsets,
etc
and
has
been
noted.
This
also
could
be
applied
to
MPLS
as
well.
Once
that's
done
and
in
future
drafts
we
will
be
bringing
forward
the
required
IGP
extensions.
R
We
did
do
a
first
crack
of
that
back
in
the
IETF
97
timeframe
on
how
to
inter
work
with
existing
mechanisms,
and
we
are
pursuing
standards.
Try
of
course,
and
as
Mike
explained,
there's
a
reason
why
we're
doing
it
in
PIM
and
that's
because
it's
not
currently
in
the
segment
routing
charter,
so
it
won't
be
for
a
while
a
10-7
I'm
the
sounds
of
it.
Yeah
Jeffrey.
V
Donald
from
juniper,
so
when
we
talk
about
spring
to
me,
the
main
event
event
you
see
we're
talking
about
is
that
it
does
not
have
a
per
tree
or
per
proton
estate
in
the
core.
Here
we
still
have
the
per
tree
state
in
the
core.
It's
just
that
on
those
points
where
you
don't
have
replication,
you
don't
need
that
state
anymore
and
if
I
understand
it
correctly,
you
still
have
still
have
to
flood
the
group
information
everywhere.
I
think
that's
even
worse
than
before.
V
V
Yes,
okay
right,
so
so,
if
this
does
not
really
it
in
my
mind,
if
they
does
not
really
fit
the
espring
philosophy,
that's
that's
one
common
there
and
another
thing
is
that
we
for
spring
multicast.
We
don't
really
need
one
solution
that
fits
all
situations.
Quite
a
few
of
us
have
actually
contemplated
writing
an
informational
draft
on
what
how
did
the
magazine
in
a
spring
network
I
think
the
best
is,
in
my
view,
the
best
would
be
to
choose
whatever
suits
you
best.
E
V
As
you,
you
don't
mind,
main
hinder
those
states
and
then
finally,
if
you
really
just
want
to
remove
another
signaling
protocol,
yet
you
still
don't
mind
having
the
piranhas
state
and
then
just
use
another
way
to
set
up
that
panel.
The
tree
said,
however,
it
is
setup
that
this
is
just
one
way
to
do
that,
so
you
realize
you
are
giving
me
a
staggering
a.
R
Okay,
so
I
mean
in
the
spring
charter.
One
of
the
statements
it
says
right
off
is
is
that
it
does
not
want
to
modify
the
data
plane
of
the
existing
technologies
that
it's
using
and
so
I
saw.
This
is
about
as
close
as
you
could
come
for
multicast,
while
preserving
the
single
control
plane
paradigm,
because
you
know
I've
checked
with
the
vendors.
This
can
be
done
with
the
existing
MPLS
stuff.
Now,
I
think
that
is
useful.
R
As
for
whether
or
not
you
end
up
with
path
state,
you
already
have
the
concept
of
the
binding
SID,
which
to
me
is
simply
a
rather
cute
and
run
around
this,
in
that
the
binding
SID
itself
locally
does
translate
into
a
potential
series
of
local
actions
that
have
been
configured.
So
you
know,
I
don't
want
to
get
into
a
philosophical
discussion
about
this
I
just
I.
So
look.
E
V
R
S
So
let
me
try
my
attempt
at
sore
loser
whining
here
so
I'm
doing
Bertie,
and
so
basically,
after
the
recharging
no
and
it
became
you
know
an
adult
working
group
and
basically
the
rule
was
only
doing
the
forwarding
plane
things
and
you
know
you're
doing
control
plane,
especially
traffic
engineering
aspects.
You
must
go
to
T,
so
T's
is
responsible
for
the
traffic
engineering.
I
haven't
followed
up.
R
S
O
We
try
to
simplified
it
and
for
service
providers
to
deliver
Tim
is
that
than
the
whole
problem
of
control,
plane
and
okay,
if
I'm,
removing
unicast
control
plane
and
putting
segment
routing,
what
will
I
do
with
multicast?
We
solve
this
with
beer.
Yes,
it
changed
a
data
path.
If
you're
using
some,
you
know
low-end
hardware,
that
was
true,
probably
five.
Six
years.
Okay,.
O
O
You
would
I
would
say
that
anybody
who
deploys
and
things
of
of
control,
plane
segment
routing
has
a
hardware
that
will
be
able
to
do
either,
which
means
why
would
we
introduce
something
else
yet
for
the
same
solution
and
add
operational
complexity
or
a
solution,
variation
complexity
that
would
and
I'm
not
argue.
You
know
if
this
was
discussed
three
years
ago.
Maybe
a
different
outcome
for
every
route
would
happen,
maybe
not,
but
today
I
think
that
should
be
about
whether
we
should
work
on
it
or
not.
Why
would
we
work
on
bit
well.
R
It's
yeah
well.
This
was
actually
first
discussed
in
IETF,
95
and
I'm,
not
aware
of
anybody
in
the
lower
end
ships,
even
contemplating
beer,
in
fact,
I
dropped
it
in
97,
because
my
expectation
was
is
that
beer
was
going
so
to
go
forward,
but
ultimately
yet
and
so
a
little
bit
more
ubiquitously
than
it
has,
and
that
hasn't
actually
really
happened,
which
is
why
people
have
suggested
I
bring
this
back
to.
O
O
E
T
So
but
I
do
feel
someone
in
agreement
with
Andrew
I,
think
you
know
segment.
The
routing
already
has
a
bunch
of
complexity
on
its
own,
and
now
we
want
to
put
multi
chaos.
On
top
of
that,
it
might
be
a
complex
solution
that
that
said
again.
I
feel
that
you're
right,
some
vendors
will
need
si
three
seed
or
its
seed
or
whatever
it
is
that
they
want
to
call
it
to
replace
a
MPLS
signal
pimsy
with
something
in
a
Sdn
type
of
level.
T
R
T
T
So,
if
you
haven't
known
there,
are
they
trying
to
leave,
create
the
leaves
it's
gonna
take
two
MPLS
labels
or
whatever
it
is
that
you
guys
are
taking
the
c1
going
north
wise
one
going
south
was
like
what
you
have
exactly
right
there
on
node
number
five,
you
using
seat
11,
going
to
leaf
11
and
seat
13
to
leave
13.
So
that's
two
different
levels
under
stacking
them:
I'm
tunneling,
you're
stacking
them
on
top
of
seat
five,
so
the
entire
tree
is
presented
by
seat.
Five.
Is
that
by
yourself.
M
V
Quick
question
to
our
ad,
and
maybe
whoever
was
familiar
with
a
spring
charter
updating
process,
so
the
Marcus
was
not
included
in
the
latest
spring
charter.
Is
it
because
they
don't
think
it's
a
problem
worth
solving
now
or
is
it
because
they
please
work
with
other?
We
think
this
should
be
done,
but
it
should
be
done
in
some
other
working
group.
J
J
A
N
To
comment
on
that,
like
I'm,
full
operator
side
and
would
not
agree
with
our
guys
from
the
vendor
side,
I
think
the
beer
is
already
in
the
next
two
years
and
the
operators
will
go
for
a
beer
model
only
so
nobody's
gonna
forklift
and
upgrade
the
networks
in
the
next
two
years.
I
able
to
be
legacy
devices
still
there
and
we
will
need
some
other
solutions
other
than
beer
as
well,
and
even
if
you
look
at
today,
this
was
bf
and
is
is
running
right
there.
Some
people
use
OS
we
have
some
people
use
is.
N
Is
this
always
better
to
have
few
solutions
like
not
hunter,
but
at
least
few
barrel
solution
which
people
can
pick
and
choose
right
and
I?
Think
it's
a
very
good
solution.
You
should
work
on
it.
The
only
concern
we
have
on
our
side
would
be
that
what
would
how
would
it
scale
on
a
large
scale?
Multicast
deployments
right?
That's
would
like
possess
a
stateful
method
and
if
it
can
scale
for
a
large-scale
multicast
networks,
this
is
a
really
good
solution.
Okay,.
O
Quick
question
what
you
guys
running
for
multicast
now,
exactly
so
a
to
to
technology,
evolutions
happen
since
it's
a
no
effect
and
and
we
you
didn't
move
for
specific
for
various
reasons.
So
now
now
we're
going
to
have
to
another
solutions
and
to
technology
evolutions
and
will
you
move
or
will
you
not
move
and
and
like
lots
of
choices,
came
sometimes
good,
sometimes
not
the
best.
N
I'm
saying
that
at
least
10
solutions
should
be
there
or
less
than
100
solutions
is
also
not
good.
So
it's
not
a
lot.
There
should
be
a
few
solutions
to
pick
from
right
and
people
that
should
have
the
choice
to
pick
at
least
one.
It's
a
philosophy.
It's
a
culture
like
different
teams,
approaches
the
different
way
right.
Not
every
network
runs
is,
is
they're,
not
happy.
Networks
are
to
us.
We
are
right
whose
people
make
the
choice
and
vendors
cannot
like
run
either.
Will
your
thing.
O
Because
seriously,
the
times
when
we
could,
as
vendors
implement
million
solutions
in
hardware
and
software
are
gone
those
times,
I
think
we
all
understand
them.
So
we
can
talk
technology
and
stuff
like
this
and
then
are
we
gonna
come
to
you
guys
and
you're
gonna,
say
well,
I
want
to
buy
it,
but
it
has
to
cost
that
much.
Oh,
it
cannot
cost
that
much
because
you
wanted
this
and
this
and
this
and
this
so
in
this
world,
of
building
efficient
things
that
do
that.
Do
the
work.
O
N
N
R
N
A
A
B
S
Now
so
just
wanted
to
say
that
on
the
forwarding
plane
stuff,
that
was
one
of
the
questions
to
us
about
MPLS,
because
I
think
we
could
keep
the
ML,
DP
or
rsvp-te
point
and
also
point
forwarding
plane.
If
we
wanted
to
do
something
like
that,
but
it's
basically
MPLS
is
completely
done
and
we
don't
want
to.
You
know:
do
new
control
for
it.
That's
I!
S
R
A
That
we
would
pull
the
list.
We
will
do
that
on
the
list.
Mike
McBride
from
always
speaking,
I
think
that
this
is
exactly
why
we
did
recharter
this
working
group
some
time
ago
to
address
protocols
for
IP
multicast,
so
I
think
it
could
should
certainly
fit
within
our
group.
We
may
have
to
talk
to
Alvaro
if
this
working
group
does
feel
like
it
should
work
on
this
type
of
work
that
we
should
maybe
add
that
to
our
charters
explicitly.
But
we
can
talk
about
that
later.
Okay,
yeah.
The
comment
well.
C
O
We
need
to
have
those
discussions.
What
I'm
trying
to
say
is
guys
we
need
to
have
the
discussion,
but
we
which
should
not
be
creating
things
and
you
know
I-
am
NOT
I'm
not
trying
to
be
controversial,
but
if
you
want
to
see
how
a
life
or
that
is
technology,
look
at
the
last
two
years
of
a
deliberate
roadmaps
or
product
extension
on
major
I'll.
Tell
you
how
active
or
not
active
certain
technologies
we
can
be
standardizing.
You
know
the
hell
out
of
the
the
stuff,
but
look
at
the
implementations
and
what
they
are
well.
R
S
C
S
Okay,
so
wait
a
second
which
which,
which
think
was
real
I,
don't
know
I've.
So
sorry,
I
didn't
know
what
in
which.
C
S
Okay,
so
there
were
no
update
since
101,
so
I
just
wanted
to
do
slides
with
a
sales
pitch.
Why
you
shouldn't
think
this
is
just
some
strange
optimization
in
the
exotic
parts
at
a
far-off
Island
in
pym
world
right
so,
but
instead
no,
it's
an
important
part
in
the
puzzle
to
update
our
protocol
landscape
for
the
21st
century.
Okay,
excite
right!
So
what's
the
strategy?
S
Sorry,
these
lights
are
all
way
too
taxi,
so
they're
better
to
read
on
your
own
after
you
had
way
too
many
beers,
so
I
think
we
want
the
best
compromise,
moving
the
industry
to
what
we
understand
to
be
best
working
and
what's
best
feasible
right
and
our
contingencies.
Are
you
know
the
network
operators
and
evolving
to
the
be
the
best?
Has
you
know
key
third-party
dependencies
and
that's
pretty
much
the
problem
between
ASM
and
SSM
that
enterprises
can't
easily
move
everything
to
SSM
right.
So
there's
a
lot
of
stuff
where
the
application
dependency
says.
S
Oh,
it
should
be
nice,
the
same
application,
but
I
can't
do
it
and
then
they're
also
great
fighter
PIM
ASM
applications
right
so
until
we
basically
make
any
progress.
I
would
claim
that
you
know
for
many
vendors
90%
of
the
money.
They're
making
comes
from
deployments
where
you
know
ASM,
with
either
PIM
sparse
mode,
intradomain
and
orbiter
PIM
is
really
crucial,
and
so
we
really
need
to
make
sure
that
we
have
for
that
option,
also
an
evolution
long-term
to
say,
here's
the
best
protocols
we
want
to
use
for
that
next
slide.
S
So,
but
one
of
the
big
leftovers
that
we
have
is
MSTP
right,
so
we're
going
to
get
rid
of
em
SDP
interim
inter-domain
if
we
adopt
the
ongoing
call,
for
you
know
the
deprecated
inter-domain
a
SM
in
Ambon
D.
So
if
you
weren't
aware
of
that,
please
go
to
the
M
bounty
list
and
say
I
support
the
draft,
so
that
was
support.
S
There
was
discussed
an
hour
ago
in
Ambon
D,
so
that
will
have
us
get
rid
of
inter-domain
ASM,
but
that
doesn't
allow
us
yet
to
completely
retire
M
SDP,
because
it's
left
over
with
a
really
well
working
solution,
which
is
called
the
MSTP
mesh
group
within
a
domain
in
intradomain
to
basically
do
a
mesh
group
for
40,
MSM,
and
so
now.
The
goal
here
is
to
figure
out
what
we
can.
S
We
do
to
replace
MSTP
network
and
we've
got
RFC
46
10,
which
is
the
pim
anycast
RP
functionality,
and
it's
just
missing
pieces
where,
when
I'm
talking
to
customers,
I'm
always
saying
if
you
want
to
have
ipv4
MSTP
in
the
implementations
in
what's
been
standardized
is
better
right.
It
has
a
mid
model
right.
It
has
limiters.
It
basically
got
reliability,
congestion
control
because
it
uses
TCP
yada-yada-yada.
S
So
in
the
end,
what
I
think
is
we
want
to
get
RFC
46:10
up
to
that
level,
which
involves
two
parts
of
work?
One
is
the
yang
model
with
which
we
can
do
all
these
operational
things
like
your
load
limiters,
and
you
know,
cache
entries
showing
all
the
stuff
can
nicely
be
up.
Optional,
it
doesn't
have
to
be
part
of
you
know
the
product
called
specs.
S
Just
you
know
a
local
implementation
part
that
vendors
can
put
in
if
they
want
to
do
with
the
yang
model
and
the
other
one
is
reliability
TCP,
and
this
is
where
this
draft
comes
in,
because
this
is
pretty
much
a
saying.
We
already
have
reliable
PIM
over
TCP
with
all
the
congestion
control
that
we
need
over.
You
know
nasty
links
that
we
get
more
and
more
with
Wireless
and
anything
else,
and
of
course
you
know
when
links
where
we
have
the
pin
register
between
mesh
group
members
running
they're
often
also
are
problematic.
S
When
we
have,
you
know,
fail
overs,
so
so
this
draft
is
pretty
much
adding
port
for
the
registers.
The
important
case,
I
think,
is
the
mesh
group.
It
also
gives
us
port
for
the
dr
to
RP
operations,
which
is
great
too,
which
kind
of
to
me
a
second
priority
from
the
strategy
perspective
next
slide
right,
so
we
would
like
so
this
has
been
around
for
quite
a
while
right
this
draft.
So
we
would
like
to
ask
the
p.m.
working
group
to
adopt
this
document.
Please
go
read
it.
S
What
you
think
right,
we,
the
the
text
for
the
technology,
has
been
fairly
stable
right.
This
is
the
strategy
right.
I.
Don't
want
to
talk
about
all
these
things
here.
I
think
that's
the
second
slot
which
we
may
run
out
of
so
the
main
missing
part
in
the
text
is
really
only
add
information
about
this
strategy,
which
relates
to
why
we're
adopting,
but
not
the
technology,
about
how
it's
working,
that's
pretty
much
done,
I
think
right.
G
Iii
think
you're
scapegoating
ms
DP
I.
Don't
think
ms
DP
is
the
criminal
here
I
think
ms
DP
is
merely
driving
the
getaway
vehicle.
The
the
the
real
culprit
here
is
ASM
and
I.
Think
you're
blaming
MS
DP
when
you
should
be
blaming
ASM
and
all
you're
doing
is
taking
the
stuff
that
ms
DP
did
and
moving
it
to
other
protocols
and
I.
Don't
think
that's
that
that
helps
ms
DP.
You
know
I
think
it's
a
scapegoat
because
it
was
given
an
impossible
task
and
it
does
it
it
doesn't,
and
it
does
it.
G
There
is
okay,
so
so,
where
ms
DP
is
bad,
is
inter-domain
right,
but
it's
not
because
ms
DP
is
a
bad
protocol.
It's
because
it
was
given
a
task
right
to
do
and
it
did
it,
but
it
was
a
it
was
an
impossible
task
or
and
not
a
good
task
that
it
should
have
never
been
given.
Yes,
intra-domain
what
ms
DP
is
doing
within
a
domain
for
anycast
RP,
which
is
typically
what
it's
used
for
is
just
any
connecting
your
anycast.
Our
peas
together,
there's
nothing
wrong
with
em
sdp.
It's
perfectly
fine
it-it-it!
G
None
of
the
things
that
you
that
that
we
associate
with
not
liking
MSD
p4
is
it
is
it
abusing
in
in
an
intra
domain
world
and
in
fact
all
you're
doing
is
just
making
RFC
46:10.
All
it
did
was
make
him
do
what
MS
DP
did
and
now
you're
saying.
Well,
it's
missing
a
few
of
the
things
that
ms
DP
was
doing
so,
let's
add
all
those
in
there.
So
we
can
completely
get
rid
of
em
s.
Dp
I,
don't
think
MS
DP
is
the
problem.
G
Renaming
protocols
doesn't
make
things
simpler,
moving
the
same
function
from
one
protocol
to
another,
because
it's
a
less
popular
product
from
a
less
popular
to
a
more
popular
protocol
doesn't
make
things
better.
You're
just
renaming
functions,
so
I
think
the
the
goal
of
eliminating
ms
DP
I
think
is
is
misguided
because
it's
MS
DP
isn't
the
problem.
Asm
is
the
problem
we're
just
you're
just
scapegoating
MSTP,
okay,.
S
So
thank
you
for
pointing
out
that
I
may
be
too
offensive
right.
So
but,
let's
say
technically
right.
So
in
the
first
place,
yes,
I
do
think
that
intradomain
PIM,
sparse
mode
with
an
MS
DP
mesh
group
is
a
very
successful
deployment
model,
all
right
very
well
working
and
it's
basically
the
best
way
for
an
enterprise
to
basically
set
up
a
rock-solid
multicast.
That
gives
you
shortest
path,
trees
and
everything
that
you
need
to
use
for
your
stupid,
ASM
application
every
stupid.
They
are
right.
That's
basically
not
the
point
here.
S
So
it's
it
gets
me
the
same
stuff.
It's
just
very
inconsistent
and
I
would
want
to
do
a
new
yang
millennial
right.
The
the
ipv4
MSTP
myth
only
doesn't
help
me
these
days
anymore.
So
that's
why
I'm
saying
it's
technically
the
better
alternative,
then
trying
to
revive
em
SDP
for
ipv6
intradomain.
Only
let.
C
G
And
and
and
in
the
case
of
v6,
we
determined,
we
don't
need
MSD
p4
v6,
because
MSD
P
was
doing
two
things.
One
inter-domain
and
one
intra-domain
embedded
RP
gives
us
in
turbo
domain
and
46:10
gives
us
intradomain.
I
guess
your
point
is
it
gives
us
intro
domain,
but
all
mo
not
as
much
there's
some
things
missing
that
we
want
to
fix
to
get
46:10
to
the
level
of
functionality
that
even.
S
Embedded,
the
embedded
RP
is
just
a
very
ipv6
specific
management
rule
right
that
basically
have
you
when
you're
doing
before
n
v6
come
up
with
totally
different
things
and
doesn't
give
you
the
same
amount
of
resilience
that
you
get
with
multiple,
simultaneously
active
RPS,
which
is
what
the
mesh
group
does
right.
So
it's
still
kind
of
the
the
best
resilient
solution
that
we
have
for
ASM.
Well,
you
still
have
46
10-4
intradomain,
any
Kaspar,
no.
G
S
I'm
saying
that
solution
doesn't
give
me
the
reliable
TCP
connection
that
basically
worked
well
over
when
links
when
I
have
fail.
Overs
and
I
get
this
burst
of
10,000.
You
know
essays
or
you
know,
register
messages,
however,
want
to
call
that
right.
So
that's
basically
just
a
rock
solid
solution
and
that's
something
which
I
think
we
should
have
better
than
with
an
ipv4,
only
experimental
protocol
that
we
typically
about,
obviously,
as
you
said
only
for
the
inter
domain
case
and
it's
unfair,
because
obviously
that
was
an
impossible
task.
So.
G
S
S
C
S
D
A
G
I
think
there
are
some
folks
who
still
want
and
intra-domain
ASM
and
I
think
in
many
cases
they're
misguided,
that
just
about
all
applications
can
be
done
with
a
SSM
as
well,
and
so
the
one
thing
I
would
be
worried
out
is:
do
we
want
to
continue
pouring
resources
into
ASM
when
and
how
n
providing
more
and
more
solutions
to
keep
ASM
alive,
even
in
the
intradomain
case?
Or
do
we
want
to
help
these
people
move
along
to
the
to?
The
next
thing
was.
A
W
Hello,
everyone
I'm
Roenick
from
Cisco
and
I'll,
be
presenting
this
raft
for
PIM
not
register
packing.
So
as
we
know
that
PIM
uses
an
unregistered
mechanism
to
refresh
the
multicast
States
at
the
RP
from
the
first
of
router
for
one
particular
SG,
we
send
one
null
register
today.
If
there,
the
number
of
states
multicast
states
increases
if
the
number
of
multicast
sgz
increases
will
have
that
many
number
of
Imanol
register
that
will
be
sent
periodically
from
fhr
to
the
RP.
This
could
potentially
cause
drops.
W
Essentially
it
could
happen
that
in
our
network
you
can
have
another
RP
which
actually
does
not
understand
this
message.
So
we
also
propose
a
compatibility
checking
mechanism
by
which
RP
actually
can
act
and
say
that
okay
I,
do
understand
this
message,
so
I
am
ready
for
the
Pagnell
register
message
only
when
they
both
support
Pagnell
register
messaging.
This
message
will
be
sent
from
the
first
router.
W
So
essentially,
the
advantage
is
actually
to
the
overall
null
register.
Packets
in
the
network
will
reduce
drastically,
will
better
be
able
to
utilize
the
control
plane
in
in
case
of
scale
specially
also,
it
is
relatively
very
easy
to
implement.
It
does
not
require
any
special
or
special
writing
of
the
code.
We
already
walk
all
the
routes
for
the
pimp
for
clubbing
all
the
pin
joints
prunes
in
one
single
message.
All
we
have
to
do
is
actually
pack
the
null
register
and
send
it
to
the
out.
W
V
A
A
Okay,
good
for
you.
That's
that's
promising,
so
we'll
take
them
to
listen.
W
So
this
draft
primarily
discusses
various
scenarios
requirement
and
a
possible
solution.
We
can
have
more
discussion
on
it
later,
but
the
draft
essentially
has
a
possible
solution
for
same
as
part
of
the
current
jail
procedure.
We,
the
router,
who
is
undergoing
Gir,
will
send
infinite
matrix
across
all
the
routers
in
the
network.
This
infinate
matrix
will
lead
to
RPF
change
on
all
the
routers,
so
some
so
the
multicast
flows
needs
to
actually
change
the
RPF
to
make
sure
that
you
know
they
point
to
the
new
path
and
remove
the
old
path.
W
W
So
the
idea
is
mainly
to
do
make
before
break
here.
Until
the
packets
arrive
on
the
new
path,
the
the
downstream
router
will
keep
on
forwarding
accepting
the
traffic
and
following
the
traffic
downstream
towards
the
receivers
once
the
traffic
come
on.
The
new
path,
the
RPF
field
packet
to
the
control
plane
will
indicate
that
the
we
have
received
a
flow
on
the
new
path
upon
which
the
RPF
will
be
changed
from
old
path
hold
our
trip
to
new
RPF,
and
this
change
will
be
Atomics.
W
So
it
should
lead
to
non-stop
forwarding
of
the
multicast
traffic,
the
above
method,
this
particular
method
of
doing
the
graceful.
Our
RPF
change
may
not
be
advisable
in
the
normal
RP
of
change
scenario,
because
it
could
happen
that
the
old
old
link
could
Li
could
be
down
due
to
network
failure
or
the
link
fail
failure,
so
RPF
may
take
more
time
which
could
increase
the
convergence
time.
Therefore,
we
propose
that
this
make
before
break
model
should
be
followed
only
for
only
within
the
gr
window.
W
We
introduce
a
new
TLV
in
the
DFM
message
and
this
is
originated
from
the
router
who
is
undergoing
gr.
This
message
is
flooded
across
all
the
routers
in
the
pim
domain
and
it
carries
the
start
and
the
end
time
for
the
gir
period,
the
you,
the
unicast
matric,
has
to
be
adjusted
in
such
a
way
that
the
universal
metric
should
come
in
between
the
start
and
the
end
time.
W
Once
all
the
routers
receive
this
infinite
metric,
it
will
try
to
do
the
RPF
chain
in
a
graceful
manner,
as
we
had
discussed
earlier,
and
this
should
hopefully
lead
to
no
disruption
well
minimal
or
no
disruption
in
the
multicast
traffic
flow.
The
same
method
can
actually
be
followed
for
the
graceful
insertion
of
the
router
and
same
method
should
follow
for
both
of
them.
So
this
is
a
new
draft.
What
I
would
like
to
know
is
your
comments
on
it
any
feedback,
and
if
this
can,
if
we
could
take
this
forward,
HF.
V
Reference
Unipro
this
make
before
break
it,
has
been
brought
up
before
you.
In
fact,
some
vendors
actually
have
implemented.
I
forgot
if
we
implement
it,
but
it
can
actually
be
used
in
the
you
know
in
more
general
case,
not
just
that
this
insert
Chris
for
insertion
removal,
because
if,
if
it's
just
a
normal
topology
change,
if
the
old
pass
can
still
be
used,
even
if
it's
not
the
best
pass
anymore,
obviously
the
implementation
should
be
smart
enough
not
to
to
tear
down
immediately.
V
You
can
still
expect
a
receiver
traffic
on
the
old
pass
until
you
receive
the
traffic
on
the
nude
pass,
and
if
that
old
pass
is
completely
broken,
the
interface
went
down.
Obviously,
your
implementation
should
be
smart
enough
to
images
to
switch
the
old
to
the
new
pass,
so
I,
don't
think
it
needs
to
be
specific
to
the
Chris
for
insertion,
removal
and
I.
Don't
think
you
need
the
signalling
so
that
everybody
know
okay,.
O
W
O
We
even
killing
ourselves
to
make
it
not
not
traffic
disrupting,
even
though
applications
at
the
end
don't
care
because
they
buffer
enough
that
we
recover
and
it's
applications
do
care.
Then
you
have
a
much
better
mechanisms
that
this
will
ever
able
to
achieve,
because
you'll
have
a
zero
packet
loss
mechanisms
then
set
up
for
multicast
so
way.
W
G
G
I
think
this
is
a
much
better
approach
than
those
dr
mechanisms.
Essentially,
you
know
make
before
break
that
that
would
solve
that
problem
as
well.
It's
a
this
is
a
generic
case
that
solves
a
lot
of,
as
opposed
to
that
being
a
specific
use
case.
I
think
this
could
this
could
kind
of
replace
the
the
dr
problem
we
were
discussing
earlier?
Okay,
thanks.
S
N
You
may
need
to
take
into
account.
Is
the
one
is
that
again,
the
duplicate
traffic?
The
second
thing
is
because
this
PIM
only
works
by
hop-by-hop,
its
adjacent
neighbors,
not
beyond
that
the
anisa
reverse
path,
forwarding
in
certain
scenarios
and
I
on
how
you
build
your
topology.
You
may
cause
our
loop
between
the
routers
or
the
signaling
part.
W
Yeah
in
the
draft-
actually,
we
have
also
mentioned
the
fact
that
since
pfm
message
could
carry
a
unicast
prefix,
all
the
routers
can
actually
know
who
that
unicast
prefix
is
so
essentially,
if,
if
you
have
a
multicast
state
already
with
that
prefix,
you
will
only
do
this
thing.
Otherwise
you
will
not
do
it.
As
far
as
the
message
is
concerned
that
it
goes
off
by
oh
I,
think
the
pfm
message
is
flooded
across
the
pim
domain,
so
I
think
we
should
be
good
there
right.
C
V
C
F
S
All
right
so
don't
move
the
slide,
so
this
is
a
quiz
so
who
was
in
M
Bundy
yeah,
so
you're
not
allowed
to
answer
so
I
want
to
build
today.
You
know
a
network
with
the
you
know,
most
IETF
well
recognized
and
standardized
the
protocol
for
hosts
to
do
multicast
question
what
what
protocol
would
that
be?
Now.
S
Okay
next
slide,
so
there's
pretty
much
only
one
of
all
these
protocols
that
has
the
level
of
full
ITF
standard,
not
proposed
standard,
not
draft
standard
but
full
standard,
and
that
is
RFC
11
12,
which
is
specifying
IGMP
b1.
So
you
don't
want
ipv6
and
you
don't
want
any
of
the
newer
protocols
if
you
want
to
have
a
full
standard.
S
S
So
I
think
there
is
some
good
education
to
be
done,
but
I
think
we
should
also-
and
that's
something
like
an
informational
model
which
we
may
want
to
put
into
an
Bondi,
but
for
this
working
group
I
think
it's
primarily
the
question
of
what
can
we
do
to
adjust
the
stages
of
the
documents
that
we
have
to
the
reality
of
what
actually
is
really
the
most
widely
deployed
and
recommended
protocols?
And
it's
certainly
not
a
GMP
version.
One
next
slide
right.
So
the
whole
idea,
of
course,
is
this.
S
Work
should
not
touch
ASM
right,
so
we
have
all
the
discussion
of
retired
it
inter-domain
and
what
we
can
basically
do
with
the
other
draft
to
evolve
the
protocol,
so
we
get
rid
of
em
STP
or
you
know
basically
just
have
a
good
standard
stuff
to
do
the
mesh
group
internally.
But
let's
say
this
particular
work
item:
let's
just
focus
on
how
we
adjust
the
stages
of
the
best
part
of
codes
and
kind
of
downgrade
the
older
ones.
Next
slide.
So
here
is
basically
list.
The
the
standard
stuff
is
what
they
currently
have
right.
S
S
There
is
no
specification,
the
IETF
for
the
ASM
service
model
for
ipv6,
but
this
document
is
two
things:
it's
the
ipv4
ASM
service
model
and
it
is
the
specification
of
IGMP
v1,
so
I
think
the
best
solution
would
be
to
really
you
know
to
a
ref
of
it.
Remove
all
the
IGMP
v2
one
at
ipv6,
right
wherever
it
says
something
about
the
protocol
kind
of
before
v6
and
that's
basically
the
standard
for
ASM
and
it
just
saying
the
service
model.
You
join
a
group,
that's
pretty
much
all.
S
It
says
obviously
a
bunch
of
interesting
details,
but
really
not
try
to
map
around
with
it.
Just
you
know,
get
rid
of
IGMP
v1.
So
we
can
continue
that
as
a
full
internet
standard,
obviously
also
for
ipv6
and
be
done
with
it.
So
then,
we've
got
a
GMP
v2
proposed
standard.
Well,
okay,
so
obviously
one
a
GMP
v3,
but
what
is
it
and
kind
of
what's
the
historic
process
right?
What's
our
downgrade
options
right.
C
J
You
guys
watch
do
okay,
I'm
gonna
regret,
so
what
I'm
gonna
tell
you?
Is
this
there's
two
options
right?
The
option
is
to
go
either
obsolete
now,
usually
obsolete
means
I
have
a
replacement
specification
for
yes,
which
is
not
this
right.
That
sounds
good.
The
other
one
is
just
change
the
status
to
historic.
J
Now
the
nice
thing
about
that
is
that
we
can
do
a
change
of
status
in
place.
That
means
we
don't
have
to
do
a
new
RFC,
1112
bits
or
something
okay
to
replace
your
one.
We
can
just
put
in
a
justification
of
why
we're
doing
this.
Take
it
to
ATF,
plus
call,
and
that's
it
assuming
know
what
the
post
is
to
that
right.
Of
course,
then
we
can
just
reclassify
any
of
that
as.
S
J
Other
words,
if
you're
saying
yes,
so,
in
other
words,
there
was
a
in
effort.
If
you
remember
last
year,
we're
making
IP
before
historic.
All
right
where
I
can
you
say,
exists
another
version
of
IP.
It
doesn't
completely
replace
before
right
and
so
the
attention
there
was
saying.
Well,
we
really
don't
want
to
use
that
your
anymore,
like
you
might
say,
we
all
really
want
to
use
as
yet
be
version.
One
anymore,
I
mean.
Is
there
we
don't
really
want
to
replace
it?
We
don't
want
to
update
it,
wouldn't
want
to
change
it.
J
J
Go
so
the
process
is,
there
is
something
called
the
status
change
document
which
theoretically
I
write,
but
that
means
that
you
write
explaining
the
that's
one
thing
I
can
delegate
there
wasn't
really
explaining
why
we're
doing
this.
So
if
it's
as
easy
as
saying
well,
you
know
no
one
really
uses
a
person
want
anymore.
That's
it,
you
know,
that's
one,
paragraph
justification,
I
put
a
data
tracker,
it
gets
last
call
and
that's
four
weeks.
J
That's
calling
me
that
change
that,
if
the
justification
is
is
bigger
or
if
there
are
exceptions
like
we
wanted
to
call
ASM
historic,
but
only
for
these
cases
or
I,
don't
know
something
really
weird
like
that.
Maybe
now
we
need
an
actual
draft
that
gets
discussed
and
process
through
the
whole
process
and
everything
else
where
it
talks
about.
Here
are
the
conditions
where
you
really
shouldn't
use
this
here
are
the
ones
where
you
might
want
to
use
it
here.
S
So
that
process
a
little
bit
more
complex.
So
if,
for
example,
the
the
most
difficult
part
of
the
whole
scheme,
I
think
is
the
one
one
one
two
all
standard
for
ipv4,
ASM
I,
think
the
ASM
part
we
I
would
love
to
see
kept
for
the
internet
Senate,
but
not
implying.
You
know
the
I
gene
pv-1
so
breath
the
document.
O
J
J
S
Like
if
I
still
want
to
have
a
sm
as
a
full
standard
right,
because
I
think
it's
valuable
inter-domain
at
least
spider
right-
I
don't
see
that
I
ever
want
that
to
go
away.
Then
I
would
make
the
new
document,
which
is
just
the
ASM
stuff
and
then
would
call
the
other
one
obsolete
right,
because
it's
superseded
and
the
super
in
in
the
superseding.
There
is
basically
no
IGMP
v1
anymore
right
right.
So
that's
the.
J
Answer
to
andrew
now,
if
someone
and
I've
never
seen
this
happen,
but
if
someone
actually
did
come
in
with
a
bit,
they
wanted
to
still
work
on
something
that
is
historic.
Well,
first,
you
guys
would
have
to
discuss
that
and
I'm
sure
people
will
get
up
and
say
no.
We
can't
do
that
because
it's
historic
and
it
might
not
get
adopted.
It
might
might
only
get
one
hand
up,
not
the
threshold
to
special
to
heads
by
the
way
we
need
to
do
something
about
two
hands
right:
I
have.
E
J
J
J
J
S
Stick
was
explaining
already
in
the
dry
run
on
an
Bondi
that
one
of
the
things
we
may
want
to
need
to
do
is
to
revisit
if
there
is
really
crappy
stuff
that
never
has
been
implemented
or
have
been
used.
So
I
think
that
seems
to
be
the
exclude
list
of
sources
that
we
don't
want
to
get
in
a
sm
mode
that
is
in
implementations,
I
know
it,
but
nobody
ever
used
it
in
application.
So
it's
an
underutilized
feature.
S
So
maybe
if
we
do
a
ref
of
IGMP,
v3
and
ml
db2,
where
we
cut
out
the
things
that
we
haven't
been
using,
which
is
the
exclude
list
and
we
kind
of
superseded
both
existing
IGMP
v3
ml
db2
2-fold
standard
kind
of
similar,
how
the
latest
revision
of
pim
was
done
where
also
stuff
was
cut
out,
and
that
should
also
supersede
then
50
790
right.
So
that
seems
to
be
to
me
reasonably
logical
and
simple.
If
that's
a
conclusion
right,
yeah
and
that's
pretty
much
know
that
was
pretty
much
kind
of
just.
You
know.