►
From YouTube: IETF100-PCE-20171113-1550
Description
PCE meeting session at IETF100
2017/11/13 1550
https://datatracker.ietf.org/meeting/100/proceedings/
A
A
A
A
We
have
a
minute
taker.
Dhruv
is
going
to
take
the
minutes,
but
he
would
like
some
help.
Please
could
you,
if
you're
not
checking
email?
Please
could
you
go
check
the
etherpad
online
of
a
PC
you
session
and
help
truth
with
minutes
or
contributions
are
very
gratefully
received.
Is
anybody
in
the
jabber
room
that
could
act
as
a
jab
scribe
Adrian?
Thank
you
very
much.
A
So
we
are
streaming
the
audio
and
video
I
see,
but
that's
not
in
vain,
because
we
do
have
some
people
in
the
meet
echo
room.
So
please
only
speak
to
the
meeting
using
the
microphones
in
the
room.
Please
state
your
name
before
you
speak
so
that
the
minute
taken
can
record
your
name
and
present
as
if
you're
presenting
please.
Could
you
keep
your
feet
inside
this
small
pink
square
on
the
floor
so
that
the
people
who
are
remote
can
can
see
you
and
yeah.
My
as
you
can
see,
there's
only
one
chair
today.
A
A
The
usual
reminder
for
everyone,
please
to
use
a
mailing
list
and
use
it
actively,
and
if
you
have
any
discussions
you
want
to
have,
please
have
them
on
the
list.
If
you're
making
any
changes
to
a
working
group
draft,
then
it
would
be
great
to
discuss
those
on
the
list.
That's
not
always
the
case,
but
if
you're
making
changes,
it
would
be
great
to
at
least
send
an
email
to
the
list
and
tell
us
what's
happened
in
your
draft.
A
A
A
A
After
five
years
and
seven
months,
we
have
finally
published
a
stateful
PCE
as
an
RFC
and
thank
you,
everyone
for
your
contributions
and
patience
as
we
as
we
got
my
drive
through
the
working
group
and
out
the
other
side
improve
EIC
and
out
the
other
side.
Now
we
have
our
SE
82
31
nice
good
news
for
pretty
much
every
of
the
draft
we
have
going
in
the
working
group
because
they
were
all
depending
normatively
on
it.
So
it's
really
good
to
have
that
out
there
and
with
it,
dropped
out
a
slew
of
other
things.
A
The
LSP
state
synchronization,
which
which
was
kind
of
a
companion
document
to
that
and
a
piece
of
extension
for
service,
aware
LS
piece
was
also
dependent
on
state
for
PCE
and
there's
kind
of
a
double
whammy,
because
another
really
important
draft
also
got
to
RFC
in
this
period
piece
M
s
so
piece
F
over
TLS
securing
P
sub.
It's
really
good
to
see
they
get
published
and
I
hope.
A
That
further
to
that,
we
have
free
drafts.
Currently
the
RSC
editors
Q.
We
have
the
staple
PCE
or
LSP
initiation,
which
is
being
edited
right.
Now
we
have
the
Intel
our
extensions,
which
depends
on
it,
and
we
also
have
the
bids
draft
for
RFC
6006.
That's
stateless
PCE
for
point-to-multipoint
all
three
sitting
in
the
RSC
editor
queue,
so
I
expect
those
to
drop
out
as
our
C's
very
soon.
A
A
Few
administrative
items
we
have
a
new
art
burrata
on
embarassingly
on
the
Roc
we
just
published
about
a
few
weeks
ago.
It
was
an
wrong
reference.
He
was
actually
an
indirect
reference
to
a
crypto
algorithm.
It
was.
It
was
a
reference
to
a
document
which
reference
to
the
documents
which
defined
the
crypto
algorithms.
So
we
need
to
correct
that
reference.
We're
going
to
correct
it
in
the
errata.
The
office
of
compact
confirmed
that
there's
no
technical
impact
so.
A
We
also
did
some
early
code
point
allocations
for
the
Association
group
draft
we're
hoping
to
get
that
draft
published
quite
soon,
but
in
the
meantime
we
needed
to
get
code
points
in
place,
because
there
are
implementations
that
people
want
to
start
building
networks
or
building
building
some
sort
of
network
with.
So
we
allocated
some
new
code
points
without
draft
they
now
left
it
listed
on
the
I
honor.
B
A
No
okay!
Well,
what
I
heard
I'm
the
word
on
the
street
is
that
the
authors
are
considering
whether
the
scope
of
this
draft
is
right.
Considering
they
started
writing
it.
When
I
was
still
at
school,
and
now
we
have
staple
PCE
and
then
the
world
has
changed.
They
may
need
to
update
the
draft
with
those
new
requirements.
So
it's
with
them
to
consider
that
I'm
not
going
to
force
them
to
do
it
that
if
they
want
to
do
it,
then
great,
but
if.
A
C
A
Then
hopefully,
we'll
just
be
shepherded
on
the
next
to
relate
to
gmpls,
whereas
Yoo
Lian
tells
me
he's
something
like
80%
of
a
way
through
writing
up
a
shepherd
report
for
through
gmpls
extensions
and
I
hope
that
he'll
be
another
20%
of
the
way
through
that
before
we
get
to
the
next
IDF
meeting
and
will
will
have
removed
this
from
the
list.
The
w.zahn
rwa
draft
is
ready
to
go
Danijela
shepherd
that
a
long
time
ago,
it's
just
blog
tom
on
gmpls
we're
gonna
move
those
two
forward
together.
A
We
have
about
five
drafts
here
that
are
pretty
much
telling
me
that
they're
ready
for
last
call
segment
routing,
which
is
basically
a
follow-on
from
the
LSP
setup
type
that
will
go
when
the
LSP
setup
type
is
ready,
hierarchy.
Extensions,
where
I
think
that
the
draft
has
expired,
I
think
the
vas
just
down
to
the
draft
being
dormant
while
they
wait
for
the
the
publishing
process.
There's
anyone
here,
who's,
an
author
of
hierarchy,
want
to
make
any
comments
about
that
I.
A
The
the
next
one
is
PC
Association
group,
where
we've
just
completed
the
early
allocation,
but
a
lot
of
work
is
depending
on
that.
The
document
seems
stable.
We're
going
to
push
that
through
to
last
call
shortly
up
to
the
meeting
staple
PCE.
Also
a
bandwidth
again
has
been
around
for
a
while
is
stable.
The
officer
saying
is
ready
and
staple
PC
points,
multi
points
you
will
be
hearing
about
in
a
few
minutes
time,
so
they
should
all
be
getting
ready
for
last
call.
A
D
From
Warwick,
so
regarding
the
yang
model,
basically
from
our
side,
more
or
less
things
are
stable
and
we
have
not
made
much
change
from
since
we
presented
in
ITF
99,
and
we
asked
a
few
clarification
questions
or
to
the
yang
doctors.
So
we
have
got
some
replies,
but
we
have
not
yet
updated
those.
So
that's
one.
B
D
D
A
D
F
So
I
think
we
addressed
recommends
that
we
received
a
couple
of
time
ago
in
the
latest
version
from
my
point
of
view,
or
there
is
one
element
that
we
added
that
are
not
completely
happy
with,
so
maybe
we
need
more
discussion
on
it,
otherwise,
I
think
the
main
point
of
the
main
architecture
of
the
draftees
is
okay.
This
just
be
small
point
to
our
advice:
okay,.
F
A
And
to
dress
release
its
ass
type
of
PCA,
1vb,
gmpls
extensions
to
stay
for
PCA
and
the
other
stable,
PC
LSP
scheduling,
where
honestly
I'm
not
sure
what
the
status
of
these
is.
They
seem
to
have
been
dormant
I.
Don't
more
sure
if
ask
us
we're
finished
or
if
that's,
because
people
are
working
on
them.
D
True
truth
regarding
the
scheduling,
I
think
we
did
make
an
update
just
before
the
ITF
and
basically
to
keep
it
aligned
with
the
t's
document
as
well
as
it's
getting
progressed
there.
There
were
a
few
other
changes.
We
wanted
to
also
align
to
the
way
the
RFC
8
2,
3
1
tells
us
to
do
a
few
things
and
the
state
synchronization.
D
A
A
Some
of
our
drafts
are
expired,
as
we've
noted.
Some
of
them
are
expired
just
because
I'm
moving
slowly
for
various
reasons
and
that's
okay,
we
just
need
to
get
them
alive
again,
so
we
can
take
the
next
step
or
a
to
where
the
chairs
are
wondering
if
they're
still
an
editor
in
charge
or
if
the
draft
is
now
headless.
A
A
B
A
H
There's
been
one
revision
published
for
this
since
the
last
IDF.
This
revision
contains
some
minor,
a
total
changes
to
get
ourselves
aligned
with
the
progress
of
the
three
documents
listed
on
the
slide.
At
this
point,
that
document
is
fairly
stable.
There
no
open
issues.
We
believe
it's
ready
to
progress
to
the
next
stage.
So
we
like
to
request
the
working
group
and
the
chairs
to
consider
this
Falasca.
A
Okay,
so
this
draft
has
been
around
for
quite
a
few
cycles.
It's
been
stable
for
a
long
time.
I
haven't
seen
too
many
reviews
of
it
happy
to
proceed
to
a
last
call.
It
would
be
great
to
see
a
few
reviews
during
last
call.
My
main
concern
is
there
haven't
been
enough
pairs
of
eyes
on
it,
so
I
mean
obviously
we
we
tried
to
do
a
Carol
Shepperd
review,
but
that's
no
substitute
for
multiple
pairs
of
eyes.
So
I'll
proceed.
The
last
call
and
I
hope
and
pray
that
people
do
do
review
that.
A
A
D
Hello
yeah:
this
is
drove
I'm,
presenting
a
piece
of
extension
for
sr
v6,
so
they're,
a
bunch
of
other,
is
our
v6
documents
that
you
are
seeing
in
the
idea
of
today.
So
within
the
B
sub,
we
wanted
to
see
what
changes
we
need
to
make
to
support
it
and
whether
it's
a
good
idea
or
not
as
well
so
so
what
we.
D
Know
that
s
are
basically
allows
you
to
steer
packets
through
both
ipv6
and
M
pianist's
and
use
the
same
source
routing
paradigm.
Only
the
data
plane
is
change
is
different.
One
uses
MPLS
stack,
other
use
an
ipv6
header
extension,
that's
the
basic
difference,
so
the
question
that
we
have
is
should
be
C,
be
able
to
compute
SR
path
for
both
ipv6
and
MPLS
forwarding
plane
and
if
it
can,
can
P
sub
be
used
as
a
protocol
to
transfer
that
information
from
the
the
PCE
to
the
the
head
node,
where
the
who.
D
So
these
are
the
two
questions
that
are
the
most
important
questions
for
the
working
group
before
we
can
jump
into
how
we
kind
of
do
it
right.
So,
from
the
author's
point
of
view,
are
we
kind
of
see
like
what
would
be?
What
would
this
extension
look
like
if
we
try
to
do
it?
Basically,
in
case
of
SR
v6,
the
difference
is
that,
instead
of
an
MPLS
label,
we
will
be
using
an
ipv6
address
to
identify
a
particular
segment,
and
just
an
ordered
list
of
ipv6
address
is
instead
of
a
label
stack.
D
You
have
an
ordered
list
of
ipv6
address
in
this
case,
so
we
already
have
PC
segment
routing
draft
which
focuses
on
MPLS
data
plane.
If
we
extend
the
same
extension,
what
are
the
changes
that
we
would
need
to
do
to
support
ipv6
data
plane,
so
we
kind
of
realized
that
main
changes
would
be
that
we
already
have
an
SRA,
ro
and
sr
r
ro
sub-object
that
we
used
for
segment
routing.
A
few
changes
needs
to
be
made
to
that
to
support
SR
v6
behalf
capability
negotiation
as
a
part
of
segment
routing.
D
Maybe
we
need
to
separate
it
out
and
since
the
parameters
are
different,
that
one
is
more
focused
on
the
MPLS
and
MSD
kind
of
stat
depth
and
those
things-
and
here
we
have
different
parameters-
maybe
doing
it
separately
would
be
a
good
idea
and
also
since
we
have
the
setup
type,
maybe
we
could
use
the
setup
type
also
as
a
way
to
signal
that
this
is
an
ipv6
data
plane.
So
this
was
at
the
high
level.
What
we
thought
would
the
extension
would
look
like
messages
I,
don't
think.
D
D
So
a
quick
look
on
the
top
is
the
capability,
so
in
the
capability
of
the
TLV
itself
can
specify
whether
the
PCC
or
PC
supports
the
SR
v6
and
the
Mac's
SL
can
also
notify
what
is
the
maximum
the
segment
ipv6
segment
header
length
that
can
be
used,
and
this
is
quite
different
from
MSD.
So
it's
better
to
have
it
in
a
separate
TLB.
D
The
as
I
said,
part
setup
type,
the
second
one-
and
this
is
the
updated
SR
aro
sub
object
compared
to
the
one
that
is
there
in
the
segment
routing
draft
the
most
of
the
top.
Things
remains
the
same,
and
if
you
remember
there,
you
have
an
S
ID,
followed
by
nai,
which
is
network
and
node
or
adjacent
c
identifier.
So
we
kind
of
updated
that
to
also
include
the
SR
v6
identifier
and
inside
there's
our
v6
identify
you
have
the
SR
v6
ID,
which
is
a
128-bit
ipv6
address
and
some
other
information
about
the
society.
D
What
function
the
Society
has
some
flags
and
what
type
it
is,
and
this
type
can
further
use
nai
that
we
already
have
to
identify
that
this
si
D
belongs
to
which
node
or
which
adjacency
etc.
So
the
idea
is
to
keep
it
aligned
to
the
s
re
ro
s
RRR.
Oh,
that
already
exists
just
a
bit
with
the
SR
v6
identifier
and
the
function
code
and
some
other
informations
that
will
help
us
achieve
the
v6
requirements
as
well.
D
So
first
I
think
to
the
working
group.
First
question
would
be
that
with
this
stuff,
we
are
making
sure
that
the
PC
and
PCL
can
be
used
for
both
modes
of
segment
routing.
So
we
as
a
we
need
to
decide
as
a
working
group
that
whether
this
is
a
good
idea,
whether
we
should
continue
to
use
B
sub
even
for
SR
v6,
and
if
we
do
it
in
that
way,
is
this
extension
what
we
are
proposing
does
it
make
sense
or
not
so
any
comments.
A
A
A
What
are
you
wait
until
I
get
the
OSP
set
up
tog
draft
out
and
that
come
home
we
yeah,
you
can
show
the
update
I
noticed
buried
in
the
tags,
that
you
have
a
dependency
on
the
segment
routing
draft
which
doesn't
specify
something
which
I
can't
remember
what
it
is.
But
if
you
could
put
that
on
the
mailing
list,
then
we
can
make
sure
I
guess.
I
D
J
D
This
is
a
park,
protection
and
general
piece
of
association.
When
I
wrote
the
the
slides
I
thought
that
I
had
to
convince
the
working
group
that
Association
needs
to
be
moved.
Luckily,
John
has
already
put
in
his
chairs
slide
that
he
wants
Association
to
be
moved
soon.
So
few
of
the
slides
we
can
kind
of.
D
Quickly,
my
work
is
already
done
there,
but
just
to
keep
people
up
to
date
it
on.
What's
the
changes
that
we
have
done
main
changes
since
we
wanted
to
publish
in
early
I
on
a
location,
so
we
make
sure
that's
completely
clean
and
it's
taken
care
of.
So
luckily
that's
done.
Thank
you
chairs
and
ATF,
and
some
of
the
implementations
are
already
started
using
the
only
allocated
code
point
and
one
more
thing.
D
So
luckily
we
have
had
a
good
back-and-forth
between
the
various
association
types
and
the
generic
association.
These
things
are,
things
are
going
well
over.
All
that
we
have
two
working
group
documents.
Three
other
documents
are
on
the
agenda,
including
this
one
that
I'm
going
to
start
talking
about
very
soon,
and
then
we
have
some
other
documents
as
well,
which
have
been
published
as
well
as
presented
in
them
some
other
idea.
So
there
is
a
good
set
of
documents
based
on
Association
so
to
the
main
topic
path,
protection.
D
So
Park
protection
in
fact,
was
one
of
the
first
Association
type
that
was
published.
In
fact,
this
was
the
type
when
we
were
when
the
author's
I
was
not
part
of
the
team
back
then,
and
when
the
authors
were
considering
part
protection,
that's
the
time
they
realize
that
we
may
need
to
do
a
generic
Association
so
that
we
don't
have
every
different
use
case,
trying
to
do
this
in
a
different
way.
D
So
we
went
back
and
said
that
let's
write
a
generic
Association
object
and
make
the
part
protection
as
a
separate
document
where
the
Association
object
is
defined
there,
and
this
document
just
defines
a
new
Association
type
called
protection
right.
So
this
document,
in
fact,
has
been
there
for
a
long
time
since
2014
last
it
was
presented
was
in
Buenos
Aires,
but
it's
a
pretty
straightforward
document.
D
It
simply
associate
two
or
more
LSPs
to
provide
path
protection,
so
it
has
a
new
path,
protection
type
and
it
has
a
TLV
called
path:
protection
association,
TLV,
which
can
be
carried
in
the
association
object.
And
why
are
this
you
identify
among
this
group
of
LSPs
which
LSP
is
working
and
which
LSP
is
a
production
LSP
and
what
is
the
mode
of
further
LSP,
whether
it
is
on
a
standby
mode
or
not?
D
So
the
changes
that
we
did
add
since
the
protection
is
a
dynamic
Association
of
sorts,
it
is
created
automatically.
We
don't
expect
operator
to
configure
the
Association
ID
and
other
details.
It
just
configure
protection
unable.
So
since
this
is
a
dynamic
Association
or
the
text
around,
it
has
been
added,
some
error
handling
has
been
updated,
made
sure
that
we
are
aligned
to
the
stateful
PC
out
of
C
at
231,
etcetera
and
the
text
from
security
and
other
manageability
considerations.
Section
was
missing,
which
has
been
added.
D
Basically,
we
feel,
like
you
know,
this
is
a
quite
important
document.
It's
a
useful
feature.
We
all
need
protection
and
draft
has
been
stable
and
there
are
in
fact
known
implementation
for
the
protection
draft.
This
was
in
fact,
as
I
said,
the
first
Association
type
that
actually
came
to
the
working
group,
but
somehow
the
diversity
and
the
policy
and
some
other
documents
moved.
I
had
much
earlier
than
this
one.
A
B
A
J
J
J
J
J
J
J
So
there
is
an
optional
Association
group
TL
we
define
that
contains
the
flags
for
forward
you,
LSP,
reverse
LSP
and
the
core
outed
parts.
There
are
some
rules
defined
in
the
RSVP
for
our
T's
working
group
document
to
identify
forward
and
reverse
LS
piece
and
the
last
one
error
handling.
So
as
mentioned,
the
forward
and
reverse
LSP
is
belong
to
the
same
tunnel
and
during
the
piece
of
communication
there
is
a
error
core
defined
to
identify.
A
J
A
A
E
D
L
So
this
market
has
been
initiated
three
years
ago
and
was
once
terminated
because
some
scope
and
conflict
with
some
other
works,
especially
for
the
Association
groups,
works
and
by
carefully
discussion
with
authors
from
other
draft.
Oh,
we
has
aligned
our
scope
and
the
risk
of
this
draft
to
support
only
the
resource
sharing
scenario
and
specify
this
kind
of
strategy
when
the
new
era
piece
used
to
to
replace
an
existing
RSP,
and
we
also
support
another
scenario
for
resource
sharing
between
two
hours
piece
with
different
parameters,
including
the
endpoints
or
bandwidth,
and
some.
B
L
Parameters
in
the
drafter,
we
include
the
two
different
use
cases,
so
why
it's
for
a
single
PC
pass
computation
in
the
single
domain
case
and
the
other
is
a
kind
of
multiple
PC
interactions
which
can
be
applied
in
either
inter
domain
case
or
inter
layer
case
and
considering
the
resource
sharing
strategies.
We
now
provide
three
different
consideration.
That
is,
you
share
the
link
or
you
share
the
node,
or
you
share
the
same
as
our
G
group.
So
now
we
are
working
together
with
the
Association.
L
Okay,
this
flowchart
is
a
little
bit
repeating
what
groups
crossing
his
picture,
but
this
one
becomes
more
simple
because
it
is
quite
clear
that
Association
group
objector
is
is,
is
a
base
objectified
and
we
are
going
to
define
different.
The
TR
is
a
comparator
with
resource
sharing
missing
the
the
other
extreme
for
past
computation
is
a
kind
of
diversity,
so
this
rather
covers
how
how
to
compute
different,
passing
or
diversity
ways,
but,
and
our
work
focused
on
how
to
do
it
in
are
sharing
ways.
L
L
So
this
is
a
brief
view
of
the
TRA,
and
currently
we
include
a
straight
event
of
flags
here
and
the
representative
for
the
strategy
are
sharing
and
the
arab.
It
is
the
link
and
bit
for
node
and
the
aspect
for
SI
ROG,
so
in
when
any
of
this
bit
is
set
to
1.
It
means,
during
the
past
computation
the
PC
need
to
prioritize
that
kind
of
sharing
during
the
past
computation.
So
it
means
that
it
would
firstly
try
to
share
the
link.
L
L
Failure
directly,
so
if
we
cannot
find
a
pass
without
link
share,
then
it
will
report
failure
its
if
failed,
again,
yeah
and
the
same
procedure.
Rules
applies
to
every
flex
and
for
their
further
node
and
as
RMG
beat
pc
just
the
priority
for
our
highest
different
parameters,
to
be
feared
for
the
past
commutation
and
there's
such
kind
of
information
to
be
shared
that
is
carried
in
the
optional
theories.
L
So
currently
we
bring
this
work
back
after
team
after
two
years,
and
we
want
to.
We
have
already
confirmed
the
relationship
for
this
work
and
the
the
other
existing
works.
We
are
trying
to
make
sure
that
we
are
doing
the
right
way
and
they,
if
there
is
any
suggestion
to
the
solutions,
well
welcome
to
to
receive
any
comments,
and
we
will
also
like
to
request
for
a
working
group
of
the
doctor.
Thank
you.
E
A
A
C
D
Hi,
the
stove
again
your
final
presentation:
it's
on
state
synchronization
between
stateful
PC.
This
document
has
been
discussed
in
the
last
two
ITF,
and
so
we
will
present
what
is
the
latest
update
that
we
have
done,
and
let's
start
with
that?
So
basically,
what
is
this
document?
This
document
defines
the
procedure
that
how
to
stateful
PC
communicate
with
each
other
and
this
communication.
Basically,
we
are
doing
to
make
sure
that
the
PCE
deployments
are
resilient,
that
if
one
stateful
PCE
goes.
B
D
Doesn't
lead
to
disaster
and
there
is
other
the
PC
which
can
easily
take
over
some
of
the
procedures
were
already
defined
in
a
2,
3
1.
The
idea
with
this
document
is
to
make
sure
that
we
become
much
more
resilient
and
solve
some
of
the
issues
that
we
found,
like
looping,
optimality
issues,
etc,
especially
in
case
when
the
path
computation
is
a
dependent
bar
computation
and
in,
for
example,
in
case
of
diversity,
where
to
LSPs
who
are
related
to
each
other,
and
when
we
are
doing
path
computation
on
them.
D
It
could
lead
to
some
computation
loops
etcetera,
which
has
been
discussed
in
the
previous
ITF
meetings
a
couple
of
times.
One
thing
that
we
can
work
towards
to
make
sure
that
we
do
this
in
such
a
way
that
it
can
be
used
in
various
PC
to
PC
relationships,
whether
we
have
a
redundant
PC
where
one
pcs
is
a
slave
at
another.
D
Pc
is
the
master
and
all
computation
is
done
by
one
guy
and
only
on
the
failure
it
moves
to
the
other
one
or
the
two
pcs
are
sharing
and
they
are
load
balancing
between
each
other
within
the
same
domain.
The
next
set
is
when
you
are
two
pcs
which
are
in
different
domain,
and
you
would
like
to
share
information
then
also
the
same
extensions
could
be
easily
used
in
both
peer-to-peer
relationship
or
parent
to
child
relationship.
D
D
So
generic
procedure,
this
is
a
generate
procedure.
It
works
for
both
the
cases.
We
call
this
piece
obsession
or
state
sync
piece
obsession
and
we
have
a
capability
around
it
so
that
you
can
identify
on
which
session
we
would
be
exchanging.
This
information
and
the
synchronization
needs
to
happen
from
both
pcs
so
from
one
PC
to
another,
one
PC
with
his
state
and
another
PC
with
another.
They
say:
that's
why
it's
bi-directional
in
nature
and
some
of
these
state
sync
relationship.
D
You
can
mark
that,
yes,
for
some
set
of
LS
B's,
one
of
the
pcs
is
the
is
the
master
PC
who's
gonna
do
all
the
path
computation
and
within
that
Association
group,
for
example.
If
we
take
the
diversity,
all
the
LS
piece
must
be
delegated
to
that
master
PC.
Who
will
do
the
computation
and
that
will
allow
and
help
us
not
to
go
into
the
computational
loop
and
which
PC
is
responsible,
etcetera
and
the
way
to
decide.
This
relationship
is
a
simple
PC
election
that
can
be
done
based
on
the
priority.
D
We
also
need
to
make
sure
that
that
how
the
NSP
state
needs
to
move
from
PC
to
PC
and
maybe
from
one
PC
to
another.
So
what
are
the
set
of
forwarding
rules
around
that
that,
when
PC
should
forward
this
information
to
another
PC
II?
So
those
rules
are
also
well
defined
in
the
document,
and
then
we
have
the
sub
delegation
procedure,
which
is
as
I
was
talking
about
in
master
and
slave
may,
be
the
PCC
delegates,
the
LS
p21
PC,
but
that
PC
is
not
the
PC
who's
supposed
to
do
the
path
computation.
D
In
the
document
so
coming
to
the
main
part,
that
is
what
is
the
update
that
we
have
done
so
the
update
was
around.
How
do
we
make
sure
that
the
state
that
is
stored
in
the
at
the
PC
is
the
latest
state?
So
you
might
be
getting
the
state
from
the
device
which,
as
as
for
a
2/3
one
happens,
that
the
PCC
is
supposed
to
provide
you.
The
LSP
state
from
the
device,
as
well
as
unable
PC,
might
be
sending
you
the
states.
D
So
we
need
to
make
sure
that
we
update
the
state
with
the
latest
information.
So
we
we
have
this
procedure
laid
out
for
that
that
how
we
could
do
that.
So
the
main
moon
two
points
are
that
we
need
to
keep
single
state
and
make
sure
that
that
state
is
the
latest.
We
will
also
maintain
from
which
all
sources
we
have
received
the
state
so
that,
even
if
one
session
goes
down
and
if
from
other
session
I'm
still
able
to
learn
about
this
information,
I'll
keep
it
till.
D
The
information
goes
from
every
source
right,
so
that
kind
of
procedure
will
help
when
we
have
a
list
of
all
the
sources.
So
how
did
we
be
we
kind
of
debated?
What
is
the
best
way
to
do
that?
One
thing
that
we
we
found
that
since
we
already
have
in
the
state
synchronization
optimization
procedure,
something
call
as
the
LSP
DB
version,
which
we
wrote
to
do
some
kind
of
optimization
like
when
we
can
skip
or
when
we
can
do
incremental,
DB
sync,
rather
than
doing
a
full
sync
every
time.
D
So
if
we
can
use
this
LSP
DB
version
yr,
which
we
can
always
figure
it
out,
that
which
LSB
state
is
the
latest
state.
So
but
the
value
of
the
LSP
TV
version
is
per
session.
So
what
we
had
to
do
was
we
created
another
theory
called
original
and
SP
DB
version
theory,
and
the
idea
of
this
TLB
was
to
carry
the
PCCs
LSP
DB
version
as
it
received
from
the
PCC,
and
you
may
still
have
the
LSP
der
DB
version,
which
is
between
PC
to
PC.
So
why
are
this
new
original
LSP
DB
version?
D
We
could
always
determine
which,
which
is
the
latest
state
coming
from
the
network
and
the
PC
updates
the
state.
So
what
is
a
rule?
The
PC
will
update
the
LSP
state
only
when
the
DB
version
present
in
the
current
report
is
greater
than
what
is
already
stored
in
them
in
my
database,
so
this
will
ensure
that
we
never
use
the
older
state.
So
let's
take
an
example,
so
suppose
you
have,
you
are
receiving
a
state
via
a
PC
e
as
well
as
PCC.
D
For
some
reason,
this
link
and
this
path
is
quite
slow
and
the
information
those
sent
by
the
PCC
this
information
PC
always
received
first.
So
let
us
take
the
top
example.
We
report
the
status
the
pc
further
forwards,
the
status
to
another
pc
e
and
includes
the
original
LS
p
DB
version.
Let's
assume
the
version
number
100
with
this
information
and
it
adds
it
into
the
database.
D
Now
some
other
change
happens
from
the
same
LS
p,
so
you
have
a
new
version
version,
0
1
and
while
this
version
is
still
going,
this
guy
is
still
quite
slow
and
it
has
not
yet
reached,
but
1
0
1.
We
simply
update,
but
on
the
slow
link
now
imagine
we
get
the
older
state,
which
is
still
not
read,
reach
the
pc
e
with
the
version
number
100,
and
since
this
is
an
older
version
to
the
latest
state,
we
will
simply
ignore
it.
So
why
are
this
procedure
very
simple
procedure?
D
We
could
make
sure
that
the
latest
state
is
always
maintained
at
the
PC
and
there
is
no
reason
for
us
to
get
like.
If
we
are
receiving
the
same
information
from
multiple
places,
we
will
make
sure
that
we
get
the
latest
information
only.
So
that's
about
the
updates.
So,
basically
what
is
still
pending
in
the
document.
We
want
to
explicitly
add
how
to
handle
initiated.
D
Ls
piece
you
see,
initiated
LS
peas
as
well,
but
technically
there's
not
much
of
a
difference
between
a
delegated
LSP
and
a
PC
initiated
LSP,
because
even
when
you
initiate
the
LSP,
it
goes
to
the
PCC
and
PC
reports
and
delegate
that
to
the
PC.
So
we
have
already
the
procedures
working
for
delegation.
All
we
need
is
to
clarify
and
make
sure
that
it
also
works
for
PC
initiated.
So
a
small
update.
We
need
to
make
which
we
are
working
during
this
idea
of
meeting
and
we'll
try
to
publish
very
very
soon.
This.
B
D
M
C
C
D
B
A
This,
what
the
use
cases
where
I
know
you
had
a
slide
on
that
didn't
quite
go
into
my
head,
so
is
it?
So
is
the
deal
here
that
there's
there
are
multi
of
multiple
pcs,
because
we
want
to
provide
some
sort
of
redundancy
or
scaling
to
the
network.
We're
just
having
one
point
of
failure
is
is
a
bad
place
to
be
okay,
yes,
in.
D
D
A
D
So
I
completely
agree.
I
think
that
model
also
exists
where
maybe
they
are
using
an
internal
database
and
sharing
clustering
solution
which
are
kind
of
popular
but
I
think
we
feel,
like
both
the
things
are
kind
of
needed.
If
a
PC
is
using
an
internal
thing,
doesn't
care
for
a
standard
protocol.
Yes,
they
can
do
within
that
as
well.
Yeah.
D
A
Standard
protocol
like
whether
it
could
be
done
with
the
standard
protocol
to
get
a
feel
for
the
need
for
it,
but
you
had
some
other
use
cases
yeah
well,
but
I
didn't
quite
understand
those
so
much.
Okay
at
the
inter-domain
case.
Why
would
two
pcs
in
a
different
domain,
share
responsibility
for
the
same
group
of
LSPs,
so.
D
If
you
have
end-to-end
LS
B's
and
imagine
you
have
an
end-to-end,
rsvp-te,
LSP
and
head
knows
definitely
knows
the
information,
but
we
also
want,
if
you
are
cooperating
between
two
set
of
pcs,
to
set
up
and
n2
and
LSP,
and
if
there
are
some
resources
information
in
the
second
LSP.
We
would
like
both
the
PCs
to
be
aware
of
that
information,
because
it's
an
end-to-end,
LSP
and
any
path
computation,
if
only
the
ingress
nodes,
nodes
and
other
does
not
will
not
give
us
the
best
optimal
stateful
PC
solution.
D
So
if
two
PC's,
when
they're
cooperating
via
request
messages
and
other
things
and
if
they
have
if
the
ingress
PCE
learns
the
latest
state,
we
wanted
a
good
and
fast
mechanism
to
also
report
that
information
to
the
next
PC
so
that
the
computation
goes
faster.
So
you
will
definitely
not
do
this
for
all
LS
B's,
because
there's
no
reason
for
you
to
share
that
information.
Only
for
inter
domain
LSPs
and
similarly
in
her
Ikey
PC
that
I
give
it
to
the
child.
D
A
A
We
got
two
I
think
two
people,
so
not
too
many
people,
so
I
think
it
seems
like
the
draft
hasn't
had
a
lot
of
traction
and
not
many
people,
who've
read
it
so
I
feel
like
it
would
be
a
good
idea
to
get
more
people
to
to
get
involved,
show
some
support,
or
at
least
interest
in
solving
the
problem.
At
the
moment,
I
think
I've
been
looking
to
find
if
there's
really
interested
in
working
on
this
problem
or
if
it's
just
something
where
you
know
sort
of
hypothesizing
Stefan.
F
Range
speaking,
so,
if
we
are
looking
at
the
current
PC
implementation,
we
know
that
are
based
on
a
application
based
redundancy,
so,
for
example,
using
that
AB,
a
synchronization
and
so
on.
We
had
a
lot
of.
We
have
a
lot
of
constraints
like,
for
example,
you
should
put
all
your
instances
in
the
same
site,
which
is
clearly
not
acceptable
for
us,
because
if
the
site
is
failing,
you
will
not
have
any
PC
anymore.