►
From YouTube: IETF114-PCE-20220728-2130
Description
PCE meeting session at IETF114
2022/07/28 2130
https://datatracker.ietf.org/meeting/114/proceedings/
A
Hi
everyone
welcome
to
the
second
session
of
pc
working
group
and
the
last
session
of
the
day.
A
The
note
well
still
applies
julian
explained
all
the
processes
at
the
start
of
the
meeting
yesterday.
It
continues
to
apply.
Please
take
care
of
ipr
and
all
our
policies,
especially
with
respect
to
code
of
conduct
as
well.
If
you
are
in
person
currently
in
the
room,
please
make
sure
to
use
the
meet
echo
lite
client.
There
are
qr
codes
as
well.
We
will
be
using
meet
echo
to
maintain
our
cues.
Please
help
your
remote
chairs
to
do
that
quite
well
and
make
sure
to
wear
mask.
A
A
Again,
a
reminder
that
maintain
the
code
of
conduct
of
itf
as
per
bcp
54.
A
Just
a
continuation,
we
have
hari
taking
the
minutes.
So
thank
you
for
that.
Please
help
hurry
out.
I've
put
the
link
to
the
meeting
in
the
chat
as
well.
When
you
are
speaking,
please
state
your
name.
We
have
not
too
much
of
a
tight
agenda,
so
there
is
a
discussion
time.
We
will
use
it,
but
in
case
we
overrun.
Of
course,
please
use
the
mailing
list
and
the
chat
for
further
discussion.
A
So
we
covered
segment
routing,
which
was
in
part
one
of
our
agenda.
Today
we
have
then
starting
with
stateful
pce,
some
new
proposals
on
tetnet
and
nrp
id
in
psep.
So
these
are
the
next
set
of
presentations
that
we
have
today.
A
A
Mike
I'll
be
giving
you
just
one
second
mike
I'll,
be
giving
you
slight
control,
so
you
should
have
it
now.
You
should
be
able
to
move
slides
yourself.
B
Okay,
yeah
thanks
hi
everybody.
This
is
mike
from
cisco
systems.
I'm
presenting
the
psep
operational
clarifications
draft.
B
So
I
just
to
give
a
brief
summary
of
the
draft
there's
about
six
points
that
we
cover
in
the
draft.
So
some
of
these
points
are
basically
informational
and
some
of
these
are
like
normative.
So
I'll
go
through
these
six
points,
so,
first
and
kind
of
very
important.
We
introduce
this
optimization
to
the
psep
protocol,
where
we
make
the
pc
request
and
pc
reply
messages
optional,
and
this
basically
reduces
the
amount
of
messages
that
you
need
to
send
when
bringing
up
the
tunnel.
B
Instead
of
sending
three
messages,
you
basically
just
have
to
send
one
message
so
before
you
have
to
send
a
pc
request,
then
wait
for
pc
reply
and
then
p
sent
the
report,
and
now
we
basically
simplified
by
allowing
you
to
send
the
report,
so
we're
not
sure
like
basically
why
it
was
done
that
way
originally,
but
it
seems
that
a
lot
of
vendors
are
are
doing
it.
So
so
this
will
be
an
update
to
the
rfc8231.
B
Next
point
is
we
we
introduced
kind
of
this
terminology,
for
what
is
a
p
sub
tunnel
versus
a
psep
lsp
and
the
tunnel
is,
is
the
entity
that's
identified
by
the
pspid
symbolic
name
versus
the
lsp?
Is?
Is
an
instance
of
the
tunnel
that's
used
for
make
before
break
and
the
lsp
is
identified
by
the
lsp
identifiers
tlv.
B
So
just
even
introducing
these
two
names
is,
I
think,
useful
in
other
drafts
as
well.
B
Third,
we
clarified
the
that
the
psep
association
contains
lsps
and
not
tunnels,
I'm
not
sure
if
it
was
very
clear
before,
but
we
just
kind
of
stated
explicitly
and
it's
still
possible
that
a
tunnel
can
be
in
the
association
when
all
the
cell
speeds
are
in
the
association
and
it's
possible
that
some
of
the
lsps
may
be
in
one
association
and
some
may
be
in
the
other,
such
as
when
you're
changing
from
when
the
tunnel
is
changing
from
one
association
to
the
other
in
a
make
before
break
fashion.
B
B
B
B
B
For
sr,
there's
no
such
thing:
there's
no
record
route
for
sr,
so
basically
we're
not
sure
really
why
it
was
these
srro
objects
were
defined
and
some
vendors
kind
of
mistake,
a
mistake,
the
rro
to
be
like
a
current.
Well,
I
don't
want
to
say
mistake,
but
they
they
treat
the
ro
to
be
like
a
current
path
and
the
ero
to
be
like
a
desired
path
or
something
like
that
and
so
yeah.
It
led
to
again
some
confusion.
B
B
So
here's
some
just
brief
history,
so
this
draft
was
first
introduced
in
itf
110
in
july
2019.
So
like
three
years
ago
and
since
then
there
was
not
much.
There
were
some
additions,
but
there
were
no
fundamental
kind
of
changes.
B
So,
basically
yeah.
I
wanted
to
make
this
presentation
kind
of
quick
to
give
room
for
questions
so
and
comments.
So
basically
the
the
thing
with
this
draft.
B
Informational
and
normative
content-
and
I
think
that's
fine-
I
saw
quite
a
bit
of
other
drafts,
or
at
least
a
couple
other
drafts
that
have
the
same
the
same
structure.
So
what
did
what
I
saw
down
is
that
they
spell
out
which
sections
are
informative
and
which
are
normative.
B
A
Thank
you
mike
first
any
questions
on
the
mic.
We
have
time
so
people
wanna
talk
about
the
issues
we
can
do
that.
Otherwise.
This
question,
which
is
right
on
your
screen,
can
also
be
answered.
I
see
johnny
in
the
cube.
D
Since
you,
since
you
bring
up
the
question
on
this
slide,
I
guess
I
would
have
a
mild
preference
for
keep
it
option.
One
keep
it
in
a
single
draft
and
clearly
separate
the
two
kinds
of
content.
B
Yeah
yeah
that's
same
with
me
yeah.
I
think
sometimes
it's
it's
kind
of
hard
to
say
what
exactly
is
informational
versus
standard
there's
not
like
a
very
clear
line
so
having
it
in
one
draft,
makes
it
a
little
bit
easier
than
to
have.
You
know
that
content
balance
between
two
two
different
drafts,
so
I
agree
with
you.
A
E
Yeah,
pretty
basically
going
to
echo
the
same
thing
I
meant
to
reply
to
the
list,
but
drew
kind
of
raised
those
you
know
what
what
is
the
way
to
kind
of
document
this,
whether
we
want
to
split
it
up
or
have
one
draft,
and
I
really
kind
of
see
the
operational
draft
as
almost
like
a
checkpoint
on
the
you
know,
the
implementations
of
pc
with
a
lot
of
implementations
now
have
kind
of
converged
on
what's
being
described
in
this
document,
and
so
since
there
is
some
updates
and
clarifications,
and
it
is
kind
of
that
you
know
checkpoint
kind
of
you
know
from
my
view.
E
I
do
like
option
one
and
keeping
in
the
same
draft
and
just
describe
which
is
doing
specific
updates
versus
which
is
just
doing
clarifications,
and
with
that,
of
course,
you
know,
since
as
an
implementer
to
get
to
this
convergence
with
a
lot
of
vendors.
It's
it's
a
really
good
thing,
so
I
do
believe
we
should
adopt
this.
Thank.
A
So,
from
my
point
of
view,
my
mild
preference
would
be
two
separate
drafts,
but
of
course,
like
working
group
preference
would
take
over.
That's
just
me
as
an
individual
and
mainly
because
when
I
currently
read
the
draft
I
find
like
you
know,
the
separation
is,
as
you
yourself
said,
that
this
separation
is
hard
to
do
and
that's
why,
in
a
single
document
I
kind
of
found
it
to
be
little
hard,
because
we
we
say
and
update
and
immediately
we
jump
into
an
example.
A
And
then
we
start
going
into
an
example
which
actually
doesn't
change
anything
from
rfc8231,
but
it's
just
explaining
it
in
a
much
better
way.
I
thought
that
if
we
do
it
in
a
single
document,
we
should
clearly
find
a
good
way
to
separate
things.
Talk
about,
like
you
know,
maybe
start
with
an
update
as
in
like
what
are
the
normative
changes
upfront
and
then
go
into
examples
and
say
that
once
this
normative
changes
have
been
applied
now
these
are
the
set
of
examples
which
will
clearly
explain
how
things
are
currently
functioning.
A
So
I
will
try
to
work
with
you
guys
and
see
if
we
can,
like
you
know,
make
this
very,
very
clear
clear.
What
is
an
update
and
what
is
just
like
you
know,
just
explaining
things
in
a
much
better
way
like
when
you
bring
in
terms
like
a
piece
of
tunnel.
A
I
think
it
is
useful,
but
it's
we
should
be
clear
that
we
are
not
changing
anything
because,
basically
for
external
person
for
an
implementer,
this
is
easy,
but
for
an
external
person
I
feel
review
would
become
harder
if
he
reads
rfc8231
and
then
suddenly
he
comes
here
and
say:
oh,
what
is
this
term?
How
do
I
relate
this
term,
the
rest
of
the
text
in
rfc8231,
so
we
have
to
be
just
a
little
bit
more
careful
with
this.
B
Sure
yeah
I
mean
what
I
saw
in
other
drafts
is
like
they.
They
say
in
the
beginning
of
the
document.
They
say
like
sections:
xyz
are
informational
and
sections,
you
know
whatever
else
abc
are
normative,
and
that
way
it's
all
kind
of
in
one
document,
but
I'm
open
to
anything
like
if
you
know
whatever
the
word
group
consensus
is
we
can.
We
can
work
with
that.
A
I
see
julian
once
you
have
a
button.
Go
ahead
julian.
G
Yeah,
I
just
wanted
to
say
that
it
seems
that
no
one
is
interested
in
option
three,
but
we
we
should
probably
take
to
the
list
the
discussion
between
option
one
and
option
two.
I
also
have
personal
preference
for
option
one
clear
separate
for
option.
Two,
sorry,
sorry,
clear
separation
with
two
different
documents
is
probably
a
clear
way
to
proceed,
but
I
think
that
the
working
group
need
to
discuss
this
more
on
the
list
and
we'll
follow
the
consensus
between
one
and
two
so
sure.
G
I
think
we
should
move
this
discussion
to
the
to
the
list,
but
clearly
there
are
interesting
material
there.
The
working
group
should
work
on
that.
So
this
discussion
is
rather
an
editorial
split
of
the
work,
rather
than
delaying
anything
on
the
procedure
and
the
adoption.
A
G
H
H
Okay,
I
can,
I
can
see
this
live.
Yeah,
hello,
everybody.
This
is
a
an
update
about
the
psep
extension
to
enable
ifit.
So
the
the
draft
has.
I
H
H
Okay,
yeah
just
few
words
about
the
background
and
motivation,
so
to
remind
the
the
scope
of
this
graph.
So
if
it
is
stands
for
institute
for
information,
telemetry
and
just
a
name
to
reverse
together
two
in
c2im
that
is
defined
in
rfc,
91
and
p7,
and
alternate
marking
that
is
currently
defined
in
these
two
experimental
rfc.
But
there
is
also
work
to
elevate
these
two
rfc,
a
321
lease
and
889
these
two
proposal
standards,
so
the
psap
extension
they
find.
H
H
So
we
firstly
define
the
a-fit
capability
tlv
as
an
optional
tlb
in
the
open
object
for
the
capability
advertised.
So
we
define
in
the
flags
five
flags
for
now.
So
four
for
ion
and
one
for
alternate
marking
and
in
addition
to
the
capability
advertisement
tld,
we
define
the
ifita
butyl
vin.
That
provides
the
let's
say
the
configurable
knobs
of
the
feature.
H
So
and
this
can
be
included
as
a
tlb
in
the
in
the
spa
object.
There
are
also,
in
this
case
five
different
subjects
defined.
H
H
H
Just
few
words
to
summarize
the
working
group
adoption
discussion,
so
we
still
need
to
address
old
comments,
since
the
suggestion
from
the
chair
was
to
publish
the
zero
zero
version,
as
is
the
last
version
of
our
draft,
and
then
we
plan
to
publish
a
new
version
in
coming
weeks
to
address
all
the
comments
that
we
receive
during
the
adoption
call
in
this
slide.
I
just
want
to
summarize
the
main
comment,
the
main
comments
and
main
suggestions
that
we
will
address
so,
first
of
all,
a
clarification
on
the
head
and
support
of
the
heat
capability.
H
It
was
also
suggest
to
mention
the
example
for
ipv6
since
for
fpv6
bottle.
Iom
and
alternate
marking
can
be
implemented
through
an
extension
header,
so
by
leveraging
the
pset
extension
correcting
materialp,
for
example,
then
it
was
asked
to
include
more
details
about
the
relationship
between
the
drafting
idr
on
sr
policy
effect.
So
it
is
important
to
realize
that
both
both
pcep
and
bgp
can
be
used
to,
for
example,
to
instantiate
the
sub
policy.
So
it
is
reasonable
to
have
the
same
ifit
mechanisms
for
pizza
and
bgps
a1.
H
I
Charges
up
here
this
is
adrian
farrell.
Thank
you
for
staying
up
so
late.
I
I
don't
know
if
you
I'm
sure
you
are
aware
that
there
was
a
draft
in
the
ops
area
working
group,
a
framework
for
ifit
that
kind
of
ran
into
a
roadblock
and
was
sent
to
at
least
be
discussed
in
ippm,
but
nothing
seems
that
happened
with
it
and
and
your
draft
here
isn't
making
reference
to
that
framework
at
all.
H
And
since
we
didn't
mention
the
framework
in
this
graph,
we
cannot
omit
the
reference.
But
if
there
is
consensus
I
can
also
add
the
reference,
because
we
also
receive
a
comment
that
suggests
that
you
add
the
reference
to
the
framework,
even
if
this
is
only
a
building
block
of
the
world
framework.
So
maybe
the
framework
need
to
reference
this
document
so
because
this
is
only
a
building
block
of
the
word
trainer.
So
we
can
add
the
reference,
but
it's
not
so
so.
In
my
opinion,
it
can
be
done,
but
it's
not
crucial
but
can
be.
A
Yeah,
how
do
you
survey?
I
think
this
the
term
I
fit
either
by
reference
or
by
description
in
the
document
needs
to
be
clarified,
because
otherwise,
even
when
we
call
our
tlbs
ifit
tles,
it
should
be
better
if
it's
very
clear
what
ifit
really
means
yeah.
So
I
think
by
some
mechanism
we
need
to
solve
this.
There
was
one
more
comment
in
the
in
when
I
was
browsing
through.
The
adoption
call
was
about
mpls.
H
Yeah,
you
are
right,
you
are
right
and
I
will
clarify
that
for
now,
because
we
didn't
mention
srm
pls
as
an
example.
So
maybe
it's
not.
There
is
only
a
section
so
yeah
we
can
omit
srm
pls
for
now
and
the
reference
to
the
in
particular.
I
think
that
greg
was
referring
to
the
draft
on
mpls
that
has
not
been
adopted
yet
so
maybe
we
can
just
omit
that
reference
and
yeah.
F
A
Yeah,
my
thing
is
like
just
track
it
because
right
now
we
have
just
adopted
it.
So,
even
if
the
work
is
ongoing
in
mpls
working
group,
it's
fine,
let's
just
track
it.
I
think,
like
you
know,
this
scope
of
having
mpls
in
scope
is
important.
We
should
keep
it
either.
We
can
decide
later
whether,
like
you
know,
if
that
that
work
is
taking
too
long,
whether
we
need
to
divide
this
into
multiple
documents
that
we
can
handle
later,
but
within
the
scope
of
this
document,
just
keep
track
of
the
mpls
stuff
as
well.
H
A
Thank
you
and
just
a
small
reminder
like
since
you
have
documents
in
idr
as
well
as
this.
Just
from
the
start,
take
care
of
coordination,
take
care
of
like
no.
The
documents
remain
in
sync.
Thank
you.
Yeah.
A
So
next
we
have
two
presentations
on
technet.
These
are
very
early
solution
document.
The
work
in
that
net
is
still
ongoing.
This
is
mainly
for
information
purpose
for
pc
working.
So,
let's
start-
and
let
me
give
you.
L
L
And
so,
let's
first
discuss
the
requirement
for
the
deathlet
and
the
psap
in
the
flat.
It
is
required
to
consider
the
abandoned
latency
or
for
past
selection
to
achieve
the
deadline
cues
such
as
minimum
and
their
maximum
end-to-end
latency
and
the
bandit
jitter,
as
for
as
per
itf
data
controller
plane
framework
and
the
path
should
be
calculated
and
established
in
control
play
to
guarantee
the
deterministic
transmission.
So
the
end-to-end
bandit
latency
constraints
should
be
taken
into
consideration
and
the
idf
that's
not
bound
in
the
latency.
L
The
end-to-end
delaying
bombs
can
be
presented
as
their
sum
of
low
queueing
delay
bound
and
the
queuing
delay
bound
along
the
path.
So
the
q
two
mechanisms
and
the
parameters
should
be
determined
during
the
past
compute
computation.
So
this
document
describes
the
extensions
for
gsaf
to
carry
bonded
latency
constraints
and
distribute
the
deterministic
paths
for
end-to-end
popul,
computation
in
deadlock,
service
and
and
for
the
psap
extension
first.
We
proposed
two
metrics
carried
in
metric
object.
L
First,
one
is
the
the
end-to-end
banded
and
then
latency
metric
their
second
one
is
the
end
to
end
bandit
jitter.
There
are
two
metrics
will
be
carried
to
request.
A
deterministic
path
to
meet
the
end-to-end
banded
latency.
We
also
request
a
d
bit
in
asp,
extended
flag,
tre.
L
So
another
preset
extensions
is
we
propose
the
to
extend
their
q
information
to
distribute
the
past
computation
how
to
carry
their
queuing.
Information
is
not
determined
so
far.
We
propose
to
extend
the
queue
information
structure
to
be
carried
in
ero
siero
or
sre
6ero,
but
new
sub
sub
objects
also
may
make
sense.
We
will
consider
that
another
version.
L
L
Similarly,
in
nasa
version
and
the
last
version,
we
will
list
out
the
requirements
for
psap
and
get
confirmed
confirmation
from
deathlet
and
we
will
align
with
the
terminologies
of
a
requirements
draft
so
comments
and
the
suggestions
are
very
welcome.
Thank
you.
A
Thank
you,
janus.
M
Hi
everyone,
janusz
with
ericsson,
as
dhruv
mentioned
in
the
beginning.
We
are
in
a
very
early
stage
of
like
extending
the
death
network
to
address
newer
requirements
and-
and
these
are
individual
contributions,
what
we
see
here
for
my
personal
perspective,
very
much
ahead
of
where
we
are
in
in
that
net.
We
are
trying
to
come
to
consensus
with
the
requirements,
and
then
we
have
a
lot
of
solution
proposals
on
the
table.
We
need
to
build
up
consensus
on
which
way
to
go
and,
after
figuring
out
the
solution.
M
From
my
perspective,
it
comes
the
encoding
of
what
fields
are
needed
and
so
on
to
to
to
meet
the
solution.
M
As
for
the
information
between
pc
and
the
devices,
the
flow
information
rfc
could
be
have
full
as
well,
because
that
already
defines
the
end-to-end
delay
budget
and.
M
E
L
Yes,
the
itp
advertisement,
folder
load
delay,
will
be
advertisement
before
the
past
computation.
E
C
The
unmute
to
add
to
what
janice
said.
I
just
want
to
point
out
that
in
the
debt
networking
group
we
have
a
controller
plane
framework
document,
that's
still
open
and
accepting
contributions.
It's
a
working
group
document,
but
it's
not
done
yet
and
if
this
work
helps
inform
that
or
anyone
inside
this
working
group
has
material
they'd
like
to
either
add
or
see
covered,
for
example,
the
last
question
the
response
answer,
the
last
question
it'd
be
great:
to
bring
that
into
that.
That
document
just
send
to
the
list
any
contribution
you
have.
L
A
Yeah,
thank
you,
my
suggestion,
which
I
mentioned
in
the
mailing
list
as
well.
I
think
to
all
the
solution.
Documents
like
have
clear
reference
to
that
network,
preferably
if
there
are
requirements
which
are
clearly
listed
for
the
protocols.
It
will
be
easier
for
us
to
match
those
requirements
into
the
extensions
that
we
are
developing
in
psep,
and
I
see
that
you
are
have
documents
in
spring
and
idr
as
well,
so
that
will
help
you
also
to
make
sure
that
things
are
aligned
so
from
the
start
follow
that
process.
A
That
would
be
quite
helpful
and
also
the
terminology
be
very
clear,
with
the
terminology
refer
terms
which
are
defined
in
that
net
documents,
so
that
there
are
no
confusion,
especially
for
folks
like
who
are
new
to
debt
debt
and
who,
who
want
to
make
sure
that,
like
you
know,
we
can
still
review
the
debt
network
for
psap
easily,
so
do
help
us
to
do
this
nicely.
Thank
you.
A
J
J
Vietnamese
deterministic
network
architecture
is
described
in
rfc
865
file.
The
data
enterprises
are
capability
to
carry
specified.
Data
follows
with
the
extremely
low
data
loss
risk
and
the
bounded
under
to
under
languages.
With
a
network
domain
rfc
file
440
describes
the
puzzle,
communication
element,
pressure
for
communications
between
path,
combination,
client,
analysis
of
path,
compilation,
element
or
two
option
to
pass.
The
communication
elements
pcp
defines
the
interaction
under
the
data
format
of
full
path,
computation
requests
under
password
communication
replies
between
pcc
and
the
pce
traffic
vestige.
J
That's
not
enhanced
data.
So
that's
not
a
data
plan
by
introducing
bonded
lantern
information,
which
facilitates
detonator
transmit,
translate
notes
to
guarantee
the
boundaries
of
language
transmission
in
data
plot.
Based
on
that
draft
supreme
sr.
Enhancer
data
defines
how
to
reorder
segmented,
routine
and
segment
routine
or
activate
6
to
employment,
boundaries
and
latency.
J
J
J
J
J
We
defined
the
abundant
language
capability
tre
to
advertise
the
support
of
bounded
language
features
in
open
object.
It
contains
the
top
flag
and
format
flag
to
inter
indicate
which
kinds
of
vr
type
and
format
the
speakers
suppose.
J
J
F
J
Each
under
the
officer
knows,
in
our
request,
requests
the
symbol
bri
to
guarantee
boundary.
Let's
say
the
of
vr
tra
is
defined.
A
shared
bra
br
can
be
used
for
all
of
the
nodes
when
the
conducted
path
is
delivered
by
sr
policy.
The
azure
policy
also
needed
to
carry
the
saturated,
bonded,
lantern
information.
J
So
all
all
of
the
notes
in
the
is
this
places,
the
path
indicated
by
the
segment
list-
requests
a
different
api
to
guarantee
bonding
lines.
A
a
brl
is
a
tre
is
needed
to
be
carried
by
sr
policy
and
then,
when
all
of
them
knows
knowledge
in
the
explicit
past
indicated
by
the
segment
list,
requests
of
the
same
bi
to
guarantee
boundary
length,
say
or
share.
The
pritra
is
needed
to
be
carried
out
with
as
our
policy.
J
A
A
And
one
example
of
like
why
requirements
would
be
very
helpful
would
be
like
when
you
were
presenting
in
the
networking
group.
I
saw
that
they
was
mentioning
that
they
could
be
multiple
blis.
A
That
would
be
needed
for
each
hop,
but
in
the
current
tlv
that
we
have
is
like
we
have
one
bli
for
one
hop.
So
I
don't
see
a
case
for,
like
you,
know,
multiple
bli
types
to
be
included,
so
I
think,
like
start
with
the
requirements,
so
that
requirements
are
clear
and
then
we
can
map
them
clearly
to
what
is
how
to
encode
them
in
pc.
A
L
And
first,
let's
first
do
quick
recant
the
pct
constraint
draft
has
been
proposed
and
presented
during
last
two
years.
It
proposed
a
set
of
constraints
for
presets,
with
the
lateral
information
such
as
faid
color
source
protocol,
id
multi,
topology
id
application,
id
slice
id
and
now
it
it
has
been
replaced
or
merged
into
four
drafts.
So
the
current
printing
presenting
a
draft
has
replaced
the
t
constraints
and
proposed
this.
Nice
related
concentrate
with
the
terminology
changing
from
the
slice
id
tlv
to
nrp
idtle.
L
So
this
draft
is
mainly
about
the
nrpid
as
per
their
itfts
and
as
ipm
pls
rp
identifier
indicates
an
identifier
that
is
globally
unique
with
within
an
rp
domain
and
that
can
be
used
in
the
control
and
management
complaint
to
identify
the
resources
associate
associated
with
nrp.
So
this
document
proposes
a
set
of
extensions
for
precept
to
support
the
identifier
of
network
resource
party
partition
as
the
constraint
of
network
slicing
during
past
computation.
L
So
for
the
psap
extension,
we
propose
the
lrp
trwe.
It
can
be
used
to
identify
the
slice
and
the
network
resource
and
reviewed
as
constraints
network
slicing.
When
pc
is
deployed,
the
pc
may
maintain
network
resources
per
path
under
nrp
state
within
the
resource
pro
identified
by
an
rpid,
so
the
rpi
the
tree
should
be
carried
in
psalm
messages
such
as
the
pc
report
message,
pc,
leisure
message
and
the
pc
update
message.
L
So
last
step,
we
also
thanked
the
suggestions
from
durf
in
the
mailing
list.
The
mrp
capability
would
be
added
in
open
message
in
next
version
and
we
will
make
clarification
for
the
past
computation
with
rpid
constraint
and
as
add
reference
to
itp
extensions
for
nrp
as
per
the
lcr
spring
rp
draft.
So
comments
and
discussions
are
very
welcome.
Thank
you.
J
A
K
K
Okay,
I
I
just
like
to
mention
that
there
is
a
similar
draft
called
the
psap
within
extensions
which
covers
both
capability
part
and
the
rspa
extensions,
and
currently
there
are
several
set
of
the
control
plane.
Graphs
on
the
network
slicing
related
extensions.
This
is
just
one
of
them,
including
the
ijp
and
the
b2p
bjprs
this
all
the
thrust
may
need
to
be
coordinated
in
the
future,
and
since
we
have
some
consensus
in
the
tears
working
on
the
terminology,
what's
in
the
coordination
seems
possible
and
we're
open
to
that.
L
L
Maybe
we
could
discuss
offline
on
main
list
or
separate
celebrate
with
you
collab.
Maybe
we
can
collab
collaborate
with
you
to
progress
this
piece
of
work.
Thank
you.
A
Thank
you,
and
that
would
be
my
comment
as
well.
I
think,
having
a
single
document
for
the
working
group
to
look
at
would
always
be
much
easier
to
process
and
most
of
the
features
are
exactly
the
same
open
and,
like
you
know,
the
id
inside
an
sp
object.
So
I
urge
the
authors
to
work
together.
Thank
you
are.
G
G
Let's
talk
on
the
mailing
list
and
hopefully
see
you
face
to
face
in
london.