►
From YouTube: IETF108-PIM-20200728-1410
Description
PIM meeting session at IETF108
2020/07/28 1410
https://datatracker.ietf.org/meeting/108/proceedings/
A
B
Yeah,
if
you
look
at
the
bottom,
there's
like
this
red
recording,
oh
yeah,
yeah,
yeah,
yeah
yeah,
I
guess
we
can
maybe
circle
get
started.
A
Yeah,
I
don't
see
human,
but
that's
that's
fine.
We
got
a
few
minutes
for
free
before
he
gets
on
yeah.
B
All
right
so
welcome
to
itf
108
hope,
you're,
all
dressed
for
the
hot
madrid
weather.
B
So
you
should
all
know
about
the
note.
Well,
let's
see,
how
do
I
change
slides
here
to.
B
Okay
yeah,
so
this
is
the
note:
well
you're,
all
aware
of
that,
and
then
we'll
move
on
to
the
agenda.
B
So
yeah
mike
and
I
are
gonna-
tell
you
a
little
bit
about
what's
going
on
in
the
working
group
right
now
and
then
we
have
five
presentations.
After
that.
Any
comments
on
the
agenda.
B
So,
according
to
this,
we
might
finish
a
little
early,
but
we'll
see
what
actually
happens
sometimes
all
right.
So
then
I
guess
I'll
move
on
to
talk
a
little
bit
about
the
status,
so
the
working
group
drafts,
so
we
have
dear
lord
balancing
that
was
published
as
rbc8775.
B
I
think
that
took
us
about
eight
years
or
something
in
total
and
mostly
yeah,
yeah,
there's
various
factors
or
reasons
for
that,
but
at
least
it
got
published
in
the
end
we
got
two
or
three
two
young
drafts
now
that
already
have
been
approved
that
are
in
the
rfc
editors
queue
and
they
are
waiting
for
the
same
set
of
references.
I
think
basically
other
young
documents.
B
B
So
I'm
hoping
the
offers
will
work
on
a
new
revision
that
the
you
know
that
can
proceed
for
publication.
We
also
have
the
no
register
packing
draft
and
yeah.
We
didn't
do
a
good
enough
job,
reviewing
that
in
the
working
group.
The
ad
found
quite
a
few
issues
and
decided
to
return
it
to
us,
so
we
need
to
be
better
at
doing
a
for
a
review
in
a
working
group.
B
B
B
I
start
packing
yeah.
It
was
revised
in
march.
I
see
it
says,
discuss
this
meeting,
but
through
not
that
many
changes,
so
I
guess
we'll
discuss
it.
A
Yeah,
let
me
just
make
a
couple
of
comments
on
that.
So
that's
yi
song
and
I
any
song
is
on
a
call
here.
We
haven't
made
any
changes
since
march.
We
did
have
one
comment
from
stig
in
the
past
about
including
some
information
about
assert,
timers,
and
so
we've
been
thinking
about
that
we
aren't
making
any
changes
to
the
pin
a
search
state
machine.
A
So
we
don't
anticipate
there
being
a
need
to
change
anything
to
the
timers,
but
we
will
include
something
about
that
in
the
draft
and
we
will
include
that,
for
we
will
send
that
to
the
list.
The
draft,
just
as
logistics,
was
written
in
a
word
format
and
I
have
no
clue
how
to
do
that.
I'm
an
xml
guy,
so
I'm
in
the
process
of
converting
it
to
xml,
which
hopefully
isn't
shouldn't,
be
a
big
deal
and
then
I'll
be
able
to
do
some
editing
is
as
well
so
we'll
have
an
update
on
that
next
time.
B
All
right,
you
also
just
adopted
the
star
point
to
point
point
to
multi-point
policy,
so
we
did
an
adoption
call
for
this
document
a
few
months
back,
but
we
didn't
want
to
adopt
it
until
it
was
a
document
it
relies
on
what's
adopted
in
the
spring
working
group,
but
we
were
just
basically
we
were
agreeing
to
adopt
it.
B
Finally,
we
did
a
survey
on
igmp
version,
3
mlb
version
2
to
help
us
proceed
in
that
internet
standard
and
the
survey
got
yeah
finished
and
I
think
we
had
maybe
at
least
30
responses.
If
I
remember
correctly,
is
there
anyone
that
can
comment
on
that?
B
But
yeah
at
least
at
least
the
story
was
done,
so
I
think
the
next
steps
will
probably
be
to
go
through
those
results
and
and
present
them
summarize
them
to
their
working
group
and
also
find
out
how
that
should
affect
the
revising
the
document.
B
A
So
once
we
do,
that
stig
is.
I
can't
remember
how
we
did
this
before
with
the
pim
spec.
What
that
we
updated,
but
do
we
just
alvaro?
Do
we
just
send
that
to
you
and
say
we're
it's
not
ready
to
be
an
internet
standard.
B
Well,
at
least
we
we
in
the
working
group
need
to
figure
out
exactly
what
we
believe
should
be
the
new
person
right,
but
yeah
after
we
agree
what
what
we
want
to
publish
then
I
guess
I
don't
know
if
I'll
rather
alvaro.
Sorry,
I
can
comment
on
this.
Are
there
any
extra
steps
for
to
do
this?
D
Can
you
guys
hear
me?
Okay,
yeah,
yeah
yeah?
No,
you
got
it
right,
yeah.
So,
just
like
any
other
draft,
I
mean
the
only
big
thing
here
is
that
we're
moving
to
internal
standard.
D
So
you
know
in
general
what
we're
going
to
be
looking
for
is
that
there
are
not
a
lot
of
changes.
D
You
know
things
can
be
taken
out,
but
we
don't
want
to
see
a
lot
of
new
things
because
one
of
the
one
of
the
bars
we
want
to
go
over
is
that
is
stable,
right
and
implemented,
and
all
that
stuff
so
just
like
when
you
guys
went
for
pim
to
enter
a
standard,
but
there
weren't
a
lot
of
changes
there.
So
we
want
to
to
do
the
same
thing.
The
same
thing
here
but
yeah.
The
process
is
the
same
process.
C
B
Yeah
so
basically
yeah
there
shouldn't
be
any
new
stuff
just
clarifications
or
maybe
improving
the
wording
or
something
like
that:
yeah.
Okay.
So
that's
it
for
the
working
group
status.
B
So
do
you
have
a
human
here
now
yeah
human?
Are
you
ready
to
present.
B
B
C
A
B
C
A
C
C
With
that
said
all
right,
first
of
all,
thank
you
very
much
for
adopting
this
draft
in
in
pim.
We
think
that
this
is
a
great
working
group
to
work
on
this
graph
and
if
we
can
go
to
the
next
slide,
please
so
these
are
the
relevant
drafts
that
are
associated
to
this
point
to
multi-point
policy,
the
replication
segment.
You
guys
already
gave
a
overview.
It
was
adopted
by
the
spring.
C
It's
a
very
simple
concept
which
I'll
go
through
it
again
throughout
these
slides
the
point
to
multiplying
policy,
if
you
will
think
of
it
as
a
provider
tunnel
as
a
pimsie
and
that's
what
this
draft
is
all
about,
it
actually
intertwined
the
replication
segment
and
the
use
of
replication
segment
into
the
point.
To
multiply
policy
draft
as
well-
and
there
is
a
bunch
of
other
drafts
that
will
follow
up-
are
already
are
in
works.
A
Feel
about,
let's
do
it
now,
so
we
did
ping
the
spring
chairs
about
this
draft,
because
we
honestly
didn't
know
which
working
group
would
be
best
and
they
said
based
upon
just
the
intro
of
the
document
that
it
probably
unfortunately,
would
be
needed
to
be
in
spring
and
unfortunately,
just
they
said
just
because,
as
you
know,
there
have
a
lot
of
documents
and
it's
slower
moving
than
we
are
just
because
we
aren't,
as
is
pressed
with
so
many
documents,
but
they
did
say
that
if,
if
so,
what
you
may
want
to
consider
is
that
being
that
they
based
upon
the
intro,
it
looked
very
replication
segment
focused
you
may
want
to.
E
C
C
I
guess
one
way
to
to
tackle
this
is
we
can
create
two
drafts
out
of
it,
one
yang
model
for
point-to-multiplying
policy
and
one
for
replication
segment
and
then
bring
the
point
to
multi-point
policy
to
to
pin
working
group
and
leave
the
replication
segment
in
a
spring
again.
We,
I
think
we
are
open
to
ideas.
It
is
just
what
is
the
smoothest
way
forward,
so
the
next
one,
a
big
one
which
we
are
working
on,
is
the
mvpn
evpn
as
our
point
to
multiply.
C
C
So
there
are
a
couple
of
main
concepts
on
the
point
to
multiplying
policy
that
you
need
to
be
aware
of.
The
first
thing
is
the
canada
path
the
canada
pad.
We
tried
to
keep
it
in
line
with
the
unicast
candidate
path.
So
again,
each
policy
can
have
multiple
candidate
paths.
A
single
candidate
path
can
be
active
based
on
a
certain
characteria,
and
the
other
candidate
pass
can
be
act
as
a
redundant
candidate
path
to
the
active
one.
Each
candidate
path
can
be
engineered
traffic
engineered
from
the
root
to
the
leaf.
C
They
can
be
srlg
separated
from
each
other.
They
can
be
engineered
based
on
certain
characteria
bandwidth,
etc,
etc.
All
those
goodies
that
come
with
the
controller
will
fall
under
the
candidate
path,
implementation
and
under
each
candidate
path.
You
could
have
instances
so
basically
the
instance
is
the
lowest
hierarchy
in
the
point
to
multiplying
policy.
So
basically
it
is
the
point
to
multi-point
lsp.
If
you
will,
if
you're
talking
about
mpls
forwarding
it's
the
point
to
multiply
lsp,
that
is
at
the
core
of
the
instance
id.
So
basically,
the
incense
are
used
for
global
optimization.
C
If,
for
whatever
reason
under
a
candidate
path,
that
is
active,
one
instance
is
not
optimized
because
of
igp
or
because
of
any
kind
of
cspf
calculation,
the
controller
can
create
a
second
instance
under
that
candidate
path
and
it
can
go
on
the
route
and
it
can
do
a
make
before
break
between
one
instance
and
the
new,
the
newly
instantiated
instance
to
go
from
to
do
a
global,
optimization
next
slide.
Please.
C
So
at
the
base
of
it,
it's
the
replication
segment
which
was
adopted
on
the
spring.
What
the
replication
segment
is.
It
actually
contains
the
forwarding
information,
whether
those
are
the
label
information
going
forward
when
it
comes
to
srv6
the
srv6
information,
the
next
hop
information
or
even
the
fast
reroute
information.
All
of
them
are
under
the
replication
segment.
C
C
It
can
be
connected
directly
to
each
other,
so
a
segment
is
actually
identifying
a
a
point
to
multi-point
instruction
at
each
node.
They
can
be
connected
to
each
other
when
nodes
are
actually
directly
connected
or
two
replication
segments
can
be
connected
to
each
other
via
a
unicast
sr
domain
and
when
they
are
connected
through
the
unicast
sr
domain.
All
the
goodies
that
comes
with
the
unique
assets
are
traffic
engineering,
etc,
etc.
Node
adjacency
node
seats,
adjacency
seats.
All
those
goodies
will
actually
apply
on
the
path
to
connect
the
two
replication
segments.
C
So
again,
we
are
not
trying
to
define
a
tunneling
mechanism.
We
are
not
trying
to
stack
replication
segments
on
top
of
each
other.
We
are
just
each
replication
segment
needs
to
be
at
the
bottom
of
the
stack.
Usually,
a
replication
segment
is
not
a
stacked
at
all,
except
there
are
some
corner
cases
which
I'll
go
through
like
fast
reroute
later.
F
G
G
But
yeah
yeah,
but
the
problem
is
you
can't
even
join
with
a
different
jabra
application
in
chat
or.
F
C
C
Okay,
so
where
I
was
was
with
the
I
don't
know
how
much
you
heard
the
so.
I
think
the
last
thing
I
was
mentioning
is
that
the
replication
segments-
usually
we
are
not
designing
them
to
be
stacked
up
on
top
of
each
other.
There
could
be
a
very
specific
case
with
aggregate
replication
segment
that
we
can
use
for
fast
rera
that
could
stack
up
replication
segment
on
top
of
each
other,
but
for
the
majority
of
cases,
replication
segments
are
a
single
seat
that
arrive
label
that
arrive
into
the
node.
C
C
So
there
is
this
concept
of
shared
replication
segment
as
well,
which
I
explained
as
a
previous
slide:
a
replication
segment,
a
normal
replication
segment
is
actually
uses
the
tree
id
and
the
root
id
and
a
bunch
of
other
identifier
to
be
identified
on
each
node
on
the
root,
transit
and
the
leaf,
but
the
shared
replication
segment,
because
it
can
aggregate
multiple
replication
segment
and
one
of
the
use
cases,
as
I
mentioned,
is
the
facility
fast
reroute
doesn't
really
have
a
tree
id
because
if
you
have
the
tree
id,
that
means
that
you
need
to
be
binded
to
a
specific
point.
C
To
multiply
three.
This
puppy
can
actually
transfer
multiple
point
to
multiplying
trees
within
itself.
So
that's
why
it
doesn't
have
the
tree
id.
As
for
the
three
id
sorry
for
the
root
id.
Also,
we
use
a
zero
root
id
to
identify
it,
so
it
has
a
unique
way
of
identification
and,
as
you
will
see
from
the
example
later
on,
it
can
be
used
for
multiple
applications
like
fastview.
C
Next
next
slide,
please.
C
So.
This
is
a
very
high
level
picture
of
the
point
to
multiply
policy
and
the
replication
segment.
All
in
a
single
slide,
so
you
can
see
the
point.
The
multiplying
policy
is
on
the
root.
You
could
have
multiple
candidate
pad,
as
it
was
explained
previously.
The
instances
under
each
candidate
path
can
be
used
for
global.
Optimization
make
a
break
of
that
single
candidate
path.
C
If
there
is
any
node
in
between
two
replication
segment,
that
does
not
support
the
replication
segment.
The
unicast
sr
policy
can
be
used
to
connect
the
replication
segment
and
you
can
use
seed
lists,
start
putting
up
stacking
up
unicast
labels
to
ensure
that
there's
traffic
engineering
between
these
two
replication
segments
next
slide.
Please.
C
So
as
you
can
see
in
the
yang
model,
there
is
the
point
to
multiplying
policy
on
one
end
with
all
the
stuff
that
I
already
explained:
the
candidate
path,
the
instance
id,
etc,
etc,
and
on
the
replication
segment
you
do
have
the
next
hop
information,
the
incoming
label.
And
then,
if
you
look
at
the
the
next
hop
information,
you
can
see
that
there
is
a
protection
next
hop
which
the
protection
next
hub
is
used
for
fast
reroute,
so
again
between
each
replication
segment.
C
C
We
can
look
at
node
protection,
but
that
brings
up
a
bigger
bucket
of
worms
because
for
node
protection
on
the
on
a
node
that
is
replicating,
it
could
create
some
complexity,
which
we
need
to
figure
out
in
this
working
group,
and
this
is
where
I
had
the
question
that
whether
we
want
to
split
up
these
two
young
models,
one
for
point
to
multiply
policy
and
one
for
replication
segment,
which
we
can
have
a
discussion
at
the
end
of
the
presentation.
Next
slide.
Please.
C
So
this
gives
a
a
very
high
level
example
of
what
happens
when
a
node
does
not
support
the
replication
segment
in
this
case
is
node
b.
So
in
this
example,
as
you
can
see,
node
a
has
the
point
to
multiply
policy,
because
it's
the
root,
node
and
rook,
node
c
and
g
are
the
transit
node.
That
support
the
replication
policy
and
d
and
e
are
the
leafs
and
c
is
also
a
bud
node
here.
C
So
in
this
case
on
a
you
create
the
point
to
multiply
policy,
you
configure
a
replication
segment
on
a
with
a
seedless
that
seedless
can
use
a
adjacency
seed
toward
b
or
it
could
actually
use
a
node
seed
of
b.
On
top
of
the
stack
and
c,
which
is
the
next
replication
segment
on
the
bottom
of
the
stack,
so
then
the
the
packet
is
issued
out
of
the
the
corresponding
well,
the
packet
is
actually
steered.
C
We
are
the
unicast
seat
list
if
you
will
arrives
to
b
and
then
from
b,
based
on
the
note
seed
or
the
replication
c.
Sorry,
based
on
the
note
seed
or
the
adjacency
c,
it
actually
arrives
to
c
by
the
time
that
the
packet
arrives
to
see
all
the
unicast
labels
are
actually
popped.
So
what
we
are
left
with
is
the
next
replication
segment
on
the
c.
C
C
Well,
actually,
we
can
skip
this
slide
for
the
sake
of
time.
Maybe
we
can
go
to
the
next
one,
please
so
here's
an
example
of-
and
I
almost
forget,
the
the
name
of
it-
the
aggregation
replication
segment
or
what
did
I
call
it
in
the
other
slide
anyway,
the
aggregation,
the
replication
segment
and
aggregate
multiple
lsps
to
use
for
fast
reroute.
So
in
this
case,
as
you
can
see,
on
c
d,
the
link
is
really
protected
via
cgd.
C
For
your
point,
to
multiply
and
lsp
is
going
from
c
to
d,
so
any
lsp
that
goes
from
c
to
d.
Any
replication
c
that
goes
from
c
to
d
can
actually
take
this
bypass
tunnel
that
is
created
via
another
replication
segment.
Toward
g
and
g
can
actually
use
implicit
null
to
send
the
replication
segment
c.
All
the
way
to
the
d-
and
you
can
see
the
label
is
stacked
there.
C
So
that's
another
use
of
replication
segment
when
sr
unicast
sr
is
not
into
place
next
slide.
Please,
and
I
think
I'm
gonna
skip
this
slide
too.
This
is
only
the
case
when
there
is
no
implicit
now
so
the
next
step.
Unfortunately,
I
did
not
update
it
again.
Thank
you
for
adopting
this
draft
and
I
guess
the
next
step
is.
A
You
so,
as
far
as
the
yang
portion
of
this
presentation
is
concerned,
I
don't
know
of
what
further
discussion
we
need
to
have.
It
does
make
sense
that
it
splitting
it,
which
would
be
a
pain
into
both
the
policy
type
of
yang,
as
well
as
a
replication
side
of
the
yang.
A
It
may
be
better
to
do
that
since
that's
how
the
drafts
are
split
but-
and
it
would
be
easy
to,
I
would
think,
as
a
working
group
decide,
whether
to
adopt
it
or
not
and
spring,
probably
wouldn't
do
any
pushback
in
that
case,
any
other
thoughts
on
that.
B
C
So
I
mean
I
need
to
have
a
talk
with
my
co-workers,
who
I
don't
think
I
want
to
just
answer
quarters.
I
don't
want
to
answer
that
question
right
on
the
spot,
but,
as
you
saw
the
slide,
I
don't
see
so
there
needs
to
be
a
thin
glue
layer
right
that
that
associates
the
replication
segment
to
point
to
multiple
policy,
and
I
think
that
thin
glue
layer
is
already
in
the
point
of
multiplying
policy.
Draft.
C
B
Yeah,
it's
maybe
not
a
big
deal,
but
but
the
thing
is:
if
there
were
a
normative
reference
right
between
the
two
young
models,
then
even
if
we
did
one
draft
in
each
working
group,
they
would
have
to
wait
for
each
other.
Yes
yeah
it
could
be
but
yeah.
Maybe
you
can
avoid
that.
A
C
C
A
Yeah,
so
aside
from
the
yang
one,
the
one,
the
the
point
to
multiply
policy
draft,
which
we've
recently
adopted,
it
already
has
a
dependence
on
the
replication
draft,
that's
in
spring,
which
has
also
been
adopted
in
spring.
So
the
yang,
if
we
were
to
do
a
yang
point
to
multi-point
policy
draft
in
here
and
spring
to
do
their
replication
yang
draft.
B
Yeah,
yes,
I
think
it,
it
might
make
sense
to
you,
know,
split
the
documents
and
do
them
in
each
working
group
just
wanted
to
point
out
that
there
might
be.
You
know
we
met.
You
know
some
there's
some
dependency
between
these
documents,
so
they
can't
just
be
published
independently
of
each
other.
Perhaps
but,
but
still
I
mean
it
might
be
good
to
do
the
work
in
with
separate
drafts
and
separate
working
groups.
B
C
Okay,
I
mean
again,
that's
doable
from
our
perspective,
have
a
talk
with
our
co-authors
as
well,
and
if
that's
I,
I
can
do
that
for
our
next
idea
for
in
next
couple
of
weeks
for
sure.
G
This
this
is
the
directly
talk,
don't
go
to
the
queue.
G
Hit
it
yeah,
no,
so
with
respect
to
how
do
we
coordinate
with
spring
on
this
in
general?
Right,
I
I
think
would
be
good
for
you
know
spring
to
you
know,
to
be
pulled
in
as
much
as
possible
and
on
their
expertise
with
the
overall
framework,
so
that
we,
you
know
when
we
go
to
the
ietf
reviewer,
so
that
we
don't
have
these
issues
later
on.
B
Yeah
so
even
yeah,
I
was
going
to
say
even
like
with
the
the
two
drafts
you
already
have
in
adopted
in
respective
working
groups.
It's
still
good
to
have
a
cross
review
of
those
those
drafts
and
and
and
maybe
also
lost
calls
across
the
working
groups
just
to
make
sure
that
we
get
everyone
to
review.
G
Them
yeah,
I
mean
one.
One
crazy
thing
would
be
to
dedicate
a
shepherd
who
is
not
in
pym
but
in
spring,
so
that
somebody
major
contributors
there
to
force
at
least
one
person.
You
know
who
doesn't
otherwise,
because
I
think
that
the
multicast
feedback
to
be
had
here
will
be
will
be
good
but
yeah.
The
the
non-multicast
feedback
is
what
we
should
worry.
B
Thanks
yeah,
thank
you
and
okay,
so
next
on
the
agenda
should
be.
Let's
see
this
draft
right
mike
yeah.
H
H
H
H
H
H
So
the
the
solution
we
proposed
here
is
that
this
is
solution
is
more,
is
closer
to
no
space
in
the
network,
and
we
just
need
to
send
the
sr
policy
which
is
see
the
list
into
the
increased
node
of
sr.
P
tone
p
pass.
H
H
H
H
Here
we
will,
for
example,
we
have
synthesis
for
tree
for
piton
b3
is
a
p1
and
p2m
and
the
p3m
and
all
the
leaf
loads,
l1mr2m
and
then
r4
r4n.
So
this
is
just
represented
or
you
encode,
the
piton
p
path.
So
after
the
english
know
to
receive
this
list
so
inverse.
Node
well
set
the
designation
da
to
the
p1n.
H
H
H
So
this
gave
up
detail,
encodings
or
details
see
the
list,
so
you
see
the
list
where
for
each
each
each
seed?
We
have
two
argument:
one
is
the
number
of
branches,
for
example,
for
lone
p1.
H
It
has
two
branches,
so
two
or
two
light
swords
which
is
a
p2
and
the
p3.
So
the
number
of
branches
we
have
two
in
the
p1n
so
use
this
information.
We
know
we
will
duplicate
the
package
two
two
times
and
one
for
p2
and
one
for
p3
so
and
then
p.
P1
will
assume
that
this
package
to
p2
and
p3
for
these
two
packets,
because
each
each
node,
p1,
p2
and
p3,
is
a
branch
head
of
p1
symmetry
head.
H
So
we
also
have
the
information
for
the
segment
these
for
those
sub
trees.
So,
for
example,
here
we
have
two
sub
trees.
One
is
a
represented
by
blue,
that's
a
seeds
and
the
other
one
is
written
by
red
right
seeds
so
use
this
information.
H
So
this
page
gives
more
details
so
here
after
p1
receives
the
package
and
then
the
destination
da
is
the
market
seat
of
p1.
So
in
this
p1
dash
m,
we
have
information
that
two
number
of
branches
is
two.
So
p1
knows
that
there's
two
branches
on
the
p1,
so
we
know
these
two
parentheses.
The
id
for
these
two
paragraphs
is
just
in
the
see
the
list,
which
is
the
p2
dash
m
and
the
p3
dot
share,
so
p1
can
duplicate
package
and
then
send
the
package
to
p2
and
the
p3.
H
So,
on
the
three
on
p3,
the
seed
list
is
represented
by
those
red
ones,
so
p1
with
duplicate
package
and
then
send
the
package
for
p2
and
p3.
And
then
this
package
we
will
have
new
csvs,
which
constructed
from
the
original
one
and
then
deliver
the
package
to
p2
and
then
similarly
deliver
target
to
p3.
And
this
will
continue
until
this
package
reaches
the
destination
node,
which
is
all
the
leaf
loads
of
the.
H
I
think
this
this
idea
is
clear
and
also,
I
think,
it's
simple,
and
I
would
like
to
have
an
option
call.
B
So
can
you
say
something
about
what
is
the
status
for
s4
v6
in
general,.
H
Yeah,
I
think
united
here
for
sr
v6
unicast
as
a
unicast.
I
think
the
from
from
standards
from
view-
and
I
think
it's
a
the
draft-
is
all
what
they
are
right.
B
So
those
drafts
are
they
adopted
by
six
men
or
which
working
group
or.
H
A
Okay,
so
stick
there
is
a
yeah.
This
is
what
you're
talking
about.
There's
an
srv6
network
programming
draft,
it's
on
version
16
in
spring,
it's
been
worked
on.
It
looks
like
for
quite
a
long
time.
Okay,.
B
Okay,
so
I'm
kind
of
normally
it
would
have
liked,
I
think,
to
see,
show
hands.
So
many
people
have
read
the
document
and
so
on.
That's
a
little
difficult
right
now.
B
C
Hi
this
is
the
this
is
human.
I
I
apologize.
I
I
did
try
to
get
into
the
queue,
but
may
I
ask
a
question
yeah,
please,
okay,
thank
you.
So
I
did
read
the
document,
a
very
interesting
concept.
Thank
you.
I
just
had
a
question.
I
just
wanted
to
ensure
that
my
understanding
is
correct,
so
each
one
of
those
seeds
so
on
the
root
you're,
putting
all
these
srv6
seeds
on
top
of
each
other.
C
So
does
that
mean
that
on
the
root
we
could
have,
you
know
six
or
seven
depending
on
how
long
is
the
the
three
six
or
seven
different
seats
stack
on
top
of
each
other.
H
C
C
H
Including
the
structure
of
the
tree
and
then
according
those,
according
to
the
information
in
the
stated
list,
each
node
will
know
the
next
hop.
I
mean
the
sub
tree
under
itself
and
then
duplicate
and
send
the
package
to
these
lights
off
nodes.
So
this
way
it
goes
on
and
on
until
the
package
reaches
the
destinations
with
the
defaults.
C
Okay,
so
is
it
the?
Is
it
safe
to
say
that
your
seedless
at
minimum
needs
to
be?
If
you
want
to
do
like
ingress
replication
at
minimum,
it
needs
to
be
all
the
leaf
routers
that
want
to
receive
the
packets
from
the
route.
C
So
again
me
just
trying
to
understand,
so
the
concept
is
clear
to
everybody.
So
let's
say
I
have
three
leaf:
router
right
so
and
I
have
a
route
and
it's
a
very
simple
network
that
there's
one
one
route,
one
transit
node
and
the
transit
node
is
connected
to
the
three
leaf
routers,
so
at
minimum.
In
this
case,
I
need
to
push
three
seats
on
top
of
the
packet
for
the
transit
node,
to
figure
out
how
where
each
replication
of
the
packet
has
to
go.
Is
that
exactly
right?
Okay,
yeah.
H
E
So
what
about
the
overhead
problem?
So
if
we
have,
for
example,
we
have
a
100
node
in
the
p203,
so
it's
it's
going
to
be
a
very
big
packet
and
a
very
long
list.
Yeah,
that's
a
good.
H
E
Yeah,
okay
and
my
second
question
is
about
the
I
just
want
to
make
sure
I
understand
you're
right
and
it's
about
the
page,
five,
the
format
of
the
multicast
seat
and
we
carry
the
number
of
branches
and
the
number
of
sets
or
in
subtree
in
the
argument
part.
So
are
we
going
to
define
a
new
kind
of
network
programming
function?
H
E
H
Yeah,
this
is
not
new,
because
for
c
right
we
have
locator
function
arguments
so
those
are
structures.
We
just
define
some
arguments
for
this
special
purpose.
H
E
I
Yes,
can
you
hear
me
guys
yeah?
Okay,
so
I
just
want
to
follow
up
on
our
previous
questions,
so
you
mentioned
multiple
times
with
multicast.
It
emma
is
my
understanding
correct,
but
this
is
a
new
type
of
sheet
which
you
want
to
define
in
the
same
draft,
or
this
is
something
which
defined
elsewhere
and
you
just
gonna
reuse.
It.
H
H
Basically,
I
see
we
have
some.
We
have
a
few
drafts
they're
talking
about
different
type
of
seeds,
for
example.
For
comparison,
they
propose
some
kind
of
a
seed
from
a
supposed
block
for
covering,
and
then
this
I
think,
a
multicast
seed
is
some
kind
of
special
seeds.
You
just
need
to
allocate
some
called
some
corn
point,
maybe
from
sabrina
somewhere.
I
H
I
think
from
I
think
that
we
can
define
different
seeds
right
because
we
have
a.
We
have
this
kind
of
system
located
whatever
seeds,
they
have
different
functions
and
then
those
are
provided
the
architecture
there.
B
It
sounds
to
me
like
we
know
me:
there's
there's
yeah
a
fair
amount
of
things
to
to
discuss
here
and
both
myself
and
maybe
some
others
need
to
also
read
this
document
more
carefully.
Think
about
this,
so
I
think
I
would
like
to
take
the
discussion
to
the
list.
You
have
time
for
a
few
more
questions
here.
If
anyone
comments,
if
people
like
that.
C
Yeah
just
one
one
question:
this
is
human
with
with
the
the
same
type
of
question
as
defining
new
concepts.
I'm
not
sure
if
there
is
this
new
concept
of
splitting
seeds
and
then
putting
them
back
together.
C
Based
on
on
a
replication
note,
maybe
I'm
wrong,
but
the
way
I'm
reading
the
draft
is
that
when
you
get
in
this
example,
if
you
get
onto
the
p1,
then
you
need
to
grab
your
seed
list
and
somehow
split
it
into
two
and
then
create
appropriate
seed
list
toward
p2
and
p5
in
in
this
diagram.
That
is
here
so
coming
from
the
root
the
seedless
will
contain.
C
H
C
So
I
think
that's
another
concept
that
needs
to
be
very
well
defined
that
how
that
slicing
and
dicing
should
happen
at
each
one
of
these
transit
notes.
If
I'm
not
mistaken,
I
don't
think
there
is
such
thing
out
there
today.
H
H
C
Yeah,
I
I
think
I
understand
that
concept.
I
I
I
get
that,
but
I
think
it's
important
to
verify
that
for
silicon
merchants.
Right
I
mean
eventually,
I
think
this
needs
this
needs
to
be
implemented
in
the
data
path
which
that
that's
the
part
that
you
know.
I
think
we
need
to
ensure
that
this
implementation
is
done
correctly
in
the
data
path.
B
J
Ac
lindem,
cisco
systems-
I
think
the
abstract
needs
to
bury
the
abstract
network
or
introduction
needs
to
very
precisely
define
the
differences
with
just
the
sr
replications
segment.
You
know
why
this
you
know
you
know
what
are
what
what
are
the
changes?
I
hopefully
no
changes,
but
what
are
the
extensions
to
it?
Because
it's
not
clear
just
from
the
title.
H
H
B
B
And
hope
yeah
everyone
that
is
interested
myself
included.
I
hope,
can
read
the
draft
more
horribly
and
and
yeah
see
what
they
think
about
it.
A
B
B
So
first
of
all,
this
is
a
generic
way
of
extending
igmp
versus
three
and
emily
versus
two,
so
those
rfcs
already
have
the
concept
of
additional
data,
but
it's
basically
saying
that
implementation
should
ignore
any
additional
data
present,
but
it
allows
us
to
to
extend
those
protocols
by
putting
something
in
the
additional
data
it
will
be
ignored
by
existing
implementations,
but
implementations
that
know
this
extension
supporters
extension
they
can
handle
it
properly
and
what
is
changed
in
this
draft
is
that
we
are
trying
to
use
tlv
so
that
we
can
have
multi
in
theory,
have
multiple
options
in
the
extension,
not
just
a
single
extension
type,
there's
also
a
registry
to
keep
track
of
which
types
are
being
assigned
for
what
purpose
and
there's
a
beer
extension
which
motivated
this
that
defines
one
such
type,
let's
see.
B
Otherwise,
we
are
proposing
using
a
reserved
bit
in
the
query
on
report
messages
to
indicate
that
this
extension
is
being
used.
Otherwise,
it's
hard
for
implementations
to
know
if
the
additional
data
is
just
some
other
data
that
someone
put
there
if
it
actually
is
tl
as
specified
in
this
document.
B
B
B
This
is
what
the
blue
part
would
look
like.
It's
basically
just
a
list
of
tlvs
similar
to
a
pim
hello.
You
can
say
one
thing
here
that,
maybe
is
not
obvious,
is
that
we
have
this
total
extension
length
field.
B
By
doing
that,
we
we
allow
for
well
two
things
one
is
we
can
do
some
additional
consistency
check
to
see
that
the
length
adds
up,
but
maybe
more
importantly,
is
that
you
could,
in
theory,
if
you
later
want
to
extend
those
protocols,
maybe
on
igmp
version
4
or
whatever.
It's
possible
to
have
additional
data
if
you
wanted,
after
these
extensions.
B
B
There's
also
some
text
in
this
document
explaining
that,
since
existing
implementations
don't
support
any
of
this
and
it
might
be
hard
to
deploy
any
news
you
know
get
hosts
to
put
support
and
extensions,
and
so
on,
it's
important
that
when
we
define
and
use
this
tlvs
that
it
kind
of
co-exists
between
hosts
that
don't
support
it
and
hosts
that
do
support
it
for
the
proposed
beer
usage,
it's
pretty
simple,
because
there's
no
existing
implementations
that
support
this
survey,
so
it
will
be
new
implementations,
so
would
like
to
get
some
more
input.
B
If
I
can,
if
you
have
any
comments-
or
I
would
need
more
people
to
review
this,
you
could
maybe
do
a
working
group
last
call
that
sometimes
helps
to
get
more
people
to
review.
I
don't
know
what
you
think
mike
the
the
main
thing
is.
I
would
like
more
input,
but
beer
is
waiting
on
this,
so
I'm
also
hoping
to
to
get
this
done
soon.
A
Yeah
speaking
of
beer-
and
I
really
don't
know
if
this
is
necessary-
not
but
you
may,
I
know
you
include
a
pointer
to
a
beer
specific
information
right,
but
sometimes
it
helps
to.
B
A
The
actual
example
about
extending
igp
mld
in
the
document
itself
right
now,
just
a
bit
more.
B
B
Yeah
the
the
other
thing,
though,
is
I
mean
the
beer
extension
is
what
we
are
considering
now,
but
then
there
could
be
other
other
extensions
in
the
future.
Of
course,.
B
B
So
as
as
an
example,
though
at
least
yeah,
you
need
to
be
very
aware
of
that
that
some
implementations
may
not
yeah
may
just
ignore
an
extension,
and
is
it
okay?
If
one
host,
for
instance,
ignores
the
tlb
and
another
host
does
process
a
tlb,
but
yeah
this
from
a
protocol
point
of
view,
I
feel
like
it's
pretty
simple
it's
my
main
concern
is
maybe,
if
there's
any
more
guidance
that
should
be
in
there.
B
B
A
A
So
that
sounds
good.
That
does
sound
good,
let's
I'll
I'll
I'll.
Take
it
the
list
since
you're
the
author
on
this.
As
far
as
as
far
as.
A
K
B
A
B
Okay,
yeah
I'll
I'll,
yeah
I'll
I'll
think
about
how
to
address
that
and
and
and
try
to
yeah
ask
people
for
more
comments
on
the
list.
Okay,
sure
thanks.
A
B
See
did
this
work.
B
A
Okay
share
your
video
keon.
F
Right
so
so
I
I
sent
an
email
out
to
the
work
group
and
I
guess
mike
had
asked
you
know.
I
guess
tonight
an
interesting
topic.
You
know
multicast
over
the
internet,
reliable
multicast,
and
this
has
been
an
issue-
I
guess
kind
of
from
day
one
you
know
their
pos,
so
I
thought
I'd
put
a
slide
back
together.
F
Just
in
regards
to
that-
and
I
guess
late
last
night
mike,
you
said
an
email
about
that
pragmatic
multicast-
about
that
reliable,
a
multicast
transport
group-
that's
been
closed,
but
possibly
maybe
reviving
that.
I
guess
so.
This
kind
of
plays
into
that-
and
just
you
know
some
ideas
of-
I
guess
qos
on
the
internet.
I
guess
and
really
really
where
the
kind
of
where
the
gap
is
with
the
udp
and
unfortunately,
multicast
is
gdp
and
that's
kind
of
where
we
go
fall
with
the
gap.
F
So
so,
just
at
a
higher
level,
like
I
said,
most
internet
providers-
and
this
has
kind
of
been-
you
know-
kind
of
the
way
it's
been
for
a
long
time,
all
traffic
of
the
internet's
it's
best
effort,
so
there's
no
preferential
treatment.
You
know
the
need
really
hasn't
had
have
hasn't
really
been,
and
you
know
with
the
providers,
it's
really
been
high.
You
know,
high
capacity
range.
F
You've
got
a
lot
of
tons
of
bandwidth,
so
you
know
anything,
that's
ccp,
based
you
don't
run
into
issues,
it's
really
the
edp
stuff
and
that's
where
and
especially
multicast,
because
it's
a
streaming
video
and
that's
where
you
run
into
problems.
So
that's
that's
kind
of
really
the
really
that
really
they've
just
been
trying
to
see
how
how
you
could
possibly
have
reliable
multitasker
of
the
internet
and
then
and
the
theory
behind.
F
Is
it
even
possible
to
actually
have
to
you
know
a
coordinated
effort
by
all
the
service
providers
to
even
provide
key
os?
You
know
across
the
internet
that
you
know
everyone
marching
to
the
same
tos
policy,
marketing
and
scheduling,
and
the
big
deal
that
happened
with
multicast.
Is
that
if
you
were,
if
you
drop
a
frame
and
it
if
it
ends
up
being
a
reference
frame,
you
know
that
you
drop
that
reference
print
frame
of
the
pointer
within
the
buffer,
and
then
you
start
buffering.
So
you
don't
you
end
up
end
up.
F
Basically
stopping
the
video
stops
playing
and
now
you're
just
buffering.
So
that's
really
the
big
impact
so
really
end
to
end
qos
for
udp-based.
You
know
streaming.
Video
is
really
a
requirement
to
really
make
it
make
it
viable
and
that
and
that's
really
where
the
the
work
that
mike
had
worked
with
the
reliable
multitask
transport
and
then
pragmatic,
multicast
kind
of
came
about
like
20
some
years
ago,
but
it
seems
like
that's
still
relevant
even
today
that
you
know
could
really
have
you
know
it's
really
there's
two
pieces
of
the
puzzle.
F
One
is
you
either
go
that
route
and
have
some
kind
of
feedback
mechanism
that
provides
like
that
math
or
act
that
you
know
when
you
drop
a
packet
or
you
have
to
os
over.
You
know,
you
know
across
service
providers,
go
ahead
to
the
next
next
next.
F
F
You
know
I
looked
looked
at
like
let's
say,
like
big
leaf
is
one
that
I
kind
of
looked.
I
did
some
research
looked
up
in
recent
and
they
they
basically
have
like
a
tunnel
service.
So
there
are
some
types
that
can
give
a
somewhat
pseudo
qos
like
a
policy
and
they're
definitely
you're
paying
like
a
premium.
So
it's
not
like
free.
You
actually
have
to
pay,
and
it's
all
you
know,
I
guess,
with
net
neutrality
and
you
know
having
to
pay
for
you
know
better
service.
F
I
guess,
if
you
pay
more,
you
get
more
so
kind
of
that's
where
that
road
goes
so
sdn,
for
example.
I
guess
you
know
you
know
in
terms
of
multicast,
you
know.
So
that's
that's
that
works.
Well.
I
guess,
for
let's
say
I
guess,
for
internal
traffic
or
internet
traffic.
F
I
guess
it's
tunnel
traffic
in
this
overlay,
but
with
for
native
multicast
because
you're,
let's
say
a
broadband
customer
just
sitting
off
of
your
you
know:
fiber
fiber
to
the
desktop
or
whatever
and
connect
it
in
and
you're
trying
to
get
your
video
to
go,
but
you're
native
and
you're
not
really
going
over
an
overlay
tunnel
so
sdn
for
let's
say
broadband
using
it
doesn't
really
doesn't
really
help.
You
really
need
that
qos
at
qs
and
it
and
it's
two
two
pieces
to
the
qs
puzzle,
I'm
good
to
the
next
slide.
F
So
this
is
just
an
example
of
kind
of
really
the
two
pieces
of
the
puzzle
related
to
kios.
So
you
got
and
it's
really
the
you
know
the
home
users
small
office
home
office.
You
know
your
your
cpe
router,
so
you
need
qs
there
and
then
and
then
it's
really
all
the
all
the
service
providers
talking
to
each
other
and
communicating
and
having
a
coordinated
qr
policy.
So
that's
that
those
are
really
the
big
two
pieces
of
the
puzzle
and
a
lot
of
the
other
streaming
content
providers.
F
They're
all
doing
they're
doing
streaming,
video
and
stuff.
But
everything
is
over
tcp,
so
they
get
to
re-transmission,
so
they're
they're,
all
fine
and
they've.
I
think
for
years.
I
guess
all
the
content
providers-
everything
that's
been
really
over.
Unicasted
multitasker
hasn't
been
viable.
You
know
due
to
not
having
the
mpos
so,
but
what
ends
up
happening
with
all
these
content
providers
providing
unicast
screening-
and
you
know
large
packets,
a
video
that
ends
up
if
you're,
if
you're
doing
a
mix
of
that
with
multicast
and
it's
all
best
effort.
F
You
know
you
end
up
running
into
trouble
so
and
not
having
the
qs,
of
course,
on
your
desk
on
your
cpu
router,
as
well
as
the
end-to-end
qos
multitask
kind
of
get
the
short
end
of
the
stick,
but
go
ahead
to
the
next
slide.
F
So
so,
just
kind
of
just
comparison,
just
tcp
youtube.
Just
basics
I
mean
you
just
don't
have
with
it
looks
like
screen
just
reset
there.
It
goes
oh
yeah
there
you
go
so
just
the
basics.
So
with
with
udp,
you
know.
So
it's
connectionless,
you
know
unreal
and
not
not
reliable
data
delivery.
So
there's
no
recovery
as
you
guys
with
tcp
would
retransmission.
I
mean
that's
really
the
big
one.
I
mean,
there's
no,
there's
no
spinach
handshake.
So
it's
not
not
connection
oriented.
F
So
if
that
packet
drops-
and
it
happens
to
be
that
reference
frame
you're
done
and
you're
in
the
buffering,
so
big
impact
for
multitasking,
you
really
you
need
reliability
and
to
make
it
not
that
you
know
viable.
You
either
have
to
have
some
kind
of
feedback
mechanism
through
the
either
pragmatic
multitask
or
you
know,
through
the
reliable
multicast
transferential
working
group
or
an
end-to-end
qs
policy.
F
So
today
you
know
if
we,
if
we
actually
looked
at
the
way
multicast,
you
know
you
know
and
marking
we
would
actually.
Let's
say
you
know
just
this
slide,
just
kind
of
gives
an
idea.
You
know,
let's
say
all
the
different
classes,
and
here
I'm
just
showing
just
one
class.
So
let's
say:
if
we
just
had
multicast
over
marketing
multicast,
would
you
know?
Do
you
know
use
that
where
the
line
says
streaming
video,
so
cs4
is
kind
of.
F
Like
the
you
know,
the
recommendation
recommended
value
kind
of
I
think
from
there's
some
graphs
related
to
us
and
which
would
classes
work
for
like
for
sure
for
forwarding
or
or
expedited
for
it,
and
so
cs4
is
really
kind
of
the
kind
of
a
guide
to
where
where
multicast
would
fall.
You
know
if
we,
if
we
did
tos
over
the
internet,
go
ahead
to
the
next
slide.
F
So
so
so
this
this
slide.
What
I'm
talking
about
in
theory,
just
just
looking
and
kind
of
digging
a
little
deeper
into
qos
as
it
actually
pertains
to
multitasking
multicast,
is
really
really
either
needs
that
and
then
qos
or
or
another
option
would
jump
feedback.
You
know
mechanism
for
the
protocol,
so
in
theory,
if
you
looked
at,
let's
say
public
public
internet
providers
versus
like
private
mpls,
you
know
mpls
or
even
any
flavor
like
srmpls,
srv6,
etc.
F
What
not
the
big
difference
is,
you
know
just
kind
of
looking
at
it
at
a
high
level,
and
that's
really
simplicity.
Then,
if
you,
when
you
look
at
it,
it
doesn't
it,
it
doesn't
seem
like
it
would
be
as
difficult
to
provide
multicast.
You
know
in
the
qs
over
the
internet
and
and
really
the
really
the
big
deal
is
because
you
have,
the
internet
providers
are
actually
routing
the
traffic
and
it's
really
really
a
single
global
field.
So
imagine
it's
just
a
single
single
tenant
and
the
tenant
is
like.
F
Is
the
internet
saying
the
enemies
he
either
route
via
the
global
table
any
any
or
you
have
a
single
verb?
And
so
it's
a
variety
I
think
most
of
the
tier
one
tier
two
they're
usually
doing
mtls
so
they're
global
table
or
router,
it's
kind
of
like
they're,
underlay,
igp,
osgs
and
they're,
and
then
they're,
that's
like
their
top
most
label
and
then
the
overlay.
F
You
know
they
have
a
single
any
danny
internet
burp,
and
that
provides
your
your
your
internet,
routing
connectivity.
So
but
it's
but
the
basic
concept
is
it's
a
it's
a
single
tenant
versus
if
you're
doing
private
mpls
you've
got
many
customers.
So
you
have
to
do
a
remark
at
the
edges
so
so
really
kind
of
at
a
high
level.
Looking
at
it
I
mean
it
doesn't
seem
too
difficult
that
you
could
actually
have
all
the
service
providers,
and
this
is
kind
of
really
in
theory,
at
a
high
level
that
you
could.
F
You
could
actually
have
all
the
all
service
providers.
You
know
across
the
board
have
the
same.
You
know
perhaps
scheduling
the
php
scheduling
and
a
common
marketing
policy
you
mark
at
the
edges.
You
don't
have
to
do
any
any
special
marketing
or
special
treatment
with
different
types
of
classes.
Like
a
growth,
you
know
gold,
bronze
silver
class
that
you
would
do
with
private
mtls,
because
it's
public
and
it's
all
just
one
single
verb
any
any.
So
that
does
make
it
you
know
viable
and
possible.
F
I
think
that
there
have
been
white
papers
and
publications
over
the
years
related
to
us
over
the
internet,
but
it
just
really
hasn't
gained
momentum
just
because
of
the
sheer
volume
of
the
number
of
service
providers
and
really
the
global
region
trying
to
get
get
the
standard
or
whatever
it
is
out
to
all
the
providers.
I
mean,
I
think,
that's
that
is
probably
really
the
biggest
challenge,
but
and
in
theory,
at
a
high
level,
because
you're
dealing
with
a
single
tenant
and
it's
just
a
thing
like
a
global
table
or
a
single
mpls
verb.
F
We
don't
the
marking
policy
and
the
keyless
policy,
it
can
be
fairly
straightforward
and,
and
it
really
can
be
feasible
and
and
it
can
be
done-
that's
kind
of
what
I'm
trying
to
say
in
this
life.
I'm
going
to
the
next.
F
One,
so
this
is
actually
all
theoretical.
So
in
theory
what
you
could
do
is,
let's
say
you
know
the
ietf.
You
know
we.
We
came
up
with
a
qos
standard
for
let's
say
public
us,
and
this
could
be
a
draft.
You
know
maybe
a
public
key
of
policy
and
maybe
something
that
we
actually
have
to
drive
some
freight.
You
know
framework
around
it
and
with
all
the
you
know,
operators
groups
like
manhattan
and
san
hogan.
We
work
with
all
the
different
operators,
which
I
guess
in
theory.
F
We
could
have
a
public
standard,
qr
policy
that
you
could
you
just
do
this
across
the
board
across
you
know
you
know
across
the
globe.
It
doesn't
have
to
be
complicated,
it
could
be
fairly
simple
and
I
kind
of
broke
it
up
into
four
classes.
So
you
could
have
let's
say
your
best
effort.
So,
instead
of
throwing
everything
into
your
best
effort,
big
bucket,
your
that
best
effort
would
be
your
file
transfer
class
and
then
you
have
cs4
multicast
would
sit
right
there.
You
have
it
sitting
by
itself.
So
it's
not
queuing
up.
F
You
know
with
other
traffic
types,
any
other
tcp
content
stuff
from
like
netflix
amazon
or
what
not
any
other
content
provider.
So
that
would
be
a
separate
class
and
then
sydney
had
like
a
41
and
then
your
voice
traffic
would
keep
that
separate.
So
really,
four
classes.
I
mean
it's
a
pretty
simple
policy.
You'd
have
like
an
ad
mark
policy
that
you'd
mark
your
standard.
F
So
in
theory,
you
you
could
actually
so
this
this
could
be
accomplished
and
you
could
you'd
have
your
your
edge
router.
So
you
have
two
pieces
of
the
puzzle:
your
your
edge
router,
your
cpu
broadband
router.
You
have
to
enable
qr,
fair
and
now
you
have
all
the
providers.
Now
with
this
common
policy,
qs
policy
that
we
come
up
with.
You
know,
let's
say
the
one
that
I've
you
know
outlined
you
all
the
providers.
They
would
have
this
standard
marketing
policy
at
all
of
their
ed
use,
so
all
their
customers
and
mark.
F
And
then
then
you
know
service
provider
service
provider.
They
would
have
a
standard
policy
that
they're
now
they
they
trust
and
they
honor
the
markets
that
are
going
between
providers.
So
there
was
an
idea
that
I
thought
of
that.
Maybe
so
this
is
one
idea
that
you
could
possibly
have
another
idea
and
it
would
be
really
based
on-
and
I
kind
of
mentioned
it
just
enough
in
a
really
brief
blurb
in
one
of
the
slides
is
that
it
would
be
a
concept
similar
to
let's
say,
bgp
flow
spec.
F
Let's
say
if
you
imagine
that
the
internet
being
hierarchical,
you've
got
your
tier
one
tier
two
and
you
got
your
broadband
carriers
and
it
could
be
like
a
policy
push
that
you
have
a
controller
and
it
would
be
similar
to
flow
spec
where
you
you
would
have
you
have
your
policy
that
gets
pushed
out
and
then
your
then
then,
your
actual,
once
once
your
policies,
let's
say,
learn,
I
guess
push
from
the
top.
You
would
actually.
F
You
could
actually
have
that
distributed,
that
same
policy
distributed,
and
it
would
be
similar
to
close
that's
where
the
policy
once
once
you
have
that,
and
it
could
be
a
dgp
capability
that
that
that's
that's,
exchanged
the
path
attribute
or
whatnot
that
you
have
that's
that's
pushed
out
through
the
controller
and
then
the
the
actual
action.
What
happened
where
the
policy
gets
created?
F
It
could
be
similar
to
like,
like
qpdb
but
kind
of
taking,
that
and
taking
that
to
the
next
level,
but
here
west
policy,
propagation,
where
you
could
push
policies
so
top
down
from
the
tier
one,
all
the
way
down
the
edge
of
the
major
dynamics.
So
all
providers
kind
of
you
know
mark
through
the
same
tune
and
they
all
have
the
same
policy.
F
Any
questions,
comments,
considerations
or
any.
K
Yeah
am
I
on
all
right,
yeah
hi.
This
is
jake
holland.
I
I
would
suggest
looking
into
fec
that's
been
that's
been
a
pretty
common
way
to
solve
the
reliability
problem
for
multicast.
It
was
recommended
both
for
flute
and
norm,
but
norm
also
has
nax
so
like
you
might
be
able
to.
K
I
mean
I
think
it
would
be
a
pretty
neat
idea
to
make
an
rtp
payload
with
like
fec
for
iframes,
but
you
know
that
I'm
not
sure.
If
that's
the,
if
that's
the
direction
you
want
to
go
with
that,
but
a
general
idea
of
yeah
I
mean
qos
inner
domain,
I
think
is-
is
going
to
be
a
pretty
heavy
lift
honestly
and
if
the
use
case
for
it
is
to
support
multicast,
then
I
don't
know
man.
F
No,
I
I
I
hear
you
I
mean,
and
you
know
in
one
of
these
slides
I
did
mention.
I
think
thing
is,
I
think,
with
service
providers
and
with
like
vw
fdm,
you
can
really
throw
like
a
ton
of
bandwidth
and
to
convince
providers
to
okay,
let's
start
using
multicast
naked
bible,
but
we've
already
been
viable
for
a
long
time
using.
You
know,
you
know,
you
know
point-to-point
sessions,
you
know
having
this
unicast
so
and
we
just
keep
throwing
bandwidth
out
of.
F
F
Multicast,
you
know,
does
make
sense
for
most
for
most
customers
enterprises,
you
know,
do
multitask,
but
I
think
from
a
internet
standpoint,
it's
not
not
as
not
as
much
and
I
think
even
like
all
the
content
providers.
I
think
really
just
tcp,
because
you
can
do
like
you
can
do
the
interactive,
video
or
streaming
videos.
You
can
do
it
all
over
tcp,
it
kind
of
kind
of
you
know
puts
the
onus
not
on
multicast.
So
then,
if,
if
there's
no
onus
or
business
justification
or
driver
for
it,
it
really
makes
it
hard
to
hard
sell.
F
So
I
totally
agree
it's
a
really
hard
hard
sell.
You
know
because
they've
been
running,
you
know
with
tcp
from
dave
for
quite
a
long
time,
almost
like
really
from
day
one
to
actually
make
that
hard
sell
for
multitask
yeah
over
the
internet
advertising,
and
that
would
be
really
the
only
driver
that
key
os
and
it's
really
keyos
is
for
multi-gate,
because
it's
bdp
based
it
needs
gos,
where
everything
else
you
can
throw
out
pipes
at
it
and
qcp
will
retransmit
and
you're
fine
and
you
work
fine.
So.
K
But
with
fec
I
think
you
can
you
don't
necessarily
need
the
retransmit
or
you
could
do
like
out
of
boundary
trends.
You
know
fetching
of
missing
data
with,
like
a
you
know,
web
api
or
something
right.
I
mean
there's
other
ways
to
to
solve
this-
that
don't
need
the
the
new
bgp
thing
and
the
hop
I
hop
network
support
right.
K
So
there's
there's
several
I
I
can.
I
can
send
you
a
few
offline
if
you
want,
but
yeah.
K
F
That
sounds
that
sounds
good
and
I
think
the
norm
and
even
like
the
programmatic
multitask,
I
mean
those
definitely
sounds
like
interesting
solutions,
but
I
think
you
know
that
could
possibly
work
and
kind
of
really
dealing
with
it
at
the
application.
Later,
I
think,
having
said
is,
is
a
probably
easier
list
than
actually
you
know
the
worldwide
multicast.
A
Well,
you,
you
were
wise
to
include
net
in
your
email
when
you
copied
our
multicast
related
working
groups
and
there's
been
a
little
discussion
in
the
chat
during
your
presentation
about
net
so
that
that
would
be
worth
pursuing
with
them.
If
they
respond
just
to
see
as
alvaro
confirmed
that
in
their
charter,
it
does
apply
to
point
to
multi-point
flows,
so
they
I
don't.
We
just
need
to
investigate
that
a
little
bit
more
because
that
may
be
a
an
area
to.
B
F
Yeah
yeah,
you
know,
I
think,
like
let's
say
with
gos
like
if
you're,
if
the
let's
say
the
service
provider
that
you're
getting
your
content
from,
let's
say:
if
they're
either
they
actually
get
a
unicast
feed.
I
guess
from
the
provider
like
a
good
example,
could
be,
let's
say
like
network
and
that's
just
how
they
have
a
content,
feed,
let's
say
in
the
verizon
and
then
verizon
within
their
head
ends
now
they're
doing
multitask
downstream.
F
F
But
if
it's
kind
of
going
as
long
as
you're,
not
going
outside
of
your
pop
outside
of
your
your
service
provider,
network,
you're,
okay,
but
once
you
leave
that
turf
right,
yeah
yeah.
F
F
So
I
did
investigate
that
a
little
bit
and
they
had
some
things
and
then,
but
I
think
dead
net.
That's
definitely
something
you
know
interested
in
pursuing
and
mike
I'll
look
at.
I
guess
your
the
workers
that
closed.
I
guess
some
of
those
are
kind
of.