►
From YouTube: IETF106-PIM-20191121-1330
Description
PIM meeting session at IETF106
2019/11/21 1330
https://datatracker.ietf.org/meeting/106/proceedings/
C
D
C
C
A
C
F
A
A
G
H
F
A
C
F
A
A
C
A
C
E
F
B
I
A
A
Welcome
to
2
p.m.
working
group
see
you
know,
hopefully
seen
enough
to
battle
before
it
should
be
the
same
as
you've
seen
in
other
meetings.
This
is
our
agenda,
so
yeah.
The
first
step
is
what
you're
doing
right
now.
Just
go
free,
working
up
status
and
stuff.
Any
comments
on
the
rest
of
the
agenda.
Hope
we
didn't
miss
any
requests.
H
A
A
A
We
requested
publication
for
the
IGMP
Emily
sleeping
young
model,
so
just
waiting
for
our
ad
to
get
the
cycle
salute
Khalid
and
also
PMD
our
improvements.
We
also
just
requested
publication.
So
what's
the
stuff
we
completed
and
also
MSTP
young
model,
so
we
did
get
some
response
from
Alvaro.
He
revealed
that
and
we
needed
have
waiting
for
a
new
person.
I
believe
do
load
balancing
as
well.
He
requested
publication
Alvaro
had
a
lot
of
comments
that
I
addressed
of
one
of
the
offers,
and
it's
going
to
rsg
evaluation.
A
Now,
then,
we
have
some
working
group
drafts
just
three
more
drafts,
so
basically
all
the
drafts
and
just
mentioned
they're
all
like
in
the
queue
to
be
published,
but
they
got
three
drafts
that
are
current
working
group
documents
that
we
are
working
on
so
now
register
packing
B
if
the
point
to
multi-point
and
the
Arjun
P
Emily
proxy
young
models.
So
those
are
the
existing
working
work
group
documents.
They
got
some
new
documents
presented
today
and
guess
we'll
consider
adoption
for
some
of
them
yeah.
That's
it
right
all
right
any
comments
on
that.
E
B
J
J
J
J
J
J
And
when
the
router
advertised
that
it
creates
BFD
session
as
multiple
in
head,
according
to
BFD
for
multi-point
networks,
which
is
now
our
50
85
62,
it
sets
the
session
down,
so
only
creates
a
state,
no
the
packets
being
transmitted
if
the
PM.
If
the
router
receives
that
they
used
the
discriminator
with
a
cap,
hello
option
sees
itself
in
a
group
designated
router
candidate
list
that
dia
router
distributes.
Then
it's
a
move
session
to
the
Upstate
and
start
politically
transmitting
MIDI
control
messages.
J
Multi
here
multi-point
leaf
and
starts
the
multiplexing
packets,
because
well
them
could
be
a
multiplicity
of
candidates.
So
that's
a
multiplicity
of
point-to-multipoint
in
video
sessions,
so
it
looks
for
the
discriminator,
but
since
the
discriminator,
only
in
my
field,
which
is
specific
to
this
type
of
BFD
session,
it
needs
to
know
the
source
IP
address
so
and,
as
already
stated
in
the
document,
the
source
IP
address
must
be
the
same
source.
The
same
ip
address,
as
included
in
hello,
pin
hello.
J
So
the
idea
is
that
they
are
monitors
the
well-being
of
candidate
or
it
could
be,
they
are
in
video
because
it's
a
multi-point
network
and
then
can
detect
whether
the
candidate
is
available.
So
if
it's
not
available,
it
can
generate
updated
candidate,
it
can
generate
the
hello
message
with
updated
Kindle
at
least
nice
faster.
J
So
that
pretty
much
the
same,
the
idea,
of
course,
are
the
dr
itself
is
the
candidate,
but
since
it
doesn't
need
to
monitor
itself,
others
can
monitor
it.
If
dr
is
using
a
point-to-multipoint
b,
FD
is
already
defined
in
this
draft
to
for
expedited
convergence.
So,
for
example,
b
dr
can
monitor
dr
as
a
candidate
for
the
load
balancing
as
and
as
a
they
are,
so
don't
need
to
create
two
sessions
next
slide.
D
J
And
v,
dr
because
ok,
the
the
benefit
is
that
because
it's
a
point-to-multipoint
session
so
firstly,
is
it,
creates
less
state
because
it's
unidirectional
right
so
the
specificity
specifics
of
our
point-to-multipoint
BFD.
It
uses
demand
mode.
So
only
there
one
side
generates
messages,
but
at
the
same
time,
since
it's
not
active
tail
listener,
the
leaf
knows
the
state
of
the
path
and
their
route.
So
in
this
case,
they
are
in
vidya
will
know,
can
monitor
the
state
of
an
arab
candidate.
Okay,.
A
Yeah,
so
everyone,
so
by
the
way,
thanks
for
that
clarification,
you
just
had.
It
was
one
of
my
questions
as
well.
Okay,
but
one
thing
I
was
wondering,
is
I
agree
that
you
know
you
only
really
needed
the
art
to
monitor
the
GDR,
but
I
know
there
are
some
some
payment
limitations
would
be
a
fever.
You
just
have
hearings
between
all
the
neighbors
and
you
just
listen.
You
know
to
check
your
neighbors
going
away
in
general
yeah.
Well
again,.
J
We
are
not
mandating
it.
This
is
option
and
they're
nice
about
point-to-multipoint
that
comparing
to
RFC
fifty
eight
eighty,
which
described
all
actually
fifty
eight
eighty
described
all
the
possibility
for
the
team
applicability
is
I.
Believe
it's
a
single
hobby
FD.
So
it's
a
synchronous
mode,
a
synchronous
mode
will
create
more
state,
because
if
we
have
the
more
routers,
we
have
on
the
same
shared
segment,
the
raw,
the
more
pin
routers
on
the
same
shared
segment.
So
the
more
state
of
BFD
sessions
that
create
full
mesh
between
will
be
there
so
and
I.
J
A
The
main
the
main
thing
I
was
wondering
about
in
a
way.
Yeah
was
you
know,
there's
it
says
here
that
you
Lachie
they
are
you.
Take
the
session
state
up
or
down,
based
on
whether
you
are
currently
announced
yes
and
I
was
wondering
a
bit
in.
Does
it
make
sense
to
just
always
keep
it
up
in
case
some
papers
are
well.
J
A
J
Then
we'll
probably
will
change
that,
because
then
then,
we'll
change
it
even
from
the
beginning
that
we're
after
they
announced
their
capability,
they
will
set
their
session
up,
because
current
text
says
that
the
session
is
initial.
State
is
down
and
you
bring
it
up
only
if
you
see
yourself
on
the
candidate
list.
So
if
there
is
a
use
case
to
make
it
well,
let
me
see
if
it
use
case
to
make
it
less
restricted.
J
A
Yes,
so
I
don't
have
any
answers,
but
but
one
thing,
for
instance,
I'm
wondering
about
this
one
is
the
our
state
right.
It's
useful
to
use
PFD
to
quickly
did
Herman,
who
is
the
Dro
GDR,
but
also,
possibly,
maybe
things
like
a
start
state.
For
instance,
if
you
this,
if
you
track
neighbors-
and
you
see
that
you
know
the
Oscar
winner
went
down
that
Islands.
J
A
J
A
J
Again,
since
Stig
mentioned
that
there
might
be
some
scenarios
that
might
change
the
normative
language,
let's
keep
it
open
for
comments
from
the
list
if
they
will
really
like
idea
of
making
it
less
restrictive.
For
example,
change
must
should,
and
if
there
are
such
requests,
yeah
I
think
that
there
is
no
problem,
but
I
would
like
to
first
understand
why,
before
making
it-
and
after
that
we'll
see,
yeah.
A
A
G
A
C
H
H
Some
updates,
so
one
acted.
The
way
I
did
the
option
at
the
confusion,
leave
to
specify
the
sender
sauce,
I
dress.
So
in
case
we
have
multiplied
dresses,
so
this
one
will
be
used
through
the
reporter
D
and
kima
option,
a
flexibility
for
the
user,
so
I
think
highlights
used
to
be
highlighted,
but
anyway,
okay,
so
that's
aligned
with
the
source
address.
Next.
My
spleen
same
thing
here
to
the
I'm
ready.
H
Vacation
tree
same
the
pinheaded
extra
space,
so
another
leave.
Your
comments
is
about
the
future
mode
were
stainless.
Also,
each
sauce,
which
tell
me,
makes
analysis
so
it
shouldn't
be
there
the
theater
mode
for
the
core
team,
so
you
can
either
any
particular
sauce
or
xcode
included
extras
or
should
be
either
black.
Also
only
so
we
remove
the
not
proper
position,
the
filter
mode,
so
this
is
a
clean
up.
Next
are
trees
seem
seem
to
the
MRD
that
the
same
changes
next
fights
so
yeah.
That's
it
some
quick
updates
to
the
changes.
A
J
G
I
H
I
B
F
I
It's
maybe
it's
my
problem,
but
the
question
is
that
whether
we
should
include
that
function
because
that
function,
sir,
is
very
important.
The
problem
is
that
the
doctor
was
not.
It
was
not
draft
rejected
I
mean
that
the
draft
was
accepted,
but
the
problem
was
in
my
I'm,
not
sure
what
the
intention
of
the
draft
state
is.
For
example,
it
should
be
a
standard
track
or
information
or
experimental
and
the
other
vendors
are
already
implemented
and
that
there
is
no
consideration
about
wired
communication.
I
So
so
there
was
a
comment
from
the
ad
so
why
we
definitely
need
to
have
that
kind
of
draft,
especially
for
as
a
standard
track
document.
So
that's
why
it's
really
stucked
and
but
that
function
itself
is
really
important
and
I'm
sure
that
several
vendors
are
already
implemented,
that
function
and
young
mothers
should
focus
on
that
kind
of
important
function.
So
the
question
is
what
we
or
they
should
do.
A
I
H
A
K
H
A
H
A
A
A
What
you
see
here,
basically
as
part
of
the
register
packing,
you
try
to
discover
if
the
RP
actually
supports
it,
you
don't
want
to
send
a
packet
register
unless
you
know
for
sure
that
it
can
be
processed.
So
there
is
to
find
a
way
of
detecting
that
the
RP
supported
was
having
a
flag
in
a
register.
Stop.
A
But
what
happens
if
your
RP
is
suddenly
downgraded?
So
it
doesn't
support
this
anymore.
So
the
draft
discusses
how
to
detect
that.
Basically,
if
I
remember
now,
if
we
send
a
packed
register
and
you
don't
get
a
register,
stop
back,
then
there's
a
chance
that
your
RP
no
longer
supports
it.
But
is
it
that
there's
some
new
disc
text
to
to
discuss
how
the
system
otherwise
I
don't
know
what
else
is
missing?
A
C
B
D
But
but.
A
A
So,
as
a
chair,
how
many
people
have
read
this
drafts
to
two
people?
Do
you
both
think
it
looks
useful
or
yeah
yeah
I
should
say
we
also
have
another,
a
cert
packing
draft
that
we
will
discuss
later
and
it's
basically
the
same
idea.
I
believe
it's
there's
a
number
of
pages
that
are
Paris,
comma
G
but
similar
to
join
prints.
It
might
be
useful
to
to
have
multiple
a
long
message:
okay,
I
guess,
we'll
figure.
A
L
Okay,
so
hello,
everybody,
I'm,
Reese
controller
from
telefónica
or
could
do
it
with
you
Toshi
a
xylophone
Nick
in
this
idea
of
multiple
absolute
interface.
Support
for
IEP
I
am
PMD
proxy,
so
the
idea!
Well,
we
were
turned
to
revive
this,
the
other
we
did
take
in
some
time
ago
and
now
trying
to
be
more
pushing
a
little
bit
more,
be
more
active
on
on
that.
So,
basically
they
they
be
able
be
to
having
to
support
in
a
in
the
proxy
the
capability
of
having
multiple
option
interfaces.
L
This
enables
a
number
of
use
cases
I
will
detail
later
on,
but
basically
the
point
would
be
to
make
a
more
efficient
usage
of
the
network
and
also
enabling
new
new
situation.
So
the
point
will
be
basically
to
be
able
of
receiving
the
multi
multicast
packets,
multicast
content
in
both
of
these
interfaces,
according
to
different
situations,
different
policies
could
be
applied
to
on
top
of
that.
So
the
we've
mentioned
there.
L
This
one
possibilities
like
well
receive
a
LT
wife
a
over
so
the
day
the
the
span
of
a
scenario
sees
is
quite
large
and
we
will
take
a
little
a
bit
later.
Next
slide,
so
the
objective
yeah
basically
to
have
the
possibility
of
receiving
multicast
sessions
because
content
in
different
upstream
interfaces,
the
solution
sohow
addresses
the
requirements
that
are
documented
in
in
another
draft.
This
and
now
progress
in
in
the
dependent
stream
or
stop
actually
progressing
so
who's
moved
to
the
in
the
potential
mission
stream
and
yeah.
L
So,
regarding
the
benefits
that
we
foreseen
if
this
was
implemented,
is
basically
having
a
flexible
operation,
so
either
we
could
select
the
do.
What
is
they
obscene
interface
based
on
the
subscriber
that
is
requesting
the
service
or
either
even
a
in
base
of
the
channel
of
the
content
that
is
being
provided?
So
we
could
play
with
these
two
alternatives.
Let's
say
a
part
of
this
flexible
operation.
This
solution
could
enable
a
robust
data
reception
because
we
will
be
able,
even
after
the
same
content
receipt
by
the
two
interfaces.
L
This
could
be
one
of
the
of
the
situations,
and
this
enables
only
scenarios
of
high
availability,
for
instance
in
the
network
and
all
okay,
even
in
other
situations
where
we
just
received
the
condemning
in
one
of
the
two,
we
could
have
mechanisms
for
protecting
the
the
delivery
of
the
content
and
having
a
switch
between
interfaces,
if
required
in
order
to
have
the
service
alive.
Yet,
even
in
the
case
of
events
in
the
network,
next.
L
In
the
use
cases,
our
refreshment
on
this
I
will
detail
trying
to
tell
a
bit
different
use
cases
that
were
documented
already
in
the
requirements.
Draft
one
situation
would
be
the
multicast
wholesale
offer
for
residential
services,
so
we
could.
L
It
could
be
the
case
that
one
operator
enables
also
enables
also
the
delivery
of
content
from
another
provider,
an
OTT
provided,
for
instance,
in
such
a
way
that
a
subscriber
to
this
operator
has
the
opportunity
to
receive
and
a
content
from
either
the
own
content
or
the
content
from
the
this
OTT
provider,
multicast
resiliency
for
sure.
In
the
case,
we
have
these
two
interfaces
we
could
or
two
or
more
interfaces.
We
could
provide
more
resiliency
to
the
delivery
of
multicast
traffic
to
the
network
load
balances
for
multicast
traffic.
L
So
having
this
possibility
of
receiving
traffic
by
through
more
than
one
interface,
we
could
take
profit
of
that
in
order
to
use
this
per
capacity
in
the
level
for
a
receive,
more
content
and
only
reducing
the
available
bandwidth
in
case
of
an
event.
So
we
could
enable
also
these
kind
of
things.
Also
there
are
situations
or
procedural.
Real
operational
situations
were
having
more
than
one
assume.
L
Interface
would
be
beneficial
like
the
case
of
the
network
merging,
so
you
are
matching
networks
and-
and
you
have
different
contents-
may
be
overlapping
the
addressing
of
the
content,
and
so
we
could
play
with
this
fact
in
order
to
have
a
smooth
integration
of
all
networks.
And
finally,
the
multicast
service
migration
so
the
same
idea.
If
we
need
to
somehow
to
migrate
a
service,
we
could
enable
a
second
interface,
a
second
upstream
interface
for
the
migrated
content,
while
keeping
the
ribbon
another
interface
for
the
old
content.
L
So
all
of
this,
as
I
mentioned
before,
is
documented
in
the
requirement
and
draft,
so
it's
available
also
for
for
you
to
check
so
we
in
this
solution
drug
we
are
proposing
to
two
ways:
two
chances.
One
would
be
the
automatic
upstream
interface
configuration
to
for
this
case
for
this
choice
we
have
yet
we
need
to
do
some
more
investigation,
how
to
solve
the
the
point.
So
here
there
is
a
list
of
questions
that
we
are
trying
to
address
so,
for
instance,
how
the
proxy
can
automatically
is
like
the
appropriate
obscene
interface
for
this
channel.
L
So
we
will
show
how
to
identify
what
would
be
the
required
logic
for
doing
that
or
even
if
they
would
be
required,
some
kind
of
signaling
for
enable
that
how
the
procedure
detect
inactive
obscene
interfaces,
maybe
checking
the
status
of
interfaces,
maybe
enable
enabling
messages
for
for
that,
and
also
starting
to
research.
Investigate
is
what
could
be
the
triggers
that
would
make
the
the
proxy
a
command
switch
from
one
absolute
interface
to
the
other,
so
these
are
open
questions
I
will
try
to
address
in
the
next
version.
L
L
You
should
recall,
is
shown,
etc,
so
we
could
rely
somehow
also
in
things
like
telemetry
and
so
for
having
these
these
kind
of
decisions
next
slide,
please.
So,
regarding
the
next
steps
already
has
to
keep
the
analysis
to
keep
working
on
the
analysis
without
Maddie
configuration
so
understand
what
could
be
the
on
stand,
train
to
figure
out
what
do
with
the
scenary
procedures
for
enabling
this
they
are
in
the
centralized
approach.
L
Sorry
trying
to
understand
what
would
be
the
implications
on
the
interface
that
we
require
for
managing
and
controlling
the
proxy,
and
our
idea
will
be
to
provide
a
revised
version
of
this
draft
before
next
site
even
meeting
and
keep
discussing
it
is
of
interest
for
the
for
the
working
group.
So
any
comment
to
provide
he's
more
than
welcome,
and
that's
all
for
my
say
thank
you.
F
I
So
if
there
is
such
kind
of
mechanism
in
Pimlott
or
whatever,
then
we
can
just
add
up
the
same
way
make
a
new
into
this
one.
So
the
our
header
equi,
is
actually
the
topic.
We
service
the
selection
mechanism
for
our
jpml,
the
proxy
upstream
interfaces.
It's
something
like
a
specific
question,
our
specific
topic,
but
the
discussion
point
or
the
core
question
is
actually
really
a
similar
to
the
pin
loudly.
So
maybe
so
do
do
some
does
some
of
you
have
some
good
answer
for
that
one.
I
So
the
heat
today
made
some
presentation
about
Sdn
I,
like
situation.
Maybe
that
is
more
feasible,
yeah,
so
controller
knows
the
quality
and
that's
why
he
made
a
presentation
today.
It's
actually
he's
from
operator,
so
he
has
a
great
knowledge
about
operators,
point
of
view,
so
I'm
not
operator
his
proposal,
mainly
his
proposal,
is
with
Sdn
like
controller
based
solution.
If
we
concentrate
on
that
one,
then
maybe
we
may
have
a
good
chance
to
provide
a
more
complete
solution
for
the
March.
I
A
Not
sure
how
relevant
but
I
know
this
one
implementation
that
supports
multiple
interfaces.
That
makes
you
so
the
well.
It
means
it's
a
team
router
to,
but
it
makes
use
of
the
RPF
interface
to
reverse
the
RP
address
to
towards
GRP
to
determine
where
to
send
a
report.
So
let's
say
you
have
figure
typical
use
case
for
this.
A
Is
you
have
to
pimp
domains,
but
you
don't
want
to
run,
pin
between
them,
so
you
do
your
P
between
the
two
pin
domains,
but
the
pim
router,
dance
downs,
the
downstream
pim
router,
what
be
configured
with
two
different
IP
addresses
from
two
different
providers
or
something
for
four
different
groups
and
and
you
might
use
the
RPF
interface
to
figure
out
which
provider
like
where
should
you
set
the
LGP
report,
for
which
group?
That's
just
one
example?
Oh,
there
could
be
other
ways,
so
you
know
koala
matically
determining
where
to
send
the
report.
Well,.
I
For
the
pin
router,
the
router
logging
protocol
depends
on
our
lanai
on
the
LPF
mekinese,
but
for
the
proxy
it
doesn't.
We
cannot
rely
on
our
PF
interface,
so
this
is
a
biggest
difference
from
the
proxy
and
router,
because
Roxy
doesn't
have
the
unicast
routing
table
toward
the
source
right.
So
currently
the
proxy
only
decide
one
single
interface.
He
doesn't
have
any
outing
protocol
allowing
proto
bandar-log
in
table
itself
so
always
fixed
us
one
single
interface.
This
is
a
problem,
so
we
don't
would
like
to
address
this
kind
of
a
situation.
I
The
reason
why
I
think
are
you
already
remember
that
wise,
so
why
the
proxy
doesn't
allow
the
multiple
upstream
interface,
because
it's
just
for
the
simplicity
reason
so
previously
map
in
a
magma.
We
discussed
several
time
for
this
kind
of
stopping,
but
finally,
we
decided
we
should
fix
the
single
upstream
router
and
because
proxy
doesn't
have
any
routing
protocol
routing
table,
so
we
can
just
fix
the
simple
oxime
router
and
that
previously
thing
is
over
15
years
ago.
It's
sufficient,
but
now
it's
not
optional.
So
that's
why
we
want
to
have
a
multi-core
interface.
I
A
I
A
On
the
use
case,
where
it's
a
home
network
or
not
but
but
least
like,
for
instance,
you
know
you
might
like
prefix
of
prefix
delegation,
but
but
basically
there
are
cases
where
you
might
have
a
route
saying
that
for
certain
prefixes
always
want
to
route
the
traffic
to
a
certain
provider.
And
if
you
have
something
like
that,
then
especially
for
SSM
you,
you
know
it
would
make
sense
to
send
s.
Komachi
reports
to
to
that
already
had
a
route
for
the
source
right
in.
G
A
A
D
E
A
A
A
So
this
sounds
like
it's
gonna
be
all
beard,
but
because
we
are
responsible
responsible
for
our
EMP
and
ml
d
in
this
working
group,
and
it's
kind
of
like
a
big
change.
I
think
it's
important
to
do
it
here.
So
so
this
is
beer
specific,
but
it
might
be
useful
to
have
a
generic
way
of
extending
our
GMP
an
ml
d.
So,
let's
see
yeah
next
slide,
so
in
our
EMP
version,
3
and
Emily
were
since
you
RFC's.
There
is
this
text
about
additional
data
for
both
queries
and
reports.
A
It
basically
says
that
if
the
message
is
longer
than
expected,
there
is
some
additional
data
at
the
end
of
the
message.
You
should
check
some
everything,
but
usually
otherwise
they
just
ignore
whatever
is
there.
So
it
means
that
if
we
were
to
sum
up
with
some
extra
date
at
the
end,
existing
implementations
would
just
ignore
it,
which
is
great
next
slide.
A
A
So
you
could
say
if
you
don't
support
some
kind
of
extension,
and
you
just
ignore
this.
The
current
implementations
would
just
ignore
it,
but
if
we,
if
we
want
to
do
an
extension
and
say
you
support
a
specific
extension
type,
then
you
check
what
comes
after
there
and
you
might
say
why
do
we
need
an
extension
type?
Why
don't?
Why?
Don't
they
just
put
the
beer
data
at
the
end,
but
just
in
case
someone
comes
up
within
a
few
years.
A
A
So
excuse
me
so,
even
though
I'm
not
considering
any
other
extensions,
I
think
there's
a
chance
at
some
point
in
time.
It
might
want
some
other
extension
and
that's
why
I
want
to
have
this
accession
type
there
and
the
idea
is
current.
Implementations
would
completely
ignore
it,
based
on
the
current
RFC's,
if
you
support
the
specific
type
in
extension
and
fine,
you
process
it.
If
you
don't
understand
or
don't
support
that
type,
then
you
again
just
ignore
it
like
you
would
do
today
for.
K
A
K
A
I
I'm
not
100%
sure,
but
I
giant
beaker.
He
doesn't
have
a
virgin
number
field.
It's
right,
yeah!
It's
based
on
the
length
so
they're
right.
That's
it
right
right!
So
currently
hostile
just
recognize
the
size
of
the
Curie
message
and
then
the
some
let's
say
100.
This
is
gesture.
For
example,
100
bytes
shirley
is
like
a
virgin
one
120
32
130.
H
I
A
Version
food
right
so
yeah.
Let
me
comment
on
that.
So
at
least
the
way
it's
defined
now
is
RGB
version.
2
is
28
bytes,
maybe
I'm
not
sure.
Now
it
is
a
certain
size
and
if
the
message
is
larger
than
that
size,
then
it's
supposed
to
be
sergeant
Pearson
three
right,
partly
because
at
least
for,
like
a
specific
query,
you
know
it
that
the
length
is
variable
as
well
for
version
3.
So
so
it's
not
always
a
fixed
size.
But
I
get
your
point.
A
If
we
were
to
ever
define
Olympia
worse
than
4,
we
would
need
maybe
some
other
tricks
than
just
the
length
to
decide
which
which
worse
than
this
okay,
it's
something
I'll
look
into
that,
but
yeah
I
believe
it
should
be
whether
it's
the
minimum
size
or
longer
I,
and
that
this
is
the
Terminator
okay.
I'll,
look
into
that
so
about
this
extension
types,
so
yeah
I
was
saying
how
he
would
ignore
it.
A
If
you
don't
support
it
and
stuff
also
would
say,
though
yeah
mostly
in
general,
it
will
be
a
non-starter
to
try
to
make
changes
to
IGMP
queries
and
reports,
because
just
millions,
some
implementations
or
deployments
out
there
and
they
wouldn't
change.
But
if
there's
some
extensions
like
in
this
case
it's
beer
specific,
then
you
know
it
might
be
doable
to
expect
at
least
those
implementations
to
change,
or
there
are
no
implementations
yet.
So
that
is
helpful
as
well.
Okay,
next
slide,
so
so
that
was
about
a
generic
part.
A
A
We
would
like
to
know
the
subdomain
that
beer
prefix
and
the
B
Friday
like
the
beer,
I,
D
or
the
sender,
so
we
could
potentially
have
used
the
the
source
address,
so
the
EMP
or
ml
d
message,
but
we
would
prefer
to
have
all
this
information
specified
and
what
I'm
saying
in
this
other
graph
did
not
be
working.
Group
is
that
that
mentioned
on
the
top.
There
is
that
you
should
always
use
this
extension,
so
we
can
know
who
it
came
from,
it's
mostly
useful
for
reports,
but
it
could
be
useful
for
queries
as
well.
A
If
you
want
to
do
some
logging
or
something
ok
next
slide-
and
this
is
what
the
extension
would
look
like,
so
you
would
have
your
normal
id
Imperium
LD
message,
and
then
this
will
come
at
the
bottom,
with
some
extension
type
assigned
by
iana
and
then
the
content
itself
next
slide.
Please
if
there
is
one,
no,
no
okay,
so
so
one
question
is:
is
it
a
good
idea
to
define
a
generic
way
of
extending
this
I
would
say?
A
If
you
do,
though
you
know,
we
should
create
a
registry
and
we
set
the
requirements
for
creating
a
new
extension.
It
should
be
something
that
is
strict.
We
don't
want
people
to
come
up
with
lots
of
different
extensions
and
in
this
case,
for
beer
I'm
at
least
the
way
I'm
arguing
it
is,
it
would
only
be
used,
must
only
be
used
when
you
encapsulate
an
attempt.
A
You
MLD
message
inside
beer,
so
it
would
not
be
seen
by
non
beer
implementations
if
they
do
it,
though
accidentally
see
if
they
were
just
ignore
the
extra
data
and
the
good
thing
in
this
case,
it's
only
support
need
to
be
supported
by
the
beer
routers
that
originates
or
receive
these
messages,
and
there's
no
implementations
today.
Really
so
it's
not
like.
We
need
to
upgrade
a
lot
of
implementations.
D
From
Cisco,
so
question
is
more
for
the
whole
working
group,
instead
of
only
you
so
so.
This
extends
and
I
know
that
with
beer,
definitely
it
adds
a
lot
of
value,
but
are
we
expecting
more
of
these
kind
of
use
cases
if
some
host
or
some
application,
who
is
using
IGMP
and
wants
to
add
some
extra
context
about
join
membership
requests
it's
in
future
I
mean
I
said
today,
all
the
hosts
they
work
either
in
v2
or
v3
mode.
Is
it's
more
of
stuck
it's
stagnant
that
we
don't?
D
We
don't
do
anything
else
in
IGMP
as
of
now,
but
when
we
are
opening
this
channel,
so
is
it
good?
It
is
bad
how
it
is,
it
might
add
a
lot
of
value
as
well.
If
there
are
some
new
application
coming,
they
might
want
to
add
some
extra
content
or
extra
context
about
what
they
expect
from
upstream
Wouter
yeah.
A
Yeah
I
mean
I,
think
yeah,
I,
think
I
know
you
were
us
in
the
group
and
happy
to
hear
what
others
think,
but
yeah
I
think
there
could
potentially
be
some
use
cases
and
well
filo.
We
you
know
in
this
working.
We
should
be
in
control
of
what
use
cases
get
sterilized.
So
what
extensions?
So
if
someone
has
a
use
case,
we
should
consider
it
here
and
see
whether
it
makes
sense
but
yeah.
You
could
imagine
for
certain
cases
that
maybe
some
host
implementation,
for
instance,
was
announced
to
support
something
new.
A
The
thing
now
is
you
can't
expect
devices
in
general
to
support
new
extensions.
I,
don't
know
if
we
could
also
be
some
interesting
things
to
think
about
related
to
like
sleeping
and
proxying
and
stuff
and
what
happens
if
some
support
and
extension
and
always
do
nots
and
in
the
beer
case
at
least
it's
encapsulated
and
there's
no
no
LTE
devices
on
the
path.
So
that's
good
one
question
I
have
for
the
working
group
is
well
one
is:
is
it
okay
to
extend
our
Jim
PNM
LD?
A
If
we
do,
is
this
scheme
reasonable
with
this
extension
type?
Another
question
is
I'm,
trying
to
figure
out
what
should
we
do
in
this
group
I?
What
should
we
do
in
beer-
and
there
was
some
discussion
about
that
in
beer
this
morning
too,
so
I
feel
like
the
extension
mechanism
itself
should
definitely
be
done
in
this
working
group,
but
the
actual
beer
TLV
that
you
see
here
that
could
potentially
be
done
in
the
beer
working
group
depending
on
what
people
think.
D
Mom
come
not
from
it
Cisco,
so
I
think
yeah.
You
clearly
mentioned
that
this
part
of
the
work
can
go
to
be
a
working
group
and
I
really
feel
that
I
am
extension.
Defining
a
new
and
you
might
be
good,
there
might
be
new
use.
Cases
coming
in
future
from
multicast
and
host
might
not
be
just
hosts
what
they
are
today.
They
might
be
some
kind
of
application
which
can
do
much
more
than
just
doing
a
jumpin,
so
yeah
it
would
it
would.
It
would
open
new
opportunities
there
to
do
something.
Yeah.
A
F
A
K
I
may
have
been
confused,
but
its
own
is,
if
you
mention
in
beer,
something
like
it
was
first
onion
work,
one
working
group
or
some
other
document
had
first
been
done
in
on
working
group
and
then
thrown
over
the
fence.
Was
they
actually
something
like
that?
Because,
as
long
as
we
don't
find
another
example,
then
the
beer
one
it
might
be
better
to
kind
of
bring
it
into
good
shape
and
beer
first,
alright,
so
I
think
that's
that's
a
little
bit.
What
I?
What
I'm
worried
about
that
you
know.
K
A
Right
so
yeah
I
mean,
if
you
ask
me,
as
some
offer
or
whatever
I
mean
I'm,
also
working
on
that
Amidala
drafted
beer
I
feel
like
it
makes
sense
to
do
this
option
in
beer
actually
and-
and
you
know,
there's
been
like
tlvs
for
our
GPS
and
so
on
to
that
were
defined
in
beer,
because
the
actual
use
case
of
the
option
how
it
is
handled,
what
you
put
in
there
and
so
on.
That's
all
beer
specifics,
so
my
current
thinking
now,
if
you
guys
agree,
is
view
this.
K
A
K
I
mean
Greg
is
sleeping,
so
I
mean
either.
The
obvious
idea
coming
to
mind,
which
would
be
the
same,
would
be
something
like
if
you
do
it
that
for
rsvp-te
or
so,
if
you
want
to
build
a
point-to-multipoint
tree,
would
that
have
something
like
similar
properties,
because
you
need
to
know
the
leaf
some
specific
identifiers,
not
that
I
would
want
to
do
it
right,
but
yeah,
just
that
we
kind
of
vet
the
extensibility,
somehow
yeah.
A
B
Cisco
so
I
think
I
good
steak
actually
got
he's
taking
a
right
approach
here.
That's
a
there's
undefined
space.
Now
that
you
can
use,
but
you
cannot
use
it
once
for
beer
right.
You
have
to
put
his
steel
research
in
place,
so
other
features
can
be
added
later
so
splitting
that
into
drafts
want
to
define
that
you
have
a
structure
and
one
in
beer
as
a
use
case.
I.
Think
that's
perfectly
enough
to
do
this
right.
You
don't
need
to
another
use
case,
I,
think
yeah.
A
I
should
also
say
at
least
my
thinking
is
I,
don't
want
to
go
overboard,
I
mean
in
theory.
We
could
define
some
kind
of
a
GMP
options
like
how
options
we
could
add
like
lots
of
theories
and
so
on,
but
I'm
intentionally
thinking
it's
best
to
keep
it
as
simple
as
possible.
All
I
want
is
this
identifier
to
just
make
sure
that
it
doesn't
conflict
with
other
possible
extensions
in
the
future.
K
Maybe
maybe
I
wasn't
expressing
myself,
while
I'm
certain
I'm,
not
saying
that
the
document
itself
should
have
a
text
about
additional
examples.
It
was
just
kind
of
if
we
had
a
discussion
just
in
terms
of
okay.
You
know
each
of
us
thinks
about
something,
and
then
we
feel
more
safe,
that
you
know
it
will
work
for
extension
right.
So
that's.
C
F
There's
up
next,
while
you're
coming
up
just
to
confirm
with
the
working
group,
we've
had
an
understanding
with
the
spring
working
group
that
they
are
not
chartered
to
work
on
multicast
related
type
stuff
in
the
spring
working
group
there's
been
a
little
bit
of
question
recently
because
they
had
something
added
to
their
Charter,
and
so
people
were
kind
of
curious.
If
that
was
the
case,
so
this
is
Ian
and
I
had
a
conversation
about
this
earlier.
So
just
an
hour
ago,
in
the
the
ad,
the
spring
eighties
and
and
chairs
agreed.
F
We
were
under
this
understanding
that
we
could
always
put
things
back
to
them
if
we
need
to,
but
it
sounds
like
there's
not
any
plan
for
that
to
even
anytime
soon
to
take
place.
There's
not
gonna,
be
any
change.
So
does
anybody
have
any
questions
or
comments
on
that
before
hooman?
Goes
that
that's
our
understanding?
So
if
we
were
to
adopt,
we
were
certainly
free
to
adopt.
These
kind
of
drafts
is
what
I
is.
What
our
point
is.
A
Yeah
also
I
think
hopefully
we'll
mention
this
as
part
of
your
presentation.
So
there
is
this
one
draft
being
considered
for
adoption
and
spring.
That
is
like
a
replication
option
or
something,
but
this
is
kind
of
going
further
with
with
that.
So
so
this
small
part
might
be
done
in
screen.
We
might
consider.
M
Yes,
yeah,
so
if
you
can't
go
to
the
next
slide,
but
let
me
let
me
start
from
a
score
one.
What
what
this
graph
is
trying
to
achieve
so
currently,
when
it
comes
to
the
transport
and
mainly
in
in
5g,
and
some
of
these
converge
course
signal
routing
is
playing
a
big
role
when
it
comes
to
traffic
engineering.
Slicing,
you
guys
heard
about
a
slicing
at
lunchtime.
M
M
What
should
I
do-
and
this
is
where
this
draft
and
this
idea
comes
into
play
so
basically,
when
it
comes
to
the
transport,
it's
the
same
transport
that
we
have
today
in
MPLS,
it's
just
an
incoming
label,
outgoing
interfaces
and
outgoing
labels.
So
there's
nothing
changed
on
the
data
path
of
the
MPLS.
It's
just
how
we
nailed
down
the
point-to-multipoint
tree.
M
This
idea
says:
let's
use
the
controller
to
nail
it
down.
Previously
we
were
using
signaling
like
LVP
and
rsvp-te.
So
that's
the
only
part
that
this
draft
is
trying
to
resolve
it's
trying
to
simplify
multicast,
remove
some
of
the
current
legacy
and
I
used
that
term,
careful
in
Legacy,
multi
called
multicast
protocols
and
moving
to
the
Sdn
controller.
If
you
can
go
to
the
next.
M
So
here's
a
brief,
a
story
how
it
started.
I.
Think
my
previous
explanation,
kind
of
explaining
you
know
what
was
the
theme
behind
this
idea.
Now
we
have
started
introducing
a
draft
in
is
free
spring
source,
routing
multicast,
every
single
node.
You
have
a
state
and
you
need
to
make
a
decision
at
every
single
node
on
transit
or
even
on
the
leaf.
So
it's
not
so
much
of
a
source
routing
when
it
comes
to
the
multicast
and
that's
where
they
become
a
little
bit
of
what's
the
right
border
clash,
maybe
not
on.
M
What's
the
right
word
to
use
here
in
the
spring
Charter
saying
that
this
is
not
source
routing,
because
every
single
router
has
to
make
a
decision,
and
this
is
why
we
introduced
one
draft
in
this
spring.
It's
a
replication
segment.
I'll
explain
later
on
what
the
application
replication
segment
is,
but
the
bulk
of
the
work,
which
is
the
point
to
multi-point
policy,
how
the
whole
thing
works,
we
decided
to
bring
it
into
the
pane.
Just
we
felt
like
you
know.
M
There
is
more
multicast
expertise
here
and
you
know
they
can
address
this
point
multi-point
three
better
in
NP
mattered
in
in
signaling.
So
this
is
how
the
architectural
Draft
has
been
a
slice
and
dice.
As
of
now,
there
is
one
a
small
graph
in
segment
routing
in
a
spring.
The
reason
that
we
put
it
there
at
the
end
of
the
day.
This
draft
talks
about
seats.
M
It
talks
about
policies
and
a
little
bit
of
signal
routing,
so
we
needed
to
have
something
there,
but
then,
as
you
will
see
in
the
next
slides,
the
entire
idea
is
a
point-to-multipoint
three
and,
and
the
bigger
architectural
draft
is
is
gonna,
be
we
are
hoping
that
is
going
to
be
worked
on
in
this
working.
So
next
slide.
Please!
So
here
are
some
other
relevant
draft.
Do
you
guys
can
go
through
it?
So
the
entire
idea
is
T.
M
There
is
to
architectural
draft
the
PMS,
our
point-to-multipoint
policy,
which
we're
gonna
explain
here:
the
replication
segment,
it's
a
very
a
small
subset
of
the
point-to-multipoint
policy,
so
the
point-to-multipoint
policy
actually
covers
the
replication
segments
and
and
the
bigger
picture,
and
then
there
is
a
yang
draft
which
we
put
in
the
spring.
As
of
now
to
you,
I,
don't
know
whatever
you
need
to
bring
that
into
the
PM
or
not.
We
can
discuss
that.
But
if
you
look
at
the
yang
it
kind
of
explain
how
their
architecture
is.
M
It
gives
you
a
good
overview
of
what
this
whole
idea
is
all
about,
and
then
we
need
to
have
southbound
and
northbound
I.
Guess:
communication
between
the
router
and
the
controller,
and
that's
where
the
two
last
draft
is
there's
a
PCE
draft
that
actually
takes
care
of
a
Southdown
and
also
there
is
acknowledgment
a
northbound
from
the
node
to
the
to
the
controller
and
then
obviously
the
sexy
one
is
IDR
point-to-multipoint
policy
for
pgps
RTS,
that's
another
way
to
actually
program
this
screen.
So
there's
two
way
of
programming
the
tree
depending
on
the
operator.
M
So
maybe
we
can,
for
the
sake
of
time,
go
through
the
next
few
slides
like
you,
can
skip
the
next
slide
and
go
to
the
one
with
a
pretty
picture.
Usually
pictures
explain
much
much
better,
so
here's
a
the
entire
architecture
of
point-to-multipoint
policy
so
on
the
route
there
is
a
policy
that
actually
displays
the
the
root
node
and
the
leaf
node.
So
you
go
under
decree
the
point
of
multiplying
policy.
You
say
what
are
the
Leafs,
how
you
learn
the
Leafs?
M
It
could
be
manually
configured
on
the
controller
or
you
could
actually
have
the
controller
listening
to
the
NP
bgp
bgp
multi-protocol
communication
that
is
going
between
the
route
and
between
the
Pease
and
learn
the
Leafs
weird
about
that
communication.
So
that's
how
you
build
your
point-to-multipoint
policy.
Their
route
builds
up
the
point-to-multipoint
policy.
It
uses
P
SEP
as
of
now
to
shoot
all
that
information
to
the
controller.
M
So
the
controller
then
understands
where
the
route
is
where
the
Leafs
are
and
because
it
has
the
view
of
the
entire
network,
it
can
create
a
point-to-multipoint
tree
and
download
it
to
the
routers.
Now
there
are
a
couple
of
ideas
here
and
the
first
one
is
a
candidate
path,
so
these
ideas
are
not
new
to
this
graph
like
a
candidate
pad.
If
you
look
at
the
SR
policy
unicast
our
policy,
all
these
ideas
are
already
there.
We
are
just
using
them.
M
So
a
candidate
path
within
a
point-to-multipoint
policy,
simple
term
is
LSP
redundancy,
so
under
that
policy
could
create
multiple
point-to-multipoint
LSPs
and
they
can
be
redundant
based
on
the
preference.
The
one
with
the
highest
preference
is
the
active
point-to-multipoint
tree
now,
each
one
of
those
cat
candidate
pads.
You
can
optimize
them
globally,
so
there
is
fast
reroute
concept
here,
let's
say
one
of
those
candidate
paths
because
of
a
failure
goes
into
a
fast
reroute.
M
You
can
optimize
it
globally
and
that's
where
the
ins
ideas
come
into
play,
so
each
candidate
pad
can
have
two
point-to-multipoint
LSP
instances
and
those
are
actually
used
for
global
optimization
and
make
before
break
on
the
root
note.
So
if
one
of
those
instances
is
doing
a
fast
reroute,
the
controller
can
compute
a
brand-new
tree
with
with
the
SLA
s
that
are
in
the
laser
that
are
relevant
to
that
multicast
path
and
download
the
second
instance,
and
on
the
head
end,
you
can
do
a
make
before
a
break
between
one
to
the
other.
M
M
So
you
can
stack
up
labels
if
you
are
going
to
a
unique
ass
domain,
but
as
soon
as
you
get
to
a
multicast
domain-
and
you
need
to
do
a
multicast
replication,
you
need
to
have
the
replication
policy
and
you
need
to
be
having
an
incoming
label
and
your
outgoing
interfaces.
So
this
is
the
the
very
high-level
idea
of
this
draft
next
slide.
Please
so
I
put
a
couple
of
examples
together,
just
for
like
a
case
study.
M
So
in
this
case
we
have
a
route
that
is
on
North
a
and
we
have
two
leaves
which
is
T
and
E.
So
what
will
happen
is
that
if
there's
n
P
BGP
going
on
between
piece
between
a
T
and
E
a
we
learned
that
router
D
and
router
or
actually
beliefs,
it's
gonna
send
that
information
to
the
controller.
The
controller
will
create
a
point-to-multipoint
policy
with
those
information,
and
it's
going
to
note
the
tree
ID
and
it
multicasts
tree
needs
to
have
a
identifier
and
that
identifier
is
a
tree
ID.
M
It
builds
a
candidate
that
gives
the
preference
of
1,000
as
an
example
to
the
candidate
path.
It
goes
to
note
a
C,
D
and
E.
It
creates
the
replication
segments
and
all
these
nodes.
That
said,
sorry,
it
goes
on
node,
a
C,
D
and
E,
because
b
is
not
multicast
ver.
That
said,
when
it
goes
on
note
a
it
creates
a
seat
list
that
says
push
B,
which
is
the
unicast
C
and
then
push
C,
which
is
a
multicast
replication
C.
M
So
in
this
case,
if
the
packet
comes
in
on
a
is
actually
going
to
push
be
on
top
of
the
stack
see
at
the
bottom
of
the
stack,
the
packet
goes
to
B.
B
just
does
normal
segment
routing
pops,
the
label
forwards
it
to
C,
which
is
a
replication
segment
and
the
replication
segment.
Gonna
say
that
your
outgoing
interfaces
are
DNA
and
here
the
labels
that
you
need
to
use
to
shoot.
The
packet
is.
K
M
K
K
K
Have
F
some
slightly,
you
know
more
abstraction
right.
The
fact
that
you're
heading
on
a
per
hop
basis
on
seats
that
are
forwarded
by
that
are
not
local
sit,
but
global,
sits
right
on
every
forwarding,
hope,
you're
changing
the
offset.
That's
the
key
difference,
you're
not
using
this
year,
I
think
right.
So
so
on
there.
M
Is
traffic
engineering
involved
here
because
of
the
controller
has
the
whole
view
of
the
of
the
network?
We
are
not
in
the
mercy
of
IGP,
so
the
controller
can
create
a
tree
through
the
network.
For
that's
for
the
district.
You
can
create
different
and
slices
through
the
network
for
the
same
point-to-multipoint
policy.
K
No
I
understand
that
all
I'm
saying
is
that
I'm
not
persuaded
they're
trying
to
apply
the
city
terminology
to
what
the
forwarding
plane
is
doing
is
the
correct
thing
right.
It
looks
to
me
more,
like
normal
MPLS
forwarding
state
on
every
hop
right
that
that
I
have
in
ml
DP
rsvp-te.
So,
whereas
it's
as
I
said
right
ARP,
you
know
network
of
network
wide
relevance
with
you
know
per
have
sets
that
are
changing.
So
that's
why
I
mean
I.
Think
to
me
the
use
of
CID
is
more
confusing
than
helpful
I.
K
M
K
I
mean
we
do
have
nice
address
spaces
where
effectively
this
thing
could
simply
be
setting
up
aesthetic.
You
know
a
replication
tree,
for
you
know
right
I'm,
saying
kind
of
again
the
same
thing
of
oh
yeah.
Everything
has
to
be
segment
routing
where,
in
the
end,
what
kind
of
controller
built
you
know
static
tree
right,
which
we've
done
forever
I'm
saying.
If
you
want
to
run
with
ipv6
right,
you
don't
and
you
don't
need
to
try
to
kill
yourself
by
making
this
look
like
SR
v6
with
D
cap
and
rien
cap
you're.
K
M
K
That's
fine
right,
III
I'm,
pointing
to
the
fact
that
I
think
this
this
thing
might
fly
it
easier,
the
more
we're
trying
not
to
fiddle
it
through.
You
know
the
needle
of
trying
to
make
it
look
like
a
segments
routing,
but
just
you
know,
using
controller
based
established,
MPLS
forwarding
or
when
we
go
to
v6.
You
know
controller
based
traffic
engineering
of
existing
v6
Nautica's.
Now,
okay,
point
ik.
M
Okay,
so
here's
a
example
of
global
optimization.
So
previously
we
had
candidate
Pat
one,
and
then
there
is
a
failure
which
was
going
ABC.
Now
there
is
a
failure
between
B
and
C,
so
the
controller
kind
of
realizes
that
in
the
draft
there
is
a
fast
reroute
that
he
can
actually
do
a
fast
reroute
between
link
protection
and
you
can
go
through
G
to
make
it
all
the
way
back
up
to
C.
But
then
the
controller
tries
to
optimize
that
path.
M
So
it's
gonna
create
an
second
instance
for
the
same
candidate
path
and
it's
gonna
nail
down
the
replication
segments
for
that
second
instance
throughout
the
network.
So
basically
what
that
means,
that
is
on
each
note:
C
G,
D
and
E
you're,
going
to
have
to
replication
segment
one
for
the
previous
primary
one
and
one
for
the
instance
to
LSB
ID
two
throughout
the
network,
when
the
second
instance
is
nailed
down
throughout
the
network.
M
So
here's
another
example
with
regard
to
the
candidate
pad
itself:
you
want
to
have
LSP
redundancy.
You
want
to
give
different
preferences,
so
there's
a
candidate
path
with
preference
1000
there
is
a
candidate
pad
with
preference
100
by
the
way
that
letter
flashing
should
shouldn't
be
in
this
slide.
M
Think
the
the
seat
comment
that
was
that
was
put
under
the
table.
You
know
we
can
definitely
discuss
that.
The
reason
that
we
decided
to
go
with
replication
series,
obviously
because
we
had
an
innerspring
right.
So
so
what
are
we
trying
to
achieve
with
with
this
draft?
If
you
could
go
to
the
next
slide,
please
it's
just.
K
Just
a
quick
comment:
right
I
mean
that
either
you
can,
you
can
do
I
think
what
is
less
work
and
in
pitches
up
to
the
people
who
already
got
MPLS
multicast
deployed
whether
it's
RSVP
T
or
ml
DP.
By
naming
this,
what
I
think
it
is,
which
is
you
know,
controller
based,
MPLS,
multicast
or
you're.
Trying
to
you
know,
go
through
more
hoops
and
making
it.
You
know
sound
like
SR,
because
it's
a
better
marketing
term,
which
I
think
is
where
this
was
coming
from
I.
N
Understood
I
do
have
a
question:
are
these
SIDS
so
because
III
confess
I
read
it
and
I
inferred
from
my
reading
and
I'm
I,
probably
skipped
many
words
in
the
process
of
reading,
because
I
was
an
early
that
day,
like
I,
usually
am
I
I
presumed
that
they
were
SIDS,
so
I
I
thought
there
was.
It
would
be
a
sit
at
D
and
a
sit
at
E
and
and
so
on
upstream,
towards
the
root
for
every
point
in
the
network,
where
some
sort
of
multicast
awareness
was
required
and
that
these
were
indices
into
a
table.
M
The
thing
we
all
know
when
it
comes
to
a
spring
and
segment
routing
you
can
go
on
and
pls
back
on.
You
can
start
stacking
up,
sits
right.
What
is
a
sit?
It
identifies
a
resource
within
the
network.
What
are
the
resources
right?
It's
adjacency,
see
and
know
what
see
and
based
on
the
label
stack.
You
can
traffic
engineering
source
route,
your
LSP
throughout
the
entire
network
with
multicast.
You
cannot
grab
replication
seats
and
start
stacking
them
up.
M
The
reason
for
that
is
that
when
you
get
to
a
point
that
you
have
actually
you're
like
a
branching
point
in
multicast,
and
if
you
have
stacked
up
seats,
then
you
don't
know
on
north
direction,
which
seats
are
relevant
on
south
direction,
which
seats
are
relevant.
That's
the
issue
with
multicast.
That
said,
the
reason
that
we
keep
calling
a
CID
is
because
this
entire
idea
can
work
in
a
unicast.
M
It
could
be
actually
source
routing
source
spraying,
so
you
could
actually
go
on
the
head
and
router
create
a
replication
seat
and
that
replication
seat
is
actually
built
from
unicast
adjacency
seats,
binding
seats,
Nord
seats
all
the
way
to
the
leaf.
So
multi-hop
unicast
seats
all
the
way
to
the
leaf
and
the
leaf
has
another
replication
see
which
just
says
this
is
multicast
on
the
leaf,
that's
higher.
So
this
is
the
entire
idea.
That's
why
we
call
it
a
replication
seat
because
it's
really
identifying
a
multicast
resource,
a
multicast
seed
within
the
network.
M
N
N
M
N
K
As
I
said,
as
long
as
we
stick
with
MPLS,
the
distinction
of
whether
we
calling
it
MPLS
right
or
SIDS
is
a
lot
more
subtle,
but
the
problem
is
as
soon
as
we
starting
calling
its
it
we're
running
into
the
likely
dead
end.
Then
you
know
we're
doing
something:
a
lot
more
complicated
with
v6
right
as
opposed
to
keeping
you
know,
just
as
a
single
you
know
just
making
it
native
VC
three
established
by
the
controller
right
with
some.
You
know:
v6
multicast
destination,
address
where
every
existing
ipv6
multicast
router.
K
Could
you
know
from
the
controller
build
an
engineer
tree?
That's
basically,
you
know
if
you
want
to
have
backward
compatibility
right
for
people
that
like
to
do
things
from
the
controller.
That
is
the
only
thing
you'd
be
able
to
do
right
now,
anything
where
you
would
have
to
do
rewrites,
you
know
in
SR,
v6
on
every
hop
is
not
going
to
fly
with
any
of
the
existing
equipment.
B
N
I
can
go.
Let
me
put
it
I
think
you
need
to
unpack
FRR
and
a
bunch
of
other
stuff,
rather
than
skipping
it
over
to
sort
of
get
at
all
of
this
and
I
agree
on
there
and
and
I
think
that
it
would
be
really
good
if
we,
rather
than
having
an
oversimplified
presentation,
spend
some
time
thinking
about
this.
So
so.
M
K
The
argument
for
the
sit,
if
you
really
want
to
go
that
way,
right,
which
I'd
prefer
not
to
do,
because
if
I
want
to
talk
to
people
with
the
you
know
existing
deployments
with
MPLS,
that's
not
only
the
easier
solution
but
better
marketing
for
me,
but,
as
I
said,
the
difference
between
the
cities
when
it
goes
across
multiple
Hopf
and
then
basically
every
how
change
is
the
offset
right.
So
that's
basically
something
you
want
to
have
anyhow
right,
then
that's
a
good
argument
to
call
it.
Is
it
so
that
so,
when
we.
M
Started
with
this,
it
was
just
a
global
seed
that
represents
the
point
of
multi-point
three
right.
So
a
single
label
was
presenting
that
tree
on
every
single
router
right,
but
now
that
would
be
tree-sit
more
than
a
replication
sit.
Yes,
now
exactly
did
ya
need
to
net
get
new
glasses
I'm.
Sorry!
So
now,
when
it
comes
to
the
replication
see
each
one
of
these
router
can
have
its
own
seat
area.
If
you
will
can
have
its
own
bucket,
that
will
choose
the
label
from
that
bucket.
So.
M
K
M
M
So
then,
the
next
the
next
slide,
please.
So
the
next
step
is
I
think
we
had
the
the
sip
argument
in
in
the
spring
too.
So
this
the
next
step
is.
We
are
hoping
that
we
can
have
a
working
group
adaptation
in
came
and
work
on
this
whole
idea
and
in
the
pink
yeah
like
if
you
guys,
can
adopt
this
draft
on
the
pink
group.
You
know
I.
F
F
K
Just
we're
not
raising
their
hand
right
I
mean,
except
for
reading
all
the
details,
but
it
is
I
really
think
that
the
draft
the
way
you
presented
it
still
struggles
off
of
oil
defining
you
know
where
it
wants
to
be
right,
so
I'm
all
for
having
you
know
a
controller
based.
You
know
forwarding
scheme
for
existing
MPLS
multicast
hardware,
but
the
way
that
this
is
being
done.
B
N
I
think
that
it's
highly
premature
to
ask
for
working
group
adoption
I
think
that
at
some
point
down
the
road,
when
you've
actually
answered
a
bunch
of
these
questions
and
thought
about
it
more
and
maybe
gotten
some
more
participation
from
others
to
help
you
think
about
it.
It
could
work
out.
But
it's
way
too
soon
for
that.
M
F
H
F
You
need
to
sign
it
yeah.
Okay,
can
you
get
that
D
in
that'd?
Be
great?
Okay,
so
I
presented
this
draft
to
ITF
segoe,
so
I
don't
need
to
go
into
too
much
detail,
but
I'll
quickly
go
through
it.
It's
basically
trying
to
find
a
way
to
optimize
asserts
in
the
occasional
situation
where
you
could
have
a
lot
of
messages,
a
lot
of
certain
messages
on
a
land,
whether
it
be
in
an
exchange
or
some
other
type
of
environment
when
you've
got
a
lot
of
asserts.
F
This
is
a
way
that
you
can
pack
asserts
into
a
particular
packet
to
kind
of
reduce
the
reduce
the
traffic
on
a
particular
line.
If
you
can
go
to,
if
you
can
be
our
my
slide
guy,
so
this
that's
the
problem
and
just
go
to
the
next
one,
if
you
would
just
keep
going
alright,
so
there's
no
change
in
the
assert
state
machine.
We
do
develop
a
new
pinhole
option
for
assert
packing
and
we
have
two
different
ways.
If
we
decide
that
this
is
something
that
we
want
to
do.
F
A
F
A
F
So
that's
a
good
point,
won't
add
to
the
draft
if
we
pursue
it.
Thank
you.
So
this
is
a
simple
way
to
go
about
doing
it.
You
just
take
that
existing
assert
and
put
it
into
an
assert
record
and
add
it.
Several
of
these
asserts
records
into
one
particular
packet
need
there's
advantages
in
that
it
reduces
the
packets
on
the
land,
but
there's
disadvantages
because
the
disadvantage
is
that
you're,
you,
you
have
you
you're
wasting
the
payload,
because
many
of
the
packets
have
the
same
sourcing
group
next
slide,
and
this
is
the
packet
format.
F
Next
slide,
I
just
yeah.
This
is
the
more
involved
aggregating
packet
solution
where
you
are
aggregating
based
upon
the
source
address
of
the
Arpi
address
or
the
group
address,
and
so
you're,
not
you
say,
you're
more
efficient
in
the
packing
method,
but
it's
a
little
bit
more
involved
adds
complexity
next
slide,
and
this
is
the
packet
format.
Yeah,
that's
fine!
This
is
good
out
there
just
for
the
sake
of
time
yeah,
so
people
can
look
at
that
later.
So
there
was
a
lot
of
discussion
last
time.
F
I
presented
this
on
whether
this
is
something
that's
worth
doing
to
assert.
Should
we
pursue
it
or
just
leave,
asserts
alone?
Do
we
if
we
do
want
to
pursue
it,
so
we
replace
asserts
some
people
mention
that
you
really
just
don't
do
asserts
and
just
live
with
duplicates,
and
this
draft
is
saying
well,
there's
one
option
is
to
optimize
asserts,
and
so
there
was
some
people
who
mentioned
that
it
would
be.
You
know
this
could
be
a
good
idea,
there's
many
people.
F
That
said
this
is
probably
not
something
that's
worth
doing,
and
so
we
thought
we'd
just
bring
it
to
the
working
group
again,
since
it's
been
a
couple
working
groups
and
to
see
if
the
attitudes
changed
at
all.
If
there
is
interest
in
in
working
on
this,
if
so,
then
we
will
continue
to
work
on
it.
Any
comments.
A
Yes,
I
have
a
couple
of
comments
just
as
a
working
with
participants.
Yes,
so
sure
it
could
be
nice
to
get
completely,
but
I
think
we
have
to
live
with
asserts
in
my
scenarios
or
less
forever,
so
I
think
it's
I
think
it's
worth
optimizing
asserts
if
you
can't
get
waited
on
grades,
but
but
if
he
counts
them,
but
it's
better
to
optimize
it.
A
I
I
know
law
so
well
actual
issues
out
there
in
the
field,
where
there's
issues
with
a
cert
packets,
getting
dropped
and
stuff,
because
there's
just
too
many
asserts
and
if
you
drop
on
a
Start
packet,
bad
things
happen
like
duplication
and
stuff.
So
I
think
this
is
worth
doing.
I
mainly
have
two
comments.
One
is
a
lot
convinced
that
the
more
advanced
packing
is
necessary.
You
still
have
a
huge
benefits.
Just
with
us
simple
packing
I
mean
if
you
send
the
1500
byte
packet,
you
will
be
able
to
learn.
A
What's
the
math,
you
can
put
quite
a
few
a
search
until
one
packet.
If
you
do
jumbo
grants,
you
can
get
a
lot
more.
The
only
thing
is
I.
Don't
understand
in
your
advanced
format.
While
you
have
an
RP
address
there,
because
you
don't
tell
an
RP
address
in
the
starts
today:
sourcing
groups-
yeah,
you
want
just
source
of
the
serie
with
it's
like
an
start.