►
From YouTube: IETF104-BIER-20190325-1120
Description
BIER meeting session at IETF104
2019/03/25 1120
https://datatracker.ietf.org/meeting/104/proceedings/
C
D
D
D
All
right
over
there
just
don't
bump
that
don't
bump
that
chair
yep
all
right.
So
this
this
is
gonna,
be
a
v6
our.
So
this
draft
has
spawned
from
a
variety
of
drafts
that
have
been
presented
over
the
last
few
years
on
v6,
the
problem
being
how
to
get
beer
headers
across
a
v6
core,
whether
that
be
six
core
is
on
a
data
center
or
operator
core
or
whatever.
D
That's
trying
to
be
solved,
discuss
some
use
cases
and
mention
the
solutions
that
have
been
proposed
up
until
now
to
help
the
working
group
to
come
to
some
sort
of
conclusion,
because
a
lot
of
people
been
asking
us,
we've
had
customers
asking
us
about
beer
and
v6.
You
know
you've
got
the
segment
routing
folks
working
on
that
and
they
have
asked
you
know
about
beer
in
that.
If
you
know
SR
v6
world
and
how
I'm
gonna
make
all
that
work,
so
our
goal
is
really
in
this
strap
and
this
draft
to
be
completely
solution
agnostic.
D
D
Yeah
go
ahead,
yeah
next
slide,
so
it's
just
to
be
super
clear
or
again
we're
just
trying
to
get
beer
headers
across
v6
environment
and
there's
a
variety
of
ways
that
you
can
do
that,
and
we
mentioned
that.
We
mentioned
that
in
the
draft
I've
mentioned
some
of
these
things
and
reasons
why
we
want
to
do
this.
D
Discussions
happening
in
spring
if
you're
not
familiar
with
this.
This
area,
this
environment
in
b6,
is
called
non
MPLS
ipv6
networks
and
there's
been
variety
considerations.
They
have
v6
encapsulation
for
beer
to
have
beer
native
in
the
header
to
have
beer
in
the
payload
to
not
encapsulate
it.
There's
pros
and
cons.
We
tried
to
in
this
draft
not
mention
pros
and
cons,
because
it
could
be
a
little
bit
contentious
and
I'm,
not
sure
if
that's
the
right
approach,
but
we
just
tried
to
be
again
just
mention
the
solutions
and
just
say
how
it
is
Mike.
B
D
D
Not
saying
that
I'm
just
I'm
just
saying
that
SRB
six
is
something
that's
progressing
in
spring
and
whether
beer
is
it's
in
that
environment
or
not
are
the
things
that
have
been
discussed.
So
as
far
as
the
working
group
goes,
the
working
group
not
chattered
but
chartered
to
work
out.
This
working
group
has
been
chartered
to
work
on
beer
v6
and
we
we've
had
drafts
that
have
been
with
the
name,
including
six-man,
and
we've
just
changed
that
to
ipv6
so
to
Greg
and
Tony.
D
This
is
at
the
end
of
this
presentation,
I'm
going
to
ask
for
a
working
group
adoption
request,
so
just
a
heads-up
on
that,
and
if
that
does
happen,
either
now
or
later
or
ever,
then
there's
probably
some
coordination
that
you'll
need
to
do
with
the
six-man
working
group
and
maybe
other
working
groups
so
much
sure,
but
we're
determined
to
help
they
work.
You
understand
the
applicability
of
this
area,
okay,
all
right
just
to
continue
to
beat
a
dead
horse.
D
This
is
the
purpose
of
the
draft
to
describe
the
problem
of
transporting
packets
with
beer
headers
in
a
v6
environment
and
the
way
beer
will
function
in
that
kind
of
an
environment.
There's
been
several
proposed
solutions.
We're
gonna
cover
those
and
it's
supposed
to
help
them
be
a
working
group.
Okay,
so
we're
gonna
start
just
briefly
talking
about
each
of
the
proposed
solutions.
D
This
is
the
one
area
and
the
only
area
that
we
did
add
some
commentary,
because
with
that
commentary
it
helps
justify
some
other
solutions
that
have
been
proposed,
assuming
there's
some
more
native
ipv6
solutions,
and
so
we've
made
some
comments
in
there
that
you
know
there
are
some
benefits
of
having
a
more
native
solution
to
take
advantage
of
these
six.
You
know
network
program
ability
and
other
things
that
an
actual
native
solution
will
bring,
but
we
wanted
to
make
sure
that
people
knew
that
this
is
certainly
a
solution
that
is
available
as
well.
D
B
D
Right
so
in
this
case
and
I
think
his
name
is
Pfister
Pierre,
so
there's
a
draft
a
few
years
ago,
I
think
I.
Somebody
else
was
involved
in
this
one.
This
is
proposed
to
encode
that
bitstring
in
the
low
order
bits
of
the
destination
address,
I'm
a
v6
address,
and
then
the
unicast
address
is
a
usual
unicast
address
and
information.
There
is
used
to
inform
that
there
is
beer,
a
beer
header
here,
so
we
include
this
in
the
draft.
We
again
just
take
information
out
of
that
draft.
We
didn't
make
a
pros
or
cons
statements.
D
D
Well,
these
are
so
very
good,
so
it'd
be
good
to
have
you
think
about
maybe
even
getting
involved
in
our
draft
if
you're
interested,
but
you
can
transport
beer
as
an
IV
CIPD,
six
payload,
so
the
beer,
header
and
the
payload
is
part
of
the
ipv6
payload.
There's
there's
benefits
to
doing
that
and
that's
just
one
additional
option.
Okay
and
then,
of
course,
you
can
also
tunnel
beer
in
an
ipv6
tunnel.
D
So
these
these
are
the
these
are
the
solutions
that
we've
so
far
identified.
There's
potential
solutions
for
this
working
group
to
evaluate
again
we
don't
intend
to
choose
one
over
the
other.
Unless
that's
what
the
working
group
things
that
we
should
do
or
just
presenting
the
facts.
This
is
the
problem
and
maybe
in
subsequent
drafts
the
working
group
can
decide
what
we
think
is
probably
the
best
way
forward.
D
Eric
Rosen,
who
I
just
heard,
is
retired,
so
good
for
Eric
I'm
excited
for
him,
but
we
did.
We
did
quote
him
in
the
draft
he
listed
in
one
of
the
email
threads,
some
requirements
that
he
thought
were
best,
so
we
just
put
them
in
there
as
potential
requirements
for
whatever
the
solution
may
be
should
be
considered.
You
mentioned
things
like
it:
shouldn't
require
a
hop-by-hop
modification
of
the
destination
address
shouldn't
require
the
BFRs
to
inspect
layer
four,
and
things
like
that.
D
D
A
F
G
Cisco,
so
thanks
for
putting
that
together,
actually
I
do
think
it's
useful
to
see
all
the
different
options.
You
know
listen
with
draft,
so
you
can
have
a
quick
overview
on
how
to
compare
them.
So
that's
good
I
think
it
over
the
overall
problem.
That's
gonna
solve.
Is
you
want
to
have
if
you
see
expected,
replicated
using
v8
and
v6
destination?
G
Now,
as
you
say,
there
are
many
ways
how
to
do
that,
but
and
come
to
the
same
conclusion
as
Jeffery.
Ultimately,
the
replication
that
you're
doing
is
done
bf4,
so
no
matter
where
you
stick
it
right,
rayful
to
bits.
Ultimately,
you
end
up
somewhere
where
you
do
to
be
a
logical
so
and
is
a
question
like
to
what
is
native?
G
What
is
not
so
how
do
you
get
the
packets
across
from
note
to
note
because
I
think
taking
the
ether,
encapsulation
I
think
that's
probably
very
clean,
but
they
know
people
will
say
perception,
but
that's
not
ITB
6
right.
So
if
you
don't
put
a
v6
address
in
front
and
you
make
this
v6
address
specialist
say:
oh
now,
you
doing
four
six,
then
you
punch
it
to
you.
Their
replication
bother
no
same
thing
right,
but
it's
there's
a
lot
of
deception
and
that's
yes,
I
think
it's
the
biggest
problem
with
solvents
right.
A
So
either
you
take
the
v6
bytes
and
you
stop
you
stop
using
them
as
v6.
So
it's
not
v6.
You
just
found
the
bytes
or
otherwise
you
stick
it
somewhere
into
a
v6.
But
then
you
have
to
take
away
the
global
address
significance
from
v6,
because
otherwise
you
get
the
trouble
right.
What
you
forward
on
it.
It
can
have
basically
just
local
significance.
G
H
Tallis
eckhart
my
way,
I
think
it
will
be
interesting
to
wait
on
the
final
outcome
of
the
SR
v6
architecture
and
encapsulation
documents,
because
the
ongoing
review
with
requirements
from
8200
on
you
know
whatever
encapsulation,
you
know
changes
you
can
even
do
on
path.
I
think
would
equally
apply
here
for
when
we
put
the
bits
inside
the
string
right,
because
whenever
we're
resetting
bits
that
might
well
be
considered
within
8200,
as
you
know,
a
new
ipv6
packet
right
and
that
requires
then
rewrite
of
the
source
and
destination
ipv6
address.
H
That
is
the
you
know,
current
understanding
of
when
you're
actually
trying
to
change.
You
know
as
our
v6
extension
headers,
that
that
entitles
of
a
new
encapsulation,
so
source
and
destination
address,
need
to
change.
That's
just
the
cost
of
doing
business.
I
from
a
different
perspective
than
what
I
say
right.
If
you
want
to
be
in
a
wonderful
extension
header
or
behind
the
ipv6
header,
that's
a
cost.
You
have
to
suck
up
otherwise
go
below
ipv6.
That's
my
my
perspective.
I
Top
six
forwarding-
and
it's
really
not
native,
but
let's
this
music
is
very-
might
want
to
have
a
say
like
repair
tunnel
or
like
bypass
and
bypass
an
on
the
router.
We
want
to
do
IP
tunneling,
so
you
might
want
to
do
ipv6
forward
in
our
beer
package
just
to
reached
or
bypass
along
the
around
her
or
you
might
somehow
connect
to
beer
domains
by
tunneling,
basically
doing
ipv6
someone,
okay,.
D
E
Jeffery
to
follow
up
on
sticks
points,
ipv6,
tunneling
of
your
packets.
The
tunneling
itself
is
not
beer
forward,
he's
just
getting
the
packet
from
one
here.
Another
one
and
the
other
point
I
want
to
make.
Is
that
some,
if
you
are
trying
to
get
their
ipv6
multicast
packet
across
the
beer
domain,
I
assume
you
to
know
what
to
change
the
ipv6
multicast
destination
address.
So
if
you
want
to
use
ipv6
gierek
encapsulation,
that
means
you
are
going
to
doesn't
mean
you.
You
need
to
burn
another
ipv6
header,
okay,.
B
So
ii,
can
I
brush
that
directly
just
so
we
just
don't
rehash.
This
is
craig
again
chair
or
cisco
in
his
diagram.
There's
nothing
about
the
payload.
The
payload
should
be
irrelevant
in
this
case,
if
it's
a
v6
at
the
edge
or
v4
at
the
edge,
that's
irrelevant
to
what
the
end
cap
in
the
encode
for
the
beer
domain
should
be
I,
don't
think
that's
even
in
the
problem
statement.
Is
it
yeah?
So
this
is
not
about
what
is
in
the
payload
at
all.
B
E
A
F
Some
trying
really
hard
to
not
jump
into
solution
mode
and
keep
the
focus
on
the
problem
statement,
so
the
requirements
in
consideration
that
need
to
go
in
right,
whether
we
do
the
know
the
bits
in
the
last
64
bits
of
the
v6
header
or
inside
the
ethernet
header
or
where
that
goes
as
a
solution
space,
so
I'm
I
think
as
a
working
group,
we
should
definitely
pay
more
consideration
and
tension
to
the
requirements.
There
was
one
slide
later
that
says
here.
The
list
of
couple
of
requirements
and
I
think
those
are
really
good
starting
points.
I
D
Respond
to
that,
so
that's
a
very
good
point,
excellent
point:
we
took
it
from
the
tact
of
like
what
ice
mentioned.
Is
that
there's
so
many
different
solutions?
This
kind
of
just
do
a
brief
summary
and
all
that
just
summarized,
and
it's
a
lot
easier
to
know
where
we
stand.
I
think
those
are
should
stay
in
the
draft
personally,
but
instead
of
them
being
the
bulk
of
the
draft,
the
requirements
and
other
use
cases
should
be
the
bulk
of
the
draft.
F
H
A
D
H
Work
I
mean
the
question
is:
if
we
just
want
to
kind
of
do
waterfall
do
you
know,
waterfall
process
means
we
write
all
the
wonderful
requirements
that
we
would
like
to
see.
Then
we
make
an
RFC
out
of
that
and
we
go
back
and
figure
out
solutions
and
there
is
no
solution
that
fits
all
these
wonderful
requirements
so
or
if
we
try
to
have
a
little
bit
more
interactive
discussion
about
that.
Only
what
I
was
I
mean.
A
A
We,
we
rehash
all
the
solutions,
the
pros
and
cons
right
and
we
come
back
with
the
requirement
set
at
the
suggested
solution
and
capsulation
went
through
the
process.
It
was
incredibly
productive,
right,
possible
form
and
the
other
format
is
the.
We
argued,
the
waterfall
and
outer
problems
which
is
engaging
free-for-all
Jujitsu,
where
everybody
argues
for
his
solution.
I
mean
none
of
that
is
a
given
right.
It
so
be
argued.
What
do
we
do.
H
B
Now
now
this
is
Greg
Cisco,
but
now
we
crossed
that
line
again
that
that
jeffrey
talked
about
I
saluted
to
a
little
bit
and
it
came
up
quite
a
bit
before
and
I
talked
about
it
when
you
first
brought
up
that
second
use
case,
there's
in
calf
and
there's
in
code
and
at
some
point
you're
crossing
the
line
and
blending
the
two.
We
have
a
beer
header,
that's
well-defined.
Ultimately,
it
gets
pushed
down
into
a
hardware
fib
lookup
right.
B
So
if
we're
deconstructing
a
v6
header
to
reconstruct
a
beer
head
to
get
back
into
beer
forwarding,
it's
not
v6
we're
not
using
B
640.
Really
we're
trying
to
do
is
find
the
neighbor
with
an
ink
cap
that
works
hot,
buy
hot.
Now,
as
they
said,
eath
is
clean,
but
if
you
can't
get
it
hardware,
what
we
do
I've
heard
discussions
of
using
link-local
z6.
B
H
So
tell
the
secretary:
how
is
what
you're
saying
different
from
let's
say
s
our
v6
right?
You
also
have
an
how
much
time
do
you
have?
No,
no
in
terms
of
logically
from
it's
not
ipv6
anymore
right,
so
I
think
the
same
argument
could
be
said
about
SR
v6.
When
you
get
a
sit
and
thus
it
says
all
type
of
local
programming
and
stuff
I
result
in
replication.
We
don't
know
rights,
it
could
do
anything.
I
disagree.
B
H
D
E
A
D
E
A
B
F
Mean
Rajyam,
sorry,
so
from
ipv6
point
of
view
in
the
last
64
bits
could
be
used
in
many
different
manner
in
there
tons
of
different
out
of
C's
out
there
drafts
out
there
usage
out
there
in
mobility
space,
for
example,
and
so
it's
I
mean
having
something
in
the
last
64
bits
is
not
refire
fast,
but
again
that
delves
into
solution
very
specific
solution.
But
what
made
me
start
thinking
about
it?
G
G
So
maybe
that's
something
we
need
to
sort
of
list
as
requirements
and
see
what
you
want
to
do
there,
but
of
course,
for
the
router.
It's
it's
a
pain
right,
because
you
know
the
bits
are
so
far
into
the
packet
like
you
eat
so
much
bits
already
before
you
can
still
get
to
your
B
header.
That's
a
problem.
B
G
B
G
B
H
A
I
mean
the
beer
in
six
I
mean
just
how
I
circle
towards
that
is
because,
when
you
look
at
really
low
end
hardware
right,
the
beer
thing
could
be
actually
done
in
the
control
plane,
really
slowly,
because
the
v6
Hardware
always
exists.
But
then
you
pump
it
up
and
you
do
the
stuff
slowly
in
the
plane,
and
you
do
link
local
again,
which,
for
example,
who
is
routers,
is
not
an
unthinkable
option.
Well,.
H
I
was
thinking
that
if
we
just
have
the
standard
beer
header,
it's
just
the
next
product
called
from
ipv6
we're,
also
not
an
ipv6
extension
header
and
all
my
paints
of
8200
or
many
of
them
will
go
out
of
the
window
and
I
mean
obviously
we're
having
to
rewrite
the
source
and
destination
address
because
they're
linked
local.
So
that's
the
cost
of
authorship.
A
D
H
A
B
Anything
else
to
comment
on
the
on
the
problem
statement
draft.
So
if
I
can
summarize
it'd
be
tough,
hopefully
notes
are
good,
an
actual
requirements
list
to
extract
them.
This
would
be
good
thing
to
work
from
said
sound
like
what
we're
kind
of
looking
at
okay,
all
right
and
then
from
there
I
guess:
EC
potential
solutions.
B
D
Have
a
question
before
you
go
toilets
is
one
of
the
questions
that
we
bet
around
is
do
we
remain
agnostic
with
our
opinions
on
these
solutions?
Do
we
we've
done
today
or
do
we
try
to
put
in
some
pros
and
cons
some
benefits
to
these
solutions
in
this
draft?
That's
the
question
I
would
have
do
we
change
it
for
what
we
have
yeah
can.
B
I
answer
that
I'm
gonna
answer
that
just
as
a
contributor,
not
as
a
chair,
I
think
the
document
would
be
far
more
valuable
if
you
help
walk
through
that
process.
But
as
a
group
we
document
right.
So
it's
totally
fair
as
a
group
document
and
a
problem
statement
and
evaluating
the
Opera.
That's
exactly
what
we
should
be
public
view.
That's
what
I
think
you're
else
does
agree
with
that.
I
mean
that
kind
of
gives
the
the
paper
some
value
rights
and
the
documents
and
some
use
I.
H
Think
that
the
document
is
valuable
to
track
all
the
stuff
right.
Obviously,
if
we're
not
doing
waterfall
but
in
parallel
will
start
raising
opinions
right,
maybe
at
the
end
of
the
document
most
people
feel
oh
yeah.
We
know
that
four
out
of
five
options
are
crappy
now,
but
it's
still
valuable
I
think
to
have
documented
information.
All
right.
We
can
stay
neutral
right
now,
weather
will
stay
through.
B
You
know
comments
on
this
draft
in
particular,
so
there's
a
lot
of
good
opinions
here.
I
want
to
make
sure
that
we
take
this
to
the
list.
We've
gone
the
notes
here
that
these
are
things
that
the
entire
group
needs
to
contribute
to
and
maybe
restructure
for
the
problem
statement.
We
can.
We
can
thrash
that
first
and
then,
with
those
lists
of
solutions
we
can
start
hashing
out
pros
and
cons
and
I
tore
this
case
I
mean
you
took
kind
of
an
extreme
like
all
these
are
trashed,
not
necessarily
we
could
look
at
trade
off.
B
B
H
D
Okay,
so
my
my
request
to
the
chairs,
then,
is
that
everything
all
the
solutions
document,
including
the
next
one,
is
a
moot
point
unless
we
have
a
draft
like
this
to
kick-start
things,
so
my
request
should
be
to
with
the
comments
that
have
been
made.
Turning
this
into
more
of
a
requirements,
draft
adding
wajib
and
anybody
else
that
may
want
to
join
us.
B
D
D
C
K
L
Hey
guys
until
Bobby
again
and
it's
started
so
this
this
draft,
we
helped
post
another
way
to
you
know:
encode
bareheaded,
within
the
ipv6
header,
see
I,
think
Jing,
wrong
and
Mike
has
presented
the
solution.
Couple
of
the
past
280
of
meetings
from
there.
We
have
renamed
the
draft
and
rearranged
and
updated
sections
to
make
it
more
readable.
L
Remove
the
problem
statement
apart
from
this
draft
and
spawned
a
new
draft,
but
you
know
Mike
to
Center
from
the
technical
side,
we
have
removed
the
dependency
on
the
SRH
and
used
a
unicast
ipv6
destination
addresses
for
some
special
cases.
So
we
will
see
about
that
in
detail
further,
and
we
have
added
some
more
details
with
respect
to
each
field
of
the
encapsulations
and
the
forwarding
procedures
which
need
to
be
followed
so
anyways.
Will
you
know
about
those
things
the
detail
further?
Next,
like
this
yeah
here?
What
do
we
see
here?
L
Is
the
proposed
end
caps.
You
can
see
that
you
know
the
original
packet
is
encapsulated
with
the
outer
ipv6
header.
You
can
see
that
at
the
top
is
the
180
ipv6
header,
followed
by
a
destination
options.
Extension
header,
which
carries
the
native
I
mean
which
carries
the
standard
beer
header,
which
is
defined
by
our
of
CA
to
96.
L
So
what
we
propose
here
is
to
carry
the
beer
header
within
as
a
beer
option
TLV
within
the
destination
options.
Extension
header,
so
here
the
ipv6
destination,
address.
What
should
we
use
as
a
destination
address
and
IP
out
of
ipv6
header?
We
propose
that
could
be
a
well-known
multicast
address
which
could
be
reserved.
You
know
by
a
na
and
the
source
address
could
be
a
notable
ipv6
unicast
address.
Normally
English
routers,
you
know
ipv6
prefix.
L
A
L
L
L
I'll
go
to
the
next
one,
yeah
yeah,
so
forwarding
procedures-
normally,
yes,
I
mean
like
just
we
discussed
before
that,
it's
just
about
where
we
put
the
beer
header,
but
once
you
you
know
D
cap
state
and
get
the
beer
header.
We
follow
the
normal
forwarding
procedures,
as
described
by
you,
know,
RFC,
eight,
two,
seven,
nine
there's
no
change
there,
but
yes,
we
also
have
the
ipv6
header.
L
So
there
are
some
ipv6
specific
forwarding
procedures
that
we
are
talking
about
here,
like
I
mentioned
before
the
source
address
must
be
a
routable
unicast
ipv6
address
normally
be
of
IR
ipv6
address
I
mean
they
may
be
F
IR
prefix
that
we
have
advertised
in
the
IGP
and
the
destination
addresses
again
beer
multicast
address.
What
we
propose
here
is
this
f
of
zero
X.
A
B
R
could
be
an
unicast
address
in
some
special
cases,
which
you
see
shortly.
L
Yeah
nodes
which
support
via
v6,
can
you
know,
obtain
the
non
MPLS
beer
header
as
seen
before,
but
the
nodes
which
don't
support.
You
know
beer,
header,
I,
guess
that's
the
one
of
the
reason
why
we
have
selected
the
destination
options,
extension
header
and
backward
comfortable
node,
which
doesn't
support
a
specific
extension
header.
Like
you
know,
beer
options,
shredder
or
specific
beer
options
can
just
power
the
packet
using
the
you
know,
destination
address
without
looking
into
the
extension
seder.
L
So
here
we
explain,
you
know,
try
to
explain
how
the
forwarding
works.
You
can
see
that
as
the
you
know,
multicast
packet
enters
the
beer
domain.
The
ingress
router
is
a
here
encapsulate
s--
the
inner
packet
with
an
outer
ipv6
header
carrying
the
beer
header
in
the
destination
options.
Later
here's
full
case
where
you
can
see
that
the
destination
address
is
set
to
one
multicast
address,
which
is
reserved
and
well
known,
for
you
know,
be
route
us.
L
L
H
I
think
one
of
the
interesting
question,
which
is
why
I
mentioned
spring
and
segment
routing,
is
the
question
whether
you're
allowed
to
change
the
bit
string
without
calling
the
operation
be
a
decapsulation
in
rien
capsulation.
If
it's
the
letter
one,
then
you
need
to
change
the
source
address
to
be
one
owned
by
B.
That's
basically,
the
discussion.
L
Two
things
here:
I
mean
like
the
ROC
a
to
double
zero.
A
say
is
that
a
destination
options-
header-
you
know
the
option,
types
that
we
are
allowed
to
you
know
carry
allows
to
change
the
content
and
it
says
that
there
are
two
flags
in
the
options:
type
change
flag.
So
you
know
the
beer
option,
the
option
type
that
we
are
proposing
to
carry
beer
options.
H
L
H
F
Achieve
a
sorry
scope,
so
eighty
two
hundred
actually
allows
for
the
source
IP
address
to
be
retained
as
the
packet
transits
through
the
network.
In
fact,
we
early
this
morning
the
IP
p.m.
we
had
the
similar
proposal
in
which
the
IOM
data
goes
through.
The
changes
hop-by-hop
the
source
IP
address
does
not
change,
but
it's
still
worth
checking
for
this
point.
Okay,.
E
L
I
mean
like
l2,
not
thought
about
that,
but
yes,
but
we
are
thinking
that
you
know
it's
just
a
way
to
know
a
couple
of
advantages
here.
To
use
a
multicast
address
in
this
type
of
network
is
that
you
can
avoid
changing
the
destination
address
each
hops
and
again
itself.
You
know
alone,
addressed
give
you
an
example:
it's
just
like.how
OST
of
the
so
the
multicast
address
to
follow
the
packets,
something
like
that.
A
E
And
if
you
use
unique
as
the
appear
prefix
with
do
you
need
to
you
need
a
ton
ahead?
Heather,
because
if
you
just
use
the
unicast
address
the
beer
prefix
without
an
effect,
that
would
would
it
be
possible
for
you
to
say,
send
the
package
to
the
control
plane.
Oh
you're,
talking
about
using
any
case
of
distance
of
destination,
address
and
unique
right
now,
you're,
using
if
you're
unique
as
its
nutrients
and
with
the
first
with
the
rather
somehow
send
the
packets
into
your
control.
Because
your,
for
example,
is
your
loopback
address.
E
G
H
H
L
Yeah
I'll
mention
that
we
were
using
it's
possible
to
use
unicast
destination
addresses
of
special
cases,
so
this
is
one
such
special
case
where,
and
you
know,
support
non-beer,
capable
notes
in
the
network.
We
can
just
channel
over
try
to
tunnel
I
use
the
word
tunnel,
but
it's
not
exactly
channel.
We
can
bypass
the
non
beer
capable
nodes
by
using
the
unicast
destination
addresses,
as
you
can
see
here
that
you
know,
let's
assume
that
es
not
be
our
v6
capable
in
this
case
we
can,
just
you
know,
base
the
next
next
hops.
L
You
know
unicast
address
here
in
this
case.
What
happens?
Is
it's
not
really
a
tunnel?
What
he's
going
to
do
is
you
know
it
just
to
power
the
packet
by
native
ipv6,
forwarding
of
this?
This
is
in,
and
you
can
see
that
you
know
we
can
avoid
some
of
the
complexity,
complexities
that
we
have
talked
about
in
terms
of
MTU.
You
know,
gentlemen,.
A
Resist
the
urge,
ok
to
build
those
shortcuts.
We
have
an
architecture
which
is
hop-by-hop.
We
have
extensive
tunneling
with
sr.
We
have
all
the
stuff
in
place,
so
don't
shortcut
around
the
quick
and
dirty
hacks
will
remain
dirty
much
longer
than
they
have
been
quick.
Okay,
just
as
input
we
can
discuss
it
out.
Yeah.
A
L
So
why
do
we
think
this
encapsulation,
you
know,
may
walk
some
of
the
points
that
we'll
discuss
further?
Why
use
ipv6
destination
of
options?
Header,
like
I
mentioned
before
a
to
double
zero
says
that
you
know
doesn't
really
recommend
adding
new
extensions
header
and
less?
We
don't
find
any.
You
know
suitable
I
want
to
carry
stuffs
that
we
need
and
we
think
that
destination
options.
Header
fits
the
bill
because
we
think
that
you
know
it's
it's
suitable.
Where
in
you
know
we
have,
we
have
to
bypass
tasks
where
you
know,
transit
notes,
don't
want
to.
L
Why
use
multicast
addresses
ipv6
vfo
general
case?
Yes
again
and,
like
I
said
like
it's
not
to
make
it
simple?
It's
just
like
you
know
how
the
other
routing
protocols
to
seven
a
multicast
address
just
to
you
know,
recognize
that
this
a
beer
packet
and
to
you
know
also
to
pilot
the
Habra
have
for
body
this.
Can
you
know
simplify
things
further,
we
can
discuss
anyways.
L
This
is
a
another
point
where
and
we
you
know,
but
this
is
one
of
the
side
that
we
have
skipped.
We
think
that
we
can
continue
to
use
the
ipv6
next
set
of
field
rather
than
the
proto
field
in
the
beer
header,
because
we
think
that
it's
better
for
backward
compatibility
wearing
many
offline
tools
can
be
able
to
know
directly
recognize
the
beer
header
field.
I
mean
I
next
set
of
field
in
that
p
v6.
It.
L
Yeah,
the
previous
IETF
meeting
as
well
I
think
we
have
discussed
about
there
are
commands
about
very
clear
I
mean,
like
you
know
we
can
use
be
wreath
to
for
forwarding
the
packets
in
the
ipv6
network
as
well.
So
we
have
tried
to
compare
some
of
the
aspects
of
you
know:
beer,
v6
cab
that
we
have
proposed
here
with
beer
eat
the
first
stuff
we
have.
You
know
I
like
to
point
out.
It's
not
present
here
is
that
a
BRE,
this
L,
not
LT
agnostic,
can
work
only
with
you
know,
ethernet
links
wearin.
L
This
is
you
I
mean.
Basically,
since
we
are
putting
the
beer
hat
on
the
entry,
it's
basically
L
to
agnostic,
how
they
replication-
yes,
I
mean
like
not.
This
is
a
great
advantage,
but
you
know
we
don't
need
to
change
the
MAC
addresses
of
each
hub
destination.
Mac
addresses
each
hop
if
we
use
multicast
ipv6
addresses
destination,
and
you
know
I
feel
that
this
encapsulation
has
some
advantages
in
terms
of
you
know
how
to
support
non
we're
capable
nodes,
as
we
you
know,
seen
that
it
doesn't
really
require
tunneling.
L
L
Yes,
I
mean,
like
you
know,
Mike
mention
that
about
you
know
by
using
the
ipv6
header
natively,
we
can
try
to
see
that
we
can
get
some
of
the
advantage
of
Nate
I
mean
network.
Programmers
will
teach
you
here
as
well,
I
think
in
the
next
slice
we
can.
You
know
that
dingdong
is
going
to
present
that
we
can
see
more
about
that
I'll.
Just
you
know,
have
a
shot
mention
about
that
here.
That,
for
example,
you
know
SR
v6
interviews,
the
networking
program
will
wave
for
minutes
and.
B
E
On
this
slides
that
there's
three
beer
you
skinned
multicast
address
that
we
talked
about
that
it
doesn't
work
online,
so
you
have
to
use
única
unicast
and
that
so
that
difference
is
gone
and
the
markers
are
multi-hop
replication.
Whether
you
are
doing
is
not
no
different
from
tunneling
and
in
fact
you
are
making
that
you
are
doing
the
tunneling
even
on
the
hopper
hopper
it
entire.
It
appears.
H
G
A
Right,
let's,
let's
keep
it
short,
so
I'm
highly
sympathetic
to
not
modify
the
source
destination
right
I
mean
that
would
speed
up
the
forwarding
excellent.
If
the
16
man,
let
it
pass
cool
I,
think
the
option
keeping
in
the
option
is
of
a
vote.
I
think
that
getting
just
the
next
next
protocol
header
getting
a
specialized
thing.
It
just
appears.
You
know
your
friend
in
that
will
be
far
more
practical,
but
that's
kind
of
how
I
see
it
so
it's
kind
of
similar
we
can
merge
whatever
discuss
it.
Shades
of
things.
J
Hello,
everyone,
this
rafter
present
there
be
a
v6
emission.
This
is
the
initial
idea
to
define
the
be
a
v6
admission
procedures
and
messages.
It's
just.
It
invented
massive,
a
trio,
the
peer
PGA
attribute
with
the
I'm
just
neighbor
settled
0,
and
it
reads
the
PTP
prefix
as
a
key
attribute
with
the
ipv6
address
to
identify
a
median,
the
sacramental
emission
and
the
extra
lat
immersion
is
not
covered.
This
draft
also
help
understand
Adia
v6
and
it's
applicability.
J
J
There
is
also
some
IP
basics
in
universe:
racketeer,
really
religion,
legend
of
Maxwell.
Yes,
there
is
some
ipv6.
We
instruct
infrastructure
religion
felt
like
the
original.
A
team
routers
IP
address,
wrote,
attack,
targets,
extended
community,
and
so
on
this
this,
our
defender,
you
need
the
current
RFC
and
also
GTM
using
a
v6.
That's
that
yeah.
This
is
also
defined
in
in
current
RC.
J
B
B
Minutes,
please
email
them
to
me:
GJ
shot
the
Gmail
sent
up
two
chairs
I.
Think
it's
M
bone
chairs
work
soon
IETF,
but
you
should
still
my
direct
blue
sheets.
Everyone
sign
a
blue
sheet.
Okay,
everyone
find
enough
beer.
Yet
this
week,
there's
plenty
of
beer
around
eat
recommendation,
just
fire
them
out.
You
guys
have
a
great
week.
Thank
you
very
much
enjoy
Prague
and
the
rain.