►
From YouTube: IETF103-PIM-20181106-1350
Description
PIM meeting session at IETF103
2018/11/06 1350
https://datatracker.ietf.org/meeting/103/proceedings/
A
C
D
A
C
A
E
D
A
So
quickly
gonna
go
through
them
working
upstairs.
You
have
a
pingyang
draft.
That
is
it
obviously
edit
or
skew.
It
should
be
an
RFC
in
a
few
weeks.
I
would
think
I'm,
not
sure
if
it
work
is
waiting
for
any
other
young
documents.
Is
it's
an
acute
there's.
A
G&P
MLD
yang
draft
that
has
been
revised
a
bit
based
on
young
doctor
input,
and
so
on
must
short
expert
review
is
now.
Is
that
another
young
doctor
or.
C
A
Overall,
with
that
is
some
design
issues
and
how
it
fits
into
a
routing
models
in
general,
all
right
and
then
there's
an
MSD
P
young
draft
and
that
past
working
group
last
call
and
we
are
almost
ready
to
go
on.
The
only
slight
question
is
some
people
are
saying
that
maybe
it
should
be
an
experimental
document,
because
MSTP
itself
is
experimental.
A
C
Heidi
again,
so
we
had
some
questions
to
the
aug
about
this,
because
we've
been
getting
yang
models
for
Bachelorette
for
protocols
and
I
think
basically,
the
conclusion
there
was
no,
it
doesn't
have
to
be
experimental.
It
can
be
experimental
if
the
work
wants
it
to
be
experimental,
but
you
know.
Presumably
this
is
something
that
people
are
going
to
go,
implement
and
use,
and
you
know
etc,
and
it's
useful
for
interoperability
and
everything
else
so
Sam's
track
is
okay.
If
that's
what
the
working
was
right.
So
it's
really
up
to
you.
Yeah.
A
So
I
don't
think
anyone
really
had
an
issue
with
it
being
Steiners
track.
I
think
it
was
more
like
a
circular
like
a
question
that
was
raised,
but
does
anyone
in
the
room
have
any
thoughts
on
whether
it
should
be
experimental
or
not?
This
right?
Now
it's
it's
supposed
to
be
proposed
standard,
and
unless
anyone
has
any
issues
with
that
I
guess
we
won't
do
that.
A
D
So
this
is
a
draft
that
sticks
on
so
I'll
speak
to
this.
It
didn't
have
a
whole
lot
of
response,
but
it
did
have
a
response
to
the
working
group.
Last
call
Jake
made
a
few
comments
and
he's
comfortable
with
this
progressing
as
long
as
those
concerns
are
addressed.
So
as
long
as
the
author's
addressed
Jake's
comments,
I
think
we
are
good
to
go
with
sending
this
off
to
Alvaro
and
the
game
unless
anybody
else
has
any
concerns
about
this
draft.
F
D
A
All
right
there's
also
a
G&P
Emily
sleeping
draught,
and
that's
that's
almost
done
some
slides
from
that
later.
We
had
I
working
with
last
call
on
this
up
you
up
here
for
prefix
or
ipv6
next
hop.
There
were
several
comments
that
were
raised
and
the
authors
are
planning
to
to
post
the
universe
and
trying
to
address
those
comments.
A
That
draft
hasn't
been
worked
on
in
a
while,
so
hoping
that
the
offers
will
post
the
new
works
no
that
later,
otherwise
we
have
few
drafts
that
just
got
adopted
since
the
last
ITF.
So
it's
not
changes
since
the
previous
verses.
They
just
got
resubmitted
as
working
group
documents,
but
the
offers
would
be
happy
to
receive
comments
and
try
to
come
up
with
some
new
version
for
the
PFD
document.
A
The
offer
in
particular
wanted
us
to
try
to
get
input
from
the
offers
or
the
different
D,
our
improvement
or
the
BD
our
drafts
and
so
on
to
see
how
this
can
be
used
for
the
re-election
all
right.
The
last
thing
I
want
to
mention
is
implementation
requirements,
so
the
different
routing
area,
working
groups
all
have
different
requirements
for
for
drafts
or
RFC's,
and
we
haven't
really
talked
much
about
it
in
this
working
group.
I
feel
like
our
requirement
is
basically
no
requirement,
which
is
the
bottom
one
they're
curious.
A
If
people
feel
like
we
should
do
something
more
than
that.
One
thing
we
did
for
one
Java
piece
was
to
have
a
like
an
implementation
status
section,
that's
something
pretty
simple:
we
could
do
personally,
I'm,
not
sure.
If
what
do
you
know
have
any
formal
requirements
for
implementations,
but
at
least
knowing
that
implementations
exist
could
be
useful,
but
they
have
people
have
any
thoughts
on
this.
B
D
A
But
it's
quick
so
basically
after
this
was
submitted
to
the
SG,
it
went
to
another
young
doctor
review
and
there
are
lots
of
comments
and
multiple
e-mails
back
and
forth
from
malicious
to
the
draft.
So
this
is
this
slide
basically
shows
what
God's
changed
don't
want
to
spend
much
time
on.
This
is
better
if
people
can
go
and
look
at
it
if
they're
interested,
but
as
you
can
see,
there
were
quite
a
few
changes
to
the
draft.
A
A
I
Okay,
so
first
our
inference
of
the
motivation
of
the
draft.
So
basically,
there
are
several
situations
or
scenarios
in
current
networks
based
on
the
spins
from
the
operators
that
we
have
in
the
course
of
the
draft
that
require
new
solutions,
because
with
current
solution
cannot
be
properly
solve
and
those
scenarios
are
documented
in
the
draft.
But
some
posts
are
the
one
that
are
listed
on
the
slide.
I
The
first
one
multi-has
wholesale
offer
for
all
services
is
basically
when
you
have
more
than
one
operator
incoming
operator
and
another
service
provided
that
are
offering
multi
COS
services,
and
you
want
to
have
the
possibility
of
choosing
from
which
one
you
get
the
content.
There
are
senators
who
work
for
multicast
resiliency,
where
you
may
have
more
than
one
of
provider
and
you
wanna
be
able
to
switch.
If
in
case
there
is
a
failure,
you
may
have
a
scenarios
for
load
balancing
which,
yes,
for
sake
of
not
overloading
a
particular
segment
of
the
network.
I
You
wanna
have
multiple
choices:
network
merging,
multicast
emigration.
There
are
several
scenarios
in
the
draft,
so
current
solutions
or
the
the
way
this
could
be
solved
would
be
by
using
PIM
into
him,
but
that
has
limited
deployment
in
current
networks
and
it's
also
a
bit
complex.
So
that's
why
I
deem
PML
be
proxy
with
multiple
absolute
interfaces.
Maybe
a
simple
solution
for
this,
based
on
on
the
fact
that
the
proxies
are
widely
deployed
today
and-
and
you
will
avoid
some
complexities-
so
that's
part
of
the
motivation.
I
I
It
was
because
of
sorry
mobility,
related
requirements
not
trigger
going
to
this
working
group,
because
the
multimode
was
close,
but
then
we
also
realized
that
there
was
not
only
mobility
rated
requirements,
but
also
all
the
requirements
related
to
fixed
networks
and
all
the
requirements
for
both
mobile
and
fixed
networks
are
the
ones
that
are
called
all
the
scenarios,
the
ones
that
are
documented
in
the
Libre
next
one
please.
So
the
goal
of
the
draft
is
to
basically
documentos
a
scenario
where
we
need
some
additional
solutions.
I
This
support
for
multiple
asset
interfaces
that
was
already
kind
of
discussed
in
the
making
in
the
magma
working
group
some
years
ago,
but
at
that
time
was
designed
not
to
go
for
that
because
of
the
complexity
that
that
will
add
to
support
like
multi-home
kind
of
a
scenarios
with
ml
DMP
proxies.
But
the
fire
is
that
relative
to
data,
we
have
this
so
we
had.
We
don't
have
the
need
for,
for
this
kind
of
extension,
an
in
addition
to
describing
redefined.
I
The
scenarios
is
also
to
define
the
requirements
that
those
scenarios
pose
for
a
potential
solution
on
multi
policy
interfaces
for
IGMP
MLD
proxies,
and
then
these
requirements
should
help
defining
the
solution.
So
we
have
clear
documentation
of
what
a
requirement
a
potential
solution
may
may
need
to
to
provide
next
one.
Please.
I
Working
group
where
we
were
dealing
with
mobility,
but
then
the
multimode
working
was
close
and
it
was
meant
to
be
the
best
placeholder
or
base
form
for
this
kind
of
work.
Then
we
have,
we
have
been
evolving
the
draft,
including
additional
content,
security,
new
pekin
ETA
scenarios
and
then
in
beginning
of
2018
this
year
we
got
some
comments
from
our
ad
and
we
took
a
while
to
to
to
address
those
comments.
I
applaud
you
for
that,
but
then
we
bring
it
into
a
discussion
and
we
were
doing
some
changes
that
are
summarized
next.
I
So
from
the
a
B.
We
got
comments,
for
example
about
the
the
requirements
being
relatively
simple,
and
it's
true
that
they
are
simple.
But
it's
also
true
that
there
is
a
need
for
those
simple
requirements
to
be
addressed,
because
there
is
no
current
technology
in
operational
networks
that
can
be
used.
There
is
no
other
solution,
idea
that
can
be
applied
to
solve
the
requirement
that
we
documented
in
the
in
the
draft.
There
were
some
comments
also
on
some
requirements,
being
generic
and
pretty
obvious
and
again
is
true
that
they
are
kind
of
straightforward.
I
I
There
was
a
comment
about
some
scenarios,
not
in
a
specific
requirements
that
recur
the
requirement
not
been
very
specific
and,
for
example,
on
the
fast
reaching
about
interfaces,
and
we
have
added,
in
the
last
version
of
the
document,
pointers
to
video
interaction,
kind
of
requirements
that
can
be
applied
for
this
particular
phase,
switching
requirement
and
the
same
for
the
service
mutilation.
So
we
have
added
additional
details
based
on
the
on
the
a
B
review.
I
So
next
steps
is
to
come
up
with
a
new
version
where
we
will
be
having
some
additional
operational
details
that
a
B
also
requested
and
that
we
even
have
time
to
put
in
the
cr7
version
before
the
submission
deadline.
But
those
are
easy
to
add
because
we
have
that
into.
Actually
we
have
some
text
in
the
discussion
on
the
mini
list
with
ad,
then
something
that
will
like
to
have
for
this
session
is
to
understand.
I
If
there
is
any
other
aspect
that
you
believe,
the
working
group
believes
that
needs
to
be
added
into
the
into
the
draft
cover
by
the
requirements
raft,
and
then
we
believe
that
the
it's
time
for
the
solutions
draft
to
take
over
and
to
basically
work
on
the
solution
meeting
the
requirements
that
we
have
in
the
document.
There
is
already
one
that
is
the
one
is
mentioned
in
the
in
the
slide.
But
I
don't
know,
if
maybe
other
solutions
that
can
be
also
proposed
by.
I
G
Hey
J,
holin
I
had
to
go
back
and
look
at
ITF
94
or
some
of
the
discussion
about
the
requirements
document
took
place
because,
when
I
read
this
I
didn't
understand
why
it's
useful
so
I
guess
what
I'm
wondering
is.
Would
it
make
sense
to
do
these
SI
cluster
or
is
that
the
plan,
or
is
the
plan
to
make
the
requirements
a
released?
G
Rfc,
that's
informational
and
then
later
work
on
solutions
like
I
get
that
it's
useful
to
kind
of
do,
especially
if
there's
multiple
solutions
that
address
subsets
that
the
requirements
it
makes
sense
to
separate
out
the
requirements
document,
but
I'm,
not
sure
it
makes
sense
to
publish
a
requirements
document
without
any
solutions
for
an
indeterminate
time.
At
least
I
would
find
it
confusing
it.
If
encountering
this
in
the
wild
yeah.
D
A
A
G
G
A
A
G
G
A
Think
maybe
what
you
could
do
is
one
thing.
It's
a
you
know.
Next
steps
try
to
include
the
requirements
a
little
bit
otherwise
in
white
people
well
read
about
the
solution
and
see
whether
they're
happy
with
the
proposed
solution
or
if
they
want
to
you,
know,
think
there's
other
ways
to
solving
a
problem.
J
In
my
opinion,
I
think
the
clarifying
the
requirement
is
really
important,
even
though
we
will
finally
need
to
go,
buy
the
solution
documentation
because,
for
example,
let's
imagine
that
for
me,
I
could
I.
Imagine
that
the
multiple
interface
about
foraging
family
proxy
may
become
something
like
LFC
4605
beasts,
for
example.
This
is
because
this
is
very
basic
functionality
that
must
be
supported
by
new
EMP
emily
proxy.
So
this
idea
on
obviously
4605
beasts
is
a
may,
be
a
final
goal
as
a
solution
to
support
multiple
interface.
J
But
someone
may
think
that
why
we
need
to
revise
the
proposal
standard,
the
documentation
which
is
out
of
C
4605
and
just
to
support
multiple
interface.
Why?
How
many?
What
kind
of
use
cases
exist
and
how
it's
important?
Maybe
such
kind
of
clarification
is
really
needed
to
move
the
next
activity
forth
to
provide
a
new
standard
documentation,
which
is
a
4605
beasts.
J
J
Actually,
I'm
also
this
individual
solution
draft,
but
still
there
are
lots
of
open
shoes,
and
today,
I
don't
have
time
to
present
what
kind
of
a
point
you
exist,
but
just
to
support
multiple
interface
tell
a
lot
of
things
we
need
to
address,
and
sometimes
we
may
need
to
add
a
new
I
J,
apparently
message
or
signaling,
and
this
must
be
very
heavy
task
or
if
we
don't
have
any
special
message
to
decide
a
multiple
upstream
interface,
then
how
we
can
decide
which
are
screaming
interface
is
best
or
better
or
what
kind
of
a
scenario
for
the
scenario
or
some
scenario
so
well
just
to
support
us
so
I
think
that's
why
magma
just
ignore
at
that
time
to
support
multiple
interfaces,
because
it's
really,
if
it
does,
even
though
just
to
add
one
single
or
more
upstream
interface,
so
I
don't
want
to
start
actually
I.
A
Of
discussion,
do
you
feel
that
the
existing
requirements
drafts
include
enough
detail
for
people
to
understand
these
issues?
I,
don't
know
I,
don't
know,
but
yeah
I,
hope
so
yeah,
because
these,
if
possible,
it
could
be
nice
to.
Maybe
you
have
some
more
technical
detail
in
the
requirements
draft
that
can
clarify
why
this
is
a
difficult
problem
or
what
solutions
need
to
you
know
make
solve
or
take
care
of,
maybe
just
just
think
about
it.
K
A
I
C
Without
a
running
ad,
so
as
the
presentation
started,
this
was
motivated
because
I
made
some
comments.
I
made
some
comments
because
this
already
past
Les
Paul,
and
so
it
surprised
me
very
much
that
only
two
people
raised
her
hand.
Then
they
had
actually
read
the
draft,
even
though
we
don't
have
I
would
hope
that
so
the
reason
for
doing
this
presentation
today
was
this
is
just
requirements.
C
There
is
a
solution
that
had
been
worked
on
many
many
years
ago,
so
my
intent
was
to
be
able,
if
we're
going,
to
go
forward
with
the
publication
process
to
justify
to
the
ASG
that
we're
publishing
a
very
light
requirements
document,
but
that
at
least
the
working
group
is
interested
in
working
on
solutions.
But
no
one
raised
your
hand
only
jake
volunteer
to
maybe
test
something
there.
So
what
I
think
we
should
do
going
forward?
Is
this
I
don't
think
I
can
just
find
the
publication
in
the
ITF
string.
C
We
can
do
one
of
two
things:
I'm
going
to
return
the
document
to
the
working
group.
If
you
want
to
go
forward
and
publish
it
through
the
independent
submission
tract
when
it
comes
back
to
review
the
a
is
coz
I
want
the
poster
I
want
to
post
it.
You
know,
make
it
go
forward,
so
it
can
be
published
as
an
RFC.
It
won't
be
an
ITF
document.
C
A
So
so
maybe
one
way
forward
and
would
be
to
revise
the
document
but
not
go
for
publication
yet
and
then
we
start
working
on
the
solution
and
as
they
work
on
the
solution
we
can
see
you
know
if
we
find
out
the
requirements.
It's
be
a
bit
further,
but
once
we
have
a
solution
that
we
are
happy
with,
then
they
can
hopefully
ask
for
publication.
Then
they
can
point
to
the
solution.
A
C
Thanks
again,
go
back
to
one
point
that
Jake
made
before
that
and
I
agree
with
him
that
if
there's
one
solution
it
seems
obvious
and
nice
so
include
the
requirements
in
the
justification
of
that
solution
in
the
same
draft.
You
know
that
way.
When
people
see
the
solution,
they
don't
have
to
go.
Look
to
see
why
this
was
made
or
where
the
requirements
are
or
whether
they
see
a
requirement
that
I
have
to
go.
Look
for
the
solution
is,
but
they
see
everything
together.
C
A
A
A
L
L
L
L
Next,
after
you
updating
information
to,
we
move
a
certain
sales,
another
smoking
instance,
if
you
specify
oh,
this
is
a
hierarchy
if
you
specified
any
age
I'm
his
new
instance,
and
there
is
the
list
of
certain
states
to
the
universes.
L
And
now
we
have
advised
almost
all
the
comments
from
your
melter,
except
only
one.
This
is
a
little
problem,
which
name
is
better.
We
define
our
PC
called
its
name
with
clear-eyed
youngest
moving
rules,
but
by
the
young
daughter
prefer
three
for
another
name.
I
think
that
it
should
be
called
clear
idea
is
moving
caches
at
last
the
way
or
chilled
agreement
to
ask
the
pin
rule,
which
one
is
better.
L
Men
step
now,
I
think,
is
ready
for
it's
almost
a
down,
so
we
would
like
to
apply
for
walk
off.
That's
called
and
more
comments
which
one
is
paid.
Her
sing.
L
L
L
A
L
L
A
A
H
H
A
L
Okay-
and
there
is
another
new
young
model
for
large
MP
and
I
married
epoxy,
and
this
is
a
neutral
mode,
individual
topped
and
the
first
portion
for
presentation
and
it's
12
and
the
effort
is
from
one
cast
young
son
team
and
I
memorize
from
Everson
motel.
While
we
are
in
for
this
is
visitor
structure
and
to
configure
the
AGM
Qian
MLT
policy.
We
augment
the
interface,
and
this
is
a
hierarchy
under
the
edge
MP
policy
is
we
can
innovate
and
some
other
I
feel
if
you
rather
require
route.
L
L
We're
writing
this
new
model.
We
meet
a
unsolved
problem:
nice
somewhere
nurse
for
another
Hawaiian
to
infer
configure
the
agency
policy
on
a
stream
interface
but
and
some
wonderful
novel
Cisco
configure
the
IGMP
policy
on
the
don'ts
women
who
face
a
hostile
eyes,
and
this
is
the
problem
and
as
I
know,
when
we
configure
the
I'm
I'm
I'm
out
the
HMP
I'm
out
the
policy
on
Cisco
device
and
their
ways,
we
should
also
configure
the
IGMP
UDR
interface
in
Cisco,
but,
as
I
know,
other
Werner's
doesn't
have
a
UDL
interface
unit.
L
M
M
L
L
M
Again,
different
platforms
have
different
ways
on
how
to
do
it.
All
I'm
saying
is:
you
might
have
mode
of
operations
where,
on
the
upstream
interface,
you're
running
IGP,
proxying
and
or
a
pin,
and
so
the
question
is:
do
we
have
a
way
across
the
models
that
will
come
up
to
express
that
right?
Do
we
have
in
the
existing
pin
model,
for
example
the
opportunity
to
say
disable
him
on
this
interface,
which
you
know
normally
we've?
M
Never
you
know
when
we
implemented
by
the
approximant
before
didn't,
have
an
option
to
disable
pim
on
the
interface,
but
still
do
the
same
functionality
as
far
as
aggregating
the
stage
sending
out
the
status,
8,
IG,
MP,
memberships
right.
So
all
I'm
saying
is
be
very
careful.
If
we
assume
that
we
get,
you
know,
representations
of
doing
what
the
router
needs
to
do
with
only
thinking
about
IP
proxying,
completely
ignoring
the
impact
on
him.
L
A
Yeah
I
mean
we
don't
need
to
resolve
all
the
issues,
but
I
would
like
at
least
several
people
to
read
the
documents.
Okay-
and
you
know
like
like
and
basically
support
the
document
so
I
think
for
now
I
mean
we
should
just
say
you
know
that
people
need
to
need
to
read.
The
document
provide
comments
on
the
mailing
list
and
yeah
I
try
to
improve
the
documents
for
the
next
ITF,
but
yeah.
A
N
D
O
O
Thank
Greg
mercy
very
much
for
his
careful
review
and
suggest
suggestion,
and
the
modification
is
simply
but
there's
a
new
job
from
McManus
a
provider
new
solution
for
dr
improvement.
So
let
me
let
us
review
the
content
of
these
drops
quickly.
So,
let's
see
the
problem,
that's
the
e
strapped
one
two!
So,
according
to
FC
7761,
we
know
that
when
dr
changes,
a
new
dia
with
a
higher
highest
priority
will
replace
existed.
The
at
will
be
the
new
dia,
but
there's
some
time
will
be
cost
to
to
edward,
adopt
the
change.
O
So
some
application,
such
as
real
time
applications
like
a
TV
network
making,
will
be
influenced
in
fluentd
and
if
we
use
the
default
all
the
time,
the
maxim
recovered
her,
maybe
105
seconds,
so
the
networker
will
be
influenced
and
as
a
what
has
the
flow
will
be.
Influential
and
I
see
it's
in
this
network.
O
We
know
that
the
dr
has
been
deleted
and
the
user
net
he
means
share
the
media
network
and
when
a
newcomer
come
seeing
and
the
newcomer
has
high
her
their
priority
than
the
existed
yeah,
the
newcomer
will
replace
the
dr,
so
they
are
still
some
interrupt
will
occur
so
from
this
situation.
We
want
to
solve
this
problem,
so
we
think
that
that
there
should
be
stable,
even
if
the
new
router
has
a
higher
priority
and
the
ones
the
old
dr
is
done.
O
Let's
see
a
solution,
the
dr
PDR
solution
is
bored
from
OSPF
or
protocol
defining
FC
23:28,
and
but
we
made
some
minor
change.
Yeah
in
this
solution.
Here
is
the
router
which
has
the
highest
priority,
but
once
thea
is
elected,
new
rotor,
which
has
a
higher
proud,
he
cannot
replace
the
exist
that
they
are
immediately
and
the
PDA
is
a
rotor
which
has
the
highest
priority.
Acceptance,
I
existed
yeah
and
the
PDR
will
monitor
the
existed
at
the
a
by
PFD
other
function.
O
O
So
let's
see
the
figure
to
describe
the
solution.
Well,
then,
you
wrote
her,
which
has
the
higher
price
they
are.
Priority
comes
in.
The
new
rotor
will
stand
in
the
hollow
cavity
that
Thea
and
the
media
are
all
set
to
know.
After
the
new
router
receives
hello,
packet
of
roms
existed
yeah.
It
will
know
that,
as
there
is
leaving
the
are
in
sir
network,
so
it
will
follow
the
dia
and
the
new
rotor
will
not
replace
exist.
O
If
all
the
rotor
Zinser
network
finds
that
the
new
rotor
has
higher
priorities
than
the
exists,
the
pedia,
so
they
will
treat
the
newcomer
is
a
nupedia
not
that
yeah
when
a
pedia
is
elected.
So
we
know
that
the
PDR
were
imported,
multicast
flow
from
upstream
and
routers,
but
PDR
will
not
forward
as
a
multicast
flow,
and
he
OTR
is
unreachable.
O
O
Let's
see
the
compare
compatibility
when
new
router,
which
has
no
dia
improvement
capability,
comes
in
the
new
rotor
will
stand
as
a
hollow
packet
with
it's
yard
priority.
So
after
the
new
router
receives
help
from
the
existed
yeah,
it
compares
the
our
priority
if
the
new
rotor
elects
itself
via
it
ascends.
How
imperative
is
di
cell
to
itself
so
and
the
rotor
see
in
the
network
will
elect
her
the
new
dia
according
to
the
di
election
algorithm,
it's
a
specification
of
the
election
algorithm
step.
One.
O
We
collected
the
candidates
of
media
except
trotters
who
declare
themselves
as
they
are
and
step
two.
We
select
the
one
who
has
the
highest
priority
to
be
media
source
or
it
has
a
high
break
for
it
and
step
three
and
we
correct
the
candidates
of
PR.
So
we
collected
the
rotors
a
hooter
cragger
declare
themselves
themselves
SDR
and
step
four.
We
selected
one
who
has
the
highest
priority
to
pedia
from
the
they
are
set
if
step
file.
O
D
Okay,
so
you
mentioned
monk
Amana
made
some
comments
right,
yeah
yeah,
so
the
thing
that
this
has
taken
a
while
this
draft
seems
like
it
would
be
ready
for
robust
call,
although
less
IETF
monk
I'm
on
a
presented,
a
draft
that
would
this
be
considered
competing
or
would
it
be
a
complement
or
what
would
you
know
from
Cisco?
So.
F
I
won't
call
it
as
a
competing
I
had
just
one
more
way
of
selecting
the
media
so
rather
than
using
new
hello
options.
Why
can't
we
use
existing
hello
itself
so
that
that's
what
my
point
was
and
in
fact,
I
think
in
last
IETF
few
few
of
the
members
mentioned
that
that
can
be
as
a
informational
that,
because
this
draft
talks
about
having
BDR
pulling
the
traffic
dropping
it
unless
you
or
the
dr,
so
that
talks
the
different
mechanism
end-to-end
mechanism
I
was
just
concerned
about.
F
Can
we
do
dr
eyelets
and
without
even
having
extra
hellos,
because
today,
when
we
are
sending
hellos,
we
already
have
the
list
of
team
neighbors.
So
why
can't
the
same
algorithm
can
be
run
twice.
That
one
is
the
best
best.
One
is
the
dr.
The
second
best
is
b
dr
by
default.
So
that
was
the
my
point,
so
I
don't
see
it
as
a
competing
draft
to
this.
It's
just
alternate
way.
Yes,.
O
D
A
D
A
Great,
if
you
can
comment
on
it,
but
at
least
my
understanding
is
that
the
main
difference
between
the
two
drafts
is
that
your
draft
supports
like
a
sticky
mechanism,
where
you
don't
immediately,
go
back
to
the
new.
If
the
dr
goes
down
and
comes
back
up
again,
you
don't
switch
back
to
the
old
year.
I
think,
but
apart
from
that,
I
think
you
know
the
working
group
needs
to
see.
Do
they
want
this
extra?
These
extra
features
that
were
drafted
support.
What
do
they
think
that
the
the
other,
maybe
more
basic
solution,
is
sufficient
sheffield.
P
Round
juniper,
I
sorry
I
haven't
ready,
were
the
new
draft
yet,
but
it
seems
that
the
new
graph
is
just
used
you
using
just
electing
a
Jinnah
PDR
without
without
any
new
hello
messages,
and
it
does
not
touch
upon
other
things
right.
If
that
is
the
case,
could
that
then
the
the
new
solution,
which
only
it,
which
is
only
about
the
period
action,
be
folded
into
the
existing
draft.
P
K
O
F
So
I
think
if
this
has
been
already
implemented
and
it's
out
there
in
the
field,
so
maybe
the
other
procedure
is
kind
of
just
informational-
that
if
someone
wants
to
use
without
new
hello
Upson
in
future,
they
can
use
it
so
that
doesn't
change
any
protocol
or
that
is
not
going
to
break
the
working
of
this
draft,
so
both
of
them
can
coexist
together.
That's
what
my
point
is:
are
my
feelings.
A
G
A
Celebi
will
check
on
the
list
if,
if
no
just
asked,
if
there's
any
objections
to
our
last
call
on
the
list
in
a
skit,
now,
let's
get
some
hands
on
who
thinks
it's
ready
for
it.
Okay,
who
thinks
it's
ready
for
applause,
Scott,
okay
for
people
all
the
people
have
read,
it
I
think
anyone
against
think
it's
not
ready
for
last
call.
A
There
is
a
draft
for
how
to
send,
pin
joints
over
beer,
but
they
don't
really
have
a
soul,
at
least
in
my
opinion,
they
don't
have
a
good
solution
for
to
decide
which,
which
ingress
beer
out
there
to
actually
send
up
and
join
to
each
beer
out
there
is
closest
to
the
source.
So
what
I'm
proposing
this
draft
is
that
when
you
receive
an
pfm
message,
just
contains
the
source
group
and
whole
time.
A
The
ingress
beer
after
adds
its
own,
be
for
ID
and
sub
domain
and
stuff
and
metric
to
the
source,
and
then
the
egress
B
routers
can
see
which
ingress
router
is
closest
to
the
source.
But
if
you
have
any
ideas
of
comments
or
thoughts
on
this
great,
if
you
can
come
to
beer
tomorrow
or
just
send
me
comments.
A
A
Yeah
I
only
have
a
couple
of
quick
slides
here,
but
but
basically
we
had
some
brief
discussion.
Last
night,
EF
few
people
at
least
think
it's
maybe
time
to
progress
IGMP
with
three
and
then
believe
it
too
on
the
understand
racetrack,
they
are
pretty
mature
documents.
They
have
been
around
more
than
14
years.
There's
lots
of
implementations,
I,
believe
I,
believe
it's
supported
by
almost
all
houses.
Today,
all
modern
operating
systems
and
maybe
most
switches
and
routers
deployed
I.
A
Could
they
run
it
just
to
hear
what
you
think
and
I
think
many
I
was
want
to
tell
people
deploying
multicast
in
general
that
they
should
try
to
use
these
protocols
one
of
the
reasons
in
support
SSM
and
we
might
want
to
deprecated
I
can
pv-1
worse
among
perhaps
worse
than
to
is
proposed
standard.
If
you
think
they
really
should
deploy
out
University.
Maybe
we
should
progress
version
three,
so
it's
it's
clear
that
that's
the
intended
document
to
sort
of
the
best
protocol
to
use.
A
A
If
they
want
to
do
this,
we
may
have
to
do
a
similar
process
that
they
did
for
him
when
they
were
vice
him
to
internet
standard,
which
would
be
doing
implementation
reports
stuff
to
find
out
what
pieces
have
been
implemented.
What
have
not
been
implemented,
not
been
deployed
or
any
interoperability
issues,
and
so
other
people
found
all.
M
Do
we
foresee
need
for
for
for
the
ref,
and
maybe
the
the
main
thing,
of
course,
is
that
the
the
whole
exclude
sources
in
a
non-empty
list
of
sources
to
be
excluded.
Right,
I'd
be
surprised
if
that's
actually
being
used
by
application
right,
so
I'm
pretty
sure
that
all
the
implementations
have
it,
but
do.
Does
that
really
mean
we
know.
You
know
whether
how
well
it
works.
If
you
know
we
don't
have
any
applications
that
are
using
it.
A
So
this
what
we
did
for
PIM-
and
we
could
do
here-
is
that
we
had
a
group
of
volunteers
working
together
coming
up
with
some
with
a
sorry
SEPA
story
for
operators
separate
for
implementers
that
the
a
me
you
know
we
did
this
in
in
the
working
group
decided
on
when
we
came
to
agreement
on
what
the
service
should
be,
and
basically
it
sent
this
out
everywhere.
We
could
and
we
had
someone
receiving
them
anonymizing
the
responses
and
me
about
an
hour
see
the
base
of
that
which
is
RFC,
1763
I
recommend
looking
at
that.
A
A
Yeah,
whoever
might
be
using
this,
it's
can
be
hard
to
reach
out
to
the
right
or
reach
the
right
people,
but
you
kind
of
want
to
reach
as
many
different
people
as
possible
and
find
out
what
are
they
actually
using
and
then
it's
up
to
you
to
to
us
to
find
out
you
know:
do
you
think
this
is
you
sufficient
has
been
tested
sufficiently
or
not
being
used
at
all?
Should
we
take
it
out
or
not.
M
M
C
Go
look
up
whatever
the
I
think
it's
be
325,
which
is
the
standard
process
and
if
I
remember
last
time,
I
read
it.
It
talks
about
the
fact
that
to
move
to
internet
standard,
yes,
we
want
deployment,
ations
and
appointments
and
no
rata
and
all
the
stuff,
but
I
think
it
said
that
it
is
not
a
requirement
to
have
implementation
reports.
This
was
one
removed
in
the
center
of
our
season
and
I'm,
not
sure
if
it's
PCB,
25
I'm
pretty
sure
is,
but
it
said
of
all
those
RCS
it
started
with.
C
C
G
G
The
IGMP
downgrade
is
a
problem
when
you
have
traffic,
which
is
only
reachable
by
an
SSM
join
and
I've,
also
observed,
I.
Think
I'm
gonna
file
a
bug
report
with
Apple.
If
you
join
two
different
sources
on
the
same
group
with
the
same
group,
SSM
joint,
it
will
collapse
them
to
a
single
you
know
without
having
the
the
downgrade
from
v2
or
whatever
so.
A
A
G
A
G
F
A
D
When
we
did
this
with
PMA,
it
took
time
and
it
was
a
pretty
good
effort,
but
it
wasn't
too
bad
I
mean
there
was,
you
know,
you
paint
the
internet
to
list
and
get
opinions
from
them
and
get
them
to
fill
out
the
survey
and
it's
it
just.
It
takes
some
tireless
now.
We
did
the
same
thing
here,
something.
A
A
Them
and
if
you
want
to
do
that,
maybe
it
would
be
useful
to
have
some
kind
of
template
or
some
way
oh
intimate
or
specifying
this,
even
if
it's
just
on
a
wiki,
so
I
know.
Maybe
if
you
could
find
some
volunteers
that
more
or
less
could
break
down
the
this
back
into
like
individual
circle
like
parts
and
then
we
can
ask
each
of
the
vendors
each
of
those
parts
they
implemented.
Something
like
that
with
that
miessence.
A
G
A
D
Yes,
maybe
mm,
maybe
just
take
it
out
loud.
Maybe
what
we
do.
Stig
is
weeping
the
list
about
this,
but
we
stopped.
We
saw
the
six
and
said
okay,
so
we
can,
you
know,
form
a
little
design
team
and
just
make
a
plan
and
start
bringing
it
out
see.
People
really
want
to
do
this,
but
it
seems,
like
it's
people,
think
it's
a
good
idea.
P
A
A
I
D
J
Yeah,
this
is
a
potential
solution,
items
for
watch
through
interphase,
suppose
boy
I
shall
be
a
very
proxy,
and
this
is
history,
and
we
worked
for
that
one
as
well
as
requirement
definition
and
now
the
requirements
rough
is
becoming
a
working
draft
and
we
just
stopped
actually
stopped
the
working
for
this
solution
draft
because
we
thought
I
thought
that
it's
better
to
wait
for
finalizing
a
requirement
to
project
but
opening
to
the
eighties
comment.
Maybe
it's
better
to
revive
the
solution,
destroy
game.
So
actually
there
is
no
big
change
from
this
one.
J
So
this
is
a
requirement,
so
maybe
I
don't
need
to
Express
explaining
what
is
a
requirement,
and
so
this
is
a
situation
so
different
to
networks
or
to
make
it
to
novice.
Do
we
have
more
singer?
They
work,
but
path
can
be
double
or
triple,
and
there
is
a
potential
situation
that
the
proxy
attached
to
the
wired
and
Wi-Fi
wireless
networks
and
also.
J
J
Yes,
so
this
this
is
a
benefit,
so
the
purpose
of
supporting
in
a
modular
interface
for
load
apart,
distinct
purpose.
We
should
have
this
idea
or
we
should
have
a
mechanism
to
support
subscriber
base
top
stream
with
intersection
and
also
the
channel
based
upstream
direction
and
the
for
the
lobster
data
reception.
We
may
want
to
receive
a
multiple,
the
same
content
from
multiple
interface,
and
sometimes
we
may
want
to
have
a
backup
interface,
and
if
there
is
something
happens,
some
problem
happens,
then
click
or
take
over
to
the
backups
interface.
J
So
this
is
a
purpose
to
support
multiple
interface,
so
the
upstream
interface
configuration
actually
currently,
there
is
no
definite
solution
to
automatically
decide
which
II
or
what,
which
interface
should
be
used
to
receive
the
mark,
a
stream
or
channel.
So
at
this
moment,
we
something
like
us,
specify
the
configuration
syntax
so
subscribe,
others
purposes.
So
this
is
very
detail
also,
this
ok,
so
the
automatic
configuration
this
is
a
well
I.
J
J
So
this
is
something
like
a
hush
body
we
can
use.
So,
according
into
hash
values,
always
we
select
a
single
interface,
so
we
have
a
multiple
interface,
the
hash
bar.
You
select
the
single
interface,
but
this
is
something
like
a
static
configuration,
so
this
is
not
well
defined
to
support
the
multiple
upstream
interface
direction,
according
to
the
network
condition
or
some
policy
configuration
and
so
on.
J
Primary
message
call
will
cost
so
under
what
is
a
trigger
when
router
switch
to
the
secondly
upstream
interface
camera
time
I
is
not,
maybe
not
sufficient.
So
there
everything
is
a
open
question
Oh
issue,
so
we
need
to
provide
some
solution
to
support
multiple
upstream
interface,
for
example
the
proxy,
and
there
are
many
open
D
issues
and
especially
for
automatic
from
interface
configuration
or
selection.
J
So
maybe
this
is
really.
This
may
become
a
big
discussion.
They
require
somebody
enough
discussion
and
we
may
say
this
is
something
like
LSE
4635
beast,
but
I
don't
know.
We
should
replace
the
current
IGMP
MLD
proxies
specification,
which
is
RFC
4605,
but
if
the
working
will
decide
to
revise
the
specification,
maybe
this
is
also
idea.
G
Let's
check
the
Jake
Holland,
the
I
just
searched
the
draft.
I
don't
see
RPF
mentioned
like
if
some
of
the
upstream
interfaces
do
not
have
a
route
to
the
source
and
it's
a
known
source
like
is.
This
seems
like
an
obvious
addition
that
they
can
simplify
it
somewhat
in
practice.
Right
or
is
that
not
addressing
the
issue
at
all
like
it's?
J
Big
blocks
ebooks
behave
as
a
hostage
so
RFC
are
they
RTF
our
hip?
Ltf
support
doesn't
help
because
it's
just
a
host
so
host
doesn't
care
the
alpi
f,
so
single
interface
or
interface.
How
we
select
the
interface
so
currently
the,
for
example,
the
UNIX
box,
the.
If
we
have
a
two
or
let's
say
two
interface,
then
the
default
interface
is
just
sacred
according
to
the
lower
I
gave
us.
This
is
hostly
host
of
specification,
so
proxy
is
behave.
Me
behave
as
a
host,
so
this
is
a
problem.
G
Okay,
but
yes,
there
is
a
problem,
but
it
seems
like
specifying
that
where
you
have
a
more
specific
route
on
one
of
them,
which,
in
depending
on
the
on
the
network
right-
yes,
sometimes
you
have
multipath
to
a
global
club
but
fairly
frequently
I
find
that
I
have
a
a
private
network
as
well
and
I
know
that
my
source
is
down
that
Network,
but
you're
correct.
G
What
I
find
is
that
that
it
will
try
to
join
on
the
default
interface,
which
is
not
as
useful,
even
though
the
RPF
would
be
a
very
good
indication
that
my
source
is
in
the
in
the
network.
But
the
I
know
that
it's
inside,
if
we
specify
the
RPF,
is
a
good
way
when
available
to
choose
the
interface
for
what
I've
seen
it
solves.
Half
the
problems
but
for
you
know
again,
maybe
I'm
looking
at
a
different
problems
based
on
you.
But
that
seems
like
a
useful
addition.
M
Told
us
accurate
yes,
so
I'm,
even
trying
to
remember
there
for,
for
the
most
time
I.
Remember
there
weren't
any
you
know,
rules
and
the
products
that
I
know
they
were
doing.
Rpf
based
on
group
addresses
right,
but
always
only
on
the
source
addresses
in
the
forwarding
tables
I.
Think
in
the
recent
few
years
there
might
have
been
some
features
come
in,
but
vendor
specific
right,
I
haven't
seen
anything
in
the
idea
is
that
I
know
there's
versus
fiscal.
J
M
The
main
issue
here
to
me
seems
that
ultimately,
this
ends
up
in
the
forwarding
table
of
being
something
like
saying.
Okay,
incoming
interface
is
also
depending
on
the
group
address
right,
so
you
have
one
provider
I
mean
you
need
to
manage
it
somehow
by
ASM
group
addresses
right.
If
you
do
SSM,
you
can
simply
use
normal
RPF
say
you
send
out
the
IGMP
join
like
a
pin
joint
to
wherever
you
get
the
sauce
from
and
I.
M
Think
unicast
is
your
friend
you
don't
care
about
group
addresses
so
for
SSM,
I,
don't
know
what
else
we
would
need
to
do
other
than
saying,
and
that
would
be
an
update
to
60/40
six
or
five,
which
is
okay
for
it.
For
SSM,
you
simply
RPF
and
send
your
IGMP
membership
to
whatever
your
RPF
interfaces
for
the
source.
I
think
ASM,
I,
think
you're
going
to
manage
by
group
ranges
right.
This
provider
uses
this
ASM
group
range
that
provider
Evol.
M
Are
you
get
RPF
based
on
the
group
addresses
and
that's
a
concept
that
we
don't
have
and
you
know
if
we
want
to
introduce
it
would
be
a
lot
more
lovely
if
we
figure
out
that
that
we
start
doing
that
from
the
the
M
rib
basis
and
then
yeah,
whether
you're
doing
IGMP
or
even
doing
the
same
with
PIM
I.
Don't
care
right,
I
mean
but
doing
some
one-off.
That
is,
you
know
not
something
we
want
to
be
able
to
have
generic
forwarding
planes
for
is
a
yeah.
M
M
I'm
saying
whether
you're
doing
IGMP
signal
pins
thing
to
me
is
is
irrelevant.
The
first
question
is
the
policy
on
how
I
determine
different
apps
upstream
interface.
It
sounds
to
me
like
there's
a
case
wherein,
if
you
want
to
do
it
with
ASM,
which
you
know
I'm,
not
sure,
if
something
we
should
still
consider,
but
if
you
do
ASM
it
would
be
on
group
ranges.
We
don't
have
that
notion
in
the
forwarding
tables
when
we
are
thinking
about
which
interface
do
we
select
packets
from
right,
I.
J
May
not
understand
your
point,
but
but
okay,
they
say
so.
If
the
party
box
has
a
routing
table,
maybe
it's
possible,
but
how
about
is,
for
example,
the
subscriber
based
configuration,
for
example,
even
though
you
allowing
table
for
the
source
sector,
the
interface
a,
but
according
to
the
some
subscribers.
J
M
Think
the
the
way
Jake
brought
it
up
is
still
the
best
one
which
is
kind
of
how
do
we
think
about
this
in
terms
of
our
PF
selection
right
and
that's
where
I
was
coming
from,
that
I
was
expanding,
that
RPF
selection
based
not
on
only
the
source
indicated,
but
also
the
source
in
the
group
right.
So,
for
example,
that
a
particular
group
range
goes
to
this
one
interface
independent
of
the
source.
J
P
M
C
C
The
discussion
before
was
about
moving
IGMP
v3
to
interest
standard.
You
meant
only
the
main
document,
not
which
is
4604,
but
it
looks
like
when
magma
published
for
six
before
the
policy
to
foreign
forces
applied
together,
which
seems
to
be
but
I
didn't
know,
since
that
which
seems
to
be
the
attendant.
Maybe
both
those
two
specifications
went
together.
So
is
the
intention
we're
moving
to
internet
standard
to
move
just
4604
Oh,
both
good.
Q
Q
When
a
working
group
adoption
call
was
put
forward
and
then
finally,
there
was
a
an
ID
that
Jeffery
Zhang
and
a
bunch
of
other
people
put
together
that
kind
of
stated
clearly
what
their
concerns
were,
and
so
this
is
largely
a
response
to
that
draft
and,
to
some
degree
the
conversations
that
are
on
the
mailing
list
and
in
the
room,
and
so
we'll
start
like
to
start
I'm
not
going
to
read
these
in
detail.
They're
available
on
the
on
the
working
group
repository
for
the
meeting
I
will
say
that
I,
you
know
it
was
good.
Q
Q
It
is
not
a
data
plane
that
is
supported
in
any
of
the
silicon
that
we
currently
use
in
our
products.
It's
not
in
a
substantial
fraction
of
the
existing
field.
That
Hardware,
all
of
which
is,
you
know,
available
and
could
readily
and
in
fact,
in
large
degree
I
understand,
is
being
upgraded
for
a
segment
routing.
Q
Mld
ml
DP
is
cool,
but
it
does
require.
L
DP
is
a
signaling
protocol
and
it's
an
interesting
conversation.
If
you're
trying
to
run
a
network
with
segment
routing,
particularly
a
new
Greenfield
Network,
why
would
you
want
to
necessarily
turn
on
LD
P,
just
to
get
multicast
RSVP
point-to-multipoint,
similar
PIM,
etc?
Q
Et-Cetera
dimension
in
MO
SPF
was
very
helpful
in
terms
of
contextualizing
some
of
the
feedback
and
they
sort
of
point
out
802
dot
1aq
as
well,
because
it
also
provides
some
historical
precedent,
and
that
is
in
fact
something
that
we're
leaning
on
heavily
in
making
this
proposal
just
to
recapitulate
sorry
cap,
if
I
can
be
so
bold
I
tried
to
extract
from
the
fairly
extensive
draft
that
Jeffrey
put
forward
with
his
colleagues.
A
few
points
from
the
summary
beer
is
the
best
choice.
Q
Q
Q
There
is
no
upgrade
potential
on
existing
s
are
capable
systems
other
than
the
ones
that
have
you
know
that
we've
seen
people
doing
early
beer
on
merchant
silicon
for
sure,
I
spend
a
lot
of
time.
Reading
data
sheets
of
what's
available
and
I
can
say
with
a
lot
of
confidence
that
there
are
a
few
now
just
recently,
but
certainly
none
of
the
current
product
is
sort
of
in
the
mainstream
and
being
shipped
in
volume.
Q
Has
it
and
those
that
do
have
it
have
a
significant
premium,
a
rate
related
to
it,
and
you
can
read
it's
three:
a
three
to
five
and
a
half
times
the
price
for
the
ASIC
and
about
four
times
the
power
per
100g
per
10
DB
equivalent
and
that's
based
on
me.
Looking
at
two
chips
in
the
same
current
technology,
so
I'm
not
trying
to
compare
everything
in
the
soup,
the
pot
that's
available,
but
yes
doing.
R
Good
questions
now
throughout
I,
don't
care
right
time
with
me,
yeah
I'm
doing
this
tutorial
assess
adjust
it
later
when
he
comes
up.
Okay,
Gregg
from
Cisco
I'm
glad
you
pointed
out,
I
was
going
where
this
calculation
come
for.
Really
this
cost
isn't
what
the
cost
is
in
beer
at
the
hardware
level.
It's
what's
the
comparison
between
a
current
chip
that
supports
it
and
one
that
does
not
that.
Q
To
be
very
careful
because,
first
of
all,
some
of
that
information
that
is
anonymized
to
a
degree
under
NDA
and
I
can't
really
disclose
the
details
without
getting
in
trouble,
but,
yes,
they're
there
they're
there
relative
costs
of
chips
of
similar
fabrication
technologies,
etc.
It's
that
are
very
current
generation.
S
And
the
goalie
Nokia,
so
the
first
question
is
I:
guess
should
this
be
in
the
spring
working
group
or
is
it
something.
D
I
think
that's
a
great
question.
I'm
sure
we
all
have
different
opinions,
but
we've
discussed
this
like
a
year
or
so
ago,
with
the
spring
chairs
as
far
as
multicast
and
segment
routing
and
at
that
time,
and
still
really
mostly
multicast,
is
not
part
of
the
Charter
within
spring.
So
we
agreed
that
we
would
address
these
kind
of
things
here
for
now
and
that's
why
we're
doing
here.
A
A
Q
S
Understood
and
and
I
guess,
the
next
point
is
I.
Think
one
thing
you
hit
the
nail
on
the
head
is
the
fact
that
you
know
when
you
go
to
a
unique
ass
network
that
is
segment
routing
and
the
operator
goes
through
that
much
trouble
to
remove
legacy
protocols.
Then
obviously
the
next
question
within
a
year
or
two
becomes
what
am
I
going
to
do
for
multicast.
If
I
removed.
Q
S
That
that
said,
if
you
look
at
the
legacy
multicast
protocols
today,
ml
DP,
point-to-multipoint,
rsvp-te
p.m.
etc,
etc
they
kind
of
go
hand
in
hand
to
create
a
entire
multicast
as
well
so
yeah.
You
know,
I,
don't
want
to
use
this
wording,
but
you
know
beer
being
the
Batman
and
every
Batman
needs
a
Robin
I.
Don't
see
why
a
segmented
routing
type
of
solution
that
brings
a
point-to-multipoint,
MPLS
data,
plane
or
ipv6
or
whatever
it
is
into
the
picture,
would
not
fit
nicely
with
a
solution
like
beer.
S
M
S
Yeah
and
they
just
want
to
stick
something
on
the
MPLS
land
yep
that
is
programmable.
We
are
Sdn
or
something
as
simple
as
that:
yanked
the
rsvp-te
point-to-multipoint
tree
or
ml
DP
point-to-multipoint,
three
out
of
your
network
and
just
pushed
something
with
this,
and
that
does
the
same
thing
on
the
MPLS
there.
Okay,
there's
I
I
would.
Q
I
would
generally
sort
of
agree,
and
at
least
in
principle
with
what
you've
said
and
I
think
that
what
we're
proposing
would
be
one
choice
for
doing
that.
I
also
think
that
for
some
people,
the
proposed
tree
said
with
some
of
the
bgp
extensions
to
help
put
it
into
the
network
is
another
viable
way
forward
and
I.
Don't
think
that
they're
they're
overlapping,
so
there's
space
for
both
yeah.
S
M
Yeah,
just
big
answers
with
the
programmability
right
I
mean
beauty
is
also
exactly
an
attempt
to
make
it
easier
just
to
have
a
programmable
solution
that
doesn't
depend
on
the
IGP
right.
So
in
that
framework
we
have
that
too,
if
you
just
just
quick
with
respect
to
that
whole
power
thing
or
so
right,
I
think
we
shouldn't
look
at
you
know
a
verb.
Very
you
know,
early
adoption
timeframe
too,
make
long-term
judgment
over
time
technology.
M
Q
Q
M
Just
just
testing,
because
because
you
know
it's
it's
it's
true
right.
If
you
bring
in
new
technology
in
a
chip
design,
that
was
almost
done
and
you
know
and
we'll
get
it
somehow
done.
Oh
recirculation
and
lower
performance
and
all
this
stuff
that
all
exist
and
then
a
generation
later
or
so
it
totally
looks
different
already
right,
so
I
think
that's
basically
something
we
should
credit,
really
innovative
and
new
technology
like
beer
for
or
not
and
yeah.
These
things
do
take
it
take
a
while.
Q
Q
So
if
you
look
at
this
I
hope,
there's
no
controversy
here,
because
this
is
just
me
trying
to
sketch
out
what
current
unicast
SR
MPLS
does,
which
is
build
a
sink
tree
with
and
towards
this
device
called
Zed
and
device
called
Zed.
What's
a
nodal
SID
or
some
other
type
of
SID
out
into
the
IGP
and
all
the
devices
use
that
to
compute
this
sink
tree
and
install
them
the
correct
forwarding
along
those
paths.
Q
Q
So
the
intent
here
is
that
we
would
advertise
a
new
type
of
CID
and
flood
it,
and
just
to
get
to
the
next
step
of
this
leaves
would
indicate
their
interest
in
being
on
the
tree.
In
this
case,
every
every
device
says
that
they
want
to
be
on
the
tree,
and
so
they
in
turn
flood
the
CID
back
into
the
network,
and
the
tree
is
then
constructed
in
a
distributed
fashion
through
compute
on
every
node
to
build
the
forwarding
table
forwarding
tables
in
all
the
nodes
such
that.
Q
If
something
arrives,
it
said
it
will
get
everywhere.
It
is
also
the
case
that
this
is
a
template
tree.
That's
used
in
the
logic
to
produce
the
subtree,
that's
needed
for
a
limited
scope,
multicast
and
that's
on
the
next
slide.
So
with
this
picture,
there's
a
smaller
number
leaves
interested
and
they
advertise.
Just
as
I
said
before,
there
is
a
pruning
process.
Q
That's
applied
to
the
template
tree
to
reduce
it
to
this
sub
graph
of
the
total
tree
and
you're
done
and
I
won't
go
into
the
details
and
read
any
of
it,
but
it's
available
online.
So
the
the
final
step
within
the
current
proposed
document
is
to
provide
a
certain
level
of
efficiency
with
regard
to
forwarding
table
entries
and
where
a
node
in
the
network
is
not
involved
in
making
actions.
Q
Q
I've
just
built
the
sub
portion
of
the
the
sink
tree
that
we're
interested
in,
but
there's
a
pink
and
a
purple
CID
that
is
the
unicast
destination,
and
that
tunnel
is
used
as
a
bypass
to
get
through
nodes,
and
this
too
is
also
computed
in
the
proposed
algorithms
to
produce
this
final
graph,
and
that
kind
of
concludes
for
the
most
part.
The
sort
of
overview,
or
does
conclude
the
overview
of
how
and
what
we're
proposing
I,
have
for
a
brief
period
to
look
at
the
grumpy
old
man
slide.
Q
I'm
familiar
with
all
of
these
things
on
all
of
these
things
in
the
picture
on
here,
I
was
there
in
1994,
and
the
important
thing
here
is
that
that
there
does
seem
coming
from
a
certain
subgroup
of
the
people
that
I've
talked
to
you
about
this:
a
concern
about
performance
or
memory
or
whatever
and
I
hope
that
this
chart
in
a
good-natured
way
provides
some
refutation
of
that.
It
doesn't
deal
with.
Q
Q
Q
Q
We
do
think
that
there's
a
substantial,
useful
text,
or
at
least
text
that
can
be
modified
to
to
become
useful
in
the
current
draft.
We
also
accept
the
idea
that
there's
may
be
other
lots
of
other
things
that
could
be
said
about
this
lots
of
other
ways
of
adding
to
the
documentation
of
it,
and
maybe
things
that
could
be
left
out
and
we
look
for
some
help
and
guidance
in
all
of
that
and
I
guess.
The
one
thing
we
don't
look
for
is:
please
go
away.
A
F
One
comin
up
from
Cisco,
so
I
won't
say
whether
it
should
go
to
pay
more
a
spring,
but
I
had
only
one
comment
that
I
guess
there
are
some
individual
drops
in
the
spring
also-
and
it
might
be
good
idea
to
you-
know,
get
feedback
from
the
other
working
group
and
authors
how
exactly
to
move
forward.
It
might
not
make
sense
that
something
we
standard
here
and
maybe
something
else
they
are
trying
to
do
in
the
next
room.
So
it's
just
feedback
yep.
Thank
you.
I.
T
Cisco
so
they'd
forget
in
second
routing,
if
you
enable
it
for
unicast,
it
makes
you
change.
Multicast
right
talked
about
little
yesterday
right,
so
you
can
just
do
in
as
you
do
today.
You
can
do
em
know
the
PS
you
do
today.
So
then
the
question
is:
why
would
you
want
to
change
that
for
multicast,
right
and
I?
T
Think
one
of
the
key
points
that
why
people
and
change
their
deployment
is
simplicity,
I
think
it
is
one
of
the
I
think
the
key
drivers
that
you
know
that
drove
beer
and
white
you
know
went
so
smooth
in
the
United?
Yes,
because
it's
a
simple
and
saying
that
you
know
all
you
know
it.
If
you
just
remove
elder
people
from
the
network,
that
means
you
cannot
on
Emily,
P
I.
Think
there's
such
a
misconception
with
people.
T
It
just
means
you
should
be
education,
that
if
LDP
you're
not
using
LD
P
for
unicast,
you
just
happen
to
use
the
same
TCP
session
and
same
data
formats.
So
but
if
that's
really
your
problem
you
want
to
solve,
then
it's
that's.
That's
a
misconception.
I
think
it's
the
wrong
reasons
to
disable
the
protocol.
So
I
don't
see
that
as
a
reason
to
say
you
can
have
from
Emily
P
because
you're
disabling
LD
for
unicast
but
sure
you
know
so
I
certainly.
Q
If
you
were
running
a
ml
DP
and
he
decided
to
turn
on
segment
reading
and
you
decided
to
leave
m
LD
P
in
place,
I
wouldn't
call
you
crazy.
However,
if
you're
building
a
new
network
and
you're
starting
off
using
SR-
and
maybe
you
choice
of
your
products-
doesn't
include
a
device
that
does
MLD
P
but
does
include
SR.
With
these
extensions
applied
to
it,
you
might
be
wise
to
pick
that
product
rather
than
the
one
that
does
both
well
and
that's
a
that's
me.
T
Q
Q
S
Q
M
M
There
was
a
from
Dino
and
implementation
of
you
know
MPLS
multicast
in
Peyman
99,
so
that
was
obviously
completely
politically
incorrect,
so,
which
is
why
we
then
looked
how
to
make
it
politically
more
correct,
and
actually
you
know
we
fell
in
love
with
ml
DP,
because
the
reliability
right
I
mean
we
did
that
later
in
PIM
right.
So
it
had
a
lot
of
good
things
in
the
association
with
the
unicast.
Ldp
was
great
politically
at
that
time.
Right.
So
now
it's
really
bad
right.
M
Right
so
no
pun
intended,
you
know,
but
I
think
the
the
key
thing
that
I'm
worried
about
is
that
as
cool
as
I,
like
your
slide
about
em
OSPF
back
right,
the
way
on
how
to
build
trees
with
receiver
based
joints
is
something
where
we
have
millions
of
users,
and
you
know
the
20-plus
plus
years
of
experience
and
doing
a
distributed
tree
calculation
in
the
way
that
M
OSPF
does
is
a
cool
idea.
But
we
just
don't
have
the
same
I.
Think.
Q
I
think
we
we
may
not
have
done
as
good
a
job
of
harvesting
the
knowledge
that
exists
from
the
people
who
are
using
this
everyday
in
spbm
based
networks.
But
it
is
the
case
that
there
are
over
a
thousand
networks.
They
rely
on
multicast
because
it's
actually
really
intrinsic
to
make
the
bloody
thing
work
and-
and
some
of
them
are
at
a
thousand
nodes
and
they've
been
operational
for
quite
a
while.
So
that's
a
very
well
we're
gonna.
We're
done.