►
From YouTube: IETF99-BIER-20170720-1810
Description
BIER meeting session at IETF99
2017/07/20 1810
https://datatracker.ietf.org/meeting/99/proceedings/
A
B
A
C
A
A
Before
we
start
can
have
someone
volunteer
to
take
minutes
before
I
assign
someone
to
take
minutes
and
I've
done
it
yeah,
it's
all
those
hands
going
up.
I'm
least
the
making
eye
contact
usually
you're,
going
down
your
keyboard.
Pretend,
like
you
don't
hear
me.
It
did
get
quiet,
though
that
was
good.
D
A
Anyone
come
on
go
on
Jeff,
you'd
love
to
do
it.
You
K,
really
wow.
You
got
cover
no
you're
presenting
you're
presenting
twice.
That's
not
right.
Volunteers
come
on
someone,
hey
Pierre,.
A
F
A
E
A
A
G
H
I
Perfect
human
beat
goli
Nokia
I'm
here
to
talk
about
first
of
all,
I'm
a
first
time.
Well,
I've
been
here
a
couple
of
times,
but
I'm
new
here.
Take
it
easy
on
me:
no
initiation
procedures,
please
so
I'm
here
to
talk
about
draft
the
beer
tunneling.
We
change
the
name
of
the
slides
to
pin
stitching
because
it
was
creating
some
confusion.
Some
great
comments
came
up.
Thank
you
very
much
if
we
can
go
to
the
next
slide.
So
let's
talk
about
the
problem.
What
we
are
trying
to
solve
here.
The
problem
is
threefold:
number
one.
I
We
are
seeing
some
providers
that
they're
trying
to
go
to
the
next
generation
core.
This
next
generation
is
a
converge.
Core
is
a
lean
core
and
what
I
mean
by
a
converge
core
is
that
previously
for
from
core
point
of
view,
there
was
a
fixed
core
for
business
services,
verticals
and
fixed
type
of
services,
and
then
there
was
a
wireless
core
now,
as
you
guys
have
been
hearing
about
5
g
5
g
5g,
this
wireless
course
there
is
a
need
for
data
centers,
there's
a
need
for
cloud
services.
I
Caching
points
so
from
some
of
these
provider
it
makes
complete
sense
to
converge
their
core
to
converge,
their
services
to
actually
start
saving
money
and
operational
status.
I
guess
so.
They
want
this
court
to
be
clean,
meaning
that
they
don't
want
to
have
any
multicast
assets.
They
don't
want
to
have
any
bgp
protocol
single
protocol
that
does
unicast
and
multicast.
Now
that
takes
us
to
the
second
problem.
The
problem
becomes
as
soon
as
you
converge
the
core
and
you
put
a
mobile
backhaul
over
a
core.
The
access
network
becomes
very
large.
I
Let
me
give
you
an
example:
some
of
these
providers
wireless
providers
they
have
in
Access
of
tens
of
thousand
radio
unit
radio
towers
each
radio
tower
in
the
LTE
network
has
a
router
sell-side
router
each
one
of
those
sell-side
router
is
gonna,
be
a
multicast
leaf,
so
multicast
had
to
branch
out
to
tens,
even
maybe
more
10,000
or
more
of
leafs.
So
scalability
is
the
next
issue.
Last
but
not
least
is
when
you
start
converging
the
core.
I
I
We
need
to
have
some
kind
of
marriage
between
the
legacy
multicast
services,
whether
it's
in
the
GRT,
whether
it's
in
MVP
n
to
a
core
of
beer-
and
this
is
a
lean
clean
core
as
I
keep
saying
over
and
over
again,
meaning
that
they
want
a
single
protocol
for
MPLS
and
for
unicast
and
multicast
and
go
to
the
next
slide.
So
in
the
next
one
please.
I
So
this
is
what
we
suggest
from
a
solution
point
of
view.
So
what
we
are
doing
from
solution
point
of
view
is
there's
going
to
be
two
pieces
to
it.
There
is
going
to
be
signaling
and
there's
gonna
be
data
that
actually
this
is
not
my
latest
slide,
but
from
data
path,
point
of
view.
There
is
no
changes
whatsoever.
Multicast
packets
comes
to
the
bier
core
vehicle
forwards
it
to
the
other
beer
edge
router
when
it
comes
from
signaling.
That's
where
we're
introducing
the
changes
from
signaling
point
of
view
in
the
beer
core.
I
It
needs
to
be
very
simple
signaling,
so
this
will
create
a
ping
domain
and
a
beer
domain,
the
edge
router
that
connects
the
beer
to
the
pin
on
one
end.
It's
doing
PIM
neighboring
PIM
dr
joins
is
complete
PIM
negotiation,
but
when
it
goes
toward
the
core,
it
needs
to
grab
that
SG
and
somehow
similar
to
the
other
beer
edge.
Router,
that's
signaling.
We
could
have
done
via
a
sub
TLV.
We
are
not
trying
to
create
a
pimp
adjacency
through
a
beer
core,
there's
going
to
be
too
complex
for
this
core
providers.
I
They
just
one
simple
SG,
join
and
prune
through
their
core.
So
basically
we
will
terminate
the
PIM
adjacency
when
it
goes
through
the
beer.
If
it
figures
out
that
the
source
is
sitting
on
the
other
side
of
the
beer
domain,
we
will
terminate
the
beer.
We
need
to
signal
the
SG
somehow
and
as
it
happened
right
now,
we
use
a
pin
joint
or
a
pin
prune
to
signal
sg2,
the
other
core.
So
that's
the
signalling
point,
and
that
brings
up
a
couple
of
terms
here-
that
we
are
willing
to
change.
I
If
it's
confusing
that
brings
up
the
pin,
be
fer
and
the
pin
be
fi
are
basically
what
these
are
is.
These
are
the
edge
routers
that
terminate
the
pin
toward
the
beer
core
next
slide,
please
so
here's
an
example
in
this
example.
As
you
can
see,
one
thing
before
I
go
through
the
example.
This
solution
will
work
for
multicast
data,
it's
not
really
MVP
in
solution
or
it's
not
really
a
GRT
solution
it
just
in
multicast
in
general.
I
It
just
so
happens
that
some
of
the
MVP
and
multicast,
as
you
guys
know
better
and
I-
do
like
graph
Rosen
use,
pin
for
signaling
of
the
provider
tunnel
from
one
end
to
the
other
end.
So
here's
example.
So
in
this
example,
the
PE
is
on
the
edge
were:
let's
say
that
the
cells
sell
side.
Routers
are
sitting,
they
are
trying
to
provide
their
pin
joint.
They
go
to
the
pin
edge
routers
the
pin
signaling
will
become
terminate.
I
You
try
to
get
that
SG
somehow
through
the
core
beer
to
the
other,
a
beer
edge
router
and
the
other
beer
beer
edge.
Router
we'd,
remove
the
beer
header
from
the
ping
packet
and
we'll
create
a
new
pin
joint,
whether
it's
the
same
packet
or
not
doesn't
matter,
and
it
will
send
it
all
the
way
to
the
source.
I
One
thing
that
the
pin
edge
router,
the
one
that
is
egress
pim
edge
router
needs
to
do-
is
it
needs
to
track
which
one
of
the
pin
PF
IRS,
is
sending
the
group
and
it
needs
to
keep
track
of
the
idea
of
that
beer
router.
In
that
case,
when
it
comes
to
the
data
path,
you
have
a
mapping
of
reach
between
bf
IR
is
actually
interested
into
that
group
and
you
can
multicast
through
a
pin
Gore
next
slide.
Please
one
more,
please
so!
Here's
an
example
of
the
data
path.
I
As
you
can
see,
we
we
have
a
table
at
the
bottom
that
says:
lookup
g3b
fer.
That's
it
that's
our
kind
of
implementation,
so
we
are
keeping
track
of
all
the
groups
and
which
one
of
the
team
B
I
are
that
are
interested
in
that
group.
So
when
the
source
gets
the
join,
it
is
start
sending
the
multicast
PDUs
to
the
peer
edge
routers,
the
beer
edge
routers,
they
have
their
tracking,
which
group
is
interested
with
which
PFI
are
router
and
they
put
beer
header
this
in
the
packet
toward
the
piaac
or
the
other
edge.
I
A
A
So
the
map
in
there
of
the
SG
in
upper
right-hand
corner,
says
p
e1
for
group
1.
Really
it's
p1
for
group
one's
the
destination
right,
that's
the
bit
that
gets
set
on
key
1.
Yes,
ok,
ok,
that's
correct!
Alright!
So
that
means
between
the
PE
s
and
the
peer
outers.
We're
going
just
IP
multicast
UDP
joins
alright
got
it.
Yes,
thank.
J
You
Oh
Tala
Secord
sure
what
what's
what's
the
unicast
routing
between
the
left
and
the
right
exits?
It
could
be
anything.
A
K
J
So
I'm
totally
not
understanding.
What's
missing
right,
if
I'm
using
draft
rosin
right
or
you
know,
with
the
same
signaling
in
BGP
I've
got
my
you
know:
PIM
overlay
or
BGP
overlay,
p2p
signaling,
where
the
upstream
knows
every
downstream
receiver
right,
okay,
so
an
early
draft
rosin
you
couldn't
do
explicit
tracking,
but
you
just
need
to
do
a
explicit
tracking
eval.
Are
you
have
the
information
on
the
ingress
so
on
DB,
f
ir?
So
what's
missing,
yeah
right?
No,
but
I
mean
that's
what
the
overlay
signal
already
does
right.
In
MVP
n.
A
L
J
No
I
mean
I,
don't
need
MVP
and
I'm.
Just
saying
that
if
I
have
the
overlay
signaling
from
the
egress
into
each
with
the
ingress
PE
right,
I
have
on
the
ingress
PE
the
list
of
egress
piece
that
want
to
have
an
Eskimo
G,
and
that
means
I
can
build
my
beer
tree
so
I'm
trying
to
understand
what
Ramirez
neptr
is.
What
do
you
mean?
Okay,
sorry,
whatever
the
right
term
is
right,
the
beer
bit
string
right
all
the
masks.
The
interests
mask.
I
C
A
J
L
K
Think
of
it
that
way,
what
what
you
are,
what
you
actually
think
is
you're
removing
the
stay
and
yet
and
you're
removing
any
different
applications
just
because
the
size
of
the
domain
is
so
huge.
So
even
if
you're
running
it
on
my
PE
levels
and
we
would
run
a
beer
from
PE
ones
at
the
tens
of
thousands
of
scale.
Ok,
we
all
have
the
hardware
limitations.
None
of
us
will
get
to
tens
of
thousands.
So
by
pushing
it
one
level
into
the
car
we
we
can.
We
can
scale
better
without
the
need.
K
M
D
I
I
J
Think
then
the
the
only
question
was
always
you
know,
is
the
edge
state
that
you
have
on
these
egress
P
notes
is
that
you
know
more,
you
know
functionality,
then
you
would
like
to
have
on
a
P
note
right,
so
I
think
you're
trying
to
make
the
argument
that
the
overall
complexity
of
having
you
know
PIM
on
an
egress
side
and
B
fer
that
that's
very
lightweight
so
I
think
that's
what
exactly
the
the
major
we
review
point
is
what
operators
think
about
that
right.
The.
J
G
Stay
with
us,
so
if
you
forget
about
MEP
ends,
writers
know
des
really,
but
you
have
certain
routers,
of
course,
at
the
are
at
the
edge.
We
are
beer
domain
and
in
that
draft,
to
say
that
you
know
you
say
that
how
to
basically
figure
out
where
to
send
the
join,
what
the
e
PB
ers
is
kind
of
an
otoscope
and
it
seems
mean
I,
have
some
idea
how
we
could
do
it,
but
it
seems
that
is
the
most
tricky
part
of
this.
Perhaps
you're.
I
Absolutely
right
I
mean
there
are
multiple
ways
of
skinning
that
cat,
depending
on
how
the
operator
wants
to
go.
If
the
operator
isn't
I'm
just
giving
an
example.
If
the
operator
wants
to
make
that
p1
and
p3
to
be
a
ABR
router,
which
summarizes
the
route,
you
know,
then
the
ABR
router
it
starts
the
route
with
its
own
loopback
IP
address.
So
that's
one
way
of
thinking
but
I.
Definitely
we
are
open
to
two
ideas.
G
G
K
D
G
H
N
A
M
M
A
P
R
R
Let's
see
the
brief
brief
introduction
of
a
protocol
like
PDP
pebble
is
a
distance
vector
routing
protocol
and
it
can
be
used
in
world
and
the
various
networks
and
the
ending.
The
latest
version
of
the
protocol
of
fc6
1
to
6
P.
It's
draft
sub
T
of
V
has,
inter
as
the
be
defined
to
carry
extension
impure
protocol
Olimpico
protocol.
So
your
information
can
also
be
conveyed
by
this
way.
Next,
it's
a
similar
way
to
do
this.
R
The
pure
information
can
be
carried
in
verbal
update
message
and
we
use
a
news
sub
jovi
to
define
this
and
because
there
is
a
manager
repeating
pebble
protocol.
So
we,
the
beer,
the
monitor,
repeat
of
appears
up
to
be
issued,
be
said
to
0f
other
cannot
recognize
the
sub
T
of
V
doesn't
work
can
ignore,
is
actually
and
we
can
use
pebble
protocol
which
has
further
PR
information,
so
every
node
in
the
network
can
receives
in
the
Biafra
d
and
the
VFR
prefix
and
other
information
I'm.
A
M
D
S
R
A
R
A
R
T
H
U
Okay,
Julia
scrubbers,
like
I'm,
described
in
the
Bible
working
group,
and
so
just
together,
quick.
We
are
looking
at
that
with
a
lot
of
interest.
However,
right
now
in
Babel
we
are
focusing
on
the
core
specifications
and
trying
to
avoid
spending
too
much
time
of
extensions
until
the
cross
specifications
are
done.
So
we
are
not
adopting
that
yet
okay
and
it
doesn't
mean
we'll
adopted
that
we're
looking
at.
It
was
a
lot
of
an
interest
and
we're
excited
about
that.
Yuria.
A
What
you
represent
before
is
we've
done
the
IGP
work
in
here,
because
those
iGPS
are
fully
cooked
right
for
the
most
part
and
we're
just
doing
extensions
to
them,
and
then,
when
we
go
to
last
call
which
we've
just
done,
we
get
feedback
from
those
appropriate
associated
work
groups
as
well.
I
think
in
talking
to
alia,
if
I
just
provide
your
words
in
this
conversation,
that's
okay,
Babel
is
still
like.
You
said
you
guys
are
busy
you're
doing
a
lot
of
other
work,
so
it's
I
think
it
would
be
I.
A
Think
the
beer
stuff
is
fairly
well
cooked,
what's
not
cooked
as
the
Babel
side
of
it.
It's
not
as
understood
as
like
is
I
as
our
OSPF
is
being
cooked,
so
the
suggestion
was,
it
may
want
to
live
there.
Instead,
while
you
guys
bake
the
rest
of
the
solution
and
then
we
stay
on
top
of
it,
for
you
know,
make
sure
that
the
right
beer
informations
in
the
signal
tell.
J
A
Think
that's
actually
a
direct
question
and
it
could
I
can
jump
on
a
soapbox
and
go
on
for
hours
because
we're
we
used
to
have
a
multicast
kind
of
steering
working
group
and
that's
gone
and
buddies
kind
of
pick
that
up.
But
the
mechanism
within
the
IETF
tends
to
be
the
published
us
to
be
able
to
come
as
opposed
to
G,
multicast
us
and
there's
an
idea,
let's
bolt
it
on
later
and
then
not
talking
to
the
people
who
do
it.
So
I
think
this
is
happening
already
here
to
Arles.
A
A
T
But
it's
not
a
trivial
jump
in
everyone
knows
how
to
do
this,
so
I
want
to
make
sure
that
the
babel
expertise
actually
gets
to
look
at
it
and
be
very
comfortable
with
it
on
the
home
that
piece.
If
you
look
at
the
home
met
architecture,
all
that
it
says
about
multicast
is
pim
and
I
am
not
aware
of
any
other
discussion,
but
I
think
personally,
this
has
some
interesting
promise.
F
Tim
chai
and
editor
of
the
homie
architecture.
There
was
some
discussions
around
I,
do
remember
things
like
discussing
the
scope,
I'm,
pretty
sure
it
was
discussed
here
at
one
point
very
briefly,
but
people
like
Ted
lemon
got
involved
with
it
as
well.
I
think
he
was
ad
at
the
time
about
some
certain
guidance
on
scope
and
other
things.
I
think
also
Babel
is
the
home
net
routing
protocol?
Isn't
it
rather
than
a
routing.
F
B
F
B
F
A
A
T
From
a
process
perspective,
of
course,
things
like
adoption
calls
are
very
nice
to
include
other
working
groups
on
so
that
they're
aware
that
you're
coming
to
a
pivotal
point,
if
you
hit
a
point
where
you're
like
we
think
this
is,
you
know,
there's
a
good
implement
in
this
case,
you
know,
there's
a
good
implementation.
We
think
you
know
here,
you
can
go,
take
a
look
at
it.
Let
us
know
concerns
you
know.
H
Q
R
Let's
see
the
left
figure.
The
last
figure
is
a
three
generic
reference
model.
There
is
alright,
they
working
group
document
about
multicast
of
reworking
and
we
Austria
Network
and
the
ping
and
the
beer
is
also
be
mentioned
because
they
can
also
be
used
as
if
him
I
promote
him
multi
custom
under
date.
Technology.
Let's
see
the
red
figure.
R
Let's
see
the
red
figure
I
can
we
can
use
the
example
taken
topology
of
a
memory
under
a
network.
We
replace
this
part
from
the
virtual
arena
overlay
network
into
if
I'm
spying,
the
project
and
as
your
general
topology
used
in
a
data
center,
and
we
know
that
we
have.
We
used
p
m--
as
multicast
underlay
and
the
team
will
must
build.
Motive,
has
the
tree
in
leaf
and
spying
devices
leaf
and
spy
device
or
have
their
multicast
the
flow
stage
and
in
case
one
of
the
source
and
receiver
leaf
changes.
The
multicast.
R
This
data
along
the
trees
needs
to
be
changed
and,
let's
see,
beard
her
apology,
so
the
first
of
I
don't
need
to
read
it.
Okay,
let's
see
the
beer
requirements,
every
edge
nodes
include
psi
R
and
the
PFR
he
needed
to
be
assigned
a
unique
EF
ID
and
the
aged
nose
should
exchange
PF,
ID
and
bf
a
prefix
and
other
information
by
IG
PPP
extension
and
the
beer
ingress
nodes
for
our
multicast
flow
encapsulate
Samadhi
the
multicast
packet
in
a
beer
header
which
tests
at
a
destination
as
the
BF
r
ID
set
of
a
beer.
R
R
Let's
see
the
first
method,
the
first
method
leaf
devices,
we
use
the
leaf
devices
as
the
AGR
nodes,
so
we
know
that
our
relief
devices
will
be
assigned
a
unique
appear
ID
and
the
leaf
devices
and
spy
devices
exchange
is
a
ADP
or
PDP
extension
to
build
a
beer
forwarding
plane,
but
lve
the
beer
and
Flo's
wanted
to
send
from
mve
to
leaf.
Underneath
must
know
the
destination
leaves.
R
R
If
device
will
encapsulate
the
flow
with
pure
headers,
which
the
destination
is
if
devices,
and
we
know
that
from
this
method
we
know
that
idmp
MRD
is
still
needed
to
run
between
m
ve
and
the
leaf
devices
and
the
the
multicast,
the
group
for
poor
attendance
and
the
specific
multicast
application
still
needed,
and
the
the
third
one
is
the
PS
error
limitation.
I
think
it's
a
general
question.
R
So
from
this
this
method
we
know
that
we
know.
In
some
situation,
I
mean
you
cannot
run
PDP
or
PDP
extension
and
can
not
exchanges
their
IDP
or
bgp
information
with
the
network
devices,
so
the
MBE
SPF
ID
and
the
BFI
prefix
must
be
advertised
by
any
other
race,
and
the
second
thing
is
still
the
PS
imitation.
So
we
we
know
that
from
this
way,
sir,
we
don't
wrong,
maybe
much
complicated
protocol
and
we
taught
you
better.
H
H
R
A
A
D
A
J
Perfectly
valid
to
present
to
n
vo
3
with
respect
to
this
is
the
value
it
gives.
They
don't
have
to
understand
how
it
works
in
detail
just
if
they
give
the
feedback
that
yeah
the
service
that
they
get
out
of,
that.
That
would
be
interesting,
but
they
can't
figure
out
if
it
actually
works,
then.
Basically,
that
would
be
a
lot
more
motivation
for
us
to
just
understand
all
this
crazy
and
do
three
stuff
which
I
don't
currently
so.
R
J
R
T
A
multi
right
so,
as
sandy
just
said,
there
is
a
NVRAM
cast
frame
architecture
framework
draft,
which
is
in
my
publication
queue
which
just
went
to
pim
and
amber
andy
for
review
so
and
got
you
know
for
during
the
working
group
last
call
and
such,
and
it
would
be
very
nice
to
have
feedback
I'm,
certainly
happy
to
have
extra
reviewers
during
IETF.
Last
call.
Yes,.
M
E
J
Slide
so
basically
I
wanted
to
bring
back
the
dear
te
draft.
We
have
a
beauty,
architecture,
draft
and
a
beauty,
efr
drop,
and
so
basically
we
had
some.
You
know
issues
that
made
them
expire
both
from
the
author's
side
and
then
also
I,
think
early
on
when
we
were
doing
the
first
call
for
adoption.
There
was
more
things
on
the
on
the
plate,
and
so
we
got
the
notion
that
so.
A
J
J
Was
done
so
what
the
afford
was?
Actually
you
know
so,
I
didn't
do
anything
new
on
the
beer
to
eat
stuff
that
was
fixed
in
before,
but
the
last
things
that
we
got
back
was
that
the
whole
fo,
our
story
that
we
had
was
first,
you
know
spin
it
out.
We
had
done
that
last
time
on
this
time
around
the
O
we
did
Reese,
pin
and
and
put
the
scope
of
the
fr
completely
so
that
it
hopefully
better
matched
what
the
feedback
was.
J
We
got
okay
next
slide,
so
just
quick
summary
here
for
people
who
haven't
seen
beer
E
right,
so
it's
basically
just
like
beer,
except
that
the
bits
now
can
also
indicate
intermediate
hops,
not
only
B
F
ers,
and
that
way
you
can
steer
traffic
through
the
network
along
paths
that
you
would
like
to
do,
and
the
trick
of
that
is
that
you
only
look
at
the
bits.
Indeed
are
adjacent
to
your
nodes
so
that
you
can
exactly
only
care
about
how
you
get
it.
J
You
don't
even
need
any
IGP
routing
protocol
or
anything
in
beer
2e,
because
the
stuff
gets
steered
purely
by
the
bitmask,
and
we
feel
that
you
know.
The
hope
is
that
the
beer
te
forwarding
rules
can
easily
be
added
to
forwarding
machinery.
So
if,
basically,
the
industry
is
starting
to
look
into
the
beard
forwarding
machinery,
it
would
just
be
lovely
to
have
an
RFC
so
that
the
chance
is
not
missed
to
get
that
added
into
the
next
generations.
J
The
there
is
a
lot
of
you
know,
work
in
the
beauty
architecture
draft
to
try
to
minimize
the
number
of
bits
needed
because,
obviously,
when
you
want
to
indicate
all
the
hops
through
the
network,
you
need
more
bits.
So
that's
the
majority
of
the
complexity
and
that's
all
in
the
control
plane
and
not
in
the
forwarding
plane.
Next
slide.
Ok,
so
beauty
air
for
our.
So
basically
now
we
did
come
up
with
a
very
complex
solution
to
do
it
natively
in
beer
tea
and
basically
we
sorry.
What's
your
time.
A
J
K
J
You
can
also,
then,
simply
reduce
that
complexity
and
sending
only
one
copy
at
a
time
do
failover
to
the
other
one
and
what
actually
helps
you
greatly.
There
is
the
fact
that
in
beer
and
beer
te
you
can
indicate
the
receivers
very
quickly,
so
you
can
very
quickly
without
signaling
changes,
change
the
set
of
receivers
right
then,
basically,
link
protection,
just
use
whatever
link
protection.
You
have.
That
is
not
nothing
new.
J
Next
one,
no
protection,
that's
obviously
where
existing
mechanisms
are
really
bad
because
you
only
have
point-to-point
met,
backup
tunnels,
so
you
want
to
have
something
better
than
point-to-point,
backup
tunnels
for
no
protections
next
slide
so
now.
Basically,
how
would
you
do
no
protection
with
beer
te,
two
options:
beer
te
and
beer
te
and
cap-
that's
probably
the
most
reasonable
option
and
then
basically,
this
native
solution
that
that
we
had
invented,
which
is
cool
optimization,
but
it
doesn't
work
in
all
cases.
J
So
that's,
basically
the
summary
of
the
rewrite
of
the
beer
te
fr
draft
last
slide.
So
there
was
a
research
prototype,
implementation
is
done
by
co-authors
and
and
their
students
before
you
can
read
up
all
on
that,
and
so
we're
asking
for
working
group
adoption
for
beer
te
architecture
and
the
fr
draft
and
yeah
we
would
love
to.
You
know
see
the
chip
vendors
be
confident
that
the
working
group
review
has
been
passed
so
that
we,
basically
you
know
that
this
stuff
works.
A
So
this
shaker
time
and
and
just
consider
charter
be
damned
with
this
question
who
thinks
this
would
be
work
that
we
want
to
adopt
and
do
here
in
the
beer
or
here
all
right
who
thinks
it
doesn't
belong
in
the
ITF
or
doesn't
belong
here
all
right,
good,
so
I'll
dress
the
charge.
Next
we
talk
about
this
all
right.
Questions
improve
recovery.
N
A
T
T
A
I'm
dusting
off
some
old
brain
cells
here
tortoise.
If
you
will
give
you
a
two
seconds
here
to
jump
to
the
mic
from
what
I
recall
the
beer
fib
doesn't
change,
I
know
it's
built
but
and
we'd
have
to
set.
It
would
be
it
like
a
separate
set
but
I'm
a
long
time
since
I
white
board
of
disco
there
was
napkins
I.
Think
sorry,
just.
J
Give
me
give
me
the
concern
again,
even
if
there
is
additional
forwarding
things
to
be
done,
I
think
it's
up
to
the
vendors
to
decide.
If
they
want
to
do
it
right,
we're
not
saying
that
they
must
do
it
in
the
same
round
or
so,
but
if
they
have
the
opportunity,
they
look
at
it
and
whatever
you
note,
but
if
it
changes
the
beer
architecture
should
be
part
of
the.
J
J
T
T
O
J
L
This
work
is
about
using
beer,
or
you
know,
VPN,
net
EVP
and
network.
We
have
co-authors
myself,
Tony,
Adi
and
Jorge
next
slide
so
well
for
you
VPN
the
you
can
have
all
kinds
of
provider
or
under
a
tonneau,
it's
P,
2,
MP,
ingress,
reading,
all
kinds
of
those
things,
and
now
we
can
all
see
it's
beer
and
when
you
will
use
a
beer
or
for
any
VPN
tunnel-
and
it's
very
I
said
it's
actually
very
similar
for
the
effort
for
the
MVP
in
case.
L
So
with
Avakian,
there
are
auto
discovery
routes
in
particular,
I'm,
a
rouse
and
some
odd
as
pins
reroutes.
The
defining
that
draft
that
announces
what
kind
of
what
tunnels
to
use
for
certain
flows
that
routes
carries.
A
PTA
is
pimsy
panel
attributes.
Their
pta
basically
identifies
the
panel.
That's
used
to
that
is
bound
to
that
route.
The
PDA,
including
the
tunnel
type
identifier
label
and
flags
next
slide.
L
L
This
is
already
defined
for
the
beer
and
VPN
tanner
ID
again,
at
the
same
as
an
VPN
includes
a
subdomain
ID
and
the
if
I
are
prefix
address
notice
that
this
appear
tunnel
is
considered
as
an
aggregation
tunnel,
which
means
that
no
matter
how
many
bridge
domains
you
have,
you
only
need
one
tunnel
for
it
and
because
of
that,
we
need
to
carry
a
label
in
the
case,
MPLS
infrastructure.
That
label
is
upstream
assigned
by
the
PFI.
Are
this
in
a
central
scenario
it
identifies
the
bridge
domain?
L
I
will
not
go
into
the
other
scenarios
here,
because
I
don't
have
enough
time,
and
if
you
are
using
the
V,
excellent
or
MB
gr
e,
then
the
label
field
of
the
PT
will
be
the
VI
or
BSI,
and
that
is
globally
unique
right.
Now
we
don't
cover
and
we
H
nearly
that
could
be
edited
in
the
later
version
and
then
the
flux
field
there
are
two
piece
could
be
used.
Why
is
our
leaf
information
required
bits?
The
other
one
is
if
information
required
per
flow
bit
I'll
get
to
that
later.
L
Next
slide,
so
for
beer
to
each
PA,
firearm
is
to
find
out
which
P,
F
ers
need
to
receive
the
traffic
so
that
you
can
construct
the
bit
string.
How
do
we
find
that
out?
This
procedure
is
called
leaf
tracking
if
we
are
using
inclusive,
eternal,
the
EVP
I
met
routes,
which
is
equivalent
of
the
inclusive,
IP
and
zero
out
in
a
making
case
that
can
be
used
to
attract
peas
that
need
to
receive
the
traffic
and
also
there
is
this
s,
mail
routes
that
is
defined
in
the
IGA
as
MP
ml
d
proxy
grafts.
L
Now
there
are
some
other
scenarios
that
we
need
to
use:
Espeon,
zero
outs
for
their
purpose
and
that
requires
cross
bonding
leaf
ad
routes
that
is
triggered
because
of
the
those
two
bits
carried
in
that
PTA.
So
the
draft
talks
about
that.
The
slides
talk
about
that,
but
our
spirits
in
the
presentation
now
next
slide
so
now
come
to
data
plane.
L
For
that
the
beer
headers
proto
protocol
field,
we
need
to
specify
a
new
type
new
two
types:
two
new
types
for
the
big
sandwich:
GRE
and
when
comes
multihoming
sweeps
with
horizon
procedures
for
the
X
now
on
this
year,
is
local
bias
based
and
that
still
works,
because
the
PFR
ID
in
the
beer
header
identifies
the
BFI.
Are
you
can
use
that
information
to
do
the
local,
biased,
split
horizon
procedure?
Now,
if
the
infrastructure
is
MPLS
Network,
then
beside
the
ethernet
inner
unit
for
Ethernet
frame,
you
will
have.
L
You
may
have
a
ESI
label
for
spirit
and
purpose,
and
then
you
have
a
label
/
PT
here.
If
it
is
per
bridge
table
or
a
broadcast
domain,
it's
the
same
thing
and
in
more
complicated
situation
you
can
have
a
label
special
specific
for
the
pinzhi
I'm
not
going
to
there
so
notice.
That's
here,
it's
possible
that
we
have
to
upstream
assign
labels.
L
L
You
use
our
CPP,
don't
be
telling
a
story
in
ml
DP
or
in
our
areas
for
area
use
beer
and
then,
when
it
comes
to
beer,
there
is
another
use
case
where
you
have
a
large
European
or
MEP
and
domain,
where
you
have
many
many
PE
routers,
and
but
you
have
your
B
string
lenses
only
256,
so
you
could
sell
multiple
copies
using
the
Magus
module
success
concept.
Another
way
to
address
that
problem
is
you
divide
that
beer
domain
into
smaller
sub
domains
so
inside
each
sub
domain?
L
You
just
need
to
send
one
copy
to
the
smaller
set
of
the
PFE
yards.
Those
peers
could
be
EVPs
or
it
could
be
a
segmentation
point
and
that
the
segmentation
point
will
further
replicate
the
traffic
into
the
next
beer
domain
or
next
MLP
domain.
So
that's
the
general
concept
of
the
segmentation.
So,
to
do
that
segmentation
points
will
update
the
PDF
field
when
it
realized
those
routes
into
the
next
one
to
specify
a
new
tunnel
type
or
Newton
OID.
That's
the
general
concept
of
the
segmentation
next
slide.
Please.
L
L
So
when,
when
I
BRE
dog
has
in
the
next
domain
notice
that
it
will
change
the
BFI,
R
or
202
ABR
to
itself
and
change
the
subcommittee
to
s2
and,
more
importantly,
now,
the
different
labels
are
otherwise.
There
are
labels,
3
and
label.
For
now
the
ABR
was
set
up
the
14
path.
So
that's
when
this
is
labor
one
you
will
label
switch
to
label,
3
wins
his
neighbor
to
you.
Will
label
switched
to
labor
for
so
now,
when
a
beard
package
comes
in
arriving
from
people
arriving
on
ABR
from
p1
it
does.
L
The
decapsulation
peer
header
is
removed,
and
is
this
is
label
one?
He
will
label
switch
to
label
3
and
then
it
was
sent
into
the
next
sub
domain
as
to
putting
onto
a
new
beer.
Header
is
the
two
sub
domains
are
completely
unrelated.
The
day
BR
does
is
teaching
next
fact.
So
next
steps
we
are
requesting-
or
in
group
Commons
in
fact,.
L
All
right,
this
should
have
been
presented
in
the
best
group
as
well,
but
I
forgot
to
request.
I
know
they
are
also
round
a
patent
anyway.
So
alright,
the
comments
should
go
to
both
working
groups
and
next
time,
I'll
try
to
present
it
in
the
best
working
group
as
well.
Actually
yeah
thanks
all
right.
One.
A
A
And
I
think
we
have
an
open,
discuss
right
now
that
I'll
just
address
it
directly.
It's
operational
considerations,
so
Lee
and
I
talked
about
a
little
bit
I've
kind
of
worked
out
a
little
paragraph.
It's
not
like.
We
have
to
go
into
a
complete
operational
architecture
under
the
architects
draft.
It's
more
like
you
know
what
is
operationally
different
about
what
we
currently
do
versus
what
beer
offers
and
just
so
people
can
read
it
and
I
guess
expand
their
head
a
bit
about
what
fear
does
for
the
networks.
A
I
mean
that's
the
best
I
can
describe,
because
there
will
be
operational
documents
coming
out
of
this
group
that
dress
that
directly.
They
don't
details
that
they
won't
be
in
an
architecture.
Draft
all
right,
good
question.
I
saw
finger
going
up,
so
the
rest
of
these
they've
all
gone
last.
Call
they
have
all
been
I,
guess
well
vetted
with
response
except
for
two
is
is,
and
the
ID
are
extensions.
Those
two
have
gotten
no
feedback
at
all
in
the
list.
A
So
I'm
gonna
kick
the
lists
again
for
both
of
those
just
to
get
some
feedback
and
then
we'll
progress.
The
other
four
and
Tony
here
is
gonna,
be
looking
for
shepherds
so
who
here
is
looking
to
you
know
scheppers
an
opportunity
to
get
your
head
into
how
the
process
works.
It's
not
a
big
time-consuming
requirement,
any
kind,
there's
just
a
QA
sheet,
there's
a
whole
list
of
questions.
A
A
T
But
it's
a
really.
It
is
a
really
good
way
of
seeing
like
sort
of
the
ietf
process
through,
particularly
if
you
haven't
had
the
joy
yourself
and
joyce
yeah
joy,
and
it's
also
a
really
helpful
way
of
indicating
the
strong
interest
in
the
mailing
list
in
the
work
that
there
are
people
who
are
willing
to
volunteer
to
actually
help
with
the
process
load
and
getting
it
through.
A
A
Thank
you.
So
if
you,
if
you
guys,
are
interested
right
about
this,
would
want
to
do
grab
us
this
week.
Otherwise
we're
gonna
offer
the
request
list
and
get
some
feedback
there.
Again.
It's
just
jump
in
the
middle
of
sausage
factory
and
house
see
if
things
are
chopped
up,
but
it's
a
great
way
to
learn
and
get
and
get
engaged
boom.
I
Leah
I'm
sorry
I
took
your
notes
at
lunch
and
then
I
didn't
put
them
in
this
deck.
A
T
A
Here
for
you,
okay,
just
going
back
to
the
Charter
again
run
a
time.
Please
bear
with
me
a
couple
things
on
one
addresses
this
is
important.
Our
Charter
is
specifically
talks
about
this
work
being
experimental.
It
also
gives
us
some
hurdles
to
jump
over
to
make
that
migration.
We've
learned
in
Chicago
that
we
can
go
to
the
art
we
can
go
to
RFC
process
get
a
number
as
experimental,
and
if
and
when
the
group
makes
the
justification
to
jump
to
standards,
it
happens
without
revving,
the
doc.
So
that's
a
clean
process.
A
We
also
got
great
feedback
from
operators.
They
were
more
concerned
about
getting
a
number
an
RFC
rather
than
the
track
that
was
on
so
because
the
chicken
horse
requirement
is,
we
need
to
get
bits
in
the
field,
get
some
feedback
other
than
the
bits
in
the
field.
There
are
four
things
to
talk
about:
what's
wrong
with
the
current
solutions:
what's
the
advantage
of
the
new
solution,
how
does
it
impact
hardware,
40
and
how's
that
impact
the
internet
architecture?
All
of
these
needs?
We've
talked
at
at
length
in
groups
and
on
the
list.
A
So
we've
talked
about
putting
this
draft
together
from
the
hands
in
Chicago,
we'll
get
it
out
there
for
feedback,
and
it's
probably
gonna
sit
there
and
stew
for
a
bit
until
we
get
some
field
feedback,
but
it's
the
next
thing
we
need
to
do
from
there.
We
can
reach
Artur
and
talk
about
what
what's
next
work
to
do
here.
This
isn't
something
new
in
the
forwarding
plane
right
we
got
IP,
we
got
MPLS,
then
we
have
beer.
A
If
you
think
about
that,
and
the
use
cases
are
just
going,
you
know
coming
out
now,
I
think
we're
scratching
the
surface.
I
think
there
may
be
a
lot
of
work
to
do
here,
going
down
the
road
so
think
about
that
and
we'll
take
it
to
the
list.
One
more
thing
so
Linda
Wang
from
ZD
has
moved
on
to
Australia
she's,
watching
this
video
anywhere.
So
everyone
just
say:
hi
Linda.
Can
you
let.