►
From YouTube: IETF101-BIER-20180321-1330
Description
BIER meeting session at IETF101
2018/03/21 1330
https://datatracker.ietf.org/meeting/101/proceedings/
A
The
update
on
the
changes
next
slide,
please
so
just
to
refresh
every
memory.
I'm
gonna
start
with
part,
which
is
a
data
path.
So
basically,
there
is
no
data
path
changes
in
this
proposal.
The
main
proposal
is
again
to
try
to
signal
ping
access
networks
through
a
beer
core.
So
what
that
means
is
that,
when
the
people
beam
signaling
on
the
ping
domain
arrives
at
the
boundary
beer
router,
we
need
to
terminate
that
pim
signaling
and
somehow
signal
the
the
need
for
the
join
or
the
prune
throughout
the
beer
domain.
A
To
signal
that,
in
this
picture
on
p2
and
p4
as
an
example,
they
terminate
the
p.m.
signaling
and
then
they
need
to
signal
the
pin
joint
to
P,
p1
and
p3.
To
do
that,
we
look
at
the
source
in
this
case
p1,
and
we
try
to
resolve
the
source
via
an
egress
beer
boundary
router,
and
this
is
where
most
of
the
comments
were
in.
Basically,
the
questions
were
what
the
comments
were.
How
do
we
find
out
the
egress
beer
boundary
router
next
next?
One
please
so
I
already
explained.
Thank
you.
A
A
So
basically
you
create
a
static
route
with
the
source,
and
you
say
next
hop
is
the
egress
beer,
boundary
router,
so
obviously
to
resolve
the
egress
beer
boundary
router,
it's
a
recursive
lookup
and
eventually
you
will
get
another,
be
router
within
the
beer
domain
and
then
you
can
actually
put
the
right
bits
on
the
bitterness
index
and
forward
that
signaling
packet
to
the
egress
boundary
router,
which
eventually
removes
the
the
beer
header
and
forwards
the
ping
packet
all
the
way
to
the
source.
The
second
pretty
obvious
one
is
BGP.
A
What
that
means
is
that
between
the
egress
beer,
boundary
router
and
the
ingress
beer
boundary
router,
the
you
create
the
bgp
session
and
you
advertise
their
beer
prix
fixe
ID
through
that
bgp
session.
Again
it
becomes
a
recursive
lookup
and
you
can
find
your
path
throughout
the
beer
domain
via
that
recursive
lookup.
A
The
third
is
some
operators
that
have
a
ASPR
or
a
ABR,
and
these
routers.
They
summarize
the
route
and
we
can
use
the
field
in
the
summarization
route,
which
is
the
source
IP
to
actually
figure
out
where
the
egress
speed
boundary
router
is
so.
In
short,
what
we
are
saying
here
is
that
the
ABR
is
the
egress
beer
boundary
router,
that
did
the
summarization
of
the
route
and
the
last
but
not
least,
is
the
CE
SPF.
Basically,
the
idea
here
is
when
we
advertise
the
beer
extensions
via
IGP.
A
Every
router
knows
who
are
the
boundary
router,
and
we
can
do
some
kind
of
constrained
shortest
path
to
look
up,
saying
that
I
want
to
go
to
this
egress
beer,
boundary
router
and
hopefully
the
routing
returns
the
right
next
hop
for
that
next
slide,
please.
So,
since
it
has
become
adopted
by
the
working
group,
we
consider
this
solution.
Complete
I
believe
there
has
been
some
implementation
of
the
solution
already
and
definitely
we
are
seeking
more
comments.
You
know
any
comments
are
more
than
welcome,
but
our
intent
is
to
go
last
call
on
the
next
ITF.
A
B
C
D
With
us
I
think
this
is
a
great
solution.
I
just
had
like
one
very
minor,
maybe
silly
comment
but
to
me
like
ingress
and
egress
is
use
like
opposite
or
what
I
would
expect
in
this
document.
It's
always
fun,
it's
hard
to
read
and
I
kind
of
wonder.
Is
it
just
me
or
what
do
people
think
in
general?
What
is
the
best
way
to
use
those
terms?
Yeah.
B
This
is
Greg
I
kinda
wanted
the
same
thing.
I
understand
the
intent
right.
There's
data
egress
and
there's
control,
egress
I,
don't
I,
don't
have
a
suggestion
how
to
clean
it
up,
but
it
was
kind
of
hard
for
a
while,
maybe
I,
look
at
the
acronym
is
different
and
once
I
look
at
the
academic
I
know
I'm
talking
message
versus
data,
it
might
work.
Just
read
it
a
few
more
times
just
kinda.
D
B
B
B
G
B
E
E
E
Skip
this
slide
because
I
we
have
a
Virginia
so
to
calculate
the
foreign
past,
and
let
me
explain
some
terms
first,
so
calculation
is
a
prior
to
topology
may
be
subject
to
some
constraints.
Here,
the
topology
is
basic,
a
graph
of
nodes
and
links,
and
each
each
link
has
set
of
characteristics,
including
metric
or
color
or
whatever
and
algorithm
examples
are
shortest
path.
First,
could
be
spanning
tree
in
the
future.
The
constraints
are
like
use,
T
metric,
whatever
tribe
metric,
or
it
could
be
excluding
the
railings
things
like
that.
E
Those
are
just
examples
next
time
and
then,
when
it
comes
to
bar
and
IP
a
field,
the
bar
face
appear:
algorithm
IPA
is
ICP
algorithm,
so
both
can
be
interpreted
as
two
components.
Why
is
the
algorithm?
The
other
one
is
constrained,
so
we
have
this,
be
a
beer,
specific
algorithm
and
BC
your
specific
specific
constraints,
and
correspondingly
we
have
routing
algorithm
routing
constraints,
so
the
bar
is
basically
the
be
a
plus
BC.
Ipa
is
basically
are
a
pass
see
next
time,
so
in
general
the
rules
are
like
this.
E
We
start
with
the
topology,
which
could
be
the
default
apology
or
a
multi
topology
polygon,
multi
topology.
We
apply
the
peer
specific
constraints
that
gives
you
the
pc
princess
X,
and
then
you
apply
the
routing
kind
concern
constraints
you
get
you
get
next
one
the
RCEP
C
X,
and
then
you
determine
the
algorithm
to
you
to
use
the
currently
that
for
simplicity.
If
the
BA
is
not
now,
we
just
use
the
be
recordin.
If
otherwise
we
just
use
the
routing
algorithm
in
the
future.
This
could
be
enhanced,
but
for
now
let's
just
go.
E
E
This
second
bullet
was
added
recently.
It
was
not
in
the
spec
in
our
draft.
It
was
after
some
discussions
and
not
quarters.
Recently.
Yesterday,
we
believe
that
it's
it's
good,
that
that
we
can
allow
the
override
in
the
future
by
individual
and
power
IP
burials,
but
in
general
the
rules
are
what
we
just
talked
about
in
the
earlier
slide,
but
some
flexibility
we
when
we
define
individual
power
IP
varies
in
the
future
with
it
could
be
algorithm.
E
And
another
important
point
is
that,
if
you're
doing
a
calculation
for
of
a
particular
sub
domain
and
you're
configure
power,
IP
a
value
is
different
from
another
router.
That
sickening
for
the
same
subdomain,
then
that
the
other
router
rule
will
be
treated
at
some
Inc,
incapable
support
in
theater
how
daddy's
handouts
there
are
different
ways
actually
I'm
going
to
talk
about
in
the
next
presentation.
E
H
B
H
H
Just
did
not
follow
everything
and
the
slides
may
be
yellow
with
confusing
there.
The
whole
intent
of
bar
an
IPA
is
you
know
if
you
have
a
bar
0,
it's
simple
yeah,
like
whatever
is
in
an
IPA
field,
dictates
your
algorithms,
an
IG,
p
dictates
IGP
and
in
case
the
bar
is
not
zero.
Then
we
really
will
leave
that
the
definition.
So
we
have
an
example
here.
What
can
it
be?
But
we
really
leave
the
definition
to
that
nonzero
value.
H
What
would
it
actually
mean
and
what
type
of
values
in
in
the
IPA
feels
I
allowed
or
not
allowed,
because
hypothetic
like
otherwise
we're
going
to
go
into
hypothetical
discussion
which
we,
which
we
try
to
avoid?
There
is
some
framework,
but
it
allows
independent
bar
it.
It
allows
a
GP
running
and
leaves
the
place
for
for
both
of
those
two
to
interact
in
the
kind
of
simplified.
I
Well,
I'm
here
I
Cisco
and
also
made
one
clarification
here
still
so
if
bar
is
zero,
so
we
look
at
the
the
IPA
owned
only,
but
just
to
make
clear
we
when
that's
the
case,
we
don't
expect
a
specific
calculation
to
happen
by
beer
by
creating
topology
right
with
we
depend
on
a
GP
topology
to
be
there.
That's
what
we
want
to
point
at
so
we're
not
proposing
any
specific
calculations
just
for
for
beer,
correct,
then,
and
there's
also
implementation.
J
B
E
E
This
drafts,
your
algorithm
draft,
has
one
proposal
which
is
method
number
four
in
this
slide
deck.
That
draft
also
covers
other
topics,
but
in
this
presentation,
which
is
only
going
to
focus
on
this
particular
problem
next
time,
so
method
number
one
is
was
already
talked
about
in
the
beer
architectures
back.
E
It
could
be
that
you
are
mark
or
links
to
that
beer
incapable
router
with
certain
colors
a
prong,
and
then
you
D,
flying
defying
a
flex
algorithm
to
exclude
those
belong.
Browning's
and
also
if
you
Eve
already,
you
have
a
base
flex
I'll
go:
let's
say
you
exclude
railings,
then
you
have
to
copy
those
rules
over
to
this
new
flex.
I'll
go.
E
So
that
means
that
you
have
to
have
a
extra
flex
algorithm
for
each
base.
Flex
I'll
go
just
for
the
pier
purpose
and
if
a
router
is
upgraded
to
support
beer,
then
you
have
to
remove
those
brown
color
on
those
things
just
one
second,
and
so
every
shown
with
this
he
says
you
smarty
topology,
if
you're
not
using
flexible,
ready,
okay.
E
The
Flex
I'll
go
for
no,
oh
I,
think
yeah
I
think
I
covered
that
the
next
slide.
Okay,
next
is
just
that's
beautifying,
Affleck's
Argo,
saying
that
escape
bearing
here
/
routers
and
then
sit
very
similar
next
slide,
so
finally
come
to
appear
at
meta
number.
Four.
We
basically
define
bar
value.
1
here
is
peer,
specific
algorithm
here.
Well,
the
algorithm
is
the
SPF.
E
E
Have
some
comparisons
here
against
number
two
and
three
you
just
you
have
a
less
signaling
overhead
provision,
insignia,
overhead
and
and
in
particularly
number
three,
you
are
basically
finding
something
specific
to
beer
in
the
in
the
Flex
alcohol,
then
B
to
number
four
and
number
one
implementation
wise
number.
Four.
Is
it's
easier?
Basically,
when
you
put
a
round
out
into
the
candidate
list,
you
just
skip
if
it
turns
for
the
beer,
and
the
rest
is
just
the
same
now,
one
important.
E
Property
here
is
that
with
method
number
one
you
have
congruent
forward
in
between
my
beer
and
your
a
unicast
with
number
four,
essentially
your
you're
making
them
in
congruent,
but
that
is
something
that's
may
be
desired
in
some
situations
or
maybe
not
not
desire
in
some
other
situations
next
time.
So
we
believe
that
doing
it.
This
way
has
a
practical,
practical
use
and
advantages
depending
on
the
scenario.
E
F
Tony
P,
though,
I
mean
as
a
practical
observation
as
well.
I
mean
we
don't
have
to
define
anything
at
all
in
a
sense
right.
We
can
support
non
congruent
topologies
by
using
multi
topology
right
in
people
setting
up
tunnels
and
putting
them
into
multi
topology.
The
beer,
as
you
stand
today,
doesn't
need
really
any
extensions
to
work,
but
all
of
these
things
have
different
advantages,
disadvantages
and
preconditions.
What
you
have
to
deploy
to
make
it
work.
L
And
to
describe
which
I'm
just
a
quick
comment
in
everything
you're
presenting
you
are
assuming
that
the
ITP
is
link
state,
which
is
fine,
because
I
mean
if
you
read
the
the
architecture
document
in
beer,
you
can
feel
that
the
author's
are
thinking
in
terms
of
link
state
but
I.
Think
that
deserves
to
be
mentioned.
Beer
in
itself
is
not
restricted
to
beer,
to
link
state
and
here
you're,
assuming
link
state
you're.
I
So
my
first
general
comment
would
be
that
that's
a
building,
a
topology
that
includes
your
beer
routers
is
very
topology
specific
right,
because
if
your
primary
path
is
not
being
capable,
you
expect
them
to
be
another
path
to
be
be
a
capable
right.
So,
but
that's
not
good
enough,
because
if
you
want
redundancy,
you
have
to
need
to
have
another
path.
Yet
that
has
a
beer
router
in
order
to
you
know
to
periodic
converts
so
I'm,
not
so
convinced
that
this
is
actually
a
good
way
to
deal
with.
I
E
So
I
don't
see
why
we
are
creating
something
that
duplicate
effects
are
in
fact,
this
method
with
this
method
when
it
comes
to
provisioning
or
signaling
it
exactly
the
same,
saves
you
travel
from
you
have
having
to
create
a
duplicate.
A
flexural
go
or
topology
accept
a
twist
appear
removed
from
the
in
cable
as
well
from
that
high-poverty.
So
I
said
part
I
don't
understand,
but
as
far
as
requiring
your
first
comment,
I
think
that
even
for
the
method
number
one,
you
also
need
to
have
your
peer
or
keep
operators.
E
E
F
You
to
the
list
and
I
mean
don't
forget
that,
yes,
things
work,
you
know,
every
solution
is
a
simple
solutions
if
it
means
that
no
assumptions
to
make
it
work
right,
but
take
you
to
the
list,
discuss
the
stuff.
Let's
wrap
this
thing:
let's
keep
the
stuff
flexible,
alright,
but
we
have
to
move
on
right.
Yeah.
M
M
B
D
Yeah
hi
I'm,
Stig,
I'm
gonna
talk
about
MTU
discovery,
so
I
think
we
need
to
talk
about
more
about
MTU
discovery
in
this
group,
and
this
is
like
one
proposal.
We
have
a
smaller
proposal
or
actually
working
with
document
already
about
MTU
discovery.
I
think
it's
worth
discussing
more.
You
know
what
approaches
we
should
follow
and
what's
the
benefits
are
and
so
on
different
approaches,
so
I'm
sure
you
agree,
we
need
them
to
discovering.
D
Basically,
when
a
IP
packet
enters
up
your
domain,
you
need
to
be
able
to
send
packet
too
big
or
something
for
our
IP
MTU
discovery
to
work.
Also,
when
you
do
overlays
like
him
or
IGMP,
and
so
only
need
to
find
the
MTU
so
that
we
can
send
maximum
size
joins
in
packets
through
our
computers
and
few
reports,
we
want
to
pack
as
many
as
comedy's
so
whatever
inside
those
reports
as
we
can.
D
So
what
I'm
proposing
here
is
a
way
of
doing
a
subdomain
empty
you.
So
basically,
instead
of
the
usual
path,
MTU
is
finding
them
to
you.
That
covers
the
whole
gear
domain
and
one
other
advantage
to
that
is
that
it
doesn't
depend
on
the
receiver
set
usually
with
puff
MTU
discovery.
Whenever
a
new
receiver
joints
join
some
of
the
cost
flow
you
might
change
for.
The
actual
MTU
is
for
that
tree
or
that
flow,
so
that
gets
complicated.
Also,
if
there's
some
kind
of
rerouting
and
then
the
empty,
you
might
change
at
any
time.
D
If
you
do
path,
MTU
discovery
by
doing
a
subdomain
m2u,
we
can
make
it
more
static
in
a
way.
It
also
has
some
text
in
the
draft
about
how
he
might
if
a
link
goes
down,
you
may
not
update
the
MTU
right
away
if
it
goes
below,
I
mean
becomes
higher,
rather
just
be
kind
of
slow
to
update
them
to
you
just
try
to
make
them
to
kind
of
more
stable.
D
J
Cylinder
Cisco
Systems
I,
just
looked
at
this
really
quick,
I
mean
I,
read
the
draft
really
quickly,
but
if
the
IGP
domain
and
the
beer
domain
are
the
same,
this
empty
you
I,
don't
think
many
devices
support
different
multicast
and
unicast
em
to
use
it
might
be
useful
to
other
applications,
make
it
general
lies
rather
than
putting
it
within
the
advertisement
specific
to
beer.
I
know.
D
B
B
Like
you
look
into
slider
says
it
is
useful
for
beer
ingress
router
to
know
why
it
seems
to
me
more
of
a
configuration
like
evaluation,
because
if
it's
my
overlay
domain,
I'm
set
9k
and
I'm
done
like
the
link,
I
may
have
missed
one
and
I'd
like
to
have
a
tool
to
find
that
one
but
I'm
not
crossing
domains
where
some
other
operator
has
something
not
understanding
that
I'm
encapsulated
in
40.
But.
B
Don't
think
operationally,
that's
really
how
you
build
a
network.
I
mean
really
it's
like.
If
I
have
an
operator,
Network
and
I
have
I
know
I'm
doing
overlay,
I'm
I've
got
modern
Ethernet
interfaces,
I'm
set
9k
across
the
board.
I
may
have
messed
up
and
not
done
why
but
I'm
not
crossing
my
domain.
The
normal
path
into
you
for
IP
is
and
N
and
I'm
out
of
my
domain
into
someone
else's
and
I.
B
D
B
D
It
is
that
problem,
so
what
we
are
doing
today
with
multicast
ipv6
multicast
just
goes
to
de-puff
MTU
discovery
and
send
packet
to
begin
zone
and
yeah.
Basically,
what
routers
have
to
do
is
they
need
to
look
at
their
well?
What
happens
today
is
you.
You
basically
get
the
packet
too
big
in
response
to
a
multicast
packet,
so
it
would
get
forwarded
down
the
multicast
tree
and,
at
some
point
some
router
might
send
a
message
back
saying
this
is
too
big.
You
need
to
keep
updating.
What
is
your
empty
you
for
the
tree
telling.
M
Okay,
I
was
never
named
Tara
Secord
I
was
never.
You
know,
persuaded
that
the
active
probing
would
scale
I
mean
beer
domains
may
be
smaller
for
on
a
you
know,
individual
VI
ft
basis,
so
it
might
be
more
useful
here,
but
I
think
the
most
important
stuff
was
to
put
in
the
advanced
ipv6
socket
API.
This
stuff
default
is
1280,
and
hopefully
it's
good
enough
for
you
when
you
do
multicast
so
get
get
away
with
the
problem.
The.
D
A
A
G
D
Basin
got
the
static,
though
no,
basically
you
would
look
at
say
the
layer,
3
MTU
or
IP
MTU
craps
of
all
your
links
in
the
beer
domain
and
you
would
have
to
for
each
each
Li
links
or
interfaces.
You'll
have
to
subtract
that
beer
header
to
find
out
that
the
beer
empty
but
yeah.
If
you
could
find
the
layer,
3
MTU
or
your
beer
domain,
and
you
assume
that
the
uncaps
raishin
size
is
fixed
on
the
Heather
sites.
Then
you
could
that's.
D
Depends
a
little
bit
whether
you
it
might
be
fixed
in
a
subdomain,
but
it
depends
a
little
bit
whether
you're
doing
say
you
know
here
with
an
MPLS
label
if
you're
doing
Bo,
if
not
ribeirão
like
you
were
six
or
something
right:
flashlight,
okay,
so
yeah!
So
I
wanted
mainly
to
our
discussion
whether
this
is
useful
and
stuff,
and
please
comment
on
the
list,
but
this
last
slide
just
talks
about
how
you
actually
do
this.
So
the
idea
is
how
router
looks
at
all
these
local
interfaces,
with
your
neighbors
in
the
subdomain
and
finds
out.
D
Basically,
what
is
the
smallest
empty
of
all
my
local
interfaces,
so
you
basically
announced
in
our
so
as
sorry
OSPF
for
eius
eius.
What
is
the
largest
packet
I
can
forward
out
of
any
of
my
local
interfaces,
and
then
you
know
a
router
can
look
at
what
everyone
announces.
There
are
no
severe
defects,
tagged
with
with
this
MTU,
so
you
can
say:
okay,
this
is
the
minimum
or
what
everyone
announces.
So
that's
my
that's
our
subdomain
empty
yeah!
That's.
D
B
Discussion
usually
takes
place
in
a
better
form
if
it's
a
part
of
the
working
group
work
so
who
thinks
this
is
something
we
should
adopt
as
we're
gonna
group
item,
you
see
some
hands
in
there
too.
It's
worth
taking
the
list
at
least
alright,
and
maybe
maybe
the
drafts
merged
in
some
way.
You
know,
we've
talked
about
overall
solutions.
Sorry,
let's
take
it.
The
list
Thanks
stig
next.
M
M
Okay,
this
is
just
a
single
one:
slight
update
on
the
beauty,
forwarding
architecture
through
adoption,
so
there
was
the
ask
from
Illya
to
basically
better
describe
the
forwarding
plane,
differences
between
beer,
te
and
beer,
and
so
that's
what
I,
added
and
actually
now,
with
with
the
other
work,
we've
done.
There's
there's
one.
You
know
bit
of
clarification
needed,
so
the
really
main
difference
is
that
in
beer
you're,
looking
at
all
the
bits,
because
they're
all
B
F
ers
that
you
may
want
to
forward
to
while
in
beer
te,
every
adjacency
is
only
interesting
to
you.
M
If
it's
a
direct
adjacency
that
you
have
so
you're,
basically
applying
on
ingress
with
a
package
some-some
end
of
only
those
bits
that
are
really
your
known,
local
adjacencies
and
you
ignore
all
the
others.
So
that's
really
the
main
difference,
then,
as
far
as
the
representation
of
how
we
have
it
in
the
document.
So
normally
the
way
we've
been
thinking
about
a
beer
te,
the
the
forwarding
bitmask
the
stuff
that
you
end
when
you
send
out
a
packet
that
actually
would
be
the
same
for
all
the
copies
in
normal
beer
te.
M
So
now,
when
we
sat
down
this
week
and
we're
thinking
about
the
the
other
stuff
that
you'll
see
about
the
traffic
engineering
and
and
perf,
we
figure
out
that
we'll
also
have
the
case
when
we
want
to
have
better
OEM,
where
the
forwarding
mass
would
also
be
individually
calculated
on
a
per
outgoing
interface
and
I.
Think
that
will
become
clear
from
another
presentation
so
that
that's
pretty
much.
M
Okay,
so
they're,
a
bunch
of
this
is
all
just
not
for
via
people's
so
skip
over.
All
of
that
that's
skip,
skip,
skip,
skip
it
to
say
gang
ding,
because
all
of
that
this
little
big,
yeah,
okay,
stop
there
so
yeah
right.
So
the
the
new
thing
and
that's
going
to
be
in
the
other
presentation
that
we're
bringing
in
is
basically
really
the
dual
life
life
stuff.
So
that's
better
slide
right.
So
then,
basically
I
think
what
we
haven't
really
described
that
well
in
the
beer.
M
Forwarding
architecture,
which
is
more
interesting
for
the
controller,
is
the
fact
that
how
do
you
think
about
on
the
sender
side
application
how
to
set
the
bits
for
a
particular
set
of
receivers
normally
in
beer,
it's
just
one
bit
per
receiver
and
the
equivalent
in
beer
te
would
be.
Somebody
calculates
you
for
every
receiver,
a
bit
string
and
you
just
all
them
together.
For
the
list
of
receivers
you
want
to
have
right,
because
every
bit
string
would
indicate
a
path
and
if
you
just
have
multiple
receiver
and
the
other
path
to
them.
M
Well,
you
get
basically
your
distribution
in
the
network
across
your
traffic
engineered
path,
and
so
that's
basically
kind
of
the
starting
point
of
the
model
that
ultimately
would
become.
You
know.
Parts
of
an
API
between
a
BFI
are
asking
a
controller.
Please
give
me
for
a
set
of
receivers
or
for
the
superset
of
all
receivers,
a
traffic
engineer
pairs
the
way
I
can
see
it
is
that
you
will
have
policies
like
saying
so.
The
VPN
foobar
should
basically
get
a
pass.
M
That
XYZ
ask
the
controller,
for
you
know,
pass
for
XYZ,
so
that's
kind
of
the
operational
model
to
work
out
between
a
BF
ir
and
a
pc
controller.
And,
of
course,
this
thing
kind
of
free,
calculating
everything,
doesn't
work
for
Steiner
trees,
so
there
obviously
are
different
forms
next
slide.
So
here
is
a
basically
the
overview
kind
of
expanded
from
what's
in
the
forwarding
architecture,
with
the
new
aspect,
so
we
had
that
by
our
ER
and
then
going
to
controller
host
and
in
the
origin,
original
forwarding,
plane
architecture.
M
We
didn't
include
considerations
for
the
IGP
and
in
this
atius
architecture
we
expanded
that
with
proposals
on
how
to
leverage
the
IGP
in
similar
shapes
and
forms
like
it
would
be
done
in
rsvp-te
or
even
in
segments
routing
in
so
far
as
that,
the
IGP
is
optional,
but
it
could
basically,
if
used,
provide
distribution
of
the
beer
te
topology
so
that
the
BFI
r
could
calculate
path
itself.
And/Or
that
all
the
nodes
in
the
network
could
basically
figure
implement.
M
Sisseton
sees
in
bid
configuration
and
even
some
auto
configuration
of
the
more
complex
adjacencies
without
the
help
of
a
controller.
The
controller
will
always
be
required
for
the
initial
provisioning,
but
then
you
know
during
the
build
of
traffic,
we
have
the
alternatives
to
use
the
controller
explicitly
or
leverage
the
IGP
so
kind
of
that's
the
highlight
next
slide
right.
So
this
is
the
data
model.
I
just
wanted
to
compare
it
quickly
to
beer
right
in
beer.
M
We
have
in
the
IGP
the
announcement
from
every
node
what
basically
his
own
B
fer
ID,
is
the
MPLS
label
range,
and
then
you
know
more
stuff.
Like
all
the
IGP
stuff,
we
said
planet
via
the
IGP
gets
into
the
routing
table
in
a
node,
the
routing
tables,
IP
identifier,
and
then
the
next
stop.
So
let's
basically
take
in
the
calculation
going
down
to
the
forwarding
table
for
which
we
calculate
the
FV
ends
next
slide.
So
this
is
basically
the
equivalent
in
beer
te,
and
the
big
difference,
of
course,
is
we're
not
doing
shortest
path.
M
Calculation,
so
the
whole
kind
of
routing
table
level
goes
away,
but
instead
what
we
have
is
her
node,
exactly
the
local
adjacencies,
all
the
bits
that
are
directly
adjacent
to
a
node
given
bits
for
every
node.
That
stuff
would
come
down
from
the
controller
and
configured
on
every
individual
node
and
then,
basically,
we
could
flood
this
in
the
IGP
and
then
basically
the
BFI
our
could
calculate
they
pass
through
it.
We
can
also
plan
it
through
the
topology
and
then
basically
from
your
own
configuration
and
the
known
topology,
we
can
consistency,
checks.
Oh
wait.
M
M
So
that's
why
the
proposal
for
the
IGP
stuff
would
really
be
that
we
consider
really
two
instances
the
configured
and
the
operational
one
and
clearly
distinguish
on
them
and
have
the
different
operations
run
on
them
and
depending
on
which
operations
we
want
to
distribute
in
the
network.
We
would
need
to
distribute
both
instance
of
them,
and
maybe
there
is
a
way
to
make
it
into
one
compress
it
so
what
that
would
be
future
work
for
the
IGP
encoding
it's
like,
so
this
is
basically,
then
they
kind
of
not
yet
complete,
correct,
abstract
form.
M
Right,
so
these
are
the
and
trying
to
really
get
to
the
data
model
in
gang
of
these.
Okay
next
slide
yeah.
So
this
is
all
I
think
it's
when
we're
running
out
of
time.
Let's
take
it
to
the
next
one.
So
this
this
maybe
one
is
the
interesting
configuration
right
when
we
don't
want
to
do
replication
on
every
node
in
the
network,
and
we
have
the
routed
adjacencies.
One
of
the
typical
uses
would
be.
M
You
want
to
be
able
to
just
send
on
these
notes
to
either
of
these
two
nodes
as
the
traffic
engineering
things
that
all
these
adjacent
and
we
can
automatically
build
them.
This
guy's
only
announcing
the
adjacencies
these
people
second,
the
bids,
and
that
would
be
auto-configuration
through
the
ITP
right.
So,
if
we're
running
out
of
time,
I
think
that
was
kind
of
the
highlight
there.
You
know
more
details,
it's
it's
a
start
of
larger
work
and
yeah
I.
M
M
So
discuss
determine
the
order
of
the
next
steps
right
for
me:
kind
of
building
for
the
topologies,
the
yang
model
kind
of
configuring,
the
beer
domain.
That
seems
obviously
like
the
first
step,
then
PCP
protocol
to
control
from
the
controller
and
then
slowly
trying
to
figure
out
where
to
go
with
the
IGP
and
then,
of
course
improve
the
framework
according
to
that
guidelines
from
T's
and
then,
basically,
all
the
cool
things
about
prep
and
OEM
that
were.
N
B
Was
this
extent
work
this?
You
said
dr
t,
he
was
an
intent.
You
said
dr
clear,
your
tea
so
take
guide
in
term
cases
where
you're
going
that
oh.
M
O
O
Describes
the
use
case
of
multicast
HTTP
using
beer
next
slide,
please.
So
in
terms
of
like
a
quick
recap,
this
is
an
realization
of
the
use
cap
use
cases
and
in
that
a
few
requirements
were
listed
as
well
as
certain
operational
details
were
described
in
terms
of
how
to
realize
the
use
case
over
a
beer,
so
in
Pacifica.
O
So
if
we
go
to
the
next
slide,
so
in
terms
of
applicability
for
of
the
use
case,
so
this
HT
t
multicast
can
be
also
seen
to
be
useful
or
related
to
other
use.
Cases
such
as
virtual
reality
and
v2x
use
cases
in
case
of
virtual
reality.
There
are
situations
where
several
users
join
a
dear
session
at
the
same
time
and
centered
around
a
joint
event,
and
we
see
multiple
requests
are
sent
for
the
same
content
at
any
point
of
time.
O
What
like
exactly
is
this
this
this
use
case
and
how
it
can
be
realized.
So
just
to
give
a
brief
background.
Http
requests
and
response
are
routed.
Based
on
the
URI
in
this
use
case
and
URI
is
used
to
identify
source
and
destination,
and
this
requests
are
routed
using
path
based
forwarding
mechanism,
and
this
request
is,
as
of
today
like
if
it's
an
HTTP
based
request,
the
path
based
forwarding
can
be
done
using
a
service
router.
The
next
slide,
please.
O
So
it
says
this
use
case
can
be
realized
using
existing
transport
technology,
such
as
Sdn,
where
the
we
can
use
the
Sdn
feature
of
path
based
forwarding
through
this
wild
card
matching
fields.
What
happens
there
is
this?
The
ethernet
frame
format
a
layer
2
can
represent
can
represent
the
topological
links
of
a
specific
forwarding
path
in
the
transport
network,
and
this
in
this
approach
or
the
implementation.
The
ipv6
source
and
destination
field
is
being
used
for
storing
this
bit
array.
Information
next
slide.
O
So
with
respect
to
existing
solutions,
it
is
again
just
to
clarify
this
is
completely
an
overlay
solution
over
beer,
and
this
is
more
like
it's
a
multicast
where
it
is
an
ad-hoc
multicast,
that
is,
the
multicast.
Relationships
are
built
at
the
level
of
each
HTTP
response
and
therefore
can
vary
from
request
response
transactions,
whereas
this
H
multicast
flow
aggregators
assume
a
stable
multicast
relation
and
that
can
be
mapped
into
IP.
A
multicast
next
slide,
please
so
I
think
so
so
in
terms
of
next
step,
is
this
like?
O
O
L
O
B
As
a
chair,
this
is
a
use
case
and
if
the
use
case
is
interesting,
I
don't
think
it's
outside
charter.
Necessarily,
if
there's
elements
of
it
that
require
collaboration
with
other
work,
I
would,
you
know,
definitely
reach
out,
but
insulting
me
well.
I
think
there
are
dependencies
like
you
know.
Api
is
for.
P
Rachel
on
this
use
case,
yeah
Mick
said
to
me,
but
I'm
not
sure
it
should
be
in
biro
I'm,
not
sure,
because
you
know
it
looks
like
to
me.
It
should
be
related.
You
know
we
do
delivery
or
something
to
capita
from
the
network
updates
or
something
and
Network
layer
protocols.
So
it
maybe
can
be
a
story
by
some.
You
know
HTTP
or
it
may
be
a
application
layer
than
you
know,
just
a
signaling
or
something
like
that,
but
I'm
not
sure
a
beer,
hats
use
of
this
company.
So
I,
don't
I,
don't
understand.
O
P
I
Just
quickly
so
one
of
the
key
benefits
of
Ojai
Cisco,
one
of
the
key
benefits
of
beer,
is
that
there's
no
need
to
build
a
tree
right
sure
you
have
immediate
access
to
all
your
endpoints
without
having
to
tell
beams
I/o
now
build
me
a
tree
and
this
kind
of
joint.
So
it's
an
infinite
amount
of
combinations.
You
have
on
your
fingertips
right.
That's.
M
Why
beer
is
great
for
this
yeah
just
just
to
answer
to
Rachel's
questions?
Really,
if
you
understand
how
bit
rated
affleck
video
is
at
any
point
in
time,
you
need
to
let's
say
for
a
live
video
that
you're
sending
to
all
these
receivers
that
have
varying
bit
rates
over
time
and
basically
for
every
you
know
packet
for
every
picture.
You
need
to
send
the
video
in
the
right
bitrate
to
every
receiver.
So
you
know
every
time
you
send
it
out.
B
M
B
G
Yeah
and
sorry
about
my
voice
I'm,
so
the
new
Charter
specifically
allows
for
applicability
statements.
We're
saying
this
is
how
you
can
take
beer
to
use
it
for
different
things
and
obviously,
if
presented
this
work
before
and
as
one
of
the
pieces
that
was
in
mind,
beer
is
also
to
serve
essentially
as
a
forum.
G
You
could
think
of
it
as
an
Education
Forum
to
people
who
are
interested
from
at
the
application
area
to
come
in
to
try
and
figure
out,
how
could
they
use
beer
is
so
the
question
you're
gonna
have
you
have
is
how
much
of
this
particular
applicability
document
is
understanding
the
application
and
how
much
is
understanding
beer
and,
if
it's
more
understanding
beer
to
apply
that
the
application
makes
really
great
sense
here,
if
it's
more
the
other
way
around
you'll
probably
get
better
review
from
people
who
understand
the
applications.
Miss.
F
Honey,
so
you
know,
let's
say
that's
a
valid
application.
The
interesting
application,
and
out
of
that,
would
spin
out
something
like
build.
This
funky
tcp
over
UDP
that
can
adapt
those
rights
and
change
receivers.
I
think
this
kind
of
stuff
would
get
spun
out
into
a
different
group
or
go
to
some
HTTP
guys
who
know
much
better
than
us.
R
Good
afternoon
everyone
I'm
ginger
from
ZTE
are,
you
can
call
me
sandy?
This
presentation
is
for
PR
prefix,
the
distribution.
We
have
caused
our
Devery
and
ice
and,
let's
see
the
problem
statement,
I
present
ated
the
problem
in
last
meeting,
but
now
we
provide
a
different
resolution
for
it
at
first.
Let
us
see
the
problem
again.
This
is
that
have
typical
hybrid
network.
It
was
a
different
routing
protocol
running
in
different
regions
according
to
administrator
consideration.
R
So
you
can
see
the
figure
above
as
this
is
level
2
domain
and
the
the
speaker
under
the
under
below
is
a
spear
for
earlier,
whatever
and
as
another
so
and
the
network.
The
different
regions
has
different
that
network
architecture
and
not
many
routers.
They
are
not
many
wrote
her
seeing
some
regions,
but
there
is
only
one
hop
forward
in
some
other
regions.
R
Multicast
estar
is
provided
in
the
network
now
by
using
pin,
but
if
we
want
to
be
prepared
in
this
network
and
from
the
existed
protocol
we
handle
that
we
can
deploy
it
appeared
of
making
each
I
defeat
Yugi.
So
we
will
think
this
network
of
we
can
build
three
peer
domain
in
it,
so
the
father
wrote
her
such
as
r3
and
r4
needs
to
maintain
the
multicast
flow
over
a
state,
and
the
bother
with
her,
such
as
r3
and
r4,
must
account
worth
here
encapsulation.
R
What
if
or
we
have
one
beer
boom
and
spending
all
the
regions?
And
we
can
do
it,
then
the
three
regions
is
merge
at
1:00
p.m.
and
so
there
is
no
overlay
state
for
the
rooters,
such
as
a
3
and
a
4,
and
the
no
beer,
encapsulation
and
encapsulation
functions
wrong
in
beer
rotors.
R
A
Sorry
yeah
thank
you
interesting
draft,
but
before
you
get
to
the
next
slide,
I
just
wanted
to
understand.
If
you
go
back
to
the
previous
slide,
please
so
just
an
example
here
on
our
one
from
data
path,
point
of
view
from
the
beer
header
point
of
view,
are
we
gonna
set
if
r1
wants
to
send
the
packet
to
our
X
or
our
Y
or
RN
on
the
r1?
Are
you
guys
setting
the
bets
for
our
M
RN,
Rx
and
ry
yeah.
R
A
R
It's
a
solution.
At
first
we
can
reuse
the
peer
sub
T
of
e,
with
beer
prefix
redistributed
by
other
looters
from
while
routing
region
to
another
and
the
so
the
road
hogging
all
the
beer
domain
can
build
is
the
peer
forwarding
plane,
so
just
it's
just
alike
SPF
in
her
error
case
and
for
PR
in
peers
in
PRS
encapsulation
stop
at
yogi.
It
may
be
included,
but
it
is
not
needed.
A
network
has
the
PSLV
because
it
has.
R
It
has
a
local
meaning
so
f,
only
if
we
want
to
send
a
pair
packet
a
director
to
an
outer
after
all
external,
be
FR
we
can,
we
may
use
it.
They
are
forming
at
that
depends
on
the
administrator
consideration
next
and
it's
either
another
part
of
the
solution,
because
we
know
that
butter
root
are
always
use
summary
or
tea
for
the
root.
That
way.
The
word
has
raw
roots
to
another
rigid.
R
So
if
the
summary
or
aggregation,
you
have
quite
an
aggregation
and
all
the
photo
root
rots
as
are
used
to
send
to
another
region.
Nah
single
summary,
not
mention
too
much.
A
single
summary
wrote,
may
cover
many
PF
ideas.
So
how
can
it
work?
I
said
in
this
chart
we
defined
a
new
proxy
range
sub
govt
to
advertise
it.
R
So
you
can
see
the
form
art
is
like
this
and
the
multiple
beer
proxy
when
just
up
to
you
is
maybe
at
the
word
heisted
if
the
bf
ID
is
covered
by
the
prefix
allocated
from
different
oranges.
So
there
is
no
more
one-to-one
mapping
between
individual
via
prefixes
and
the
we
have
IDs
overlay.
We
know
that
the
overlay
needs
to
include
DFID
EPF
er
ideas,
one
second
or
into
PFR
III's.
So
that's
o
adding
comments.
K
Hi
it's
Peter
Francisco,
so
I
just
have
a
very
practical
comment
that
encoding
works
for
one
of
three
protocols,
so
I
would
advise
to
work
with
the
protocol
guys
to
make
the
correct
encoding
and
also
the
draft
doesn't
say
anything
about.
Where
do
we
put
this?
It
says
it
comes
with
the
prefix.
There
are
multiple
ways
to
advertise:
prefixes
so
and
needs
to
be
some
work
there
to
be.
You
know
clarify
that's
all.
Okay,.
F
That
makes
me
very
nervous,
because
then
you
have
to
start
to
run
a
distance
vector
protocol
to
make
sure
you
don't
loop,
and
there
is
a
lot
of
very
ugly
cases
where
you
start
to
redistribute
IGP
into
IGP,
and
you
end
up
with
redistribution
loops
plus.
Normally
we
don't
during
redistribution
between
protocols,
direct
large
amount
of
information
between
protocols,
normally
our
heat.
Actually.
So,
if
that's
supposed
to
be
standards,
I
think
there's
tons
of
work
to
be
done.
Okay,.
I
F
K
K
F
S
R
This
presentation
is
for
PR
will
drift,
we
have
coarser
debris
and
so
on.
Let's
take
our
glass
of
rift,
her
protocol,
it's
a
hybrid,
the
rocking
protocol
for
cloths
and
factory
networks
and
for
north
bound.
We
use,
link,
state
routing
and
the
forced
respond.
We
use
distance
vector
routing
in
suspect,
D
for
the
rocks
most
is
used
most
of
the
time
and
some
specificity
is
aggregation.
Rules
is
I,
use
the
to
avoid
back
black
holing
or
provide
optimal
routing
in
certain
situations.
R
R
Because
amperes
is
not
always,
you
know
not
always
use
the
yin
data
center,
so
we
must
consider
that
now
I'm
sure
as
encapsulation
function.
So
there
is
only
one
difference
between
down
imperious
and
an
imperious
encapsulation
sure.
So
what
we
should
do
is
to
distinguish
its
mpi
FG
ID
in
the
beer
Heather
next,
so
the
pure
second
owning,
like
I'm
curious
label
block,
is
used
to
advertise
your
information
in
not
I'm
curious.
We
can
use
to
measure
for
it.
One
is.
R
R
So
I've
simple:
let's
summarize
the
draft,
so
in
drift
northbound
we
use,
we
are
ITP
like
signaling
functions
and
ying
roof
to
sauce
panda.
We
use
the
function.
Defining
PR,
perfect
suite
is
tribute
to
edward
heists,
the
PR
information
so
and
we
use
the
similar
yeah
FK
ideas,
technology
for
balls
and
purist
and
imperious
encapsulation.
This,
because
rifka
is,
has
a
thrift
SEMA
feature,
so
you
can
use.
We
have
implementing
later.
M
Chair
another
working
group
right
now,
so
so
the
idea
is
to
offer
beer
to
eat
with
them.
M
Now
the
you
know
opportunity
to
create
a
standards
version
of
that,
I
think,
would
be
really
highly
beneficial.
So
the
press,
packet,
replication
and
elimination
function
to
me.
It's
just
a
new
term
for
what
we
called
you
know,
an
IP
multicast
live
live
dual
transmission.
A
lot
of
terms
have
been
used
around
the
industry,
so
the
idea
is
to
have
packets
with
flow
ID
and
sequence,
number
send
across
two
disjoint
paths,
and
then
the
receivers
perform
duplicate,
elimination
by
the
flow
ID
and
the
sequence
number
right.
M
You
just
remove
the
duplicate,
packets
and
actually,
in
the
case
of
the
beer
te
solution,
it
can
also
be
midpoints.
I
don't
have
the
example
here,
but
I'll
have
it
on
Friday
and
the
dead
net
session.
So
where
we're
going
to
talk
about
that
in
more
detail.
So
this
this
scheme,
the
the
life
live
transmission-
has
been
used
in
IP
multicast
since
about
2010
in
video
receiver
applications
in
the
multicast
application,
maybe
since
1997.
So
the
idea
in
the
application
side
has
been
around
forever.
The
feasibility
in
layer,
3
and
the
u.s.
M
M
Flexibility
next
slide.
So
beauty,
you
would,
of
course,
be
responsible
for
the
flexible
dual
disjoint
path
or
triple
path.
Even
you
know,
in
that
net
they're
thinking
for
even
more
redundancy,
so
the
the
pref
modeling
how
we
would
want
to
do
that
with
beer
and
that's
also,
then.
The
details,
of
course,
are
in
the
encapsulation
draft.
We
would
want
to
have
an
eighth
and
enhance
your
header.
Include
the
sequence
number,
that's
the
new
thing.
Vfr
ID
entropy
at
is
the
flow
ID,
so
we
can
discuss
that
in
the
encapsulation
draft.
M
The
BFI
are
creates
the
packet
with
a
sequence
number,
with
the
flow
ID
any
bf.
Are
you
know
whether
it's
V
fer
or
intermediate
one
configured
with
the
elimination
function
on
ingress
before
the
replication
would
eliminate,
duplicates
and
that's
the
current
thinking?
Of
course
they
can
still
evolve
in
the
details.
There
are
a
couple
of
you
know.
Things
were
still
reviewing
the
linkage
between
beer
te
and
the
press
function
really
is
you
know
the
encapsulation
already
provides
50
percent
of
what
we
need.
We
already
have
in
the
you
know.
M
Encapsulation
header
also
other
fields
that
were
reusing
that
were
only
brought
in
for
the
application
or
for
beer
itself
like
the
BFI.
Our
ID
is
used
for
the
overlay,
not
for
the
forwarding
in
beer,
and
so
that
I
think
makes
it
very
logical
to
add
the
sequence
number
as
an
option
there
and
as
I
said,
the
elimination
function
does
not
happen
after
beer
is
done,
but
it
has
to
happen
is
actually
on
ingress
of
any
bf
our
next
slide.
M
So
this
is
the
example
to
showing
what
the
benefit
is
of
doing
the
elimination
function
on
ingress,
because
it's
really
cool
and
better
than
what
we
could
have
done.
We
you
know
with
the
older
multicast
application.
We
just
have
two
trees
and
there
is
no
elimination
function
staged
in
so
you're,
sending
the
same
copy
both
ways
around
around
the
ring
right.
This
way,
and
this
way
each
of
these
nodes
on
ingress,
does
elimination
function
but
then
copy
further
out
in
the
direction
into
the
receiver.
For,
thank
you
not
sure.
M
If
that's,
oh,
because
I'm
not
allowed
to
go
out,
oh
I'm,
sorry
right!
So
what
basically
happens
instead
of
sending?
You
know
both
copies
through
the
whole
ring.
What
happens
is
this
copy
only
goes
up
to
here,
and
then
it
sees
oh
I've
already
got
the
packet,
and
the
packet
from
the
other
side
only
goes
here
sees
it
so
I'm
saving
50%
of
bandwidth
by
doing
the
elimination
function
on
ingress
and
doing
replication
afterwards
right.
M
So
that's
a
very
cool
example
of
how
to
improve
this
by
being
able
to
not
do
it
just
as
an
overlay
on
the
edge
next
slide.
Oh
this
clicker
doesn't
work.
Okay,
so
then
basically
comes
the
OEM
function
and
the
OEM
function
is
the
ability
to
look
at
the
receive
bit
string
and
figure
out
which
copy
you
actually
got
by
the
bits
that
are
still
in
the
packet.
And
so
then
you
can
basically
also
see
you
get.
M
You
know
one
or
two
packets,
and
especially
in
you
know
the
Denton
topologies
that
which
are
not
the
ring.
You
will
always
get
both
copies
and
you
can
create
a
lot
better
statistics.
In
terms
of
you
know
what
was
the
difference,
you'll
delay
and
you
can
also
understand
where
certain
things
fail
along
the
path.
So
we
don't
have
examples
of
that
in
this
presentation
so
and
and
I
that
that's
the
key
part
that
at
Pascal
next
slide
so
yeah
changes
from
the
o2
version.
M
N
You're
particularly
bound
it
to
be
R
T.
If
you
look
back
how
we
did
you
all
join
love
life
for
beam
or
in
the
LS
networks,
we
would
do
it
for
help.
So
if
you
do
it
with
flex
al
burn,
colored
link,
you
are
done,
you
just
just
joined
I
mean
you
either
need
to
implement
traffic
engineering.
To
do
this.
M
So
that
I
think
very
much
a
question
also
to
the
use
cases
in
being
in
debt
net,
where
you
may
want
to
have
you
know
across
different
path
segments
along
the
path,
different
amount
of
resilience,
so
I
was
saying
exactly
I.
Don't
want
to
have
this
part
of
the
solution
be
applicable
to
only
beer
to
eat,
and
that's
exactly
the
header
discussion.
M
This
particular
draft
yeah
I
think
once
we
feel
comfortable
with
this
I
think
it
should
be
I,
guess,
informational,
probably
because
the
normative
part
would
just
be
the
encapsulation
and
then
we'll
have
to
figure
out
where
to
define
the
elimination
function.
Dupree
prior
slide
said
that
we
need
to
figure
out
which
pieces
we
can
say
are
generic
across
different
encapsulations,
so
that
we
don't
have
to
define
it
in
beer
in
which
pieces
of
that
our
beer
or
beer,
tea
specific,
like.
P
Okay,
so
after
our
tourists
took
about
the
yeah,
this
is
in
beauty,
encapsulation,
yeah,
okay,
this
is
some
highlights.
We
are
separated
for
this
object,
currently
all
the
details,
basically
our
best
guess,
and
this
draft
proposal
enhanced
version
death,
I
capsulation
for
to
support
both
beer
and
BT.
Of
course
it
based
on
RC
82,
United
States.
Currently
they
would
propose
it
to
make
it
a
version
two,
but
of
course
it's
possible.
P
It
also
possible
to
make
it
out
in
out
version
and
in
addition
to
that,
this
a
capitulation
support
folk
I'm
allowed
beer
to
be
using
debt
net
anyway.
This
is
just
one
choice
and,
of
course,
we're
open
for
you
know
as
options
if
you
have
any
good
suggestions,
let's
please,
okay,
the
one.
The
first
feature
of
this
encapsulation
assimilate
a
simultaneous
support
for
you
and
bTW,
actually
yeah
sure,
okay,
here,
okay,
so
it's
a
panel,
every
domain
should
only
use
a
you
know
single
type,
a
but
here's
a
beer
or
phe.
P
P
I
P
P
We
discussed
I
think
of
Britishness
yeah
because
it
is,
but
the
problem
is
that
for
current,
the
MPOs
encapsulation
it
can
solve
it
perfectly.
But
there's
country
for
no
mpos
bit
encapsulation
may
have
some
difficulties
or
something
because
currently
the
label
have
seemed
to
be
cell
phone
format
of
the
label
or
something
like
that.
I
think.
M
I
Yes,
but
I,
don't
think,
there's
a
big
difference
between
MPLS
and
non
MPLS.
Let's
say
in
an
online
pls
case.
You
have
to
say
what
biffed
ID
you
associate
with
a
subdomain
missing
length
and
what
encapsulation
you
using
right
or
what
beauty
or
normal
beer
I
don't
see.
I,
don't
think,
there's
a
difference.
Yeah.
P
Okay,
actually
yeah,
okay
yeah.
This
is
just
some
explicit
option
to
do
it,
but
also,
as
I
said,
it
could
be
a
some
employee,
implicit
option,
yeah.
Okay,
another
feature
for
this
I
capped
relations
that
the
support
for
dead
net.
So
this
proposal
at
control
world
a
field
to
head
that
you
allow
the
the
encapsulation
used
as
a
they,
then
net
data
plane
and
this
field
is
a
32-bit
and
the
for
the
net
can't
really
only
are
to
net
a
bit.
P
It's
used
as
a
sex
number
and
+4
0,
so
this
secret
number,
as
is
allowed
to
correct
ordering
and
some
discovering
Packer
loss
when
using
resilience
your
path
transition
in
that
net
yeah
power.
But
we
are
our
also
missing.
This
overhead
is
acceptable,
but
even
if
some
people
think
that
maybe
in
some
cases
other
than
they
net
this
field,
it's
not
it
is
useless.
Maybe
an
option
could
be
user
one
bait
to
indicate
if
the
field
exists
or
not
other
than
that
also
out,
then
that
needs
a
flow
ID.
P
P
The
t
field
indicates
a
beer
o
phe
when
is
that
is
PRT
entropy
modified
but
can
be
reused
who
controlled?
Yes
did
I,
explain
yeah
in
the
previous
right,
so
on
that
space.
So
I
think
this
is
partly
disgusting.
P
So,
let's
slice
but
and
there's
that's
one
option
also
another
option
could
be
you
know,
maybe
use
Beauty
itself
to
to
design
new
adjacent
adjacency
type
for
tu-tu-tu-tu-tu
achieves
as
receiving
the
operation.
Yes,
please
yeah.
There
was
some.
There
were
some
discussion
in
last
IDF
meeting
about
his
daughter
because
BSL
lens,
which
may
you
know,
limits
Beauty
usage.
That's
because
you
know
the
the
size
of
the
topology.
The
biggest
L
indicates
the
size
of
topology
to
was
about
the
FA
Yara,
and
you
know
the
pastor
can
be
explicitly
be
engineered
to
reach.
P
That
means
that
it
consumes
more
bit
position
than
the
year
so,
but
in
our
opinion,
there's
some
still
some
ways
to
could
be
used
to
reduce
the
number
of
base
could
be
to
assign
it
to
the
individual
in
the
immediate
hubs
in
Beauty.
There's
two
examples:
one
is
IPTV
topology.
You
can
see
here
for
IPTV
topology.
If
we
use
beard
he
it,
it
looks
like
a
tree.
Topology
and
all
the
traffic
from
BFI
are
to
be
fr
from
via
RT
of
pfr
are
warm
to
be
fr
and
all
the
trophies
maybe
or
all
the
same.
P
So
they
can
share
the
warm
bits,
but
the
traffic
engineer
happens
from
VFR
to
BF
y
ER,
so
this
as
there's
may
be
multiple
passes
in
between.
So
in
this
case
we
can
assign,
in
this
case
we
can
slice.
Three
different
beats
to
you
know
each
pass
and
things
this
topological
pick
is
similar
from
the
same
topology
from
a
pfn,
a
PRN
PFR
and
to
PF
your
n.
So
these
these
three
different
bits
can
be
reused
in
such
kind
of
same
similar
topologies.
So
in
this
way
some
bits
can
could
be
saved.
P
Okay
yeah:
well,
let's
talk
about
next
step
yeah,
so
we
talked
about
using
it
as
a
version
to
accept
a
capsulation
and
if
we
agree
to
do
that,
shall
we
use
this
version.
You
know
maybe
subs
or
some
BFI
VIP
ideas,
I'm
gonna
issue,
yeah,
that's
just
some
open
question.
We
did
in
the
propose
anything
the
in
this
draft,
so
yeah
I.
I
P
M
Us
I
think
the
the
main,
the
main
point
for
thinking
about
that
distinction
was
really
from
the
sender.
Indicating
I
meant
a
beer
te
bit
string
as
opposed
to
a
beer
bit
string.
That's
I
think
the
key
diagnostic
I
think
for
the
other
points.
I
would
agree
that
basically
we
can
distribute.
However,
we
do
the
bi
ft
stuff
right
through
our
GPS
or
other
schemes,
but
how
do
we,
you
know?
Get
the
application
to
I
mean
you
know
I
like
Diagnostics,
but
that
there
would
be
my
question
mark
right.
Is
it
worth
a
bit
right?
F
But
to
give
diagnostic
you
have
to
holo
am
support
so
I.
Don't
you
just
put
a
special
away
impact
I
can
go
and
test
whether
or
no
my
my
path
is
consistent,
because
otherwise
everybody
with
a
special
little
you
know
operational
hobby,
will
try
to
stick
a
bit
to
see
it
on.
Uncaps
doesn't
scale
right.
That's
why
we
put
om
into
the
technology
from
bottom
up
and.
G
M
M
M
B
B
Q
B
T
T
T
T
T
It
is
also
common
in
some
SP
networks
that
most
of
the
loads
are
agile,
owes,
to
example,
a
habit
spoken
topology
in
metro
network
and
Al
Ahly
example.
It's
a
green
topology
in
backhaul
network,
so
transition
from
legacy,
and
maybe
in
in
networks
where
the
incapable
a
lot
is
making.
So
this
is
the
second
problem.
T
T
So,
what's
the
alternatives
to
solve
the
two
problems
for
proof
for
the
first
problem
of
truth
is
during
the
trees
we
can,
we
may
want
to
computer.
The
truth
is
Johanna
tray
using
some
algorithm
under
then.
How
should
we
do
just
computing
computing
and
computing
or
just
build
it?
This
draft
is
determined
to
just
build
it
and
for
the
second
problem
of
incredible
a
load.
T
T
This
is
a
deep
exploring
of
tree
paste
appear
for
wedding.
This
is
amazing.
The
paralytics
explored
in
the
PA
architecture
RC,
and
from
this
exploring,
we
can
support
incapable
edge
nodes
which
is
not
supported
by
the
peer
architecture.
Rc,
and
also
we
can
support
incapable
middle
ODEs
without
using
the
ingress
replication
in
the
peer
architecture
of
C.
T
So
the
Hopi,
via
the
Magnificent
part
of
the
whole
picture,
it's
the
step
0
in
the
top
red
top.
That
is
to
use
a
relative
here
or,
as
with
he
or
him,
seem
him
SSM
to
build
a
tree
with
peer
information.
That
is
a
peer
underlay
procedure
and
after
that
war,
since
done
service
and
the
it
can't,
it
will
solve
the
problem.
The
first
and
the
second
program
mentioned
it
before.
T
T
T
So
summary,
the
two
problems
and
the
three
sameness
point
and
the
philosophy
is
very
simple:
that
is,
you
need
any
of
any
offer
that
is
join
the
tree
then
just
build
it,
and
the
target
scenario
is
for
peer
transition
from
NGO
million,
and
there
may
be
a
focus
question
since
ITF
100.
That
is
some
simplification
or
complication
to
brain
the
tray
into
Pia
and
the
for
this
question.
I
have
the
following
answer:.
T
U
U
U
But
it
would
be
good
for
this
working
group
to
decide
whether
transition
mechanisms
are
important
or
if
they
are
not
important,
do
we
want
to
be
hardline
with
saying
that
a
network,
if
it's
going
to
support
beer,
it
has
a
sort
of
support
Bureau
or
do
we
want
to
be
more
flexible
to
allow
operators
to
be
able
to
run
both
at
the
same
time?
And
that's
kind
of
the
idea
for
this
is
we're
working
with
operators
who
are
saying
we
don't
see
the
benefit
of
beer
and
we're
saying
you
know
we
we
believe
in
beer.
U
B
B
B
I
know
I
wanted
to
get
to
this,
though,
to
there's
specific
questions
about
this
draft.
We
have
one
more
to
talk
about
we're.
Splitting
me
kicked
out
of
this
room.
We
got
pretty
darn
close
to
the
end
I'm
impressed
with
new
sheets
yeah
blue
sheets,
so
I
have
to
apologize
too
yeah
resilience
trap.
Anyone
wearing
a
shirt
get
up
here.