►
From YouTube: IETF113-BIER-20220323-1330
Description
BIER meeting session at IETF113
2022/03/23 1330
https://datatracker.ietf.org/meeting/113/proceedings/
A
C
A
C
A
All
right,
yeah
yeah,
no,
the
media,
echo,
is
good.
Yeah
buttons
are
changing,
it's
getting
better
and
better.
E
A
A
So
this
is
all
the
stuff
that
we
need
to
encode
in
non-mpls
case,
then,
let's
talk
about
the
io
am
stuff
that
was
suggested
in
basically
oem
in
general
classes.
Minuses
because
there's
a
couple
of
proposals
being
tossed
around
then
the
brfr
stuff
comes
up
again.
I
see
actually
I'm
I'm
lost
where
I
said
on
the
agenda.
Okay,
I'm
kind
of
I
lost
it
here.
Then
we
talk
about
the
brh
beer
stuff.
I
guess
again.
A
If
there
is
anything
to
be
talked
about,
and
then
we
do,
the
general
delivery
function
with
staff
is
interesting,
especially
with
all
the
oem
suggestions
and
fragmentation
coming
up
with
you
know
goes
across
multiple
different
technologies.
All
right,
so
we
fire
off
the
status
all
right,
so
there
be
a
bar
ipa.
I
think
jeffrey
closed.
All
the
comments
it's
on
alvaro,
pim
single
is
waiting
for
a
document
to
be
referenced.
The
the
architecture
is
kind
of
all
sued
up
I
saw
everything
has
been
addressed
pretty
much.
A
The
ospf
b3
is
hanging
in
publication
next,
one,
please
all
right
so
yeah
that
is
the
ethernet
goes
into
non-mpls.
Jeffrey
will
be
talking
about
the
stuff
next
one
right,
so
the
pattern
q
discovery
is
waiting
for,
write
up
and
ping
is
also
waiting
for
the
write
up.
So
I
assume
there'll
be
some
kicking
needed.
Okay,
the
bgpls
vr
is
expired.
Idr
didn't
react,
the
ibr
extensions.
A
The
draft
has
been
expired,
so
we,
you
know
we
have
to
go
and
look
for
authors
again
or
revive
the
stuff
and
the
multicast
hp
response.
Yeah,
sorry,
also
exactly
so
that
the
draft
is
being
replaced,
replaced
as
a
presentation.
Today.
Sorry,
that's
where
I
got
lost
because
I
still
have
you
know
the
multicast
http
response.
The
brfr
has
been
merged.
Everything
is
kind
of
ready.
There
is
one
mailing
list
stuff.
Oh
yeah.
I
should
probably
talk
about
the
git
quickly,
which
would
need
to
be
addressed
for
the
adoption.
A
I
think
it
has
been
brought
up
during
the
adoption
call
and
multicast
as
a
service
will
be
presented
today,
we'll
see
what
the
author
calls
for
adoption,
I'm,
I
will
work
the
queue
over
once
withdraw
the
status
next
one
please
all
right.
So
that's
kind
of
the
status
jeffrey.
You
have
the
mic.
F
Yes,
the
our
ipa
drafts,
thanks
for
alvaro
to
review
it,
and
we
had
quite
some
rounds
to
discuss
what's
the
best
language
there
and
yet
need
to
do
it.
One
more
revision
I
haven't
got
that
done
yet
should
be
simple
change
and
then
we
should.
You
should
be
able
to
move
forward
so
about
the
martingales
as
a
service.
Well,
I'm
not
presenting
it
today,
but
indeed
it
was
presented
before
and
we
call
we
wanted
to
do
an
adoption
call.
F
By
that
time
there
were
a
lot
of
drafts
to
be
to
be
called,
and
so
we
were
we.
I
was
so
that
we
would
pace
out
and
I
think
now
it's
time
to
to
to
do
it
now,
but
I'm
not
presenting
today.
I
think
that's
that's
about
it
from
me.
A
Okay,
so
I
take
that
stuff
as
adoption
call
going
to
the
list
for
the
beers
multicast
as
a
service.
Okay,
and
thanks
for
the
correction
on
the
idr.
Okay,
please
state
name
and
affiliation
we're
coming
up
with
the
mic.
It
will
help
the
people
online
alvaro.
You
have
the
mic.
G
Hello,
so
I
wanna
the
deck
is
not
there
anymore,
but
I
want
to
go
back
to
the
dear
freshly
route
draft.
G
A
Yes,
sorry
so,
yes
andrew
actually
suggested
that
we
have
some
kind
of
a
repository
where
we
can
have
a
history
per
draft
of
all
the
issues
that
have
been
addressed
and
what
is
outstanding,
and
we
went
back
with
greg
back
and
forth
and
with
the
secretary
and
we
decided
that
the
best
approach
will
be
basically
to
go
on
to
github
because
of
the
history
requirements
right
that
the
tracker
doesn't
allow
us
to
really
have
a
history
of
stuff
that
was
going
on.
A
G
Sure
so
I
don't
have
a
problem
with
that.
So
what
I
wanted
to
do
is
highlight
two
points.
One
is
the
lack
of
response
on
the
list
that,
if
you
already
replied,
then
that's
great.
A
G
G
How
are
the
issues
that
are
being
discussed
in
github,
going
to
be
reflected
to
the
list
or
not?
Is
everyone
expected
to
go,
get
an
account
on
github
and
follow
the
issues
there,
yeah
they're
going
to
happen
only
for
drafts
that
are
adopted
or
not.
This
one
is
not
adopted,
of
course.
Yet
so
you
know
there
needs
to
be
a
policy
for
the
working
group.
That
is
clear,
and
everyone
knows
about
it.
There's
a
couple
of
drafts
that
the
git
working
group
produced
last
year
on
recommendations
on
how
to
do
all
this
right.
G
Only
how
to
set
up
the
repository
which
you
already
did,
which
is
great,
but
also
on
on
the
different
decision,
points
that
need
to
be
made
that
need
to
be
made
right
because
you
know
whatever
issues
are
discussed
on
github
are
not
automatically
reflected
on
the
list.
Yeah.
Unfortunately,
right,
okay,
there's
a
note
well
issue,
and
you
know
all
that
other
stuff.
So
please
take
a
look
at
the
git.
D
G
Forget
the
numbers-
and
it
provides
there
a
list
of
things
to
to
consider.
A
Yeah,
don't
worry
we'll
find
that
stuff,
so
I
take
it
up
a
section
item
on
the
chairs
yeah.
I
think
you
pointed
us
already
to
this
good
working
group
and
then
we
kind
of
went
off
and
started
to
think
how
we
deal
with
the
stuff
with
the
history
issues.
It
is
unfortunate
that
the
tracker
does
not
allow
you
know
to
keep
the
issues
per
draft
and
the
history.
A
That
would
be
a
good
suggestion,
because
that
starts
to
become
you
know
more
and
more
of
a
pressing
issue,
since
mailing
lists
are
just
simply
too,
you
know
far-flung
for
to
expect
everyone
to
be
up
to
date
on
you
know
all
the
threats
and
all
the
stuff
that
has
been
raised
so
okay
action
night
with
the
chairs,
let
us
convert
from
the
stove
and
fire
up
something
to
the
list
with
kind
of
a
official
policy
I
mean
we
don't
want
to
make
it.
A
You
know
too
much
red
tape,
but
something
that
is
based
on
the
git
working
group
recommendation.
How
will
we
roll
the
stuff
forward?
Okay,
good?
Yes,
thanks!
Why
mo
you
have
the
mic.
C
F
Okay,
so
this
is
updates
on
this
non-mpo
extension
on
behalf
of
the
co-authors
next
step,
please,
it's
got
quite
some
history
back
in
2018,
we
have
this
initial
version.
The
name
is
non-mpos
extensions.
F
You
can
notice
the
non-nps
keyword
there,
but
at
that
time
the
scope
was
internet
only
and
because
of
that
three
months
later,
we
renamed
it
to
ethernet
extensions
to
reflect
that
scope
of
internet
only
and
then
later
on.
I
raised
the
question:
why
should
we
limit
to
internet
only?
There
is
no
reason
to
to
to
to
limit
that.
It
should
work
for
all
situations,
but
the
work
has
thought
since
then,
besides
the
working
group
edition
adoption.
F
Finally,
we
recently
confirmed
that
original
editors
could
no
longer
work
on
this.
So
I
took
the
pen
and
then
published
this
new
version
with
the
non-mpr
extension,
because
we
have
not
heard
a
good
reasons
to
not
to
do
so,
but
we
can.
We
can
still
discuss
it
whether
this
is
a
good
thing.
So
far,
I've
only
seen
good
reasons
to
to
make
it
generically
non-mpos
next
slide.
Please,
since
it's
been
there
for
quite
a
while,
so
I
thought
I'll
just
go
through
the
contents
very
quickly.
F
The
encapsulation
rfc
says
that
for
non-mpos,
the
biff
ids
they
are
domain
wide
unique
in
case
of
mpos.
Bifids
are
just
labels,
so
they
are.
They
are
locally
significant,
but
when
it
comes
to
non-pos,
they
are
domain-wide
unique
according
to
the
encapsulation
rfc,
and
there
are
two
ways
to
to
to
specify
the
those
gifts
but
the
brief
ideas.
F
According
to
the
draft
I
etf
beer
now
mpl
spift
encoding.
The
first
one
is
basically
just
hard
encoding,
big
string,
lens
sub
domain
id
and
set
id
sd5d,
and
when
you
do
that,
there's
no
need
for
provisioning
or
signaling,
but
that
does
not
give
you
any
flexibility
that
mpos
week.
That
gives
to
retain
some
of
the
flexibility.
F
Then
a
second
way
to
do
that
is
that
instead
of
hardcore
encoding,
the
bsl
and
subdomain
id
we
heart
encodes
a
16
bits
ibu,
I
forgot
what
ibu
stands
for,
but
basically
just
an
opaque
number.
F
F
So
in
another
draft
it
was
argued
that
even
for
non-mpos
beef
ids
can
be
like
mpls
labels,
and
if
you
do
that,
you
do
not
need
to
and
to
have
any
provisioning,
and
you
see
you
still
have
the
flexibility
that
mtos
way
provides
you.
F
F
F
So
in
this
documents
we
want
to
take
a
pro
take
the
approach
that
you
can
either
use
the
two
approaches
specified
in
that
non-mps
beef
encoding
spec
or
we
can
signal
the
beef
ids
that
can
be
local
or
the
main
web,
unique
just
like
how
we
do
it
with
mpos.
F
Basically,
they
will
be
extended
to
signal
dynamic
and
local
non-labeled
beef
ids,
and
it
mirrors
the
way
we
do
it
for
mpos.
F
So
in
the
in
the
bottom.
There
are
two
figures
there.
The
first
one
is
the
beer
information
tlv
that
is
already
specified
in
the
mpos
signaling
and
that
that
remains
that
trv
has
some
sub
trvs,
that
in
case
mpos
they
will
specified
npr's
encapsulation
and
it
will
signal
the
labor
bases.
F
Now
we
will
just
mirror
that,
so
we
have
a
new
sub
glv
to
signal
the
the
non-mplc
encapsulation
with
the
bf
ids.
You
can
see
that
if
you
replace
the
b5d
with
label,
then
it
will
be
identical
as
the
mpos
case
next
slide.
F
F
F
So
I
have
an
example
topology
here,
I'm
ospf
example,
one
area
on
the
left,
another
area
on
the
right,
bfer12
and
bfbr34.
F
F
F
Oh,
I
can
get
to
bfer3n4
through
bfr3.
So
as
long
as
I
know
that
and
then,
as
long
as
I
know
what
encapsulation
I
should
use
to
get
to
bfr3,
they
should
be
all
set
so
because
of
that
when
we
leak
the
routes
into
across
areas
or
across
levels,
then
for
beer
information
tlv-
if
we,
if
it
does
not
have
a
bfr
non-zero
bfr
id,
then
then
that
the
information
does
not
need
to
be
leaked
at
all.
F
Of
course
you
can
lick
it
it's
just
it's
not
it's
of
no
use.
So
we
can.
We
say
that
you
may
skip.
You
may
omit
the
beer
or
info
trv
along
with
this
subjects.
F
If
the
bfr
isn't
is
zero
and
then
you
may
also
in
emits
omits
the
increment
encapsulation
to
the
sub
glb,
even
if
you
do
dig
the
beer
in
for
trv
next
slide,
please.
F
So
comments
I
want
to
mention
that
we
we
had
a
working
group
last
call
before
on
the
idr
extension
and
also
bgpls
extension.
At
that
time
I
commented
that
we
should
wait
until
this
draft
settles,
because
this
drafts
originally
was
talking
about
ethernet
only
and
but
idr
and
bgpls.
They
were
money
they're
talking
about
non-mpos,
so
we
should
be
consistent
now,
if
we,
if
we
agree
that
we're
not
settled
on
this
one,
then
at
least
my
earlier
comments
on
those
two
drafts
and
they
are
no
longer
there.
F
We
believe
is
ready
for
working
group
last
call
we,
I
did
have
some
discussion
with
jin
roon
offline
on
whether
we
are
we.
We
want
to
use
the
locally
significant
significance
before
these,
so
I
added
those
slides
for
this
today
to
call
that
out
to
show
why
we
want
to
do
that,
and
I
hope
we
we
have
reached
that
consensus,
but
we'll
see
so.
A
Yeah,
tony,
so
what's
the
consensus
on
the
local,
significant
beef
beef
ideas?
I
didn't
see
this
discussion
going
on.
You
want
to
do
translation
between
domain
when
you're
leaking
or
what's
the
deal.
F
A
A
So
the
discussion
was
whether
we
need
both
variants
or
whether
we
keep
the
globally
one.
That
is
pretty.
That
is
basically
computed.
F
Both
they
are
all
okay
I
mean
they
did.
The
operator
can
choose
which
way
to
go
right.
A
A
H
H
I
H
H
This
job
outlines
on
requirements
on
iom
over
beer.
Some
multicast
flows
such
as
live
video
and
real
real-time
meeting
are
positive
to
packet,
loss,
delay
and
other
factors
nicely.
A
instituto
oem
provides
a
way
to
achieve
on-pass
telemetric
information
collection,
which
is
necessary
for
the
beer
multitasked
network
operator.
H
H
The
authors
believe
this
chapter
is
really
for
working
group
adoption.
However,
there
was
a
there
was
a
big
picture.
Tdf
brought
up
to
our
attention
last
weekend.
H
A
Okay,
so
let's
have
a
vivid
discussion,
because
I
I
thought
that
the
mailing
is
fired
up
in
a
very
productive
way
right,
and
I
think
I
would
like
opinion
on
two
axes
here.
The
first
one
is,
there
is
obviously
an
advantage
if
we
stick
iom
on
on
the
beer
packet
right,
because
it
kind
of
measures
the
data
path
as
it
goes
and
not
some
artificial.
You
know
oem
stream
going
now.
A
The
problem
is,
however,
that
the
beer
header
will
determine
what
is
the
destination
of
all
this
oam
information,
and
is
it
desirable
that
the
oem
ends
up
on
all
the
receivers
or
do
we
want
to
send
basically
an
oam
operationally
per
receiver?
Is
that
the
more
common
case,
because
it
determines
how
useful
the
whole
thing
is?
A
And
the
second
discussion
point
is
here:
the
second
axis
is
no
that's
the
primary
axis
and
as
observation
to
the
presentation,
I
think
the
authors
may
have
unders
misunderstood
how
oem
is
encoded
in
beer
today,
oam
is
its
own
beer
protocol,
so
the
oam
packet
does
not
carry
a
payload
behind
it
and
greg
mursky
will
correct
me
if
I'm
wrong,
but
I
think
that
was
how
all
oem
was
intended.
So
it's
in
fact
a
separate
stream
from
the
real
data
stream.
So
I
would
encourage
discussion
along
those
lines.
A
A
F
Okay,
jeffrey
or
darkway
from
juniper,
so
about
inc.
How
do
you
encapsulate
the
including
the
iom,
data
of
the
two
options?
One
requires
a
beer
extension
header.
I
suggest
that
any
discussion
related
to
that
extension
header.
We
defer
that
to
to
today
to
the
presentation
the
last
presentation
today
that
talks
about
exactly
that
topic.
F
I'll,
have
more
or
more
details
and
information
available
for
as
part
of
my
presentation.
At
the
end.
J
A
Okay,
so
I
think
the
main
objection
was
that
the
payloads
carried
in
the
beer
packets-
they
have
their
own
oan,
but
now
the
question
is:
should
we
rely
on
that?
That
was
not
the
beer
architecture
right
based
on
the
requirements
by
providers
the
they
wanted,
oem
directly
on
the
layer
2.5,
because
it
would
start
to
stick
ipv6
packets
and
into
beer
and
then
assume
that
the
ipv6
within
beer
does
the
oam.
A
K
K
I
just
want
to
point
out
that,
let's
not
assume
that
active
oem
does
not
follow
the
same
path
as
as
a
data
flow,
the
beer
flow
that
it
monitors.
K
So
in
terms
of
what
is
being
monitored
and
measured,
I
don't
see
a
difference
whether
we
use
iom
or
active
oam.
A
Greg
so
I
quickly
jump
in
this
is
true
to
an
extent.
You
cannot
guarantee
that
the
oem
is
following
the
same
queuing
disciplines
through
the
boxes
and
oem
may
have
different
packet
sizes,
which
all
affect
delay,
jitter
and.
K
Other
stuff
right,
but
at
the
same
at
the
same
time,
then,
if
we
use
iem
trace
options
up
by
hub,
so
the
space
for
telemetry
information
either
has
to
be
pre-allocated
by
their
ingress
bfr
or
are
incrementally
added
by
their
bfrs
as
it
transits
so
right
and
that
affects
and
skews.
A
I
H
So
the
question
from
tony
second
question:
iom
is
in
c2,
so
the
iom
header
is
with
the
packet
the
the
data
packet
of
the
beer.
So
it's
not
just
active
om.
So
it's
in
situ
om,
it's
with
a
package
data
packet
now.
Second,
today
I
want
to
say
currently
we
have
already
two
adopted.
H
A
I
I
would
contradict
that.
Go
look
at
all
the
supported
beer
protocol
in
the
registry,
for
example,
ethernet
and
all
kind
of
mpls
things
so
with
you
cannot
rely
on
the
fact
that
the
payload
will
always
have
its
own
oem.
It's
an
interesting
discussion,
of
course
right.
But
your
point
is
that
the
payload
carried
by
beer
will
always
have
an
aom
is
an
assumption
which
will
not
hold
up
okay.
L
Hello,
hello,
we
can
you
hear
me
yeah,
okay,
I
came
in
from
hawaii.
I
have
this
following
comments.
First,
I
I
in
fact
I
already
explained
my
concern
in
the
main
list.
Ever
before.
First
I
mean
that's
the
duplicate,
the
iom
functionality,
because
the
imprs
has
the
iom.
Ipv6
has
iom,
and
also
this
the
beer
is
the
independent
layer.
It
also
has
iom
if
the
beer
over
mpr's
appear
over
ipv6
there's
the
duplicate
rm.
This
is
the
functionality
and
the
encapsulation.
L
I
think
I
don't
know
how
to
cope
with
this
situation.
The
first
one,
the
second
one,
because
here
is
the
because
discuss
about
this
iom,
but
you
notice
now
this
there's
also
the
network
slicing
and
there's,
maybe
also
some
this.
The
alternative,
alternative
marking,
encapsulation
functionality-
that's
the
ipv6,
is
supported,
I'm
not
sure.
If
the
slice
for
the
beer
or
some
this
alternate
marking
for
the
for
the
beer,
do
we
need
to
go
on
to
extend
or
define
this
the
extension
header
for
the
br
layer
to
support
this
functionality
or
not
the
second
one.
L
L
F
Okay,
jeffrey
from
juniper
in
the
ipv6
environment,
the
one
option
to
do
to
the
beer
is:
that's.
You
do
not
need
the
ipv6
at
all,
always
you
can
between
the
two
adjacent
bfrs.
You
could
just
be
the
beer
header
following
the
ethernet
header,
so
their
ipvx
does
not
apply
at
all
and
even
when
we
do
need
to
use
a
ipv6
tunnel
between
two
bfrs
that
are
not
directly
connected
at
that
time.
F
The
the
iom,
information,
which
is
specific
when,
if
it's
specific
to
beer,
then
that
should
be
it
should
go
along
with
the
beer
header
itself
instead
of
at
ipv6
level.
That's
that's
how
I
say
it
and
I
don't
see
how
encapsulation
plays
plays
a
role
here,
because
let's
say
you
have
a
encapsulation
for
the
ipv6
tunnel,
but
that's
fine
and
beer
had
a
beer
processing
does
not
happen
until
you
exited
ipv6
tunnel.
So,
even
if
your
ipv6
tunnel
is
inc
encrypted,
that's
fine.
A
Yep,
pretty
much
concurs
with
what
I'm
thinking.
Thank
geoffrey.
C
A
L
A
F
I
want
to
add
jeffrey
from
junior.
I
want
to
add
that
in
case
of
beer
over
mpos,
in
most
situation,
the
you
there
is
no
nps
tunnel
and
then
the
label
is
only
to
indicate
that
the
beer
header
follows,
and
then
this
gives
you
the
bp5d.
F
Another
thing
is
that
if
there
is
a
a
reason
to
have
a
beer
extension
header,
for
example,
for
apm
for
whatever
purpose
for
slicing
as
long
as
you
need
a
peer
extension
header,
then
let's
defer
that
discussion
to
the
end
of
today's
session,
where
I
my
my
presentation,
talks
about
that
topic.
Exactly.
C
If
there
are
no
more
comments,
I'll
propose
to
take
this
to
the
list.
It's
a
good
discussion.
M
M
Let
me
see
how
it
looks:
that's
the
one!
Oh
yeah,
sorry,
okay,
still
labeled
http.
So
if
you
go
to
the
next
one
please,
so
this
is
a
zero
zero
draft,
but
there's
some
legacy
to
this
draft.
I
just
wanted
to
point
out
the
draft
regionates
from
and
now
expire
traffic,
which
was
in
version
six
on
multicast
http.
It
was
very
focused
on
there
was
an
applicability
oriented
traffic
to
realize.
Http
based
scenarios
in
a
beer
environment
must
have
been
the
order
of
three
and
a
half
years
old.
M
I
think
I
still
started
that
in
my
old
company
before
joining
huawei,
it
was
in
be
a
working
group.
Last
call
it
returned
very
useful
comments
and
feedbacks
from
the
application
areas.
We
had
a
couple
of
discussions
around
january
time,
etc,
but
we
took
this
back
to
the
original
author
set
to
see
if
there
is
an
interest
to
continue
on
this
and
there's
the
organizational
reasons
why
that
didn't
happen.
So
I
was
told
by
the
author
said
there
wouldn't
be
any
interest
to
continue
this,
which
is
the
reason
for
the
zero
zero
draft.
M
So
I
restarted
this
because
of
the
interest
in
the
original
trial,
so
I
I
thought
letting
this
trap
would
be
a
shame.
So
if
you
go
to
the
next
slide,
please
so
what
I've
done
in
this
version
now
is
to
take
the
to
generalize
the
draft.
So
it's
been
generalized
towards
a
new
communication
semantic
which
in
that's
done
in
section
three,
which
now
is
applicable
to
use
cases
that
are
more
than
just
http,
so
we've
turned
an
http
applicability
draft
into
one
that
is
tackling
a
communication
semantic
there.
M
So
there
are
more
use
cases
being
given
and
then
sections
five,
six
and
seven
they
are
adapted
from
the
original
craft
in
order
to
support
the
more
general
semantics.
So
it's
kind
of
like
removing
or
replacing
some
of
the
http
terminology,
section
eight
is
meant
to
be
a
placeholder
to
incorporate
the
comments
and
discussions
that
were
received
from
the
app
area
that
I
mentioned
that
we
discussed
in
january.
It's
still
a
place
where
it's
empty,
I'm
working
currently
on
on
on
on
on
putting
the
pieces
in
there.
M
If
you
go
to
the
next
slide,
please
so
very
briefly.
The
court
change
is
really
to
introduce
this
new
semantic
frm,
which
stands
for
fault,
request,
return,
multicast
semantic,
which
defines
a
very
which
you
could
already
see
in
the
original
draft.
In
the
original
http
draft,
a
multicast
communication,
semantic
is
extremely
flexible,
so
here
a
datagram
with
the
source
address
s
is
towards
the
destination
d1
to
dn
is
formed
as
one
or
more
responses
to
adequate
requests
from
those
destinations.
M
The
mono
requests
that
come
in
the
forward
direction
2s,
but
the
ephemeral
group
address
r
is
defined
through
an
identifying
characteristic
across
all
received
requests.
The
identifying
characteristic
is
an
implementation,
specific
parameter.
That's
used
to
distinguish
among
different
requests
if
you
translate
it
back
from
the
old
http
case.
Essentially,
the
things
like
an
http
uri
was
used
in
the
http
applicability
draft
to
differentiate
requests.
So
if
you
have
one
set
of
requests
coming
into
a
single
uri,
you
you
created
a
dynamic,
multicast
response.
M
If
the
uri
was
different,
it
created
a
different
ephemeral
group
address.
So
this
is
the
generalization
of
that
idea.
The
nature
of
that
multicast
is
inherently
dynamic,
so
the
multicast
responses
are
formed
in
response
to
incoming
requests.
They
may
differ
in
extremely
short
time
frames,
and
the
initial
example
of
the
http
case
was
showcasing
that
with
over-the-top
video
people
are
viewing
the
same
thing
and
you're
starting
to
deliver
the
actual
chunk
request
as
multicast
responses
back
to
the
actual
clients.
That
was
the
idea
there
go
to
the
next
slide.
Please.
M
So
the
next
steps
really
here
are
a
to
firmware
from
the
details
section,
six
and
seven.
You
know,
based
on
the
frm
generalization,
to
incorporate
the
comments
from
the
list
that
were
received
into
section
eight
and
obviously
to
incorporate
any
feedback
comments
from
from
the
list.
You
know
on
this
work
and
in
particular,
if
you
go
to
the
last
slide,
it's
the
main
question.
This
is
a
short
presentation
meant
to
be
really
answering
the
question
or
getting
an
answer
to
the
question
from
our
side.
M
If
the
work
is
still
of
relevance
to
this
group,
is
this
something
the
group
feels
worthwhile
to
continue
with
a
changed
author
set
at
the
moment?
For
the
reasons
mentioned,
I
would
also
like
to
understand
more
if,
if
this
work
is
more
widely
applicable,
even
though
section
six
and
seven
in
particular,
are
being
described
but
beer
in
mind
is
this,
given
that
it's
talking
about
the
general
communication
semantic
is:
are
there?
Are
there
other
underlay
techniques
that
could
be
utilized
for
that
any
thoughts
that
anybody
had?
M
M
A
Okay,
so
if
no
one
else
is
on
the
queue
I
jump
in
tony
juniper,
yes,
that
looks
interesting,
but
it
also
looks
like
reliable
multicast
generic,
reliable
multicast,
which
is
kind
of
you,
know
one
of
the
famous
red
holes.
It
can
be
solved
wonderful,
well,
it's
not
the
full
reliable
multicast,
but
you
know
from
one
source
to
multiple
destinations,
no
opinion
whether
we
should
you
know
take
on
anything
like
that,
whether
it
should
be
done
some
other
context.
I
think
it
very
much
depends
on
the
interest
within
the
group.
A
So
comment,
please.
If
you're
interested
you
know
in
this
kind
of
work
or
do
you
think
that
would
make
sense.
M
Maybe
one
short
feedback
on
the
reliable
multicast
on,
but
isn't
necessarily,
as
you
already
mentioned,
it
doesn't
need
to
be
reliable
multicast.
It
really
depends
on
some
of
the
service
implication
protocols.
We've
been
looking
at
there
they're,
not
necessarily
reliable,
they're,
relatively
transmitted.
That
may
may
happen
as
well.
I'm
sort
of
stepping
away,
because
taller
says
I
yeah.
N
I'm
trying
to
sneak
through
without
the
stupid
application
and
phone
and
so
consider
myself
the
button
to
be
clicked.
Sorry
about
that.
No
I
mean
the
way
I
was
joining.
The
original
effort,
which,
unfortunately,
due
to
the
you
know
main
authors
failed,
was
that
I
I
felt
that
this
this
was
back
then
the
best
option
to
promote
the
new
multicast
model
that
beer
gives,
by
being
able
for
the
sender,
to
indicate
the
explicit
set
of
receivers
for
every
individual
packet,
and
we
haven't
really
leveraged
on
on
that
opportunity.
N
Yet,
and
so
maybe
it
is
a
good
thing
that
we
can
try
to
broaden
the
scope
of
explaining
exactly
that
functionality
to
to
find
more
interested
beer
and
the
fact
that
we're
forwarding
through
sender
defined
bits
to
receivers
right
so
that
that
that
would
be
my
very
ad
hoc,
bad
sales
pitch
and
I'll.
Try
to
join
the
effort
by
some
appropriate
word
on
on
some
other
use
cases.
So
I'm
not
quite
sure
how
to
structure
the
whole
thing.
A
Okay,
some
input
from
my
side
will
be
focused
on
basically
requirements.
What
problem
do
you
try
to
solve?
So
we
don't
end
up
in
the
generic
reliable,
multicast
problem,
which
is
one
of
the
formulas.
You
know
totally.
A
D
A
Yeah
so
join
the
draft
and
work
with
tolas
and
the
author
on
specifying
what
problem
do
you
really
try
to
address,
because
it
seems
you
know
to
be
more
generic
than
before
I
know
and
before
we
can
even
go
and
start
to
maybe
280s
or
you
know,
talk
about
what
will
be
scope
of
work
like
that.
We
need
a
problem.
Definition
right.
Practical
use
case
is
fine,
but
really
what
is
the
scope
of
something
like
this?
Thank
you.
D
C
O
O
This
presentation
includes
four
parts:
the
considerations
for
beer
information,
encapsulation
in
layer,
3
header,
the
format
of
the
beer,
routing
header,
the
multicast
package,
forwarding
procedures
and
the
further
actions
of
this
draft
next
slide.
Please.
O
O
O
Considering
the
above
requirements,
we
think
use
routing
header
to
carry
beer
information
has
the
following
advantages:
it
lied
with
the
usage
of
rotting
header.
The
t
and
b
can
be
realized
in
a
unified
way
and
the
previous
requirements
can
be
met.
So
we
defined
a
new
type
of
routing
header
to
carry
beer
information
next
slide.
Please.
O
O
O
Then
it
checks
whether
there
is
fifth
correct,
corresponding
to
the
fifth
id
locally,
if
not
discarding
the
packet,
otherwise
performing
the
normal
beer
forwarding
the
same
forwarding
procedures
also
perform
r
node
d
to
e
to
f
during
the
forwarding
pass.
The
source
and
destination
address
in
the
ipwa6
header
are
not
changed.
Only
the
b
string
in
beer
routing
header
is
updated
next
slide.
Please.
O
O
O
Oh
okay
and.
O
O
Then
it
sends
the
packet
to
nazi
nazi
performs
normal
fpv
ipv6
forwarding
according
to
the
outer
fpv6
header,
and
sends
the
package
to
noddy
noddy
decapsulates,
the
outer
ipv6
header
and
forwards
the
packet
according
to
the
bift.
O
O
Our
next
steps
are
listed
here.
We
plan
to
extend
the
solution
to
carry
vpn
related
information
in
multicast
destination
address,
including
the
generation
and
transmission
of
the
address
and
the
behaviors
on
devices
to
handle
it.
That's
all
for
the
presentation.
Your
comments
and
suggestions
are
always
welcome.
Thanks.
I
P
P
A
No,
but
I
mean
they
ask
for
presentation
slot
it's
up
to
us
to
let
things
present.
Frankly,
I'm
lost
as
well.
There
were
no
updates
to
the
draft.
I
think
the
process
ran
its
course
all
the
way
to
the
bitter
end
of
formal
complaint
against
the
chairs.
But
you
know
if
presentation
slots
are
requested,
we're
perfectly
fine
to
see
something,
especially
if
there's
any
new
arc,
which
I
didn't
see
here
frankly
satisfactory
thanks.
E
F
Okay,
so
this
is
basically
to
the
slides
of
to
help
the
discussion
discussing
the
beer
extension
headers
next
slide.
Please.
F
Some
background
there
have
been
several
drafts
already
the
beer
that
start
talking
about
beer
extension
headers.
The
first
one
is
this
generic
literary
functions
that
we
call
gdf
that
we
put
out
a
few
years
ago,
a
couple
of
years
ago,
in
the
first
in
the
mpos
area,
an
er
growing
group.
F
Basically,
we
noticed
that
there
are
several
functions
that
are
currently
defined
for
ip,
but
they
are
actually
applicable
for
other
layers
as
well.
One
example
is
fragmentation,
another
one
is
security,
and
so
we
thought
that
it
would
be
nice
to
be
able
to
extract
that
out
and
apply
it
at
different
layers,
be
it
mpos,
ipv6,
beer
or
ethernet,
if
they,
if
they
want
to
do
so
so
we
we,
we
wrote
that
gdf
draft
and
we
we
discussed
it
in
mqs
working
group
at
that
time.
F
F
When
I
was
working
on
a
draft
about
the
beer
or
solution
support
for
network
slicing-
and
in
one
case
I
I
would
need
to
increa
encapsulate
some
other
information
about
a
slice
or
or
even
more
granular
information
that
that
would
need
to
be
put
into
a
extension
header.
F
So
for
that
I
brought
it
to
beer
working
group
as
well
in
the
last
ietf
meeting.
I
refer
to
it
in
a
slide
and
talk
about
it
briefly,
but
I
have
not
got
a
chance
to
actively
drive
the
discussion
in
the
beer
working
group,
even
though
I
said
yes,
though
this
when
it
comes
to
beer,
we
need
to
discuss
in
beer,
but
I
had
not
done
so
then.
F
Just
last
week,
I
noticed
this
beer
iom
drafts
where
we're
talking
about
the
beer
extension
header
as
one
of
the
options
to
encode
the
iom
information.
So
now
it's
clear
that
it's
time
to
actively
discuss
the
how
we
do
the
beer
extension
headers
back
to
npos.
F
It
has
a
design
team
to
look
at
mqs
extension
headers,
and
there
is
this
strapped
draft
song
talking
about
extension
headers.
I
think
both
taran
and
I
are
co-authors
of
that
draft.
So
when
it
comes
to
our
the
gdf,
we
wanted
to
align
the
beer
and
mpos
extensions.
F
F
F
F
F
So,
but
to
in
order
for
us
not
to
use
too
many
values
for
npos
purposes,
then
we
say
that
one
of
the
next
header
value
will
allow
us
to
say
that
we'll
have
subtype
so
that
we
can.
We
can
further
distinguish
which
are
the
mpos
or
specific
ones.
So
that's
the
basic
idea.
F
One
thing
I
want
to
point
out
is
that
you
can
see
that
if
you
exclude
the
the
header
headers
part,
it's
very
similar
to
ipv6
with
yx
one
difference
that
the
header
lens,
the
mqs
case
is
in
the
four
optic
units,
but
ipv6
header
is
header.
Lens
is
in
the
eight
active
units.
F
F
F
So
if
you
consider
that
for
real
generic
function
it
will
be
applicable
to
ipv6
as
well.
So
ideally,
we
would
want
to
be
able
to
just
reuse
the
ipv6
extension
for
particular
function.
If
there
is
ipv6
extension
header
defined,
we
would
want
to
be
able
to
use
it
as
is
for
mpos
or
for
beer,
but
the
header
lens
in
our
four
arctic
units
prevents
us
from
doing
that
next
time.
Please.
F
So
for
beer
here
are
the
questions
I
want
to
to
discuss
in
the
in
in
a
working
group.
We
don't
have
to
have
any
conclusions
here.
I
just
want
to
point
this
out.
We
can
follow
up
on
the
muni
list.
F
So,
first
of
all,
does
this
make
sense
to
beard.
We
want
to
align
the
extension
header
formats,
including
between
beer
and
mpos
and
even
with
ipv6,
and
in
the
iom
case,
do
we
want
to
use
this
format
for
br
iom?
If
the
br
iom
goes
ahead,
do
you
want
to
align
with
mpos
or
they
want
to
align
with
ipv6
as
well
they're?
Actually
so
one
simple
way
well
aligned
with
ipv6.
F
Is
that
simply
change?
That's
header
lens
from
the
four
active
units
to
to
eight
arctic
units
that
would
work
out
easily
easily.
I
guess
the
concern
why
they
wanted
to
do
a
four
active
units
in
npr's
case
is
because
it's
more
granular
so
for
us,
which
why
do
we
want
to
go
and
also
actually
just
before
this
meeting?
I
was
thinking
of
another
way
to
to
allow
that
for
after
units
normally,
but
still
we
have
another
container
to
to
to
put
all
the
ipv6
extension
headers
in.
F
So
I
just
want
to
throw
out
these
questions
and
then
we
can
discuss
here
and
discussing
in
the
mailing
list.
I
want
to
point
out
that
it
seems
that
in
the
brlm
draft
it
also
just
seems
to
be
putting
the
ipv6
header
directly
after
beer
header,
so
we
may
be
already
aligned
somewhat.
F
A
F
It's
really
to
ex
to
have
beer
extension,
headers
well
gdf.
To
do
gdf.
We
will
need
extension,
headers
right.
A
Okay,
go
to
okay!
So
do
you
have
you
know
some
packet
format
suggestion
what
we
would
need
to
do.
F
So,
ideally,
we
would
want
to
align
beer,
mpos
and
even
ipv6
extension,
headers
same
format
that
way
any
function,
that
is,
generic
that
can
be
applied
at
ipv6
or
npos
or
beer
level.
We
just
use
the
same
same
encoding
that
way.
The
hardware
implementation
can
be
reusable.
A
F
Oh,
this
is
one
way
to
do
the
g
to
do
the
gdf.
Yes,
this
is
the
one
way
to
do
the
gdf
proposed
way
to
do
the
gdf
from
me.