►
From YouTube: IETF109-BIER-20201118-0500
Description
BIER meeting session at IETF109
2020/11/18 0500
https://datatracker.ietf.org/meeting/109/proceedings/
A
Welcome
to
bangkok,
so
I
got
the
slides
here,
so
I
don't
think
you'll
need
to
share
them
as
we
roll,
but
I
believe
we've
got.
We
need
to
take
a
let's
say
no.
Well.
First
welcome
to
beer
you're
in
the
right
room.
A
B
C
B
C
Somebody,
otherwise
we
shall
pull
a
random
person.
Take
the
next
one
after
her.
No
one
come
on
all
right.
Fine
I'll
do
the
minutes.
C
Yeah,
can
you
paste
the
link
into
the
chat?
Then
I
pick
it
up
and
I
will
be
taking
the
minutes.
Okay,
not
above
that,
and
we
have
an
exceedingly
lazy
crowd
tonight.
That's
okay,.
C
C
A
So
tony,
can
you
pay
attention
to
the
queue
as
well
or
you
want
me
to
do
that
and
bounce
back
for
someone's
gotta
mount
that
and
then
there's
questions
come
up.
So
I
guess.
A
D
C
A
A
The
current
agenda
we
shuffled
some
things
around
for
the
sake
of
discussion
from
recognition
of
the
a.d.
We
also
had
some
time
crunches
for
at
least
one
agenda
item
here,
so
we
moved
it
accordingly.
Let's
see
we
have
a
panel,
you
can
also
click
on
note,
taking
tool
top
right.
Look
at
that
see
that
tony
in
the
notes,
all
right
and
here's
the
agenda
you
straight
great
right
into
status,
so
we
have
a
bunch
of
docs
in
our
queue.
Most
of
them
have
gone
through
last
call.
Some
have
shepard.
A
Some
are
looking
for
shepard.
Some
are
waiting
for
shepard
write-ups,
some
need
other
reviews
from
other
groups
at
least
one
I've
sent
over
and
got
no
response.
I
probably
should
have
gone
to
the
the
chairs
and
solicited
some
help
there,
but
that's
our
next
step,
so,
let's
go
through
them
individually
and
we'll
find
out
who's
on
the
scope
here.
So
the
ipa,
the
bar
ipa,
we
got
consensus,
shepard's
done
we're
waiting
for
lsr
to
review.
This
is
the
one
I've
bounced
still
sorry.
A
I've
heard
nothing
from
them,
so
we'll
have
to
shake
them
up
with
the
chairs
and,
of
course,
all
ccd.
You
get
the
ads
big
stick
in
the
game
as
well.
A
A
E
G
Yep,
okay,
I
don't
know
it
says
here
that
you
already
had
either
your
review
or
not
yeah.
A
We
went
through
before
we
had,
some
comments
are
addressed
and
it
looks
like,
but
do
I
need
to
go
back.
G
I
no,
I
would
say
that
if
they
were
you
that
know
giving
them
a
heads
up
would
be
fine.
You
know
just
instead
of
in
other
words,
not
necessarily
wait
for
a
review.
Just
say
you
know
we
already
address
everything.
Here's
the
the
the
last
one
or
whatever
excellent.
We
should
be
able
to
keep
going.
A
We
got
pin
signaling
shepard's
done.
Comments
have
been
addressed,
we
do,
let's
see
shepard
needs
to
update
upload
the
review
in
tracker
and
then
we'll
bounce
it
to.
I
guess,
stig
and
mike
over
at
pim,
to
get
there
and
put
on
it
as
well.
Has
this
been
presented
in
pim
stig.
A
Let's
see,
I
don't
think
it
has,
but
at
least
you
know
now
we're
going
to
review
we'll
we'll
take
the
aid
to
the
chair
there.
We
go
stig.
H
Yeah
hi,
no,
I
don't
think
it's
been
presented
in
pen,
so
we
can
always
take
it
to
the
mailing
list,
but
it
might
have
been
good
to
have
it
presented.
A
H
I
would
say
you
don't
want
to
wait
for
the
next
itef,
so
yeah
just
just
send
an
email
to
the
list,
and
hopefully
a
couple
of
people
will
sign
up.
A
A
G
Yeah,
so
it's
not
the
acronym
police,
it's
the
consistency
made
sure
that
we're
talking
about
the
same
thing
everywhere-
people,
not
police,
good
reviewers,
I'm
going
to
call
them
for
the
record
here.
So
I
think
that
last
time
I
talked
to
deborah,
if
I
remember
correctly
yeah,
I
think
we
we
can
move
over
still
t
e
to
mean
something
else
tree,
I
think,
is
what
it
means
now,
that's
not
the
best,
but
I
I
think
we're
we're
good
to
go.
G
As
I
said,
not
the
best,
but
you
know
we
we
need
to
move
on,
so
I
think
we
can
move
on.
If,
if
there
are,
you
know
other
issues
that
that
debra
wants
to
bring
up.
We
can
see
those
in
ia
review
and
deal
with
that.
There.
I
Thanks,
can
I
just
quickly
comment?
Yes,
please
yeah,
I
mean
in
in
in
the
review
from
deborah
and
and
lou.
I
I
brought
out
the
arguments
that
you
know
there
is.
You
know
sufficient
pre-existing
evidence
that
there
is
a
no
consistency,
that
there
is
overloading
of
these
things
and
that
it's
well
explained
and
that
we're
doing
something
that
the
unicast
folks
aren't
doing
haven't
been
doing
so
that
their
pushback
is
not
taking
into
account
that
we're
doing
something
different
and
there
were
no
other
responses
to
these
arguments.
I
So
if,
during
itf
review,
other
people
want
to
bring
up
the
same
argument,
you
know
I'll
have
the
same
responses
and
I
didn't
see
any
pushback
on
them.
So
that's
why
I
would
say
that
alvaro's
evaluation
is
correct.
A
So
beer
ping
expired
recently
we're
waiting
for
the
shepherd
review.
I
guess
man,
if
you're
on
the
on
the
call.
This
is
where
we
start
pointing
fingers.
I
know
they'll
point
back
at
me
and
us
and
we
need
to
move
things
along
as
well
from
that
first
list,
but
we
have
some
shepherd
reviews
we're
waiting
on
here,
so
we
also
have
beeryvpn.
A
A
So
if
you're
looking
to
get
more
in
depth
in
this
exciting
thing
of
staying
up
late
at
night
and
staring
at
your
laptop
with
a
bunch
of
people
from
around
the
world,
honestly,
the
the
the
shepherd
process
gets
you
right
into
the
mechanisms
of
the
draft
of
the
process
itself
going
through
the
queue
and
it's
a
great
chance
to
get
engaged.
So
we'll
take
the
list,
we'll
ask
for
volunteers
directly
for
these
three
and
then
man,
if
you
can
bump
these
yeah.
K
Prepared
their
new
version,
we
just
want
to
update
their
contact.
Information
for
vera
is
not
with
huawei
any
longer.
So
we
need
to
confirm
that
we
have
a
correct
coordinates
for
her
and.
H
Stupid
yeah
so
about
the
mld
test.
There
is
a
hard
dependency
on
a
drafting
pim
for
an
igp
mlb
extension.
So
I've
been
waiting
on
that,
but
that
is
going
to
work.
Group
last
call
shortly.
H
A
A
Are
any
of
these,
your
bfd,
no
all
right
new
drafts,
but
I
guess
we're
not
even
discussing
them
well
what
a
shame
all
right
and
other
docs,
so
the
v6
requirements
it's
going
to
be
presented
again.
This
is
a
cycle
we're
going
around
and
around
and
I
want
to
say
we
need
to
be
firm
on
terms
because
we're
all
chasing
this
round
robin
of
semantics,
and
we
need
to
be
very
explicit
here.
What
is
encapsulation,
what
is
encoding
and
what
is
architecture
and
we'll
get
into
that?
A
Hopefully
tonight
in
some
detail
and
we'll
come
to
some
agreements,
and
then
we
can
have
some
plot
forward.
Let's
see
here
php,
I
guess
we've
addressed
the
comments.
Maybe
it's
ready
for
last
call.
Anyone
read
it.
A
So
I
guess
taking
it
to
the
last
call:
we'll
definitely
stir
the
list.
People
have
to
be
engaged
in
yeah.
Go
ahead.
Sorry.
A
Oh
seriously,
okay
status
says
it's
ready,
so
I
guess
we
we
slipped
that
one
through.
If
it's
finished
last
call,
then
that
means
we're
waiting
for
a
shepherd.
So
that's
four
shepherds
we're
looking
for
now,
so
please
solicit
friends,
family
neighbors
in
lockdown,
looking
for
nothing
more
to
do
than
read
and
follow
some
instructions.
It's
a
quick
list
of
questions
to
answer
and
we
can
get
you
through
these
things.
C
A
quick
intermission
alvaro,
it
is
still
necessary
for
people
on
the
mic
to
say
who's
speaking,
because
we
know
we
see
these
people
coming
up
and
I
know
who
people
are.
G
Let
me
think
what
I
should
say
right
now:
first,
I
don't
return
a
rallying
d
how's
that
I
think
it
would
be
nice.
I
think
the
muneco
indication
there
you
write
it.
It
tells
you
who's
talking
of
everyone-
who's
green
up
at
the
top,
so
it
should
be
okay,
I
think
in
general
it's
probably
fine
if
we
don't
initially
identify
ourselves,
so
it
is
not.
You
know
mandatory
to
to
identify
your
affiliation
or
anything
like
that.
But
people
want
to
you
know
it's
not
not
a
problem.
C
M
M
M
So
from
this
fr
beta
index
rounding
table
for
a
label
x,
we
can
derive
corresponding
fr
beta
index
forwarding
table
so
with
nerve.
A
node.
A
label
x
fails
so
the
node
as
a
will
use
fr
beta
index
forwarding
table
to
forward
the
nba
package
get
around
the
data
fail
the
node.
So
let's
look
at
the
details.
M
M
M
M
So
first
we
started
calling
the
bt
index
login
table
to
this
fr
rounding
table
for
x
and
then
for
each
designation
with
label
or,
like
slope
x,
we
compute
a
bicarb
microsoft
for
x.
So
this
bicarbonate
slope
is
a
l
of
a
for
protecting
against
the
failure
of
x
and
then
we
just
replace
this
x
with
a
backup
like
stop.
And
then
we
get
a
fr
bt
index
rounding
table
for
x
next
page.
M
So
here
we
just
give
our
examples
so,
for
example,
on
node
b
we
have
beta
e
next
login
table,
so
in
order
to
have
f
of
b
negative
routing
table
for
c
consider
c
failures.
So
first
we
just
call
the
e
to
the
unit
login
table
to
the
fr
between
routing
table
for
c.
That's
the
starting
point
and
then
for
every
equation:
node
we
select
top
label
c,
and
then
we
compute
bicarb
lag
stop
for
c.
M
M
So
because,
for
sometimes
after
the
load
of
phases,
we
don't
have
any
get
a
wrong
way
to
equal
in
this
case,
so
one
option
is
that
we
can
drop
that
package,
so
another
option
is
that
we
can
just
steal,
continue,
deliver
the
beer
package
to
the
fail.
The
note,
so
I
think
that
the
one
option
is
that
we
can
consider
this
a
special
case.
That's
a
option,
so
I
think
either
way
it
will
work.
M
M
L
First
of
all,
this
is
all
internal
implementation,
details
that,
even
if
you
want
to
write
the
document
graph,
it
should
not
be
a
standard
track
and
mostly
the
informational
track,
and
especially
the
way
that
you
use
a
separate
table
for
for
fr.
It's
not
not
necessarily
the
best
way
to
do
it.
L
I
understand
that
different
people
have
a
different
view
on
that,
but
if
you
want
to,
when
you
write
a
graph
about
it,
you
you
certainly
don't
want
to
document
the
the
best
solution
and
but
I
I
don't
think
we
can
reach
consensus,
that
if
this
is
the
best
solution.
M
Yeah,
I
think
I
also
let
me
give
my
opinions,
so
I
know
this
we
can
we
can.
We
can
have
multiple
labels
or
multiple
tables,
and
then
we
can
just
combine
multiple
into
one
table.
M
M
So
in
this
case,
so
we
can
see
that
if
we
use
different
separate
table,
it's
logically
very
simple:
we
we
generate
we'll
maintain
these
tables
separately.
It's
very
vertically,
very
simple,
and
the
only
thing
that
we
may,
which
first
consume
some
extra
memories
for
those
space.
We
don't
know,
don't
use
so
logically,
I
think
vertically
the
same
functionally
either
we
combine
multiple
tables
into
one
or
separately
vertically
or
functionally
at
the
same,
and
because
we
have
for
this
special
case.
I
think
your
separate
table
may
be
similar
vertically
for
maintenance
or
whatever
for
implementation.
C
Yeah
right
right:
okay,
stick.
M
You
mean
detect
the
failure,
yeah
or
detect
failure.
I
think
we
defend
that's
a
another
knowledge
when
I'm
around
him,
because
routines
are
too
slow
and
normally
it
should
be
used.
Bfd
or
whatever
detection
magnets
means
is
a
in
the
mini
seconds
is
faster.
M
H
M
H
M
A
Right
so
yeah
stick
you're
going
to
answer
reply
to
that.
N
A
So,
but
if
you
have
ipfr,
beer
doesn't
have
to
worry
about,
reachability
computer
can
just
be
forwarding
and
you
fine-tune
your
igp
so
that
the
beer
table
gets
updated
after
convergence
having
the
igb
converge
and
then
trigger
that,
for
our
calculations
seems
like
just
adding
a
layer
of
complexity
and
potential
race
condition.
Now
I'm
not
saying
the
mechanism
itself
is
is
not
valid,
but
architecturally.
M
Yeah,
I
think
in
the
that's
a
good
question
I
think
in
the
just
jeff
john
jefferson,
that
gives
a
very
good
comments
on
the
list.
So
jefferson
mentioned
that
in
the
architecture.
I
also
replied
that
one
in
the
architecture
document
they
mentioned
that
we
can
use
any
unicast
fossil
route
to
beer
right.
So
this
draft
is
about
apply
ipfr
to
beer.
So
that's
a
this.
C
So
greg
I'm
jumping
in
here,
so
the
igp
is
one
solution.
The
architecture
does
not
say
it's
the
single
possible
solution.
I
mean
nothing,
precludes
the
npr
architecture,
the
controller
from
installing
the
tables
right
right
right.
So
here's
my
observation
to
the
draft.
First,
don't
overspecify
don't
go
into
so
many
implementation
details
right!
This
is
all
very
vendor-specific.
It
mostly
backfires.
This
kind
of
drafts,
where
you
start
to
you,
know,
specify
an
implementation
in
a
lot
of
detail.
You
can
give
an
example:
okay,
but
focus
more
on
architecture.
C
I
see
a
use
case
for
it.
If
you
don't
have
an
igp
right,
because
then
you
don't
have
fr.
Igpfr
works
beautifully,
I
mean
implementations.
Are
there?
We
know
it
kicks
in
beer.
Just
runs
over
igpfr
works
like
a
charm
with
the
50
milli.
C
Now,
if
you
want
to
solve
the
use
case
of
a
controller
without
igp
or
something
installing
the
tables
which
doesn't
have
a
benefit
of
igb
computing
fr,
the
problem
you
need
to
solve
is
how
to
manage
and
synchronize
the
pq
space
right
between
different
routers,
because
everybody
has
to
agree
that
they
are
supporting
this
now.
What
is
confusing
your
draft
is
basically
specifying
igp
extensions
to
do
that.
C
So
it
would
look
to
me
very
weird
if
you
run
an
igp
just
to
signal
a
pq
space
and
not
use
an
igp
fr
to
provide
frr
so
think
through
the
issue.
How
will
you
make
sure
that
everybody
synchronizes
the
same
pq
space,
but
I
think
it
has
certain
architectural
lags
it's
right
now,
it's
a
overspecified
draft
with
too
much
implementation,
and
it
is
confusing
because
it
uses
this
igp
for
signaling,
at
which
point
in
time.
I
don't
think
there
is
a
use
case
for
it.
Thanks.
M
C
M
C
N
L
And-
and
you
really
don't
need
any
any
further
extensions
so
this
at
most,
you
can
write
the
informational
draft
about
it
and
there
is
already
a
draft
about
frr
and
it
was
presented
a
couple
of
times
as
well.
If
you
want
to
proceed
you
can
you
can
check
with
the
that
author
of
that
draft
and
then
see
if
you
you
can
produce
a
combined
document.
M
Yeah,
that's
good
so
for
that
data
data
java
is
also
called
called
the
bfr,
but
they
use
different
approaches.
I
also
reply
on
the
maintenance
so
that
fr
use
the
tunnels
to
the
legs.
Like
top.
So
that's
what
is
different
from
we
just
use
the
ipr.
A
So
we've
got
no.
L
Matter
how
you
use
it,
it's
whatever
you
use
to
to
to
protect
a
unicast
pass
to
a
to
a
bfer,
then
that
that
can
be
used
for
beer.
So
it
does
not
matter
which,
whether
it's
tunnel
based
or
ipf
firebase
or
whatever.
M
M
A
D
O
O
Okay,
thank
you.
I
remember
last
time
there
are
some
very
excellent
attacks
about
if
we
introduce
brfr
in
the
beer
mechanisms
the
time
there
are
some
benefits
rather
than
reuse,
the
igpfr
mechanism.
So
I
think
that
will
make
sense.
O
Last
time
we
have
a
test
showed
in
our
working
group
right,
I
think,
from
the
university
and
from
the
others
of
the
other
fr
drafts.
Do
you
remember
and
in
their
test
results
it
shows
that
if
we
introduce
brfr
rather
than
reuse,
the
igp
fr
there
there
the
time
will
be
much
faster.
E
P
D
Q
I
will
do
a
quick
comment
in
my
opinion,
this
structure
didn't
introduce
any
new
function
for
the
ipfr,
so
it
reduced
the
ipfr
function
to
make
it
as
the
brfr
function.
So
I
don't
think
this
introduced
any
new
in
ipfr
so
because
br
inherited
the
ipfr
advantage
from
ipfr,
so
I
don't
think
it's
needed.
That's
my
option.
Thank
you.
M
For
this
one
I'll
talk
about
the
beer,
egress
protection,
nice
page.
M
M
Page,
so
for
for
equal
production,
so
normally
we
have.
We
consider
we
have
a
multicast
tree,
so
this
is
multi-tree
is
indicated
by
the
bit
strains,
for
example,
which
just
consider
the
multiculturally.
You
have
one
equation
note
b
and
then
this
d,
as
the
equal
node,
will
send
the
multi-control
to
receiver
ce
so
consider
this
one
one
inverse
node
a
multicultural,
maybe
have
multiple
users
or
just
consider
this
one
to
explain
the
e-waste
protection
ideas
so
in
the
normal
normal
case.
M
M
So
first
we
need
to
have
a
configuration
on
this
node
d,
configure
a
backup
inverse
node
to
protect
this
equation
of
d,
for
example.
Here
we
for
node
d,
we
can
configure
node
h
as
a
backup
equivalent
to
product
b.
So
after
this
configuration,
this
equals
node
will
distribute
the
information
about
the
back
by
cover
equivalent
h
to
these
direct
labels.
M
So
this
forwarding
table
will
deliver
the
traffic
target
to
d
to
the
backup
equation
of
edge,
which
is
configured
so
in
this
case,
whenever
c
receive
whenever
c
detect
failure
for
equations
d,
it
will
use
the
egress
protection
for
the
table
folding
table
for
d
to
deliver
the
package
target
d
to
the
bicarbonate
equation,
node
h
and
then
the
backup
equivalent
h
will
deliver
the
traffic
to
the
receiver
ce.
So
that's
the
basic
idea
of
the
egress
production.
M
This
is
the
forwarding
type
of
either
this
logitable
for
y,
so
to
build
this
equals
production.
Rounding
table
for
y
on
that
on
that
node
is
easy.
For
example,
first
we
just
copy
the
normal
ba
index
loading
table
to
this
equals
production,
load
interval
for
y
and
then
for
every
equation
of
the
y
with
neighbor
y.
We
just
add
backup
information.
M
This
background
information,
which
is,
in
fact
just
the
backup,
equals
nodes
for
this.
This
eagles
node
y
so
use
these
back
any
bicarb
informations
when
the
label
of
y
detect
the
failure
of
y
and
then
that
label
will
use
this
bicarbonate
node
to
deliver
the
package
packet
to
equivalent
y
to
the
bike
of
those
equals
note.
M
M
So
here
on
the
node,
we
consider
protected
node
d
as
the
inverse
node
and
then
the
label
node
c
c
is
a
label
of
d,
so
on
on
labels,
unknown
c
will
create
an
egress
production
routing
table
for
d,
so
this
table
the
equals
production.
Relative
body
start
from
the
normal
here
in
the
controlling
table.
So
for
from
this
starting
point,
and
then
we
just
consider
the
equation
of
d
with,
like
top,
is
also
d.
So
for
this
this
foreign
entry,
we
add
the
protection
information,
so,
for
example,
here
we
just
add
protection
information.
M
Is
that
this
node
d
as
the
equals
node
is
protected.
We
use
the
flag
e
equals
production
ep
equals
to
one,
and
then
we
have
the
bicarb
equal
source
id.
So
here
the
backup
equals
id
for
protecting
the
equinox
b
is
h.
So
with
this
information,
so
we
can
forward
the
package
attack
to
d
to
its
byte
of
equals.
When
d
phase
fails.
A
C
But
that's
where
I
got
confused
because
here
are
you
signaling
the
protection?
So
my
question
is:
why
does
not
normal
fr
work
here?
I
mean
use
signal
protection
in
mpls
case
on
epe,
but
that's
because
you
need
special
labels.
You
don't
need
any
special
labels
here,
so
either
normal
fr
works
here
and
you
don't
need
any
signaling
of
the
backup
or
otherwise
it
doesn't
and
the
other
draft
doesn't
work.
So
that's
what
confused
me
between
the
two
drafts?
Why
you
signaling.
M
Yeah
this
one,
because
the
way
a
signal
is
that
it's
just
notify
the
bicarbonate,
because
the
ipfr
don't
provide
productions
for
the
e-waste
node.
C
L
So
I
also
made
comments
on
the
email
list
about
this.
One
first
of
all,
minor
point
is
that
they
have
separated
the
eagles
production
table.
It's
not
necessary,
but
that's
again,
that's
implementation,
detail.
L
The
main
concern
I
have
is
that
some,
according
to
the
drafts,
when
c
redirected,
the
package
that
was
the
best
into
d
to
the
protection
node
h
c,
will
actually
turn
off
the
beat
for
d,
but
turn
on
the
beat
for
h
and
that
well,
that
is
not
good,
and
if
there
is
a
receiver
of
h
each
one
that
receiver
may
get
duplicate
package,
so
I
I
also
in
the
in
the
email
I
I
mentioned
that
the
tethering
drafts
can
be
easily
extended
to
to
handle
the
egress
protection.
L
L
If,
even
though,
if
a
beer
node
fails,
you
can
think
that
okay,
I
have,
I
can
have
the
helper
node
to
deliver
traffic
to
the
to
the
ce.
So
I
think
that
that
solution
will
be
much
better.
M
Yeah,
that's
that's
arguable,
because
for
this
one,
so
if
we
have
a
good
planning
so
for
each
equals
node
and
then
we
configure
bicarbonate
to
know
because
in
the
normal
situation
or
in
the
normal
operation,
the
the
traffic
only
delivered
to
the
e-waste
node,
the
traffic
will
not
deliver
to
the
backup
using
those
equals
enough
right.
So
only
the
even
though
the
fails
and
then
we
deliver
trafficking
targeted
to
hebrew
to
backup
username
and
then
that
backup,
you
know
the
way
deliver
traffic
to
the
receiver,
so
that's
more
efficient.
M
So
if
we
have
a
good
planning
so
that
in
that
way,
so
I
know
your
case
is
that
so
if
we
have
a
mixed
configurations,
so
this
is
the
equation:
node
and
the
binary
node
don't
mix
the
biggest.
Then
guidewell
will
have
some
case,
as
you
mentioned,
that
we
need
to
have
a
tunneling,
and
then
we
also
needed
to
remember
the
primary
equation
repeat
and
then
on
the
by
table.
You
know
that
we
check
whether
this
is
a
for
for
the
primary
use.
Node,
we
don't
have
duplications,
that's
only
so.
L
M
Yeah
next
next
slide.
Yes,
this
just
gives
examples.
How
do
we
derive
the
forwarding
table
from
a
routing
table
and
then
after
we
have
routing
table
and
then,
as
soon
as
we
detect
the
failure
for
the
equation?
Node,
the
neighbor
node
will
follow
the
traffic
using
the
equals
protection
for
the
table.
For
that
eagles
note
and
then
deliver
traffic
to
the
backup,
usernodes
and
the
backup
backup
you
can
always
deliver
the
traffic
to
the
receiver
ce
so
next
page.
M
So
this
one
just
some
updates
for
forwarding
procedures
in
the
forward
procedures.
So
we
will
consider
the
protection
so
when,
when
a
node
is,
though
the
failure
fails
and
then
we
don't
have
a
pass
to
you
that
user
node
and
then
we
have
protected
information.
M
So
if
we
have
protection
information
for
data
equals
node,
then
we'll
check
equals
production
ep
is
one,
so
that
means
data
equals
node
is
protected.
Then
then,
in
this
case
we
just
clean
the
bit
for
that
equation.
Node
k
and
then
we
use
the
backup
equation.
Note
and
then
we
just
add
the
beat
for
that
bike.
M
A
E
L
Okay,
so
this
is
a
review
of
this
magikas
and
beer
as
a
service.
It
was
actually
presented
the
first
time
in
bangkok
two
years
ago.
Now
here
we
we
are
again
virtually
in
bangkok
next
slide.
Please.
L
The
basically
this
is
a
stable
and
we
believe
it's
ready
for
working
group
adoption.
L
L
So,
basically,
because
fear
does
not
require
per
flow
information
in
the
network.
So
now
an
operator
can
start
providing
multicast
transport
service
to
its
customers
in
a
very
scalable
and
simple
fashion,
and
this
is
a
simple
example
why
it's
not
simple.
It's
a
it's.
A
single
operator
example
many
asses
and
it
has
bfers
all
over
the
places.
L
Now
this
this
operator
can
start
with
only
bfers
and
no
bfrs
in
the
middle
just
start
doing
beer,
but
that
means
that
you're
essentially
doing
the
ingress
replication
between
the
bfers.
L
But
that's
fine
and
you
can
gradually
add
bfrs
at
strategic
points.
For
example
in
the
middle
of
asbr,
23
and
asbr-24
in
the
as200,
you
can
turn
the
br40
on
those
two
svrs
and
then
you
can
use
tunnel
encapsulation
attributes
to
steer
beer
traffic
along
the
beer
or
capable
routers,
and
then
let's
say
that
later
on,
you
start
a
most
of
the
routers
in
s100
or
you
know,
area
in
s.
100
can
start
supporting
beer,
then
at
that
time
you
can
enable
beer
in
that
a.s
or
in
the
area
as
well.
L
So
for
this
to
work,
we
will
use
pgp
based
beer
signaling,
especially
when
you
involve
this
multi-as
situation
and
and
when
you
have
a
native
beer
for
the
in
ais
or
in
your
area,
you
use
igp
signaling
and
you
can
distribute
the
beer
information
between
igp
and
iga
and
bgp,
and
we
already
have
a
working
working
group
drafted
to
cover
that
redistribution
notice
that,
even
though
this
is
multiple
aes,
it
can
still
be
just
single
beers
of
domain.
And
initially
you
don't
need
any
segmentation.
L
You
you
can.
If
you
desire
that
you
introduce
segmentation
incrementally
next
slide,
please.
L
Well,
the
same
topology,
but
imagine
that
es200
in
the
middle
is
actually
a
third-party
provider,
provides
beer
transport
to
its
bigger
customers.
In
this
case,
that's
in
that
for
that
provider
in
iso
200
it
does
not
have
even
have
bf
ers.
It
only
has
bfrs
no
customer
sg
stays
and
in
fact
this
third
party
provider
can
have
many
customers
and
each
customer
can
have
their
their
own
beer
domain
and
those
beer
domains
can
have
a
completely
sub
domain
ids
and
bfr
ids,
and
this
can
still
work.
L
All
the
details
are
in
the
draft
and
in
the
in
the
slides
at
the
end.
So
I
will
I
will
have
to
skip
those
details
for
now
next.
So
the
key
point
here
is
that
we,
this
solution
is
deep.
We
we
believe
that
it's
stable,
it's
well
specified
and
where
we
would
like
to
seek
comments
and
for
group
adoption.
A
A
C
O
C
N
O
Yes,
I
have
already
indicated
that,
but
maybe
my
my
audio
is
so
not
so
good.
This
is
true
so
on
the
mic,
and
my
comments
is
that,
as
I
remember,
there
are
some
previous
discussions
in
the
middle
east
about
when
we
discussed
about
beer
activities
requirement,
and
it
is
said
that
interest
domain
is
not
in
the
architecture
of
beer.
So
I'm
wondering
is
that
this
work
is
about
that
topic.
I'm
interested
in
this
just
to
make
sure
whether
this
is
inside
the
chatter
or
architecture
or
not.
A
Semantics
of
the
charter,
because
in
the
idea
that
we
would
have
multiple
igps
being
multiple
domain-
and
here
we
have
to
depend
on
that
and
extend
is-
is
not
what
is
actually
being
discussed
here.
This
is
a
single
basically,
reachability
domain
is
an
overload
so
because
it's
an
overlay,
it's
going
interdomain,
but
it's
not
necessarily
hot
by
hop,
enter
main
solution
with
beer.
A
I
mean
ultimately
because
it's
an
overlay
and
jeffrey,
I
got
a
lot
to
share
with
you
as
well.
I
should
take
some
of
this,
but
we've
explored
a
lot
of
things
because
it's
an
overlay
there
is
no
physical
topology.
You
need
to
adhere
to.
You
can
do
whatever
you
want
with
it,
and
now
your
forwarding
table
is
basically
yours
and
the
fib
can
be
identical.
A
T
C
T
Verizon
right,
yes
with
verizon,
yes,
yes,
thank
you.
Thank
you
yeah.
So
the
question
it
was
similar
to
the
previous
question
related
to
the
nras,
and
I
was
kind
of
curious
how
that
would
work,
but
as
as
greg
you
mentioned
it's
an
overlay,
so
you
so
you
there's
the
enter
to
make
the
boundaries.
I
guess
are
really
kind
of
there's
really
no
boundary
here.
Actually
you
can
really
extend
the
tree
really
anywhere
and
that
that
was
really.
T
The
question
that
I
guess
was
also
mentioned
was,
I
think,
one
of
the
slides
mentioning
like
about
distinguished
here
and
maybe
maybe
doing
like
our
key
translation,
or
you
know
this
would
yeah
in
the
draft
reading
through
the
draft
I
glanced
through
it,
but
it
didn't
didn't
really
go
really
deep
into
the
details
of
that
of
how
the
inner
domain
and
like,
if
they're,
like
translation
happening.
T
L
Well,
I
would
like
to
to
to
hear
more
from
you
on.
L
Jeffrey
from
jimmy
yeah,
so
yeah
again,
we
we
we
can
pull
up
on
the
money
list
or
offline
on
on
the
details
that
you
think
are
are
missing,
yeah
and
yeah.
I
I
and
greg
I'll
I'll,
follow
up
with
you
as
well
and
for
your
initial
question.
I
would
like
to
get
a
reference
to
the
original
email
that
you
are
referring
to.
I
don't
think
that
this
is
related
to
to
to
that.
But
let's
follow
up.
A
To
the
show
of
hands
tool,
we
have
live,
say
it's
ready
for
adoption.
One
says
it's
not
so
that's
enough
for
us
to
at
least
take
it
to
the
list
and
we'll
see
whether
the
crew
responds.
A
C
T
L
Okay,
so
this
is
about
mirror
independence,
fragmentation
or
or
ipsec
esp
function,
not
down
at
ip
layer.
You
can
you
notice
that
this
right
now
we
it's
it's
for
the
tsv
transport
area
working
group,
but
it's
got
a
use
case
in
beer
in
npos.
C
L
In
tsp,
so
the
use
case
can
be
in
beer
in
npos,
invest
but
actual
work.
For,
for,
let's
say
we
standard
adjacent,
whether
that
happens
in
in
tsv
or
not.
We
don't
know
yet
we
it's
okay.
This
subject
is
open,
yeah,
okay.
So,
let's
start
with
the
observation:
that's
with
evpn
using
npos.
L
L
L
So
today
the
only
workaround
is
use
ip
encapsulation
you,
you
first
impose
a
service
label
to
that
ethernet
frame,
and
then
you
put
it
in
the
ip
you
fragment
the
ip
package
send
that
across
and
then
on
the
other
end,
you
reassemble
the
ip
package,
decalculate
iot,
and
now
you
see
that
your
service
label-
you,
then
you
know
where
which
bridge
domain
this
this
package
frame
belongs
to
that
works,
but
notice
that
here
mpos
is
only
used
for
for
for
service
label.
L
It's
not
used
for
transport
at
all,
and
there
are
operators
who
do
want
to
use
npr's
transport,
and
in
case
you,
you
use
ipv6
encapsulation.
You
are
you're
having
a
large
ipv6
overhead.
L
So
this
the
need
for
fragmentation
is
actually
not
new.
In
fact,
pseudowire
and
vpos
sir,
has
a
solution
for
this.
That
is
documented
in
rfc
4623.
L
L
Because
evapn
either
does
not
use
control
word
or
when
it
does
use
control
word
it's
all
zero.
L
It
does
not
use
a
sequence
number
and
additionally,
in
case
of
pseudo-wire
and
vpos,
the
fragmentation
and
reassembly
is
down
in
the
context
of
each
pseudo
wire,
but
with
evpn
you
don't
have
the
pseudo
wire
anymore,
so
you
cannot
do
that.
L
You
cannot
use
rfc
463
method,
so
the
second
observation
is
that
some
ip
fragmentation
can
actually
be
viewed
as
independent
of
iot
as
long
as
that
identification
field
in
that
fragmentation,
header
is
available
today
in
case
iv,
fragmentation
you
use
the
ip
source
and
ip
destination
address,
as
the
contacts,
in
fact,
the
source
address
itself
is
enough.
You
don't
really
need
a
destination
to
be
in
the
context.
L
So
the
proposal
is
that
we
support
independence,
fragmentation
and
reassembly
function
in
a
shame
layer.
So
in
that
evpn
mpos
example,
now
the
ingress
key
it
imposes
the
service
label
and
then
the
fragment
package
now
notice
that
this
is
without
doing
iv
encapsulation.
First,
we
use
a
generic
fragmentation
header
and
the
next
value.
Next
header
value
in
the
header
says
ngos
to
indicate
that
the
following
that
the
gf
gfh
is
the
is
the
mpls
payload
now
compared
to
the
ib
basic
header.
L
The
main
difference
is
that
now
gfh
has
additional
information
about
the
source,
we'll
we'll
come
to
the
details
later,
so
the
ingress
pe
will
impose
the
gfg
label
to
indicate
that,
after
this
gfh
label,
there
is
this
gf,
the
genetic
fragmentation
header
that
follows.
Then
it
imposes
a
transport
label
and
send
traffic.
L
L
So
all
the
fragments
of
that
recommended
ip
packet
will
have
the
same
identification
number
and
that
identification
number
is
in
the
context
of
the
id
source
destination
address
now
for
the
genetic
fragmentation,
we
will
start
with
our
four
zero
bits,
followed
by
the
next
header,
followed
by
the
header
lens,
and
the
identification
field
is
variable.
L
L
L
If
we
don't
have
that
for
a
zero
bit
sphere,
when
this,
when
the
packet
goes
through
a
transit
router
and
that
transit
router
is
doing
a
ecmp
hashing,
it
may
think
that
this
header,
gfch
header,
is
ipv
ipv4
or
ipv6
header,
and
when
that
it
does
is
in
p
hashing
you
you,
you
may
get
a
packet
ordering
issue,
and
that
is,
if
you
have
read
the
straps
closely,
you
will
notice
that
that
four
bit
zero
four
zero
bits
there,
I'm
not
we're
not
in
the
draft
itself,
but
some
stewards
brought
this
up
brought
up
this
ecmp
issue
and
made
comments
on
the
menu
list.
L
C
Jump
in
tony
here,
because
we
had
this
precisely
the
same
nibble
problem
with
beer
right,
you
have
to
think
through
that
the
stuff
is
not
being
confused
for
v4
or
b6
and
whether
any
silicon
will
do
funky
funky
stuff
with
the
all
zeros.
That's
why
you
have
zero
one
zero
one
for
beer
right,
so
it
doesn't
get
forgotten.
Yeah
thanks.
L
So,
coming
back
to
the
motivations,
this
will
solve
the
event
evp
and
ngos
fragmentation
problem
without
incurring
iv
overheads
or
requiring
iv
transportation.
L
L
Encapsulation
has
a
protocol
field
and
that
field
can
be
used
to
specify
that
the
payload
after
beer
header
is
header
and
in
theory,
if
you
assign
either
type
for
gfh,
then
you
can
even
do
fragmentation
for
even
the
frames
on
a
pure
layer
to
a
device
that
is
just
in
theory.
If
I
triple
you,
think
that
there's
good
idea,
they
could
do
it
same
idea.
L
L
Next
slide,
please!
So,
basically
we
see
comments.
We
are
presenting
this
and
having
discussions
in
the
past
npos
here
how
and
ps
working
groups
we
we
will
need
to
find
the
home
whether
it's
the
use
cases
are
certainly
in
baths,
npos
and
deer.
But
if
we
decide
to
take
up
the
work,
then
the
design
of
this
solution,
a
standardized
solution,
whether
it
happens
in
phd
or
in
internet
area
or
some
other
working
groups-
we
don't
know
yet
that's
open
for
this
stuff.
K
D
A
Greg
independent
prom
say
ai,
so
did
you
present,
as
you
said,
in
csv.
L
Tsv
treaty
presented,
it
was
just
one
slide,
because
they
they
were,
they
were
prioritizing
governments
for
this
new
document.
They
only
gave
one
flight.
J
P
A
L
Well,
I
actually
missed
that
session
because
at
the
time
I
don't.
L
Any
discussion
there,
but
in
nprs
there
were
stuart,
brought
up
us
a
lot
of
comments
and
especially
point
of
view
problem.
So
we
we
do
have
a
proposal
to
solve
the
using
key
problem.
A
Isn't
living
here,
but
it's
definitely
stuff.
We
should
be
paying
attention
to
and
help
move
along.
Tony.
You
said
something.
C
E
J
T
All
right
hi,
my
name
is
gion
mistra
and
I'd
like
to
review
the
beer
ipv6
requirements
draft
on
the
list.
I
know
a
lot
of
a
lot
of
folks
are
familiar
with
this.
It's
been
around.
It's
been,
I
think,
we're
going
on
close
to
two
years
with
this
draft
the
next
slide.
T
So
what
I
wanted
to
do
today,
I
think,
on
this
with
this
presentation-
is
really
just
go
over
the
history
of
this
draft
and
really
some
background.
I
kind
of
kind
of
came
into
this.
You
know
in
the
middle
of
the
summer,
so
I
don't
have
complete
history
of
you
know
through
the
mailing
list
of
and
just
what
I've
you
know,
you
know
scraped.
You
know
you
know
going
through
the
mailbox
historically,
but
so
this
slide
what
we
do.
T
What
I
did
was
I
just
went
through
and
I
scraped
all
the
drafts
and
really
what
I
did
was
look
at
the
table
of
contents
and
just
like
you
know,
and
really
the
one
contentious
item
that
came
up
and
it
was
through
the
end
of
the
summer,
and
then
we
made
some
changes
at
the
request
of
of
the
work
group
chairs
and
the
sorry.
If
you
could,
if
you
could
stay
on
the
last
slide,
observe
it
then.
Oh.
T
No
problem,
yes,
so
what
I
so
what
I
did
was
so
I
did
there
was
there
was
a
debate
about
the
solution,
so
I
wanted
to
bring
this
up
that
so
the
solutions
and
really
what
happened-
and
I
talked
to
jeffrey
zang
about
this
a
little
bit
and
I
think
he
gave
me
some
feedback
on,
I
think
from
the
the
original
solution.
T
There
was
a
one
solution
that
came
out
in
2017
and
that
was
the
the
beer,
beer
and
beer
solution,
beer
and
six,
and
so
that
was
the
original
one
and
then
early
in
2019,
a
second
solution
came
out
which
was
an
integrated
mod
model,
the
brb6
model,
and
then
shortly
after
that,
this
draft
came
about
the
requirements
to
come
up
with.
T
You
know
set
of
requirements
because
we
had
one
and
then
a
second
came
and
then
really
trying
to
determine
well,
you
know,
does
do
both
drafts
really
meet
what
the
requirements
are
and
that's
where
this
all
came
about.
So
we
started.
Basically,
it's
may
2019
and
now
we're
about
a
year
and
a
half
later
we're
at
the
end
of
2020
we've
gone
through
10
revisions,
and
so
through
the
10
revisions.
We
have
had
the
solutions
in
there,
but
I
think
really
the
focus
after
this
last
revision.
T
Since
from
some,
I
guess,
from
from
revision
zero
through
the
revision
nine,
we
had
both
solutions
in
there
either
they
were
in
the
body
or
in
a
or
in
the
appendix,
but
they
were
in
the
in
the
draft
itself.
Just
in
the
last
revision,
we
did
remove
it,
so
we
removed
it
at
the
at
the
request
and
and
I'm
completely
on
board
with
it,
and
we
have
all
the
authors
on
board
that
we
want
to
focus.
We
want
to
get
through
the
requirements
and
we
do.
T
The
goal
is
to
you
know,
get
this
down:
get
this
set,
get
get
whatever
we
need.
We
want
to
get
it
done
and
and
then
move
on
to
the
next
steps.
So
with
that,
let's
go
on
to
the
next
slide.
A
Yeah
just
greg
his
chair
just
to
refresh
on
what
happened
on
revzir,
where
rev
zero
came
from
when
the
first
end
cap
draft
came
out.
Let's
call
it
an
encode
draft.
A
It
wasn't
clear
what
problem
they
were
trying
to
solve.
That
wasn't
already
solved
with
many
of
the
existing
tools
that
were
out
there,
and
so,
as
that
conversation,
does
this
normal
spiral
out
of
control?
We
said,
let's
just
start
with
a
requirement,
strap.
If
you
lay
out
what
the
requirements
are
we're
trying
to
solve,
then
we
can
better
evaluate
the
actual
solutions
and
then
come
up
with
some
later.
T
Here
I
understand:
that's
a
good
correction
that
you
said
so
the
requirements
draft
actually,
so
we
had
the
first
model
and
then
the
requirements
came
up
to
like
really
so
we're
all
kind
of
marching
to
the
same
page,
really
in
sync
and
then
and
then
and
then
came
the
second
one
gotcha.
Thank
you
for
bringing
that
up.
So
I'll
clarify
that.
Thank
you.
O
Thank
you
for
at
the
to
summarizing
history.
Actually,
I'm
not
sure
why
we
use
new
solutions
to
describe
the
calculation
solution.
Using
four
solutions
are,
they
are
doing
things
and
defining
new
things,
and
I
I
cannot
say
something
is
inside
the
existing
toolbox
and
something
is
wrong.
I
think
there
is
no
such
conclusion
before
just
one
comment
and
I'm
okay
with
the
other
conclusions
here.
P
C
P
O
Oh,
let
me
just
repeat
my
comment
here.
Yes,.
E
O
Okay,
I
just
want
to
say
I
don't
know
why
people
just
classify
these
few
human
solutions
describe
it
as
something
new
and
someone
who
is
traditional
and
inside
the
existing
toolbox.
I
think
there
is
no
solution
here,
because
all
these
true
solutions
or
existing
solutions
are
new
for
beer
episodes.
O
P
T
For
this
draft,
so
the
purpose
of
this
draft
is
to
specify
the
requirements
for
transporting
packets
and
beer
headers
in
the
19v6
environment,
and
the
focus
is
really
on
the
requirements.
So
I
think,
as
the
chairs
and
ada
requested
to
remove
the
solution,
so
I
think
we've
offered
we've
agreed
to
remove
that,
and
I
think
that
would
really
kind
of
raise
your
focus
on
these
requirements.
So
we
want
to
get
through
that,
get
that
nail
down
and
that's
when
that's
really
the
goal,
so
we
want
to
help
help.
T
T
So
what
I
did
was
I
broke
up
the
revision
so
revisions
here
through
four.
They
had
some
commonalities
and
then
revision.
Five
through
nine
had
commonality
which
and
the
commonality
was
version
zero
through
four
it
was
all
broke.
It
was
all
one
set
of
requirements
and
we
didn't
have
mandatory
and
optional
and
then
revision
five
through
a
nine,
had
the
breakup
of
required
enough.
T
So,
as
you
can
see,
we
have
we
had
a
bunch
of
initial
requirements.
I
guess
zero
one,
two
three
four
most
all
of
them
were
all
within
each
one,
so
we
have
layered
two
agnostic,
hvh
destination,
option,
layer,
four
inspection,
multicast
address
in
the
force
address
field,
sorry,
field
incorrect,
fit
support
of
your
architecture,
conforming
to
ipv
specification,
support,
simple
encapsulation
essay,
quiltery
support,
icon,
stack,
support,
fragmentation,
hardware,
fastpass
and
then
support
itd6
security.
T
So
as
we
evolved,
we
could
see
through
rev
five
through
nine,
some
of
what
was
in
the
ground,
zero
through
four
and
dropped
out
and
we'll
go
through
the
mandatory
and
then
what
I
did
was
I
kind
of
gave
the
notation.
T
You
know
you
know
five,
six,
seven,
eight
nine,
which
whatever
requirement
was
part
of
that
draft,
so
so
they're
they're,
two
agnostics,
so
that
that
was
in
five
and
six
and
then
shortly
after
that
and
then
after
that
and
rev7
had
dropped
out
various
where
two
link
types
so
that
stayed
all
the
way
through.
So
that
was
seven.
Eight
nine,
supportive
beer
architecture
that
that
was
an
important
one
and
that
kind
of
stayed
from
five
all
the
way
through
nine
from
foreign
existing
ipv6
spec.
T
That
was
in
six
and
that
dropped
off
after
six
supportive
deployment
of
non-vfr
routers.
So
that
was
an
important
one
and
that
was
in
five
and
then
it
remained
all
the
way
through
to
six.
I'm
sorry
to
nine
support
of
nras
multicast
deployment.
That
was
in
five
and
six,
and
there
was
some
chatter
on
list
and
then
that
ended
up
dropping
off.
As
as
a
required
mandatory
requirement,
supportive,
simple
encapsulation
was
in
five
and
six,
then
supportive
deployments
deployment
security
that
was
in
five
and
six
and
then
it
dropped
off
and
then
support
of
oam.
T
So
that
was
in
seven,
eight
nine
and
it
remained
in
the
final
moving
on
to
optionals.
We
had
support
of
mvpn,
so
that
was
in
five
and
six
and
that
drop
dropped
off
after
that
support
of
oam.
Actually,
sorry,
that's
a
that's
a
replica
support
of
iphone
esp,
so
that
was
in
five
and
six
and
then
what
happened
was
we
dropped
that
we
removed
and
then
it
went
to
esp
since
the
esp
has
been
like?
T
It
has
been
the
industry
standard
and
I
think
that
may
be
one
of
the
reasons
of
removing,
as
even
an
optional
requirement,
so
789
carried
on
the
vsp
support
of
fragmentation.
That
was
important.
That
was
five
through
nine,
so
that's
in
the
existing
and
then
the
last
one
is
supporting
hardware
fast
path,
so
that
was
in
five
and
six
and
then
it
dropped
off.
So
in
summary,
I'll
just
kind
of
go
through
like
what's
in
revision.
Nine
today
so
revision,
nine.
T
As
far
as
mandatory
requirements,
if
you
could
stay
on
that
sorry,
you
just
stay
on
the
page.
I
was
just
going
to
read
off
like
mine.
Okay,
thank
you.
Yes,
so
revision
nine!
So
we
got.
We
got
the
various
layer,
two
link
types.
We
have
supportive
beer
architecture,
we
have
supportive
deployment
with
non-bfr
routers
and
then
we
got
supportive
oam
and
then
we
have
support
of
ipsex
esp
and
the
final
one
is
supportive
fragmentation.
T
So
out
of
all
the
mandatory
and
optionals
that
we've
had
and
what
we
see
here,
does
anyone
see
any
that's,
really
blaringly
missing
or
something
that's
in
the
list?
That's
in
number
nine
in
the
draft
today
that
we
we
feel
that
should
not
be
there
that
we
can
tailor
on
the
call
today
or
and
then
we
can
take
it
on
the
on
the
mailing
list.
T
But
what
we'd
like
to
do
is
you
know
you
know
going
through
this
requirements
draft
we
want
to
hone
in
and
try
to
focus,
really
focus
and
try
to
get
this
nailed
down
exactly.
What's
there
what's
missing,
what
do
we
need
to
do
and
get
it
finalized?
So
if
everyone
can
really
take
a
good
good
look
what
we
have
so
this
is
rev
five
through
nine.
T
Does
anyone
see
anything
missing
that
we
should
add
that
was
removed
or
anything
new
that
should
be
added
and
I'll
give
it
to
the
floor?
I
guess
anyone
anyone
comments,
questions.
Anyone.
B
G
So,
since
we're
walking
down
memory
lane
here,
I
just
want
to
say
that
the
only
reason
I'm
involved
in
this
sab
is
because
it
was
brought
up
to
the
aesg
that
the
working
group
wasn't
making
fast
enough
progress
on
this
yeah
there's
been
nine
revisions,
it's
been
a
long
time.
G
G
So
when
I
read
this,
you
know
I
don't
find
you
know
to
your
question
again
of.
Is
there
anything
missing
or
should
we
add
anything
else
or
put
anything
in
you
know?
When
I
look
at
this,
I
see
very
general
requirements.
G
Support
of
the
architecture
make
sure
it
works
with
ipv6.
Well,
obviously,
right
I
mean
you
know
this
is
beer
on
ipv6
network.
So
these
seem
to
me,
like
obvious
requirements,
the
one
about
oam
I've
made
this
common
before
there
is
no
standard
oam
solution
defined.
So
I
don't
see
what
can
be
mandatory
to
be
supported.
G
If
there's
no
standard
solution
yet
if
there
is
a
future
center
solution,
you
know
that's
fine,
you
know,
but-
and
obviously
we
want
to
manage
this
thing
as
well
as
we
want
to
manage
any
other
network,
but
there's
nothing
yet
right.
So
I
don't
see
what
can
be
mandatory
here
so
going
back
to
to
the
main
things
right:
support
deployment
on
bfr,
that's
part
of
the
architecture
anyways.
G
So
it
seems
to
me
that
that
this
boils
down
to
support
of
your
architecture
and
run
over
an
ipv6,
rfc
8200
network,
and
if
the
objective,
which
is
what
I
want
to,
which
is
to
move
on
to
solutions-
and
we
want
these
requirements
to
either
help
us
decide
which
solutions
to
move
on
with,
then
we
only
have
we
need
to
run
your
ipv6
and
to
me
that
seems
very,
very
wide,
which
means
that
pretty
much
anything
that
supports
the
architecture
and
the
reservoir
ip6
could
be
a
solution
right.
G
A
Right,
this
goes
back
to
the
original
presentation
in
the
first
draft
and
we
asked
what
problem
they're
trying
to
solve
what
specifically
can't
be
done
with
just
generic
encapsulation,
or
you
know,
encapsulating
in
v6
and
sending
over
the
top.
Well,
just
this,
we
just
chased
our
tail
on
this
karma,
strap
and
moved
around.
T
Right,
you
know,
you
just
told
me
a
good
point
that
you
bring
up,
but
you
know,
I
think,
the
big
really
I
mean
it's
kind
of
you
know
it
stares
you
right
in
the
face.
You
know
the
elephant
in
the
room
and
that
is
that
beer
was
there
for
v4
before
the
mpls.
Not
I
guess
the
not
the.
What
am
I
gonna?
What
I'm
trying
to
say
is
the
I
guess.
T
Yes,
there's
the
the
non-mpls
or
mpls,
I
guess
the
original
beer
and
then
this
is
really
the
non
non
mpls,
which
is
the
ipv6
forwarding
plane
so
that
that's
really
the
the
main
really
topic
of.
T
We
know
what
we
have
today,
which
is
beer
with
mpls
or
beer
ethernet,
and
so
this
is
kind
of
outside
of
that
so
non-non-brmpls
going,
which,
which
implies
you
know
your
ipv6
and
that's
and
that's
really
the
framework
that
we're
looking
at
beer
over
ipv6
and
how
can
we
do
beer
over
ipv6
sporting
plane
and
then
and
that's
really
the
main
construct
of
it?
And
then
you
have
no
beer.
A
Over
the
v6
boarding
plane,
that's
not
the
requirement.
It's
beer
over
a
v6
network
that
doesn't
support
beer,
that's
where
the
first
draft
came
up
and
what
we
made
clear
from
the
beginning
is
you're
not
going
to
move
forward
with
a
standard.
That's
transitional
right!
If
the
idea
is,
I
need
to
do
all
these
fast
things
in
this.
You
know
in
the
forwarding
plane,
so
I
get
over
this
box
that
someday
I'm
going
not
to
need
that
doesn't
make
a
lot
of
you
know
heavy
lifting
sense.
So
that's
what
we
kept
saying.
A
What
are
you
trying
to
solve?
What's
specifically
trying
to
solve
so
you're
quite
telling
when
you
called
the
previous
solutions
of
e4,
because
they're
not
here
rides
on
top
of
any
igp
and
what
it
need
to
do
was
get
from
hop
to
hop.
How
do
we
do
that
either
type
encapsulations,
a
long
haul?
It
takes
a
while
to
an
attraction
to
get
there,
but
right
in
a
core
network
was
easy,
just
a
label
in
cap
and
we
get
got
it
over
the
top.
A
No
beer
information
is
in
the
mpls
except
the
type
or
the
the
set,
and
we
replicated
that
with
either
type
so
that
the
header
doesn't
change
and
anybody
else
can
encapsulate
the
beer
packet
involves
the
header
and
the
data
and
get
it
across
that
infrastructure.
A
Once
the
forwarding
planes
established
that's
the
forting
plane,
and
then
we
do
things
to
make
it
better,
and
we
do
things
underneath
it
that
it
inherits
to
do
better,
but
we
don't
spread
it
around
and
make
the
standard
muddy
right.
So
we
wanted
to
be
clear
what
we're
trying
to
solve
before
we
move
forward
with
the
solution
that
makes
that
that's
my
memory
of
our
processor.
T
Under
understood
so
so
greg
just
said,
so
I'm
clear,
so
I
think
really
the
goal
is
I
mean
from
the
from
the
requirements
and
the
draft-
and
I
think
I
know,
we've
gone,
probably
gone
through
like
different
circle,
but
really
just
making
sure
that
we're
really
locked
up
and
barrel.
You
know
with
it.
It's
really.
T
You
know
that
we,
how
really
the
encapsulation
and
encoding
of
how
we
wanted
to
really
how
and
and
being
able
to
do
that,
just
supporting
you
know
and
the
reasons
why
we
want
to
do
it
and
it's
not
necessarily
that
you
can
do
it
on
an
ipv6
boarding
plane.
It's
it's
more
so
like
wow.
Why
do
you
need
that
and
what's
the
gap
that's
being
filled,
I
guess
without
it,
but
again.
A
Putting
doing
beer
processing
from
a
signal
that
comes
from
the
v6
header
is
not
doing
beer
in
the
b640
plane.
We
have
to
be
very
clear
about
that.
A
lot
of
this
has
been
misdescribed
to
move
agendas
along
and
that's
the
frustrating
part
there's
no
integrated
solution
here.
Once
you
get
to
the
beer
domain,
you're
doing
beer
right
so
the
same.
We
don't
when
we
encapsulate
any
other
protocol,
we
don't
steal
pieces
from
it
and
make
a
dependency
on
another
layer.
It
just
doesn't
make
sense
unless
we
can
justify
what
we're
trying
to
solve.
U
So
my
question
is
when
I,
when
I
started
out
in
the
industry
like
40
years
ago,
45
one
of
the
first
things
I
did
was
actually
write
requirements
and
people
told
me
that
they
need
to
be
measurable.
They
need
to
be
verifiable,
and
if
I
look
at
the
l2
l2
link
types
requirement
here,
it
says
it
should
support
the
various
kinds
of
so
I
ask
how
many
is
various
is
two
enough:
five
does
any
old
l2
technology
count
like
in
hdlc
or
lappy
or
whatever?
U
U
T
T
A
So
we
are
tight
on
time
and
I
want
to
make
sure
we
get
all
the
way
through
the
jeffries
at
the
end
here
as
well,
but
I
think
what
we're
getting
here
is
what
we
have
is
mud
right.
These
things
just
keep
getting
moved
around
and
what
we
don't
have
still
is
a
problem
statement.
What
are
we
trying
to
solve?
Specifically,
then
we
can
understand
what
tools
are
missing
and
we
can
engineer
them
understood
all
right
language.
O
Susan
from
huawei
on
the
mic
response
in
the
comments
of
the
chairs.
Thank
you
for
your
comments
and
my
my
understanding
is
just
that.
It
is
not
so
easy
to
put
beer
under
ipv6
header.
You
know,
ideally,
if
beer
want
to
transport,
maybe
over
ips
over
ethernet
or
ipv6,
we
just
put
it
under
the
header,
but
it
doesn't
work
because
ipv6
in
the
ipv6
header
there
is
next
header
sure
we
can
define
a
new
next
header
type
for
beer.
O
But
if
we
see
the
tcp
ip
structure
we
can
see,
there
is
no
places
of
for
beer.
I
remember
when
beer
insects
document
is
presented
in
sick
men
last
time
the
ad
told
the
others
that
the
they
should
get
involved
transport
layer,
people
into
the
discussion,
because
if
we
just
make
beer
as
the
next
header
of
the
ipv6
header,
it
means
that
beer
belongs
to
transport
layer.
I
think
that
is
not
we
want.
So
the
the
thing
is
not
so
straightforward
as
we
think.
Ideally,
beer
is
everything
and
we
can
order
everything.
O
A
O
L
O
A
O
Actually
that
depends
how
we
understand
the
problem
if
we
want
to
use
some
multicast
solutions,
just
like
beer
in
fpv6
solution,
so
we
need
beer.
That
is
what
we
want
in
ipv6.
Yes,
we
have
unicast.
I
can
use
ipv6
header
directly,
but
if
I
want
to
multicast
the
replication
ipv6
header,
I
need
some
extension
headers
to
know
how
I
do
replication.
O
No
it
it
just
means
that
if
I
want
to
do
replication
and
multicultural
behavior
in
ipv6
network
network,
okay
in
an
ipv6
network,.
O
A
A
Sorry,
I
I
can't
I'm
not
going
to
swallow
that,
because,
if
you're
trying
to
replicate
based
on
a
bit
string
the
functionalities
in
the
box,
it's
in
the
router,
you
can't
say
it's
just
v6.
If
you're
doing
replication,
because
v6
doesn't
replicate
it's
a
unicast,
only
solution
putting
the
bits
in
the
header
make
it
a
b6
solution.
All
it
does
is
v6
defined.
What
the
beer
process
now
has
to
do.
O
O
A
O
A
A
O
I
think
that
is
the
main
point
of
why
we
need
a
requirement
document,
so
I
think
the
the
the
argument
is
really
important
here.
I
think
we
should
continue
and
I
want
to
continue.
My
point
is
that
fear
is
not
naturally
the
next
header
of
if
basic
header,
as
I
have
mentioned,
the
next
header
of
fpv6
header
is
transport
layer,
it's
tcp,
header
and
udp
header.
We
cannot
put
beer
header
everywhere
as
we
want.
O
O
L
O
A
R
A
C
Okay,
so
next
one
on
the
mic,
please
name
affiliation.
V
Okay:
okay,
this
one
correct
in
fact
in
the
srv6
and
also
they
use
the
routine
header
in
the
ipv6-
is
an
exchange
header,
there's
also
the
replication
fragment.
You
know
that
this
is
adopted
in
the
spring
working
group.
They
also
use
this
the
replication
segment
to
indicate
the
market
cost
so.
V
V
But
you
know
the
challenge,
because
the
current
current
of
the
existing
device-
they
always
assume
that
the
up
layer
of
this,
the
ip
ipv6
is
the
udp
or
tcp.
So
if
we
directly
encapsulate
the
encapsulated
the
beer
in
the
ipv6,
so
I
think
they
may
have
some
these
the
possible
risks.
So
this
is
just
mentioned.
You
mentioned
this
one,
so
I
think
maybe
it
can
be
discussed
in
the
transport
layer
to
avoid
the
possible
risk
and
to
lend
the
opinions
from
the
transport
layers.
Opinions.
R
A
We
need
feedback
from
the
v6
experts
to
see
if
this
is
actually
the
case,
I
mean
because
ip
and
ip
works
fine
and
we
have
another
draft
that
shows
how
to
encapsulate
a
beer
packet
in
a
v6
header.
So
I
don't
think
this
is
a
non-starter
as
is
being
defined.
A
So
next
is,
can
you
be
really
fast?
We've
seen
this
one
a
lot.
I
think,
if
something
new,
you
can
go
to
that's
great,
but
we
don't
have
time
for
you
to
go
to
the
entire,
how
it
works.
Presentation.
S
Yeah
well,
super
quick.
I
I
think
it's
super
quick
is
that
the
next
two
presentations,
as
you
just
said,
greg
are
solutions,
so
I
don't
even
know
if
we
even
need
to
have
them
at
this
point.
If
we're
not
going
to
agree
that
the
requirements
are
set,
I
mean
we've
we've
heard
from
multiple
solutions,
many
many
times,
and
it's
I
I
just
don't
know
the
benefit.
S
The
point
we're
at
is
that
we've
got
several
people,
several
authors,
who
are
anxious
to
start
working
on
solutions
in
the
bare
working
group
and
if
we're
after
two
years,
not
able
to
get
to
the
point
where
the
chairs
particularly
are
satisfied
with
that,
then
maybe
we
need
to
have
you
guys
join
us,
so
we
need
help
because
we've
added
we've
added
people
to
the
requirements
draft
we
added
jeffrey
we've
added
gion.
A
To
get
going
and
unfortunately,
how
that
began
was
it
was
great.
You
wrote
the
draft,
you
presented
it
and
no
one
had
interest
and
we
pushed
and
we
kicked
and
that's
why
this
time
went
on
for
a
long
time
and
unfortunately
the
feedback
I
I
gave.
Then
I
mean
it
was
as
broad
as
it
was
like.
If
no
one's
responding,
then
there's
not
enough
interest
to
move
things
along
right.
You
can't.
J
A
A
J
A
Going
into
in
these
drafts
and
presenting
stuff
right
now,
but
let's
let's
get
some
update
first
before
we
do,
we
have
two
drafts
to
discuss.
I
don't
want
to
go
into
detail
about
them
unless
there's
new,
so
is
there
anything
new
to
present
in
this
draft
dijon.
O
O
O
We
split
the
document
to
two
parts
and
one
of
them
is
requirement
document
and
in
version
six
we
have
some
update
and
we
fix
all
the
concerns
about
the
security
about
about
some
other
comments
in
the
main
list,
and
then
we
go
to
version
six,
and
we
have
a
lot
of
comments
in
the
middle
is
to
address
it
and
and
the
what
group
told
tell
us
to
send
it
to
six
men.
O
Okay
for
verse,
seven,
we
do
a
lot
of
actual
updates
to
the
document
and
we
do
send
it
to
six
men
and
six
man.
People
think:
okay,
we
are
fine
and
then
we
also
have
received
some
comments
from
six
men,
four
versions.
O
Okay,
so
because
the
details,
because
the
details
will,
I
think
they
will
bring
some
discussions,
I
can
go
to
details
what
we
have
done.
For
example,
we
we
updated
the
terminology
like
vr
basics
domain.
We
just
redefined
the
use
of
how
we
use
the
protocol
field
in
beer,
header
and
the
next
header
in
ipv6
header
and
some
more
considerations
about
security,
and
we
clarify
the
id
needs
and
the
co-orders
more
co-authors
are
ended
so,
and
we
sent
this
version
to
six
men
and
psychology
psychologized
to
beer
as
well.
O
Okay,
next
version-
and
we
do
receive
some
comments
from
six-month
people
to
make
it
more
clear.
We
have
a
diagram
showing
basics,
perhaps
packet
processing
in
a
yeah
fpv
system,
how
it
works
and
the
wii
clarification
of
vrv6
how
it
aligns
with
beer
architecture
in
appendix
a
and
reference
for
the
control
plane.
Extensions
headers,
which
are
necessary
for
this
solution,
are
noted
in
appendix
b
and
also
text
for
the
use
of
unicast
address
in
section
3.2
is
moved
to
appendix
c.
O
That
is
what
we
have
done,
based
on
the
comments
from
six
men
and
also
we
put
it
to
the
main
list
of
fear
and
we
receive
some
positive
feedback,
actually
quite
some
feedback.
I
I'm
not
agree
that
people
don't
interested
in
it.
We
have
people
interested
in
this
topic
and
they
want
to
deploy
it
even
in
the
existing
network,
and
the
working
group
suggestion
is
that
we
should
focus
on
requirement
document
first.
So
we
put
a
lot
of
efforts
on
requirement
document
and
we
cooperate
with
other
others
from
other
solutions.
O
O
Yes,
some
brief
summary.
This
document
has
proposed
in
bureau
group
for
more
than
two
years,
and
we
have
ten
review
eight
revisions
to
fix
all
the
comments
that
already
raised
by
the
working
group,
and
we
have
more
than
100
emails
of
peer
mentis
and
six
more
millions
to
talk
about
whether
this
work,
this
mechanism
works,
it
works
and
we
have
five
operators
support
as
co-orders.
That's
this
and
they
think
this
is
promising.
We
have
five
drafts
more
drafts
referred
to
this
document
and
which
is
not
ended
in
this
slide.
O
O
N
N
L
Okay,
so
these
are
the
opinions
from
from
sandy
from
zte
me
from
juniper
and
iceland,
cisco
previously
cisco
and
the
woman
from
endogenous
our
thoughts
about
supporting
beer
in
now
npr's
ipv6
networks.
Next
slide,
please
I'm
trying
to
find
where
to
go
there.
It
is
all
right.
L
L
If,
if
you
are
using
ipv4
or
v6
tunnel,
then
you
do
need
a
new
next
header
value
defined
for
beer
now,
so
if
ipv4
ipv6,
tunneling
or
encapsulation
is
used,
then
it's
just
a
transfer
means
to
beer
and
just
like
any
other
means,
for
example,
mpos
or
gre
or
whatever
tunnel,
and
this
is
between
the
bfrs
that
are
not
directly
connected
and
beer
header
is
the
beginning
part
of
the
ip
payload
all
right
so
before
between
the
indirectly
connected
bfrs.
L
L
Right:
it's
it's
really,
not
not
the
changes
in
the
draft.
It's
really
about
how
we
view
the
how
beer
can
be
done
in
ibv6
network.
So
this
draft
beer
in
six
drafts
does
reflect
the
concepts
we
just
talked
about.
So
it
does
have
one
optional
feature
that
I'm
going
to
skip
it
for
now.
You
can
think
that
you
can
pretend
that
option
feature
does
not
exist.
L
So
the
main
purpose
of
these
graphs
is
to
specify
this
optional
feature
or
you
can
just
ignore
it
and
then
explain
how
existing
beer
procedure
can
work
for
ipv6
networks
next
slide,
please.
Now
this
alternative
solution,
beer,
v6
now
encodes
the
beer
header
in
the
ipa,
that's
v6
destination,
option
header!
L
It
uses
srv6
style
handling
with
special
mvp
and
evp
procedures,
and
so
we
all
know
that
working
group
requests
will
have
a
requirements
draft
first
to
justify
this
additional
solution,
because,
yes,
we
can
allow
multiple
solutions,
but
if
you
don't
have
significant
advantages,
why
bother
with
an
additional
solution?
Next
slide?
Please.
L
L
L
Now
so,
in
our
view,
beer
v6
solution,
yes,
the
solution
will
work,
but
it's
just
not
needed
because
beer
in
six
solution,
which
is
consistent
with
existing
solution,
satisfies
all
the
requirements
and
it
does
not
have
ipv6
overhead
with
beer
with
this
solution.
L
L
So,
basically
you
we
don't
need
this
additional
solution
because
I
don't
see
it
offers
obvious
benefits
or
advantages
there
and
it
does
introduce
complexities.
We're
going.
W
Understand
we
just
our
suggestion
next
steps
yeah,
so
this
I'd
like
to
make
a
generic
comment
to
the
process
as.
A
A
whole
we
make
arguments
and
decisions
on
technical
merit,
not
how
many
times
things
have
been
done,
how
many
emails
were
sent
or
how
many
discussions
were
had
taken
place.
The
idea
is,
we
come
out
with
a
solution
that
sets
a
standard
that
the
industry
can
then
progress
from
in
a
way
that
is
allows
us
to
continue
doing
these
things.
It
doesn't
lead
us
into
dead
ends,
and
one
thing
we've
learned
is
layering
and
independence
is
really
important
for
scale
and
just
functionality
and
clarity.
A
We
have
beer
combined.
So
the
question
is:
what
does
that
architecture
mean
and
everyone's
because
he
pointed
to
the
architecture,
but
no
one
really
defined
what
architecture
is
right.
So,
despite
all
that,
I
think
jeffrey
made
a
solid
point
here
is
we
need
to
understand
the
value
the
only
pushback
I've
heard.
Is
it
can't
be
done
and
that
doesn't
make
sense
to
me.
I
see
how
it
can
be
done.
So
if
there
is
something
specific
that
can't
be
done,
that
can
only
be
accomplished
by
blurring
the
lines
completely
between
beer
and
v6.
A
Then
it
needs
to
very
well
be
defined
so
that
we
can
understand
and
make
a
decision
based
on
it,
not
on
how
many
emails
were
sent
not
on
how
many
presentations
were
given
or
not.
How
many
different
authors
have
come
to
the
game.
These
are
technical
decisions
made
by
engineers
who
have
a
stake
in
this
game.
We
want
to
make
sure
we
don't.
I
mean
this
is
new.
This
is
brand
new
right.
A
Multicast
multi-point
transport
has
been
the
bastard
stepchild
the
internet
for
decades,
and
with
that,
we've
always
had
to
have
dependencies
that
have
crippled
us
every
step
of
the
way
tim
protocol
independence
was
a
breakthrough.
We
no
longer
depended
on
having
you
know,
rip
basically
integrated
with
tunneling
and
forwarding
all
in
dvmrp.
C
C
Yeah
we
have
two
people
on
the
mic.
You
want
to
take
this
we'll
be
talking
two
minutes
right:
okay,.
O
I
think
there
are
some
very
difficult
defeats
in
the
united
states
pollution
because
it
cannot
exist
independently
and
it
can.
It
cannot
satisfy
what
is
defined
in
the
mandatory
requirements
in
the
republic
document,
because
in
the
case
of
pfr
connected
directly,
if
there
is
no
other
mechanism,
you
cannot
hear
forwarding
and
the
next
I
have
indicated
before
the
experience
is
requesting
your
next
header.
It
should
be
put
into
the
transport
area,
and
that
is
also
recommended
by
the
sigma
working
group
and
the
adf
in
area.
R
And
then
so
in
fact,
I
think
that.
V
So
I
think
that
if
I
think
that,
maybe
if
we
wanted
to
replace
the
coming
to
determine
the
resolution
is
very
difficult,
so
I
think
maybe
we
needed
to
justify
the
different
requirements
scenario.
Maybe
the
two
solutions
can
clearly
release.
That's
my
first
point.
The
second
point
I
think,
for
the
peer
insights.
I
I
mentioned
that's
why?
V
You
know
the
iom
has
been
encapsulated
in
the
ipv6
option,
but
I
don't
know
if
we
wanted
to
do
the
pr
insights,
the
lm
we
encapsulated
the
iom,
header
in
the
peer
layer
or
in
the
ipv6
layer.
So
I
think
this
will
I
miss
this.
Maybe
the
issue,
but
maybe
not
in
the
scope
of
the
sr,
the
pre-6,
because
just
like
the
sro
udp,
does
not
cope
with
the
network
slicing
and
the
iom
issues
now
like
this
way.
So
that's
because
of
my
comments
on
this
compilation.
A
T
Hey
yes,
so
I
just
want
to
just
wrap
up
on
the
feedback
on
the
requirements
graph.
So
so
what
I
what
I
heard,
I
think-
and
I
think
right
just
correct
me,
but
I
think
what
we
need
to
do
is
really
circle
back
on
really
the
reason
why
we
want
to
do
you
know
we
have
a
solution
today
that
worked,
you
know
with
mpls
and
it
worked
great
or
ethernet.
T
T
A
Q
A
A
I
know
this
is
going
into
a
long
gap
between
our
next
meeting
and
a
lot
of
holidays
between
them,
but
we
have
to
get
some
stuff
moving
along
we're
getting
a
lot
of
stuff
in
our
queue
that
we
can
go
right
now
and
we'll
push
that
and
then
we
gotta
dig
us
some
shepherds
to
get
the
wrist
stuff
going
and
then
we'll
circle
back.
Definitely
on
this
guyana
reach
out
to.
Let
me
really
work
on
this.
A
I
can
help
you
out,
because
this
we
need
to
turn
this
into
a
document
that
we
can
use
all
right.
Thank
you.
Greg
really
appreciate
it.
Thank
you.
Thank
you
guys.
Anyone
else
questions
comments
all
right
meet
you
guys
in
the
bar
afterwards.