►
From YouTube: IETF114 MPLS 20220726 1730
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Okay,
it's
1
30..
I
don't
want
to
delay
it,
but
let
me
mention
I'm
expecting
my
co-chair
laura
anderson
to
be
joining.
I
did
text
him
and
hopefully
he
will
be
able
to
join.
A
So
before
I
proceed.
Let
me
welcome
everybody
for
joining
the
mpls
working
group
session
for
ietf
114,
your
working
group
chairs
for
mpls
working
group,
myself
tarek
saad
loa
anderson,
who
am
I
whom
I'm
is
expecting
to
join
and
he
did
join
now.
A
We
have
nick
lehman
as
well,
but
he's
not
able
to
join
us
today.
Our
secretary
mack
has
been
very
helpful
in
producing
a
report
and
other
things,
mac,
chen
and
a
reminder
to
everyone
that
this
session
is
being
recorded
before
I
flip
to
the
next
slide.
I
know
that
lower
wanted
to
give
a
couple
of
words
and
he's
already
raised
his
hand
so
I'll
give
him
the
stage
to
proceed.
Please
go
ahead.
B
B
B
But
what
happened
was
that
joel
help,
and
that
was
the
responsibility
at
that
time.
He
beat
us
to
the
goal
line
and
he
actually
shorted
the
mpls
working
group
in
march
1997
and
the
meeting
we
had
in
san
jose
was
kind
of
a
mix
between
above
and
a
normal
working
group
meeting,
as
I
remember
it.
Dj
and
yours
were
sharing,
and
I
was
a
notetaker
and
roscal
and
eric
rosen.
B
B
So
that
was
all
the
all
the
things
that
I
people
requested
slot
people.
People
made
presentations
that
wasn't
kind
of
a
company
sponsored
and
things
like
that.
B
So
I
think
we
could
actually,
if
we
want,
we
could
consider
august
15
1997
at
our
birthday
and
it
actually,
the
that
day
is
actually
corresponding
to
the
meeting.
In
the
summer,
so
it's
wednesday
tomorrow,
so
we
can
say
that
we
made
25
years
and
we
are
going
strongly
into
the
next,
whatever
it
will
be
25
years.
B
A
Okay,
thank
you.
Lower,
I'm
very
proud
to
see.
Mpls
has
made
it
to
the
25-year
tick
mark
and
I
want
to
wish
it
another
50
or
maybe
100
years.
A
Okay,
I'll
have
to
run
a
little
bit
faster.
So
let
me
progress
to
the
next
slide
and
unless
you,
I
still
see
you
raising
your
hand
lower.
But
let
me
know.
C
B
A
Usual
time
where
we
present
the
note
well,
which
many
may
already
have
been
acquainted,
but
for
those
who
don't
know
about
it,
please
you're
encouraged
to
read
the
best
current
practices
about
contributions
and
collab
participation
at
itf.
A
A
bit
of
administrative
pointers,
we
do
have
an
mpls
working
group
wiki.
We
encourage
you
to
visit
that
it
has
informative
information
about
the
activities
that
the
working
group
is
working
on.
We
also
have
a
github
page,
so
we
do
once
in
a
while
use
it,
and
we
we
plan
to
continue
to
use
that.
A
A
So
those
who
don't
who
have
not
uploaded
the
slides,
know
themselves.
A
We
do
have
two
errata's
reported
since
last
time
we
met
the
first.
One
is
pretty
straightforward.
I
think
it.
The
authors,
dropped
the
rro
ipv6
sub-object
from
the
sentence,
although
they
meant
say
two
flags.
A
The
next
erata
is
is
against
rfc
3031..
There
is
a
claim
that
the
u
usage
of
the
tur
of
the
of
the
abbreviation
l1,
l2
and
l3,
may
be
confused
with
for
labels.
Mpls
labels
may
be
confused
with
layer.
One
two
and
three
discussed
that
with
my
co-chairs,
and
we
did
agree
that
with
25
years,
I'm
not
sure
how
many
years
for
our
rfc
3031
it's
been
alive
and
people
are
by
now
are
very
well
acquainted
with
what
l1,
l2
l3
means
in
the
context
of
rfc
3031.
A
A
We
have
an
rfc
which
is
stuck
in
miss
ref
right
now,
and
I
checked
the
the
the
mishra
pointer
it's
pointing
to
a
draft
that
has
expired.
I
know
the
I'm
not
sure
if
there
is
a
co-author
present
that
want
to
comment
on
that.
But
I
know
one.
The
main
author
is
in
a
way
so
we'll
have
to
follow
up
on
that
and
feel
free
law
to
intervene.
A
If
you
know,
if
you
know
of
an
update
on
that
in
terms
of
new
working
group
documents,
so
the
working
group
was
active
the
past
period
and
we
have
four
documents
that
got
adopted.
A
Thank
you
to
the
working
group
and
the
co-authors
I'll
quickly,
skim
through
the
the
documents
and
before
I
do
that.
Let
me
give
laura
a
chance
to
to
comment.
B
So
concerning
the
document,
the
sfl
control,
we
have
appointed
mcshanis
the
shepherd
and
he
will
actually
submit
the
or,
if
you
start,
writing
the
shepherd's
write-up
as
soon
as
stewart
repost.
The
draft,
because
it's
expired.
A
A
C
So
hi
everyone,
my
name,
is
rakesh
gandhi
and
presenting
the
draft
on
the
mpls
iom
on
behalf
of
the
co-authors
listed
next
slide.
Please.
C
So
agenda
is
a
quite
simple
requirements
and
scope.
The
summary
and
the
next
step
and
next
slide
please
so
requirements
and
the
scope
of
this
draft
basically
is
to
transport
the
iom,
data
fields
with
mpls
encapsulation.
C
So
in
scope
is
the
work
that's
being
done
in
the
ippm
working
group.
So
the
first
draft,
the
iom
data
is
in
rfc.
Now
I
think
it's
rfc
9197,
I
believe
then
the
next
one
is
for
direct
export,
but
irrespective
of
the
data
fields
here,
the
the
scope
is
on
the
encoding
or
end
cap
on
the
mpls
side
and
cover
both
the
edge
to
edge,
as
well
as
the
hop
by
hop
iom
cases.
C
So
draft
has
been
around
for
a
few
years
now
used
to
be
in
spring.
It
was
moved
to
mpls
about
a
year
and
a
half
ago
we
had
mplsrt
expert
review.
We
received
good
comments,
including
the
gas
channel
for
iom,
and
this
was
just
before
the
m,
a
work
that
got
started
since
then.
C
The
encoding
of
the
end
cap
has
changed
a
few
times.
This
one
is
the
latest
encoding,
that's
in
the
drop
jacks
mpls
mna
header,
so
we'll
just
review
that
encoding
today
and
next
slide.
This.
C
So
the
m
a
and
indicators,
basically
as
defined
in
the
direct
jackson
draft
this
morning
that
was
presented
in
pulse.
C
There
is
a
bit
a
flag
in
the
ttl
in
the
next
lse
after
the
m,
a
label
which
is
the
special
purpose
label
that
indicates
that
there
is
post
tech
data
present
and
if
there
is
a
need
to
process
it
hop
by
hop,
then
there
is
another
flag
for
it.
C
So,
as
mentioned,
there
are
two
flags
defined
in
the
ttl
field
and
in
case
of
n2n
iom,
there
are
option
types,
that's
defined
for
that
in
the
ippm
documents
are
applicable
and
for
hub
by
hop.
There
are
also
option
types
defined
for
that
are
applicable
in
these
two
cases
and
next
slide.
Please.
C
C
So
the
complete
packet
with
encoding
defined
in
this
draft
there
is
an
mna
label,
the
special
purpose
label
in
the
next
lse.
There
are
two
flags
defined
in
ttl
and
post-tech
data.
Basically
the
iom
data
fields
next
slide,
please
so
the
procedure
wise,
the
encap
node,
will
add
the
iom,
data,
the
option
type
and
the
indicator
so
which
is
the
m
a
label
and
the
flags.
C
In
case
I
went
edge
to
edge.
There
is
a
flag
bni
flag,
because
the
hub
by
half
flag
is
not
set
in
the
m.
A
the
intermediate
nodes
will
skip
the
iom
processing
and,
as
is
the
case
with
mna,
that
the
mne
header
needs
to
be
received
by
the
decap
node
that
contains
the
those
flags
in
the
header
and
basically
d-cab
node
will
process
the
iom.
C
It
may
point
the
data
iom
data
to
the
slow
path
and
it
will
remove
the
iom,
data
fields
and
the
mna
header
and
next
slide.
Please
so
only
difference
in
hub
by
hub
case
is
that
there
is
a
new
flag
set
for
it
and
the
intermediate
nodes
will
see
it
and
it
will
process
the
iom
data
from
the
posttec
data
option
types
next
slide.
Please.
C
There
is
some
good
feedback
for
the
mpls
extension
header
draft
that
hyu
presented
this
morning.
So
we
do
have
a
gas
base.
Posttech
data
defined
it
probably
makes
sense
to
use
the
extension
header
as
a
common
header,
assuming
that's
what
the
working
group
consensus
or
acceptances
this
can
be
done
as
part
of
the
working
you
process,
but
if
you
have
any
feedback
and
suggestion
on
that,
please
let
us
know,
and
in
the
end
we
are
requesting
a
working
group
adoption
for
this
trial.
C
I
think
that's
all
I
had
thanks.
Thank.
D
Because
it
will
be
embarrassing
to
me
okay,
so
I
have
a
couple
questions.
First,
rfc
5586
defines
gach4
only
to
be
used
on
oam
packets,
so
it's
not
to
be
used
on
the
data
packets,
so
that
makes
it
problematic
of
applying
iam
to
the
data
packets,
which
is,
I
understand
it
intention.
D
So
you
know
that
pre-allocated,
it's
basically
when
each
transit
node
adds
data
to
the
packet.
I
think
that's
a
very
serious
impact
on
performance
and
I
would
be
very
much
concerned
about
that
to
be
supported
in
mpos.
D
Not
useful
option
for
npls,
so
maybe
in
some
other
environments,
it's
useful,
but
in
mpls,
especially
since
it's
beneficial,
but
not
required
options.
So
it's
something
that
concerns
me
and,
second
of
all,
your
request
to
working
group
adoption
is
not
clear
because
you're
proposing
a
particular
encapsulation
which
cannot
be
used
on
data
packets.
So
that
makes
this
solution
that
you
are
proposing,
not
realizable.
C
C
Okay,
thanks
greg
for
the
so
gsch
recommendation
came
from
the
mplsrt
expert.
I
do
agree
that
in
5586
it's
mentioned
it's
not
for
the
pro
or
the
for
the
data.
E
F
D
C
Yeah
and
currently,
as
you
know,
there
is
only
one
proposal:
that's
the
highway
drop
for
post,
like
data
encoding,
and
that
seems
to
be
good.
It's
not.
D
A
Thank
you.
I
am
next
in
the
queue.
My
question
hopefully
is
very
quick
rakesh.
Is
there
any
additional
validation
that
the
ingress
will
have
to
do
before
triggering
this
action,
be
it
edge
to
edge
or
hop
by
hop
like
capability
check,
specifically
the
edge
to
edge?
Does
it
have
to
check
if
the
egress
is
capable
of
processing
the
extra
header
or
even
the
action
timestamping
thanks.
C
Signaling
is
required
from
egress
and
if
up
by
up
then
up
as
well-
and
this
is
either
part
of
the
mna
capability
signaling
or
there
is
also
quite
a
bit
of
work
going
on
with
I-feet
and
other
pce
based
signaling
as
well
for
that
capability,
but
yeah
there
is
definitely
to
avoid
dropping
the
packets.
So
we
do
need
the
capability
signaling.
A
I
don't
see
anyone
else
in
the
queue,
so
thank
you.
Rakesh
I'll
move
on.
C
G
G
So
one
of
the
comment
was
how
to
handle
reserve
bits
and
initially
we
had
written
it
as
a
should
be
zero,
and
the
command
from
working
group
was
to
make
it
as
a
must
be
g
road
on
transmission
and
ignored
on
the
received
side,
and
I
think
that
is
fair
enough,
and
unless
anyone
has
any
other
option
about
this,
I
think
we
are
okay.
With
that
yeah
we
can
go
to
the
next
slide.
G
G
We
don't
think
that
maybe
a
good
option
are
really
needed,
because
there
may
not
be
a
deployment
where
you
really
want
to
have
empty
as
well
as
on
top
of
it
flex
elbow
so
you
will
be
using
either
of
them,
and
maybe
that
was
the
reason
I
don't
have
historical
reason,
10
years
back,
why
it
started
with
two
different
draft
and
then
we
finally
decided
to
merge
it.
So
I
think
we
would
like
to
go
with
the
way
it
is
currently
implemented
and
the
way
the
draft
is
so
that's
all.
A
We
have
lower
in
the
queue
and
go
ahead,
though,.
A
A
H
He's
going
so
I'm
at
the
bike,
so
I
do
not
have
slides.
I
was
hoping
that
maybe
ron
had
uploaded
the
slides.
H
I
can
give
an
update
of
where
closer
okay,
so
I
can
give
an
update
of
where
we
stand.
With
respect
to
this
in
the
document
in
the
lsp
ping
document
we
had
several
modes
and
one
of
the
modes
is
that
we
want
to
be
able
to
return
the
the
ping,
the
reply
via
control
channel-
and
it's
not
clear
at
the
time
why
we
did
that.
I
think
there
was
some
concern
that
if
you
return
it
over
another
lsp
or
something
and
you're,
you
know
debugging
lsps.
H
That
would
be
a
problem,
so
we
so
we
introduced
that
mode
and
then-
and
then
we
said,
oh
to
make
sure
that
happens.
Let's
make
make
the
packet
go
up
to
the
control
plane
at
every
hop.
So
that's
one
use
of
router
alert
the.
H
Make
sure
that
the
reply
or
the
original
message
doesn't
make
it
past
the
end
of
the
mpls
domain
and
somehow
get
injected
into
traffic
outside
of
that,
and
we
have
several
ways
of
doing
that,
so
we
don't
need
to
do
a
router
alert
for
that
one
one
point
was
brought
out
that
in
so
the
way
we
do,
that
is
we
set
the
destination
address
in
ipv4
to
127,
slash,
I'm
trying
to
think
eight
127.00,
no
127,
slash,
eight
and
unfortunately
in
in
ipv6
there
is
not
a
whole
subnet
that
you
can
use.
H
Similarly,
there's
a
single
address.
I
think
it's
colon
colon
one
which,
which
is
something
that
greg
had
pointed
out,
so
that's
a
little
bit
of
a
restriction,
but
at
the
same
time
you
know
it's
in
we
set
the
ttl
to
one.
We,
we
set
a
bunch
of
things
so
that
the
packet
won't,
you
know,
go
beyond
the
last
mpls
router,
and
so
the
idea
was,
let's
just
deprecate
doctor
alert
and
that's
the
direction
that
ipv6
guys
want
to
go.
Independent
of
you
know
what
we're
doing
here.
E
H
Bing
so
modulo
this
one
comment.
H
I
think
this
draft
is
ready
to
go
in
terms
of
you
know
at
least
to
do
a
working
working
group
adoption,
and
then
you
know
if
we
have
to
iron
out
a
few
things:
okay,
but
then
you
know
we
want
to
get
to
the
next
level
where
we
we
say
this
is
that
whole
approach
of
having
a
router
alert
in
lsd,
ping
packets
should
go
away
and,
of
course,
between
the
working
group,
adoption
call
and
working
group
glasgow.
H
H
Where
this
draft
stands
and
I'm
sorry
I
don't
have
slides,
but
that's
a
that's
a
summary
of
this.
A
Okay,
thank
you
kiriti.
We
have
people
in
the
queue
for
asking
questions
and
let
me
ask
laura
to
go
ahead.
B
So
hello
kiriti.
Actually
the
point
with
this
draft
is
that
you
presented
it
once
before,
and
you
are
asking
for
working
group
adoption
and
we
didn't
have
one
single
reaction
on
the
mailing
list,
so
you,
your
task,
is
to
actually
make
sure
that
you
have
a
discussion
that
can
motivate
make
it.
The
working
group
document
thanks.
A
H
E
Yeah
there
is
a
farley,
so
you
mentioned
that
the
ipv6
group
is
also
going
in
that
direction.
Could
you
elaborate
a
little
bit
more
because
I
think
there's
an
individual
draft
but
no
discussion?
I
I
could
be
wrong
on
that.
E
F
H
Yeah
saying
you
know
we
we
want
to
get
rid
of
router
alert
and
I
think
in
general
they
want
to
make
sure
that
the
extension
headers
that
are
being
used
are
ones
that
you
know
actually
are
being
used
and
will
go
forward.
So
I
don't
I'm
not
a
regular
attendee
of
six
man.
So
that's
more
of
a
side
comment
I
mean
whatever
we
decide
here.
H
We'll
have
some
influence
there,
but
you
know
really.
If
we
are
not
using
it,
whatever
six
man
is
doing.
If
nobody
is
in
has
implemented
lsd
ping
with
the
router
alert
option,
either
in
v4
or
v6.
E
A
D
Hi
I'm
gregory
erickson,
as
committee
pointed
out,
so
there
is
a
problem
with
the
ipv6
address
being
documented
in
lspp.
D
A
Okay,
no
one.
H
A
H
So
so
let
me
switch
to
this
one
in
in
this
document,
we've
proposed
a
a
registry,
an
iana
registry,
for
what
we
are
calling
the
mpls
first
nibble,
which
is
the
first
four
bits
after
the
last
label:
the
label
with
a
end
of
stack
bit
set,
so
so
we're
up
to
division
o2
here-
and
this
is
joint
work
with
stuart
bryant,
matthew,
bocce,
greg,
mursky
and
lowe
anderson
next.
H
H
We
actually
use
zero
for
both
survivor
control
word
and
that
next
control
word
and
then
we
use,
I
forget
what
two
or
one
or
two
for
the
beer
header,
but
these
are
sort
of
just
allocated
and
basically
everyone
just
says
avoid
four
and
six
and
then
you're
good.
H
So
that
kind
of
answers,
the
question:
why
a
registry,
the
other
part
that
there
was
some
confusion,
is:
does
this
registry
mimic
the
ip
version
registry
and
the
answer
is
very
clearly?
No,
we
avoid
four
and
six,
but
if
tomorrow
there's
an
ip
version,
seven,
the.
I
H
Could
also
have
version,
I'm
sorry.
This
first
nibble
registry
could
also
also
have
an
entry
for
seven,
and
if
you
follow
the
recommendations
in
the
document,
there
will
not
be
confusion
between
ip
version.
7,
packets-
and
you
know,
pseudo
wire.
Sorry
post
stack
data,
so
the
recommendation
here
is:
you
can
send
a
packet,
that's
a
native
ipv4
or
a
native
ipv6
packet
without
vsd.
H
H
Now
can
we
mandate
this?
We
already
have
an
rfc
that
says
at
least
for
ethernet
pseudo-wires,
that
you
must
have
it,
but
you
can't
mandate
it
in
the
sense.
There
are
implementations
that
don't
do
this.
You
can
rot
them
across
the
knuckles.
You
can
do
various
things.
The
providers
who
have
this
should
understand
that
they're
opening
themselves
up
to
packet,
reordering
and
other
kinds
of
trouble,
but
you
know
all
we
can
do
is
set
the
rules
and
people
can
decide
whether
they
want
to
follow
them
or
not.
H
So,
for
example,
with
pseudo
wires,
you
say
in
the
control
plane
whether
you're
going
to
insert
a
control
word
or
not
or
should
be
in
the
data
plane,
and
so
many
of
the
mna
proposals
say
there's
a
bit
in
you
know
the
moral
equivalent
of
the
fbi,
special
purpose
label.
That
says
there
is
psv
in
the
packet
or
should
be
both,
and
I
think
stuart
put
it
in
this
way
that
he
doesn't
like
the
belt
and
suspenders
approach.
H
H
So
I
think
you
know
that
discussion
that
we
had-
and
some
of
it
was
pretty
vigorous
in
the
design
team-
needs
to
happen
in
the
mprs
working
group
at
large.
But
I
think
the
questions
to
ask
are:
is
this
stuff
useful,
but
does
it
belong
in
the
itf?
H
A
Yeah,
I
have
a
question
please
so
with
signaling
it's
a
little
bit.
I
understand.
If
you
signal
in
advance,
you
know
I
I
will
be
sending
you
a
control
word
and
then
you
start
sending
traffic
after
and
that's
a
kind
of
a
static
state
that
you're
in
that
all
your
flow
or
all
your
packets,
from
ingress
to
egress
will
contain
the
control
word
and
that's
understandable,
but
when
you're
doing
on
demand
type
of
thing,
where
you
enable.
A
You
know
you're
saying
here
a
control
word.
I
can
give
a
different
example.
You
enable
something,
but
then
your
flow
is
already
started,
so
some
packets
may
carry
that
or
some
some
packets
may
not,
and
there
will
be
a
timing
issue
between
control
plane
and
the
data
packets.
So
we
cannot
correlate
when
the
state
is
ready,
for
you
know,
control
work
being
present
at
that
time,
so
I'm
not
sure
yeah,
that's
signaling.
I
mean
there
is
advantages
in
getting
carrying
it
in
the
data
plane.
In
that
sense,.
H
Yeah
clear
guys
do
that
as
well.
So,
even
though
they
have
a
lot
of
signaling
in
the
control
plane
in
the
data
plane,
they
have
a
special
purpose
label.
That
says,
I
have
a
beer.
H
You
know
beer
data
which
comes
after
the
stack,
so
basically
they
have
brpsd,
but
that's
heralded
by
a
special
purpose
label.
So
we
do
both
like
the
control
words
for
that
net
and
pseudo
wires
are
signaled
in
the
control
plane,
but
not
the
data
plane
in
beer.
We
do
both
and
then,
as
you
said,
there
may
be
cases
where
it's
more
ad
hoc
and
so
you'll
have
things
that
are
signaled
in
the
data
plane,
but
not
in
the
control
control
plane.
H
A
Okay,
and
do
you
want
controlled
flip
between
slides.
J
J
Okay,
we
know
some
technique
on
challenges
to
mps.
First,
one
is
the
amherst
legs,
the
mechanism
of
source
education
for
mp2p
connections.
This
causes
the
difficulty
and
the
complexity
for
omo
or
mps.
A
A
Do
you
like
to
take
the
questions.
D
Thank
you.
Can
you
clarify
what.
E
A
J
J
J
The
first
is
the
ipv6
source
address
is
used
to
do
for
more
sourcing
additives
and
the
second
the
ipv6,
that's
kinda
can
indicate
the
payload
type
and
the
third
is
the
ipv6
flow
label
can
are
used
for
the
smp
and
the
last
one
is
the
in-cab
solutions
for
the
new
features
have
been
defined
well
in
the
ipv6
and
can
be
reused
easily
next
step.
Please.
J
Okay
and
in
order
to
support
the
mps
based
on
the
jp
tunnel,
the
method
carrier,
ms
label,
stick
information
is
defined
as
follows:
pressure
all
well
known,
ipv6
profiles
need
to
be
assigned,
and
then
encapsulation
the
ms
label,
and
the
second
is
the
ipv6
pressure.
Prefix
can
be
followed
by
maple
the
mps
label
in
cap
solutions
to
form
120
bits.
J
I
J
J
Okay,
if
all
the
empty
labels
type
cannot
be
placed
in
the
ipv6
distinction
device,
ipv6
the
hydra
can
be
used
to
host
the
remaining
has
mps.
Labor
stake
in
this
figure
is
defined,
ibv6
amputated.
J
J
Some
considerations
about
the
control
plan.
First
of
all,
the
jp6
only
processor,
the
way
to
carry
mps
label,
cab
solutions
in
the
data
plan
and
the
amps
can
travel
and
actually
need
to
be
changed.
So
I
missed
the
label
can
still
be
distributed.
Using
existing
control
plan
doesn't
change
anything
okay.
Next,
please.
A
J
D
Okay,
thank
you.
Okay.
Okay,
now
I
have
two
clarification
questions.
The
first
is
to
the
first
slide,
where
you
mentioned
that
motivation
for
this
work
is
difficulty
in
complexity
using
mpos,
oam
and
second,
is
how,
in
your
opinion,
this
work
is
related
to
mpls
over
udp
rfc,
7510
and
mpls
sr
acid
impellers
or
ip
rfc
8663.
J
Sorry,
my
level
is
not
a
stable.
I
cannot
listen
very
clear
and
jamie.
Can
you
help
claire
for
it?
For
me,
okay,
jamie.
F
Yeah,
I
can
try
to
help
to
help
to
answer
that
one.
I
think
the
complexity
about
the
oem
for
mprs
is
mainly
due
to
the
lack
of
the
source
node
indication
in
the
nprs
package,
so
that
is
usual
document
is
talking
about.
As
for
the
ampers
over
ip
and
udp
encapsulation,
my
understanding
is,
it
is
a
separate
thing
from
the
npr's
original
impr's
encapsulation,
so
we
were
comparing
the
npr's
absolution
with
this
new
proposal
here.
Okay,.
D
Little
bit
that
you
say
that
mpls
oem
packet
don't
have
source
information,
because
if
we
use
ipedp
encapsulation
for
oem
packets,
as
we
discussed
earlier,
for
example
in
lspping,
so
it
does
include
ipsource
address.
F
D
F
Yeah
that
one
has
also
been
mentioned
in
the
presentation.
Well,
you
can
see.
Sfl
is
one
option.
It
is
not
widely
implemented
or
used
in
the
network.
D
A
Okay,
greg:
please
follow
up
on
the
mailing
list
as
well,
so
I'm
next
in
the
queue
tarek
sad
as
a
working
group
participant
the.
As
you
know,
the
mpls
label
contains
an
additional,
in
addition
to
the
label,
value,
ttl
and
traffic
class
fields
and
the
ib
header
as
well.
The
ipv6
in
this
case
contains
traffic
class
and
ttl
so
which
ones
will
be
respected,
and
your
in
your
encoding
proposal,
if
they're,
contradictory
or
different.
K
Hello
tarik.
Can
I
take
this
question.
K
Okay,
tariq,
I
think
that's
a
very
good,
very
good
question.
In
fact
this
has
been
taken
into
account
until
now.
We
think
that,
in
order
to
maintain
the
original
impr's
encapsulation,
we
recommend
that
the
mprs
ttl
traffic
class
will
be
used
instead
of
the
ipv6
ttl
or
the
other
traffic
class.
That's.
This
is
the
answer
until
now,
but
we
thinking
maybe
in
the
future,
if
possible.
Maybe
we
only
encapsulate
encapsulate
the
label
value,
but
the
ipv6,
ttl
and
traffic
class
can
be
reused,
but
I
think
that
means
much
change.
A
K
In
fact,
yes,
in
fact,
you
use
not
a
ipv6
address,
but
you
know
that
we
talked
about
some
of
the
this
generalized
srv6.
I
mean
this
is
the
segment
that
encapsulated
the
impr's
label,
so
we
call
it
a
type
of
this
seed,
maybe
more
appropriate.
K
K
A
Okay,
I
don't
know
if,
okay,
I
don't
see
so
sorry
ac.
You
want
to
ask
a
question.
I
A
A
Okay,
that's
it
that's
it
and
we're
right
on
time.
I
thank
you
so
much
the
presenters-
and
this
was
our
last
presentation
for
today
again
thank
you
for
joining
and
contributing
to
the
working
group
looking
forward
to
ietf
115.
Thank
you
lava.
If
you
want
to
see
any
closing
remarks,
go
ahead.
B
No,
I'm
fine,
I
think,
next
time
it's
london,
it
might
be
possible
to
travel.
Even
from
me
see
you
in
london,
bye.