►
From YouTube: IETF-MPLS-20230810-1400
Description
MPLS meeting session at IETF
2023/08/10 1400
https://datatracker.ietf.org/meeting//proceedings/
B
A
C
C
Six
minutes
after
and
we
have
16
attendees
present,
it's
a
good
number.
So
what
are
we
expecting?
Are
we
missing
any
of
the
core
attendees.
A
And
I'm
missing
Matthew
but
I,
don't
know
about
Matthew.
I
know
that
Nick
is
on
vacation,
so
he's
not
will
not
show
up,
but
I
don't
know
about
Andy
and
Matthew
Stewart.
Do
you
have
an
idea.
D
All
right,
okay,
I've
got
a
microphone,
no
I,
I,
I
I,
don't
know
about
either
of
them
and
he
was
busy
with
something
else
on
the
chairs
meeting.
Wasn't
he
so.
A
E
A
C
All
right
so
thanks
everyone
who's
joined,
and
this
is
the
m
a
interim
meeting,
the
first
one
we're
having
after
IDF
117.
C
This
is
a
joint
effort
between
the
three
working
groups,
and
this
is
an
official
interim.
So
we
have
to
flash
the
note
12.
if
you
have
not
got
acquainted
with
it.
Please
do
so,
and
this
slide
shows
some
administrative,
useful
links
for
anyone
who
cares
about
these
calls.
You
will
find
the
minutes
available
online,
as
well
as
the
recording
and
our
mpls
working
group,
Wiki
and
so
on.
C
C
Then
we
will
give
a
chance
for
the
draft
m,
a
header
solution,
draft
the
authors
to
ask
any
clarification,
questions
following
the
the
IDF
117
feedback
that
we
got
and
we
will
talk
about
future
agenda
items
but
before
going
over.
Second,
the
third
fourth
item
I
wanted
to
review
the
action
items
that
we
have
outstanding
and
lastly,
we
have
the
usual
all
other
business.
A
A
To
speak
up
on
any
other
business,
I
just
want
to
say
that
again,
the
item
number
three
is
not
intended
to
be
a
discussion.
It's
just
a
chance
for
authors
to
ask
clarification.
Questions
on
what's
been
going
on
what
has
happened
on
the
mailing
list
regarding
the
m,
a
header
draft.
C
C
We
do
have.
We
do
have
an
action
item
to
track
updating
the
documents.
The
working
group
documents
that
we're
driving
for
m
a
specifically
we
have
the
requirements
draft
during
itf-117.
C
Also
Matthew
was
author
on
that
raised
a
possibility
of
merge
between
the
requirements
and
framework
draft,
but
there
was
supposed
to
be
a
follow-up.
It
was
not
converged
that
there
is.
This
merch
will
happen,
so
it's
a
chance
for
the
co-authors
attending
for
the
two
drafts
to
update
this
action
item.
C
If
I
think
Matthew
is
not
here,
but
anyone
else
think
Tony
was
supposed
to
follow
up
with
Matthew
only
Lee.
So
do
you
have
anything
to
say
about
that.
C
Okay,
all
right
is
there
a
plan
to
to
attempt
again.
A
Yeah
I
know
you
can't
see
that's
something
out
with
the
mid
Tech
with
the
and
share
sharing
the
slides,
can't
see
the
the
last
thing
for
it.
You
have
this
be
able
to
speak.
I
have
one
comment:
yeah,
Tony
and
Matt.
You
should
discuss
this,
but
I'm,
not
in
favor
of
merging
into
documents
and
I
haven't
really
heard
anyone
that
is
so.
It
might
be
that
and
second,
the
requirements
draft
is
actually
passed.
A
C
Yep,
so
that's
a
good
feedback
and
I
think
it's
a
start
for
the
discussion
on
that.
We're
not
saying
we
will
merge,
but
there
were
some
Nets
or
Snippets
that
could
be
moved
between
the
documents.
So
that's
another
alternative,
okay
and
the
second
action
item
was
against
the
solution:
draft,
the
mpls,
sorry,
the
mpls
mne
header
draft
during
the
idf-117
sessions
we
and
as
well
on
the
mailing
list.
We
have
good
discussions
about
updating
that
draft
with
suggestions.
C
C
You
know
same
scope,
adding
actions
in
within
the
same
scope.
So
that's
a
action
item,
I'm
tracking
and
if
anyone
has
an
update
on
it,
please
come
to
the
mic.
C
I
can
call
out
names
as
well,
I
mean
if
Joel
or
even
the
the
authors
was.
The
concerned
raised
before
the
other.
E
C
And
that's
exactly
I
think
that
is
okay
for
the
update
I'm,
not
looking
for
more
than
that.
I
think
also
that
you
know
item
three
is
related
to
this
on
the
agenda
item
three
on
the
agenda
and
the
office
will
get
back.
They
promise
to
get
back.
So
I
will
tag
this
as
an
update
and
and
move
on.
A
A
C
C
All
right
and
I
I
think
we
can
safely
move
on
and
to
the
next
item
on
the
agenda,
which
is
the
m
a
where
interact
interactions
with
beer
in
the
same
packet.
C
So
today,
Greg
will
talk
about
this
and
I
can
present
the
slides
for
that
myself
and
let
me
see
if
I
can
give
you
a
chance
to
flip
slides,
Greg.
C
I'll,
do
the
flipping
somehow
I,
okay
one!
Second,
let
me
see
if
I
can
find
you
Craig
past
slide
control,
so
you
should
have
slight
control.
Craig.
D
F
Okay,
first
I'll
give
you
the
overview
of
our
beer.
Over
mpls
looks
like
and
then
there's
some
discussion.
I
had
with.
F
Jeffrey
about
post
that
data,
mpls
Network
action
combination
with
the
beer
over
npls.
F
So
what
is
bit
index
explicit
replication?
It
is
a
multicast
technology,
it
works
in
a
data
plane
and
it
does
not
require
creation
of
their
per
Flow
State
in
the
transit
nodes.
So
we
can
think
of
it
as
a
source.
Routing
Plus,
multicast
or
multicast
was
so
strolling
because
they're
Ingress
node,
the
encapsulating
node,
determines
based
on
routing
control.
F
Or
orchestrator
input
of
their
explicit
destination
for
their
packet
to
be
replicated
and
then
beer
domain
consists
of
Ingress
router.
It
forwarding
beer
forwarding
index
Ingress,
router
dfrs,
it's
a
Transit
nodes
and
egress
routers.
F
Identified
by
dfr
ID
and
if
we
look
at
the
beer
header
so
here
we
see
and
that's
what
we
will
be
talking
for
some
time
now
so.
F
Dfrid
is
identifier
of
their
Ingress
router
and
because
that
is
uniquely
associated
with
IP
address,
it
gives
the
opportunity
for
routers
that
want
to
reach
this
route
of
their.
This
multicast
distribution
tree
over
IP
network
to
map
it
back.
F
F
Okay:
let's
look
at
the
first
four
octets,
because
the
space
for
identifying
destination
addresses
is
limited.
F
There
might
be
a
multiple
forwarding
tables
and
each
of
the
bfr
routers
it
advertises
one.
G
F
Beer
bit
indexed
forwarding
tables
so
that
it
will
know
how
to
map
the
bitstring
too.
At
the
same
time,
this
beef
ID
occupies
the
20
bits
and
can
be
in
is
viewed
as
a
beer
mpls
label.
F
So
when
we
look
at
the
beer
header,
it
does
include,
as
defined
currently
in
their
architecture
over
ntls.
It
does
include
the
bottom
of
the
stack
LLC.
F
F
So
this
gives
their
length.
This
field
carries
the
length
of
their
bit
string
and
the
entropy
value.
F
Two
bit
OEM
flag,
been
discussed
in
one
of
the
proposals
is
to
use
for
to
to
flag
alternate
marking,
that's
being
discussed
by
dear
working
group.
So
then
prata
is
explicitly
identifies
the
payload
type
of
the
beer.
F
And
followed
by
their
bit
string,
which
is
a
bit
flex
for
destinations.
B
F
Okay,
I
think
that
that
would
be
a
major
rework
and
there
was
something
okay
in
my
exchange,
it
was
Tony
p.
My
interpretation
was
that
there
was
some
idea
towards
that,
but
the
problem
that
I
see
would
be
that
it
will
significantly
impact,
especially
the
bit
string,
because.
B
F
Yes
again,
definitely
it's
something
that
could
be
discussed
again.
Everything
can
be
done
right,
so
whether
it's
a
better
solution,
because
I
believe
that
Jeffrey
has
another
solution:
how
to
do
a
PSD
m
a
while
keeping
beer
Heather
outside,
or
at
least
most
of
the
deer
header
outside
of
MLS
Tech.
E
H
This
beer
header
includes
the
first
four
options,
which
includes
a
peer
label
here.
H
A
more
logical
view
here
is
that
the
the
MPS
label
is
part
of
the
mpos
layer,
but
the
rest
of
the
beer
header
is
Bo,
is
beer
is
beer
layer,
and
so
we
can
think
that
mtos
labor
stack
ends
after
the
the
first
octet,
and
so
if,
if
there
is
ISD
in
the
mtos
label,
stack
is
is
transparent
to
beer
and
if
there,
if
there
is
PSD,
then
we
we
need.
We
need
to
worry
about
Legacy
peer
router.
That
does
not
understand
the
the
PSD
I.
I
F
Actually,
I
agree
that
ISD
M
A
is
transparent
to
beer.
Even
now.
The
only
the
only
question
that
we'll
have
is
that
and
that's
again
for
future
discussions
with
the
beer
working
group
and
mpls
working
group.
Is
that
my
understanding
that
beer
and
PLS
label,
which
is
if
first
or
bottom
of
the
stack
here,
is
expected
in
the
current
solution
to
be
bottom
of
the
stack
so
whether
it
will.
I
F
To
be
requested
as
such,
or
that
can
be
eased
up
and
say
that
when
the
beer
bfr
finds
the
beer
mpls
label,
then
it
might
followed
by
one
or
more
link
State
elements
and.
I
F
Stack
elements
that
to
be
seen,
but
what
I
wanted
to
present
for
now
is
the
current
state
of
the
art
lower.
A
Please
so
I
have
two
points,
one
point
of
order:
the
can
everyone
that
is
not
speaking,
actually
mute
themselves.
So
the
we
get
rid
of
the
noise
I
think
we
see
Steward
popping
up
now
and
but
he
has
Newt
yourself
and
everyone
else
also,
the
other
one
is
the.
A
F
F
F
So
clearly,
there
is
some
Oddity
and
there
is
some
issues
with
using
PSD
over
m
a
over
brm
PLS.
Because
of
this
require
expectation
and
requirement
that
bottom
of
the
stack
includes
via
mpls.
B
A
One
right
yeah,
the
the
that's
actually
where
I
was
getting
those
if
you
say
bottom
of
Stack
may
be
possible,
but
I
think
that
the
position
immediately
after
the
bottom
of
Stack
bit
is
actually
taken
by
a
couple
of
other
applications
that
actually
could
Collide.
So
I.
A
Think
what
I
want
to
say
and
I
agree
with
attorney
that
if
we
actually
find
that
we
need
to
do
something
that
is
a
bit
of
extra
work,
but
I
think
we
should
discuss
it
one
way
or
another
to
see
what
what
we
should
do
and
see
if
you
can
live
with
the
current
Build
architecture.
F
Yeah
I
I
I
I
agree
that
already
they're
identified
as
several
options
how
to
do
it
and
Jeffrey
proposal
to
First
architecturally
separate
this
first
four
octets
that
include
dist
ID
or
beer
mpls
label
from
the
rest
of
the
header.
So.
B
F
Will
probably
most
likely
require
some
work
with
the
concern
of
being
compatible
with
existing
Solutions
and
then
I
agree
that
whether
this
label
must
be
a
bottom
of
the
stack,
that's
another
question
and
then
probably
trying
to
get
to
their
more
flexible
solution.
A
F
H
H
H
Right,
the
the
the
beer
label
itself
well,
what
what?
What?
What?
How
both
the
two
things
one
is
that
a
beer
header
follows
the
other
one
is
that
which
particular
beer
folding
table
to
use.
So
the
label
itself
will
or
explicitly
tell
that
a
beer
header
follows
yeah.
H
Another
point
I
want
to
make
is
that
the
bottom
of
the
stack
assumption
I?
Don't
think
that
would
change.
But
that's
just
my
my
view
here,
but
the
the
real
issue
is
that,
after
the
bottom
of
the
stack
label,
what
happens
if
you
have
a
PSD
a
block
and
that
that
is
the
real
issue
yeah?
So
please
go
ahead
and
yeah.
F
I
I
agree
with
Jeffrey
that
again
I
believe
that
this
is
a
solvable
solution
and
how
to
do
that.
But
again
it's
something
that
will
require
work.
C
Yeah
hi
Greg
I
am
the
entropy
field,
attracted
my
attention
and
I'm
curious
in
mpls.
I
presume
this
is
an
mpls
beard,
header,
that's
what
my
guess
is.
So
we
have
entropy
support
in
mpls.
So
what's
the
interaction
between
this
entropy
and
an
entropy
that
can
exist
in
the
label
stack
and
if,
if
the
entropy
label
that
we
support
in
mpls
is
not,
there
is
a
Transit
router
supposed
to
be
parsing.
This
entropy
and
doing
hashing
based
on
it.
H
Oh
I
I
was
talking
I'm,
muted,
all
right,
so
the
mpos
forwarding
and
that
gets
the
package
to
this
particular
beer.
Router
will
only
look
at
the
mtos
really
hit
the
labels
or
whatever
it
does
not
look
into
in
this
in
this
entropy
field.
Now
after
this
router
received
this
package,
it
will
start
spear
for
forwarding
and
then
the
beer
will
only
look
at
this
entry
entropy
field
in
this
peer
header
or
for
its
for
its
purpose.
H
The
that's
totally
independent
of
each
other
yeah.
F
So
we
can
think
of
it
similar
to
a
service
function,
chaining,
so
service
function.
Forwarders
may
be
interconnected
with
mpls
network,
but
that
will
be
LSPs
that
connect
these
entities,
so
similarly
bfrs
might
be
interconnected
with
their
mpls
Network
and
that's
so
that
will
be
only
mpls
tunnels
that
interconnect
them.
F
But
it's
not
expected
that
Transit
LSR
will
look
into
the
beer
header
and
understand
the
entropy
information
in
a
beer.
F
So
it's
like
a
transport
Pilots,
probably
not
the
right
word
to
say:
mpls
is
a
transport,
but
it's
a
in
mpls.
We
have
underlay
Network
entropy
and
in
beer
we
have
a
service
entity
or
overlay.
E
F
Have
I
managed
to
make
it
confusing
even
more
or
it's
clear
enough.
F
C
G
B
G
I
type,
something
in
the
chat
explaining
why
beer
entropy
is
basically
has
its
own
use.
That.
F
You
clarified,
okay,
so
let
me
switch
the
next
slide.
F
Okay,
so
what
rules
appear
over
in
PLS
I
wanted
to
highlight,
as
we
talked
about
it,
that.
F
F
So
and
some
values
that
being
already
assigned
you
can
see
here
in
this
slide.
B
A
F
It's
probably
better
ask
Tony
Jeffrey
and
ice
they're
more
familiar
with
the
status
of
implementation,
deployment
of
theater.
H
Are
talking
about
Upstream
assigned
label
after
the
beer
header?
That
is
that
it
is
how
it
is
expected
to
work,
for
example,
mvpn
or
evpn
using
beer,
as
as
the
provider
tunnel
for
multicast
traffic.
F
E
F
Jeffrey,
okay,
I
will
move
to
the
next
slide.
F
Okay,
so,
obviously,
because.
F
For
top
octets
in
beer,
header
interpreted
as
bottom
of
the
stack
label
stack
element
post
deck
M
A
cannot
proceed
beer,
mpls
header,
so
yes,
G.
F
F
F
Me
yes
very
faintly.
If
you
can
speak
up
louder
or
get
closer
to
the.
J
Okay,
okay,
so
I
think
I,
guess
the
chat
with
Tony
p
in
the
chat
window,
I
think
the
current
brmprs
encapsulation
was
designed
before
we
have
a
m
a
right.
So
we
may
consider
that
Peter
is
following
the
mprs
layer.
It's
another
upper
layer
of
the
amperage
layer,
but
when
we
consider
Mna
is
introduced
in
the
future
network,
Mna
is
part
of
the
amperes
layer
right.
J
E
J
F
I
I
see
it
a
little
bit
differently
so
and
earlier
there
was
a
note
and
discussion
that
for
instack
data
m
a
because
that
applies
to
mpls
stack
entirely
it
it's
transparent
to
the
air.
So
if
effectively
it
works
on
an
underlay
Network.
F
So
the
only
concern
or
issues
that
we
see
now
is
that
posted
data
m
a
so
I
would
not
say
that
the
introduction
of
m
a
in
mpls
in
general,
requires
work
with
a
beer
over
mpls.
It's
only
if
there
is
a
need
to
use
a
postdecdata
m
a
then
something
needs
to
be
done.
F
J
E
J
F
Right
because
when
I
looked
at
it,
so
in
my
opinion,
ISD
M
A
is
not
required
to
be
bottom
of
the
stack.
So
in
that
case,
so
if
the
bfr
is
capable
of
supporting
ISD
M
A,
then
Nas
can
proceed.
The
deer
header
that
starts
with
the
bottom
of
the
stack
are
label
step
element,
so
I
might
be
missed
something
but
I
have
not
seen.
Then
there
will
be
an
issue
with
peer
over
npls
header
and
ISD
MNA.
J
J
J
G
G
Yeah
I
concur
with
Greg,
it's
basically
mpls
processing
until
you
hit
the
beer
label
and
you
do
beer
processing
and
if
the
underlying
preserves
the
ISD
and
builds
a
new
stack
and
puts
beer
on
top
for
the
next
guy.
Nothing
prevents
you
from
doing
that.
So
the
only
real
issue
that
we
kind
of
so
here
is
that
the
PSD
after
the
bla
right,
because
the
beer.
J
E
J
F
Well,
you
need
to
do
that
again.
You
need
we.
E
F
Understand
that
this
is
a
multicast
so
again
in
each
underlay,
we'll
have
a
different
labels,
so
the
label
stack
on
each
replicated
packet
would
not
be
the
same
right.
So
that's
that's!
Why
reconstructing
their
underlay
encapsulation
for
each
replicated
packet.
J
That
means
you
you
need
to
in
push
the
labels
stack
for
the
next
LSP
or
the
tunnel
to
the
next
video
node
right,
but
the
wider.
You
still
need
to
encap
the
previous
iced
tea
into
something
not
apparent
operation.
To
me,
it's
something
maybe
need
a
special
operation.
F
Okay,
if
somebody
doesn't
like
doing
beer,
they
may
not
do
beer.
Okay,
that's
I'm!.
J
H
Don't
do
that
here.
Mpos
is
just
a
way
to
get
to
get
a
beer
package
from
one
beer
router
to
another
beer
routes
browser.
In
fact,
if
the
two
peer
routers
are
directly
connected,
we
only
use
one
beer
label
in
the
label
stack
and
the
only
purpose
of
that
beer
label
is
to
indicate
that
their
header
follows
and
the
whiskey
Pier
14
table
to
use.
H
If
the
one
peer
router
needs
to
tunnel
to
another
beer
or
a
router,
a
PR
packet,
then
mpos
tunnel
may
be
used,
but
in
in
all
the
cases
between
the
beer,
routers
mpos
is
just
a
a
transfer
or
a
mechanic
mechanism.
We
don't
carry
the
mpos
information
from
one
beer
router
to
another
beer
router,
so
the
ISD
data
and
PSD
and
PSD.
They
all
terminates
at
the
at
this
beer
router
itself.
We
do
not
properly
propagate
it
further.
J
Actually,
maybe
you
mentioned
another
possible
issue
with
size,
the
if
you
say
that
the
peer
knows
directly
adjacent
to
each
other,
then
you
will
only
allow
one
beer
label
in
the
MPS
label
stack
then
how
you
can?
How
can
you
add
ISD
in
this
case.
F
Again,
because.
F
F
F
No,
the
type
of
the
connection
does
not
has
any
consequences
on
the
label
step,
so
you
have
one
transport
label,
but
it
could
be
segment
routed,
mpls
right
so
again
we
we
need
to
separate
underlay
mpls
network
from
beer
overlay.
F
K
K
Yeah
yeah,
I'm,
sorry
Choice,
interrupt
yeah
I.
Think
G's
Point
here
is
that
if
you
put
a
an
Instax
m,
a
label
in
place
stack
with
beer
I
want
to
carry
it
across
end
to
end
right.
Then,
each
time
you
put
you
know,
push
and
pop
the
B
label.
Yes,
remembrance
label
and
put
it
again
on
the
stack.
So
it's
a
bit
inconveniency
that
you
have
to
sort
of
you
know
deal
with
that
inside
of
the
beer
forwarding
to
to
you
need
to
remember
that
context.
Maybe
that's
the
point.
G
is
trying
to
make.
F
F
I
understand,
but
that's
why
early
in
our
discussion,
I
use
the
analogy
of
service
function
chaining.
So
in
the
service
function
chaining
we
have
service
function,
forwarders
and
they
are
interconnected
with
the
underlay.
F
So
but
these
tunnels
that
are
in
interconnect
service
function,
forwarders,
they're,
terminated
between
these
two
entities
so
similar
with
the
bfr
bfr,
the
interconnected
with
the
underlay
Network.
So
for
beer
domain
as
I
understand
it.
There
is
no
notion
end-to-end
underlay,
because
if
they
can
be,
they
may
be
interconnected
by
mpls
and
IP
tunnels.
F
To
to
say
that
I
want
to
have
my
ISD
M
A
to
Traverse
end
to
end,
it
might
not
happen
because
that
will
be
a
different
underlay
Networks
even
more
so
there
could
be
that
we
have
an.
F
Islands
of
beer
they're
interconnected
by
underlay
tunnel
that
connect
one
island
with
another.
So
there
might
be
different
scenarios
and
that's.
Why
I
think
that
the
requirement
that,
if
Ingress
bfr
sets
ISD.
F
H
K
F
F
Well
again,
it
does
not
work
out
of
box,
so
if
we
want
to
do
some
information
preserved
between
systems,
so
we
need
to
do
something
again.
I
probably
will
go
back
to
this
service
function,
chaining
analogy
because.
F
What
we
are
chaining
is
not
only
forwarders,
but
the
forwarder
has
service
function
so
something
that
performs
certain
processing
on
a
payload.
F
But
it's
expected
that
service
function
will
hold
some
information
that
is
needed
to
continue
on
the
service
function
chain,
because
it
has
some
information
that
is
will
be
used
to
identify
where
the
next
service
function
may
be
located
as
it
mapped
to
the
service
function
forward.
So
if
we
want
to
have
this.
F
Network
slice
identifier
as
a
dedicated
identifier
being
traversing
the
whole
viewer
domain.
Then
it
needs
some
additional
instrumentation
on
the
system.
J
Yeah,
that
is
one
difference
between
the
ISD
and
PSD
PSD
can
be
preserved.
J
F
But
that's
that's
something
that
we
need
to
discuss
further
because
again,
as
been
mentioned
by
Tony,
p
and
Jeffrey,
there
are
several
ideas
on
how
to
do
how
mpls
PSD
can
work
with
their.
G
F
But
that
will
require
some
discussions
and
considerations.
Okay,
sorry.
E
J
J
Well,
please,
because
you
don't
have
this
in
the
slides-
and
we
already
pointed
a
several
possible
issues
for
discussion
or
for
consideration.
I.
A
Please
I
have.
A
It
would
be
good
if
someone
can
actually
look
at
how
the
labels
are
handled
by
different
notes
in
different
cases.
It's
kind
of
a
tricky
job,
but
it
would
be
good
if
it
could
be
done.
A
A
The
other
one
is
that
we
had
about
a
year
ago.
A
discussion
on
if
I
think
the
starting
point
in
that
discussion
was
that
there
were
more
than
one
specification
that
said
that
the
this
service
header
needs
to
be
immediate
after
the
bottom
of
stock.
But
my
stack-
and
this
is
the
third
one
so
and
I
think
that
was
related
to
pseudo-wise,
so
maybe
Stuart
or
Matt.
You
can
try
to
figure
out
how
how
we
solved
it
at
that
time.
I,
don't
remember.
A
C
Tara,
please,
okay,
hi
Greg
I
want
to
look
at
this
a
little
bit
differently,
rather
than
retrofitting
beer
to
m
a
I
want
to
State.
You
know
to
me:
beer
is
a
replication
action
at
a
specific
LSR,
at
least
in
the
mpls
network.
C
F
H
I
H
Yeah
so
Tariq
you
mentioned
LSR
I,
would
say
l-e-r
and,
and
you
you
talk
about
the
BRS
action,
I
I-
think
we
really
should
stick
to
the
fact
that
the
beer
is
the
a
payload
of
nkos
here.
H
But
we
can
talk
discuss
further
later.
But
just
here
are
just
some
two
quick
comments
here:
I'll
I'll
get
back
to
to
Greg.
F
Yeah
actually,
I
think
that
Jeffrey
point
is
very
much
helpful
because
indeed
dfr
is
a
egress
router.
C
If
I,
if
you
allow
me
just
to
respond
quickly
so
I
to
me,
you
know,
LSR
is
not
the
core
of
this
discussion.
I
mean
to
me
if
you're
doing
transport,
multicast
transport-
and
you
know
you-
you
will
do
replication
at
multiple
nodes
or
call
them
whatever
you
want,
and
you
know
if
you're
going
over
mpls
I
would
like
to
do
this.
You
know
action
at
select
nodes,
so
the
question
is:
can
M
A
invoke
these
actions?
Thank
you.
H
We
can
discuss
that
further
separately,
yeah,
so.
A
It's
just
one
hope
and
you
might
want
to
do
yeah
some
who
am
but
I,
think
you
can
do
that
on
the
beer
directly.
H
H
H
F
Okay,
lo,
you
have
your
hand
raised.
F
And
then
I'm
just
curious,
okay,
okay!
So
let's
go
to
the
next
slide
and
I
think
that
I
try
to
capture
some
ideas
that
we
exchanged
before
the
meeting.
So
one
was
that
for
posted
M
A
in
beer
is
to
present
post-tech
m
a
as
part
of
the
beer
payload.
F
E
F
But
that
will
require
that
post
that
encapsulation
will
have
the
protocol
next
protocol.
B
F
And
then
use
the
same
registry
as
defined
for
beer
next
protocol
identifier
registry.
F
And
again,
that's
only
a
proposal,
it's
not
something
that
being
done
so
another
is
I,
think
that
was
from
Tony
P
not
to
set
s
beat
in
a
beer,
mpls
LSC.
F
But
I
believe
that
that
will
require
more
discussions
as
well
as
Jeffrey
proposal
that
will
look
at
beer,
mpos
label
stack
element
and
the
remaining
of
beer
header
as
a
two
separate
entities.
So
thus
there
might
be
a
post-tech
data
Mna
in
between.
F
So
I
think
that
we
have
at
least
three
proposals
on
a
table
for
discussion.
Esg.
J
F
No
gee,
no,
it's
not
putting
a
m
a
in
beer
header,
it's
putting
M
A
after
beer
header
and
that's
why
it's
important
to
have
a
distinct
protocol.
Identifier.
F
So
it's
not
part
of
a
deer
header,
so
beer
header
is
a
fixed
size
that
well
not
fixed
size,
but
the
size
is.
F
By
bit
string,
but
then
What
this
option
proposes
is
that
they're
proto-filled
in
the
beer
header
identifies
that
the
beer
header
is
followed
by
post
deck
data.
F
And
then
post
that
data
has
an
optional
Has,
a
Field
that
might
identify
their
payload.
J
F
J
Yes,
yeah
with
that
to
the
encapsulation
I
think
they
may
change
the
hierarchy
between
the
MPS
MLA
and
the
beer.
We
can
see
the
beer
as
a
upper
layer
of
MPS
and
Anime
is
the
part
of
the
mpis
layer.
Right
I
mean
if
we
put
something
after
the
beer
header
that
will
be
either
peer
specific
or
the
upper
layer,
specific
functionality,
and
it's
not
a
generic
mprs
functionality.
I.
F
I
agree
I,
it
does
put
it
on
a
beer
level
and
that
will
be
all
replicated
and
we
need
to
understand
the
consequences
of
this
and
see.
If
that's
what
we
want.
I
agree
and.
E
F
This
is
not
or
ironed
solution.
It's
just
one
of
the
mechanisms
that
I
thought
of.
But
yes,
you
are
correct.
There
are
some
implications
we
need
to
understand.
If
that's
implications,
we
are
comfortable
with
and
that's
what
we
really
want,
but
on
another
hand
what
it
gives
it
gives
this,
that
these
actions
would
be
applied
on
overlay.
F
Not
on
each
individual
so
basically
at
all
Lars
of
npls
underlay.
J
Okay,
so,
but
for
option
two,
do
you
mean
the
beer
label
can
be
not
located
at
the
bottom
stack
then
for
the
following,
the
bottom
stack
there
will
be
a
M
A
or
it's
a
steel
beer,
header,
I,
I.
F
Think
it's
a
good
question,
so
yeah
I
think
that's
a
good
question.
So
again
it
might
become
a
little
bit
more
trickier
because
again
the
requirement
would
be
that
this
beer
and
POS
label
will
be,
at
their
top
add
their
intended
dfr.
F
So
whether
we
can
safely
remove
bottom
of
the
stack
indication
that
will
again
have
some
issues
with
their
existing
implementations
deployed,
implementations
or
how
that
can
be
addressed
so
again,
each
option
as
I
understand
I
will
have
some
significant
discussion
and
consideration
require
before
it
becomes
a
solution.
J
Yes
and
For,
Me
Maybe,
the
another
option
is
to
have
the
ma
first
and
then
the
peer
header
follows
in
that
case.
We
use
something
something
some
other
indicators
in
the
Mna
to
indicate
the
existence
of
the
beer
header.
That
is,
we
can
call
it
an
peer
over
ampere,
7A
encapsulation,
which
is
slightly
different
from
the
current
temperature
over
mprs.
F
I
think
that
would
be
along
their
suggestion
from
by
Jeffrey.
That
would.
F
Their
mpls
label
stack
element
from
their
bit
string
of
the
deer
header,
so.
J
F
Mmaos
label
is
required
because
it
identifies
the
forwarding
table
to
be
used
how
to
resolve
the
bead
string,
so
it
it
is
required.
J
Okay,
maybe
we
can
discuss
this
further
offline.
F
H
Yeah
yeah,
indeed,
we
need
to
discuss
these
options.
Further.
Jj
already
spoke
about
this.
My
comments
about
option,
one
that
beer
is
no
longer
the
mpos
payloads.
H
If
we
do
option
one
and
option
two,
it's
not
exactly
to
me
how
it
is
done,
but
both
option
one
and
option
two
I,
don't
think
they
handle
the
situation
where
you
have
two
Legacy,
a
a
beer
forward
in
router
the
following
the
old
practice
and
then
the
bfr
beer
router
one
panel,
the
packet
to
be
a
router
2,
and
then
some
Transit
LSR
puts
a
a
a
a
a
PSD
MMA,
and
then
the
bfr2
will
be
screwed,
so
I,
I,
I
I,
think
we
have
issues
with
for
both
option.
H
One
option:
two
in
that
case
options
three,
which
is
not
on
the
slide
but
as
Jay
mentioned
and
Greg
mentioned,
that,
where
we
put
a
psdma
between
the
beer
label
and
the
rest
of
beer
header
that
that
one
works
well,
except
that
we
need
to
make
sure
that
we
don't
send
a
legacy.
H
Beer
router
or
a
packet
with
that
psdm
Mna
between
the
beer
label
and
the
rest
of
beer,
header
and
I
have
some
thoughts
on
how
that
can
be
done
and
that
it
actually
may
that
may
need
to
be
done
for
non-beer
situation
anyway
and
I
have
some
thoughts
written
down
in
the
email
I
mentioned
earlier.
So
we
can.
We
can
follow
up
for
for
further.
F
H
Yeah
that
that
is
already
to
the
to
both
to
both
lists.
E
H
We
have
some
offline
discussions
and
later
on,
I
realized.
The
real
issue
here
is
the
backwards
compatibility
and
so
before
the
meeting
I
summarized
the
that
on
that
on
that
point,
so
we
can.
We
can
follow
up
on
that
further.
E
A
E
A
B
F
Envisions
that
beer
mtls
are
labels.
That
element
can
be
anywhere
as
long
as
at
the
top
for
their
bfr.
F
And
I
would
say
at
this
time.
That
is
something
that
we
can
discuss
to
me
again.
Everything
is
possible
how
much
it
will
cost
how
how
difficult
it
will
be.
What
it
gives
us
do.
We
need
this
flexibility
I
believe
that's
something.
I
I
Okay,
yeah
sorry,
so
I
was
talking
about
the
option.
2
point
one
right,
so
isn't
it
this
optional
I
mean
the
yes
bit
set
mandatory
thing
is
even
applicable
for
ISD
m
a
so
that
we
can
place
our
ISD
Mna
anywhere.
The
stack.
F
In
a
reworked
beer
over
in
PLS
architecture,
then
it
gives
us
more
flexibility
but
I,
envisioned
that
it
would
not
cost
would
not
come
for
free
and,
as
Jeffrey
pointed
out
and
I,
think
that's
what
we
agree
is.
B
F
Pointed
out
that
we
are
creating
a
new
beer
header
version,
so
how
these
two
coexist.
G
The
second
option
will
be
pretty
much
harder
vision
of
beer.
As
far
as
I
see
we
violating
directly
the
current.
You
know
proposed
standard
rfcs.
If
we
don't
set
the
S.
The
first
option
is
more
subtle
because
we
do
not
prescribe
you
know
which
protocols,
beer
silicon
has
to
support
So.
If
you
add
a
new
protocol,
then
detecting
the
incompatibility
incompatibility
will
be
more
subtle.
We
basically
have
to
stick
more
signaling
into
igp
to
show
who
actually
understands
you
know
these
PS
M,
A
stuff.
F
Yeah,
thank
you
Tony
again
to
me
it's
all
about
compromise,
so
we
want
to
do
something.
Let's
see
how
difficult
or
easy
that
could
be.
So
that's
how
we'll
compare
these
Solutions.
K
Just
always
to
repeat
what
what
Tony
was
saying
so
in
the
beer
specifications
we've
not
specified,
you
know
not
setting
the
S
bit
right,
so
implementations,
just
probably
assume
as
bit
is
set
and
will
just
index
immediate
you
to
the
post
tag.
Data
for
beer
I
would
be
highly
surprised
if
implementation
would
deal
with
situations
where
the
sbit
is
not
set.
So
I
would
think
that
we're
going
to
invalidate
you
know
a
lot
of
implement.
Well,
the
implementations
that
are
there
we're
going
to
validate
them.
So
I
would
say
this
is
probably
very
costly
option.
G
G
G
A
A
B
G
E
F
F
Just
a
rendering
of
option,
one
which
I
think
that
easy
to
understand.
B
F
So,
basically,
what
it
shows
that
it
has
posted
M,
A
identifier
and
then
post
Tech,
MMA
header
include
some
product
field
that
identifies
the
payload,
which
follows.
H
So
indeed,
at
this
time
is
this.
Space
is
a
basically
a
theoretical
exercise
on
what,
if
we,
they
have
a
a
PSD
MMA
and
it
appears
yeah
in
a
beer
package
and
what
happened?
What
what
do
we
do.
H
Exact
use
case
we
we
don't
know
yet,
but
if
some,
if
somehow
that
becomes
possible,
then
then
we
need
to
to
figure
out
how
to
how
to
how
to
handle
the
issues.
And
we
have
we
talk
about
three
options
and
I
think
we
did
do
need
more
discussions
and
then
and
again,
please,
if
you're
interested
in
this
topic,
to
check
out
the
the
email
I
sent
out.
Sir
earlier
today.
H
F
Thank
you,
Jeffrey
and
I
I
agree
with
you
that
that's
what
I
try
to
present
that
the
current
state
of
Art
and
then
that,
if
even
when
there
is
a
need
to
do
post-tech
data
M
A,
then
there
are
certain
well.
Some
significant
work
and
discussion
have
to
happen
for
the
beer.
Specifics.
F
Okay,
so
that's
all
I
have
and
I
will
try
to
give
I'll.
C
Thank
you,
Greg.
All
right,
you
mentioned,
you
know,
stay
tuned
to
the
discussion
on
the
on
the
mailing
list,
so
there
are
good
ideas
here
to
follow
up
on
and
let
me
go
back
to
the
agenda
agenda
and
before
that
I
see
that
Laura
wants
to
speak.
Let
me
give
him
a
chance.
Go
ahead.
A
C
Yeah,
definitely
we
can
review
the
feedback
from
today
and
work
on
it.
If
you
think
there
is
an
explicit
action
item,
anyone
thinks
that
we
should
be
tracking
an
action
item.
Let
me
know
and
I'll
add
it
to
our
list.
C
Otherwise,
the
next
item
on
our
agenda
today
is
the
mpls
m,
a
header
solution,
draft
and
a
chance
for
the
authors
to
ask
for
any
clarifications
on
previous
comments
that
were
raised.
C
So
anyone
from
the
attendees
of
of
the
authors
of
that
draft,
please
hold
the
mic,
and
you
know
foreign,
if
you
have
anything
to
add.
Otherwise,
we
can
move
on.
C
I
presume
you
heard
me
and
you
don't
have
anything
or
anything
to
clarify
so
I'll
move
on
to
the
next
item
on
our
agenda,
which
is
future
agenda
items
for
future
interims.
C
A
Please
tell
the
shares
the
it's
true.
What
Turk
said
that
if
we
don't
have
again
that
we
cancel
so
there
might
be
a
space
for
discussion.
So
please
let
us
know
if
there
is
anything
you
want
to
discuss
thanks.
C
Okay
with
this,
we
come
to
the
end
of
the
agenda
of
the
day
and
if
nobody
else
wants
to
see
anything-
and
we
can
conclude
today
and
look
forward
to
the
next
up
upcoming
interim.
C
F
Oh
no
I'm,
just
reiterating
your
and
Jeffrey
call
for
continued
discussion
on
the
mailing
list,
using.