►
From YouTube: IETF114 MSR6 20220726 1900
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Good
afternoon
welcome
to
msr6
both
please
take
your
seat.
Put
your
chair,
chair
in
upright
position,
put
your
phone
in
your
airplane
mode
or
at
least
to
silent
mode.
Please,
because
this
session
is
being
recorded
and
we
don't
need
any
musical
soundtrack,
so
we
have
busy
agenda.
So
I
guess
we
shall
start
yeah
and
please
scan
this
beautiful
qr
code,
so
you're
on
the
blue
sheets.
A
A
A
We
are
going
to
talk
for
a
bit
about
proposed
solutions,
but
I
suggest
we
are
not
focusing
too
much
on
this
and
and
during
those
parts
please
only
ask
clarifying
questions
like
I
don't
understand
what
you
mean
by
that
and
keep
questions
like.
I
don't
think
it
should
be
done
that
way
to
the
second
part
of
the
session.
We're
gonna
have
open
mic
discussion,
then
we'll
talk
about
charter
and
hopefully
make
some
decisions.
A
Please,
because
we
only
have
two
hours
and
I
suspect
most
people
here
could
talk
about
on
this
topic
for
like
a
couple
of
weeks,
please
keep
your
comments
focused
and
if
you
notice
the
first
slide,
we
do
not
want
to
talk
about
how
before
we
discuss,
should
we
right
so
what
we
need
to
actually
agree
right
now
is:
is
this
problem
worth
solving?
Okay?
Is
it
a
problem?
Do
we
want
to
solve
it?
Do
we
want
to
solve
it
at
ietf,
and
if
answer
is
yes,
then,
where
exactly
are
we
going
to
solve
it?
A
Are
we
going
to
use
existing
venue
or
we
need
to
create
a
new
one?
And
if
you
answer,
if
you
find
answer
to
that
question,
we
can
discuss
about
charter
and
deliverables
and
all
those
things.
So
please
keep
this
in
mind
right.
Let's
refrain
from
discussing
details
of
the
solution,
because
if
we
decide
to
form
a
working
group,
it
will
be
working
group
job,
not
the
task
of
this
both.
A
So
I
think
actually,
that's
all.
I
have
any
comments.
D
So
just
one
important
thing
like
if
you're
going
to
join
the
mic
line,
please
use
the
meet
echolite
client,
if
you're
local,
to
join
the
line,
so
we
can
kind
of
manage
between
the
remote
and
local
lines.
Thank
you
very
much.
A
A
E
Okay,
okay,
sure,
good
afternoon,
everyone
here
on
behalf
of
the
author
list,
I'm
going
to
talk
about
the
msr6
use
cases,
I'm
a
tng-
and
this
is
some
work
just-
is
derived
based
on
the
mailing,
alias
the
the
sun
meeting
and
all
the
contributions
from
different
people.
So
here
I'm
presenting,
can
you
do
the
next
one.
G
E
Yeah
from
the
meeting
one
one,
one
two,
and
also
the
melee
discussion
about
the
the
use
cases
and
all
the
requirement
objectives
and
the
team
has
already
have
already
laid
a
solid
foundation
on
what
will
be
achieved.
What
will
be
pursued
and
all
the
you
know,
objectives
and
requirements
so
for
the
problem
statement.
So
hopefully,
is
you
at
least
to
get
some
background
about
that
things.
Here
I
will
just
give
a
some
sort
of
a
summary
of
what
will
be
the
objective
requirement
to
be
achieved.
E
What
is
we
want
to
get
the
the
first
one
is
the
native,
so
basically
we
want
this
one
to
be
done
on
the
native
ipv6,
so
it's
not
likely
in
cap
over
in
cap
over
incap.
The
the
second
one
is
the
stateless.
So
this
case
here
we
do
not
want
to
get
the
gigantic
number
of
software
states
to
be
refreshed
every
sometime
in
the
multicast
domains,
the
stateless,
the
third
one
is
a
large
skill.
E
So
it's
like,
we
want
to
handle
a
large
scale
of
networks,
not
just
like
a
small
and
in
the
large
scale
network,
we're
going
to
have
a
new,
numerous
multicast
streams,
and
also
we
have
some
other
requirements
like
the
the
especially
what
we're
going
to
when
I
mentioned
about
the
technical
domain
is
some
extreme
dynamics
in
the
subscriber,
drawing
and
the
living
and
and
also
we
want
to
use
the
msr6
this
type
of
mechanism
to
get
some
add-on
value
and
the
features
that
can
be
coupled
together.
E
Okay,
so
for
all
the
objective
requirements
in
mind
today,
I'm
going
to
present
four
cases
from
different
categories.
The
first
one
is
from
the
telco
domain.
It's
like
a
5g
transport
network.
The
second
one
is
from
the
idc
network
for
the
large-scale
dc.
The
third
one
is
for
the
enterprise
network.
It's
like
the
vertical
is
a
is
the
case
for
civilians
cameras.
The
last
one
is
like
a
holistic
use
case
that
is
called
sd1,
but
it's
going
to
span
the
teleco
domain
network
cloud
network
in
the
price
and
also
public
okay.
E
I
can
go
to
the
next
one.
The
the
first
use
case
is
the
the
multicast
for
toggle,
as
we
know,
with
advancement
of
5g
technology
and
its
commercial
deployment.
E
3Gpp
has
already
3gpp
has
already
defined
in
the
ts23247
enhanced
mbs
architecture
to
handle
to
handle
the
different
cases.
If
you
look
at
the
top
left
picture,
that
is
the
one
in
the
23.247,
I'm
not
sure
if
the
the
function-
small
or
not,
but
you
can
focus
on
the
right
circle
throughout
the
bottom
part
of
the
top
left
picture,
and
here
you
can
see
the
mbupf
and
look
at
there.
This
n3mb
interface
is
at
the
very
bottom
line
and
toward
the
left
side
to
the
g
node
b.
E
That
is
the
for
the
multicast
communication,
if
they
zoom,
if
you,
if
we
zoom
that
one
in
into
a
large
picture
that
will
be
shown
at
the
the
bottom
left,
but
the
bottom
left
is
a
still
a
very
high
level
architecture.
Like
a
thirty
thousand
football
view
of
a
it
is
a
real
deployment.
But
here
we
just
give
a
very
high
level
view,
so
you
can
see
all
kind
of
the
the
ring
from
the
core
from
the
backbone
from
aggregation
from
the
edge
until
the
g
node
b.
E
If
you
look
at
the
the
magnitude
of
order
on
those
type
of
rings,
okay,
the
you
know
the
ring
you
can
consider
this
one
is
like
a
multicast
tree,
but
instead
of
a
stick
or
branch
of
a
tree
here,
you
can
consider
it
like
a
ruin.
So
each
ring
has
a
branch
and
then
this
is
just
like
a
a
chain
of
rings,
but
it
forms
a
tree
and
rooted
on
the
right
hand.
Side
like
a
ups,
okay
and
then,
when
you
put
everything
together
here,
it's
on
the
ballpark
around
the
30
000
level.
E
Okay,
so
it's
it's
so
huge.
It's
so
huge!
It's
not
just
so
simple
to
handle
this
type
of
things
in
the
regular.
You
know
our
existing
solution
of
multicast,
okay
and
remember
here.
This
is
for
the
taggle
domain.
You
know
for
tempo
domain
and
also
for
5g.
You
can
consider
there
are
a
lot
of
requirements
for
the
dynamics
like
the
mobile
subscriber.
E
Their
tendency
to
move
between
from
one
g
note,
b
to
the
next
one,
where
5g
has
specified
the
different
ssc
mode
service
at
the
session
continuity
mode,
one
two
three
so
for
those
type
of
things,
you're
going
to
have
some
anchor
pd
the
psa
on
the
ups
side,
so
this
one
will
introduce
another
dimension
of
dynamics.
E
So
in
that
case,
even
if
you
try
to
you
know
you
can
you
want
to
do
divide
and
conquer,
to
put
this
like
a
30
thousand
node
network
into
some
clusters?
But
the
thing
here
is
like
it's
going
to
be
very
dynamic:
it's
not
an
easy
job.
Maybe
you
need!
I
don't
know
how
many
csies,
but
unless
something
to
handle
the
whole
thing.
So
it's
going
to
introduce
the
the
burden
of
opex.
Remember,
5g.
Capex
is
already
a
big
burden
for
mobile
operators
so
but
put
everything
together.
E
Okay,
so
you're
you're
going
to
know,
okay.
What
we
want
to
achieve
that
is
on
the
bottom
right,
there's
like
to
avoid
poor
flow
state
to
prefer
selective
over
inclusive,
just
this
one.
Just
so
you
can
consider
like
the
dvmrp
or
the
pin
dense
mode.
Those
several
things
or
worse,
the
sparse
mode,
and
also
we
want
to
avoid
unnecessary
pack,
the
in-cap
okay.
E
H
E
Okay,
this
one,
no,
no,
not
this
one,
the
dc,
okay,
oh
yeah!
Thank
you.
This
is
another
case.
It's
also
a
real
things.
You
know
probably
are
familiar
with
the
the
global
the
mobile
network
operator,
especially
north
america,
or
europe,
and
normally
they're,
going
to
have
their
own
network
cloud
to
run
the
4g
or
even
5g
virtualized
support,
but
in
in
mainland
china,
the
mobile
operator
actually
owns
both
a
network
cloud
and
public
cloud
here
in
the
public
cloud
is
owned
by
public
hyperscalers.
E
So
in
those
things
we
have
extremely
large
dc
networks
to
handle
the
5g
core
network.
You
can
consider
you
know
the
subscribers.
In
our
case,
you
know
we
are
the
largest
mobile
subscriber
in
the
world
in
terms
of
the
numbers.
It's
like
a
a
billion
so
about
a
billion
subscribers,
and
then
we
have
some
number
of
dc
network
to
handle
the
5g
cores.
E
So
you
can,
you
can
know
on
ballpark
how
large
it
will
be,
and
also
there
are
some
other
like
hpc
applications
that
require
the
large
required
multicast
communication
to
improve
the
efficiency.
So
when
you
consider
this
one
together,
so
this
is
another.
You
know
we
put
a
number
there
like
a
30k
switches,
layer,
three
switches
with
the
links
on
60
k.
So
when
you
put
everything
together
and
also
consider
requirement,
we
specific
we
specified
at
the
beginning,
scale,
scalable
and
stateless
native
ip
dynamics,
all
kinds
together.
E
So
this
is
another
challenge
use
case
we
have
to
face
next.
You
know
for
this,
one
is
for
the
enterprise
or
the
vertical.
So
this
is
like
the
civilian
camera.
There
are
some
public
stats.
I
can.
I
found
google
it's
like
in
in
beijing.
It
has
like
eight
million
cameras
in
uk
london.
It
has
close
to
a
million
surveilling
cameras
so
depending
on
the
government
regulation
or
local
governments
or
policies.
E
So
the
the
data
captured
by
those
such
a
large
number
of
cameras
will
be
stained
towards
some
places.
Are
some
analyzers?
This
is
the
picture
on
the
left
hand
side.
So
if
those
information
stand
about
those
analyzers,
this
amount
of
information
will
be
very
large,
and
the
number
of
modern
streams
will
be
huge
so
for
this
case.
For
this
case,
we
do
not
want
to.
We
do
not
want
the
network
itself
to
be
burdened
with
the
states,
so,
for
this
particular
case
is
also
a
real
requirement
case.
E
Okay,
yeah,
you
know,
consider
all
the
three
cases
you
know
in
the
teleco
network,
in
the
in
a
dc
network
and
also
on
the
enterprise
of
vertical.
So
the
last
case
is
like
a
holistic
use
case
with
add-on
feature
and
values
we
are
talking
about.
Sd1
sd1
itself
is
is
nothing
new,
but
here
when
the
skill
goes
up,
you
know
this
is
another
real
for
one
large
enterprise
company
in
china.
E
It
has
cpesd1
node
up
to
the
national,
the
nationwide
up
to
100k
cpes,
and
those
cpes
will
be
connected
through
like
a
tow
code
domain
through
enterprise,
because
they
know
they
have
the
their
branch
office
and
through
the
cloud
they
may
have
some
virtual
cps
running
on
the
the
the
public
cloud
and
those
things
will
be
connected
to
the
public
internet.
E
So
this
is
really
a
big.
You
know
a
big
deployment
and
remember
you
know
when
those
things
are
connected
together
this
through
they
go
through
the
public
internet.
So
there
is
a
requirement
for
the
security
you
do
not
want
to
expose,
especially
for
the
enterprise.
E
So
in
this
case,
so
in
this
case
we
want
to
have
some
sort
of
way
to
encrypt.
Okay.
So
remember
we
have
the
requirement
objective
to
use
the
native
ipv6,
so
for
msr6
it's
going
to
have
the
advantage
just
to
to
leverage
to
to
leverage
ipv6,
v6
extension
header,
the
esp
and
the
eheader
to
do
this
type
of
encryption.
E
So
for
this
holistic
case
you
have
all
the
things
you
want
for
the
scalable
stateless,
the
native
dynamics
of
msr6,
plus
the
the
natural
encryption
decryption
embedded
with
the
ipv6
extension
header,
the
next
one.
So
the
next
one
is
the
summary.
So
here
is
the
use
case.
Problem
statement
has
been
laid
down
by
the
colleagues
and
on
the
email,
alias
and.
E
Okay-
and
you
know
here
it's
just
like
the
the
summary
what
I
want
to
achieve,
the
one
is
the
native
ip6
is
the
required
and
also
the
status
is
important,
but
remember
you
know
everything
together.
We
have
like
the
dynamics
and
some
add-on
features.
So
this
yeah.
So
this
important
things
it
has
all
the
objective
requirement.
Clearly
a
setup
so
yeah,
hopefully
it's
yeah,
hopefully
you'll
be
yeah
you'll
get
it
yeah.
Thanks,
go
ahead.
E
It
no
it's
not.
G
My
name's
greg:
can
you
define
what
you
mean
by
native
ipv6?
Do?
Can
you
please
define
what
you
mean
by
native
ipv6?
Oh.
E
It's
just
like
using
the
activated
header
using
sv
header
without
the
end
cap.
You
know.
G
E
K
Yeah
go
ahead:
hi
andrew
alston,
I'm
just
wearing
my
operator
hat
in
the
you
referred
to
non-encapsulated.
Now,
if
you
go
back
to
the
previous
slide,.
K
E
Which
are
here
well
remember.
The
extension
header
is
something
like
like
a
proposal
like
proposed
solutions
and
the
the
colleague
earth
and
will
be
giving
well
I'll,
be
giving
some
description
of
those
things
so
which,
after
talking
about
that.
K
In
rfc
50,
I.
D
Think
andrew
right,
like
I
think
you
have
a
point,
but
can
we
have
that
in
the
open
mic
discussion,
because
I
I.
M
D
Use
case
itself
doesn't
violate,
like
maybe
a
proposed
solution
might
violate,
like
you
know,
not
encapsulating
it,
but
that's
a
use
case.
It's
a
use
case
right.
So
I
I
do
get
your
point,
but
we
can
have
that
in
the
open
mic
discussion
right,
there's
nothing
that
can
be
clarified
and
I'm
happy
with
that.
Okay,
thank
you.
Okay.
Thank
you.
J
N
Just
a
clarification,
I
hope
you
can
clarify
you
talk
about
the
size
of
the
networks,
they
didn't
say
anything
about
the
size
of
the
multicast
tree
or
or
bandwidth
or
how
many
flows
you
would
have
in
the
network.
So
they
have
some
thoughts
on
that.
D
Yeah,
I
think
his
question
is
like
what
is
the
size
of
the
multicast
tree
yeah.
E
Oh
the
size
of
multicast
streams.
Okay,
if
you
look
at
the
the
first,
the
use
case
for
telco,
and
then
we
have
to
give
the
ballpark,
oh,
can
you
can
you
go
to
the
the
the
teleco
case?
We
have
to
give
the
ballpark?
No,
yes,
oh
no
one
more!
No!
No
previous
previous
yeah!
Yes,
this
one!
If
you
look
at
this
one,
the
bottom
left
one
and
then
the
ballpark
for
the
the
ng-run
is
running
as
ip.
E
It's
a
run,
ipv6
clear
three:
it
can
up
to
30k
yeah
and
then
look
at
all
the
rings
like
we
have
like
a
10
for
backbone,
100
on
aggregation
and
for
the
excess
and
1k.
So
this
is
like
a
chin
of
rings.
It's
like
a
tree,
but
instead
of
the
seed
or
branch
of
a
tree,
each
one
is
like
just
like
a
ruin
and
you
like
a
ring
instead
of
a
branch,
but
those
rings
will
form
a
big
tree.
N
N
E
F
Way
past
the
time
I'll
answer
to
the
questions
raised
in
my
part
of
the
presentation.
Okay,
thank
you.
Thanks.
E
Tree
actually,
they
are
viewing
the
same
streams,
but
on
different.
You
know
if
you
look
at
this
on
different
genomic
on
different
aggregation
of
access
aggregation,
those
type
of
rings.
So
it's
distributed.
Remember
here,
you
know
I
can.
I
can
see
one
more
thing.
This
is
within
a
city,
it's
not
a
province
or
state.
Yet.
D
D
P
Thanks:
okay,
a
couple
of
comments:
please
first
thing
on
the
5g
use
case:
as
you
know,
the
g
note
b's
or
the
e
note
b's
they
do
are
hosts
or
they
do
igmp
or
mld,
join
to
the
sell
side.
Router
and
the
cell
start.
Router
is
where
the
trio
starts.
So
really
you
shouldn't
be
counting.
The
g
note,
b's
or
e
note
b's,
because
they're
just
hosts
and
for
the
tree,
you
should
start
counting
the
cell
side
router,
because
that's
where
the
pim
or
mldp
or
the
tree
starts.
P
But
my
question
is
that
this
problem
has
been
solved
for
centuries,
like
all
these
alerts
that
you
folks
get
on
your
cell
phone
for
earthquakes,
for
you
know
bad
weather,
child
abduction,
etc,
etc.
All
of
the
star
stuff
are
embms
and
they're
multicast.
So
every
single
major
provider
in
the
world
does
have
multicast
running
for
this
emdms
type
of
application,
which
is
very
important
for
each
government
within
the
world.
So
that's
common
number
one
and
comment
number
two
is
with
regard
to
your
camera
diagram.
P
If
you
can
go
to
that
one
or
it
doesn't
matter,
if
you
go
there
or
not,
but
my
understanding
is
based
on
the
multiple
smart
cities
that
we
have
put
together
the
cameras
they
usually
do
unicast
to
a
server.
So
there
is
a
server
that
is
recording
all
these
cameras
real
time
and
the
cameras
do
unicast
to
the
server
and
the
reason
that
the
cameras
are
doing
unicast
is
because
of
security.
P
So
the
camera
starts
a
ipsec
tunnel
to
the
server
which
the
server
terminates
ipsec
tunnel
and
any
of
the
operators
on
different
areas
within
the
country
that
want
to
look
at
that
a
stream
they
do
a
join
to
the
server
that
is
recording
those
cameras.
So
those
cameras
are
not
part
of
the
multigas
domain,
usually
within
the
smart
cities.
Because
of
the
security
issues,
they
are
unicasting
to
these
four
or
five
data
centers
that
they
are
recording.
All
these
streams
live
and
then
any
any
operator
police
ambulance.
D
L
Here
I
want
to
give
another
example
for
the
for
the
lives
for
the
multicast
request
requirement
from
the
for
a
large
large
network.
D
Arjun,
we
cannot
hear
you
like,
can
you
you
know
yeah?
Can
you
shout
or
get
closer
to
the
mic
or
I'll
come
back,
we'll
take
vichang
and
then
we'll
come
back
to
you.
M
M
In
the
near
future,
we
will
have
the
opportunity
to
see
the
purely
ipv6
network.
So
if
we
can
have
a
native
app
this
ipv6
network,
there
will
be
a
good
chance
to
simple,
simplify
the
network
and
the
second
one
about
the
en
bmis.
M
M
I
just
want
to
the
response.
Some
people
write
the
the
question
about
the
mud
cast
in
4g
embankments
solutions.
I
think.
D
D
L
D
L
Yeah
yeah,
so
here
I
want
to
give
another
example
for
the
for
the
multicultural
service
within
the
large-scale
network.
You
know.
Currently,
the
live
stream
are
emerged
on
the
internet
service
and
I
think
the
largest
live
stream
not
exists,
not
only
within
the
5g
transport
network,
it
it
can
span
the
multi-domain
you
know
in
in
china,
we
our
we
operate,
held
several
domains.
L
Several
several
net
several
domains
connect
together,
so
the
the
the
multicast
source
always
located
in
one
metro,
meta
network
under
the
receiver,
located
on
the
other
side
of
the
metro
network,
so
the
livestream
will
span
the
multi-domain.
So
I
think
the
this
such
services
are
sold
currently
by
the
syrian
cydia
network.
I
think.
D
And
if
you
have
a
question
for
tng
or
you're,
also
agreeing
because
your
audio
is
very
poor,
if
you
have
a
question,
please
type
it
in
the
chat,
otherwise,
we'll
take
it
during
the
discussion.
Time
like
we
do
have
an
open
mic
time.
L
Okay,
I
will
type
my
my
information
really
in
the
chat.
Okay,.
L
E
G
Yeah
great
sorry,
I
didn't
catch.
That
was
the
end
of
the
presentation.
It
was
still
up
greg
again,
I'm
a
little
baffled
that
we're
not
starting
with
a
problem
statement
that
we're
actually
looking
at
a
unique
set
of
requirements
that
can't
be
solved
with
existing
solutions
that
are
out
there
to
justify
some
additional
work.
G
What
we
see
here
is
a
whole
list
of
use
cases
that
are
really
not
any
different
than
what's
already
been
solved
or
can
be
solved
by
existing
solutions.
So
we've
asked
this
work
in
the
past
to
provide
a
problem
statement
and
we
never
got
one.
So
I
was
hoping
today,
we'd
actually
see
some
effort
to
show
what
the
gaps
are,
what
the
needs
are
and
justify
this
work,
and
I
have
not
seen
it
I
I.
D
G
Q
Hello,
my
name
is
gion
mishram
with
verizon
and
I'm
on
this
slide
deck.
What
I
plan
to
go
over
is
this:
this
state
of
multicast
for
usa,
domestic
operators
and
then
how
how
the
from
a
technological
perspective,
how
how
the
current
state
of
multicast
applies
to
msr-6
and
how
msr-6
can
at
a
minimum,
meet
these
base
requirements
that
that
are
used
with
technologies
that
are
deployed
today
throughout
the
united
states,
with
operators
next
slide.
Q
So
from
a
video
transport
perspective
use
cases
we
have-
and
this
is
just
typical
distribution.
So
we
have
the
contribution
network
where
we
got
uncompressed
video
and
then
from
a
technology
perspective
the
what's
used.
Q
There
is
rsvpte
and
within
the
contribution
network
for
for
for
a
seamless
and
lossless
video
delivery
at
the
source,
as
well
as
at
the
primary
distribution
state
as
well
rsvpte
at
the
secondary
distribution
on
the
right,
secondary
distribution
network,
we
have
rs
and
that's
going
to
the
access
networks,
fixed
broadband
and
as
well
as
mobile
broadband
access
networks
mldp
as
well
as
pim
next
slide.
Q
So
here
we're
also
sharing
the
ver,
the
variety
the
distribution
flow
from
at
the
very
left
showing
the
uncompressed
stream.
So
the
higher
bandwidth,
video
delivery
at
the
left
and
then
it's
the
primary
distribution
network,
compressed
video
and
then
at
the
very
right,
uncompressed
video.
Q
You
know
so
the
stream
of
of
how
how
the
tr,
how
video
flows
from
left
to
right
and
the
and
the
technologies
used
on
the
left
side
rcpt
primarily
has
been
used
for
domestic
operators
for
the
primary
distribution
as
well
rsvpt
and
then,
as
you
get
to
the
secondary
distribution.
Q
It's
it's
majority,
mostly
mldp
for
the
for
the
distribution
next
slide.
Q
This
in
this
slide
shows
just
a
depiction
of
the
of
the
public
internet,
an
operator
network
in
the
center,
showing
the
core
core
network
access
aggregation
and
then
the
access
network,
mobile
broadband
and
fixed
broadband.
So
so
with
that
mvp
mvpn,
pmsi
ptas
that
are
deployed
mldp
is
the
primary.
Q
I
would
say,
majority
of
customers
in
us
use,
mldp
and
point
to
multipoint.
That's
probably
the
primary
pta.
That's
used,
rsvpte
at
the
so
at
the
source
at
the
at
the
primary
contribution
network,
as
well
as
the
the
prime
primary
distribution
and
then
mldp
point
to
multipoint
multi-point
to
multi-point.
Mldp
is
used
in
the
financial
industry
primarily,
and
there
may
be
some
other
smaller
use
cases
but
point
to
multi-point.
Mldp
is
really
one
of
the
primary
use
cases
that
are
used.
Pre
used
for
most
customers
within
the
us.
Q
Hear
you
at
the
back-
oh
sorry,
thank
you,
sorry,
and
so,
as
as
far
as
asm
versus
ssm,
you
know
from
a
technology
perspective
and
and
pim
binder
majority
of
uses
from
customer
networks.
Asm
is
still
what
prep
you
know
widely
used
on
customer
networks.
There
have
been
a
lot,
a
lot
of
enterprises
as
well
as
customers,
migrating
from
asm
to
ssm,
still
rarely
not
use
as
much
with
the
bi-directional
trees
point
to
multi-point
to
multi-point
pea
trees
within
the
core.
Q
So,
overall,
primarily
it's
really
mldp
point
to
multi-point
is
really
the
primary
technology.
That's
used.
You
know
for
the
p-tree
within
the
within
the
core
out
to
the
from
the
core
to
aggregation
out
to
the
how
to
enterprise
customers
within
the
united
states
next
slide.
Q
So
this
this
slide
shows
this
private
mpls,
so
in
here,
just
very
similarly
the
as
far
as
the
mvpn
use
cases
for
the
types
of
pmvpn,
p,
trees
that
are
deployed-
and
it's
still
primarily
primarily
mldp-
is
really
the
primary
and
asm
is
still
is
used
primarily
for
customers,
enterprise
customers
as
well
as
customers.
You
know
through
provider,
customers
that
exist
for
the
other.
Q
The
other
mvpn
ptas
that
are
used,
it's
not
as
widely
mdt
safy
and
some
of
the
other
ptas
are
not
as
widely
used,
and
here
in
this
case,
as
well,
multi-point
multi-point
for
pin
binder
trees.
That
is
not
not
as
widely
used.
Financial
industry
is
really
really
the
primary
use
case
where
pim
bider
is
used
for
multi-point
to
multi-point
trees
next
slide.
Q
So
this
this
slide
shows
msr6
requirements
for
ipvtv
delivery.
So
really
so
here
what
what
I'm
trying
to
depict?
I
guess
is
lossless
video
delivery
and
fast
reroute.
That's
really
one
of
the
primary
you
know.
Primary
technologies
used
for
rsvpt
fast
reroute
is
really
a
critical
requirement
for
primary
distribution,
as
well
as
the
content
distribution
networks
where
the
source
feed
comes
in
and
then
as
well
as
with
mldp
multitask.
Q
Only
fast
reroute
next
slide
here,
we're
showing
as
well
with
msr6
requirements
for
legacy
technologies,
mldp
and
rcpt.
So
here
as
well,
we're
just
showing
the
requirements
so
mplc
fast,
reroute,
link,
node
and
paths,
path,
protection,
50,
millisecond,
reroute
and
then
for
mldp
mo
multigas.
Only
fast
free
route,
as
well
as
local
protection.
Q
Q
The
primary
distribution
and
content
distribution
has
been
rsvpt
for
the
path,
protection
and
and
with
link
node
and
path
protection
for
disjoint
trees,
as
well
as
where
you
have
we're
requiring
triple
play
services
where
you
have
multi
multiple
pads
next
slide,.
Q
Q
This
slide
shows
as
well
comparison,
so
the
so
the
benefit
of
rsvpte
and
that's
really
where
you
have
redundant
pads
and
you
need,
and
you
need,
link
node
and
path.
Protection
for
triple
play.
Services
as
well
as
live,
live
protection,
the
use
of
rsvpte
with
that
50
millisecond,
failover
and
lossless
failover
next
slide.
Q
Q
Failover
with
live,
live
production
where
you
have
redundant
pads
very
similar
to
live,
live,
I
guess
very
similar
to
net
pre-off,
where
you
have,
where
you're
not
having
a
replicated
stream
from
the
from
the
ingress
to
the
egress
pre-off
mechanism,
where
you're
actually
sending
two
streams
down
to
the
receiver
end.
So
having
that
that
ability
and
protection
with
the
rsvpte
next
slide.
Q
This
slide
shows
the
entire
just
the
overall
end
to
end
stream,
just
for
going
from
the
from
the
left
side
from
the
contribution
network
from
the
source
through
the
distribution
so
rsvpte
in
the
core
network
and
at
the
distribution
layer
and
then,
as
you
get
to
the
access
layer
and
then
and
two
enterprises
and
large
medium
small
customers,
their
mldp
primarily
used
and
then
as
well.
Q
Q
So
a
summary,
so
the
goal
of
this
slide
deck
really
is:
try
really
try
to
look
at
the
use
cases
and
really
the
state
of
multicast
within
the
us,
domestic
and
and
the
requirements
that
at
a
minimum
that
would
need
to
be
met
by
msr-6
and
and
so
in
summary.
Here
we
got
fast
free
route,
protection,
injury,
engineering,
separate
protected
pads
scalability,
as
we
see
with
mldp
as
compared
to
rsvpte
the
live,
live
protection,
loss,
lossless,
zero
delay
and
then
lastly,
triple
play
services
next
slide.
Q
So
this
slide
what
I,
what
I
wanted
to
share
here
is,
like
you
said,
the
state
of
with
usa,
domestic
operators
and
then
srv6
deployments
and
and
as
as
well
as
migration
towards
an
ipv
towards
ipv6.
Q
Just
looking
at
the
bullets
here
that
I
got
laid
out
native
srv60
airing
capabilities
with
srv6,
with
with
us,
with
an
srh,
the
benefits
of
ipv6
flow
labels,
so
having
an
ipv6
data
playing
the
gains
there,
as
well
as
data
center
deployments,
where,
where
you
have
you're
using
an
nv,
nvo
overlay,
vxlan
type
overlay
ip
underlay,
where
you
know
you
can
take
advantage
of
srv6
in
the
underlay
and
then
ipv6
benefits
with
qos
and
then
lastly,
mpls
elimination.
Q
So
here's
the
last
slide
just
a
summary
of
solutions
that
exist
today
for
multicast
I've
just
related
as
related
to
srv6.
So
so
today,
mldp
rsvpt,
they
can
be
deployed
in
parallel
with
our
srv6.
We
do
have
segment
routing
related
solutions
that
can
be
deployed,
such
as
tree
sid
and
then
bgp,
multicast
and
bgb
multigas
controller.
Q
Those
are
as
well
options
that
that
exist
today
that
can
be
deployed
with
segment
routing
and
then
as
well
bit
beers
available
and
then
lastly,
and
just
kind
of
really
a
segue
into
the
solutions
for
msr6
is,
is
the
new
technology
that
we're
going
to
be
going
over
today
in
subsequent
slide
decks.
Thank
you.
A
D
Greg
go
ahead,
greg
mursky.
I
R
P
Q
Sure
so
I
think
the
lost
lossless
and
zero
zero
delay
that
would
be
achieved
with
redundant
paths,
which
is,
which
is
some,
which
is
something
that
is,
is
deployed
today
that
you
can,
if
with
redundant
pads,
where
you
have
a
replicated
stream.
D
Similar
you're
going
into
the
solution
space,
so
I
think,
if
I
can
refresh
a
question
greg,
is
that
a
non-negotiable
requirement?
Would
that
be
a
fair
phrasing
of
your
question?.
R
D
S
Hi
tom
hill
bt-
I
was
curious
really
in
in
the
sense
that
I
think
a
lot
of
the
use
case,
for
this
is
obviously
going
to
be
in
video
distribution.
A
lot
of
the
benefit
really
from
doing
this
will
be
in
video
distribution.
I
was
curious
how
you
envision
msr
6,
helping
with
tivo
style
services,
so
pausing
live
television,
for
example,
pausing
live
streams
and
catch
up
on.
S
That
is
this
the
suggestion
that
we
continue
falling
back
to
unicast,
or
do
you
feel
that
there's
some
benefit
here
that
can
be
made
out
of
a
new
protocol
with
regards
to
that.
Q
F
Can
I
give
a
quick
answer
to
that
yeah
they're
we're
attempting
to
to
restart
work
on
exactly
that
solution
description.
We
started
that
in
beer,
so
the
stateless
options
all
have
ways
to
improve
those
solutions,
and
we
haven't
put
that
specifically
together
for
msr6
right
now.
Okay,
thank
you.
Greg.
G
Q
G
Actually,
I
didn't
see
any.
It
was
again
just
all
solutions
that
we
are
have
already
seen
yeah
so
again.
So
what
you're
saying
here
is
you
have
no
goals
to
do
better?
You
don't
have
gaps
from
existing
deploy
to
what
you're
trying
to
achieve
and
your
objectives
are
to
be
just
as
good
what
we
currently
have.
I,
I
don't
see
any
other
answer
from
what
you've
said
and
what
you've
presented
thanks
craig.
D
D
Tell
us
please
go
ahead
thanks.
I
I
think
on
the
agenda
point
itself,
you're
running
a
little
bit
late
so
like
any
time,
is
going
to
cut
into
the
solution
which
you're
totally
fine
with
okay.
So
just
we'll
try
to
get
the
use
cases,
requirements
stuff
nailed
down
as
much
as
possible.
Thanks.
F
Okay,
welcome.
I
wanted
to
get
down
a
little
bit
from
all
the
details
of
the
use
cases
to
what
I'm
extracting
as
the
operational
use
case
requirements
based
on
my
kind
of
staying
around
for
30
years
with
this
technology
multicast,
and
what
what
I
learned
from
that
next
slide.
F
So
I
think,
there's
really
one
core
requirement,
which
is
that
we
want
to
have
a
simple
ipv6,
integrated,
end-to-end,
stateless
ipv6,
multicast
for
ipv6
only
networks
and
what
ipv6
networks
I
think,
all
of
them.
We
saw
a
lot
of
them
being
listed
here
in
the
prior
slides,
but
I
also
think
that
this
technology
is
quite
valuable
beyond
the
large
service
provider
networks,
but
maybe
not
for
this
point
in
time.
I
did
send
notes
out
to
the
iot
working
groups,
which
I
think
should
have
interest,
but
maybe
another
time
next
slide.
F
Okay,
so
beer
has
often
been
more
or
less
implicitly
being
brought
up
in
the
questions
raised
here.
So
let's
do
a
quick
refresher
on
what
beer
and
ipv6
networks
how
they
would
go
together
without
new
work,
so
the
beer
architecture
was
not
specific
to
any
particular
encapsulation,
but
the
working
group.
F
F
So
three
layers
of
encapsulations,
so
that
is
that
is
working
quote
in
the
way.
Fine,
as
a
lot
of
other
technologies,
we've
done
is
working.
Fine
next
slide
to
the
end
that
my
experience
has
been
that
something
really
is
working
for
ib
multicast,
when
operators
want
to
apply
use
and
deploy
it
successfully
when
it
is
trying
to
be
as
close
as
possible
to
the
unicast
technologies
that
are
being
deployed
in
the
network.
F
So
we
started
in
89
with
native
ipv4
multicast
and
by
adding
that
to
ip
with
exactly
the
same
packet
headers
and
as
much
the
same
behavior
somewhere
we
needed
to
sneak
the
replication
in.
Of
course,
we
were
allowed
to
reuse
and
extend
the
whole
ecosystem
of
ip
and
later
in
the
same
way
of
ipv6,
starting
from
the
sdks,
the
socket
apis,
the
qs
diffserv
insert
rsvp
acls,
all
the
layer,
2
encapsulation
that
ip
headers
were
built
for
ipfix
ipsec.
I
can
go
on.
F
I've
actually
spent
part
of
my
career
of
implementing,
or
you
know,
architecting
a
lot
of
these
add-ons
to
ip,
and
I'm
just
you
know,
really
scared
of
having
to
do
all
of
this.
You
know
four
beer
every
time
that
comes
around
if
we
have
the
option
for
existing
ip
networks
to
have
a
native
ipv6
solution
as
well.
That
would
allow
us
to
have
the
same
benefits
of
reusing
all
these
ecosystem
elements
that
we
do
understand
how
to
build
them
for
ip.
F
We
also
did
try
to
come
up
with
cool
new
novel,
multicast,
routing,
mospf
and
dmvpn,
and
after
a
couple
years
we
figured
out.
Well
that's
going
to
be
not
of
fun
for
the
operators,
so
we
had
to
revert
to
a
multicast
technology
that
is
using
all
the
deployed
unicast
routing
protocol,
just
so
that
multicast
became
operable.
F
Then,
basically,
we
had
perfectly
well
working
mvpn
services
for
multicast
in
mpls
networks,
which
wasn't
using
mpls
encapsulation,
but
which
was
using
ip
multicast
encapsulation.
They
said
yeah,
the
customers
are
buying
it,
it's
fine,
but
it
doesn't
meet
our
operational
expectation
of
our
network,
which
is
purely
mpls
forwarding
plane
base.
So
we
spent
another
10
years
to
build
native
mpls
forwarding
plane
for
those
mpls
networks.
Well
done
total
duplication
of
ip,
but
that's
how
the
market
space
works
right.
F
You
have
people
who
run
native
ip
networks
and
you
have
people
who
run
what
I
would
call
native
mpls
networks,
and
I
think,
in
that
respect,
the
beer
has
kind
of
evolved
over
the
time
that
the
working
group
has
been
trying
to
be
focused
to
deliver
something
running
really
on
the
mpls
solution
and
the
proposed
draft
for
this
you
know:
ipv6
over
beer
over
ipv6
is
kind
of
an
add-on
that
is
really
not
meeting
the
requirements
of
native
ipv6
networks.
Clarifying
questions.
F
R
Greg
asked
already
what
is
native
ip.
Yes,.
F
F
K
F
Just
trying
to
remember
which
slide
it
was
on
right,
so
the
stateless
stuff
is
was,
was
the
other
big
thing
right?
So
let's
talk
about
three
key
parts
right
so
me,
the
most
important
part
is
the
operation,
simplicity,
troubleshooting
and
everything
else
where
you
eliminate
a
lot
of
complexity
of
the
stateful.
So
there's
a
lot
of
of
aspects
here
in
details
that
I
think
we
can
revisit
if
we
had
more
time
in
the
solution
slide,
but
of
course
it
was
also
the
core
reason
for
beer.
F
The
scale
and
convergence
is
where
effectively
the
same
applies
and
in
the
solution
slides.
I
think
you
should
see
that
by
going
away
from
what
I
call
the
flat
bit
strings
that
be
introduced
into
you
know
more
advanced
processable,
encoding
of
the
destinations
or
the
destination
trees.
We
think
that
we
should
be
able
to
achieve
a
lot
better
scalability,
which
we
need
for
the
large
service
provider
networks,
and
that
would
obviously
also
be
considered
to
be
one
of
the
core
requirements.
F
The
the
additional
thing
that
people
often
forget
is
that
when
we
want
to
replicate
the
ecosystem,
we
want
to
get
all
the
way
up
to
the
application
layer,
and
that
means
we
need
to
get
into
socket
apis
and
socket.
Apis
have
been
extended
to
support
ipv6
extension
headers
for
ipv6
20
years
ago,
with
that
rfc
number
that's
barely
visible
on
the
slide,
whereas
extensions
for
other
new
technologies
that
we
have
done
would
be
much
yeah
would
have
to
wait
another
10
years,
that's
kind
of
the
minimum
time
we've
seen
next
slide.
R
J
F
F
F
I
think
it's
also
important
to
have
the
daywi
day
one
support
for
path,
steering
and
strict
and
loose
hops,
which
basically
means
to
be
equally
efficient
in
the
stack,
whether
you
have
a
support
by
hop
by
hop
for
the
technology
or
only
on
a
few
incremental
hops,
and
then
you
can
lose
the
loose
loose
hops.
So
the
more
scalable
I
mentioned
before.
F
That's
the
best
effort
and
what
we
call
the
traffic
engineering
path,
steering
solution
the
modes
and
that's
where
I
mentioned
the
flat
bit
strings
have,
in
our
simulations,
been
shown
to
require
more
copies,
to
be
sent
to
receivers
for
the
same
set
of
especially
small
receivers
things.
So
I
I
detail
that
in
one
of
the
solution
drafts
that
we
have
and
then
of
course,
very
important,
as
you
saw
from
guyan's
slide
deck,
the
integrated
support
in
the
header
for
service
guarantees
beyond
best
effort
which
so
far
has
been
punted
off
to
other
working
groups.
F
So
combining
these
things
is
really
difficult.
When
you
need
to
do
these
things
hop
by
hop
and
you
only
have
or
one
routing
header
that
actually
can
be
processed
hot
by
hop.
So
that's
why
I
think
it
needs
to
be
integrated
and
the
rest
is
terminology
and
and
and
a
sample
picture
next
slide,
which
is
the
last
slide
there.
F
I
think
the
really
cool
thing
that
we
can
do
with
ipv6
by
being
something
that
has
been
defined
all
the
way
end
to
end
is
also
for
these
constrained
control
networks
like
a
data
center,
enterprise,
iot
and
other
spaces,
go
all
the
way
up
into
the
host
using
ipv6,
socket
apis
and
then
the
typical
use
cases
you
start
with
are
the
big
data
center
servers
that
are
routers
themselves,
so
they
have
all
the
existing
routing
requirements
to
to
be
able
to
apply
the
existing
technologies,
and
then
there
is
additional
requirements
when
the
hosts
are
not
routers.
F
I
think
then,
there's
the
magic
inside
at
the
end,
so
yeah
right,
that's
what
we
would
like
to
have
right,
msr6,
keep
it
simple
and
make
ipv6
multicast
great
again,
so
native
state
is
multicast
for
all
ipv6
networks,
stateless
ipv6,
multicast
into
applications,
data
center,
industrial,
so
on
and
reuse,
and
share
all
the
good
things
that
beer
has
done
all
right.
Thank
you
questions.
Thank
you.
Okay,.
R
F
Well,
if
you're
not
going
to
do
forwarding
hop
by
hop
on
rfc
8200
rules,
then
what
do
you
do?
I
don't
know
I,
for
example,
beer
right
beer
is
a
different
forwarding
plane.
It
could
be
mpls,
it's
a
different
forwarding
plane
if
I'm
going
to
do
forwarding
based
on
an
mpls
header,
that's
not
native
ip.
If
I'm
forwarding
based
on
beer,
it's
not
native
rfc,
8200
forwarding,
but.
R
F
R
F
D
So
a
lot
of
people
are
not
joining
the
thing,
so
I'm
just
like
keeping
it
in
my
head,
so
I
apologize
but
greatly
appreciate
if
you
can
actually
join
the
app
on
there.
So
I
have
stig
tony
p
greg
joel,
that's!
What's
in
my
head.
N
Thank
you,
yeah
stigma,
yeah
I'll,
remember
to
use
that
sorry.
So
it
sounds
like
this
is
very
simple
and
just
plain
old
ipv6,
but
I
suspect
that
you
know
you
have
to
encode
new
things
in
the
packets.
You
need
to
process
them
and
how
you
do
that
processing
is
very
different
from
ipv6.
F
Yes,
but
no
no,
I
mean
it
it.
It
is
basically
a
a
steering
header
where
we
need
to
represent
a
set
of
destination
or
a
tree,
not
necessarily
through
flat
bit
strings
but
through
better
encoding
for
the
scalability.
You
know
it
started
with
rsv
sorry
with
brte.
You
know
me
recognizing
the
scalability
issues,
but
then
we
did
the
simulation
comparison.
So
that's
one
thing.
The
other
thing
is
the
other
header
elements
that
we
want
to
make
sure.
F
Obviously
it
needs
to
be
native
v6,
so
we
need
to
have
the
multicast
destination
address
in
the
header
and
then
I'm
thinking.
We
also
want
to
have
the
qs
header
elements,
for
example,
from
what
we
see.
We
would
need
in
a
stateless
mode
of
operation
for
that
net.
But
that's
a
lot
of
details
that
I
didn't
want
to
put
in
the
requirements.
They
are
requirements
in
my
opinion,
but
I.
N
T
T
This
thing
that
you
are
asking
for
in
this
bath
involves
representing
a
tree
and
involves
replicating
packets
along
different
branches
of
the
tree,
properly
processing
some
different
representation,
whether
you
put
that
representation
in
an
mpls
stack
in
an
srv6
stack
that
doesn't
yet
exist
or
in
an
extension
header.
It
is
still
not
the
same
as
current
native
existing
ipv6.
N
F
Right
so
joe,
we
we
can
argue
about
the
native.
You
know,
I
think
nobody
here
rejected
the
term
when
we
were
running
around
for
ten
years,
saying
go
native
for
ip
multicast
and
we
called
it
native
ip
multicast.
So
you
know
I'm
calling
it
native
ipv6.
That's
that's
fine!
If,
if,
if
the
discourse
gets
down
to
how
we
call
it,
let's
just
call
it,
you
know
rfc
8200
forwarding,
which
is
what
ipv6
does,
which
is
what
this
solution
does.
F
It
does
rfc
8200
forwarding
rules
and
then
basically,
no,
not
all
the
type
of
encodings
are
the
same.
If
you
have
you
know
ipv6
in
beer
in
ipv6,
that
is
not
matching
what
and
I'm
still
calling
it
a
native
ipv6
operator
with
an
ipv6.
Only
network
wants
to
have
right
so
so
that
is
I
mean
why
the
heck
are
we
having
srv6
stateless
source
routing
if
we
could
have
done
that
with
mpls
as
well?
Thank
you
very
much
right,
and
that
was
of
course
not
acceptable
for
operators
of
native
ipv6
networks.
F
G
I
can't
match
what
joel
won
at
his
emotional
level
was
was
brilliant.
Thank
you
joel.
I
feel
all
of
that
watching
this
presentation
so
much
misrepresented
of
what
happened
in
the
beer
working
group.
What
happened
with
this
work
along
the
way,
but
we
can
go
specifically
to
the
host
stack,
because
beer
is
not
a
routing
protocol.
It's
a
forwarding
paradigm.
G
Beer
says
nothing
about
ip
beer
says
nothing
about
mpls.
So
all
these
all
this
baggage,
you're
hanging
on
the
discussion,
is
a
is
a
fabrication
and
there's
a
misrepresentation
at
best.
What's
happened
in
the
other
group,
but
in
the
host
stack
when
you
say
this,
you
know
can't
be
done.
Take
20
years,
it's
been
done,
I'm
not
employed
currently
and
I'm
actually
unemployable.
And
after
this
conversation,
I'm
probably
going
to
make
that
concrete.
But
we
had
an
aws
beer
overlay
infrastructure
four
years
ago.
G
U
D
So
can
I
interpret
your
answer
as,
like
you
know,
beer
is
kind
of
open
to
other
kind
of
encapsulations
than
what
is
defined
like
you,
don't
have
to
answer
it
like
as
like
the
chair
itself,
but
like
do
you
have
any
thoughts
on
it?
Oh
I'd
love.
G
To
okay,
because
we,
when
this
work
was
first
presented,
it
was
presented
as
transitional
and
we
made
it
clear:
we're
not
changing
the
forwarding
plane
for
something
transitional
when
they
admitted
the
authors
that
they
they
wanted
to
go
to
native
beer
and
when
that
didn't
work
and
get
their
work
actually
accepted.
We
had
this
whack-a-mole
process
around
round
round
round.
But
what
I
made
clear
is
that
an
encapsulation
sounds
great.
We're
not
changing
the
encoding.
G
This
is
probably
a
not
an
exact
quote
from
aaliyah,
but
the
message
I
got
was
don't
with
a
forwarding
plane,
so
we
had
to
get
it
right
and
when
you
get
it
right
and
you
cut
it
in
stone,
you're
protected
and
taking
those
bits
and
shoving
them
somewhere
else
and
violating
layers
and
calling
it
integration.
It's
not
it's
not
honest
discussion
and
it
doesn't
represent
good
architecture.
G
F
I
don't
understand
how
it
is
a
you
know,
architectural
garbage
or
what
the
other
words
were,
that
I
forgot
in.
In
your
words,
when
we
are
having
an
equivalent,
you
could
say
of
a
multicast
version
of
an
sr
v6
routing
header
for
ipv6
packets.
So.
F
C
I
G
F
I
can't
answer
because
you
didn't,
let
me
end
finish
my
sentence.
D
Okay,
so
just
a
point
of
order
here,
I
think
we
are
way
over
time
for
like
the
solution
thing,
so
we
need
to
have
the
discussions,
because
I
think
it's
more
important
that
we
hear
about
the
problems,
requirements,
disagreements
and
hear
about
some
solutions,
so
we're
cutting
all
the
solution,
presentations
from
the
agenda
and
turning
this
now
into
an
open
mic.
So
queues
are
open.
D
Everybody
makes
statements
and
told
us
if
you
want
any
other
proponents
to
come,
join
you
here,
that'll
be
good
as
well.
Well,.
F
One
of
the
important
part
is
to
see
that,
obviously
we
have
a
strong
opposition
from
the
people
who
want
to
protect
their
market
segment
with
what
the
beer
solution
has
done.
What
whatever
you
say
around
that
and
so
one
the
solution.
Draft
intro
slides,
for
example,
would
list
all
the
vendors
operators
and
and
and
people
that
we
have
seen
to
support
our
direction,
and
I
think
in
the
past-
and
you
know
in
recent
work.
F
Many
people
in
the
ietf
stood
up
and
told
me
that,
obviously
you
know
when
there
are
differences
about
interest
in
solutions,
then
we
just
should
check
if
there
is
a
critical
mass
in
support
of
a
particular
solution
and
if
it's
technically
viable
and
then
you
know,
if
a
competing
solution
is
there,
the
same
thing
applies
to
it,
but
not
using
more
or
less
shame
arguments
to
try
to
suppress
competition.
I
think
that's
what
I've
been
seeing
here.
O
Hey,
I'm
sorry
for
the
non-technical
content,
but
there's
two
things
I
need
to
say
you
remember
the
note
well
that
we
all
look
at
the
beginning.
O
I
appreciate
that
everybody
here
feels
passionately
about
the
subject.
I
don't
appreciate
people
calling
each
other's
id,
you
know
ideas,
garbage,
etc.
Please
don't
do
that.
O
Second
point:
I
was
really
uncomfortable
with
the
cultural
appropriation
in
the
graphic
on
the
final
slide.
I
don't
know
if
other
people
feel
that
way,
but
I
it
made
me
feel
bad.
F
U
U
No,
let
me
maybe
you
know,
make
a
statement,
so
we
had
this
running
conversation
for
three
years
and
I
don't
think
none
of
the
stuff
that
we
said
that
the
process
you
know
was
run
through
resonated
much.
But
that's
still,
you
know
that
needs
to
go
into
the
minutes.
Okay,
so
I
understand
you
know
people
in
love
with
srv6.
U
Okay,
I
understand
some
people
may
already
have
the
stuff
in
silicon,
as
was
I
think,
admitted
in
the
last
bath
all
right
and,
as
yakov
said,
nothing
prevents
you
to
take
an
itf
standard
and
do
unnatural
thing
with
the
stuff
and
you
know
deploy
it.
The
point
of
idea
is
not
to
wide
wash
silicons
and
not
you
know,
have
people
fall
in
love
with
technology
and
just
build
yet
another
thing
because
they
love
it.
Okay,
the
substantial
problem.
I
think
that
you
have
is
that
those
use
cases
can
be
all
solved
with
the
stuff.
U
U
Having
said
that-
and
we
had
this
conversation
violating
layers
always
sounds
like
a
great
idea:
okay,
but
it
isn't.
The
costs
later
in
deployment
are
insane.
If
you
really
care
about
running
this
ipv6
native,
implement
something
like
beer
on
ethernet
and
you
can
send
an
ipv6
frame
over
that
over
a
beer
header
without
or
with
less
overhead
that
what
you
try
to
create
here.
U
This
is
most
likely
violating
six
men
and
it's
clearly
violating
beer
architecture
doing
that
stuff
all
right.
It
stomps
probably
on
three
different
charges
of
three
different
groups,
but
you
know
it's
out
my
pay
range.
That's
the
80s,
so
that
probably
should
go
into
the
minute
processes
have
been
run,
we're
like
fourth
or
fifth
time
at
the
same
place.
U
D
U
Because
otherwise,
what
are
we
working
on
just
another
variant,
because
somebody
likes
it
blue
rather
than
red?
And
you
know
additionally
breaking
seven
layers
with
always.
You
know
like
this:
it's
more
efficient.
This
is
like
the
first
thing.
I
fire
my
junior
development
developers
about
right
if
they
go
to
the
code
and
start
to
make
it
more
efficient
right
so,
but.
J
U
This
discussion
has
been
going
on
for
three
years,
so
we
didn't
make
any
point.
Obviously
the
parties
are
pushing
the
point,
but
that
is
for
the
minutes:
no
s,
no
without
any
motions
as
the
technical
layout
and
someone
that
cares,
because
this
stuff
fed
me
for
30
years
and
hopefully
will
feed
me
for
20
years
right
and
I
will
have
to
clean
up
this
stuff
operationally
with
people
deploying
it.
D
Thank
you.
Let's
go
ahead
and
greg
if
you
can
step
up
to
the
mic,
I
think
you're
first
in
the
line.
Okay.
So
when
told
us
answers
20
piece
question,
thanks:
you're
on
the
mic
line,
yeah.
F
Sorry,
it
was
so
much
and
I
just
took
the
notebook
a
little
bit
later,
so
I
may
not
be
able
to
remember
all
the
points
you
were
trying
to
raise
right
so
now
this
is
not
meant
to
be
beer.
This
is
meant
to
learn
from
beer
and
it's
meant
to
be
what
I
call
a
native
ipv6
solution:
call
it
just
an
rfc
8200,
compliant
ipv6
network
solution
and
yeah.
F
I
think
many
people
also
tried
to
sell
into
ipv6
network
traffic
engineering
with
mpls
and
ipv6
network
operators
on
the
unicast
site.
Didn't
want
to
have
that.
So
that's
why
an
rfc,
8200
forwarding
based
solution
was
done
for
traffic
steering
in
unicast,
and
this
is
basically
you
know
one
comparable
option
for
multicast
right
and
as
far
as
layer
violations.
No
it's
not
about
the
layer
violations.
F
V
Thank
you,
some
response
to
previous
comments.
The
first
one
is
that
I
think
maybe
people
just
remember
some
arguments
or
discussions
in
a
beer
working
group,
but
the
msr
work
is
very
very
beyond
what
we
have
done
in
beer
before
and
you
will
go
into
the
solutions.
There
are
multiple
different
methods
of
encoding
based
on
sales
routine
and
that
I
think
that
is
not
belongs
to
the
scope
of
beer,
and
the
second
point
is
that
ipv6
is
not
relevant.
V
It's
it's
not
only
one
type
of
encapsulation
and
it's
not
technical
preference.
Ipv6
has
its
capability
of
extension,
which
is
more
friendly
to
the
host
initiated
case
and
also
more
friendly
to
the
flexible
encoding
we
want
to
support
here.
So
I
think
the
these
two
features
are
the
core
of
this.
This
bulb.
So
I
think
people
can
give
more
pay
more
attention
to
the
solutions
and
they
will
see
the
benefits
there.
A
S
Hi
there,
tom
hill
from
bte,
there's
a
slightly
concerning
trend
of
claims
that
are
being
made
and
they're
not
just
being
made
within
this
both.
Certainly
the
first
two
presentations
made
this
claim,
but
it's
been
made
very
far
and
wide
in
a
lot
of
standards.
Organizations
that
operators
such
as
myself
fully
understand
the
benefits
of
srv6.
S
S
This
is
not
clean
cut,
yet
it
definitely
is
not
cleaned
up.
So
whenever
we
get
told
that
lots
of
people
are
really
interested
in
this,
I
don't
believe
it
because
I
don't
see
it
via
any
of
the
other
means
by
which
I
speak
to
my
peers
and
the
other
folks
that
run
operators
run
networks
in
an
operating
fashion
around
the
world.
S
F
Can
I
you
tell
me
when
you're
done
so?
No,
no!
I
I
think
this
is
an
excellent
point
and
I
was
using
so
first
of
all
I've.
I've
been
just
fighting
for
these
30
years.
Just
to
get
you
know,
equal
treatment
for
multicast
in
the
networks,
wherever
they
are
and
not
be
degraded
to
a
second-class
citizen.
As
far
as
technology
service
is
concerned,
for
the
multicast
right,
and
that
basically
was
learned
from
the
examples
that
I
said
where
you
know
we
started
saying
hey.
We
think
this
multicast
technology
is
better.
Why
don't
you
just
use?
F
S
F
Respect
to
srv6,
I
I
don't
have
any
strong
opinions
right,
I'm
just
caring
for
the
multicast
solution.
I
think
it's
important
to
understand
that
the
way
that
ipv6,
not
srv6
or
so
consider
to
be
source
routing
to
be
done
is
with
the
source,
routing
extension
header.
We
don't
have
only
sr
v6.
We
also
have
an
equal
extension
header
for
constrained
iot
networks
using
exactly
the
same
mechanism.
Some
interesting
routing,
detailed
differences
right.
F
So
this
is
not
only
proven
once
but
proven
twice
if
you
don't
like
it
and
and
and-
and
you
think,
there's
a
lot
of
problems
with
it.
But
let
me
ask
you
this:
is
this
a
reason
that
you
want
to
forbid
other
people
who
want
to
have
it
and
want
to
have
an
equivalent
multicast
solution
to
not
get
it
is
that
is,
do
you
think?
That's
that's
the
correct
prerogative.
What
you
have
what.
F
Right,
but,
and
for
for
us
on
the
multicast
side
right,
it's
it's
on
one
hand
using
the
srv6
example,
as
as
the
most
easy
way
for
people
to
understand
that
this
is
you
know
what
what
source
routing
is
doing.
The
reason
for
doing
stateless
multicast
is
a
lot
more
foundational
and
a
lot
bigger.
F
S
S
F
S
F
But
this
this
is
not,
I
mean,
except
for
the
rfc
8200
mechanism
of
using
extension
header
in
ipv6
as
the
code
native.
However,
you
want
to
call
it
way
in
ipv6
to
do
source
routing,
and
then
you
can
have
kind
of
up
with
your
solution
right.
If
you
don't
like
like
like
srv6,
that's
fine,
but
nobody.
It
tells
you
that
you
have
to
use
it.
F
You
have
to
judge,
I
think,
the
benefits
of
the
mrh
header
that
we're
proposing
for
stateless
multicast,
based
on
the
benefit
of
of
those
multicast
use
cases
right,
and
so
I
I
gave
a
couple
of
of
these
things
right.
The
statelessness
as
the
biggest
benefit
operationally
and
then
the
new
encodings
that
what
we
want
to
do,
10
years
after
we've
done
them
for
beer
right,
which
was
10
years
ago.
What's
the
best
we
can
do
now.
We
think,
10
years
later,
we
can
do
better
right
for
those
ipv6
network
for
a
longer
term
solution
right.
F
So
so
there
are
a
lot
of
technical
details
that,
to
a
good
extent,
would
have
been
in
the
solution
drafts
right
and
not
only
the
requirements.
There
were
scale
requirements,
and
so
on
that
drive,
I
think
a
significant
set
of
differences
and
yeah
the
the
native
forwarding
is
is
a
big
important
one.
I
mean
there
are
all
these
ecosystem
things
right.
F
I've
done
all
these
qs
thing,
diffserv
insert
acls
ipfix,
all
these
things,
and
it's
just
terrible
to
having
to
repeat
that,
for
let's
say
just
a
beer
based
forwarding
plane,
instead
of
an
actual
ipv6
forwarding
plane
that
just
has
source
routing
added
to
it
right,
that's
it's!
It's
the
whole
bloody
ecosystem
that
that
you're
starting
to
replicate
it's
already
hard
enough
to
replicate
the
ecosystem
from
unicast
to
multicast.
D
Andrew
go
ahead
because
you
are
in
line
before
the
other
people
got
on
thanks.
Thank
you.
K
Andrew
liquid
telecom
wearing
that
hat
and
purely
that
hat.
So
if
I'm
going
back
to
the
previous
point
that
I
was
making,
can
you
hear
me
now
that
better.
K
Okay,
there
we
go
so
going
back
to
the
previous
point
that
I
was
making.
K
The
fact
is
that
that
particular
use
case
I
was
referring
to
earlier-
shows
srv
sex
over
the
public
internet
unencapsulated.
That's
what
the
slide
showed
right.
That
is
a
clear
violation
of
8754,
clear,
clear
cut.
It's
got
nothing
to
do
with
the
solution.
Your
use
case
is
premised
on
a
violation,
and
you
refer
multiple
times
to
20
years
ago,
x
happened.
K
20
years
ago
we
looked
at
source,
routing
and
went.
This
is
a
bad
idea
and
we
deprecated
it
and
the
security
issues
when
you
are
showing
me
use
cases
that
are
premised
on
a
violation
and
then
when
people
say,
but
it
might
not
be
srv6,
but
the
simple
fact
is:
is
that
that's
what
this
is
called
msr-6
right,
and
I
also
have
to
second
what
tom
said,
because
I
keep
seeing
people
saying:
srv6,
wonderful,
everybody's
using
it
here,
etc,
but
there
was
a
slide
in
the
deck
earlier.
K
K
F
Andrew
so,
first
of
all,
I
don't
think
we
have
any
kind
of.
I
would
call
it
native
multicast
and
I
think
that
term
has
been
established
by
you
know
all
these
contributors
in
the
ietf
25
years
ago,
when
we
started
doing
pim,
we
have
very
little
of
that
in
the
internet,
the
best
that
that
we
have
are
kind
of
research
networks
and
everything
else
is
in
controlled
private
networks,
including
service
provider,
access
networks
to
deliver
iptv
to
their
customers
and
so
on
right.
F
So,
as
far
as
the
extent
of
where
multicast
today
goes
and
could
go
with
source
routing,
I
think
it
would
be
very
much
the
same
spaces
and
I
think
that's
a
great
and
excellent
discussion
to
have,
and
if
one
of
those
slides
was
misleading
to
say
it's,
the
random
part
of
the
open
internet,
that's
not
part
of
the
places
where,
for
example,
we
have
existing
multicast
solutions
that
just
don't
scale
and
are
you
know
harder
to
operate
than
the
stateless
versions?
That's
fine,
then.
I
think
there
is
a
mistake
in
that
slide.
F
As
far
as
judging
the
market
space
and
the
set
of
participants
in
the
ietf
that
are
proactively
working
toward
the
solution
because
they
believe
in
it,
I
think
that's
certainly
one
of
the
things
to
figure
out.
I
would
just
like
to
understand
to
what
extent
people
who
prefer
a
different
technical
solution
and
all
their
arguments
why
their
solution
is
sufficient,
should
have
a
significant
impact
in
the
decision.
F
I
think
it's
secondary
anything
that's
technically,
not
working
is
fine,
but
you
know
if
we
have
competing
opinions
about
market
space
solution,
I
think
we
should
just
vet
for
each
of
them
if
they're,
technically
solid
and
if
they
have
enough
support
in
the
ietf
positively,
but
not
kind
of
you
know
count
the
negative
against
it.
If
it's
not
technically,
but
based
on
a
different,
you
know,
market
solution,
preference.
E
For
the
use
case,
it's
not
just
like
we
have
msr6
and
then
we're
looking
for
some
real
deployment
or
something
like
that.
No,
it's
a
very
wrong
because
the
especially
for
the
first
case
for
the
teleco
domain,
this
advancement
of
5g
technology
and
commercial
deployment
and
then
we
with
them
like
the
tick
tock,
just
like
the
the
chinese
version
of
like
instagram
youtube,
those
type
of
things,
social
media
and
you
are
going
to
see
the
receivers
on
the
10th
millions.
E
Maybe
I
don't
know
it's
up
to
100
million
or
not
and
also
over
the
5g
network.
So
we
are
seeing
the
problem
with
that
and
seeing
the
dynamics
scalable
those
type
of
things,
and
then
we
we
try
to
get
the
you
know
something
to
handle.
It's
we're
looking
at
existing
schemes,
solutions
and
then
we
found
some
discrepancies
and
then
that's
why
you
know
this
and
also
for
some
other
use
cases.
The
same
thing.
Thank
you.
D
I
David
lamparte,
I'm
just
gonna,
offer
my
confusion
in
in
case
it
helps
I
I
came
here
to
working
well
to
a
session
called
multicast
source
routing
and
I
feel
there's
a
huge
piece
missing
where
there's
actually
a
discussion
about
what?
How
exactly
does
changing
the
the
location
of
determining
the
the
receivers
for
the
multicast
group?
I
How
does
moving
that
to
the
source
actually
help
us?
How
does
it
was
it?
What
what
does
this
provide?
What
is
where
is
this
coming
from
I'm
seeing
like
a
half
solution,
maybe
that
is
prepared
work
in
progress,
but
where
did
this
start?
Why?
Why
is
it
better?
Where
is
it
coming
from.
F
So
so
yes,
so
I
had
some
more
detailed
solution
slides
so
when
we
all
started
the
beer
work
right.
So
what
what
was
basically
happening
is
that
at
that
point,
in
time,
service
providers
were
saying
hey.
You
know
this
whole
multicast
stuff
is
so
difficult
because
we
have
to
troubleshoot
multicast
state
on
the
p
nodes
in
a
service
provider
network.
So
you
know
right
now.
F
And
then
we
said
that
doesn't
scale
right
and
we
can
give
you
a
solution
that
gets
rid
of
that
multicast
state
on
the
transit
hops
right
and
that's
basically
what
beer
became
and,
as
I
said
in
my
you
know,
evaluation
of
how
the
working
group
evolved
is
it's
just
the
way
it
implemented
the
forwarding
plane
aspects,
especially
the
encapsulation,
very
optimized,
for
mpls
networks,
and
there
I
think
it's
great
right
so,
but
but
but
but
this
all
goes
back
to
what
we
recognized
after
we
did
all
the
mpls
multicast
natively
for
10
years,
and
then
service
provider
came
back
and
said.
F
Well,
thank
you
for
spending
10
years
in
the
itf
on
doing
mpls
multicast.
But
now
we
decided
not
to
deploy
it
right.
So
that's
that's
basically,
one
of
those.
You
know
at
least
my
origin
story
for
beer.
I
Okay,
but
so
now
I'm
asking
myself
is
this
just
moving
the
problem
from
source
discovery
to
destination?
Discovery
like
the
argument
chain
is
not
computing.
For
me,
that
is
the
what
I'm
trying
to
say.
F
I
mean
I'm
happy
to
take
it
offline,
so
we,
I
think
you
know,
I
don't
think
this
answer
fundamentally,
would
be
different
for
beer
and
msr6
right.
So
this
is
this
is
all
about.
You
know,
I
think,
high
level
about
the
ipv6
networks
versus
mpls
networks
and
then
also
newer
and
better
encodings
of
the
source,
routing
things
kind
of.
If,
if
we
break
it
down
to
you
know,
fundamentals.
D
W
W
Mobile
and
as
an
operator
we
have
deployed
at
more
and
more
and
as
introduced
in
the
use
cases
we
have
a
very
large
network
and
the
potential
multicast
services
that
should
we
do
live
streaming
is
also
very
huge,
and
the
existing
flow
state
solution
for
the
multicast
cannot
afford
the
overhead
for
so
huge
days
for
the
funding
cost
and
the
existing
stateless
multicast
cannot
afford
the
large-scale
network
topologies
and
come
combine
all
of
these
requirements.
W
We,
I
think
we
need
a
simple
and
unified
solution
to
solve
this,
and
that
can
bring
a
new
opportunity
for
the
multicast.
I
think
so.
We
want
to
form
a
new
working
group.
That's
all
thank
you.
X
D
Shin
bin
will
come
back
to
you.
Chang
go
ahead.
D
M
Chang
hello,
hi
thank.
M
D
M
Okay,
okay,
so
I'm
muchan
chung
from
channel
mobile.
Here
I
would
like
to
provide
the
two
points
of
my
observation.
The
first
point
I
think
ipv6
traffic
is
increasing
rapidly.
M
About
two
years
ago,
this
number
was
less
than
20,
so
I
think
it
the
the
traffic
ipv6
currently
ipv6
traffic
is
increasing
dramatically.
M
So
we
have
reason
to
believe
that
in
the
near
future,
almost
all
traffic
will
be
ipv6
for
operator.
We
should
prepare
for
the
situation,
so
I
think
a
lot
of
discussion
we
have
done
just
now.
M
M
M
X
Okay,
now,
in
fact,
because
there's
no
time
for
the
presentation
of
the
solutions,
I
here
just
to
give
some
this
the
suggestion
about
this-
the
solution,
in
fact
in
the
solution,
it
shows,
in
fact,
in
the
used
case,
it
shows
that
the
prt
is
not
a
skill
enough
to
satisfy
the
requirement
and
the
user
cases
presented.
X
So
this,
in
fact
there
is
the
new
solution
cannot
covered
by
cx,
mark,
sabrina
and
and
the
beer.
So
we
think
we
need
a
new
venue
to
dis,
develop
this
the
new
solution,
so
this
is
just
a
consideration
for
the
msr,
both
okay,
that's
just
some.
This
is
the
thinking
about
from
this
the
solution
and
that's
the
proposal
for
the
ms
r6.
J
I
Y
This
is
the
hall
from
mrsa.
We
think
ms6
is
a
meaningful
topic,
as
discussed
today
appreciates
the
presenter
clearly
defined
applicable
scenarios
for
rmr6
and
its
native
ipv6
nature.
So
as
a
vendor,
I
believe
it
will
be
great
to
form
a
complete
solution
or
music
and
believe
that
a
separate
working
group
is
more
helpful
to
promote
the
process
with
this
matter.
Thanks.
E
Yes,
here
I
have
four
points
to
to
cover
here.
Basically,
it's
for
the
the
both
goals.
The
first
line
is
just
based
on
the
use
case,
based
on
the
gap
analysis
that
being
done
before
and
on
the
meeting
alias.
So
it's
going
to
say
to
answer
the
question
is
the
problem
is
a
real
problem.
Yes,
it
is
the
second
one
is
like
well.
Unfortunately,
the
technical
solutions
have
no
time
to
be
presented,
but
also
those
things
it's
going
to
show.
E
You
know
this
is
something
should
be
done
in
igf
and
also
it
can
be
done
in
itf.
But
the
third
point
is
like
people
you
know
from
today's
participant
to
their
discussion
and
also
from
the
alias
discussion
from
the
sign
meeting
discussion.
It
shows
an
its
sma's
subject.
Matter
of
expert
are
showing
a
demonstrate,
a
great
amount
of
interest
on
the
topic.
E
The
fourth
one
actually
is
like
is
that
the
reasonable
to
deliver
something?
Yes,
it's
actually
you
know.
If
you
look
at
the
the
sunni
hexa
there,
the
team
just
use
p4,
I
think
they
did
the
implementation
and
the
emulation
for
the
msr6,
be,
I
think
so
basically
means
it
can
be
done
so
for
out
of
forcing
together.
Well,
I
try
to
answer
the
question
for
the
boss
goal
so
yeah.
We
do
hope
this
one
msr6
can
be
accepted
or
in
to
be
done
in
the
idf.
Thank
you.
A
Okay,
I'll
abuse,
my
chair
power
and
hijack
the
queue
to
relay
the
message
from
the
chat
from
dinner.
Fairness
is
saying
what
does
multicast
scale
because
receiver
state
is
not
tracked.
If
you
require
the
source
to
know
about
the
receivers,
it's
a
non-starter
look
at
st2
from
mid-80s,
where
source
initiated
trees
failed.
F
So
I
think
one
of
the
core
understanding
is
that
in
large
networks,
most
of
the
multicast
is
sparse.
That's
why
we
started
with
what
we
call
pimp,
sparse,
node
right,
so
the
total
number
of
receivers.
Isn't
you
know
the
same
as
the
total
size
of
the
network?
F
The
size
of
receivers
typically
is
fairly
limited
and
they're
randomly
distributed
based
on
the
service
that
you
have,
and
you
don't
want
to
have
for
each
of
these
small
groups
relative
to
the
size
of
the
network,
a
state
on
every
hub
that
you
need
to
troubleshoot.
That
is
one
of
the
core
value
proposition,
exactly
what
you,
basically,
you
know,
started
doing
beer
for,
and
so
I
I
think
putting
this
into
question
would
equally
put
beer
into.
B
This
is
dino.
Well
torilis.
Your
core
author
said
your
co-author
said
that
they
need
to
support
10
000
receivers.
Are
we
going
to
put
10
000
receivers
in
a
source
route?
Give
me
a
break
okay.
So
maybe
it's
maybe
your
answer.
Is
it's
not
10
000
receivers?
It's
a
thousand
receivers
made
off
of
10
routers.
Okay.
So
at
that
point
the
replication
has
to
get
to
the
10
routers
and
then
they
each
replicate
to
1
000,
maybe
over
the
ram
that
supports
native
multicast,
that's
achievable,
but
that's
not
native
multicast
you'd
have.
B
F
No
so
I
mean
the
way,
we're
thinking
about
it.
Think
of
a
simple
service
provider.
Core
network,
with
whatever
number
of
pes
is.
The
number
of
you
know
destinations
that
you
need
to
do
source
routing
for
right
and
one
of
the
recognition
that
we
had.
Is
that
obviously
it
it
may
often
be
good
enough
to
just
have
something
like
256
bit,
which
which
is
kind
of
the
most
likely
standard
in
beer.
F
And
then
we
get
a
an
improvement
by
a
factor
of
256
by
just
sending
as
many
copies
as
we
need
to
reach
all
the
destinations
divided
by
256.
But
obviously
you
can
now
have
the
easy
problem
that,
especially
when
you
have
small
groups,
you're
sending
to
10
receivers,
but
you
actually
need
to
send
10
packets.
F
So
you
didn't
have
any
multicast
benefit
because
you're
using
flat
bit
strings
and
each
of
the
10
receivers
is
in
a
different
bit
string
and
that's
basically
what
we
run
for
a
large
service
provider
topology
as
simulations
to
show
them.
But
it's
it's
it's.
You
know
easily
understood
when
you
need
to
break
up
the
receiver
space
into
flat
bit
strings
so,
and
those
things
can
be
done
better
if
you
do
better
than
the
fat
bit
string
encoding,
which
would
be
the
next
generation
of
the
encodings
there.
D
I
think
sit
down
would
be
good.
Thank
you.
Thank
you.
Shuru
zhang,
please
go
ahead.
I
don't
know
if
I
got
your
name
right,
please
go
ahead
thanks.
C
Yeah
here
is
zhang
jieru
from
china
unicom
there
are,
there
have
been
about
40,
smart
micro
networks
and
some
byteball
night
work
notes
are
built
in
isrb6.
They
are
unicost.
We
really
need
new
multicast
for
large-scale
networks,
which
is
based
on
srv6r
ipv6.
C
D
D
H
Okay,
thank
you.
I
am
sijali
from
beijing
university
of
post
under
telecommunication
occasions.
We
would
like
to
make
an
introduction
about
our
project
in
over
a
minute,
but
we
didn't
have
it
enough
time.
So
we
put
it
in
this
section
in
the
this
classic
okay
and
we
had
a
hackathon
a
project
for
msrbe
solution
in
this
ieft
introduction.
H
It
means
in
includes
two
parts.
The
first
one
is
gp4
implication
of
msrbe
under
the
emulations
of
msr6pe,
based
on
intel,
tofino
sweeties.
H
D
Thank
you,
so
we
just
want
to
have
tng.
Did
you
want
to
make
like
a
really
really
brief
statement
on
that?
Thank
you
for.
E
Mentioning
about
the
1027
receivers!
Consider
it's
like
a
reasonable!
Actually,
it
is
for
our
first
case
and
you
look
at
the
5g
20
24
23
247
after
the
definition
about
the
five
five
mbs
nihana
architecture
from
the
ups
and
upf
up
to
ginobi,
and
you
look
at
that,
one
that
link
will
be
used
to
multicast
and
then
the
number
of
genovi
can
go
like
ballpark,
30,
000
and
beyond.
So
it
is
reasonable.
Thank
you.
D
Thank
you.
Thank
you,
so
I
just
want
to
do
like
a
quick
poll
of
the
room
because,
like
I
think,
a
lot
of
the
disagreements
coming
from
the
problem
itself,
like
not
in
the
solution
space
like,
even
though
we
did
talk
a
little
bit
about
the
solution
space,
so
I
just
want
to
run
a
poll
like
please
get
on
your
phones,
computers
to
raise
your
hand
or
not
raise
your
hand
based
on.
D
I
D
Pull
close,
so
we
have
a
very,
I
would
say,
evenly
split
room
and
like
remote
room
as
well.
D
So
it's,
I
think
our
conclusion
as
shares
and
to
be
confirmed
by
the
ad
is
that
the
problem
statement
requires
for
the
development
before
we
go
any
further
with
this
without,
like
you
know,
going
to
a
charter
or
something,
I
think
we
need
to
spend
a
little
bit
more
time
like
narrowing
down
the
problem
statement
right
and
we
can
continue
the
discussion
on
the
mailing
list
and
try
to
make
progress
over
there
instead
of
like
trying
to
go
through
the
working
group
charter
questions,
because
it
does
not
make
sense
right,
because
if
people
don't
have
a
common
understanding
of
the
problem,
it
doesn't
make
sense
for
us
to
ask
questions
like
do.