►
From YouTube: IETF105-BIER-20190724-1330
Description
BIER meeting session at IETF105
2019/07/24 1330
https://datatracker.ietf.org/meeting/105/proceedings/
C
D
D
D
So
you
guys
in
the
right
place,
beer
good
everyone's
looking
up
at
me,
smiling
I,
love
that
look
at
those
direct
eye
contact
minutes.
Please
someone
raise
your
hand
I
need
minutes.
We
can't
move
forward.
We
have
to
have
this
document
there's
always
discussion
after
about
who
said
what
somebody
Wow
look
at
that
eye
solid
on
the
keyboards
oh
come
on.
Is
that
a
response?
Is
it
you've
got
it
come
on
me
you're
good
at
it,
though,.
D
All
right
got
it.
I
know
people
get
a
lot
of
conflicts
that
people
leave
someone's
got
to
do
this
who's
not
presenting
today,
who
can
sit
there
and
do
all
my
usual
suspects
or
presenters,
hey,
you
think,
I'm
doing
minutes
yeah.
Thank
you.
Please.
We
need
someone
and
I
trust
you
completely
there.
It
is
all
right.
Jabber
scribe
is
someone
on
jabber
anybody
on
jabber.
We
have
no
one
on
jabber
either.
D
B
H
D
D
Anyone
recognize
this
guy
you're
supposed
to
be
our
jabber
scribe.
Oh
so
here's
the
existing
agenda
there's
been
a
lot
of
discussion
about
it.
Thank
you
guys
for
participating
through
here,
I
think
I'm.
This
one
we
got
in
there
and
then
we'll
have
some
good
discussion
here.
Moving
forward,
I
want
to
start
with
working
new
dock
status
because
I've
had
a
handful.
You
come
to
me
and
say:
hey
this
docks
ready
for
last
call.
D
What's
the
cue
what's
going
on
so
what
we
chose
to
do
with
four
or
five
documents
ready
for
last
call:
I
didn't
want
us
hammer
cuz
right,
we're
all
volunteers
for
time,
for
the
IETF
is
voluntary
right,
I
I,
don't
expect
people
to
respond
immediately,
but
with
a
two-week
window
at
least
say
yes
or
no,
let's
just
progress.
So,
let's
look
at
the
stats.
Okay,
we
had
cleared
our
IPA
cleared
in
February.
Still
waiting
for
a
shepherd.
I've
hammered
the
de
list
a
few
times.
D
Looking
for
shepherds-
and
we
don't
have
them
so
I-
do
have
someone
just
stepped
up
this
morning
volunteered
for
this
one,
so
I've
got
a
shepherd
assigned
for
that
and
we'll
move.
Let's
move
down
te
arc
for
people
respond
to
the
thread.
Saying
I
accept
this
as
a
word,
as
a
last
call
nobody
else,
we
can't
call
that
consensus.
I
can't
in
good
conscience
send
that
off
that
iesg
all
right.
There's
a
lot
of
people
participate
in
here.
D
This
is
significant
addition
to
the
overall
architecture
of
beer
at
ete
and
I
I
cannot
move
this
forward
lesson
good
review,
so
at
least
toilets
didn't
he
he
did
rev
it.
So
I
guess
there's
some
input
that's
taking
place,
but
this
is
where
we
are
I'm.
Gonna
start
it
again
after
this
discussion
he's
gonna
present
today
and
then
please
respond
and
that
we
can
get
some
and
that
response
could
be
know.
If
you
don't
think,
is
ready
for
last
call
if
there's
comments,
but
please
participate
otherwise
I'm,
not
certain
what
we're
doing
here,
all
right.
D
Does
not
speak
chef
he's
tried
and
failed
countless
time
shut,
the
door
shut,
the
door
turn
off
the
recording
devices
bTW
pls.
We
got
eight
responses.
That
was
good,
that's
on
the
high
side,
but
we
had
the
author
made
thirty.
First,
we
had
some
really
good
comments
about
the
document
itself,
which
kind
of
sat
dead.
I
tried
to
kick
him
a
bit.
July
12th.
We
actually
had
a
reply
to
the
doc
good,
so
some
practice
product
versus
make
is
moving
forward.
However,
I
think
the
comments
weren't
a
rev
because
there
was
some
Corrections.
D
There
was
some
clarifications,
so
I
would
like
to
see
that
revved
once
rather
than
and
submitted,
we
can
go
back
to
last
call
on
that
get
confirmation
and
get
a
Shepherd
and
we'll
move.
Em,
LD
and
PIM
signaling
are
both
just
sitting
in
my
queue.
I
was
just
kind
of
waiting
for
these
others.
Progress
before
I
take
them
to
the
list,
but
if
you
think
there's
something
we
can
celebrate
on
that,
we
can
move
forward,
something
listen
yeah.
I
B
D
B
I
K
D
D
Again,
sorry
for
the
conflicts,
this
has
been
a
kind
of
a
conflict
in
week.
I'm
gonna.
Take
it
to
the
list
again
to
just
ask
a
request
for
working
groups
that
we
have.
The
peoples
are
participating
in,
so
we
can
try
to
get
that
that
list
cleaned
up
all
right,
thanks,
Greg,
yes,
what
we
I
just
do
the
PDF
thing
rather
than.
L
L
L
L
But
the
idea
was
that,
basically
from
the
head,
there
is
nothing
to
do
so.
It's
only
dynamically
enabling
or
disabling
the
monitoring
point
that
I
think
that
it
was
addressed
over
I
suggested
to
add
operation
of
consideration,
section
it's
added,
but
it
might
not
be
up
to
level
because
the
question
is
outstanding
from
alvera.
Is
that
can
we
can
the
document
provide
more
specific
recommendations
in
terms
of
parameters
of
this
coloring
blocks
and
frequency
of
measuring
delay
and
purity?
Section
yeah,
Security
section
was
really
weak
and
just
plain
wrong:
I
apologize
for
that.
L
So
the
question
is
that
whether
there
is
a
integrity,
protection
and
as
far
as
I
know,
the
alternate
marking
method
does
not
have
integrity
protection.
Actually,
the
idea
and
go
of
alternate
marking
method
is
to
have
as
minimum
footprint
as
possible
as
I
mentioned
some
of
questions
and
comments
not
addressed
and
they
require
working
group
consideration.
Can
we
go
to
the
next
page?
Please,
oh.
L
No
yes,
yeah
open
delicious,
so
the
track
8321
is
experimental
and
experimental
it
for
the
reason,
because
Telecom
Italia
way
of
implementing
it
in
IP
they
used
space
of
differentiated
services,
called
pourraient
field
and
only
in
their
network.
So
basically
it's
non-standard
and
ipv4
doesn't
have
a
good
way
of
supporting
alternate
marking
method.
L
E
L
Okay,
my
understanding
is
that
I
want
to
inform
the
community
about
this
discussion,
even
though
the
discussion
was
in
the
mailing
list
as
a
summary,
because
I
don't
know
if
we
can
reach
the
decision
here
so
I,
it
would
be
great
if
we
can
reach
the
decision
here.
My
expectation
I
came
to
the
meeting
with
expectation
that
we
might
start
the
discussion,
but
their
final
decision
will
be
made
on
the
list
and
it's
probably
will
have
to
go
for
another
working
group.
West
called
that
I.
Don't
know
this.
D
Chef
as
chair
asking
my
boss,
man
over
there,
what
we're
producing
our
specifications
right,
the
requirements
talk,
is
often
I.
Look
it
as
being
a
working
document
for
the
group.
It's
not
always
needed
to
go
all
the
way
to
publications,
just
use
through
the
process.
So
if
there's
something
in
there,
we
need
to
reference
directly,
then
maybe
we
need
to
progress
it.
I
would
prefer
to
dress
that
in
this
dock
and
move
it
as
a
solution
right.
M
So
specific
to
that
comment,
that's
why?
Because
the
three
points
there
are
independent.
So
that's
why
I
was
asking
that
you
want
to
go
question
my
question,
but
when
I
was
reviewing
this
hey,
you
know
my
other
things
that
go
check
the
mailing
list
and
other
stuff,
and
that
I
follow
available.
Is
that
requirements,
draft
and
I
thought
well
this
one
that
it's
tried
to
solve
an
away
in
problem
doesn't
even
talked
about
the
requirements.
Raft
doesn't
even
say
there
is
a
requirements
raft
over
there
right
and
then
I
think.
M
Remember
correctly,
it
went
through
last
call
or
some
state
like
that.
So
my
question
too
great
I
think
was
you
know
what
is
relationship
now?
His
initial
answer
was
okay.
Oh
we
meet
requirements,
2
&,
4
or
something
along
those,
but
there
are
like
14
requirements.
So
of
course
the
next
question
is
well
what
about
the
other
requirements?
If
the
working
group
agreed
whether
we
published
the
requirements
document
or
not,
is
relevant,
but
if
the
working
for
agreed
on
a
set
of
requirements
for
OEM-
and
we
only
support
two.
M
N
M
D
Need
to
worry
about
so
again
is
chair.
Antonio
disagrees,
but
I've
often
looked
at
the
requirements.
Documents
is
something
to
keep
open
until
complete
its
trouble
in
an
OEM
case,
where
we
have
a
tool
that
solves
a
couple
of
them.
Knowing
it's
not
going
to
be
one
tool
solves
all
solution,
we'd
like
to
see
that
thing
progress,
but
there
may
be
requirements
that
come
up
along
the
way
they
get
exposed
that
we're,
because
we're
just
developing
an
architecture
and
starting
to
finalise
this
stuff.
M
Yeah,
that's
why
I
was
asking
what's
the
relationship
and,
as
you
said,
you
know
we
don't
necessarily
need
to
make
that
requirements
locked
in
an
RFC
when
you
say
keep
it
open
to
me.
It
sounds
like
you
can
keep
working
on
the
draft
and
sure
you
can
reference
the
draft
from
the
RFC
s
as
informational
and
that's
it
right.
The
draft
is
so.
E
Why
I
encouraged
the
requirements
on
the
OEM
site
initially
very
strongly
is
because
we
have
no
tradition
of
publishing
good
OAM
on
our
technologies.
Okay-
and
this
is
no
major
carrier,
stuff
and
I-
think
we
have
to
shift
this
culture
and
then
having
these
requirements
not
being
contested
because
there's
so
many
OEM
things
right
models.
What
you
could
do
could
lead
to
some
productive
work
rather
than
go
and
argue
once
you
know
a
couple
of
competing
OEM
things
have
materialized.
E
Now,
where
the
information
should
be,
the
requirement
should
be
published,
informational,
I,
don't
think
so,
because
you
have
a
good
template
to
go
and
beat
other
people
over
the
head
and
says,
like
that's
type
of
Oh.
Am
I
want
you
to
bake
into
the
next
technology
that
we
can
deliver
the
stuff
solid?
But
you
know
whether
you
see
any
value
in
that
on
alternates.
Our
job
is
to
deliver
and
carry
a
great
Oh
a.m.
with
beer
or
for
beer,
whatever
yeah.
So
that's
I.
E
D
M
D
Just
commented
that
a
bit
seems
that
may
be
more
of
a
semantic
argument.
I
mean
the
OEM
requirements
document
started.
First,
we
worked
from
it
developing
these
tools,
just
because
the
publishing
process
was
out
of
order
doesn't
mean
the
process
was
out
of
order
right.
It's
a
perception
and
says
from
the
ounce
that
I
made
look
like
that
happened
just
because
of
date
of
publication.
But
clearly
we
know
in
the
IETF
documents
did
begin
that
publication
date
right.
M
M
And
then
we're
gonna
have
you
know,
27
or
not,
27,
13
and
other
80s
abstain
of
the
document,
because
we're
republished
all
the
solutions
for
that.
So
I
think
that
I
would
rather
either
publish
the
requirements
at
the
same
time
of
the
solutions
or
if,
as
Tony
said,
there
are
requirements
outstanding,
there
are
left
for
the
future.
Then
we
can,
you
know
supposed
to
then
and
call
those
up
and
say
you
know
we
solve
all
these
things,
but
then
there's
there's
these
other
important
things
that
we
haven't
solved
there.
D
D
N
O
Is
a
you
know
not
helpful
for
furthering.
You
know
work
in
the
ITF
when
the
stuff
that
ultimately
people
are
referring
to
to
understand
why
the
heck
is.
Are
these
protocols
doing
all
these
crazy
things
are
is
seen
by
the
iesg
as
second-class
citizens
and
the
process
that
we're
doing
right
in
my
case
in
the
animal
working
group
was
also
you?
O
Sometimes
the
explanation
of
why
these
things
that
these
protocols
are
doing
are
needed
to
take
longer
than
actually
coming
up
with
the
protocols
themselves
and-
and
somebody
comes
oh
you're
too
late
right-
you
should
have
finished
all
these
requirements
in
detail
before
these
protocol
bits
were
developed,
I'm,
sorry,
but
I'm
on
completely
the
opposite
side
of
El
burro,
and
this
one
and
sorry
I
came
I,
told
the
second
I'm
not
I.
Haven't
read
this
I'm?
O
P
Than
we
gotta
move
this
Akbar
just
one
comment
from
previous
experience:
if
you
have
requirements
or
something
that's
requirements
like
people
might
object
to
classifying
that
as
informative,
because
by
its
very
nature,
it's
actually
normative.
So
again,
maybe
if
the
IDI,
you
know
supports
I,
think
it's
a
good
thing
to
what
the
ad
proposes
and
what
you
propose,
but
in
similar
circumstances,
we've
run
into
problems
when
they
went
to
IEC
and
they
said
well,
you
cannot
make
something.
That's
a
requirement
is
informative
because
it
goes
against
great.
M
The
reference,
so
you
can
get
away
with
both
now.
The
thing
is
that,
if
it's
normative
than
what
that
means,
is
that,
even
if
you
send
this
for
publication
now,
we'll
have
to
wait
for
the
requirements
we
publish
and
that's
equivalent
to
what
I
was
the
other
alternative,
which
is,
let's
publish
everything
at
the
same
time
right.
So
it's
the
crippling
either.
You
send
me
everything
at
the
same
time
or
you
send
me
everything
in
pieces
and
then
everything
gets
published
with
an
RFC
no,
but
at
the
same
time,
at
the
end.
D
O
Thomas
Eckert
so
again
it
for
a
normal
requirement,
stuff,
that's
kind
of
closed
and
seem
to
be
finished
for
whatever
it's
done.
Don't
think
what
I
wanted
to
say
is
interesting,
but
I
thought
that
Warren
had
this
thing
going
on
with
a
more
agile.
You
know
document
option
and
maybe
that's
something
so.
C
L
Only
what
it
defines
it
defines
interpretation
of
the
om
field,
which
is
a
part
of
beer,
MPLS
header.
So
there
are
couple
questions
out
of
this
comment
is
so
can
there
be
other
interpretations
of
om
field
or
only
once
that
will
be
defined
in
a
this
draft
and
even
the
protections
of
oil
filters
only
in
the
finest
is
then
draft.
L
Does
it
mean
that
this
draft
updates
there
RFC
eighty
to
ninety
six?
So
in
any
case,
I
am
a
consideration
section
dozen
is
not
needed,
because
if
there
could
be
other
interpretations,
then
they
do
their
interpretations.
If
it's
the
only
interpretation,
then
we
update
the
draft
in
Ayana
has
no
action
and
then
the
question
of
the
naming,
the
loss
and
delay
versus
single
and
double
marking
method.
E
M
That's
what
the
draft
says
right
now,
there's
no
way
to
discover
what
you're
doing
right.
You
configure
the
two
endpoints
and
you
interpret
the
bits
that
way
right,
and
there
was
a
question
because,
yes,
the
beer
header
has
two
bits
and
it
says
that
it
can
be
used
for
LeAnn,
but
doesn't
hate,
see
how
the
way
I
interpret
the
RFC
is
that
it's
open
to
the
OM
method
to
describe
how
and
then
you
agree,
but
the
way
this
draft
was
written
was
that
it
was
basically
taking
ownership
of
those
bits.
Yes
and.
M
This
question
to
the
working
group
is
that
the
interpretation
that
the
bits
can
be
used
by
any
method-
you
know-
and
it's
just
a
matter
of
configuration
or
discovery
or
something
or
is
the
intent
that
we
were
to
assign
those
two
bits
to
a
specific
mechanism.
And
if
yes,
then,
is
this,
the
mechanism
Quantrill
silencer.
N
E
D
Except
yeah,
listen
to
these
things,
so
good
points
came
up.
I
mean
we
should
highlight
those
from
the
minutes
and
I'll
bang
those
things
out.
Who's
got
the
minutes
again.
Where'd
he
go
there.
You
go
great
mm-hm,
okay,
so
we
have
to
go
to
last
call
again.
Yes,
there's
a
rep
yeah,
which
is
so
who's
read
the
current.
Rather
the
draft,
we
got
three
people,
four
people,
no.
D
N
B
A
Q
D
E
R
R
So
some
quickly
goes
through
the
basic
idea
of
peer
telling
it's
in
the
wrong
for
your
deployments
situation.
How
do
we
handle
incapable
routers
you
either
get
around
them
or
your
tunnels
through
them
in
the
left
picture?
It's
that's
where
we
get
around
them.
The
router
X
does
not
support
peer.
So,
even
though
going
through
X
is
the
best
pass
from
our
unica's
point
of
view,
because
that's
not
support
beer,
then
we'll
go
through
be
a
bar
to
even
though
the
cost
is
higher.
R
Imagine
that
okay,
so
because
there
is
no
animation
here
who
has
to
imagine
for
a
moment
that
would
be
fr.
X,
that's
my
exist
here
so
for
PFR,
one
will
need
to
tunnel
for
copies
of
the
packet
from
bf
bf
ir
1
to
p
FR
3
4
5
6,
respectively,
and
if
the
link
between
p
FR,
1
and
roster
X
does
not
have
enough
bandwidth,
then
you're
wasting
your
precious
bandwidth
on
those
replicas
copies.
So
the
solution
for
that
is
that
we
attach
a
beer
perhaps
to
to
the
router
X
with
a
local
fed
pipe.
R
Then
the
be
a
part
1
with
ton
of
the
package
to
the
B
FRX,
just
one
copy
and
then
be
our
FB
of
our
actual
panel
individual
copies
2
3
4
5
6
through
that
local
fed
pipe
next
slide.
Please
so
because
that
BRX
is
like
a
stop
router
there.
So
the
normal
six
point:
five,
a
six
point:
nine
procedure
will
not
how
will
not
work
so
to
make
it
easier.
We
do
some
additional
signalling
I'm
going
to
jump
to
the
alternative
method.
R
R
So
we
had
that's
a
simple
picture
there.
We
had
attached
that
be
FRX
to
the
to
the
Inca
router,
but
any
is
notice
that
some
bf
are
three
four
five
six
in
the
picture
they
are
connected
to
ax.
They
are
capable
beer
any
one
of
those
or
multiple.
Those
could
all
be
the
helper
2x
as
long
as
the
connection
between
the
helper
and
that
there
helped
its
fat
enough.
R
So
when
you
have
their
kind
situations,
they're
signaling
that
I'm
access
Harper
can
carry
a
priority.
So
that's
the
ones
with
the
highest
priority
is
used
as
helper.
You
could
even
have
multiple
ones
either
has
in
the
same
priority.
Then
all
those
could
be
used
in
other
situation
is
that
one
helper
could
actually
help.
Not
multiple
number
efforts
will
have
a
slight
later
for
that.
So
with
OSPF,
star
I
assess
signaling.
The
helper
needs
to
be
in
the
same
area
or
level
as
num
be
a
par
that
it
helps
that's.
The
OSPF
is
a
signaling.
R
So
you
may
have
some
concerns
on
possible
looping
situation.
You
may
get
into
what.
If
BFRO
and
tunnels
the
peer
packet
will
be
FRX
and
in
somehow
pfr
X
sends
a
packet
back
to
PFR.
Why,
especially
if
you
have
a
direct
angle
connection
between
VFR,
while
I'm
VFR
X,
so
there
are
some
simpler
scenarios
where,
if
you
have
a
dedicated
stop
helper,
that
does
not
have
any
other
connections,
then
you
you're
guaranteed,
not
working
in
the
loop
or,
if
you
have
helper,
that
has
other
connections.
R
For
example,
in
this
picture,
PF
rx
has
connections
to
be
a
power
5
5
&
6,
it's
no
longer
a
stop
helper,
but
in
but
as
long
as
the
upper
axe
does
not
have
connection
back
to
the
tunnel
ingress,
then
it's
also
fine,
but
you
may
say
that
it's
probably
harder
for
me
to
guarantee
my
topology
like
that
and
next
slide.
Please.
R
It
turns
out
that
it
can
also
be
guaranteed
as
long
as
you
do
as
your
SPF
calculation
niku.
Let
me
jump
jump
to
the
boat
and
slanted
text
there.
Basically,
in
this
picture,
pfr
1,
when
it
decides
whether
PFR
acts
can
be
used
as
a
helper,
it
just
as
a
SPF
calculation
with
the
PFR
PFR
acts
as
the
root,
even
if
it
realize
that,
if
somehow
be
a
power,
X
would
use
PFR
one
as
next
hop
to
reach
be
a
power
3.
R
Then
PFR
1
will
not
panel
Packer
to
be
a
4x
too
risky,
a
par
3,
so
that
extra
calculation
is
actually
no
different.
It's
the
same
as
the
extra
calculation
you
use
to
prevent
looping
in
the
OFA.
So
it's
the
same
idea.
In
fact,
you
can
view
the
tunneling
of
beer
from
beer
power
1
to
P
of
X
as
LF
a
protection
pass.
It's
just
now.
You
you
always
using
that
protection
passing
stuff
in
so
that
nature
pass
so
that
SPF
calculation
routed
pass.
D
Greg
independent
just
trying
to
follow
the
example
I
understand
what
you're
trying
to
do,
but
the
example
has
me
a
bit
baffled
and
I.
Don't
know
why
that
would
be
a
problem
here,
because
you're
going
back
I
mean
why
would
I
go
back
to
be
afar,
one
in
the
first
place,
if
the
bits
not
set
for
that
and
no
ingress
would
set
its
own
bit
coming
in
so
I
only
work
at
bfr.
One
was
the
path
through
X
back
three
and
four.
It
would
take
that.
R
D
R
It's
that
sum
I
think,
first
of
all,
or
the
metrics
there
may
be.
The
metric
is
not
the
rights
to
these
explain
the
problem.
This
is
imagine
that
PFR
one
send
a
packet
destined
to
be
a
BF
ER
3
to
be
a
power
X,
because
b,
FR
ax
is
the
helper
and
somehow
b
FR
x.
Does
its
calculation
realize
that,
oh
that
the
torus
PFR
3
actually
have
it
goes
through
the
FR
1?
In
that
situation,
then
yeah.
B
R
When
we
first
came
up
with
tethering
solution,
how
always
kind
of
nervous
that's
where
I
get
into
looking
and
with
this
I'm
actually
much
relieved
that
this
is
finds
it's
going
to
work
out
next
slide.
So
what
what?
If
you
have
a
situation
where
you
have
you
want
to
use
one
helper,
in
this
case
it's
BF
r,
XY
in
the
middle
to
help
multiple
non
capable,
incapable,
routers
x,
iy,
xn
y
here.
R
R
R
R
R
Now
VFR
3,
4
5
6
continue
to
advertise
those
bf
bf
our
prefixes,
to
be
FR
x,
ya,
to
be
a
power
x.
Now
this
time
you
will
change
the
panel
encapsulation
attribute
to
be
across
3
4
5
6
peer
predicts
that
were
there
with
that,
when
the
routers
on
the
right
on
the
left
side
send
them
beer,
packets,
with
some
kids,
be
said
for
beer
for
ER
three,
four
five
six,
they
were
just
simply
send
the
packet
through
the
PFR
three
four
five.
Six.
Now,
when
X
gets
that
advertisement,
it
will
advertise
reader.
R
R
E
R
R
There
are
two
options
to
signal
and
the
preferred
solution
of
signaling
is
to
edit
I
that
helper,
otherwise,
that
I'm
the
helper
with
that,
then
the
incubo
browser
does
not
need
to
do
anything,
which
is
a
good
thing,
because
in
most
cases,
if
you
cannot
do
PR
you
don't
you
would
not
want
to
upgrade
it
for
whatever
reason
a
software
upgrade
and
we
have
some
flexible
heathering
options.
You
can
have
stop
helpers
different
transit
helpers.
R
You
can
run
for
many
helper
or
many
for
one
helper,
and
we
know
that
if
you
do
the
extra
calculation
you
can
you
know
that
when
to
do
go
through
the
helper
or
not
next
slide,
so
we
continue
to
see
comments,
and
the
authors
also
believe
that
the
document
is
mature
enough
for
working
group
adoption.
So
we
want
to
that
request.
Yes,.
D
D
B
S
R
S
R
Call
it
proxy
yeah.
Yes,
it's
it's
proxy,
but
the
the
reason
we
don't
call
proxies
that
some
there
is
already
another
traps
with
the
proxy.
Is
that
it's
that
proxy
is
really
trapped?
It's
really
about.
So
you
are
realizing
beer
or
prefixes
across
areas
or
across
protocols.
Stat
rather
already
used
the
proxy
turn.
So
that's
why
we're
not
using
C?
Indeed,
it's
a
the
FRX
is
the
proxy
for
X
okay.
So
it's
going.
R
Bpf
for
the
helper,
that
does
not
keep
additional
information,
except
that
I
am
the
helper,
our
X,
that's
the
only
additional
information.
That's
bf,
Iraq
skips
that
way
when
the
when
the
FRX
does
is
calculation
knows
that
so
I'm
not
going
to
use
X
and
then
the
other
BFRs
they
also.
They
only
remember
that
pfr
x
is
the
helper
for
x.
S
I
So
most
of
the
examples
here,
I
see
only
one
router
that
cannot
do
that
is
not
beer
capable
and-
and
we
are
trying
to
get
around,
that
one
router
so
I'm
just
wondering
how
realistic
is
this
in
in
like
a
provider
network,
and
the
second
part,
maybe
would
be
the
same
token,
is:
let's
assume
that
now
that
one
router
becomes
a
cluster
of
a
router
like
a
ring
and
we
want
to
bypass
that
ring,
that
is
not
Bill
capable.
How
will
how
will
these
procedures
go?.
R
R
It
can
handle
tremendous
amount
of
unicast
traffic,
and
but
now
you
want
to
pierce
and
it's
not
just
not
feasible,
to
add
peer
support
to
those
routers.
In
that
situation.
In
in
theory,
you
could
attach
a
small
PFR
router
to
any
one
of
them,
and
then
you
can
just
do
the
tunneling
through
that
help
that
that's
in
theory.
R
So
you
can
just
pick
your
you
just
look
at
your
network
and
you
see
that
okay,
even
though
there
are
many
billion
cable
routers
there
I
could
attach
a
helper
for
every
one
them
or
I
could
just
simply
pick
a
couple
or
a
few
of
strategic
replication
points
attached,
help
more
help
there.
So
that's
one
way
to
do
it.
R
I
I
I
R
R
T
What
you
telecom
to
your
question,
how
relevant
this
is
as
a
co,
also
also
from
from
this
draft,
for
example,
in
our
network,
it's
it
is
relevant
if
you
think
of
the
brownfield
approach,
and
you
have
a
life
cycle
of
about
five
to
eight
years,
when,
once
you
renew
the
router,
we
have
done
the
calculation
on
our
end
and
we
see
that
we
have
some
relatives
in
the
middle
of
our
backbone,
which
will
not
be
being
capable.
So
the
question
is:
what
do
you
do
now?
I
Just
a
third
question
in
that
case,
like
there
are
two
scenarios
here.
There
is
a
tethering
scenario
and
there
is
a
scenario
that
we
go
away
from
the
non
beer
capable
so
going
away
from
non
Butte.
Get
all
that
that
completely
makes
me,
you
know,
put
a
router
that
is
pure
K
for
all
your
unicast
goes
over
the
one
that
is
not
there
and
your
multicast
goes
over
the
one
that
is
beer
capable,
the
one
that
is
for
title
tethering,
which
actually
tunnels
the
beer
through
whatever
LDP
sr
or
whatever.
R
Quick
comment
down
to
a
human:
if,
if
you
want
to
get
around
the
income
of
routers,
then
you
still
need
to
ensure
that
eventually,
you
have
a
connected
graph
for
other,
the
rich
or
the
B
F
ers,
and
sometimes
you
may
not
be
able
to
put
in
those
additional
connections.
You
can
put
a
router
in
there,
but
you
may
or
may
not
have
an
extra
fiber
or
connection
for
that
with
the
tethering.
As
long
as
you
have
a
local
fed
pipe
to
the
between
the
help,
rather
than
the
helped
then
address
will
just
work
out.
U
The
Sun
is
only
he.
My
question
is
I
just
admitted
the
newest
version
of
this
draft
and
I
found
that
there
are
two
no
two
type
of
node
is
defined
in
the
draft
helper
note
under
help
know
that
right
and
it
reminds
me
the
PTP
feature
for
grace
for
restart
and
the
only
the
node
who
will
help
to
other
know.
That
will
send
this
a
future
of
helper,
but
no
one's,
then,
is
a
helped
tutor
for
it.
So
I'm
just
wondering
if
we
should
define
only
one
type
of
it.
Just,
however,
not
helped.
R
R
U
R
The
thing
is
that
if
you
look
at
this
picture
here,
even
though
this
is
BGP
you'll
spoke
about,
this
is
about
BGP,
so
the
here
X
does
not
say
anything
and
pfr
one
following
the
existing
six-point-nine
procedure.
If
you
were,
you
will
realize
that
okay
X
does
not
support
peer.
Therefore,
for
PFP
are
three
four
five
six
I
will
have
the
tunnel
to
be
a
par
three
four,
five,
six
crossbow
Nene,
and
that
will
work,
but
it
does
not
work
well
because
PFR
one
needs
with
tunnel
for
copies
through
X.
R
Now,
with
the
additional
other
hidin
from
VFR
X
saying
that
I
am
helping
X
than
PFR.
One
will
say
that,
okay,
now,
instead
of
replacing
X
with
PFR
three
four
five
six
following
the
section
six
point,
nine
procedure
I
will
just
simply
replace
X
with
P
FRX
with
the
helper.
So
that's
the
that's
the
trick
here.
D
Behind
here,
so
you
did
the
neck
OH
I!
Guess
we
dressed
this
all
the
way
down.
The
other
question
is
to
address
this
so
I
in
the
discussion
where's,
the
DT
guy-
that
we
agree
on
whom
is
questions
as
well.
Maybe
an
example
that
shows
incremental
deployment
as
opposed
to
the
tail
end
of
the
deployment
right
like
I've
got
a
couple
modes
I
can
put
in,
and
the
majority
of
my
network
has
not.
D
How
would
this
tool
migrate
as
opposed
to
because
it
because
the
snare
is
like
one
lock
left
node
as
opposed
to
a
couple
of
EUR
nodes
and
everything
else
not
I
knew
was
that
would
that
be
like
a
valuable
human?
Would
that
be
valuable
to
the
to
the
draft
that
we
showed
that
incremental
deployment
is
supposed
to
like
the
tail
end.
R
D
I
think
clearly,
these
questions
are
coming
up,
so
if
it's
looked
at
as
being
transitional
would
show
that
path
would
be
all
right.
All
right.
Next,
I,
don't
get
out
of
this
I
found
the
button
so
I'm
making
progress
here,
oh
by
the
way,
I
just
found
this
slide
doomed.
If
you
have
PowerPoint
documents,
they
need
to
be
converted
to
Google,
slides
and
just
all
of
these
simple
instructions.
D
This
is,
but
this
was
at
my
desk
right
here
right
so
apparently
I'm
supposed
to
do
this
to
allow
you
to
animate
for
every
deck.
It's
just
let
you
know.
This
is
not
gonna
happen
up
here,
but
if
you
need
this
stuff,
maybe
we
should
all
go
to
Google,
slides
instead
and
then
we'll
be
a
quick,
quick
move
thanks.
All
right
next
is
signaling
over
beer.
This
is
ml
DP,
not
ml
d.
I
did
the
same
thing
of
a
mailing
list.
When
I
saw
the
the
requests
come
up.
I
There
one
letter
difference
between
them,
so
this
is
the
second
try
for
the
MLB
signaling
over
beer.
The
previous
draft
that
we
had
I
think
there
were
some
concerns
about
the
way
that
the
signaling
was
down.
So
we
retrieved
it
and
here's
a
new
way
of
doing
it,
that
the
main
problem
is
the
same
right.
So
we
are
trying
to
segment
of
the
network.
I
I
Excuse
me
with
minimum
disruption
or
software
upgrade
on
these
legacy.
Multicast
networks.
So
next
slide,
please
so
now
the
way
that
we're
gonna
do
this
is
via
RFC
7060.
We're
gonna
try
to
connect
the
two
ml
DP
Islands
together
over
the
beer.
We
are
signaling
TL
DP
through
the
beer
core,
so
literally
you're
gonna
be
seeing
the
TL
VP
packets
on
the
beer
core
they're,
not
being
tunneled
or
anything
like
that
tree.
I
One
thing
you
gotta
keep
in
mind
is
that
usually
MLBPA,
as
everybody
knows,
is
in
a
d:
u
mode
with
the
TLD
P,
it's
gonna
be
downstream
on
demand,
meaning
that
I
PBR,
when
it
gets
effect
from
the
from
the
receiver,
will
actually
ask
from
the
label
from
the
upstream
router
and
of
a
stream
router,
which
is
the
egress
bbr
pH
router
will
assign
that
label
to
the
to
the
downstream
router
next
slide.
Please
so
from
procedure.
Point
of
view
again
on
the
ib
b.
I
So
those
procedures
on
the
IP
BR
will
actually
identify
the
egress
beer
router.
Now
the
egress
B
router
again
it's
the
last
router
that
supports
beer
B
floor.
The
root
note
on
the
point-to-multipoint
LSP.
Next,
our
next
slide,
please
so
on
the
ebbr
on
the
BBB
are
basically
the
procedure
is
when
these
facts
arrive
from
the
IBB.
Are
the
ebbr
needs
to
track
all
these
facts?
The
reason
that
it
needs
to
track
the
facts
is
for
the
same
facts.
I
So
there
are
multiple
ways
of
doing
that,
but
we
feel
that
that
assignment
needs
to
be
unique
throughout
the
entire
beer
domain,
and
that's
why
the
draft
MVP
an
EVP,
an
aggregation
label
which
uses
like
unique
upstream
label
assignment
it
will
come
in
handy
in
these
procedures
are
also
so
next
slide,
please.
So
when
it
comes
from
the
other
pad
perspective,
as
when
the
packet
comes
back
from
the
root
with
the
MPLS
label,
it
arrives
on
the
ebbr,
the
ebbr
will
do
a
swap
with
the
label
that
it
has
assigned
for
all
the
downstream
labels.
I
With
the
same
token,
it's
going
to
look
at
all
the
PFE
ours
that
are
interested
in
this
fake.
Based
on
that
information,
it's
gonna
push
the
beer
header.
On
top
of
it,
we
are
thinking
that
the
beer
header
protocol
prototype
protocol
should
be
an
MPLS,
so
the
BF
ER
can
identify
that
beer
packet
as
an
MPLS
payload
and
actually
removed
the
beer
header.
Look
at
the
MPLS
label
underneath
do
a
swap
with
the
label
that
is
relevant
on
the
leaf
domain.
I
D
V
Okay,
so
so
this
was
an
update
to
the
micros
overlay
for
adaptive
streaming
services.
Since
the
last
idea
of
104
we've,
you
know
we
have
a
use
case
of
expanded,
comes
to
the
next
one.
We
ever.
The
the
trough
shows
the
reference
architecture
and
the
realization
of
the
multicast
overlay
in
over
IP
MC,
but
also
over
beer
as
a
comparison.
V
The
details
that
we've
changed
compared
to
the
previous
version
is
that
we
added
a
second
category,
so
we
focus
initially
on
the
HTTP
based
streaming
use
case
where
we
added
a
description
of
in
there.
I
guess
that's
the
realization
in
one
of
the
examples,
but
we
also
added
another
use
case
for
HTTP
based
software
updates.
That's
been
added
in
the
new
version.
V
Just
have
two
different
categories
of
HTTP
based
services,
and
we
also
added
an
enhanced
the
security
considerations
to
address
a
comment
from
the
Beavers
ITF
on
the
HTTP
based
exchanges.
So
since
either
the
the
certificate
handling
is
being
included
in
that
section,
these
are
really
the
changes
since
the
last
time,
so
next
steps
is
well.
D
Read
the
draft
in
its
current
form,
you're
an
author
all
right
who
thinks
it's
ready
for
last
call:
yeah
I
get
soft
response.
Couple
hands
went
down,
we
can
listen.
Let's
take
you,
the
lists
open
thread
and
yeah
again
going
last
call
is
often
just
a
stick
in
the
nest
to
get
you
read
it
and
respond
right,
so
I'm
gonna
put
it
in
the
queue
with
these
I've
got
going,
but
we
need
to
respond
to
this
week
in
progress.
Okay,
thanks.
Thank
you
very
much.
Q
O
O
So
this
isn't
working
group
last
call
you
heard
the
working
group
chair.
Please
read
it!
Please
provide
feedback.
We
really
want
to
get
it
out
to
ISJ
right,
just
few
more
voices,
and
so
we
thought
that
we
read
it
ourselves
that
some
of
the
past
comments
were
this
is
of
obviously
it's
somewhat
difficult
technology,
so
we
added
text
to
a
better
I
think
get
started
in
reading
it
in
the
beginning,
so
next
slide
so
improve
the
abstract
right.
So,
basically,
even
though
we
introduced
beauty,
obviously
everybody
knows
what
traffic
engineering
is
no
and
of
perfected.
O
Stateless,
strict
and
loose
path,
engineer,
replication,
forwarding
right
using
peer
packets,
call
that
beauty,
the
basic
examples
I'm
going
to
show,
and
then
basically,
we
edit
how
this
topology
think
that
the
basic
example
show
comes
into
picture
in
the
architecture
and
then
also
for
people
coming
from
this
world
of
segments
routing.
You
know
trying
to
find
some
way
on
how
to
upsell
beauty
to
them
in
their
terminology.
Okay,
so
this
is
the
basic
example.
Right
is
the
first
one
on
this
slide
is
showing
hop-by-hop
native
so
to
speak.
These
are
all
layer.
O
Two
adjacencies
forwarded,
you
see
the
full
be
ifts
of
all
the
routers
and
then
the
text,
one
page
or
so
walks
through
the
forwarding
of
an
individual
packet.
How
each
bloody
bits
does
its
work
at
each
other.
So
next
slide
same
thing
overlay.
So
basically,
we've
removed
two
of
these
routers
from
beer
they're,
not
beer
capable
so
now
you've
got
forward
routed
adjacencies
before
between
the
four
remaining
ones.
Comparison
also
how
the
bits
react,
and
basically
those
are
the
two
type
of
you
know:
extreme
beauty,
topologies.
We
can
think
of
a
native
one
and
overlay.
O
You
can
have
any
combination.
That's
what
the
examples
in
this
new
introduction
part
say
so,
and
that
basically
means
in
the
in
the
architecture
paper.
It's
really
the
beauty
controller
host
read/write.
So
the
controller
discovers
the
network
topology
and
out
of
that,
it
creates
whatever
thinks
is
the
best
beer
to
eat.
Apology,
overlay
native
combination
and
the
rest
is
obviously
all
was
already
there,
but
this
particular
piece
of
explanation.
Hopefully
you
know
few
more
people
reading
it
with
this
new
text,
understanding
it
saying
great
right.
So
that's
what
we're
trying
to
do.
O
Please
last
light
right,
so
then,
oh
there
was
the
word
Tecna
drought.
We
missing
in
the
in
the
title
here
on
the
slide:
sorry
so
yeah,
so
basically
the
be
peace
in
in
the
sense
of
segment.
Routing
can
really
be
seen
as
equivalent
of
forwarding
segments,
except
that
you
can't
take
a
bit
position.
You
know
and
think.
Oh
it's
a
global
thing.
I
can
send
from
it
from
anywhere
because
the
whole
trick
of
how
to
steer
things
through
it
is
that
only
you
know
the
adjacent
nodes
have
this
bit
and
replicate
to
it
right.
O
So,
basically,
maybe
in
this
terminology
we
call
these
beer
te
bits,
adjacency
scope,
forwarding
segments
right
so
I
mean
it's
just
more
food
for
thought
on
how
you
see
it.
I'm
also
saying
that
SRK
naturally
be
combined
with
beer
te
and
help
to
optimize
it
right
when
everyone
is
deal
without
replication,
SRS.
Fine.
The
whole
point
of
beer
te,
of
course,
is
to
steer
and
replicate
right
and
then
the
last
one
which
I
think
more
people
from
just
the
beer
side
may
have
an
opinion
about.
O
Is
that
you
know,
you
can
also
see
that
here
itself,
you
know
kind
of
just
destination
sit
with
a
fashion
replication
right
instead
of
having
a
long
list
of
egress
it's
in
a
packet
and
replicating
on
that.
Well,
every
set
is,
you
know,
compress
to
one
bit
so
that
was
kind
of
you
know
this
can
all
be
removed
if
people
don't
like
to
be
compared
with
us
are
right.
This
we're
just
hoping
it's
helpful
to
bring
people
to
beer
and
that's
it
the
end.
D
Let's
take
that
delicious
of
the
response
we
took
this
to
a
last
call
before
we
had
to
people
said
it
was
ready
for
last
call,
but
we've
wrapped
since
cleaning
some
things
up
from
response.
We
can
start
the
timer
again
make
sure
the
minutes.
Note
that
I'm
going
to
take
a
vote
who
thinks
it's
ready
because
we
thought
we
were
before
what
we
need
if
people
who
are
ready
to
read
so
please
participate
alright.
Next
after
tortoise
is
dig.
K
K
Currently
we
are
saying
that
the
source
address,
so
the
MLD
or
or
RMP
messages
is
the
beer
prefix,
and
we
use
that
to
figure
out
the
B
Friday
or
the
sender
and
subdomain.
We
completely
figure
out.
We
just
said
it
has
to
be
configured
in
some
way
or
you
can
use
multiple
instances
as
it's
discussed
in
the
draft
and
you
could
say
for
a
certain
destination
address.
We
assume
a
certain
subdomain
anyway
in
pema,
decided
that
we
wanted
to
use
that
John
attribute
to
explicitly
specify
the
be
Friday
and
subdomain
and
so
on
out
there.
K
Oh,
the
join
sender
instead
of
relying
on
this
and
the
question
is:
should
we
do
something
like
that
for
our
EMP
MLB
overlay,
that
the
issue
is
that
tip
typical
implementation,
at
least
some
implementations?
When
you
parse
the
RMP
remedy
packet,
you
don't
have
access
to
the
deBeer
header
that
could
tell
you
who
sent
the
which
beavers
sent
the
join
message
or
origin
PM
le
report.
So
one
option
is
to
say:
they'll
just
go
with
what
we
have
it
works.
K
It
just
makes
some
assumptions
on
the
source
address
and
configuration
and
stuff,
or
we
could
potentially
delay
this
draft
further
and
do
some
work
on
extending
the
item.
Pm
LD
messages
to
include
this
information
I
would
say.
Normally
it's
a
non-starter
to
modify
our
EMP
or
Emily,
but
these
messages
only
sent
or
received
by
beer
routers.
So
it's
not
like
any
modifications.
Any
many
existing
implementations
also
maybe
a
bit
for
a
background
in
the
RMP
worsen
3ml
ever
since
your
RF
sees
it.
K
K
K
I
K
I
think
that
I
would
imagine
yeah
yeah,
that's
so
assuming
that
that
is
not
possible
where
it
is
very
hard,
then
you
only
have
two
options:
either
we
just
say
used
to
be
a
prefix
get
the
B
Freddy
from
that
just
sort
of
getting
subdomain
by
configuration
or
the
other
option
is
extending
our
EMP
MLB
messages
themselves
and
yeah
I'm,
just
yeah
curious.
So
people
think
about
this
I'm
kind
of
agnostic
myself.
It
could
be
nice
to
include
that
extra
info.
K
B
I
K
And
I
guess
one
question:
if
you
want
to
do
this
for
our
GMP
MLD,
is
it
worth
publishing
what
they
have
now
and
say
this
works?
And
then
you
know,
do
some
kind
of
update
to
a
new
draft
later
with
that
extension,
or
should
be
rather
wait?
The
problem
with
the
problem
in
what
I
just
said,
though,
is
that
implementations
may
have
to
deal
with
two
different
ways
of
doing
things.
So
maybe
it's
better
to
wait.
Yeah.
R
K
So
so
maybe
we
should
check
on
the
list,
but
if,
if
people
agree,
am
I'm
happy
with
what
Geoffrey
said,
if
people
agree
with
that,
then
it
means
he
won't
be
lost
its
call.
Yet
we
need
that.
It
may
actually
need
to
go
back
to
the
pin
working
group
and
talk
a
bit
about
what
is
the
best
way
of
doing
this
kind
of
extension,
origin,
PM,
LD,.
U
Good
afternoon
I'm
sanna
Dom
from
the
key.
This
furnishing
is
for
purely
ipv6.
We
have
caused
our
pony
eyes
and
many
people,
so
we
know
who
the
horrible
bag.
Let
me
read
it:
let's
see
the
advantage
of
beer,
we
know
that
here
can
achieve
multicast,
I,
hope,
I,
hope,
forwarding
and
op
c
8h
tools.
96
defines
to
bear
encapsulation
ways,
I'm
sure,
an
anonymous
and
from
it
we
know
that
a
new
internet
type
for
peer
is
defined,
and
if
we
want
to
use
peer
forwarding
in
ipv6
situation,
we
can
use
the
native
Ethernet
packet
forwarded.
U
But
we
know
in
many
networks
the
reorganization
of
the
new
Ethernet
cable
for
peer
cannot
be
supported.
So
we
he
find
a
general
and
a
simplest
way
to
achieve
the
beer
foreboding
king
ipv6
situation,
and
so
we
just
introduced
a
new
protocol
and
you
can
call
it
a
new
header
in
ipv6
frame
and
it
can
achieve
the
fast
forwarding
paths
and
so
sort
of
their
forwarding
paths.
Multicast
forwarding
and
in
order
to
receive
the
ipv6
encapsulation
pure
package.
Rotor
must
advertise
appear,
ipv6,
encapsulation
transportation,
stop
Shelby,
it's
a
very
simple
sceptre.
U
U
Because
the
extension
fool,
ipv6
header
is
very
simple,
so
let's
see
the
other
fields
in
ipv6
header
for
directory
connected
neighbor.
We
know
that
the
destination
address
should
be
the
neighbors
link.
Local
address
and
the
source
address
should
be
the
rotors
link
local
address.
But,
as
we
all
know,
we
can
defend
the
local
policy
on
the
router,
but
we
can't
keep
the
source
address
unchanged
it
on
the
other
policy.
So
we
can
make
a
great
make
many
changes
for
it
and
an
Arab.
Of
course.
O
U
You
can
use
these
ernet
or
so,
but
you
know
that
some
chips
will
not
support
the
record
nursing
of
the
either
new
user
data
type
right.
So
we
can
use
these
ipv6
extension
to
achieve
peer
forwarding
so
be
our
character
will
be
the
payload
of
the
ipv6
header
and
you
can
do
hope,
I
hope
forwarding
to
achieve
multicast
well.
O
O
E
Because
I
didn't
say
this
is
just
I
think
we
I
think
I
think
we
spelled
it
out
in
the
draft.
The
primary
intended
use
is
towards
home
net,
which
means
you
have
v6
chips
which
you
cannot
modify,
but
you
don't
need
a
high
throughput
right.
You
could
be
on
the
fast
path,
for
it
go
look
behind
a
ipv6
header
and
process.
E
O
E
O
E
E
O
E
Yes,
but
that's
just
unintended
consequence,
which
is
the
strongest
force
in
universe,
so
it
was
intended
to
be
purely
hop
by
hop,
but
of
course
you
can
go
multiple
hops.
All
of
a
sudden.
You
don't
have
to
build
tunnels
right.
You
can
just
use
v6
to
jump
over
stuff
yeah,
but
that's
unintended
consequences.
A
O
O
E
E
F
K
E
U
D
The
third
Rev
it
is
Zhang
beer,
so
its
current
name
is
not
an
adopted
draft
all
right,
it's
not
wearing
the
document.
Yet
it's
not
yet
a
working
group
document,
it's
just
it's
not
adopted
as
a
draft
for
the
working
group.
Yet
right,
yeah,
that's
I'm
till
checking
status
before
I
did
that
those
are
just
confirming
with
you
and
my
name's.
I
got
here
so
who's
read
the
draft
in
this
current
form.
D
U
U
If
this
domain
is
beardo
man,
you
know
that
the
ingress
router
we
call
it
a
BF
iOS
will
advertise
sourcing
information
to
all
the
BFE
eyes
and
the
egress
router
will
select
the
router,
which
he
thinks
is
the
prevail.
Priors
and
rotor
is
the
upstream
multicast
hope
and
the
signals
to
the
selected
via
fire.
So
in
this
picture
picture
we
know
that
and
the
PFA
Yahoo
will
receive
the
advertisement
from
VFR
1
and
V
F
IR
to
and
from
the
local
policy.
U
If
ya,
maybe
it
will
choose
B
F
IR
one
is
H,
so
BFA
Yahoo
will
signal
to
the
BFI
R
1
to
get
the
multicast
flow.
When
the
selected
BFI
affairs
in
this
picture,
we
suppose
that
the
PFR
one
field,
the
pfayetteville,
will
choose
the
p
fi
r
2
s,
the
h
and
a
second
or
two
it
from
it.
We
know
that
the
sooner
of
the
Vav
architects,
the
failure
of
the
UMS,
the
quicker
the
multicast
flow
recovers.
U
U
If
a
yeah
ii
can
send
the
periodical
ping
packet
to
the
selected
umh
in
this
picture
is
be
a
fire
one,
so
P
available
and
should
reply
to
be
fer
to
the
ping
packet,
so
P
fer
to
will
monitor
the
status
of
PFR
one
and
also
the
be
a
Fiat.
You
can
monitor
the
past
status
from
VFR,
one
to
be
a
via
to
FB,
a
Fiat
who
can't
receives
a
reply
from
the
behaved
one
for
a
period
of
time.
U
The
PFA
Yahoo
will
treat
the
PFR
one
is
a
failure
load
and
it
will
second
node
to
the
PFI
r2
to
receive
the
multicast
flow
and
in
order
to
achieve
the
its
goal,
the
S&P
ping
or
the
ping
defining
the
airplane.
Draft
can
be
used
here.
But
there's
problem
in
this
solution.
If
the
path
from
the
BF
ER
to
the
selected,
the
umh
is
different
from
the
past
from
the
umh
to
the
behavior.
In
this
example,
we
can
attach,
if
the
past,
from
PAPR
to
to
be
FR,
one
is
different.
U
From
the
past,
from
b
FR,
one
to
BF
ER
to
the
ping
packet
ER
may
result
to
an
incorrect
result,
because,
if
the
p,
the
past
from
PFA
year,
two
to
be
fi
are
one
hell
is
broken.
The
path
is
the
path
of
ROM
BF,
our
one
to
be
fer
two
is
good,
but
as
a
ping,
packet
er
will
not
be
received
by
be
fr.
One
comment.
U
U
U
U
U
K
N
U
U
Yes,
next
piece:
let's
see
the
second,
the
solution,
the
BR
PFT,
it's
defending
the
RPG
dropped,
and
so
we
know
that
the
in
this
solution,
the
universe
router,
will
sense.
The
periodico
us
today,
the
periodical,
p2
and
ppfd
control
package
to
all
the
bf,
yes,
which
is
select
itself
as
the
edge,
so
the
egress
routers.
In
this
example,
we
know
that
the
we
suppose
that
the
BFE
i1
+
PF
e
r2,
+
b,
f
r3,
all
choose
the
b.
U
Fr
1
is
the
edge
so
PF
our
one
will
send
the
periodical
feed
from
ppfd
package
to
all
these
three
routers.
So
if
somebody
ahhhhh
in
this
picture,
we
suppose
that
bf
yah
one
cannot
who
receives
a
packet
from
if
I
are
one
and
the
reason,
maybe
maybe
the
BFF
IR
one
has
failed
and
the
other
reason,
maybe
the
past
from
I
want
to
be
a
Fiat
who
is
broken
so
BAV
yeah.
What
can
choose
the
be
fio2
is
umh
and
the
second
or
two
here
and
so
again
this
function.
U
We
we
can
use
the
pure
ping
packet,
a
defender
in
burping
draft
to
bootstraps
the
people
and
PPF
decision.
So
this
is
a
easy
way
and
the
earth
and
the
past
from
the
egress
ingress
router
to
the
egress
router,
is
the
same
with
multicast
flow.
So
there
is
no
problem
that
will
cost
by
the
PRP.
Just
we
mentioned
in
master
slides
this.
D
Is
a
great
question:
is
there
a
reason
why
you're
not
running
BFD
between
both
Canada
B
I
thought
from
both
Canada
B?
If
IR
s
down
to
the
B
F
ers,
it
sounds
like
you
just
have
the
BFD
running
on
one
case
and
when
the
detection
is
failures
detected
you
have
to
then
not
only
reelect,
but
then
re-establish
a
VFD
relationship
and
begin
that
process.
It
seems
it
would
be
more
expedient
to
have
that
running
between
both
and
then
you'll
know.
U
J
U
So
we
think
that
if
the
ever
the
truth,
bf4
is
sending
the
packet
to.
U
U
I
just
mean
that,
because
in
this
feature
we
know,
that's
the
beer
for
our
one
is
primary
standing
petted,
but
maybe
BFI
are
to
respond
stirred
for
some
other
people
for
the
Eau
de
Caza
forwarding
right.
So
we
have
our
1
concern.
Does
a
karateka
be
FDA
packet
to
the
be
fer
one
to
be
a
yes,
yes,
read
and
the
BFI
are
two
can
send.
Also
the
the
chillin
EF
de
pocketed
to
the
other.
The
FA,
yes,
which
selected
his.
D
You
jump
to
an
application
of
it
or
but
I'm
thinking
more
just
from
a
protocol
design
operational
decision,
the
EFI,
the
B
F
ers,
decide
which
be
if
I
are
mm-hmm.
Okay,
so
if
they're
deciding
they
need
to
know
whose
all
there
they
didn't
know
the
liveness
of
all
of
them.
That
are
there
right.
So
it's
almost
like
you're
making
you're
letting
them
decide
and
then
you're
making
them
tell
me
if
I
are
what
they're
going
to
do
to
detect
the
liveness
it
be.
D
D
Then
then,
you
can
know
if
I
have
a
double
failure.
If
a
BFD
died
on
one
I
try
to
re-establish
another
one,
I
I
am
assuming
it's
there.
It
may
be
gone
as
well.
They
make
the
filler,
maybe
somewhere
else
right
or
between
the
two,
so
I,
just
it's
it's
noise
in
terms
of
messaging
and
the
state
machine
already
has
to
be
ready.
It
seems
to
be
a
more
efficient
process
if
we
just
let
them
communicate
all
the
time.
D
That
detecting
my
neighbors
to
begin
a
process
is
not
really
expedient.
Once
I
have
my
neighbors
and
I
want
to
elect
between
them.
That's
much
quicker.
I
need
be
on
top
of
that
stuff.
So
is
there
a?
Is
there
an
example
within
application,
the
uses
of
BFD,
where
I'm
not
just
doing
point-to-point
liveness
but
I'm
doing
a
redundancy
comparison
like
this?
That's
if
we
take
an
existing
mechanism
using
VFD,
that's
not
beer
related
that
looks
like
this.
We'll
just
you
know.
We
then
we
have
some
precedence.
Geoffrey's
got
an
answer:
okay,.
R
R
And
another
question
here:
is
that
with
fear
supposedly
the
unica
safe
are
utilizing
will
be
used
and
then
you
can
quickly
switch
over
to
the
backup
pass.
So
most
likely
your
traffic
will
recover
very
quickly
and
now,
when
you
use
this
PFD
or
PM
to
decide
to
switch
to
the
backup,
be
a
PI
R
I,
wonder
you.
If
that
switch
over,
would
take
a
longer
time
for
your
beer
traffic
to
recover
with
the
original
efi.
Are
the.
U
R
Right
so
the
first
of
all
teat
a
PFD
for
the
DFT
to
detect
that
you
have
a
problem
that
takes
time
and
then
you
send
a
signal
into
the
back
happy
if
IR,
that
takes
some
more
time,
so
I
wonder
by
the
by
the
time.
All
this
detection
and
switchover
her
request
happens,
the
the
the
original
that
the
traffic
from
the
original
P
Farr
may
already
have
recovered
on
the
back,
half
pass
I'm
just
curious.
If
that
could
be
the
case,
you.
K
Figure,
yes,
I
agree
with
that
comments.
If
there's
a
link
failure,
you
might
be
able
to
route
around
it
and
you
may
not
eat
it,
which
ingress
router
is
forwarding.
What
you
may
be,
he
do
is
do
some
kind
of
forwarder
election
though,
and
do
BFD
between
be
if
I
are
one
and
two
and
if
one
of
them
goes
down
and
the
other
one
takes
our
SS
forwarder.
If
you
imagine
that
you
actually
join
to
both
both
the
bf
IRS,
but
only
one
of
them
will
send
your
data.
K
U
K
N
T
Neil's,
just
as
a
extension
to
what
Jeffrey
and
stick
just
said,
what
are
you
trying
to
cover
when
you're
trying
to
cover
a
node
failure?
I'm,
not
sure
if
this
is
the
right
mechanism,
if
you're
trying
to
cover
the
link
area,
then
the
underlay
is
probably
quicker
to
detect
it.
Then
then
you
can
do
with
a
in
the
overlay,
because.
U
T
D
T
T
D
D
D
Me
the
failure
could
be
not
just
it
could.
I
have
a
route
to
it.
Just
fine!
It's
not
moving
packets
networks,
link
behind
it's
failed
and
that's
not
going
to
be
a
my
GP
I'll,
never
know
exact
as
a
BF
ir.
Yes,
that's
different
than
its
down
right.
So
that's
route
to
it.
It's
not
gonna
be
detection.
Okay,.
U
D
Just
a
cloud
picture
right
there.
Yes,
this
is
great
discussion.
I
think
we
need
to
really
consider
all
of
the
failure
scenarios
to
be
kind
of
interesting
to
to
break
those
down
and
see
what
we
have
in
terms
of
solutions,
what
problems
they're
addressing
and
maybe,
if
there's
some
open
problems,
but
who's
read
the
draft.
Currently,
all
right
and
I
don't
believe
it's
adopted
right.
It
is
still
an
independent
craft.
D
Okay-
and
you
think
this
is
kind
of
work
we'd
like
to
adopt
in
the
working
group,
I
see
any
hands.
I
see
a
few
hands.
Okay,
all
right,
because
honestly
I
think
it's
I
think
it's
worth
taking
on
this.
Just
drag
independent.
Just
didn't
keep
these
conversations
going
so
that
we
come
to
a
conclusion
whether
it
goes
all
the
way
to
RFC
or
not
it's
irrelevant.
In
our
process
we
have
to
solve
problems
and
whatever
the
solutions
fall
out,
this
is
helping
us
to
get
there
I
think
we
should
do
it.
Thank
you.
X
Had
this
I
hadn't
read
this
I.
W
X
U
Co
me,
this
front
is
for
PR
PFT,
because
the
author
account
attended
this
meeting
because
of
the
visa
problem.
So
I
present
it
is
strapped
for
her,
and
the
update
of
this
version
is
the
description
about
PRP
of
decision
bootstrapping
and
the
actual
hotel
part
has
been
updated,
and
we
know
that
the
multi-point
of
EFT
and
active
terror
draft
has
being
published
as
FC
propose
the
standard
of
ca10,
562
and
8563,
and
also
the
other
modification
is
about
the
PRP
ft,
sub
Jovi
or
sub
sub
shall
be
carried
genes
SPF
and
you
see,
is
advertisement.
D
D
I
just
jump
in
on
the
time
that
this
is
this
is
great,
but
this
is
not
sure
how
it
works
is
just
you've
done
your
homework.
This
is
great.
So
let's
go
what
our
next
steps
are
here,
so
the
idea
I
think
with
BFD
and
how
its
units
all
standards
based,
which
is
excellent,
I,
had
the
one
comment
about
that
use
case.
If
there's
an
existing
use
case,
where
BFD
is
used
like
that,
we
can
kind
of
use
as
a
model
be
beneficial.
Are
there
other
use
cases
in
this
draft?
B
D
No
readings
when
I
trying
to
lose
a
long
time
ago,
yeah,
alright,
so
I
think
it's
willing
to
throw
to
the
list
get
some
feedback
on
it
again.
I
think
to
work
from
this
right
now
is
tied
to
the
previous
draft,
which
we're
gonna
take
to
the
list
anyway.
So
I
think
it
makes
sense
to
have
this
part
of
the
conversation.
Well,
we'll
take
it
to
listen,
see
where
we
go.
Okay,
thank.
D
C
Right
go
for
it,
okay,
so
at
this
point
three-minute
review
there
may
not
be
much
any
time
for
discussion,
but
this
draft
has
moved
from
a
problem
statement
to
a
requirements
draft
for
last
night,
if
discussion,
we've
per
the
decision
of
the
working
group
moved
the
requirements
section
up,
making
that
the
main
focus
of
the
draft
we
added
regime.
As
a
co-author,
it's
now
a
working
group
document
and
we've
put
out
a
new
array
of
mainly
developing
the
requirements
section
next
slide.
C
Hopefully
you
already
know
what
the
draft
purposes
so
next
slide.
So
the
these
are
the
requirements
and
we've
added
some
more
commentary
to
some
of
these
requirements.
We
have
a
few
additional
requirements
that
we
intend
to
put
into
the
document
between
now
and
next
month
and
please
look
at
these
requirements.
If
you
go
to
the
exercise,
you'll
see
some
new
requirements
that
we
intend
to
put
into
the
document.
W
C
G
W
C
Giving
our
best
what
those
are
and
where
this
thing
that
leads
us
to
that
last
slide
is
just
looking
at.
You
know
the
different
solutions.
We
need
to
provide
the
pros
and
cons
per
our
discussion,
less
EF
l.
So
we
will.
We
need
to
be
as
impartial
as
possible.
We
probably
need
to
which
we
don't
do
right
now
explicitly
state
at
the
beginning
whether
this
is
an
encapsulation
method.
C
If
visits
an
encoding
method,
we
probably
need
to
agree
on
what
exactly
native
ipv6
means
to
us
and
because
everybody,
and
in
all
those
solutions
we
all
talk
about
native
ipv6
I,
think
it
made
me
a
little
bit
something
different
each
of
us.
We
don't
have
time
to
discuss
it
now,
but
we
can
take
these
things
to
the
list,
but
that's
our
request
and
that's
the
update
so.
D
D
Encapsulation
is
what
we're
really
targeting
if
there's
encapsulation
use
cases
to
do
it,
but
when
we
merge
the
two,
as
you
said,
capsulation
encoding,
there
has
to
be
reason
why
we're
doing
that
you
know
and
caps
to
get
over
something,
but
the
encodes
already
established
in
this
cut
in
stone.
We
can.
D
We
can
deconstruct
it,
but
there's
we
need
to
know
why
right
because
there's
hardware
being
built
to
pipeline
this
stuff
through
and
if
there's
another
step
to
be
ordered
in
front
of
it
to
take
pieces
out
of
an
existing
header
and
put
it
back
into
a
beer
structure
for
the
hardware.
It's
and
consider
transitional.
That's
transitional
hardware
is
a
really
hard
sell,
yeah
right,
yeah.
D
Okay,
but
and
again,
I,
don't
want
to
read
it
one
more
point:
if
your
solutions
in
this
document,
please
step
up,
I
mean
that
that's
the
deification
comes
through.
You
can
come
out
and
say
this
is
what
we
need.
The
existing
tools
don't
get
us
there.
We
need
something
else.
Then
we've
got
a
reason
to
go
forward
with
this
work.
So
if
your
use
case
is
on
there
and
and
you
think
this
is
important
work,
you
need
to
make
your
case.
Thank
you.
Thank
you,
Mike.
Any
other
questions.