►
From YouTube: IETF106-BIER-20191121-1000
Description
BIER meeting session at IETF106
2019/11/21 1000
https://datatracker.ietf.org/meeting/106/proceedings/
A
A
A
A
B
C
A
Right,
everyone
read
the
note.
Well,
you
know
your
legal
obligation
when
you're
here,
neither
but
I
never
know
well
so
agenda
we're
not
totally
packed,
but
I
do
want
to
push
some
stuff
along
and
make
room
for
things.
We
want
us
discuss.
Cuz
some
of
the
stuff,
I
would
say
contentious,
but
this
is
the
open
issues
to
talk
about
and
I'd
like
this
dynamic
conversation
room
where
it's
much
better,
hey
dad's,
here,
I
dad.
A
A
Okay,
anything
outstanding,
like
business-wise
other
than
a
bunch
of
documents
in
the
queue
we've
got
a
bunch
of
working
group.
Last
call
we
have
bunch
we're
looking
for
shephard
summer
sign
shepherds
and
we
still
have
documents
that
really
come.
Hopefully
we'll
be
adopting
adoption
calls,
but
the
helpless
get
through
that
stuff
sandy
has
volunteered
to
step
up
as
Secretary
and
jump
in
and
help
us
push
yourself
along.
This
is
kind
of
weird
from
here
goes
into
holiday
week.
I'm,
sorry,
we're
full
sorry,
sir
sir.
We're
full.
A
No,
if
it
were
multicast
sure,
won't
Shepherd
to
be
enough.
It's
not
been
deployed
so
over
the
holiday,
we're
gonna,
cue,
this
stuff
up,
I'm
liking,
the
dump,
everything
and
your
email
address,
because
no
one's
gonna
read
them
anyway,
but,
like
we
did
last
year,
come
January,
it's
gonna
be
flooded,
we
gotta
push
this
up
through,
and
so
many
things
are
dependent
and
I
feel
like
we
had
such
great
progress
and
we're
almost
the
point
of
being
dysfunctional.
Now
nothing
is
no
one
could
worker
to
people
we
just
soar.
A
A
F
At
first
I'd
like
to
thank
you,
our
chairs
give
me
the
great
chance
to
take
the
secretary
job
and
I'm
very
glad
to
work
for
the
working
group
with
our
chairs.
Thank
you
and
now
let
me
start
my
presentation
for
the
beer
prefix
redistribution
tract
we
have
many
cold
calls
are
include
iced
every
and
many
others.
So
at
first.
So,
let's
see
the
problem
statement.
We
know
that
it's
a
traditional
networking,
our
deployment.
F
F
But
if
we'd
like
to
deploy
multifaceted,
English
networks,
we
can
use
PIM
protocol
to
do
it
and
it
works
well,
because
it's
not
a
depends
on
the.
It
only
depends
on
the
unicast
routing
calculation
result
so,
and
we
know
that
seeing
these
networks
may
be
in
some
areas,
just
for
example,
these
errors.
There
are
not
too
many
routers
in
the
error,
it
just
there's
telling
rotors
in
the
error
so
and
the
same
with
other
errors.
F
So
if
we'd
like
to
deploy,
pin
in
this
network
as
no
problem,
but
if
we'd
like
to
use
a
beer
to
replace
him
in
this
network,
we
will
face
some
problems
and
let
me
expand
it
because
we
know
that
from
the
existed
standard
dropped,
the
beer
is
related
to
the
IGP
errors,
so
the
so
the
every
IDP
ever
will
become
appear
domain.
So
then
this
figure
we
will
have
three
beard
of
me.
F
F
So
we'd
like
to
improve
the
efficiency
of
the
network,
so
we
wanted
to
build
a
large
period
of
men,
throw
all
these
errors,
so
we
can
remove
the
state
management
taking
the
error
borders
and
we
can
eliminate
the
encapsulation
and
decapsulation
functions
of
Rome's
abs.
So
we
will
improve
the
peer
forwarding
efficiency,
but
the
problem
is:
how
can
we
achieved
it.
F
So,
just
as
my
side,
the
beer
domain
is
related
to
the
specific
ITP
error
for
now
so
we'd
like
to
deploy
the
peer
across
many
errors.
So
we
know
that's
the
one,
the
ABR
to
the
prefix
distribution
work.
We
can
also
redistribute
as
a
peer
info
information
such
as
BFF
prefix
and
the
PFA
ID
and
the
other
associated
information.
F
So
the
beer
know
the
information
can
spread
in
the
whole
peer
domain
and
across
multiple
regions
errors.
So
at
first
we
can
use
the
advertisement
aligned
with
existed
a
GP
and
the
BP
definition.
So
once
the
prefix
at
word
highest
across
IDP
error,
one
by
one,
we
can
also
carries
the
peer
information
with
it,
and
so
as
well
as
the
employers
encapsulation.
You
can
also
advertise
it
because,
though
the
parent
absolution
has
local
significance,
but
we
may
use
it
across
different
errors.
So
I
really
know
the
hing.
F
F
So
you
know
the
one:
the
ABR
to
the
unique
host
prefix
with
distribution
work,
some
summarized
or
default
route
or
aggregate
function
can
be
used.
So
even
when
the
default
route,
for
example,
vanity
for
the
filter
is
used,
only
one
prefix
will
be
at
word
highest
into
another
error.
So
in
this
situation
this
will
high
menu.
F
We
have
a
prefix.
So
if
we
like
to
Edward,
has
the
Associated
bf
IDs
with
the
default
route,
we
must
need
our
new
extension
poet.
The
new
extension
is
that
we
can
carry
the
associated
bf,
IDs
and
all
set
and
Edward
has
set
into
the
other
error.
So
we
can
achieve
the
goal
that
Edward
highest
VFR
prefix
and
the
other
pair
information
associated
with
any
type
of
prefix.
G
Before
this
said
that
the
p
r--
p
FR
t
imported
from
outside
the
area
its
advertised
with
summer
youth,
I
think
it.
This
should
be
a
host
perfect,
because
not
only
the
FC
8401
requires
that
the
PA
information
is
advertised
with
host
prefix,
but
also
the
architecture
FC.
Looking
to
clear
that
the
bill
information
should
advertise
by
IP
address.
Let's
it's
a
hosta
pigs,
let's
have
silly
mini
host
picks,
so
I
think
so.
My
comments
is
that
information
post
by
this
document
should
be
advertised
with
your
host
perfect.
So
that's
my
comment.
F
Once
the
host
perfect,
just
mention
a
by
genome,
can
be
accurate
highest
across
different
errors,
one
by
one,
of
course,
the
host
prefix
and
is
associated
at
BFI.
This
can
be
Edward
house
in
the
same
time.
So
it's
the
first,
the
solution
for
it.
If
you
do
the
prefix
advertisement,
one
by
one
across
a
GPRS,
you
can
do
it,
but
if
we
want
to
use
default
or
summarized
route
route
to
across
the
meaning
errors,
we
must
use
some
other
method
to
do
it.
So
we
impose
there's
a
new
extension
for
it.
F
F
Summary
route
right,
let
me
explain
it
because
we
like
to
merge
all
the
errors
in
one
peer
domain
right,
so
only
in
this
figure,
just
in
this
figure
r1
and
r2
and
I
am
an
axon
ry
will
pisa
PFI
are
and
the
BFE
are
so
the
r3
and
r4
needn't,
tupiza
BFI
are
also
bf
yeah.
They
just
appear
finds
a
forwarding
plane.
F
So
we
use
advertisement
for
prefix
redistribute
it's
just
work,
work
on
this
a
BIA
and
redistribute
the
prefix,
seeing
this
error
into
the
core
error
right,
so
one
the
as
I
am
and
the
RSV
after
we
have.
Our
prefix
is
well
Edward
has
by
the
US
we
wrote
water,
it
can
just
advertise
the
summarized
route
into
the
core
network.
So
it's
just
the
control
plane.
Eunuch
has
the
work
in
the
word
husband,
it's
just
an
extension
to
IDP
yeah.
So.
H
B
I
F
F
And
so
so,
I
think
it's
a
challenger
for
the
it's
not
actually
challenges.
Sorry,
it's
just
our
computational
and
administration
requirement.
So
you
may
configure
the
BFI
this
in
my
area
and
with
not
continuous
range
for
it,
but
the
it
may
be
the
advertisement
to
complicate
in
the
a3,
but
it
can
do
right.
So
so,
if
you
can
configure
this
with
same
range
or
just
a
little
ranging
and
it
can
be,
edward
has
only
a
few
minutes.
We
only
feel
sub-ranges,
so
it
may
works
well
in
the
network.
F
So
it
depends
on
your
configuration
on
the
BFI
ID.
So
we
suggest
that
you
can
configure
the
containers
dfid
in
one
error.
It's
it's
the
most
efficient
way
to
it.
But
if
you
don't
it's
a
thought,
man,
as
doesn't
matter
the
a3,
how
also
invert
I
said
into
the
other
errors.
So,
and
so
it
depends
on
your
deployment.
G
F
G
F
G
Right,
yeah
I'd
get
cut
to
your
mini
I'm,
sorry
and
I.
Don't
need
to
configure
and
ready
to
be
after
I
pee,
but
it
has
to
advertise.
The
beer.
Encapsulation
is
a
sabot
to
me,
I'm
the
service
of
actually
it's
under
the
PL
information.
Sabot
your
way,
the
PL
information
suffered
govt
has
the
tfiid
I
thought
very
that
the
authority
or
you
ready
the
PF
idea
of
r3
itself,
doctor
information,
including
the
sanitary
and
the
servicer
TOB.
It's
completely
there
since
its
FC
8401.
F
G
F
Si
side,
if
you
have
the
ABR
to
the
traffic's
redistribution
one
by
one,
so
the
a3
will
Edward
has
one
prefix
of
one
node.
It
can
do
the
same
thing
with
existing
IP
extension,
but
air
for
r3
would
like
to
advertise
motive.
Prefix
in
one
advertisement
such
as
summaries
summarize,
the
prefix.
You
should
carry
the
Associated
VF
ideas
of
Ag
rotors,
so
I.
K
Cisco
make
it
about
clarify,
so
the
summarization
is.
It
is
only
an
optimization
right,
so
you
can
just
plug
those
things
right
through
then
they're
one-to-one
and
at
the
end
of
day
it's
not
tuning
more
than
256
updates
anyway
right.
So,
but
if
you
do
summarize,
then
that
that
ABR
will
put
its
own
a
loopback
address
as
to
be
a
Friday
mm-hmm
right.
So
it's
not
that
complicated
I
think
yes,.
L
Analysis
thing,
synchronous,
so
you're
now
sub-sub
theories
here
with
the
existing
beer
sub
sub
TVs,
also
be
you
know
possible
to
use
with
this
as
an
example,
it's
the
first
half
comes
to
my
mind,
is
like
empty
year.
For
instance,
you
know
if
you
do
like
this
empty.
U
sub
sub
T
a
week
before
a
beer.
Prefix
they've
been
useful
to
do
that
here
as
well,
because
you
can
say
this
is
same
to
you
for
the
entire
domain.
L
L
Anyway,
though,
I
feel
like
it
might
be
useful
to
allow
certain
sub
sub
theories
that
we
have
for
the
current
ears
subtly
to
be
used
with
this,
no
matter
that
requires
some
kind
of
updates
to
some
documents.
Yes,.
J
G
F
Sorry
in
IDP,
let
me
select
new
aside
the
IDP
you
already
use
summarized
prefix
I.
A
Let's
move
this
one,
the
worst
was
over
already
I,
don't
think
it's
as
complicated,
forgetting
it
but
I
think
we're
moving
towards.
You
know
some
commonality.
Let
me
just
address
the
important
part
of
program.
Progress
here.
Who's
read
the
draft
alright,
who
thinks
this
should
be
adopted
right,
okay,
so
we're
in
that
same
queue,
so
we'll
load
that
out
in
fact,
I'll
address
our
secretary
and
see
if
we
can
get
this
thing
moving.
Thank.
A
Yeah
majority
of
the
room
I
mean
I,
saw
it
probably
a
good
forty
percent
of
the
room
with
the
hands
up
of
and
I,
don't
see
anyone
whose
hands
that
led
to
it
again,
who
read
it,
keep
your
hands
up,
who
thinks
it
should
be
adopted,
keep
your
hands
up.
Alright,
all
the
readers
think
it
should
be
adopted.
There's
a
good
dozen,
at
least
that's
pretty
good
for
a
doc
all
right.
Excellent
thanks,
Mike
Thank
You
sandy,
all
right
back
to
legenda,
pin,
signaling
and
yeah.
A
H
So
who
made
call
in
nokia,
we
uploaded
the
version
8
or
the
VA,
and
there
were
some
good
comments
on
the
working
group
with
regard
to
this
draft.
We
added
three
new
sections
or
three
new
clarifications.
One
is
on
ecmp.
Basically,
what
we
are
saying
is
that
on
the
IBB
are
when
you
try
to
find
the
ebbr
order,
there
are
multiple
EVP
RS.
You
can
actually
look
at
the
CSG
and
try
to
load
balanced
Europe
in
signaling
over
multiple
egress
PVR's.
H
So
the
next
one
was
there
was
a
comment
on
the
join
attribute
address
family.
We
clarified
that
that
address
family
is
actually
the
team
packet
address
family
that
is
arriving
on
the
ingress,
bber
router
and
that's
the
one
that
we
are
actually
actually
passing
through.
The
pin
signaling
next
is
like
this,
and
last
but
not
least,
we
clarified
the
PM
SM.
H
So
this
is
the
latest
version
and
next
slide,
please
so
where
we
are
standing
now
with
these
comments,
we're
wondering
whether
there's
any
other
cavities
in
the
draft
and
if
there
are
no
comments,
questions
I
think
we
done
last
call
on
this
graph
twice.
So
we're
wondering
what's
the
next
step,
whose.
A
Readiness
form
all
right,
keep
your
hands
up.
If
you
think
it's
ready
for
last
call
keep
them
up
drop
them.
Otherwise,
yeah
we've
addressed
those
actually,
so
no
one
doesn't
go
back.
The
list
is
well
I.
Think
they're
too
weak
may
have
come
up
with
you
bribed
again.
Just
for
clarity.
We
may
be
accelerated
so
we'll
go
and
drop
by
drop
based
on
history.
If
you've
gone
through
two
or
three
like
this,
we're
a
band
guys
sell
a
consensus
on
good
to
start
over
again,
but
which
way
this
is
Pizza
going
yep.
A
L
As
far
as
far
as
I
mean
I
mean
I
did
Estevan
also
deeply
the
draft
pretty
carefully
not
this
person,
but
the
previous
one
and
I
think
it
should
be
pretty
good
from
pin
perspective.
But
it's
great
to
get
of
course,
we're
doing
a
team
working
group.
So
so
I
would
say
we
can
I
can
send
emails
with,
but
we'll
just
say,
there's
the
last
call
and
in
beer
and
please
go
and
have
a
look
at
the
draft.
Synchronize.
N
A
A
H
All
right
yeah,
so
this
is
a
I
want
to
use
my
words
very
carefully.
I
was
gonna,
say
extending
in
signaling
for
EM
LDPE,
but
I
know
there.
There's
a
I'm
gonna
get
a
slap
on
the
wrist
for
that.
So
this
is
ml,
DP
signaling
over
a
beer
core.
Basically,
it's
the
same
idea
again.
What
we
are
trying
to
do
here
is
we
are
trying
to
extend
any
legacy
multicast
protocol
over
a
beer
core
without
actually
affecting
the
access
legacy.
Multicast
protocols.
H
H
So
basically,
what
we
are
doing
is
that
we
are
using
RFC
70
60,
which
is
TL
DP
and
upstream
assign
labels
to
assign
a
label
in
the
beer
core,
and
we
stitch
that
label
the
upstream
assign
label
which
is
assigned
by
the
ebbr
actually
to
the
ml
DP
downstream
label,
and
that's
how
we
actually
complete
the
solution
of
signaling
MPLS
in
this
case
MLB
pitcher
of
beer
core.
So
there
has
not
been
many
changes
in
version
one.
H
There
were
some
comments
which,
were
you
know,
asking
us
clarify
some
aspects
of
it
in
the
draft
next
slide.
Please
so
one
thing
I
added
was
that
I
added
ecmp
case
for
for
this
also
so
the
same
thing
on
the
IBB.
Are
you
can
look
at
the
route
and
and
the
opaque
like
the
effect
that
is
arriving
from
downstream
and
based
on
based
on
that
fake?
You
can
actually
load
balance
your
point-to-multipoint
tunnels
over
multiple
egress
TBR's
next
slide.
H
So
on
the
ebbr
procedure.
Again,
it's
the
same
as
it
was
on
the
previous
draft.
I'm
not
gonna,
go
over
it
again
for
the
sake
of
time
next
slide,
please,
and
on
the
data
part,
we
did
not
do
any
changes
compared
to
the
last
time
that
we
presented
so
again
for
the
sake
of
time,
I'm
gonna
skip
over
it.
So
where
we
stand
with
this,
is
that
I
think
we
have
multiple
players
on
this
draft
and
we
are
asking
for
working
group
adaptation
to
make
this
draft
part
of
it.
Working
with
you,
who's.
A
L
Yeah
hi,
so
this
is
about
the
beer
extension
to
our
champion
ml
d.
So,
as
you
know,
we've
been
discussing
about
an
item
pure
ml
d
overlay
for
beer,
so
kind
of
similar
to
that
pin
signaling
we
just
spoke
or
discussed
if
you
want
to
use
I
jump,
your
ml
d
as
an
overlay
and
as
to
figure
out
with
with
PIM,
is
that
it's
good
to
have
a
way
of
identifying
exactly
who
the
receivers
are
like,
who
are
the
Debbie
egress
routers?
What
I
should
say?
L
Basically,
when
you
receive
a
pin
joint,
how
do
you
know
exactly
the
be
Friday
and
so
know
who
the
joint
came
from
and
also
forum
p.m.
of
the
overlays?
We
want
a
way
of
identifying
who
who
sent
that
idea,
P
remedy
report
and
who,
who
wants
to
receive
yeah
human?
Exactly?
Who
is
that
beer
receiver
anyway?
L
So
in
order
to
do
this
for
a
GMP
remedy,
we
need
to
extend
onion
p.m.
LD
messages,
and
we
don't
really
want
to
make
any
changes
to
those
protocols
on
a
three
habitude,
but
I
think
there's
an
easy
way
of
doing
this.
So
this
draft-
it
does
just
try
to
do
this
in
a
generic
way
and
by
having
like
a
IGMP
remedy
type
extension,
because
it's
generic
and
it's
kind
of
a
new
thing
to
extend
our
EMP
remedy
messages.
I
think
this
needs
to
go
to
that
pin
working
group
that
is
responsible
for
those
protocols.
L
A
B
A
Here
so
we
did
the
work
here
and
then
we
we've
brought
in
the
working
group
to
conclude
the
work.
You
know
we
basically
take
it
on
so
I
think
I
mean
stay
you're
the
chair
over
there
I
mean.
Do
you
think,
there's
enough
information
there
to
complete
it?
Should
we
adopt
to
here
first
progresses
and
then
move
it
over
all.
L
Right
this
right
now,
I'm
presenting
this
in
both
working
groups
and
they'll,
see
what
people
think,
but
but
I
would
say
when
it
comes
to
OSPF,
for
instance,
there's
all
you
know
there
already
was
a
well-defined
way
of
extending
or
defining
right
right
and
there,
but
in
this
case
there,
no,
no
other
extensions
done
for
Imperium
LD,
and
we
also
create
a
new
registry
and
stuff.
So
I
feel
like
it's
more
radical.
Okay.
L
Right,
let's
go
to
the
next
slide,
so
the
nice
thing
is
looking
at
our
comparison
to
your
MLD,
where,
since
you
are
FCS,
is
that
they
they
all
discuss
how
you
can
have
additional
data
in
in
IGMP
and
all
the
reports
and
queries
and
what
they
say
is.
Basically,
if
an
existing
implementation
receives
a
message
with
some
additional
data,
they
should
compute
the
checksum
Oh
everything,
but
they
must
ignore.
Whatever
data
comes
whatever
additional
data,
there
is.
L
So
if,
during
this,
of
course,
we
don't
expect
also,
like
Arjun
piano,
the
implementations
to
be
updated
overall.
The
key
thing,
though,
is
like
in
this
case:
you
only
want
this
for
beer
encapsulation,
so
the
only
devices
that
would
need
to
be
upgraded
to
support
this
thing
would
be
beer,
ingress
or
egress
routers,
but
if
somehow
those
reports
are
carries
would
leak,
you
know,
existing
implementation
should
be
more
yet
extra
data,
but
yeah
I
think
the
main
question
and
primer
tree
probably
will
be.
L
L
So
this
is
what
it
might
look
like.
So
you
have
the
existing
RMP
query
format,
but
then,
at
the
end,
there
you
have
an
additional
data
and
what
I'm
trying
to
define
is
an
extension
type
and
then
the
actual
value.
So
the
idea
with
a
type
I
guess:
that's
on
the
next
slide.
Let's
go
to
that.
The
idea
with
the
type
is
that
if
this
for
some
reason
and
up
adding
extensions
for
some
other
purpose
as
well,
we
can
tell
them
apart.
L
So
what
I
want
to
say
is
if
an
implementation
supports
extension
and
they
supported
the
specific
extension
type.
Then
they
process
that,
according
to
the
specification
like
like
this
draft,
if
if
an
implementation
doesn't
support
the
specific
type
or
or
extension
at
all,
they
would
just
ignore
that
extension
and
process.
The
the
EMP
must
Emily
message
just
looked
at
you
today,
but
if
it
didn't
have
this
extension
type
and
someone
also
did
some
extension
for
another
purpose
and
implementations
might
accidentally
try
to
parse
parse
it
and
you
know,
treat
the
data
in
the
wrong
way.
L
Rather
than
treating
queries
and
reports
differently,
that's
something
that
we
can
discuss
here
so
so
what
I'm
trying
to
do
here
is
one
document,
maybe
in
the
pin
working
group
that
focuses
on.
Why
do
we
need
to
extend
a
G&P
remedy
and
what's
a
generic
way
of
doing
it?
Well,
the
actual
use
of
this
would
be
in
this
working
group
and
for
for
this
overlay
draft
one
thing
we
could
consider.
For
instance,
two
is
right
now
the
dicks,
the
exact
extension
type
with
a
value,
the
TLV
canal
isn't
this
draft,
but
they
could.
L
A
L
L
A
L
L
A
D
That's
why
it's
okay,
yeah,
so
I
was
just
wondering
from
the
deployment
thing
right,
so
it
is
it
kind
of
we.
We
still
have
this
with
fear,
because
we
started
with
IGMP,
because
if
I'm
now
trying
to
explain
to
somebody
why
he
would
want
to
do
the
IGMP
overlay
as
opposed
to
using
pin
you
know
when,
when
when
would
this
be
preferable?
Now
that
we
have
the
the
pin
document
as
well,
because
every
every
edge
router
that
is
doing
pin
obviously
also
supports
IGMP,
so
I.
A
A
Why
would
you
depend
if
you
had
connecting
pin
damage
him
message
just
coming
through
her
propagates?
That's
not
easy
to
apology
answer
other
than
that,
just
religion.
You
know
cuz
if
you're
gonna
use
that
just
as
membership
signaling
independent
of
what
your
edges
are,
yeah
I'm,
not
certain.
Why
do
you
pick
one
over
the
other
yeah.
B
D
Makes
sense
all
I'm
saying
right
if
there
is
any
chance
to
give
you
know
guidance,
you
know
if
people
look
into,
we
can
only
implement
one
of
it
in
or
IGMP
right.
So
first
right
so,
like
all
I'm
saying,
is
we're
giving
so
many
alternatives
and
we
want
to
make
the
you
know
beer
successful.
So
how
do
we
kind
of
what
would
be
our
guidance
if
people
come
back
and
say
we
can't
implement
everything
at
once.
Use
BGP.
L
L
So
this
other
draft,
so
we
have
a
RFC
in
PIM
for
this
way
of
flooding,
source
information
throughout
the
PIM
domain
and
the
idea
is
yeah.
It's
described
here.
The
idea
is
it's
a
little
bit
like
PSR,
but
it's
like
source
information
instead
of
our
pian
or
grid
mappings.
So
the
idea
is
when
I
first,
a
browser
learns
to
a
new
source.
Instead
of
sending
a
pin
register
to
an
RP,
it
would
originate
this
PF
MSD
message
and
that
message
is
kind
of
similar
to
be
as
far
as
like
forwarded
hop-by-hop
throughout
the
ping
domain.
L
So
we
have
this
four
pin
today,
and
it
would
be
great
if
we
could
work
with
beer
as
well.
Basically,
if
you
have
a
beer
in
the
middle
of
a
ping
domain
like
for
the
pim
signaling,
it
would
be
nice
if
these
messages
can
make
it
through
the
domain,
and
that
means
that,
if
you
have,
let
me
go
to
the
next
slide.
L
L
We
would
like
to
some
pin
joints
for
the
beer
domain,
but
if
you
have
but
the
if
you
are
deployed
PF
MSD
with
pim
done,
basically,
you
need
somehow
to
get
that
source
active
information
to
make
it
through
the
pin
domain
through
the
beer
domain
through
the
other
side,
so
that
you
know
that
you
should
actually
send
them
a
mask.
Emoji
join
so
main
purpose
of
this
draft,
or
one
of
the
main
purposes,
is
to
just
make
sure
that
PF
MSD
messages
can
make
it
through
the
beer
domain.
L
L
But
this
this
draft
has
an
additional
extension:
it's
not
required
necessarily
just
for
the
bass
pfm
functionality,
but
one
of
the
issues
with
a
pin
overlay
is
how
do
we
determine
where
to
send
a
pin
joint
I
know
the
the
pin
mobile
a
draft
supreme
signaling
draft
has
like
four
different
ways
of
doing
this,
but
I
feel
like
this
is
in
some
ways
an
easier
way
of
doing
it.
But
this
the
proposal
here
is
when
the
beer
border
router
between
the
pin
domain
and
the
beer
domain
passes
this
TLB
into
the
beer
domain.
L
L
That
can
use
this
information
if
it
if
it
wants
to,
join
and
determine
which
which
router
should
I
join
towards.
So
so
I
think
this
could
be
quite
useful
for
the
Pima
Valley
as
well
by
the
way,
in
this
case,
there's
no
art
piece
or
anything
as
the
part
of
the
use
reason
to
use
pfm
so
to
be
all
Eskimo
he
joins,
and
the
rest
here
is
just
defining
these
new
TL.
Amis
is
basically
when
a
beer
router
is
forwarding
pfm
message
into
beer.
L
It
adds
it
identifies
itself
with
a
subdomain,
be
Freddy
and
that
stuff
and
then
on
the
next
slide.
There
is
this
other
thing
where,
basically,
you
can
associate
a
metric
with
sourcing
group
information.
Think
that's
it.
Maybe
there's
one
more
slide
at
the
end.
A
lot.
It's
really
really
hard
to
read
this.
L
A
P
L
L
L
Q
F
L
L
Okay,
so
they
put
it
this
way,
yeah
if
you
have
deployed
pfm
in
in
PIM
to
begin
with,
and
you
decide
I
want
to
have
beer
in
the
middle.
Don't
mean
leave
this
for
pfm
to
function,
but
the
second
part
is:
if
you
deploy
him
signaling
overlay,
then
this
can
help
help
you
with
determining
where
to
send
the
joints.
What
the
beer
ingress
router
should
be.
F
F
L
F
F
F
L
F
L
F
R
R
L
Okay,
so
when
you
receive
so,
the
TV's
are
not
modified
as
they
passed
through
the
beer
domain.
So
when
this
guy
on
the
right
receives
the
message,
it
will
contain
a
metric
that
was
seen
by
this
guy
over
here.
So
I
guess
what
you
want
to
do
is
small
s,
maybe
look
at
what
is
your?
What
is
your
magic
to
this
guy
across
the
beer
domain
and
add
that
to
the
perhaps
telemetric,
if
you
see
what
I
mean.
B
L
R
So
it
sounds
that
if
you
were
to
pass
that
through
that
point-
and
you
used
the
metric
inside
of
your
domain-
that
it
would
be
kinda
weird
right,
because
maybe
you
have
OSPF
here
where
the
28
is
is-
was
a
metrical
mm
and
the
other
side.
And
then
your
actual
opinion
cloud.
There
is
I,
don't
know
something
else.
So
what
do
you
do.
R
And
I
know
that
Sandy's
draft
is
not
yeah,
but
from
the
support
earlier
it
sounds
like
yeah,
so
there
say
but
they're
saying
a
functionality
in
BGP
called
I.
Think
a
GP
correct,
which
tries
to
do
the
same
thing
and
tries
to
carry
a
metric
across
multiple,
a
SS,
and
so
it's
called
the
accumulated
geometric
or
something
like
that.
So
maybe
look
at
that
because
that
I
think
they
they
did
it
on
purpose
so
that
you
can
have
multiplies
you.
R
F
Just
or
semi-solid
he
just
four
hours
question
and
we
think
that
we
will
get
the
metric
from
many
ways
as
such
as
ITP
opt
P
or
something
else,
and
maybe
we
can
configure
with
the
and
by
the
administrator
to
concur
with
the
metric
across
I.
Yes,
so
maybe
we
have
a
dissection
to
explain
it
in
the
draft
right
yeah.
Thank
you.
F
L
I
would
also
say
one
thing
to
consider
is
I
mean,
haven't
thought
much
about
this,
but
could
potentially
you
know
just
have
a
simple
draft
that
just
defines
two
simp,
the
basic
bf
mo
a
beer
which
is
sufficient
for
just
a
pimp
functionality,
this
stuff
for
the
metrics
and
stuff.
That
would
be,
you
know,
potentially
something
additional
if
we
feel
feel
is
useful,
but
need
to
think
more
about
whether
yeah
you
need
to
do
that
or
not
yeah
yeah.
L
A
N
You
say
good
morning,
montgome
know
from
Cisco,
Systems
I
will
be
talking
about
flex,
L
go
for
beer
and
in
the
current
0th
person
of
the
draft.
Rick
is
more
of
problem
statement
that
what
we
are
trying
to
solve.
So
we
have
seen
many
requirement
where
network
has
been
sliced
using
IG
v
flex,
L
go
and
each
of
the
slice
is
has
different
kind
of
capability.
It
could
be
maybe
high-bandwidth
low-latency
or
anything
else,
and
how
are
we
going
to
use
beer
or
how
are
we
going
to
use
flex?
L
go
in
the
beer
domain.
N
One
of
the
mechanism
which
we
are
thinking
about
is
having
sub-domain
per
slice.
Our
/
I
GP
algorithm
and
we
will
we'll
be
using,
are
extending
the
procedure
defined
in
the
beer
bar
IPA
draft
and
which
will
handle
this
mechanism,
and
it
is
just,
for
example,
it's
showing
that
each
in
case
of
MPLS
data
plane,
you
get
label
for
sub
domain
or
per
slice,
and
it
can
be
used.
H
Going
ochio,
yet
this
is
definitely
interesting
right,
something
that
we
need
to
definitely
work
on
in
the
field
working
group-
and
you
know,
as
we
had
conversation
previously,
I
can
see
the
sub
domain
feeling
very
nicely,
because
it's
just
the
way
that
you
know
beer
is
design
the
label.
I
I
wasn't
sure
if
I
could
get
my
head
around
it
like
to
mean,
like
a
label,
is
a
sub
domain
concept
anyway.
So
with
that
one
I
think
we
need
to
do
a
bit
more
thinking,
but
they
are
definitely
something
interesting
here.
S
K
F
Maybe
my
question
has
be
over
the
producer,
a
president
Eyring,
because
I,
because
we
use
we
know
that
a
beer
use
ITC
as
under
a
protocol.
So
we
know
that
blacks,
echo
has
been
implemented
during
the
IDP
expansion,
so
the
secret
we
just
you-
can
I
use
this
ITP
extension
the
underlay
to
achieve
the
ago
for
the
leaders
changing
that
include
the
panelists
or
something
else
right.
So
I'm
not
know,
I,
don't
understand
much
more
should
be
doing
in
beer
itself
right.
F
N
E
I
Anyway,
good
morning,
Carolyn
presenting
this
on
behalf
of
my
authors,
Jeffrey
has
presented
this
a
couple
of
times
already
and
the
idea
is
to
to
have
beer
for
evpn
services,
so
after
RFC
85
56,
it
feels
so
many
natural
to
bring
together
the
beauty
of
Vivi
PNM
beer.
So
this
is
about
having
beer
as
a
provider
tunnel
for
a
VPN
traffic
European,
not
only
IP
multicast,
on
a
VPN
but
in
general
bump
traffic,
it's
very
similar
to
a
beer
for
VPN,
and
actually
some
of
the
the
text
is
taken
from
RFC
85
56.
I
There
are
some
European
specific
aspects
that
are
described
here.
Things
like
a
leaf
tracking
some,
you
know
stuff
related
to
data
planes
and
how
you
handle
multihoming
and
segmentation
stuff.
So
we
go
to
the
next
slide.
Please
yeah
the
way
we
encode
the
beer
information.
There
are
no
surprises
here.
It's
pretty
similar
to
end
VPN.
I
We
we
put
everything
on
the
on
the
PTA
in
the
premise:
I
attend
a
lot
to
get
that
we
advertise
along
with
I,
met
route
and
SP
MC
80
routes,
which
are
they
equivalent
routes
to
MVP
an
IPM,
CNS
pmcid
routes.
So
same
kind
of
information
from
an
EVP
in
perspective,
PR
tunnel
is
just
like
you
know,
an
aggregate
tunnel,
so
we
need
an
extra
piece
of
information
for
the
multiplexing,
the
traffic
at
the
egress.
That's
a
that
goes
India
in
the
label.
I
That's
an
upswing,
assign
label
by
the
via
fire
and
it's
identifying
what
to
do
a
day.
A
day
is
pretty
much
the
bridge
table
if
you
have
any
VPN
service
or
if
you
have
an
ABR,
a
a
SBR,
the
dip
into
the
MC.
You
also
have
some
facts
that
we
use
for
leaf
tracking.
If
we
go
to
the
next
slide,
so
yeah
lifter
about
leaf
tracking,
we
use.
If
you
have
pure
lair
to
bump
traffic,
we
you
know
the
I
met.
I
I
In
some
cases
you
do,
you
may
want
to
do
some
optimizations.
If
you
don't
want
to
send
Asma
crowds,
you
know
for
every
single
flow
and
in
such
a
case
we
also
have
in
Indian
as
BMC
routes
and
leaf
routes,
so
that
you
can
do
some
tracking.
So
you
can
have
some
kind
of
mix
between
you
know
an
estimate
per
flow
or
then
you
can
track.
You
know,
depending
on
how
much
flooding
versus
control
plane
routes
you
want
next
slide,
please.
I
The
other
aspect
that
we
are
looking
at
in
this
trough
is
because
II
VPN
works
for
IP
overlay
talents
or
MPLS
tunnels.
We
also
defining
how
to
you
know
how
the
data
plane
works
with
beer.
So
in
the
first
case,
if
you're
using
IP
overlay
tunnels
like
the
expand
and
V
GRE
or
genève,
basically
you
will
have
the
beer
header
and
immediately
after
you
will
have
to
the
exam
or
NV
grea
genève
header,
and
then
you
will
have
the
payload,
which
is
always
an
Ethernet
frame.
I
There
is
no
IP
UDP
header
before
the,
for
instance,
the
VX
and
header,
and
the
reason
why
is
because
you
already
have
a
maybe
or
Heather?
You
know
the
information
about
what
the
next
header
is,
so
we
we
save
some
overhead
with
this,
and
when
we
use
this
along
with
all
active
multihoming,
there
is
something
called
esprit
Corizon
that
you
need
in
elective
multikill,
meaning
in
order
to
avoid
loops
for
bump
traffic,
and
here
because
in
the
beer
header,
you
have
the
V
F
IR
ID.
I
Just
in
the
same
case,
you
would
do
with
other
tunnels
in
in
the
case
of
MPLS,
we
have
the
beer
header
and
immediately
below
that
you
have
an
MPLS
label
to
identify
the
bridge
table
and
you
may
have
a
know
yet
another
label
to
identify
the
source
ESI
of
the
of
the
packet.
That
is
also
used
for
a
splitter
isin
with
all
active
multihoming.
I
Next
slide,
please.
So
the
drop
also
talks
about
segmentation,
which
may
be
used
in
certain
situations.
For
instance,
when
you
you
want
to
use
different
tunnel
types
in
different
areas
or
autonomous
systems,
but
you
can
also
use
this
in
a
larger
peer
domain
to
divide
it
into.
You
know
multiples
mail
and
smaller
subdomains
and
when
you
do
this
segmentation
on
the
ABR
ASPRS
as
usual,
you
need
to
change
or
to
update
the
PTA
on
the
I
met
or
or
this
beam
surrounds.
So
next
slide.
I
Please
whoops,
sorry
about
that
in
the
air
slides
it
was
looking
okay
anyway.
So
what
the
the
title
of
this
slide
says
is
what
is
new
in
the
revision
0-2?
So
what
we
added?
There
was
a
discussion
on
the
mailing
list
and
basically,
when
you
are
using
this
along
with
IP
overlay
tunnels
and
and
you
want
to
use
PHP
a
couple
of
slides
ago,
I
was
saying
that
for,
for
instance,
for
VX
LAN,
we
don't
use
an
IP
UDP
header
after
the
beer
header.
I
However,
if
you
do
PHP,
basically
you
remove
the
beer
Heather
as
well,
so
you
may
end
up
with
you
know:
packets
without
beer,
header
or
IP
UDP,
and
just
with
the
VX
LAN
header,
and
getting
to
the
egress
note.
So
there
is
no
wouldn't
understand
what
that
is.
So
what
we
are
saying
this
revision
of
the
draft
is,
if
you
are
gonna
use
PHP,
you
must
add
an
IP
UDP
header
before
the
VX
on
header.
I
Now,
once
you
do,
that
you
need
an
IP
DA
in
that
IP
header,
so
which
one
to
use
is
something
that
you
can
statically
configured
at
a
ingress
P,
so
that
you,
you
know
what
to
expect,
or
we
added
this
auxilary
information
on
the
PTA,
where
you
can
actually
add
a
tunnel
encapsulation
TLV,
defining
what
their
IP
das
as
an
IP
multicast
address.
So
you
have
both
just
pretty
much
next
slide
please.
A
N
F
Slides,
please
enjoy
your
soil
and
by
Pia
ICU
fashion.
Is
the
the
eternal
encapsulation
start
here
right?
So
what
we
will
do?
We
will
inherit
all
the
encapsulation
tabs
from
this
structure
or
we
will
define
the
type
4
for
this
tunnel,
because
I
only
see
three
tunnels
are
mentioning
attractor
right
now,
such
as
the
Geneva
and
the
explained
and
a
median.
But
so
we
know
that
the
as
many
internal
taps
are
defined.
You
know
the
tunnel
encapsulation
charge.
F
I
The
new
piece
of
information
we
are
interested
in
as
it's
really
the
IP
destination
address,
because
normally
in
any
VPN
you
already
send
the
I
met
routes
or
the
MC
routes
with
PGP
encapsulation
as
extended
community.
That
is
telling
you
whether
they
you
know
the
tunnel
is
the
exam
or
I'm
pls
or
whatever
so
I
do
not
think
that
is
necessary.
So
but
yeah
I
mean
in
theory
with
any
IP
overlay
tunnel.
You
couldn't
include
the
the
code
point
and
the
IP
destination
address.
F
I
F
I
I
R
Laura
Thunder
Oh,
Andy
gonna,
ask
after
Sandy's
question
live
away,
so
I
think
what
she
means
is
that
the
TLV
has
a
bunch
of
other
stuff
that
you
don't
care
about.
So
even
if
it's
optional,
what
happens
if
the
tunnel
type
is
something
else
so
eventually,
when
you
specify
this,
please
write
in
the
draft.
What
should
happen
when
you,
if
you
receive
that
TLB
with
some
tongs
I,
does
not
support
it
mm-hmm.
What
should
you
do?
Yeah.
A
C
D
Okay,
so
we
have
a
working
group
last
called
since
104
still
looking
for
you
know
additional
reviews,
please
check
at
it.
Last
time
we
were
at
103.
Oh
sorry,
zero!
Three
now
we're
there
are
five
with
the
review
feedback
a
little
bit
more
from
a
dirt,
but
already
done
or
three
and
a
great
review
from
Jeffrey.
So
right
now,
I
think
we're
standing
at
five
approvals
to
move
on
Jeffrey
hadn't
come
back
after
all.
Five
so
probably
been
too
busy
and
missing
here
in
action.
A
D
So,
basically,
in
the
introduction
we
so
all
the
changes
are
non-functional
they're,
all
you
know
trying
to
improve
the
readability
and
the
explanations
given
on
some
of
the
more
complex
topics.
So
one
of
the
things
we
actually
been
brain,
some
a
little
bit
in
role,
was
also
using
a
bloom
filter.
So
there
is
a
reference
there
just
to
related
work
that
had
been
starting
with
bloom
filters,
and
you
know
why
we're
not
using
bloom
filters
here
in
Beauty,
then
people
didn't
like
the
the
word
layers,
for
you
know
the
picture
showing.
D
D
There
was
a
section
3.4
with
with
the
initial
big
purity
forwarding
example.
You
know
two
people
said
that
there
there
was
a
need
earlier
in
the
document
to
do
something.
So
in
all
three,
we
had
added
a
bigger
to
new
examples,
and
so
this
old
staff
stuff
is
meant
to
be
removed
by
RFC
editor.
Unless
you
know
any
other
reviewer
chimes
in
and
says.
No
I
also
want
to
keep
this
old
example.
Next.
D
Ok,
so
then
leave
paprs.
So
oh
no
now
I'm
going
to
kill
the
remote
audience
by
going
here.
So
basically
edit
this
picture
here
to
explain
better
the
difference
between
a
normal
B
fer
that
can
be
a
transit
device.
So
this
is
basically
you're
saying
I
should
try
to
stay
in
the
cage
and
okay,
alright,
okay,.
D
D
In
this
case,
this
PE
can
be
transit
for
traffic
from
that
P
node
all
the
way
to
this
P
node,
and
so
that
basically
means
we
need
to
allocate
individual
bits
for
these
two
peas,
whereas
these
being
leaf
nodes,
we
only
need
to
attach
Beauty
bits
for
the
four
links,
therefore,
saving
bits-
and
so
this
is
now
hopefully
a
lot
clearer
through
the
picture
and
obviously
for
these
nodes,
never
to
become
transit
nodes.
The
routing
protocol,
of
course,
also
has
to
be
configured
accordingly
in
case
of
link
failure.
D
D
So
then,
also
the
the
somewhat
compressed
form
of
representing
B
IFT
entries
for
ecmp.
What
this
stuff
meant
seemed
to
haven't
been
clear
enough
so
through
the
document
where
many
of
these,
where
they've
been
expanded
into
saying,
we're
doing
an
EC
and
P
over,
you
know
multiple
different
direct
neighbor
ships
forward
connected
layer
to
adjacency
and
basically
the
EC
MP
is
picking
based
on
the
seat,
one
of
those.
So
hopefully
this
is
a
lot
better
readable.
Now,
oh
yeah,
and
they
have
been
spoke
at
an
explanation.
D
How,
basically
there
happens
book
is
kind
of
you
know
a
flood
optimization,
because
we've
seen
a
lot
of
you
know
deployments
with
multicast.
You
know
for
TV
services,
where
you
knew
all
this
program.
Stuff
needs
to
be
flooded
to
all
the
next,
a
layer
in
the
network.
Let's
say
the
the
next
aggregation
stuff,
so
you
can
really
assign
a
single
bit
to
all
the
spoke
links,
because
everything
needs
to
be
flooded
next
slide.
D
So
then
the
EC
and
P
stuff.
Obviously
you
know
the
whole
polarization
stuff
is
always
the
most
complicated
thing
to
to
work
through.
So
the
text
is
refined
in
O.
Five
now
saying
that
we
don't
need
to
standardize
the
ecmp
algorithm,
but
obviously
it
needs
to
be
documented
so
that
the
the
proprietary
mechanism
needs
to
be
documented,
so
that
the
controller
can
calculate
the
e
CMP
decision
and
there
is
an
example
of
an
algorithm
given.
D
So
that's,
basically,
this
predictable
form
of
you
know:
modulo
ecmp,
that's
done
very
often
also
classical
in
IP
multicast,
and
the
whole
point
here
was
to
have
the
seed
so
that
in
different
stages
of
this
forwarding,
you
can
configure
the
ecmp
to
use
a
different
seat
and
therefore
avoid
this
typical
multistage
ecmp
polarization
problem
that,
for
example,
because
everything
goes
left
here
in
the
next
stage.
That
also
goes
left
here,
so
nothing
ever
goes
on
this
link,
for
example,
okay.
D
Next
one,
then
that
was
also
routed
adjacency.
So
in
the
introduction
in
the
beginning,
there
was
an
explanation
that
routed
adjacencies
are
kind
of
like
this.
You
know,
I'm,
not
using
the
terminology.
Segments
from
SR,
but
kind
of
the
the
line
of
thought
is
the
same,
that
you're
kind
of
jumping
over
points
where
you
don't
need
to
do
routing
and
you're
only
interested
to
specify
on
which
kind
of
note
or
interface.
D
On
the
next
point,
where
you
want
to
continue
your
traffic
steering,
you
want
to
come
out,
and
this
whole
picture
seemed
in
the
review
from
Jeffery
to
be
too
confusing,
so
I
simplified
it
just
having
one
stage
here
right,
you're
on
one
of
these
ingress
routers,
you
want
to
get
across
this
and
you
have
these
two
different
cases
like
I
want
to
get
into
this
next
hop
across
one
of
these
two
interfaces.
So
those
are
two
bits
or
I
just
want
to
get
into
this
node.
D
D
They'll
always
only
happen
in
parallel
across
different
branches
of
a
tree
right,
so
you're,
basically
saying
here,
I'm
setting
bit
five
and
then
replication
happens
and
somewhere
down
here,
you're
always
reusing
the
same
five,
so
in
structured
networks,
for
example,
at
the
edge
of
interfaces
toward
different
areas.
Those
are
kind
of
replications,
where
you
can
save
a
lot
of
bits
when
you,
when
you
have
it
very
structured
and
you're
replicating
first
and
then
the
same
bit
will
achieve
the
same
kind
of
traffic
engineering
further
down
in
each
area.
D
So
that
was
kind
of
added,
because
that
that
seemed
to
have
been
a
point
of
confusion
before
from
the
review
from
Jeffrey
so
and
then
at
4:10.
There
is
a
summary
of
restating
all
these
nine
types
of
optimization
of
the
bit
positions
with
a
simple
paragraph,
each
too
so
kind
of
to
close
that
section.
D
So
I
overhauled
the
explanation
of
the
forwarding
pseudocode,
no
change
in
the
forwarding
pseudocode,
but
the
idea
was
to
explain
the
distinction
between
beer
and
beer
te
with
respect
to
the
fact
that
beer
by
you
know
having
these
few,
these,
the
most
optimized
number
of
bits
just
for
the
destination
will
basically
have
the
dependencies
between
the
different
replication
that,
if
you're
sending
out
a
packet
to
the
first,
you
know
interface
for
the
first
bit
that
you
are
routing
across
that
interface.
You'll
be
clearing
out.
Logically,
all
the
other
bits
that
would.
D
You
would
also
send
to
the
same
outgoing
interface
right
and
that
creates
a
dependency
between
the
replication
you
are
doing,
whereas
in
beer
te
well,
we
need
to
have
a
bit
for
the
outgoing
interface
and
that
triggers
to
the
replication
there
and
the
note
doesn't
really
care
whether
it's
replicated
further
down
to
multiple
receivers,
so
more
bits
needed.
But
for
that
matter
the
operation
of
determining
a
replication
to
every
individual
bit
is
independent
of
any
other
bits.
D
D
Right
so
then
I
had
something
like
trying
in
this
section
7,
which
was
more
operational
stuff
to
say
that
the
total
number
of
bits
we
need
for
the
transit
hops
to
specify
the
path,
maybe
between
20
and
80
percent.
So
then
dirt
challenged
me.
Okay,
where
are
the
hundred
pages
of
research
paper
with
good
combinations?
So
I
basically
had
to
admit
that
we've
done
some.
You
know
on
whiteboards
as
some
example,
but
we
haven't
really
published
any
good.
You
know
quantitative
analyses.
D
D
The
sender
just
needs
to
know
here
my
destinations
that
I
know
with
a
name
or
IP
address
and
I
know
a
bit
for
each
of
them
so
I
just
or
these
bits
together
in
Ebola
I
got
my
beer
packet
and
the
case
of
beer
te.
We
pretty
much
have
the
same
thing,
but
instead
of
having
just
a
single
bit
for
every
receiver,
you
have
a
bit
string
of
the
path
to
the
receiver
and
then
you're
ordering
these
together,
and
that
gives
you
the
beer
tea
tree.
D
So
for
the
sender,
the
same
type
of
simple
operation
and
in
before
I
had
included.
These
type
of
you
know
independent
branches
type
of
calculations
from
the
controller.
If
you
have
something
like
Steiner
trees,
which
are
more
optimized,
you
know
the
sender
has
more
work
to
do
when
he
adds
or
remove
the
receiver,
because
the
whole
tree
changes,
but
in
the
normal,
shortest
path
type
of
routing.
We
have.
This
makes
it
as
easy.
So
there
was
the
the
missing
explanation
here.
Next
light,
I
think
we
might
be
yep,
and
that
is
the
end
right.
D
A
Please
do
I
mean
we've.
This
has
been.
You
know.
This
is
a
part
of
process.
I
got
a
bit.
Jeff
read
some
good
feedback.
Great
amendments
to
it,
I
want
to
make
sure
that
we
go
from
here
beyond.
Just
the
two
of
you
talking
right.
So
after
he's
got
this
edited
from
the
last
comments
that
were
on
the
list,
primarily
from
Jeffrey's,
so
to
get
the
conversation
going
again
will
restart
the
last
call
that
rolling
all
right
anyway
else
having
issues
about
that
dock.
Any
questions
about
that
dock.
B
Alright,
so
just
a
quick
recap
of
the
purpose
of
this
draft:
there
were
a
variety
of
v6
replication
using
beer
solutions
that
have
been
proposed
and
we
decided
that
it
might
be
best
to
come
up
with
a
problem
statement
draft
which
we
did
and
then
the
chairs
suggested,
as
the
working
group
disagreed
upon,
is
to
have
a
requirements
draft
first
in
this
requirements
draft
we
do
summarize
the
different
solutions,
but
it's
not
a
solutions,
draft
petition.
We
will
be
moving
that
to
the
appendix
and
there
are
variety
of
solutions.
B
There's
you
know
we
used
to
provide
that
be
six
replication
using
beer.
There's
beer,
Ethernet,
there's,
usually
that's
not
destination
options.
You
can
put
the
bit
string
in
the
destination
address,
there's
encapsulation,
there's
a
capsulation
encoding,
there's
a
variety
of
solutions,
and
again
we
put
that
in
there,
but
we
just
need
to
focus
right
now
on
the
requirements
and
that's
the
the
purpose
of
the
draft.
B
One
thing
that
we
could
well
one
thing
that
we
do
have
in
the
draft
at
the
very
beginning
and
this
something
that
we
talked
about
last
time
and
that
is
using
the
term
native
v6,
and
that
was
a
little
bit
of
a
discussion
last
IETF
and
we
still
have
it
in
there.
That
term
is
also
used
in
the
n°
bori
workgroup
charter.
So
maybe
we
as
a
working
group
need
to
decide
what
exactly
that
means
in
this
draft.
It
just
means
it's
not
encapsulated
in
Ethernet
or
MPLS.
B
If
that
needs
to
change,
then
let
us
know,
since
last
IETF
we've
continued
to
develop
the
requirements.
Section.
We've
created
a
github
repository
for
updates
to
this
draft
because
of
the
weirdness
going
on
between
the
US
and
China
right
now
the
governments
aren't
too
good
of
friends.
So
if
we
put
things
in
the
github
just
to
make
sure
everything's
in
the
clear
and
to
cover
a
basis,
we
have
removed
some
solutions
with
regards
to
pros
and
cons
wording,
we've
kind
of
gone
back
and
forth
on
this
as
well.
B
We
first
were
trying
to
stay
as
neutral
as
possible.
Then
it
was
recommended
that
we
do
provide
some
pros
and
cons
and
then,
in
this
latest
draft
we've
kind
of
softened
that
approach
and
just
let
the
solutions
dress,
do
their
own
justification
and
just
focus
on
the
requirements.
We
provide
a
little
bit
of
commentary
under
the
requirements
and
that
may
still
need
to
be
debated,
debated
a
bit
because
the
authors
are
proposed.
Do
you
have
their
names
on
one
of
the
solutions
dress?
B
My
name
is
on
two
of
the
solutions:
dress
and
and
Canada
to
fast
forward
a
year
from
now
really
right
now
we
have
two
drafts
that
are
being
actively
worked
on.
There's
other
surprises
as
well.
There
right
now,
there's
two
correct
me
if
I'm
wrong
so
for
the
next
Rev,
and
thank
you
Tony
for
your
comments.
We
will
remove
all
references
to
SRB
six
in
the
document
we've
agreed
to
that
because
it
was
not
helpful.
It
just
complicates
the
things.
B
Rajeev
has
been
telling
me
any
other
authors
to
move
this
loose
and
summary
to
the
appendix
for
some
time
and
I
haven't
listened
to
them
and
tell
me
how,
but
now
I
feel
em'ly
a
believer
and
we
will
move
those
solutions
to
an
appendix
they.
You
have
told
us
that
those
are
helpful
and
so
we'll
keep
them
in
there
just
to
give
us
summary
an
overview
of
the
different
solutions,
but
so
for
those
of
you
that
have
solutions
documents,
please
review
those
sections.
We
would
welcome
you
to
be
authors
on
this
draft.
B
Really
again,
our
goal
is
to
help
the
working
group
come
to
conclusion
as
outside
of
this
draft,
on
which
of
these
solutions
to
rally
behind
and
adopt
and
again
my
own
bias
and
conclusion
is
that
right
now
there's
two
solutions
and
I?
You
know
I
I
think
eventually
you
may
not
want
to
just.
We
may
just
want
to
work
on
those
those
two
solutions
and
tell
somebody
else's
solutions.
They
have
interest
in
working
on
them
next
slide.
B
So
these
are
the
requirements
we
have
12
today
and
we
will
need
to
further
discuss
these
on
the
list.
That's
what's
been
most
helpful
so
again,
thank
you,
Tony
and
kind
of
providing
some
feedback,
maybe
for
the
once
we
can
just
go
through
them.
We
can
just
go
through
a
real,
quick
stand
up
if
or
speak
up
yeah.
If
there's
a
if
you
have
an
issue
with
one
of
these
requirements.
B
One
thing
that
again
that
we
need
to
be
aware
of
is
that
we
have
these
requirements,
but
we
also
have
some
commentary
behind
the
requirements
and
the
commentary
may
sometimes
be
a
little
biased
as
I've
looked
at
it.
So
that's
where
we
have
to
be
careful
and
that's
where
having
other
authors
would
be
helpful.
So
as
an
example
the
first
requirement,
it
would
be
helpful
to
have
a
solution.
B
That's
agnostic
to
the
underlying
layer
to
data
link
type
that
doesn't
seem
to
be
too
controversial
and
just
as
an
example
and
I
won't
do
this
with
all
the
requirements,
but
like
the
beer.
Ethernet
solution
is
a
very
clean
solution,
but
it
it
is
not
agnostic
to
the
underlying
layer
to
Deerling
type.
So
when
you're
evaluating
that
particular
solution,
you
can
look
at
all
the
other
requirements
and
you
can
say:
okay,
it
maybe
provides
a
meets
all
the
other
requirements,
maybe
just
not
once
that's
something
that
they
work
group
will
need
to
evaluate.
S
So,
thank
you
for
decoupling.
There's
our
v6
I
mean
we
may
write,
know
the
hope.
I
hope
loophole,
that
you
can
change
it
right
on
v6
and
we
may
not,
but
it
does
nothing
to
do
with
v6
right.
Therefore,
2,
3
and
11
dead
leads
to
a
very
profound
discussion
on
in
beer
is
a
2.5
technology.
Okay,
it
doesn't
go
multiple
hops,
it
doesn't
do
fragmentation.
This
is
like
MPLS.
S
So
if
we
want
to
change
it
in
architectural
level
and
all
of
a
sudden
go
like
multiple
hops
right
and
preserve
source
addresses,
that
is
a
fairly
substantial
discussion
with
working
group,
because
that's
what
what
is
being
sneaked
with
those
requirements
where
I
should
use
words
I
mean
date,
those
requirements
kind
of
imply
a
multi-home
architecture
which
we
don't
have
so
even
the
beer
in
six
kind
of
allows,
jumping
multiple
hops,
which
is
like
a
hack.
You
should
not
use
but
may
be
helpful
if
we
go
along
those
requirements.
S
B
G
Yeah,
it's
generally
a
layered
2.50
solution,
that
is,
it
has
been
medically
in
there.
I've
said
eighty
to
ninety
six,
it
is
allowed
to
transport,
be
a
in
layer,
three
or
Lea
file
or
therefore
or
was
so
arm,
and
it
information
that
that
I
just
rated
the
texture
from
this
I've
said
the
action
can
be
welcome,
fragment
type
here
in
the
packet.
Then
the
procedures
of
the
sixteen
are
applied
in
sequence
through
each
a
fragment
fragment
this
assay
allows
the
fragmentation
has
considered
the
fragmentation
as
additional
function
to
be
a
true.
G
Is
it
from
there
I've
seen
also
I.
Think
I
want
to
share
some
background.
Why
we
think
else
resolution
is
required.
You
know
in
Heller
the
activate
it's
a
basic
service
for
hundreds
of
millions
of
subscribers
and
are
running
our
IP
networks
using
pin.
They
are
not
intended
to
use
early
layer,
two
point,
five
solutions,
neck
amperes
and
are
likely
not
to
use
it
in
the
future,
and
the
network
is
already
at
he,
basics
ready,
so
the
required
they
required
the
solution
for
all
the
benefits
of
beer.
So
so
that's
my
comment.
G
Q
B
There's
still
much
discussion
to
be
had
about
these
requirements.
We
should
do
so
on
the
list
and
I
continue
to
request
that
others
join
us
as
authors
on
this
draft,
so
we
can
make
sure
our
pieces
are
covered
last
slide,
which
is
the
next
leg,
so
we
originally
thought
we'd
be
done
by
this
ITF,
but
it's
apparent
to
us
that
there
still
need
to
be
some
work
done
on
these
requirements.
B
To
make
everybody
happy,
it
is
important
to
realize
that
our
solutions
that
we
rally
behind
are
likely
not
to
satisfy
all
the
requirements,
but
I
think
that's,
ok,
long
as
we
feel
like
they're
meeting
the
majority
of
them.
Please
continue
commenting
on
the
draft.
Are
there
any
other
questions
or
comments.
T
T
So
the
basic
idea
in
this
draft
I'm
just
in
case
that
someone
not
reading
the
draft
so
I
spent
some
time
on
this,
so
basically
we're
using
a
n
change
the
source
address
for
the
entire
flow
and
and
also
to
change
the
destination
address
by
using
the
neighbor
beer
router.
So
basically
the
principle
complying
with
the
requirements
in
Mike's
draft
and
we're
using
the
standard
beer
header.
So
that's
a
basic
encoding
thing
and
we're
using
unicast
address
in
sense
of
multicast
solution
so
that
you
can
basically
go
through
those
and
end
multicast
aware
note!
T
So
I'd
like
to
go
through
this
process
with
the
package.
So
if
you
have
a
packet
sending
from
a
so
you
use
them,
you
can
use
the
look-back
source
and
then
you
use
the
destination
address
of
B
and
and
and
then
for
the
node
between
a
and
B
non-beer
Walter
says:
oh,
this
is
a
pack
of
four
B's
unicast
and
then
we
fold
it
to
B
and
then
B
catch
the
pack
head
and
say:
oh,
that
this
is
a
packet
for
me
and
that's
actually,
beer
address
beer
destination
address
puppy.
T
A
450
is
three
so
beat
three
make
one
and
then
I
actually
in
calculate
the
source
or
destination
address
of
B
on
the
packet
as
well
and
then
sent
to
D,
and
then
he
can
drink
the
payload.
So
that's
basically
idea
so
you
will
use
the
extension.
A
header
do
h4
for
beer,
header
or
native
encoding.
So
it's
combined
with
the
architecture
asari
requirements.
Yes,
so
next
slide,
please.
T
So
the
few
upcoming
slides
is
really
the
you
know
list
of
the
requirements
that
we
think
we're
complying
with
the
current
requirement,
Draft,
so
I'm
not
going
through
in
details
just
this
one.
You
know
basic
architecture,
doing
the
not
changing
the
be
your
header
things
like
that.
Next
one
please,
and
so
this
one
there
was
the
discussion
of
recommendations
security.
T
T
So
yeah,
so
the
the
the
we're
actually
changing
the
destination
address
have
go
through
the
packet
flow
in
the
previous
slides
and
the
source
address
is
not
changed
by
hop
a
hop
and
that's
that's.
Let's
give
you
flexibility
of
also
receiving
the
notice
on
pain
of
trades
or
MTU
notice,
and
it
makes
things
a
little
bit
easier
if
you
want
to
filter
the
packet
using
source
address,
because
it's
it's
basically
the
source,
the
real
source.
T
T
T
Yes,
I
think
in
the
current
draft,
the
forum
in
terms
of
a
solution
I
think,
while
there
will
be
some
defect,
well,
not
be
that
but
the
room
to
be
polished
but
I
think
there's
no
heart
defect
for
the
solution,
so
we
think
in
a
form
of
a
solution
based
type
of
undrafted
squat.
Mature
we'd,
like
to
you
know,
ask
for
opinion
of
calling
for
a
working
group
adoption.
Thank
you.
I.
Q
U
H
Everybody
trying
to
peel
it
with
a
different
tool,
whether
it's
a
fork
and
knife,
it
doesn't
make
it
different.
I
guess
my
comment
here
is
that
sooner
or
later,
as
a
working
group,
we
need
to
come
up
with
a
with
one
solution.
We
do
not
want
to
make
unicast
mistakes
if
I
will.
So
what
what
I'm
seeing
here
is
it's
very
close
to
beer
in
six
draft.
That
is,
that
is
going
on
also
right,
so
I
wonder
whatever
we
can
kind
of
combine
these
drafts
or
work
to
combine
them
together.
H
So
that's
the
first
climate
and
the
second
part
is
what
what
you
brought
up
here:
the
security
aspect,
IPSec
etc.
That's
very
interesting,
so
we
mean
I
think
we
need
to
understand
whether
for
beer
we
want
to
entertain
all
these
letter,
ipv6
courts
into
the
beer,
including
security
IPSec,
because
I
can't
remember
free
IP
v6
if
IPSec
is
a
tunnel
mode
or
transport
mode.
So
all
this
stuff
will
come
into
play
from
encryption
point
of
view.
B
Like
the
bright
future
ways,
so
we
as
a
working
group
need
to
decide
if
we
want
to
start
entertaining
adopting
these
solutions
drafts
in
correlation
with
the
requirements
draft
or
do
we
need
to
wait
for
the
requirements
draft
to
become
more
mature
before
we
start
entertaining
solutions
drafts?
That's
the
first
point.
K
I
Cisco
so
drunk
encapsulating
the
beer
either,
as
is
right,
so
I,
don't
think
that
doing
that
in
an
extension
of
our
adds,
any
value
I
can
agree
with
Helmand
release
at
right.
So
if
the
beer
in
six
but
just
sort
of
removes
the
extension
header
so
that
I
don't
see
the
benefit
of
that
I
had
the
other
thing.
K
A
Q
U
T
I
mean
yeah:
we
can
discuss
that
offline
in
more
detail
and
just
an
emphasis
that
the
destination
address
playing
or
a
feud.
It's
actually
for
beer.
So
you
have
your
unique:
has
normal
packet
destination
for
each
of
the
beer
wilder
anyway?
So
that's
a
that's
a
a
standalone
playing
address,
pool
for
four
for
beer
packet.
So,
yes,
we
could
discuss
that
offline
for
OEM.
So
let
me.
S
Stop
in
we
are
dry
I,
don't
see
it
address
that
this
is
being
dragged
in
a
completely
different
or
he'll
check
are
in
textual
corner
of
the
world.
Okay,
you're
taking
a
two
point:
five
technology
and
try
to
extend
it
to
be
a
tunneling
technology
and
inventing
stuff
on
the
fly.
If
you
run
beer,
beer
has
a
full
o
a.m.
layer.
Okay
and
you
carry
a
PFR
ID
in
the
beer
frame
and
you
have
om
beats
and
we
have
everything.
S
This
please
needs
an
architectural
document
with
all
the
secure
implications
or
EMP
implications
and
so
on,
right
you're,
taking
that
to
a
completely
different
plane,
though
they're
the
little
details
of
what
this
note,
that,
if
modified
source
address
or
not,
are
not
that
relevant.
This
is
shifting
it
from
a
2.5
layer
to
complete
layer,
3,
tunneling
technology.
G
Hello
from
Hawaii
I
think
I,
help
gray
with
the
ramen
and
its
main
concern
maybe
like
that.
How
is
the
difference
of
two
solutions,
and
if
this
two
solutions
can't
combine
or
comma
G
same
case,
it's
possible?
There
is
only
some
differences
between
the
two
solutions
under
some
in
common
also
that
about
the
security
concerns.
G
It
is
also
valid
and
there
are
zip.
Eighty
to
ninety
six
have
been
very
wise
to
allow
that
a
over,
be
such
such
solutions
and
the
mention
to
that.
It
is
desirable
to
verify
the
package
things
from
a
legal
source
for
layer,
two
layer,
two
point:
five
miss
Maine
law
could
be
the
problem
and
mayor
three
or
up
its
have
this
problem,
and
we
have
the
space
using
this
best
special
at
at
he
destination
address
for
peer
for
the
only
and
the
don't
open
their
TCP
or
UDP
probing
for
this.
G
A
Close
on
time
will
take
this
to
threat,
but
I
want
to
encourage
constructive
comments
like
when
you
have
an
architecture
decision
you
made
right
there
and
you
said
may
be
helpful,
may
be
helpful,
is
not
a
part
of
a
contributing
argument.
Show
us
how
it's
helpful
and
then
we
can
have
a
conversation
from
there
right.
So
just
kind
of
look
I'm
going
to
sort
of
focus
our
conversation
around
an
editorial
just
because
I'm
here
this
first
slide
this
first
moment,
yeah
I,
know
what
you're
showing
here
was
helpful.
This
is
not
encapsulation.
A
S
The
blue
sheets,
well
I,
do
a
dilution,
so
one
clarification
I
mean
you
cannot
do
it
on
in
this
nation.
Here
that
you
have
to
do,
we
don't
I,
hope,
I,
hope,
Hatter.
You
can
only
change
the
hope.
I
hope
have
a
basics
architecture.
You
cannot
change
this
nation
header
in
median
helps
so
that
confused
me
just
as
no
it's
observation.