►
From YouTube: IETF103-BIER-20181107-0900
Description
BIER meeting session at IETF103
2018/11/07 0900
https://datatracker.ietf.org/meeting/103/proceedings/
A
All
right
good!
That
means
we
have
a
minute
for
today
we're
missing
one
deck
for
borrow
spill.
So
I,
don't
you
look
that
now,
thanks
for
getting
in
I
won't
be
between
the
feet
about
being
late.
It's
in
the
district,
whatever
nice,
it
said
17
minutes
ago,
so
really
call.
This
number
I
was
on
the
walk
over.
B
A
We're
so
close
private
instruction
on
how
do
you
guys
cook
this?
Why
you
guys
were
here
and
buggy,
but
apparently
get
the
convert
everything
to
slides
instead
of
a
PowerPoint?
Have
it
happen
for
us
we're
getting
close
all
right
so
welcome
I'm
gonna
dive
in
this
anyway,
even
though
Tommy's
not
here.
So
if
you
have
anything
that
to
do
nothing,
in
fact,
let's
just
say
Tony's
taking
minutes
all
right,
we
need
to
sum
everything
minutes.
I
know
it's
morning.
It's
great
way
to
stay.
A
Awake
should
have
made
the
request
at
the
list,
but
you
know
it
is
whether
there's
somebody
any
fun
there
you
go.
Thank
you
so
much.
What's
your
email
address,
okay,
Sunday,
so
it's
you
know
send
either
IQ
center
of
your
chairs
would
be
great
or
gate.
You
can
send
us
a
link
that
your
chairs
good
morning.
E
A
A
A
F
A
What
I
I
miss
Mike
discussion
Johnson
is
use.
I'm
gonna
try
to
call
that
anyway.
Today
comes
up
in
the
conversation
sometime,
maybe
carbon
space
tomorrow,
but
again
it's
for
this
height
I
gave
you
everything
you
asked
for
any
time.
Normally,
I!
Don't
do
that!
You
look
at
it.
I
want
a
half
an
hour
and
I'll
give
you
ten,
but
so
these
are
intricate
topics
and
the
total
came
out
within
the
window.
So
we
get
this
night.
Big
work
get
more
time.
H
A
A
So
this
is
Gregg
speaking
as
as
co-chair
when
I
send
the
agenda
to
the
list.
Give
me
the
comments,
then
right.
That's
why
I
sent
it
out
there
there's
something
missing
into
some
Association
right,
so
we
get
some
feedback
and
we're
not
doing
this
in
the
room.
Anything
else,
all
good
stuff
will
cart,
try
to
carve
out
time
all
right,
booming,
you're
up.
I
I
So
we
thought
that
the
next
obvious
step
is
to
start
signaling
MPLS
type
of
solution
over
beer
again
to
refresh
everybody's
memory.
The
entire
reason
for
this
type
of
signaling
of
legacy
multicast
protocols
over
a
beer
core
is
some
of
the
Tier
one
operators
out
there.
They
want
to
replace
a
portion
of
their
network
order,
that's
core
or
even
access.
It
doesn't
matter
a
portion
of
the
network.
I
They
want
to
replace
it
from
legacy
multicast
to
beer,
simply
because
it
brings
simplicity
from
protocol
their
point
of
view
from
forwarding
all
the
good
stuff
that
we
know
and
they
need
to
stitch
legacy
protocols
through
this
beer
core.
So
this
is
why
we
are
providing
these
type
of
traps
into
the
IDF
told.
I
That's
great
question
so,
to
give
you
an
example,
some
of
these
t1
operators-
they
have
wireless
services
on
the
wireless
side,
did
you
use
ml
DP
as
an
example
on
the
business
side
they
use
p,
m--,
etc,
etc.
So,
to
answer
the
question,
yes,
all
these
type
of
s,
teaching
of
legacy
stuff
are
there.
This
is
not
something
that
we
are
just
cooking
up
from
our
imagination.
I
So,
even
though
that
this
draft
is
really
calling
out
for
ML
DP,
this
is
how
we
started.
Eventually.
What
we
see
is
that
this
graph
going
to
get
extended
to
empty,
let's
point-to-multipoint
topology,
what
that
means
is
that
we
are
seeing
a
new
multicast
point-to-multipoint
trees
coming.
We
had
a
talk
in
pym
with
the
segment
routing
looking
at
the
spring.
I
There
is
three
see
so
all
this
type
of
MPLS
point-to-multipoint
tunnels
they
kind
of
need
to
get
a
stitch
through
a
beer
core,
and
this
is
a
starting
point,
but
eventually
it's
going
to
get
extended
to
all
this
other
point
to
multi-point
MPLS
tunnels
as
well.
We
had
some
new
quarters.
Thank
you
very
much.
Rison
Eddy
was
there
and
actually
Cisco
Mishra.
Thank
you,
but
basically
what
this
draft
is
going
to
go
to
and
we
try.
We
try
to
keep
it
in
line
with
PIM
signaling,
as
everybody
is
very
familiar
with
the
team.
I
Signaling
is
two
directions,
so
the
first
part
is
from
technical
point
of
view,
is
the
signaling
part
so
on
the
signaling
and
I
still
kept
using
the
term
BB
our
boundary
be
router,
ingress
and
egress
I
know
there
has
been
some
comments
that
maybe
that
term
is
a
little
bit
confusing
and
we
might
have
to
change
that
I'm
completely
open
to
that
in
the
working
group.
As
long
as
I
can
do
a
search
replace
with
a
brand
new
turn
by
all
means.
I
Let's
do
it
and
as
long
as
we
don't
create
extra
complexity
into
the
drafts
that
are
being
introduced,
that's
it
so.
The
the
technical
part
is
very
similar
so
on
the
ib
BR
or
on
the
beer
boundary
routers,
the
signaling
MLBPA
in
this
case
becomes
terminated
and
it's
signaled
from
ib
BR
to
the
ebbr,
that's
signaling.
We
need
to
identify,
as
of
now
I
just
said,
let's
signal
the
fake
of
the
ml
DP.
So
you
grab
the
fake
of
ml
DP,
you
put
it
into
a
beer
encapsulated
packet.
I
How
you
find
the
ebbr
is
in
line
with
what
we
did
in
pin
signaling.
So
you
look
at
the
root
of
the
fake.
You
figure
out
where
the
root
is,
and
you
use
the
same
procedures
as
PIM
signalling
to
find
the
ebbr.
You
signal
your
fake
effect,
as
we
know,
will
represent
the
point-to-multipoint
LSP,
uniquely
within
the
beer
domain.
I
So
what
that
means
is
that
within
the
beer
domain,
we
need
to
identify
that
point-to-multipoint
LSP,
if
you
will
uniquely
and
how
that's
done,
is
that
on
evv
R
it
will
assign
a
beer
domain
label
again
I'm
open
to
changing
that
name
when
that
label
is
assigned.
There
is
two
way
to
signal
that
back
to
the
IB
beers
number
one
is
via
Sdn
number
two
could
be
via
BGP
and
whatever
we
need.
A
new
PTA
are
a
type
4
BGP,
again
I'm
open.
We
can
talk
about
that
order.
I
We
can
use
existing
PTAs
or
the
route
ID,
something
that
we
need
to
talk
about
from
technical
point
of
view.
But
that's
how
that
point.
Multi-Point
LSP
is
actually
identified
within
the
beer
domain,
so
I
actually
went
through
to
this
slide.
This
is
the
BGP
case,
so
the
effect
comes
to
the
IBB.
Are
the
IBB
are
actually
assigns
a
label
that
label
for
simplicity?
I
You
could
think
of
it
as
like:
a
BG
PLU
label,
so
it
will
Stitch
the
point
of
hot
multi-point
MPLS
on
the
MLB
b-side
to
a
VG,
PLU
type
of
label
on
the
beer
core
and
on
the
BBB
arse
you
need
to
swap
or
pop
and
push
whatever
it
is
that
you
need
to
do
to
stitch
this
tunnel
through
out
from
the
root
to
the
the
only
extra
part
now.
So
one
more
addition
part
is
that
the
ebbr,
exactly
like
p.m.
I
I
The
next
part
of
it
is
if
some
operator
decides
that
Sdn
is
the
way
to
go
proceed
segment.
Routing
point-to-multipoint,
as
we
talk
into
the
pim
same
idea,
with
a
stand,
so
the
control
plane
for
advertising
that
beer
domain
label
that
identifies
the
point,
multi-point
LSP
could
be
done.
We
are
a.cian
or
it
could
be
done
via
BGP.
J
I
mean
these
are
stream
signed
labels
right,
so
they
basically
need
to
be
received.
You
know
and
and
looked
upon
in
the
context
right
I
mean
you
can
you
can
have
two
different
upstream
routes
assign
the
same
legal
or
you
manage
label
pool
or
you
basically
do
a
lookup
based
on
the
label
and
the
B
if
I
are
in
the
beer
packet
header,
so
yes,
I
mean.
I
I
So
again,
between
the
PE
between
the
root
and
leaf
is,
is
today's
MVP
and
procedures
right.
So
what
happens
with
ml
DP
today
is
MVP
n
procedures
will
keep
the
leaf
to
generate
a
fake
and
that
fake
will
be
generated
to
the
root.
So
it's
gonna
have
root
IP
address.
You
know
a
unique
identifier
of
the
root
for
that
v,
PR
n,
and
that's
what
the
fact
with
the
OPEC.
I
J
I
mean
justjust,
look
at
the
B
fer
the
be
fer
gets
a
packet.
It
has
a
label
right
so
now
could
it
be
that
the
same
label
we
received
from
different
upstream
for
different
trees
work
your
joint
to
do
different
trees
on
two
different
upstream
bf
IRS
and
they
of
course
assigned
independently
from
each
other
randomly
the
same
label.
So
you
get
that
so
you
can't
decide
you
know
which
of
the
trees.
We
have
two
trees
to
which
the
same
layer.
I
K
So
I
think
what
Toulouse
means
is
on
the
way
back
right.
So
if
you
receive
the
package
of
beer
packets,
then
you
need
to
a
label
lookup
determine
you
know
its
effect
is
for,
but
since
labels
of
scientists
to
be
uniquely
in
the
context,
yes,
but
but
let's
say
the
label
underneath
the
beer
is
a
contacts
label
right
in
combination
with
to
be
a
IR
or
it's
a
global
level.
I
So
yeah
exactly
that
the
datapath
aside
is
missing
here
now
that
you
have
actually
signaled
your
control
plane
all
the
way
from
the
leaf
to
the
root
on
the
ebbr.
When
the
packet
comes
back,
you
simply
do
a
swap
on
the
on
the
ml
DP
packet
compared
to
to
the
the
beer
domain
label,
and
that
keeps
the
uniqueness
of
the
point-to-multipoint
three
throughout
the
entire
path.
I
I
K
We
go
so
that
first
part
number
one
right
where
you
or
maybe
number
two.
Actually,
when
you
send
out
your
take
your
Emily
effect,
any
signal
to
your
egress
be
PR.
How
do
you
do
that?
Because
that's
so
from
Emily's
point
of
view
that
was
like
a
community
speech
session
over
LDP,
but
now
you're,
saying
you're
putting
is
natively
on
in
a
beer
packets.
Yes,
so
you're
coming
up
with
a
new
packet
format.
Another.
I
Alleles
not
nothing
new
and
that's
the
part
that
I'm
open
to
discuss
that
part
right,
good
yeah.
So
as
of
now
again,
I
just
put
the
fake
as
a
IP,
because
the
pim
signaling
is
IP.
So
I
try
to
keep
the
same
thing.
I'm
gonna
just
create
an
IP
header
and
put
the
fake
in
there
and
make
the
MPLS
packet
to
be
a
sorry
that
the
beer
packet
to
be
MPLS
signaling
as
like
a
brand
new
beer
packet
type.
I
K
I
K
I
D
One
of
those,
maybe
Geoffrey
kind,
was
to
use
MVP
and
procedures,
MVP
and
procedures
fundamentally
I
believe
a
fundamentally
wrong.
The
reason
why
is
because
it
would
introduce
a
edge
processing
in
a
device?
That's
in
a
car,
it's
a
peer
out
or
even
a
start,
doing
a
service
awareness,
edge,
processing
at
state
of
complexity
in
a
box
that
needs
to
be
as
unaware
of
this
as
possible.
So
a
and
I'm,
not
even
gonna,
go
into
the
modes
of
overlapping.
D
This
you
there
is
BP
running
actually
properly
between
the
edges
because
there
may
be
MVP
n
as
well
running
between
P
is
not
between
pieces.
So
the
this
is
a
transient
case
and
an
introduction
of
think,
and
so
there
will
be
technologies
and
gbpn
running
across
so
I.
Think
in
a
short,
do
we
need
to
fix
the
do.
We
need
to
fix
fix
or
do
we
need
to
enhance
it
to
prevent
packet
loss?
G
G
Participant
+12
eyes
do
keep
the
what
is
effectively
overlay
signalling
out
of
the
data
path:
okay
and
whether
you
use
something
like
bgp,
synchronization
or
target
of
LTP,
whatever
doesn't
matter,
but
to
resist
the
temptation
to
rely
on
the
fact
that
you
have
two
data
paths
to
put
to
graph
some
signal
link
which
is
effectively
I,
considered
an
overlay
signaling
here
to
stitch
all
these
things,
yeah,
the
quick
and
dirty
heck
remain
dirty
long
after
they
have
been
quick,
Adisa,
quite
significant
architectural
decision.
So
for
me,
it's
plus
one
eyes
very
clearly.
L
Chef
Erin
from
juniper,
so
we've
had
some
offline
discussion,
so
I
want
to
summarize
some
points
for
the
benefit
of
the
room.
First
of
all,
if
we
are
only
considering
ml
DP
case,
then
RFC
1760
will
be
the
best
solution,
because
anyone
who
has
implemented
that
only
need
to
define
a
new
interface
ID
Toa
and
that's
it
everything
works.
And
then,
if
you
want
to
go
beyond
ml
DP
for
future
other
kind
of
anchors,
Peter
and
Peter
knows
then
I
would
argue
that
mpg
pmap
would
be
the
best
way
to
go.
L
I
I
think
I
think.
Maybe
we
need
to
address
a
couple
of
those
points
you
know
for
a
minute,
so
TLD
P.
Yes,
thank
you
great
great
option,
but
but,
as
I
mentioned
previously,
it's
not
generic
enough
to
work
with
everything
so
and
M.
Vpn
procedures
I'm
all
ears,
but
the
simple
part
of
it
which
I
cannot
figure
out,
and
you
know
I
tried
to
figure
it
out
with
the
wine,
but
I
couldn't
either
with
glass
of
wine
is
the
part
that
how
you're
gonna
run
and
VPN
procedures
on
a
peer
router.
I
K
You
know
Andrews
comments,
you'd
have
a
beer
core
and
you
want
to
overlay
another
technology
on
the
edge
right
in
a
sense
that
isn't
VPN.
It's
the
same
thing
that
we
do
with
spin
over
Emily
B
all
right,
so
you
can
say
I,
don't
want
to
be
router
to
be
ap
function
and
then
and
try
to
come
up
with
also
a
little
bit
of
hacks
to
not
make
the
P
but
the
end
of
the
day.
K
I
think
we're
hurting
ourselves
if
he,
because
the
coin
yourself
and
actually
and
could
maybe
go
back
to
the
pin
version
of
this
one
point
thing:
you
know
that
right
that
I,
don't
really
like,
is
how
you
discover
who
your
ebbr
is
and
they're
all
sort
of
procedures
for
that
or
with
MVP
n.
You
know
exactly
because
it's
defined
right,
so
you
know
we
are
egress
border
routers
are
so
if
you're
saying
I
want
a
generic
way
to
solve
this
problem
and
I
don't
want
to
be
difficult
really
here.
G
Here's
chair
and
it
would,
it
would
sound
so
P.
This
is
not
from
the
draft
was
kind
of
original.
First
hack
is
the
beautiful
architecture
emerging?
Don't
let
it
go
lightly
nicer.
He
textures
are
born
in
a
lot
of
pain.
Okay,
so
don't
let
it
go
just
to
be
pleasant,
just
the
opposition
so
so
go
back
to
the
to.
G
D
Fundamentally,
if
there
was
no
MVP
n
in
that
network
at
all,
then
we
could
probably
make
this
somehow
happen.
Somehow
I
still
have,
but
but
the
fundamental
thing
to
look
at
this
picture,
but
that
picture
is
a
little
misleading,
because
that
blue
cloud
is
between
PE
s,
that
that
central
cloud
is
between
piece.
So
what
should
the
factor
would
do
if
you
put
an
MVP
and
there
you
would
nest
an
MVP
n
inside
an
MVP
n
over
the
procedures
which
ok.
G
D
G
L
G
A
M
Morning,
this
presentation
is
for
pure
prefix
redistribute
I'm
sunny
zone
from
the
key
and-
and
we
have
author,
poor
Jeffrey
and
ice,
and
the
this
job
has
been
presented
in
London,
while
one
meeting-
and
it's
the
second
for
an
indigent
voyage
at
first,
let's
see
the
problem
statement.
It's
a
traditional
network.
M
According
to
the
administration
requirements,
we
divide
the
sub
Network
into
several
ITP
errors
and
the
IDP
protocol
run.
Seeing
each
error
can
be
the
same
or
be
different
and
the
numbers
of
routers
in
each
error
is
not.
Even
so.
Maybe
is
there
tens
of
routers
in
some
areas
and
they
are
only
few
rotors
in
the
other
areas.
M
So
now,
I'm
moti
cassis
always
has
been
deployed
in
this
network
by
peeing
protocol,
but
if
we
wanted
to
deploy
a
beer
in
this
network,
according
to
the
existed
ITP
extension,
we
know
that
one
beer
domain
is
equal
to
one
ITP
error.
So
in
this
network
we
will
have
three
beer
domains,
and
so
the
border
wrote
her
like
a
three
and
a
fall
must
maintain
the
over
a
multicast
flow
state
and
a-three
and
a-four
must
do
the
encapsulation
and
decapsulation
function.
M
So
the
year
forwarding
efficiency
may
be
decreased,
so
we
the
like
to
improve
the
forwarding
efficiency,
so
we'd
like
to
merge
the
several
errors
into
one
peer
domain.
So
we
can
remove
the
overlay
state
in
other
route
are
like,
as
we
add
a
for,
so
we
can
decrease
the
times
of
beer,
encapsulation
and
decapsulation,
but
the
problem
is
how
we
can
build
the
beer
forwarding
across
multiple
routing
errors.
M
That's
the
solution,
so
we
will
Edward
highest
PR
info
associates
way
with
P
prefix
distribution
in
bottled
water
like
Rutter,
a
three
and
a
four,
and
so
the
PR
know
the
information
we
are
spreading.
The
hope
your
domain
across
multiple
IP
arrows
and
the
advertisement
is
aligned
with
the
existed,
IDP
or
PGP
ignition
about
the
impurity
encapsulation
because
it
has
local
certificates.
M
So
we
need
not,
but
me
Edward,
Edward
hi,
said
to
the
next
rockin
ever
so
I
really
know
the
ins
one
beer
domain
computed
as
a
forwarding
plane,
because
some
prefix
in
one
area
may
be
hidin
when
bother
Walter.
Does
the
prefix
district
a
function
such
as
aggregate
route
or
summarizes
the
rod
so
or
defaulter
world
rod
will
be
used
in
here.
So
we
add
a
new
extension
for
this
type
of
route
and
we
can
call
it
your
proxy
arrange
a
subshell
V
so
like
and
the
Fermata
is
the
lack
of
these.
M
The
PID
is
associated
with
summarize.
The
prefix
can
be
Edward
highest
individually
in
the
beer
range
sub
Jovie
and
this
sub
P.
We
can
be
used
to
improve
advertisement
efficiency,
fo
BFI.
This
continues
and
the
multiple
peer
proxy
range.
Some
theories
may
be
used
if
the
BFI
ideas,
however,
the
paratroops
are
allocated
from
different
ranges,
so
maybe
you
can
use
necessary
policy
contour
it
so.
H
Stick
so
I
see
here
that
you
have
this
be
fair
range.
If
it's
like
contiguous
are
these
yeah
will
be
an
option
to
use
a
bit
set.
Instead,
like
a
beer
set,
basically
have
bit
positions
for
each
show
to
be
Freddie's
that
this
prefixes
for
cuz,
then
you
could
easily
do
any
beer
Freddy's,
even
if
they're
not
contiguous
so
I
mean
we
must.
M
M
L
This
is
really
just
a
language
issue
and
we
can
fix
that.
It's
basically
in
the
use
case
that
sandy
brought
up.
You
actually
have
different
repeat
domains.
For
example,
you
have
one
iOS,
PF
domain
and
another
were
spirit
open
that
they're
not
really
different,
OSPF
areas.
But
anyway,
though,
the
language
could
be
more
clear.
Okay,.
N
M
A
A
M
M
Whatever
a
solution
is,
let's
see
is
a
problem
statement
and
we
know
it's
simply:
Earth's
read
Network
and
there's
some
requirement
in
this
network
and
we
use
beer
to
provide.
The
motive
has
the
service
in
the
connected
area,
and
we
want
a
simple
solution
to
so.
The
palm
isolation
like
the
Gateway
list
here
is
not
provide
it
just
round
her
and
even
if
I'm,
with
MVP
an
MP
PGP,
not
wrong
in
the
gateways.
M
M
M
We
use
it
jean-pierre
over
a
control
plane
and
also
in
the
it
plane.
So
we
use
overlay
overlay
protocols
who
Edward
highest
global
VPN
ID
and
also
we
use
the
global,
which
is
the
value
of
the
global,
with
your
ID
in
the
data
plane
for
already
its
context
so,
and
we
will
add
a
new
prototype
which
indicates
the
global
will
be
my
ID
in
the
beer
header
like
the
Bing
I
wish
ID
uses
you
very
European,
but
we
will
not
use
MPP
advertisement.
M
So
we'd
like
to
use
a
Mardi
up
here,
so
Edward
has
it,
but
if
you
want
to,
you
can
use
PGP
global
advertisement
for
it.
M
So
if
we
use
this
solution,
we
know
that
we
can
use
global
whipping
ID
one
indicates
the
group
1x
cried
one
and
cried
foreign
cry
for
five
and
we
use
global
jihadi.
Two
indicates
a
group
to
the
group
who
includes
crying
too
crying
three
and
the
credit
crunch
six,
so
the
pain
it
weighs
like
I
did
it
with
one
two
three
four
will
advertise
associated
global
weeping
IDs
to
each
other,
so
the
ingress
router
suppose
it
way
one
can
encapsulate
the
packets
from
grade
one.
M
Who
is
the
global
with
your
ID
1s
contacts
and
encapsulated
the
outer
PR
header
with
gateway?
Okay,
before
it's
a
bit
extreme.
So
when
the
packets
rich
is
to
orbital
for
the
egress
router
will
remove
the
header
and
the
final
context,
value
global
with
an
ID
and
forward
it
to
the
Associated,
cried
for
and
cried
fi.
So
we
think
this
solution
is
very
simple
for
simple
network:
that's,
it
does
not
wrong
and
PPP
so,
but
we
are
open
to
the
other
solution
for
this
network.
N
M
So
if
somebody
has
new
or
good
suggestion
for
it
without
it
the
new
prototype,
we
are
also
work
hard,
because
we
know
that
because
the
context
of
maybe
you
different
fo
each
solution,
I
locate,
one
prototype,
I,
don't
know
who
it's
who
and
if
it
will
be
enough.
So
it's
just
no
question
and
the
the
networker
we
want
to
so
as
Vista
here.
So
please
we
can.
We
can
work
for
it
and
the
it
will
deploy,
increase
the
deployment
of
a
beer
technology.
N
You
know
ok
from
highway.
I
want
to
make
to
be
clear
about
the
beer
proto
value,
one,
whether
it
means
a
pier
specific
global
Vivian
label
were
a
pair
platform
amperes
label.
If
that
means
beer
specific
label,
then
there's
no
need
to
add
another.
Allow
that
be
a
proto,
but
if
it
means
the
pair
platform.
A
J
O
O
A
H
It's
good,
okay,
alright!
So,
as
you
may
remember,
the
idea
with
this
draft
is
to
find
on
the
MTU
that
can
be
used
in
an
entire
beer
sub
domain.
So
all
the
routers
announced
basically
the
local
MTU,
what
they
can
see
from
their
local
interfaces
and
by
comparing
them
to
use
announced
by
all
the
routers.
H
H
So
basically
you
you
just
check
how
many
bits
do
I
or
bytes
do
I
add
as
part
of
my
end
cap
and
you
subtract
that
from
them
from
the
subdomain
MT
that
gives
you
the
maximum
IP
packet
that
you
can
tunnel
free
beer
I
also
added
some
text
based
on
discussion
last
time.
That
implementations
should
have
some
configuration
that
can
specify
a
minimum
MTU.
H
So
basically,
let's
say
you
decide,
use
jumbo
frames
and
all
of
your
beer
network,
but
you
accidentally
bring
up
a
link
with
a
smaller
MTU
rather
than
having
the
entire
ping
domain,
so
peer
domain,
reworked
to
that
small
MTU
you.
You
then
ignore
that
particular
small
MTU
and
you
can
do
like
some
kind
of
warning
to
matter
to
administrator
that
too
low
MTU
has
been
detected
in
the
network,
something
like
that,
which
means,
though,
that
any
packets
that
unfortunately
try
to
go
through
that
one
link
might
get
dropped.
P
A
E
E
P
E
Down
so
make
sure
that,
as
a
group
process
that
we
get
early
transport
area
review
or
something
when
the
time
comes
so
that
we
address
everything
they
say
and
we
say
yes,
we
don't
really
care
that
the
packets
don't
get
to
the
other
side.
You
know
something
like
that.
That's
really
not
gonna
fly
because
you
know
it's
gonna
be
a
big
problem.
If
we
can't
guarantee
connectivity
across
the
network
because
we're
ignoring
the
link
that
we
know
has
a
lower
G
I'll.
G
E
E
May
want
to
send
it
to
the
CSV
working
group.
There
is
the
TSV
review
group.
If
you
ping
me
later,
I
can
maybe
find
where
it
is,
or
you
can
talk
to
the
transfer,
a
tease
and
have
them
ask
for
the
review.
I.
Think
in
fact,
now
in
the
data
tracker,
you
can
go,
there's
a
little
thing
that
says
request
review
and
it
takes
you
to
a
different
page
and
you
can
request
from
the
TV
or
from
routing
or
from
whatever
you
want.
You
know,
put
notes
there.
E
A
H
H
H
The
idea
explained
here
is
that
any
router
that
has
directly
connected
sources
instead
of
kind
of
sending
him
registers,
you
are
sending
something
that
looks
a
little
bit
like
PSR.
You
are
sending
messages,
get
flooded
throughout
that
pim
domain.
Saying
here
are
my
active
sources.
There
are
directly
connected
sources
and
this
is
followed
through
the
network.
So
if
you
have
a
last
up
router
and
you
get
receiver
interest,
you
can
then
join
directly
to
the
shortest
towards
the
source
on
the
shortest
path
tree.
H
So
if
yep,
at
least
some
of
us
think
this
is
a
nice
thing,
we
want
to
use
this
in
PIM
and
I'm
thinking.
If
you
deploy
beer
else,
I
would
like
some
way
for
this
to
work.
So,
basically,
if
you
have
this
situation
here,
I
have
two
clothes
that
are
pim
domains
and
then
his
life
is
cloud
in
the
middle
is
beard
basically
maybe
had
a
long
big
PIM
domain
and
you
would
place
operate
some
routers
to
do
beer
kind
of
locked
up
in
joint
signaling
or
a
beer
scenario.
H
So
what
would
happen
then,
with
this
pfm
mechanism?
Is
that
the
the
first
up
router
to
the
left
are
connected
to
the
source
with
announce
an
active
source?
It
gets
flooded
throughout
the
PIM
domain
on
the
left
and
this
summer
want
those
messages
to
reach
the
ping
domain
on
the
right
and
towards
this
last
progress
we
can
make
use
of
this
mechanism.
H
H
H
So
that's
one
thing:
the
only
thing
I'm
trying
to
do
is
to
solve
this
problem
in
the
in
the
pim
overlay
him
join
draft
with.
How
do
you
determine
which,
rather
to
send
up
and
join
to?
We
want
to
find
the
beer
router
that
is
closest
to
the
source
and
the
way
I'm
proposing
to
do?
That
is
that
when
and
a
beer
out
there
on
the
left
here,
what
I
call
an
ingress
fear
rather
and
caps
lates
this
pfm
message
it
takes.
It
adds.
H
H
H
P
I
H
So
you
can
say
yeah
one
thing
I
want
to
add
here
is
in
the
like:
I
can
P
overlay.
We
are
broadcasting
the
receiver
just
to
everyone,
because
we
don't
know
where
the
sources
are
here
were
kind
of
doing
the
opposite.
You
are
broadcasting
the
source
information
and
an
additional
thing
we
can
do
here
is
also
center,
a
directed
by
jean-pierre
reports.
So
they
just
go
to
the
routers
that
actually
have
active
sources
which
I
believe
detective
sources
told.
H
J
Maybe
be
useful
to
open
up
the
discussion,
whether
you
know
the
procedures
would
work
better
if
they
would
also
be
you
know,
beer
casted,
so
to
speak.
To
you
know
the
all
the
scene
upstream
so
that
any
any
switch
over
right
I
mean
what
happens
if
multiple
downstream
it's
kind
of
this
assert
problem
right.
So
this
is
this.
This
is
like.
What's
the
best,
you
know,
land
procedures
for
multiple,
downstream
multiple
up
streams
if
they
get
the
additional
indication,
is.
H
I
would
say,
if
you
think
about
you
know,
maybe
like
reliability
and
stuff.
It
could
perhaps
be
useful
that'd
be
for
one
on
v4
to
both
receive
that
join,
but
you
would
need
to
have
some
kind
of
forwarder
election
and
in
some
way,
or
maybe
one
start
forwarding
if
the
other
one
goes
down
or
something
like
that.
Well,.
J
Right
all
I'm
saying
is
right:
we've
got
beer,
so
there
is
no
need
to
use
unicast
just
because
we
forgot
to
to
be
able
to
send
it
upstream.
Do
all
the
possible
upstream,
ratify
it
and
try
to
think
about
whether
I
guess
in
this
case
we
wanted.
So
it's
it's
better
than
a
LAN
right.
J
But
then
you
haven't
showed
a
really
interesting
beer
domain
right,
the
you
know
this
be
if
I
r1
and
the
BF
ER
one
can
be.
You
know
both
in
the
US
and
be
fi
r2
and
PF
v
r2
can
be
in
Europe.
So
you
know
they're
the
the
cost
across
the
beer
domain
is
not
taken
into
account.
This
I
don't
know
if
we
can
or
should
do
it
all
I'm
saying:
okay.
J
H
So
we
haven't
thought
much
about
this,
but
I
guess
if
you
want
to
account
for
the
cost
across
the
beer
domain.
One
option
perhaps
could
be
that
the
egress
router,
the
BF
ER
here
basically
takes
the
metric
announced
and
adds
the
cost
to
reach
the
beer
prefix
or
either
be
a
fire
one
or
two.
So
you
can
see
the
total
cost
is.
I
P
H
H
I
H
Alternative
yep,
exactly
I
think
that's
all
I
had
okay,
so
just
very
quickly,
if
you,
if
you
choose
to
do
this,
it
would
need
to
new
TLDs
in
this
pfm
mechanism.
That
could
be
a
pin
document
or
it
could
be
down
here.
So
it's
basically
announcing
the
the
beer
info
on
or
the
only
ingress
rather
and
I'm,
this
all
time
metric
group
source
photometric
tilde.
A
Of
the
room,
who's
read
the
draft
raise
your
hands.
Please,
but
thinks
does
this
work
should
be
adopted
by
the
working
group.
So
I
saw
okay,
put
your
hands
back
up.
If
you
read
it
all
right,
keep
them
up.
If
you
don't
think
it
belongs.
To
the
group
drop
your
hand,
do
you
think
it
belongs?
You
think,
if
you
don't,
you
do
alright
looks
like
we
lost
a
couple
of
hands
out
of
the
total
or
I
will
take
this
in
the
list
and
see
where
rules
if
anyone's
willing.
I
Hooman
be
going
look
yeah,
like
from
procedure,
point
of
view,
it's
a
extra
procedure,
so
you
know
more
procedures,
the
better
but
again
I'm,
not
quite
sure
what
is
missing
from
finding
the
ebbr
s
with
IG
P.
So
we
have
IG
p.
We
have
BGP,
we
have
a
static
route,
we
have.
We
have
covered
the
entire
ground
honestly
metric,
maybe
but
I'm
not
quite
sure
what
else
this
is
not
bringing
any
traffic
engineering
or
anything
like
that.
It's
just
another
method.
On
top
of
you
know
a
a
heel
of
other
methods.
A
P
Q
Of
my
co-authors
listed
there,
so
just
as
a
recap,
this
is
a
an
example.
This
is
a
realization
of
the
use
case,
HTTP
multicast,
that
is
described
in
the
beer
use
cases
document
and
in
the
earlier
version
of
the
draft,
we
described
the
reference
architecture
and
realization
of
the
multicast
overlay,
and
we
just
described
this
overlay
on
over
IP
MC,
IP,
multicast
and
beer.
Q
We
did
evaluate
the
pros
and
cons
and
we
went
into
little
bit
details
about
the
realization
over
beer
and
described
some
of
the
operational
details,
including
functional
elements
in
terms
of
the
reference
architecture
that
was
described
there.
It
is
same
we
just
slightly
modified
the
name
instead
of
SR.
Q
From
the
last
draft,
we
did
get
some
comments
from
the
previous
meeting
Montreal,
as
well
as
in
the
mailing
list.
In
terms
of
the
comments
that
we
addressed
is
the
deployment
options
for
the
SH
functionality
in
the
be
F
ers
and
be
F
IRS,
as
well
as
to
consider
or
describes
the
work
that
is
being
going
on
and
the
other
forums
like
DVB
and
BB
F.
So
we
did
try
to
address
those
or
include
those,
but
at
a
very
high
level,
without
going
into
details.
Q
Now,
in
terms
of
addressing
some
of
the
comments
with
respect
to
the
SH
deployment
options,
we
this
SH,
as
we
described
earlier,
is
assumed
to
be
co-located
with
the
VAP
R
and
B
F
IR.
But
it
is
this
b
fe
r
and
b
f
ir
are
routers
and
it
may
not
be
possible
for
to
add
that
sh
functionality
within
this
simpler
routers.
Q
So
as
an
option,
we
described
data
that
we
can
consider
this
sh
functionality
may
be
if
it
is,
if
it
cannot
be
included
in
the
BF,
ER
or
b
f
ir,
we
can
consider
it
as
an
external
function,
which
can
be
a
virtual
functions
which
may
be
co-located
or
can
be
located
in
a
remote
location.
But
in
that
case
we
may
need
to
define
certain
interfaces
from
the
VF
e
RB
fi
RS
to
the
SH.
We
again
didn't
to
go
into
the
details
of
the
interface,
which
may
be
a
future
work
in
the
later
updates.
Q
So
basically,
the
multicast
terminates
at
this
gateway
and
from
there
there's
a
unicast
to
the
client-side,
and
so
it
also
describes
a
specific
interface
interface
through
where
the
the
terminals
or
the
content
playback
can
send
requests
to
the
Gateway
functionality
and
functions
that
are
included
in
terms
of
fetching
specified
type
of
content,
conditional
request,
range
requests
and
caching,
and
we
also
get
in
it,
would
try
to
see
what
BBF
is
doing.
So
BBF
is
kind
of
kind
of
following
what
dvv,
but
I
think
they
are
focusing
more
on
the
device
management
model.
Q
Now,
in
terms
of
this
information,
what
we
see
is
basically
the
draft
already
described
how
this
operates
on
the
IP
multicast
system,
and
we
see
it
kind
of
very
much
for
alliance
with
that
description
in
terms
of
the
way
multicast
gateway
is
there
and
how
the
client
sends
requests
to
the
Gateway.
For
specific.
Q
You
know
content
of
the
streaming
and
streams,
so
it's
kind
of
similar
and
from
there
we
take
on
and
continue
on,
the
IP
multicast
systems
and
his
features
and
his
pros
and
cons.
So,
in
terms
of
the
next
step,
we
are
also
thinking
to
include
some
additional
use
cases.
So
maybe
we
want
to
see
if
the
working
group
has
interesting,
including
additional
use
cases
for
this,
such
as
files,
application
incidence
or
software
updates
over
HTTP,
and
maybe
the
second
question
is:
is
there?
Q
E
Q
E
E
The
way
I
interpret
there,
that's
why
I
was
asking
about
changes
in
etc.
It
I
think-
and
this
is
maybe
a
question
for
the
chairs-
to
interpret
that,
because
I
think
it
talks
about
how
to
integrate
beer
and
partial
deployments,
for
example,
and
which
means
you
know
some
of
the
other
ways.
It
was
printed
before
how
do
I
interface
this
with
that
part
of
the
network
swimming
Pam
or
any
PN?
And
you
know
that
other
stuff.
It
does
have
one
item
that
says
in
applicability
statement,
but
it
specifically
talks
about
the
beer.
E
Vpn
draft
I
mean
that
one
thing.
So,
in
any
case,
you
know
there's
something
that
I
think
that
the
chair
should
check
the
Charter
to
make
sure
that
we're
interpreting
the
same
way
and
if
you
are
good,
if
we're
not,
we
should
probably
clarify
for
all
of
us
right
to
make
sure
that
we
are
looking
at
Charles.
My
way
right.
G
D
A
E
A
E
G
A
E
A
I
would
say
if
we
look
at
the
Charter
and
say
that's
not
the
case.
I'm
addressing
I
mean
if
we
could
take
the
time
this
array
of
documents
you
made
you
said,
may
come
from
this
idea.
You
know
if
this
one
for
beer
that
over
beer
that's
kind
of
another,
because
if
we
don't
say
it's
there,
people
I
mean
I've
have
to
say:
oh
this
can't
be
done.
What
do
you
mean
guys
haven't
talked
about?
Yeah
can
not
understand
that
the
actual
operation
of
beer
and
what
it
does
and
it's
not
like
you
know.
A
We
know
it's
an
overlay.
We
know
it's
just
the
think
cap,
maybe
specifically
to
get
it
done
over
there.
But
if
someone
you
know
often,
if
you
look
at
it
on
what
craft,
let's
know
coverage
there
now,
if
it's
in
the
use
case
document,
maybe
it's
not
sophisticated
enough
to
require
something
different,
but
if
it
does
use
get
talking
to
a
point
and
it's
further
articulated
in
an
RFC
food
I
mean
has
to
be
a
road
map
for
a
clue.
Otherwise
it's
just.
We
have
some.
A
J
So
I
think
in
the
ITF
multicast
overall
Tallis
occurred
been
been
fairly
good
in
you
know,
making
application
developers
happy
as
long
as
they
were,
providing
it
or
transport
services
right,
so
everything
about
VPN
anything
else
and
done
a
pretty
miserable
job
in
explaining
how
to
use
multicast
best
for
other
applications
and
beer
being
very
much
since
infancy.
You
know
I
was
joining
this
because
I
thought
this
was
would
be
good.
J
Documentation
of
you
know
this
HTTP
streaming
a
use
and
the
use
case
document
I,
don't
think,
should
go
into
all
these
technical
details
of
a
particular
application
space.
So
I
don't
really
care
where
in
which
working
group.
This
is
best
position.
I,
think
you
know
the
folks
in
the
room
and
you
know,
should
decide
if
this
is
worthwhile
to
be
documented
as
something
that
at
least
gets
working
group
review
which
of
the
working
group
that
is
mbone
D
or
beer.
D
D
E
G
Is
I
mean
the
applicability
seems
more
natural
to
be
here
because
it's
centered
around
this
specific
technology,
whereas
the
control
plane
stuff
like
we
were
talking
now,
you
know
all
the
additional
MVP
and
procedures,
whatever
not
signalling
stuff
that
could
gargy
will
go
into
people
who
deal
with
this
signaling
right
and
I.
Think
that
was
the
discussion
we
had
around
the
Charter
when
we
were
putting
it
together
right,
Greg.
A
His
chair,
more
new
advances,
is
one
of
my
many
soap
boxes,
but
you
know,
multicast
is
always
that
bastard
stepchild
in
the
corner,
you
go
with
the
other
groups.
They
said
yeah,
that's
kind
of
looking
a
little
bit
to
it,
so
even
getting
their
help,
they've
never
even
thought
about
it
for
multi
point
of
replication
services,
so
oftentimes
the
works
got
a
start
here
to
shake
people's
and
then
we
find
them.
Like
I
said
you
review.
Please
help
us
look
at
this.
We
needed
these
services
you're.
A
The
expert
Deeks
helped
us,
you
know
integrate,
but
but
the
innovation
always
the
use
case.
Now.
You
know
the
always
rises
from
this
group
of
people.
I
was
just
thinking
looking
at
faces
like
towards
got
the
Mike
insight,
I
laughed
when
I
would
see
a
person
like
for
20
years.
It's
like
the
same
people
in
the
round,
that's
in
front
to
some
point,
but
it's
we
stepped
in
it
right
and
it's
on
our
shoes
and
no
one
else
in
the
ITF
stinks
like
we
do
so
we're
the
ones
often
stuck
try
to
identify
the
problems.
G
Q
A
A
J
The
goal
of
the
document
is
to
be
able
to
enable
building
of
forwarding
hardware
that
can
support
beer
and
beer
to
II,
specifically
intending
the
document
to
be
experimental.
In
my
opinion,
because
I
think
you
can
perfectly
well
build
experimental
networks
without
you
know
defined
control
plane
by,
for
example,
just
programming,
the
bi
ft.
But
you
know
only
once
you
know
that
has
shown
successful
and
basically
the
whole
shebang
of
the
traffic
engineering
appropriate
protocols.
J
Everything
really
makes
sense
to
get
into
I
started
to
put
a
couple
of
drafts
out
around
101,
but
obviously
all
those
control
planes
stuff
would
take
a
lot
longer
so
experimental
for
now
to
again.
You
know
inside
that
this
will
work
and
can
be
done
and
then
go
back
to
the
control
plane.
So
we
had
the
discussion
about
the
encapsulation.
J
Okay,
so
I
added
a
new
section.
Three
six
requirements
with
math
should
against
the
details
of
the
forwarding
plane
and
that
I
hope
is
similar,
but
hopefully
also
a
very
explicit
to
be
R
where
I
think
the
way
I
read
it.
Ecmp
was
an
optional
addition,
but
otherwise
the
most
corvier
forwarding
was
mandatory.
J
So
here
we
go
so
must
configure
sub-domain
for
dirty
forwarding
and
then
basically,
the
semantics
of
the
bits
which
are
really
the
minimum
necessary
are
the
bits
indicating
no
or
one
adjacency
and
the
adjacencies
could
either
you
know,
link
layer
or
forward
routed
where
it
would
be
encapsulated,
for
example,
in
an
MPLS
label
to
be
sent
to
a
remote,
node
or
local
d
cap
when
you
receive
it,
so
we
could
maybe
degrade
to
assured
the
forward
routed,
but
I
think
it's
really.
For
you
know
the
typical
topologies
we've
looked
into.
J
It's
really
very
important,
I
think
to
to
have
that
ability
with
the
adjacency
but
I
think
these
three
together
are
very
simple
and
make
it
you
know
the
closes
in
requirements
to
the
beer
forwarding.
So
it
should
do
the
do
not
reset
flag,
because
that's
really
good
to
have
just
two
bits
for
arbitrary,
large
layer,
three
rings
and
it
may
have
ecmp
adjacencies
or
more
than
one
adjacency
on
a
bit
right.
So
that's
basically
trying
to
prioritize
the
functionality
okay.
So
here's
basically
then
screen
button.
J
Yeah,
okay,
so
this
is
basically
now
I
have
two
pseudo
codes
in
here.
So
this
is
exactly
the
same
pseudo
code
as
beer
has
to
highlight.
If
one
exactly
has
the
fbms
in
the
forwarding
plane
implemented
to
reflect,
but
the
beer
forwarding
graph
does,
then
there
is
basically
the
problem
that
for
beer
te,
this
is
uncommenting
in
this
pseudo
language
that
we
basically
would
not
reset
the
bits
in
the
string
after
every
individual
replication
and
here's.
J
This
is
what's
basically
trying
to
make
it
compare
very
easily
to
the
beer,
I'm
forwarding,
and
then
here
is
the
second
solution
which
doesn't
rely
on
having
the
FBM.
So
that's
just
a
matter
of
local
optimization.
How
you
want
to
move
it,
how
you
want
to
implement
it?
This
is
just
showing
really
that
you
don't
need
fbm
bits,
it's
good
enough
for
each
adjacency
to
just
have
the
do
not
reset
flag
and
then
basically
you're
just
resetting
the
bit
itself
on
which
you
were
doing
forwarding.
J
So
you
don't
really
need
to
do
anything
about
any
of
the
other
bits
in
beer
te
and
then
this
is
longer
because
it
just
also
has
the
pseudo
code
for
the
different
type
of
adjacencies,
which
wasn't
done
in
the
beer
pseudo
code.
So
I
thought
it
makes
it
easier
to
understand
what
all
these
different
adjacencies
do
a
little
bit.
But
let
me
know
if
this
is
the
best
text
or
we
should
cut
out
the
adjacencies
like
it
was
done
in
beer.
So
what
else?
So?
J
That
was
really
the
core
of
interest
I
edit,
some
opportunistic
text,
which
you
know
please
tell
me
if
that's
good
one
or
two
paragraphs
at
the
end,
our
beer
and
beer
te
might
best
be
understood
by
somebody
coming
from
the
segment
routing
side,
so
that
really
in
beer,
you
know
the
bits
are
equivalent
of
destination.
Notes
it's,
but
instead
of
you
know,
wasting
32
128
bits.
We
have
one
bit
for
each
of
them
and
then
in
beer
te
you
may
have
one
bit
equivalent
of
every.
J
You
know
intermediate
city
that
we
have
in
an
MPLS
or
as
our
v6
sit-stay,
and
we
can
of
course
do
trees.
So
I
was
basically
and
attempt
to
to
better
relate
to
that
unicast
technology,
because
today,
I
think
we're
seeing
everybody
goes
another
evolution
step
with
SR
on
the
unicast
side,
and
then
everybody
says:
oh,
that
means
in
multicast.
We
need
to
do
the
same
thing
as
much
as
possible.
I'm
saying
all
we're
doing,
look
logically,
the
same
thing
so
marketing.
J
J
So
that's
the
fun
and
crazy
part
if
I,
just
sending
fbms
now
in
beer
itself
proper.
The
way
it's
specified
right
now.
This
wouldn't
happen
because
there
really
so
far
is
I
think
no
defined
access
directly
to
the
DI
ft
and
the
FBM
right.
We
don't
have
an
API
to
do
that,
so
they
would
only
be
populated
from
the
bir
tea
wrong
wrong
wrong.
G
G
J
G
J
J
This
is
too
much
to
comprehend
completely
within
the
time
so,
but
I
thought
it
was
funny
quite
interesting,
maybe
something
where
we
want
to
say.
Let's,
just
you
know
make
if
we
mandate
how
the
bi
ft
has
to
work
when
you
program
it
directly
so
yeah,
but
to
know
that
ok,
then
maybe
we
put
constraints
on
what
allowed
fbms
are
because
maybe
a
distributed
implementation
may
not
want
to.
You
know:
support
that
crazy
fbm
combinations.
G
J
I
just
look
at
if
I
eat.
You
know
all
these
ecmp
things
out.
You
know
these
things
again,
but
you
know
I
I,
think
that
just
be
IRT
is
perfectly
fine.
I
can
basically
on
each
egress
line
card,
only
look
at
a
subset
of
the
bits
that
I
know
have
any
adjacencies
on
the
interface
I.
Don't
know,
I
don't
need
to
go
through
the
other
200
bits.
So
if
I
have
you
know
a
big
big
box
that
has
a
hundred
or
not
our
scale,.
E
J
J
G
J
G
K
J
K
G
M
G
K
Since
lost
time,
but
we
didn't
present,
it
lost
ITF,
but
so
it
has
been
accepted
as
working
of
documents
and
based
on
some
comments
right
on
the
mailing
list,
mostly
with
erosion,
so
we
added
one
actually
additional
encoding
to
this
draft,
so
this
is
one
that
really
had
before
right.
So
we're
hard-coding
missing
lengths
of
the
main
and
said
identifier
in
the
25th
table
ID.
K
This
is
nice.
You
know
if
those
values
are
sort
of
well
known-
and
you
know
you
want
to
create
a
unique
Biff's
ID
based
on
those
values,
so
a
better
way.
This
is
for
the
non
MPLS
encoding
right,
so
I
get
so
good,
and
now
we
actually
edit
a
new
one
for
a
couple
of
reasons
now,
as
you
can
see
so
so,
ibu
has
made
it
into
beer
funny.
K
So
this
is
basically
the
identifier
now
in
combination
with
said.
It
said
that
set
to
create
your
best
ID
and
the
eye
view
is
basically
becomes
sort
of
like
your
label
right
and
reasons
for
doing.
This
is
actually
well
drop,
that
the
trophy
is
it's
going
to
present
later
on,
I
could
disappear
as
a
service.
If
you
want
to
add
an
additional
identifier-
or
you
know
to
your
based
ID,
because
today
we
have
subdomain
bits
in
length,
say
daddy,
but
if
you
want
add
something
else
to
it
right
and
create
a
unique
gift.
K
K
So
basically,
so
that's
what's
the
point.
So
if
you,
if
you
do
want
to
have
other,
let's
say
waste
word-
to
create
your
based
ID,
then
you
can
do
this
now
with
this
witch's
IV
value
also-
and
that
was
a
point
that
you
know,
Eric
Rosen
made
early
on
hard
coding
fields
in
the
in
the
biffed
is
a
bad
idea,
because
we
want
to
keep
the
separation
between
control
plane
and
the
data
plane
right
and
data
plane.
K
It
should
be
a
20-bit
value
which
should
not
be
parsed
by
hardware
right,
although
if
we
connect
rate
encoding
said
actually
not
carve
it
up,
they
might
do
that.
But
in
this
case
now
we
have
two
encodings
right.
So
basically
you
cannot
really
parser
anymore
right.
So
it's
a
sort
of
secondary
fallout
of
this
of
this
solution.
G
And
so
I
had
an
exchange
with
the
other
author
I
think
that
the
value
is
zero
right.
This
is
the
one
with
the
value
zero,
meaning
that
those
are
the
generated
one
like
pre.
What
were
we
calling
them?
You
have
two
values:
0
is
reserved
right
when
you
marry
the
zero.
It
means
now.
It's
the
non
MPLS
automatically
derived
well.
G
Right
but
the
zero
was
reserved
for
the
one
that
the
draft
says
and
otherwise
so
have
carry
them
around.
Maybe
I
was
I'm
getting
on
character
strictly
or
characteristically
a
little
bit
lost,
but
the
important
thing
is
the
flat
20
bit
in
the
hardware
I'm
happy
Eriksson.
My
point
like
has
been
made.
That's
the
point.
The
rest
is
like.
A
L
Most
ten
minutes,
ok,
so
first
one
is
about
beer.
Ted
ring
off
I,
recall
I,
just
so
start
with
that
brownfield
deployment.
How
do
you
handle
beer,
incapable
routers
at
this
diagram
here?
X
in
the
middle?
That's
not
support
beer,
others
support,
so
you
either
get
around
the
in
cable,
routers
or
tunnel
through
them.
L
L
So
the
section
six
point,
nine
of
the
architecture
specs
talk
about
a
way
to
do
this.
Basically,
at
the
end
of
the
SPF
calculation,
in
this
case,
PFR
alliances
in
the
calculation,
it
gets
the
SPF
tree
with
X
being
the
it's
immediately
a
child
and
others
as
the
child
of
children
of
X,
so
exam
the
invidious
children
list
and
for
anyone
that
does
not
support
beer.
We
replace
that
child
with
its
children.
L
Sometimes
Tanana
alone
may
not
be
good
enough.
In
this
example,
PFR
one
is
two
panel,
four
copies
to
PFR
three,
four
five.
Six.
Now,
if
the
connection
between
BFRO
one
and
X
is
bandwidth
constraint,
gate
constraint,
then
that's
not
good.
So
one
way
to
get
around
this
is
that
we
tether
a
helper,
Okoye,
PFR
X
here
next
to
X
it
could
be
a
this
could
be
done
with
a
local
fed
pipe
and
now
the
package
could
be
like
this.
L
The
the
so
so
far
they
all
work,
except
that
those
tunnels
need
to
be
announced
in
AGP,
otherwise
be
FR
x,
will
never
be
put
into
the
SPF
tree
and
announcing
those
tunnels
in
IDP
is
traversing,
but
there
is
one
way
to
get
around
that
we
call
it
a
trick
or
whatever.
So
basically,
X
could
pretend
that
it's
suppose
fear,
so
it
does
whatever
a
beer.
A
PFR.
That's
ever
has
a
label
was
a
lot
of
things,
so
it
will
get
beer
packets
from
PFR
one
with
beer
labels.
L
L
So
we
need
done
by
Sydney.
There
are
two
ways
to
it:
one
is
that
X
tells
everyone
that
PFR
X
is
my
helper,
and
that
way
the
f4x
will
note.
It
cannot
just
send
beer
packs
back
to
X
natively
in
E
so
panel.
That
information
also
allows
other
BFRs,
for
example,
PFR
one
to
use
section
six
point:
nine
method
to
panel
packets
directly
to
X
instead
of
relying
on
X
to
the
label.
Switching
there
is
another
way
is
other
way
around.
Instead
of
X
tells
says
that
VF
Rx
is
my
helper.
L
Therefore,
X
can
actually
say:
I
am
XS,
help
help
her
I'll
talk
about.
Was
that
the
difference
so
for
the
two
options
where
the
first
one
is
Xpress
it
pretends
they
support
beer,
but
does
label
switching
that
you
only
need
require.
You
only
require
software
upgrade
X
itself
and
its
helper,
but
it
has
only
works
for
mpos.
It
does
not
need
any
software
upgrade
as
long
as
they
already
support
beer
on
other
BFRs.
L
The
second
method
is
where
the
BFX
advertise,
that
is
access
helper
and
then
others
who
are
tunnel
2x
based
on
their
signaling,
that
one
you
do
not
need
upgrade
on
the
incapable
outer,
sometimes
that's
necessary
because
being
an
innkeeper
router.
Sometimes
you
can
even
operate
this
software
so
anyway,
it's
basic
just
two
options,
so
I'm
seeking
comments
or
probably
polish.
M
L
L
G
L
G
L
A
L
Here
or
America
says
service
I'm,
just
going
to
escape
for
a
lot
of
slides,
talk
about
why
Marcus
as
a
service
as
not
being
become
real
and
why
he
may
become
real
and,
let's
just
say,
it's
jump
to
out.
How
could
this
could
be
done
using
a
simple
example,
we're
a
single
operator
for
doing
Marcus
for
it's
what
needs?
L
L
In
the
middle
we
have
a
s
to
200
and
then
there's
some
Gass,
so
initially
they
could
start
without
translate
the
FRS
at
all
just
the
F
years,
and
in
that
case
it
will
be
just
like
ingress
replication
among
each
other,
but
using
a
beer
header,
that's
fine!
You
can
start
with
that.
Oh
this
is
PDF.
I!
Guess,
that's!
Okay!
So
then
you
can
gradually
add
more
PFR
strands
BFRs
in
work.
L
For
example,
you
could
say
that
ASPR,
23
and
ASPR
24
now
are
now
upgraded
or
replaced
with
a
spear
or
a
PFR,
and
now
the
replication
is
no
longer
ingress.
Replication
end-to-end,
for
example,
VFR
11
when
now
ingress
replicates
to
asbr
23,
who
will
in
turn
replicate
to
others.
So
on
so
forth.
This
is
all
based
on
BGP
signaling
for
beer,
except
we
need
to
make
a
few
enhancements
a
cover
enhancements.
L
L
Ok,
it's
so
ASPR
21,
but
ASPR
21
is
not
beer
capable
instead
ASPR
23
is
then
the
best
will
be
for
the
ASPR
only
in
the
SPR
23
to
announce
that
PFE
are
at
the
PFR
IDs
and
browse
for
beer
purpose,
and
that's
that
is
one
thing.
Another
thing
is
that
today
the
IDR
extension
for
bgp
beer,
signaling,
there's
not
a
specific,
clearly
specify
how
you
decide
where
you
send
your
peer
packets.
L
So
in
this
example
the
the
be
fer
242
at
the
bottom,
since
the
other
has
a
appear
prefix
and
goes
through
a
SBR
for
SPR,
24,
SP,
23
and
then
SP
r1
and
eventually
arrived
by
PFA
year.
11
now
the
beer
next
then
BGP
next
hop
in
that
advertisement
is
a
SPR
one
and
so
be.
How
do
you
does
be
fer
11
used
the
next
hop
to
send
the
beer
packets
to
or
does
he
used
the
beer
prefix
off
to
send
traffic
to?
L
So
to
solve
that
problem,
we
we
can
introduce
a
tunneling
cap
attributes
attached
to
the
beer
prefix
advertisement
that
is
attached
by
the
be
fer
itself
and
whenever
it
goes
to
a
a
b
FR
that
changes
the
bgp
next
up,
that
BFRO
war
or
change
the
tunneling
cap
attribute.
So
that's
what
becomes
the
PFR
itself
in
the
middle
that
way
the
ingress
BF
are.
The
BFI
are
always
used
kind
of
destination
address
in
that
tunnel
in
happy
attributes
to
us
in
the
deer
package.
L
And
inside
the
particular
so
far,
we're
essentially
doing
OTT
we're
tunneling
the
beer
package,
but
inside
in
a
area
or
a
s
when,
when
you
have
enough
routers
supporting
beer,
you
can
also
turn
on.
You
can
also
start
doing
beer
in
there
and
notice
that
when
you
do
that,
you
were
still
so
far
we're
still
talking
about
single
beer
subdomain,
it's
just
a
part
of
it.
L
Beijing
I'll
just
skip
it
for
now,
and
so
we
don't
have
enough
time
now
so
far
we
were
all
really.
We
haven't
really
talked
about
service,
yet
this
is
just
a
single
sittings
and
then
network,
but
if
you
imagine
that
is
200
in
the
middle
does
not
belong
to
that
operator.
South
it
belongs
to
a
service
provider
like
AT&T,
you
Rison,
whoever
what
that
means
is
that
AT&T
or
Verizon
is
providing
multicast
serve
transfer
service
to
this
customer.
L
L
So
again,
provided
by
s200
it's
at
a
beer
level,
but
there
is
no
be
fer
for
the
provider,
so
it
does
not
maintain
customer
states
and,
more
importantly,
a
provider
can
provide
beer
transport
services
to
different
customers
independently
and
those
different
customers,
beer
domain
or
or
a
PFR
ideal
location.
They
they
could
conflict.
We
can
still
just
support
that.
L
To
do
that,
we
should
introduce.
We
need
to
attach
a
raw
distinguisher
to
the
beer
prefixes
and
now
a
b
FR
or
in
a
service
provider
just
need
to
scale
on
the
number
of
pips.
One
example
is
that,
if
you
need
to
support
256
beer
customers,
then
you
will
need
to
maintain
256
bits
and
if
each
v
is
256
bit
numb,
because
your
BSL
is
2236,
that
means
you
will
maintain
success
for
64,000
routes.
For
beer.
L
No,
is
that
this
should
not
be
a
big
concern,
because
on
the
unica
side
we
can
do
many,
many
routes
already
and
the
beer
route
and
unique
ice
road.
There's
really
no
big
difference
there
and
also
256
beer
customers.
It
sounds
small,
but
it's
actually
I
think
it's
practical,
because
notice
that
this
we're
doing
the
beer
transport
service
and
that
beer,
the
customers
beer,
can
be
used
to
do
for
many
many
things.
For
example,
the
customers.
Beer,
could
be
its
ma
p.m.
provider.
How
now
so?
L
P
L
The
provider
can
count
traffic
and
Bo
or
and
Bo
accordingly,
for
example,
at
entry
points
the
income,
beer,
packets
least
beer
label-
you
can
counter
it
Aleksey
points.
You
can
count.
I'll
go
in
focus
package
associate
with
each
outgoing
beer
label
that
it
imposes
so
summary
we
can
provide
scalable
particles
at
service
and
as
email
enabled
by
year,
it's
actually
encrypt
incremental
e
expandable,
with
policy
control
and
building.
So
there
I
escaped
a
lot
of
details,
it's
in
the
in
the
spec
and
the
graft
and,
of
course
the
job
can
be
further
improved.
D
256
comment:
ok,
that's
maybe
we
have
256
is
not
a
lot.
This
is
what
my
so.
This
is
what
my
dilemma
of
this
is
the.
When
we
started
beer,
the
whole
paradigm
was,
we
need
something
simpler
and
the
beauty
of
beer
was.
It
was
really
simple
and
for
a
first
time,
I
think
people
who
do
not
understand
multicast
could
actually
follow
it.
D
Those
are
problem
that
can
be
technically
solved,
and
this
draft
solves
all
those
problem,
no
question
about
that.
The
thing
is:
are
we
doing
ourselves
a
favor,
because
we
introducing
a
level
of
complications
to
deal
with
things
like
that?
I
would
so
before
we
do.
That.
I
would
really
like
to
understand
the
practical
use
case.
Otherwise
we
don't
have
a
complicated
standard
that
do
not
solve
your
case.
D
I
have
not
seen
personally
a
multicast
deployed
in
a
network
where
the
edge
devices
who
are
doing
it
before
anything
in
between
and
here
we're
trying
to
do
those
terminals
and
everything
and
may
as
well
do
English
application
and
other
stuff
like
this
and
I'm
just
saying
it's.
We
adding
complexity
levels
and,
and
that
will
at
some
point
turn
turn
away.
People
from
from
No.
A
D
P
D
J
Yeah
told
us
occurred
so
yeah
a
little
bit
also
around
this
building
and
they'll
come
issue
off.
Is
this
the
right
time
to
do
this
right?
So
on
the
positive
side?
I
certainly
think
we
should
have
a
good
feeling
whether
it
will
be
possible
to
sell
year
as
a
service
right.
So
the
goal
is
great
whether
we
should
work
through
all
the
details
right
now
to
make
it
into
you
know,
standards
procedures,
I
think,
is
a
different
question
and
from
the
use
cases
I
think
they're,
they're
too
big
ones.
J
To
me
right,
the
first
one
is
applications
using
actually
your
like
the
stuff
we
talked
about
and
where
ever
far,
not
at
the
point
where
this
happens
right
I
would
like
to
accelerate
that
once
that
happens,
pretty
sure
we
need
this.
The
other
one
seems
to
be
I'm.
A
service
provider
offering
some
multicast
service
and
I
have
a
choice
of
what
type
of
underlying
service
I
can
buy
right
and,
if
I'm
only
offering
IP
multicast
services
like
VPNs
or
so
to
my
customers
and
I'm
trying
to
buy
underlying
connectivity
right.
J
A
J
A
A
Who
thinks
without
like
saying
it
dot,
but
I
mean
we
see
shadow
that
this
is
something
could
be
interesting
to
the
working
group,
possibly
for
adoption,
all
right
good.
So
if
that's
the
case,
you
know,
let's
focus
that
input
on
what
are
these
use
cases
we
solve
it,
and
it's
always
this
challenge.
We
can
treat
the
technology,
but
there's
often
business
barriers
or
licensing
barriers
and
what
it
would
be.
If
we
can,
you
know,
if
you
guys
know,
operators
are
in
touch
with
operators
where
they're
looking
at
some
thought.