►
From YouTube: IETF109-PCE-20201119-0500
Description
PCE meeting session at IETF109
2020/11/19 0500
https://datatracker.ietf.org/meeting/109/proceedings/
A
D
E
E
So
I
guess
everyone
should
be
aware
of
the
usual
not
well.
Basically,
very
brief,
summary
everything
that
you
may
say
share
or
comment
during
the
ahf
meetings
are
subject
to
the
noteworth
on
the
associated
ipr
policy.
So
please,
if
you
weren't
familiar
with
those
look
at
the
pointers
that
are
included
there
and
make
sure
that
you
understand
and
follow
them.
E
Using
the
kodi
md
tool,
if
you
want
to
give
a
hand,
I
think
you
should
be
able
to
access
if
you
have
a
data
account
so
feel
free
to
to
help
harry.
If
you
feel
like
it
we're
still
there
already-
and
this
is
the
this-
isn't
the
first
online
itf
meeting.
So
you
should
be
familiar
with
the
mythical
tool,
but
a
short
reminder
that
you
have
a
tool
to
manage
the
queue.
E
E
So
this
is
the
kind
of
substitute
to
the
face-to-face
meeting
to
discuss
topics
and
create
some
communication
between
working
group
members,
but
keep
in
mind
that
we
also
have
the
mailing
list
that
is
open,
24
7
so
feel
free
to
use
it
even
after
the
meeting.
If
there
are
some
unresolved
questions
or
painting
issues,
the
meeting
is
still
there.
E
Usual
also
a
reminder
about
the
working
good
processes,
especially
during
calls
for
draft
adoption
or
working
group
last
call
to
judge
about
the
consensus
on
the
document
and
decision.
We
need
to
see
as
much
as
visible
views
and
opinions
on
the
mailing
list
so
make
sure
that
when
you
have
something
to
say
you
write
it
down
using
an
email
and
try
to
get
involved
in
as
much
as
adoptions
or
working
group
last
calls
as
much
as
possible.
E
E
F
E
Added
in
the
wrong
place
or
forgotten
or
as
progress
that
isn't
reflected
in
the
wiki
it's
available
on
a
sharing
tool
as
well.
So
it's
supposed
to
reflect
some
of
the
the
documents
that
we
have
in
our
various
queues
so
make
sure
it
reflects
the
current
state
in
case
your
document
isn't
in
that
position
you
may
help
in
updating
that
wiki.
E
E
E
Make
sure
that
you
have
gathered
all
the
preconditions
before
you
request
another
point
allocation
on
as
soon
as
it
everything
is.
Okay,
we'll
start
the
associated
process.
If
the
working
group
agrees
with
that,
so
keep
in
mind
that
this
is
something
that
may
be
worst
effort
on
some
cases,
but
not
always
because
it
also
has
some
a
couple
of
drawbacks
so
make
sure
that
in
your
case,
it
makes
the
this
sense
that
you
expect
and.
E
E
A
There
so
we
have
two
rfcs
since
iit
of
108
we
have
the
diversity
association
and
the
lsp
scheduling
rfc
is
published.
We
have
one
rfc,
which
is
waiting
in
the
rfc
editor
queue.
Currently
it's
misrep
to
the
idr
flowspec
documents.
So
once
we
have
that
this
will
get
published
as
well.
A
We
have
the
association
policy
that
we
did.
The
working
group
last
call
and
we
have
sent
this
to
our
ad
and
we
are
waiting
for
routing
direct
rate
and
ad
review
to
further
progress.
These
documents,
which
are
beyond
the
working
group
during
the
two
meetings
we
processed
three
irata's,
both
on
stateful,
pce
and
pc,
initiated
documents.
A
These
were
pretty
straightforward.
We
we
posted
the
resolution
on
the
mailing
list.
There
wasn't
any
complaints.
So
after
discussing
between
chairs
and
ad,
we
have
gone
ahead
and
verified.
All
of
these.
There
is
a
early
ima
location
that
we
made
some
time
back,
which
is
for
association
policy.
A
Good
thing
is
that's
already
out
of
the
working
group,
so
everything
is
good.
So
if
you
have
any
other
document-
and
you
need
a
code
pointer
location
as
julian
was
saying-
we
have
a
process.
Please
follow
that.
A
If
you
remember
from
the
last
time
we
we
had
an
update
of
some
of
our
documents
as
they
are
changing
in
all
these
working
groups,
so
we
updated
the
status
of
those
documents,
so
that
is
an
ongoing
layers
on
that
will
continue.
If
you
have
any
comments
on
it,
please
use
our
mailing
list
and
provide
any
suggestions
with
handling
this
liaison.
Scott
mansfield
is
coordinating
across
various
working
groups,
so
you
can
also
reach
him
as
well.
A
Okay,
so
the
next
part
is,
we
will
go
over
quickly
the
status
of
various
working
group,
ids
and
next
step.
If
you
have
any
comments
on
these,
you
can
join
the
queue
and
provide
any
update.
I've
captured
what's
there
in
our
wiki
and
what's
the
status
that
we
know.
So,
if
you
have
some
updated
information,
please
come
to
the
mic
and
tell
us
so
the
documents
which
are
post
working
group
last
call.
We
have
the
pcc
document.
The
shepard
review
was
done
by
julian
authors,
have
made
the
update.
A
A
Regarding
the
bi-directional
association,
the
shepherd
review
was
posted.
We
are
still
waiting
for
an
update
and
response
from
the
authors.
So
if
any
of
the
authors
have
anything
to
update,
please
go
ahead,
otherwise
use
the
mailing
list.
We
are
waiting
a
response
from
you,
okay,
seeing
yes
rakesh
go
ahead.
C
Yeah
this
is
in
my
next
to-do
list,
so
hopefully,
next
week
I
can
get
back.
C
A
So
the
document
which
is
nearing
working
group
last
call
this
is
the
pce
yang
document.
There
are
two
open
issues
that
are
listed
in
the
draft.
One
open
issue
is
related
to:
how
do
we
identify
in
the
t
young
model
which
of
these
lsps
are
pc
initiated?
So
that's
one
thing
that
we
haven't
resolved.
That's
been
listed
in
our
as
an
issue
for
a
long
time,
so
it
will
be
good
to
get
that
resolved
as
well.
Another
issue
is
the
use
of
lspid
as
a
key,
which
is
a
reference
to
the
pe
young
model.
A
So,
as
you
know,
in
psap
we
have
other
path,
setup
types
as
well,
so
when
it
is
non-rsvp,
how
do
we
handle
this
lspid
as
a
key
is
a
issue
which
was
recently
identified,
so
this
is
something
that
needs
to
be
figured
out.
So
what
we
will
do
is
we
will
start
a
email
thread
on
the
mailing
list
and,
if
folks
have
any
ideas
on
how
to
handle
this,
that
would
be
pretty
useful
information.
So
please
provide
that
information
on
the
mailing
list.
A
We
also
noticed
one
thing
that
we
have
an
sr
policy
yang
model
in
spring.
We
currently
don't
reference,
it
that's
a
pretty
new
model
and
it
will
take
some
time
to
progress
as
well
so
up.
I
personally
feel
that
it
might
not
be
a
good
idea
to
add
a
reference
to
sr
policy
yang
in
this
document.
We
can
do
it
as
an
augmentation.
In
another
document
we
have,
for
instance,
srv6
yang
document.
We
can
make
it
generic
and
include
both
sr
policy
as
well
as
handling
of
srv6
in
that
id.
A
So
again,
this
is
something
that
would
be
good
to
discuss
on
the
list.
We
will
start
a
thread
on
that.
Apart
from
that,
the
t
yang
dependencies
are
progressing.
We
have
a
dependency
on
tls,
so
from
netcon
document.
Those
documents
are
also
in
the
pipeline,
so
they
will
be
progressed
at
the
same
time
as
this
document
is
getting
ready.
We
have
done
a
very
early
yank
doctor
review.
A
A
If
you
remember,
we
did
a
merging
between
two
documents:
stateful
gmpls
and
pc,
initiated
stateful
gmpls.
We
combine
that
into
one
document,
so
most
of
that
combined
work
is
done.
There
is
one
thing
pending
which
is
the
implementation
status
and
since
the
document
is
expired
anyway,
we
need
a
new
revision
and
moving
this
work
along
any
of
the
authors.
If
they
want
to
say
something,
please,
you
can
otherwise
I'll
go
ahead.
A
Okay,
the
next
one
that
we
have
is
the
native
ip.
This
one
had
multiple
versions
and
rework
between
the
two
meetings.
Request
would
be
that
we
should
keep
the
working
group
in
loop
and
not
just
mention
that
the
update
has
been
made,
but
also
explain
why
the
changes
have
been
made.
So
that's
something
we
need
to
take
care
in
this
document.
A
Also,
to
note
that
in
these
working
group
we
have
a
related
tease.
Id
deborah
has
just
asked
the
keys
working
group
to
look
into
whether
the
document
status
needs
to
change
from
experimental
to
informational.
So
if
you
have
any
thoughts
on
that,
please
use
the
tease
mailing
list
to
discuss
that.
We
should
also
evaluate
that
what
we
should
do
about
the
pc
document
status
right
now.
A
It's
a
proposed
standard,
so
we
should
also
have
the
parallely
evaluate,
and
maybe
even
the
t's
working
group
discussion
should
be
in
input
for
us
to
evaluate
what
should
be
the
status
of
the
pc
working
group
extension
as
well
as
we
need
to
coordinate
with
the
idr
working
group
related
to
any
of
the
bgc
stuff.
So
for
facilitating
that
coordination,
it
will
be
good
to
have
maybe
a
bgp
consideration
section
that
describes
things
that
the
idr
working
group
should
look
at.
So
they
don't
have
to,
like.
You
know,
go
through
the
whole
document.
A
G
Yeah
yeah,
thank
you.
So
we
will
try
to
you
know,
make
practice
in
your
next
meeting
for
the
change
of
the
craft,
because
there
are
some
things
we
are
still
in
discussion.
G
You
know
and
for
the
pgp
consideration
after
the
stable
of
the
software
will
seek
the
you
know,
opinion
from
an
ideal
working
group
and.
G
A
The
next
document
is
the
enhanced
error
document.
This
one
had
an
update.
The
update
moved
the
scenarios
to
the
appendix
so,
which
was
a
good
suggestion
and
that's
been
accepted
by
the
authors.
They
have
also
updated
the
guidelines
for
other
documents
how
to
use
enhanced
errors,
so
I
think
the
document
is
progressing.
A
A
A
The
next
two
are
actually
on
our
agenda:
the
srv6
and
bindingset.
So
we
can
skip
them.
We
have
next
two
documents,
which
is
the
vn
association
which
had
a
keep
alive
update
and
we
had
the
sr
path
segment
that
also
had
a
keeper
like
update.
So
if
the
authors
thinks
that
their
documents
are
stable,
they
have
nothing
pending.
They
can
let
the
working
group
know
about
that
as
well.
A
Next,
we
have
sr
bi-directional
path.
This
one
had
an
update.
They
added
a
scope,
clarification.
They
also
updated
based
on
the
changes
in
the
rsvpte
bi-directional
documents,
which
is
always
good.
They
updated
the
figures
notations
for
clarity.
So
thanks
for
that,
the
last
document
here
that
we
have
is
the
is
the
segment
routing
sr
policy,
candidate
path
association.
A
So
the
update
was
focused
on
changing
in
the
reserve
value
of
association
id.
There
was
a
mailing
list
discussion
last
week
regarding
the
new
procedure
to
mandate
pcc's
allocation
of
association
parameters.
So
that's
ongoing.
If
you
have
thoughts
on
that,
I
think
please
use
the
mailing
list
and
provide
your
thinking
and
we
are
looking
forward
from
authors
and
update
on
that.
A
Okay.
Finally,
we
have
a
recent
working
group
document.
This
was
recently
adopted.
There
was
a
comment
to
can
this
procedure
be
made
more
generic,
whether
we
do
this
in
this
id
or
via
a
future
mechanism
that
needs
to
be
established.
So
if
you
have
any
thoughts,
please
discuss
on
the
list,
so
I
would
expect
authors
to
provide
an
update
on
that
as
well,
and
I
see
andrew
he
said
andrew
go
ahead.
H
In
your
comment,
I
hope
it
didn't
actually
upload
as
that,
but
the
document
was
labeled
as
local
protection
enforcement.
The
original
it
originally
was
listed
as
path
protection,
and
then
we
renamed
it
to
local
protection.
So
I'm
not
sure
if
it's
just
the
slide
is
not
correct
or
if
it
actually
uploaded
incorrectly.
A
Okay,
so
final
slide
from
the
working
group
status
is:
what's
our
adoption
poll
queue,
so
these
two
documents
have
been
pending
in
our
adoption
call,
so
we
will
be
taking
up
taking
up
these
documents,
pcc
sr
document
and
stateful
interdomain
document.
Many
of
you
have
made
your
request.
Those
requests
are
tracked
in
the
wiki,
in
the
link
that
you
see.
So
if
something
is
missed,
if
something
is
incorrect,
please
reach
us
and
we
will
update
that
this
queue
is
growing
long,
so
we
need
to
start
moving
it
so
to
help
us.
A
I
would
also
request
that,
like
when
we
do
the
adoption
poll,
please
do
respond
that
helps
us
even
moving
your
documents
early
on
right.
So
it's
like
you
know.
When
we
do
that
option
call.
We
are
looking
for
feedback.
Please
provide
feedback
for
all
the
working
group
documents
in
last
call
as
well
as
adoption
and
that's
it,
and
if
there
is
no
other
comment,
we
will
start
with
our
agenda.
I
I'm
michael
kolduchev
I'll
be
presenting
this
draft
carrying
binding
state
label
segment,
id
and
pc
based
networks.
On
behalf
of
the
authors
next
slide,
please.
I
In
this
tlv
there's
something
called
there's
a
numeric
field
called
a
binding
type
and
this
binding
type.
Basically,
it
controls
the
value
of
the
binding
value
so
for
binding
type,
0
and
1.
The
binding
value
is
an
mpls
label
for
binding
type
2.
The
binding
value
is
a
srv6
sid
for
and
so
in
this
new
iteration
of
the
draft.
We
define
the
binding
type
3,
which
causes
the
binding
value
to
be
an
srv6
sid,
plus
some
extra
information
for
carrying
endpoint,
behavior
and
sid
structure,
as
we'll
show
in
the
next
slide.
I
I
Is
like
kind
of
invalidation
drop
behavior,
so
it
basically
means
that
this
pause
this
tunnel
or
policy
must
kind
of
so
sorry,
what
I
mean
is
like
bgp
traffic
that
is
normally
steered
into
this
policy.
I
It's
it's
always.
You
know
steered
into
that
policy,
even
if
the
policy
doesn't
have
a
path.
So
in
that
case
the
traffic
would
just
be
dropped
next
slide.
Please,
and
that's
that's
it
for
the
updates,
so
we
can
discuss
some
questions
or
next
steps.
Thanks.
A
Any
comments
from
anyone
yeah
go
ahead.
Tarek.
B
Mike
this
is
tariq
from
juniper
networks.
Thanks
for
the
updates,
I
have
a
question
on
the
binding
sid.
A
new
type.
Currently
you
can
download
one
is
that
correct
is
my
instruction
one
binding
set
for
one
tunnel
or
one.
I
Yes,
so
yeah
thanks
for
bringing
this
up,
so
we
actually
changed
that
as
well.
That
was.
F
I
Kind
of
update
was
that
we
allow
for
multiple
binding
sets
now
because,
as
well
or
just
srv6,
we
allow
it
for
mpls
as
well.
I
J
I
Sure
yeah
so
basically
zero
and
one
is
to
differentiate
the
other
fields
in
in
the
like.
In.
I
32-Bit
label
such
as
the
exp
bits
and
yeah.
I
think
it's
just
exp
bits.
So
basically,
I
think,
like
bt1
specif
means
that
you
can
control
the
exp
bits
in
the
in
the
mpls
label
and
bt
0
means
that
you
only
want
to
specify
the
actual
20
bit
mpls
label
and
you
don't
care
about
the
exp
bits.
J
J
Maybe
if
you
can
get
more
details
in
the
is
that
is
this
details
in
your
document.
I
Yeah
yeah
it
is,
it
is
there
for
sure,
yeah.
Okay,
it's
basically
the
difference
between
you
know:
putting
a
20-bit
label
versus
putting
a
32-bit
label.
A
Right
yeah,
I'm
not
seeing
anybody
else
in
the
queue,
so
thank
you
mike.
I
think
the
document
is
making
good
progress.
We
wanted
to
check
with
you
since
all
the
comments.
Oh,
I
spoke
too
soon.
Boris
is
there
boris
go
ahead.
K
Thank
you
mike
one
question
in
recent
sr
policy
draft
where
we
added
so-called
composite
path.
Do
we
need
to
reflect
it
here
somehow
or
not.
I
So
this
draft
will
not
will
not
be
affected
by
the
composite
policy,
but
there
is
another
draft
called
psap
multipath
for
sr
policy,
which
is
going
to.
D
A
I
I
don't
think
so,
because
it's
basically
you
just
need
to
carry
the
you
know
the
color,
instead
of
the
ero,
to
to
support
this
composite
policy.
So
the
candidate
path
will
have
instead
of
having
like
a
segment
list
of
labels,
it
will
just
have
a
color
and
that's
all
there
is
that's
required
to
support.
You
know
signaling
this.
Can
this
composite
policy
go
ahead.
L
There
might
be
some
changes
in
this
policy
as
well,
so
if
there
are
multiple
ways
of
addressing
it,
you
could
have
two
constituent
sr
policies
having
an
association
saying
that
they
both
belong
to
the
same
parent
policy.
So
we
we
will
discuss
that
on
the
list
and
address
it,
but
yeah
you're
right.
There
could
be
some
changes
in.
A
I
D
A
M
Go
ahead,
oh
yeah.
I
agree
with
mike
that
we
can
wait
for
one
more
meeting
to
see
that
do
you
have
any
further
extensions
on
finding
seed
right.
M
M
So
we
make
the
presentation
last
time
in
itf
105.
M
So
from
that
on
to
now
we
have
updated
documents
from
revision
0
to
revision
like
7.,
so
this
slide
talks
about
the
update
of
from
0
to
6..
So
basically,
we
have
defined
the
foreign
extension
for
some
six
in
psep,
so
we
make
we
add,
a
new
p
part
setup
type
in
the
passive
type
capability
tv,
which
is
the
srv6
pause.
M
So
also,
we
have
added
a
new
srv6
pcp,
a
pc
pc
capability,
sub
trv,
to
specify
more
like
detailed
information
like
msd
information
for
srv6
pass.
So
we
also
introduced
the
new
pst
for
srv6
in
rp
and
srp
object
to
specify
the
pass
computation
requirement
and
reply
right.
So
the
most
important
part
is
that
we
introduce
a
new
srv6er
sub-object
and
we
we
rename
the
field
of
c
type
to
an
ai
type
entity.
For
short,
so
also
we
update
the
srv6
our
subject.
M
Next,
so
at
last
update,
which
is
from
zero,
six
two
zero
seven,
we
will
make
a
a
major
update
of
the
draft.
We
add
a
new
sub
theory,
called
c
structure,
t
of
each
aligned
with
extensions
in
isis
and
bgpls
and
phps
policy.draft
right.
So,
as
you
can,
you
can
see
here.
We
we
make
we
paste
the
updated
format,
encoding
format
of
the
srv6eo
subject,
sub
object,
which
sits
list
here
and,
as
you
can
see,
we
also
introduced
two
more
flags
into
this
sub-object.
M
The
first
one
is
t
t
means
that,
when
p
sets,
we
will
have
an
optional
a
by
c
structure
when
the
srv6
is
included
so
right.
We
have
to
make
sure
that
airspeed
is
unset
right
now
when
the
t
bit
is
set.
M
So
also
we
introduce
the
v
flag
into
this
sub
object
for
see
the
verification
so
and
the
use
usage
is
the
same
identica
identical
to
the
section
five
point,
one
of
srv6
of
the
segment
routing
policy.
Also
one
comment
here:
do
we
really
need
to
add
a
flag
here?
I
see
another
document
to
specify
to
carrying
the
algorithm
information
in
two
more
new
like
nai.
I
think
that
will
be
presented
in
the
following
topics,
so
we
can
discuss
this
so
next,
please.
M
So
this
slides
describes
the
details
of
the
cities,
structures
sub-theory.
As
you
can
see
here,
we
used
eight
bytes
tlv
to
describe
the
format
of
the
c
structure
instead
of
four.
M
The
reason
is
that
we
think
the
four
bytes
see
structure
of
it
is
too
limited,
because
we
can
only
describe
only
like
four
parts
of
the
sf60
for
now,
but
what
if
we
have
more
like
parts
or
more
like
attributes
of
the
srv6
structure-
and
we
have
no
like
further
beats
or
reserved
fields
to
to
like
describe
that,
so
we
introduced,
like
32
bits
reserved
fields
for
for
the
future
usage
right.
M
So
that
is
the
main
thing.
So
next,
okay,
the
plan
of
this
draft
is
that
we
are
going
to
update
the
document
a
few
times
and
then,
when
the
document
is
ready,
we
will
record
we
will
request
for
working
group
law
school.
But
I
don't
think
right
now
is
the
right
timing.
So
comments
are
always
welcome.
Yeah,
that's
all.
A
So
I
think,
as
cheng
was
mentioning,
we
have
the
next
talk
which
will
have
like
which
will
describe
about
algorithm.
So
we
can
take
up
this
question
about
whether
we
need
an
extra
flag
or
not.
A
One
comment
would
be
that
between
the
two
documents,
the
binding
set
and
the
and
the
p
srv6,
where
the
sit
structure
is
added,
if
you
can
align
the
sit
structure
between
the
two
documents,
that
would
be
good
like
it
should
be
same
format
in
at
least
in
the
psep,
so
that
I
would
request
the
both
authors
to
discuss
and
put
a
common
set
structure
format
for
both
binding
sid
and
srv6
ero.
A
Another
question
this
is
not
directly
related
to
to
srv6,
but
this
v
flag
is
something
that
we
don't
have
for
sr
mpls
also-
and
this
is
a
question
that
we
should
evaluate
that,
as
you
know,
sr
amperes.
We
already
have
a
published
rfc,
but
we
don't
have
this
v
flag
and
if
we
are
adding
it
to
srv6ero,
we
maybe
we
find
a
way
also
to
update
the
sr
mpls
and
add
the
v
flag
somewhere.
A
A
I
I
I
I
So
the
motivation
is
that
we
kind
of
have
two
things
we
want
to
do.
First,
we
want
to
signal
a
constraint
to
the
pce
to
say
that
we
want
to
compute
a
path
using
a
particular
sid
algorithm.
The
second
thing
we
want
to
do
is
once
that
path
is
actually
computed.
I
I
I
Yeah
so
basically,
there's
like
this
prefix,
it
algorithm
is
kind
of
a
igp
thing,
so
it's
there's
two
default
or
two
kind
of
basic
algorithms
defined
spf
and
strict
spf
they're
zero
and
one,
and
then
there
is
something
called
flex
algorithm,
which
is
id
128
and
greater
and
flux
algorithm
allows
you
to
have
like
any
kind
of
constraints
in
in
there.
I
So
next
slide,
please
so
the
way
we
signal
the
the
sid
algorithm
used
by
a
given
sid
is
we
define
a
new
nai
type
for
that,
so
nai
is
the
node
or
adjacency
identifier,
and
basically
we
define
this.
These
two
new
nai
types
for
ipv4
and
ipv6
nodesid
with
algorithm,
and
so
basically
this
nai
carries
a
little
bit
of
extra
information
to
encode
the
algorithm.
I
I
I
Yeah
so
just
comments
and
suggestions,
and
we
would
like
to
request
one
group
adoption
for
this.
One.
I
N
Hello,
yes,
go
ahead,
okay,
this
is
jaydon
and
I
have
read
a
document
and
I
think
it
provides
the
segment
times
which
are
defined
in
the
sr
policy.
That's
I
think
this
is
a
useful
extension
and
some
comments.
One
is
about
the,
albeit
I
think
in
this.
This
is
not
clear
to
me
whether
different
previous
with
different
algorithm
can
be
put
in
the
same
like
ero,
for
one
pass.
N
Is
that
allowed,
or
not
different
algorithms
in
the
same
path?
If
you
cannot
meet
yeah.
N
I
Like
you
mean,
can
I
specify
to
use
like
prefix
or
sorry
like
algorithm,
128
and
129,
or
are
you
saying
like
to
specify
okay
use
algorithm
129
if
you
can,
but
if
you
can't
then
fall
back
to
some
other
algorithm.
N
Yeah,
my
point
is
for
one
for
the
previous
series
in
one
pass.
You
maybe
need
to
restrict
them
to
use
the
a
consistent
algorithm
if
they.
N
I
can
cause
a
loop
yeah.
Different
oxygen
used
in
one
pass
may
call
the
loop
yeah
now
this
is
my
first
comment.
Another
one
is
maybe
a
general
comments
about
the
psap
sr,
because
I
see
that
the
intercept
sr
segment
types
are
described
in
a
different
way
from
the
sr
policy
in
bgp.
Right,
I'm
not
so
maybe.
F
N
To
check
whether
there's
still
some
inconsistency
between
the
two
mechanisms
in
the
meeting,
the
segment
types
defined
in
the
as
a
policy
document
in
spring
working
group.
I
F
I
Yeah,
it's
probably
too
late
to
be
honest,
because
a
lot
of.
N
A
Yeah
yeah
yeah,
okay,
just
to
add
to
what
jay
was
saying,
I
think,
since
we
have
found
one
issue
with
the
algorithm
and
we
are
fixing
it,
we
can
use
this
opportunity
to
find
anything
else
that
is
misaligned
and
in
one
document
itself,
try
to
update.
For
example,
even
the
v
flat
thing
that
we
were
discussing
in
the
previous
document.
A
Can
we
use
maybe
this
document
to
also
add
the
v
flag
for
srm
pls,
just
an
example
sure
yeah
there
is
before
I
go
on
with
the
queue
just
since
we
are
on
the
same
page.
I
think
this
lspa
part
is
not
very
clear,
because
we
are
not
sure
whether
this
algorithm
is
to
be
used
as
end-to-end
path
algorithm
or
is
it
just
while,
while
you
are
picking
a
particular
sits,
you
prefer
algorithms,
you
prefer
prefix
it
which
uses
this
algorithm.
A
That
part
is
missing
even
from
the
presentation
and
the
document,
not
very
clear.
As
you
know,
we
have,
an
of
which
is
an
optimization
objective
function
which
is
supposed
to
do
like
you
know,
minimum
delay
path,
which
is
an
end-to-end
objective
function.
Is
this
algorithm
going
to
replace
that,
or
is
it
just
adding
to
that?
So
please
do
take
care
of
that
part
as
well
when
you
are
describing
lsba.
B
I'll
talk
with
juniper,
maybe
you
were
faster
than
me
to
ask
the
question
so
but
I'll
reiterate
it
in
a
different
way.
So,
if
you're
crossing
multiple
domains,
you
might
want
to
stay
in
domain
one.
I
want
algorithm
128
and
the
domain
two.
I
want
algorithm
129
and
in
the
third
domain
you
want
a
different
algorithm.
B
F
B
Can
be
anything
else
in
domain
two
and
domain
three,
so
you
might
wanna
open
up
the
possibility
to
have
multiple
or
an
algorithm
per
domain
yeah,
and
I
don't
know
how
I
I
you
know
we
can.
We
can
talk,
how
the
details
of
it.
You
know
how
to
specify
in
the
domain
the
algorithm,
but
I
don't
see
it
end
to
end
it's
hard
yeah.
O
Yeah,
can
you
hear
me?
Yes,
yeah?
Okay,
I
have
a
question
on
the
number
of
things
you
can
do
from
one
algorithm.
I
read
the
draft.
I
thought
I
understood,
but
when
you
presented,
you
gave
an
example
where
you
can
do
two
different
things
in
the
same
algorithm.
I
Not
100
sure
what
you
mean
by
two
different
things.
What
I
was
saying
is
that
you
want
to
specif.
You
need
to
be
able
to
specify
a
flex,
algo
computation
constraint,
that's
one
thing
and
you
need
to
be
able
to
specify
that
a
given
computed,
ero
hop
is
of
a
particular
flux,
algorithm.
O
So,
let's,
let's
imagine
that
we
figure
out
something
else
you
want
to
put
in
there.
Is
it
possible,
with
the
current
format.
I
I'm
not
sure
exactly
what
you
mean
by
like
something
else.
Maybe
if
you
can
give
just
like
a
very
hypothetical
example.
I
I
I
O
For
example,
could
you
do
things
like
excluding
nodes.
O
One
constraint:
yeah,
that's
what
I
want
to
hear.
So
there
is
no
practical
limit
to
how
many
constraints
you
have.
I
D
J
I
Well,
not
necessarily
like,
for
example,
if
you're,
if
you're
optimized
like
say
you,
you
request
a
path,
just
optimizing
latency
right
and
you
have
a
flex
algo,
a
certain
flex
algo
that
optimizes
latency,
even
though
you
didn't
request
that
flex
algo,
because
it
fits
with
your
constraint.
The
pc
may
return
you
a
path
using
that
flex.
Algo.
J
So
so
is
that
a
node,
for
example,
in
one
domain,
and
then
we
have
a
multiple
prefix
sheet
and
then
for
multiple
for
each
of
them.
Maybe
we
can
use
different
algorithm,
yeah.
J
I
I
don't
think
there's
any
problem
with
using.
You
know
different
algorithms,
either
within
a
domain
or
outside
of
a
domain
like
you
may
have
a
zero
algorithm
sid,
followed
by
128
algorithms
sid.
You
know
followed
by
129
algorithms.
If
it
helps
you
reduce
the
the
label
stack
size
and
you
know
make
use
of
equal
cost
multipath.
I
I
You
know
to
to
take
care
of
that.
It
doesn't
cause
loops.
J
Yes,
maybe
it's
too
loose
or
too
flexible,
and
at
least
that
we
should
have
some
check,
whether
there's
a
so
with
different
prefix
with
different
algorithm,
and
this
will
have
some
kind
of
a
check
whether
these
are
these
different
algorithms.
At
different
points,
there
may
be
some
kind
of
a
consistency
to
some
extent.
We
can
always
just
use
different
algorithm
for
at
least
for
this
privacy,
and
then
next
is
another
other,
maybe
totally
different.
One.
I
A
Use
that
yeah,
I
think
this
is
best
for
the
mailing
list.
Now
so
yeah
we
have,
let's
take
up
with
the
next
present
next
person
in
the
queue
so
parven
go
ahead.
L
Juniper
networks-
I
there
is
definitely
value
in
having
the
ability
to
specify,
say,
different
set
of
constraints
or
different,
optimization
objectives
for
a
given
domain
for
an
inter
domain
path
right,
so
so
the
in
in
rsvp
at
least.
We
have
this
notion
of
hop
attributes
where
you
can
provide
a
set
of
attributes
associated
with
the
given
hop
so.
F
L
L
Bring
in
that
construct
into
psap,
I
think
you'll
be
able
to
address
your
requirement
where
you
say,
while
traversing
for
this
term
computation
in
this
domain
use
this
set
of
constraints
for
the
next
domain.
You
specify
the
next
domain
id
as
your
inclusion
and
then
give
the
hop
attributes
associated
with
that.
P
I
Yeah,
maybe
we
can
somehow
have
like
a
a
way
in
peace
up
to
say
that
you
know
to
give
like
an
identifier
for
a
domain
and.
F
I
L
A
Jeff
go
ahead
quickly,
please
so.
Q
I
would
say
concatenation
of
algus
would
be
okay,
it's
a
logical
end.
For
example,
you
want
to
optimize
towards
slow
latency
and
your
jointness,
logical
or,
however,
is
not
especially
with
a
single
domain
intermixing
not
from
different
algos.
It's
not
a
good
idea,
but
there's
idea
of
continuous
connectivity
within
an
algo
right.
So
I
I
would
be
really
against
using
this
way
it's
more
on
guts
feeling
than
scientific
right
now,
but.
I
Like
I'm
sure
there
there
could
be
counter
examples
to
you
know
to
cases
where
it's
bad,
but
yeah
I
mean
there
could
also
be.
You
know
examples
where
it's
useful,
so
I
don't
know
I'm
not
either
for
or
against
it,
but
the
encoding
is
there
so
like.
If
you're,
you
know,
if
your
pc
server
wants
to
encode
it.
Q
I
Yeah,
that's
more
kind
of
a
vendor
implementation
of
the
algorithm
right.
Like
you
know,
your
each
vendor
has
to
you
know,
make
sure
that
their
computation
algorithm
results
in
a
safe
segment
list
right,
and
you
know
if,
if
your
pc
computes
a
segment
list
that
can
result
in
like
loops
or
something
like
this
or
then
it's
kind
of
you
know
the
the
implementations
problem.
In
my
opinion,.
A
Yeah-
let's,
let's
take
this
now
to
the
list,
I
think
thank.
F
A
Jeff
for
excellent
suggestion:
we
are
taking
up
time
from
the
next
presentation,
so
shangji,
if
you
can
take
your
question
to
the
list
and
there's
a
lot
of
good
discussion
already
on
this
document.
So
thank
you
for
that.
Let's
move
on
to
the
next
presentation.
Thank
you.
F
A
F
Yes,
I
just
doing
a
voice
check.
Can
you
guys
hear
me.
M
F
Perfect,
thank
you.
So
my
name
is
human
bitgoli
from
nokia,
I'm
presenting
the
pce
as
our
point
to
multiplane
policy.
Next
slide,
please.
F
So,
with
regard
to
this
presentation,
I'm
just
going
over
the
high
level
view
of
what
the
point
to
multiplying
policy
is
I'm
not
going
to
go
into
the
nuts
and
bolts
you
can
read
the
draft.
I
just
want
to
make
sure
everybody
understands
what
the
idea
is
and
when
we
are
where
we
are
trying
to
go
with
this
idea.
Now
there
were
multiple
drafts,
including
one
in
a
spring,
which
was
the
replication
segment
and
one
in
pin,
which
was
the
sr
point
to
multi-point
policy
around
five
six
itf
ago.
F
I
did
present
this
graph
in
the
pce,
but
back
then
these
replication
segment
and
the
point-to-multiplying
policy
drafts
were
not
adopted.
As
such,
we
put
this
draft
on
hold
for
adaptation
on
the
pce
working
group
until
these
two
other
drafts
are
were
adopted.
So
as
of
now
they
are
adopted,
there
is
a
third
draft
that
is
the
draft
perk.
F
Mvpn
evpn
sr
point
to
multipoint.
We
were
asking
for
adaptation
for
that
too
in
bess,
and
I
believe,
as
of
yesterday,
that
draft
got
a
good
support
and
it
was
adopted
as
well
as
you
can
see.
There
are
other
drafts
to
make
this
solution
complete,
which
you
can
have
a
look
at.
If,
if
you
you
would
like
to
learn
more
about
it,
next
slide,
please
so
why
this
idea
was
put
on
the
table.
F
The
basic
idea
is
on
the
unicast
side.
Obviously
we
are
moving
away
from
the
from
the
complex
protocols
like
ldp
rsvpte,
and
we
are
trying
to
simplify
the
network
with
the
underlay
igp
and
then
overlay
pgp.
F
That
creates
an
issue
for
multicast.
Obviously,
when
a
vendor
takes
away
these
mpls
protocols
for
unicast,
they
don't
want
to
let
them
langer
in
their
networks
for
multicast
multicast
being
the
more
complicated
beast
of
the
two.
Obviously
they
want
to
do
the
simplifications
on
the
multicast
domain
as
well.
So
this
is
how
this
idea
was
evolved
by
coming
up
with
the
very
simple
method
to
program
a
point
to
multipoint
tree
through
a
network
whether
that
network
is
segment
routing
network
or
even
if
segment
routing
is
not
there.
F
F
So
the
very
first
concept
of
this
idea
is
what
we
call
the
point
to
multi-point
policy.
Actually,
it's
on
the
segment.
It's
a
policy!
My
apologies.
I
need
to
correct
that.
So
what
is
a
policy
you
can
think
of
a
policy
as
a
root
and
a
set
of
leaves
and
it's
really
identified
by
the
root
id
and
the
tree
id
now.
F
So
under
the
point-to-multipoint
policy,
you
could
have
multiple
candidate
paths.
Think
of
candidate
paths
as
a
redundancy
for
your
point
to
multipoint
three,
so
you
can
have
a
primary
candidate
pad
that
is
active
and
you
can
have
multiple
other
candidate
paths
that
are
inactive
and
there
is
the
preference
and
the
one
with
the
highest
preference
is
the
active
one
under
the
candidate
path.
There
are
two
path
instances
you
can
think
of
the
patterns
as
the
actual
point-to-multipoint
lsp
or
the
forwarding
entity.
F
The
reason
that
there
are
path
instances
is
basically
for
optimization
of
the
candidate
pad,
so
if
there
is
a
break
in
the
network
and
the
candidate
pad
needs
to
do
a
global
optimization,
it
creates
a
second
path.
Instance,
the
the
pce
programs,
the
second
path
instance
through
the
optimize,
the
route
from
the
root
to
the
leaf,
and
it
doesn't
make
before
break
on
the
head
end
to
switch
from
the
previous
unoptimized
tree
to
the
new
optimized
tree
throughout
the
throughout
the
network.
F
F
What
leafs
want
to
join
the
point
to
multiply
three
and
based
on
that?
You
can
update
the
pce
from
the
pcc
with
all
this
information
tree
id
root
id
and
on
delete
and
the
leafs
or
you
can
do
pc
initiated
what
the
pc
initiated.
Is
you
go
on
the
pce
itself
and
you
create
your
blue
route
and
the
set
of
leaves
and
you
assign
your
tree
id
and
then
the
pce
downloads?
The
information
to
the
pcc
next
slide,
please.
F
Now
one
thing
we
need
to
keep
in
mind
is
a
replication
segment
is
really
a
idea
of
multicasting
a
packet
at
a
specific
node.
Two
replication
segment
really
can
be
connected
via
a
unicast
segment
routing
domain
as
well.
So
the
entire
idea
is
not,
let's
put
replication
segment
one
after
another
to
forward
these
pdus
through
the
replication
segments,
but
it's
very
flexible
that
you
can
have
replication
segments
in
a
specific
places
in
your
network
where
you
want
to
do
the
replication
and
you
can
connect
these
two
replication
via
a
unicast
sr.
F
So
it
really
plays
very
nicely
with
the
unicast
sr,
where
there
needs
a
need
for
the
unicast
unicasting
between
the
two
replication
segments.
There
are
two
type
of
replication
segments,
and
I
want
to
be
very
clear
about
this
one
when
it
comes
to
point
to
multipoint,
lsps
or
mvpns
a
tunnel.
A
point
to
multiple
lsp
represents
the
verb
itself.
F
F
A
A
F
So
this
is
just
a
very
high
diagram
of
all
the
informations
that
are
there.
Oh
no
want
to
slide
back
sorry,
my
apologies
yeah.
So
this
is
again
I
explained
the
point
to
multiplying
plot
policy.
I
explained
the
candidate
path
why
the
path
instances
are
there
and
I
explain
what
the
replication
segments
are
there
and
the
fact
that
two
replication
segments
can
be
connected
via
a
unicast
sr
policy
now
for
the
rest
of
the
slides.
F
Those
are
just
some
examples
that
you
guys
can
go
through,
and
actually
you
can
have
a
look
at
them
and
try
to
understand
better
some
of
the
concepts
that
we
are
trying
to
bring
into
this
draft.
But
basically
the
main
point
that
we
are
trying
to
put
on
the
table
here
is
that
there
are
multiple
vendors
working
on
this
draft.
There
are
some
implementations
already
out
there.
F
F
J
F
J
So
in
that
case,
so
for
each
pitomp
pass,
we
have
states
in
the
network
right.
So
this
seems
a
lot
of
consistency
with
the
philosophy
of
sr
routing
or
whatever
segment
routing
right
for
sigma
routine.
The
idea
is
that
we
don't
have
any
states
in
the
network.
So
for
this
case
we
can
see
that
we
we
send
the
instructions
to
each
other
node
along
the
p2p
path,
and
then
those
states
stay
in
the
network
right.
F
Right
so
good
point
that
that
battle
was
already
fought
in
the
spring
working
group,
and
you
know
the
the
draft
was
adopted
on
the
spring
side.
But
to
answer
your
question:
basically,
a
segment
on
a
point-to-multiplying
segment
on
each
one
of
nodes
creates
a
replication
segment.
So
without
the
replication
segment
you
don't
know.
What
are
your
outgoing
interfaces
so
you're
going
to
go
in
this
case
you're,
going
to
go
from
a
to
c,
which
is
the
next
segment
in
in
the
replication
point.
A
Just
to
add
on
to
what
huaymou
was
saying,
I
think,
like
you
know,
of
course,
that
battle.
I
think
we
can
move
on
for
that
question.
But
I
think,
with
respect
to
pc
extension,
we
have
a
concept
called
pcc,
which
is
pc
as
a
central
controller,
and
that
was
developed
specially
for
cases
where
pc
needs
to
send
instruction
on
nodes
which
are
not
the
head
node.
A
So,
especially
in
your
case
when
you
have
to
send
instruction
to
the
the
branch
node
or
to
the
leaf
node,
I
think
the
pcc
technique
and
use
of
cci
object
would
have
become
a
better
extension
to
pc
protocol
than
what
is
currently
being
described
in
the
document.
And,
if
you
remember
we,
we
discussed
this
in
the
past
as
well.
When
you
last
presented
this
in
the
pc
working
group
and
that
concern
still.
F
F
So
we
went
down
the
path
of
the
cc
object
and,
at
the
end
of
the
day,
we
felt
that
the
the
ero
object,
the
way
that
we
are
using.
It
was
a
fit
for
this
idea,
so
you're,
absolutely
right.
As
of
now,
we
are
using
the
ero
object
to
download
the
forwarding
information,
but
yeah
like
as
as
a
group
as
as
a
team.
That's
the
path
that
we
went
down.
A
Yeah,
I
think,
like
we,
let's
have
that
discussion
on
the
list.
It's
not
just
the
matter
of
ero
object.
It's
actually
the
whole
framework
that
we
came
up
with
the
whole
framework
of
when
pce
is
interacting
with
non-head
nodes.
These
are
the
like
the
framework
and
the
architecture
and
various
things
in
the
pc
protocol
that
you
should
take
care
of.
So
I
think
those
are
still
valid.
It's
not
just
the
matter
of
whether
we
use
ero
object
or
cci
object.
It's
the
framework
that
I'm
more
worried
about.
A
R
Can
you
hear
me
okay,
hi?
This
is
shooking
from
huawei
and
I'm
going
to
introduce
the
set
of
pcc
drops
next,
please.
R
So,
first
a
quick
recap,
so
we
we
have
the
rfc8283
that
defines
the
pce
as
a
central
controller,
and
it
also
it
also
examines
the
psap
as
the
ice
sdn
source
pump
interface
and
for
this
draft
the
psap
extension
for
the
pcecc.
R
It
specifies
the
basic
psap
extensions
for
the
static
rsv,
so,
as
the
chair
has
already
introduced,
currently
exposed
working
group
last
call
and
it
has
been
reworked
after
the
shepherd's
review
here.
We
would
like
to
thank
to
julian
for
the
excellent
comments
to
us
and
also
today,
in
today's
to
this
morning.
We
also
replied
to
this
further
review
and
we
will
give
another
update
on
this
draft
to
further
resolve
the
the
comments
and,
very
briefly,
about
the
recent
changes.
R
R
R
R
So
it
allows
a
multiple
cci
object
for
the
replication
at
the
branch
node
and
again
we
also
aligned
and
synced
with
other
drafts
and
the.
Furthermore,
for
example,
we
reorder
the
section
as
well
and
as
well
as
some
editorial
real
changes.
So
again,
there
is
no
other
open
issues
next
piece
yeah.
So
we
would
like
to
request
for
issuing
the
adoption
call
and
thank
you
so
any
questions.
A
Okay,
thanks
shipping-
oh
there's
eigen!
I
just
go.
G
You
so
after
you
are
inducted.
We
know
that
the
pcc
for
mps
and
pcc
for
srv6
just
for
the
seed
or
location
you
know,
I
think
I
mean
it
is-
may
make
some
person
for
confused
with
the
pcc
for
a
pc
for
sr
policy.
So
can
we
think
some
better
to
disincrease
them?
You
know
this
job,
this
good
job,
because
only
for
the
federal
electrician
from
the
pce
and
not
related
to
the
quality.
G
So
you
know.
A
So
yeah
john,
are
you
suggesting
a
draft
name
change
or
title
change?
Yeah,
yeah?
Okay.
I
think
we
can
take
that
into
consideration
shipping.
What
do
you
think.
A
A
P
Yes,
okay,
very
good,
I'm
presenting
on
behalf
of
the
culture-
and
this
is
the
psap
extension
to
enable
like
this,
so
next
yeah,
firstly,
and
just
a
few
words
about
background
and
motivation,
so
we
already
presented
this
during
the
last
atf
and
we
also
had
some
discussion.
Basically,
the
id
terms
refers
in
this
case
to
data
plane
on
path,
telemetry
technique,
so
in
band
I
am
in
situ.
P
I
am
an
alternate
marking
and
you
can
see
the
reference
document
for
both
this
methodology
and
the
psf
extension
defined
is
knockman
allowed
to
signal
these
capabilities
in
order
to
enable
these
methods
and
to
automatically
activate
them.
P
In
particular,
we
aim
to
generalize
these
ip
attributes
to
include
this
dlv's
to
be
carried
as
lsp,
so.
P
P
Yeah
in
this
slide,
we
want
to
highlight
the
change
after
the
last
atf.
In
particular,
the
draft
has
deeply
changed,
because
you
may
recall
that
the
first
version
was
applied
as
tld
to
the
association
groups,
while
this
version
extends
this
definition
and
and
applied
tlds
for
all
part
types
and
is
applicable
to
lsp
attributes.
So
thanks
drew
for
this
input.
In
this
way
we
have
generalized
this
application,
and
the
sr
policy
is
now
a
news
case
of
of
this
draft.
P
Additionally,
we
also
got
other
comments,
in
particular
the
suggestion
from
fenway
to
add
different.
I
feed
capability
flags
in
this
way.
Each
capability
can
be
advertised
separately,
and
this
was
already
addressed
in
this
in
the
camera
and
version.
P
We
also
had
other
inputs
from
ymo.
So
thanks
a
lot,
and
we
also
improved
the
graph
to
produce
a
new
section
about
the
precept,
messages
and
procedures
for
I'm
leaving
this
tlb.
So
we
added
more
details
about
that,
as
well
as
the
example
of
application.
Usa,
quality
that,
as
I
mentioned
before,
it's
now
just
a
new
stage.
So
next.
P
Yeah,
the
psap
extension
correctly
attributes
the.
As
I
said,
the
tlds
are
now
carried
inside.
The
lsp
attributes
object
and
can
be
applicable
for
all
five
types.
So,
of
course,
these
dlvs
are
optional
and
can
be
taken
into
account
by
the
pce
during
fast
computation
and
by
the
pcc
during
path
setup,
they
can
be
carried
within
a
pc,
initiate
message.
A
pc,
update
message
and
pc
is
that
report
message
in
the
case
of
sr
policy.
Of
course,
these
attributes
also
complement
the
pc
segment.
Rooting
policy
ct
drop,
so
next
slide
is
yeah.
P
Okay,
yeah,
we
introduced
the
I
feed
capability,
advertisement
clv,
so
this
is
an
optional
tlv
in
the
open
object
for
capability
advertisement,
so
you
can
see
the
usual
tlv
format
and
five
bits
that
we
introduced
in
flags
field
to
signal
each
capability
and
each
I
fit
method
separately.
So
you
can
see
one
bit
four
bit
for
iom
option
flag
and
one
bit
for
alternate
marking
flag.
P
P
P
A
E
D
J
E
E
A
P
P
Yeah,
this
is
what
I
mentioned
before
as
an
improvement
after
the
itf-108.
So
we
details
how
these
dlvs
are
included
in
the
pc
in
psf
messages
and
also
the
example
of
application.
Qsr
policies
to
complement
the
segment
routing
policy,
cp
draft,
so
particular
port
pc,
initiated
the
lsp
with
ifit
feature
enabled
this
attribute
must
be
included
in
the
lsp
object
in
this
pc
initiate
message
after
the
instantiation
of
the
lsp.
P
Also
they
can
be.
These
attributes
can
be
included
in
the
pc
report
message
to
provide
the
status
and
when
the
lsp
is
instantiated,
the
8-fit
methods
are
applied
as
specified
in
the
corresponding
data
plane
document,
and
you
see
the
restaurant,
of
course
to
update
to
disabling,
enabling
this
feature
the
pc
update,
message
can
be
used
and
the
feed
attributes
can
be
included
next
slide.
P
P
I
Ahead
just
had
a
question
about
the
general,
like
ifit
architecture,
for
sr
policy,
whether
there
are
use
cases
where
you
could
have
different
tracing
options,
for
you
know
different
tracing
options
per
segment
list
of
the
sr
policy
candidate
path.
You
know,
as
you
know,
the
sr
policy
candidate
path.
It
has
multiple
segment
lists
right
and
I
kind
of
imagine
you
could
have
different
tracing
options
for
each
segment
list.
Potentially,
I'm
just
wondering
if
that's
been
included
in
the
actual
architecture
of
ifit
like
outside
of
psap.
P
I
Sure-
and
I
think
the
same
thing
has
to
be
done
for
bgp
t
equivalent
of
this
draft.
I
believe.
I
D
P
A
S
Hello:
everyone
I'm
looked
up
with
d4
from
mtn,
cameroon
and
I'll,
be
presenting
to
you
the
support
for
part
mtu
in
v6
on
the
behalf
of
the
quarters
drove
next
slide.
Please
so
on
this
slide,
I'll
try
to
give
some
sort
of
a
motivation
or
some
background.
S
Generally,
why
we
think
about
that
in
pset,
when
we're
looking
at
the
traditional
mpls,
the
pad
mtu
could
be
signaled
by
is
being
signaled
by
rsvpt
and
ldp,
as
you
can
see
in
the
rfc's
that
I
mentioned.
But
now
when
we
go
to
segment
routing
parts,
we
don't
have
any
additional
signaling
for
for
pad
mtu
and
we
currently
we
need
that
support.
S
What
we
can
get
excuse
me
from
the
sr
is
information
gotten
from
bgpls
and
that
is
being
used
by
pc
to
calculate,
but
when
packets
have
been
sent,
two
things
can
happen
if
it
is
below
the
the
the
mtu
size
it
can
go
through
or
if
it
is
more
you
you
have,
it
been
fragmented,
and
this
is
a
major
concern
when
it
comes
to
operator
networks,
but
because
it
it
it,
it
affects
greatly
the
the
quality
of
service.
S
So,
with
all
these
put
in
place,
we
thought
it
necessary
that
it
is
important
to
do
this
extension
in
a
preset
message.
Next,
like
this.
S
Now
this
client
basically
focuses
on
the
metric
object
for
part
mtu,
how
that
is
to
be
managed.
We
have
the
for
for
this
support
of
pad
mtu.
We
have
the
the
b
bit
which
is
supposed
to
be
set,
and
now,
when
this
bit
is
set
in
the
in
the
in
the
preset
message,
then
now
the
part
m2
can
be
used
as
a
condition
or
as
a
constraint
when
we
want
to
calculate
parts.
S
S
Now,
for
this
slide,
it
basically
gives
what
happens
when
we
take
this
into
consideration.
The
part
m2,
amongst
other
constraints,
that
we
can
have
between
the
the
pcc
and
the
pce.
S
So
what
happens
is
when
the
pcc
has
already
selected
the
pc
to
communicate
with
the
pcc
can
send
a
path,
computational
request,
a
message
to
the
pc
with
constraints,
the
exposed
constraints
it
can
either
be.
You
have
the
soft
address
the
destination
address.
S
You
can
have
the
bandwidth.
You
can
have
the
set
up
the
whole
priority
and,
in
addition,
we
have
this
part
mtu,
and
you
can
see
that
the
b
bit
is
being
set
to
one,
so
just
to
say
that
that
is
a
field
that
has
to
be
looked
in
in
the
message
now
when
this
pc
has
sent
this
request
to
the
pce.
S
The
pc
now
receives
and
computes
successfully
to
satisfy
the
constraints
that
have
been
put
in
the
in
the
packet
and
now
focusing
on
the
pce
when,
on
the
part
mtu
it
looks
at
this
parameter
and
it
can
get
back
with
the
response
meshes
telling
the
pcc
that
okay,
I've
gotten
a
successful
path
that
you
can
use,
and
now
you
can
also
have
a
case
where
this
part
is
successful.
S
Part
of
a
condition
the
conditions
are
not
fulfilled,
and
now
the
pc
he
will
get
back
to
the
pcc
and
indicate
the
conditions
that
led
to
the
failure
of
getting
a
candidate
path.
S
And
now
you
can
have
now
the
you
now
then
have
the
pc
initiate
message
which
is
used
by
the
pc
to
ask
the
pcc
to
set
up
a
new
lsp
as
well
as
provide
the
path
mtu
calculated
for
the
path.
So
that
is
what
now
the
pcc
would
use
to
forward
now
the
the
the
packet
in
this
slide.
S
H
S
Work
of
adoption
and
looking
at
how
important
this
is,
I
think
that
is
a
next
step
that
we
need
to
look
at
and
we
are
open
to
questions.
A
I
Yeah
I
wanted
to,
I
think
it's
a
good
draft.
First
of
all,
like
it's
useful,
I
wanted
to
make
one
comment
so
again
in
the,
as
you
know,
the
sr
policy
candidate
path
can
have
multiple
segment
lists
right
and.
I
Those
segment
lists
may
have
a
different
path:
mtu,
for
example,
you
may
have
like
segment
lists,
and
one
of
them
has
like
a
large
mtu
like
say
I
don't
know
2000
or
whatever,
and
another
one
has
like
a
smaller
mtu
like
1400.
I
So
in
that
case
you
know,
I
noticed
that
your
path,
mtu
is
per
candidate
path,
so
in
that
case
you
would
have
to
report
the
lowest
the
minimum
of
those
of
the
path
mtu's
of
the
constituent
segment
lists
right,
exactly
yeah,
so
it
might
be
useful
to
to
also
report
the
path
mtu
of
each
individual
segment
list
separately
as
well.
I
S
Okay,
yeah,
I
think.
A
Still
bit
low,
I
think
you
are
using
your
laptop
speakers.
I
will
ask
jeff
to
maybe
go
next,
while
you
figure
it
out,
and
I
will
give
you
audio
next
jeff
go
ahead.
Q
Q
M
G
M
Okay,
yeah,
I
could
answer
them
to
mike's
question
like,
as
mike
could
note
that
we
have
to
find
the
similar
solutions
in
bgp
as
a
policy
and
that
path
m2
is
associated
with
the
least
seat
least.
So
I
think
this
extension
and
pcp
drafts
that
would
be
identical,
so
yeah.
It
would
be.
I
didn't
associated
with
the
cities
yep.
Q
M
Oh
jeff,
we're
not
going
to
answer
your
question.
Answer
the
I'm
sending
the
mike's
question.
Sorry
and.
M
Yeah,
so
regarding
the
msd
like
proposal,
I
think
it
is
valid
and
maybe
we
can
make
more
discussion
on
the
mayan
list.
Yeah
sure
absolutely.
S
Yeah
yeah,
I
think
I
think
we
should
just
take
that
note
of
that
and
have
further
discussions
on
that.
Yeah.
M
Yes,
I'm
a
backup,
okay
go
ahead,
then
okay,
yep!
So,
ladies
and
gentlemen,
my
topic
today
is
about
a
state
synchronization
between
stateful
pc,
and
this
is
the
first
draft,
and
in
this
slide
we
were
going
to
present
three
drafts
which
are
associating
to
with
the
state
of
opc.
So
next,
please.
M
So
roughly
reminding
of
this
draft
is
that
in
this
draft
we
are
going
to
propose
the
mechanism
to
synchronize
these
states
among
the
stateful
pce's
right.
So
the
key
concept
of
this
document
is
that
we
we
initiated
this
sync
up
pc
sessions
among
stateful,
pcs,
and
so
that
we
can
sync
up
the
incremental
lsp
states
during
that
session
right.
So
we
also
supports
to
set
a
primary
and
secondary
pc
for
differentiate,
different
responsibility.
M
The
scenarios
of
this
includes
that
we
can
support
redundance
pces,
to
support
backup
or
like
load
balance,
and
also
we
can
support
the
scenarios
like
intel,
domain,
pcs
or
hierarchical
pcs
so,
and
we
have
make
a
presentation
in
itf
105
and
we
have
got
some
good
support
for
adoption.
So
next,
please.
M
M
M
So,
let's
okay,
so
to
stay
the
status
of
this
document
after
the
the
previous
presentation
is
that
we
make
some
auditory
changes
to
align
with
the
recent
I've
seen
like
yeah.
So
we
also
look
at
some
like
security
consideration,
and
so
at
this
time
we
think
the
draft
is
stable
and
natural.
So
we
could
like
to
request
for
a
working
group
adoption
of
this
document
yeah.
M
M
M
As
we
okay,
so
the
summary
of
these
drafts
is
that
we
clarified
how
the
p
flag
and
eye
flag
to
be
used,
so
it
can
identify
how
to
process
the
a
pcb
object,
and
I
think
this
kind
of
flag
has
flex
has
been
have
been
defined
in
rfc
like
54
40
right,
so
it
will
be
introduced
in
the
next
slide.
So
we
update
the
handling
of
on
how
to
handle
the
handling
of
and
no
objects
based
on
these
flags.
So
next.
M
Yeah
the
background,
the
background
of
this
p,
flag
and
ifrag
is
that
they
have
been
defined
in
ifc
5440
and
the
p
flag
is
used
for
in
indicating
that
the
pce
master
processing
must
process
the
the
objects
and
the
eye
flag
indicate
that
you
can
ignore
it
right
so,
but
in
I've
seen
like
8231
and
has
specified
that
in
the
stateful
pce
it
can
like
like
it
can,
it
must
be
set
to
zero
and
it
should
be
ignored
right.
M
So
in
this
draft
we
define
the
specific
how
say,
processing
of
this
two
flags.
Next.
M
Yeah,
so
this
slide
shows
the
p
flag
and
I
flag
usage
do
okay.
I
will
not
go
into
the
details,
so
let's
skip
that
this
part
yeah.
This
is
the
whole
flowchart
of
the
processing
of
unknown
object
right.
So
when
the
p
plug
is
set,
it
means
that
we
have
to
process
this
object.
M
Otherwise
we
do
not
need
to
the
pcp
speaker
is
free
to
process
it
or
not,
based
on
its
like
local
policy.
So
if
the
p
flag
is
set
and
the
object
is
unknown,
then
we
have
two
ways
to
go.
If
the
I
flag
is
set,
then
how
to
do
that
and
if
I
flag
is
no
set
and
the
pcp
is
also
afraid
to
ignore
it
or
not.
So
next.
M
So
the
status
of
this
draft
is
that
we
we
get
a
confirmation
of
the
problem
statement
on
the
list
and-
and
I
think
we
get
consensus
about
this
extension-
is
useful
right.
So
we
also
make
some
editorial
changes
to
think
of
the
recent
recent
ifcs
after
the
itf
105..
M
A
M
M
A
Cannot,
I
am
on.
M
The
page
which
says
vendor
specific
information
yeah
right
now,
I
can
see
the
slide.
So
the
last
draft
is
about
the
it's
about
conveying
the
vendor
specific
information
in
pcp
extension
for
a
study
for
pce,
and
I
think
some
vendors
have
implemented
it
already
right.
So
next,
please.
M
Oh,
there
are
some
delays
between
me
and
the
miracle
yep.
So
the
main
idea
is
of
this
draft
is
to
conveying
the
kvd
vendor
specific
information
between
the
pcp
speakers.
So
we
have
a
mega
presentation
in
itf
105
and
also
we
got
some
like
good
support
right
next,
please
yeah,
I
don't
think
we
can.
I
don't
think
we
need
to
go
into
the
detail
of
this
slide.
Next.
M
So
the
main
change
is
that
we
make
some
auditory
changes
we
think
to
to
to
align
with
a
recent
ifc
as
well
yeah
after
the
meeting
last
presentation-
and
we
added
the
implementation
state
case
from
cisco,
they
they
and
we
add
two
more
causes
as
well,
and
also
we
request
for
working
adoption
of
this
document.
A
From
the
chase
perspective,
we
wanted
to
ask
like
you
know:
these
documents
have
been
stable
since
idea
105.
So
if
there
are
any
objections
to
progressing
them
or
you
think
that
they
are
not
useful,
now
would
be
a
good
time
for
the
working
group
to
speak.
N
A
Okay,
julian,
you
have
any
famous
last
words
before
we
end
the
call.