►
From YouTube: IETF101-PCE-20180320-1330
Description
PCE meeting session at IETF101
2018/03/20 1330
https://datatracker.ietf.org/meeting/101/proceedings/
A
A
A
I
just
want
to.
First
of
all
start
with
the
agenda
bashing.
We
posted
the
agenda
a
couple
of
weeks
ago.
Here
it
is
please
look
it
over.
Have
me
telling
you
about
working
group
status.
First,
we
discuss
some
input
from
other
working
groups
after
that
we'll
talk
some
about
our
working
group
drafts
and
then
a
couple
of
new
drafts
coming
into
the
working
group
from
Stefan
and
youngkwang.
A
Finally,
we
will
cover
some
drafts
have
been
presented
before
get
an
update
from
the
authors.
The
only
progress
has
been
made
and
at
the
end,
we'll
close
with
an
update
on
the
Sdn
discussion
that
we
started
on
the
mailing
list
last
year.
So
does
anyone
want
a
bashfully
agenda
or
hearing
any
problems
with
it?
So
I'll
proceed
to
my
stutter,
slides.
A
Okay,
before
we
get
started,
we're
displaying
the
note.
Well,
please
familiarize
yourself
with
the
note.
Well,
if
you
haven't
done
so
already,
I
won't
read
out
every
word
of
this,
but
gist
of
it
is
that
by
participating
in
this
meeting,
you
are
making
contributions
to
the
the
ITF
proceedings
and,
basically
than
that,
well
tells
you
about
your
rights
and
responsibilities
in
terms
of
intellectual
property.
That's
the
but
may
be
discussed
during
the
meeting.
A
A
I
have
a
minute
taker,
Dhruv!
There's
anybody
here
on
Java
yung!
Okay,
thanks!
If
you
could
keep
an
eye
on
Jabbar
and
bring
any
comments
to
the
mic
for
me.
Thank
you.
We'll
be
streaming
a
session
through
audio
and
video,
and
we
do
have
several
people
here
participating
on
meet
echo
who
are
not
in
the
room.
So
it
will
be
really
good.
If
you
could,
please
speak
only
using
the
microphones
state,
your
name
before
you
speak,
so
that
the
people
know
who
who
it
is
at
speaking
and
of
presenting.
A
A
Usual
reminder
about
the
mailing
list
and
we
conduct
all
our
business
on
the
mailing
list
and
would
like
to
encourage
you
all
to
use
it.
If
you
have
anything
you
want
to
discuss
about
drafts,
their
mailing
lists.
Emails
are
better
than
private
emails
for
that,
so
that
we
can
see
what's
being
discussed
and
what's
be
agreed.
A
If
it's
only
issues
or
on
the
drafts,
then
please
put
them
on
the
list.
Any
conclusions
that
you
come
to
and
please
put
that
on
the
list
as
well.
Please
use
the
list.
If
you
have
a
new
draft,
then
the
best
way
to
introduce
that
to
the
working
group
is
by
sending
an
email
to
the
list
saying
I
have
a
new
draft
is
a
problem
that
Salt's,
because
you
know
the
short
email
to
that
effect
will
actually
give
you
a
lot
of
exposure
to
people
who
would
like
to
read
it.
A
A
Okay,
so
with
the
improve
the
agenda,
no
one
had
any
problems
quickly
talk
about
the
status
of
the
working
group,
internet
drugs,
so
first
things.
First,
we
published
four
new
RFC
since
the
last
meeting
in
Singapore
we
have
the
extensions
for
PC,
initiated
LSP
setup.
It's
been
a
long
time
in
the
pipeline
and
we're
very
pleased
to
see
that
published
complete
some
of
the
work
on
stateful
PCE.
That's
been
long
overdue.
We
have
extensions
for
in
Tulare
e
82
82.
A
A
A
Essentially,
I
think
completed
IETF
last
call
now
there
were
a
couple
of
comments
during
last
call
from
the
ADEs
which
will
be
addressed
in
that
draft,
but
that's
fairly
straightforward
and
it
will
be
progressing
to
be
obviously
at
it's
assumed
address
still
in
the
working
group.
Then
so,
let's
see
if
they
have
people
in
the
room
that
can
can
help
update
the
status
on
these
I
think
I
know
the
status
for
most
of
it.
A
B
Dude
Dan
King
has
been
taking
care,
I'm
a
quarter,
I
checked
with
him,
and
we
we
had
the
discussion
that
whether
we
should
talk
about
stateful,
BCE,
now
or
not
I
think
that
still
is
a
bottleneck
like
young
daughters
are
not
able
to
conclude
that.
Should
we
just
publish
this
as
it
is
or
open
the
discussion
and
act
stateful
part
as
well.
So
that's
the.
A
Main
reason
this
is
so
this
is
kind
of
an
old,
an
old
draft
is
drafts
go
and
it
predates
or
the
staple
PC
work
and
I
guess,
there's
a
concern
that
it
may
be
a
little
obsolete
if
we
don't
include
staple
PCE,
it's
almost
like
we'd
be
publishing
something
as
historical,
so
I
would
encourage
the
authors
to
think
carefully
about
adding
a
staple
PCE
to
that
I.
Personally,.
A
So
we
have
two
gmpls
drafts
where
it's
essentially
blocked
on
the
final
shepard
review.
I
know
Julia
had
some
comments
which
has
been
trying
to
share
with
the
the
authors
and
some
time
on
the
the
gmpls
piece
of
extensions
I.
Think
he's
close
to
doing
that.
I
haven't
I,
have
another
an
exact
update
from
him,
but
once
he
does
that,
then
we
unblocked
that
and
we
also
in
black
the
w.zahn
RW,
a
draft
which
is
which
is
sitting
in
a
queue
waiting
to
go
to
the
iesg.
A
We
have
two
drafts
which
recently
went
through
working
group.
Last
call
was
a
segment
writing
draft,
where
we
had
some
nice
comments
from
Adrian,
Thank,
You,
Adrian
and
also
from
drew
I
think
which
I
have,
in
my
queue
towards
to
address
my
apologies
for
being
a
little
slow
in
getting
to
those
it's
just
because
of
not
having
enough
time
to
process
them,
but
I
will
get
them
soon.
I
promise
and
then
we've
just
passed.
A
A
So
now
that
is
now
a
live
draft
again
I
think
we
can
proceed
the
last
call
there.
We
also
have
staple
PC,
auto
bandwidth
in
the
queue
which
is
just
sitting
ready
for
last
call,
so
we'll
get
that
last
call
after
the
meeting
various
things
not
on
the
agenda.
This
time
we
have
two
new
working
group
items,
OSP
control,
request
draft
and
the
newly
adopted
piece
up
flows
back
which,
which
was
just
posted
a
few
days
ago.
B
Regarding
the
Younger
we
made
an
update,
the
main
update
was
only
to
add
some
examples
and
clarify
how
the
yang
model
would
be
used.
So
we
added
some
JSON
examples
in
the
appendix.
Apart
from
that,
I
think
the
document
is
quite
stable
and
we
would
think
that
it's
time
for
getting
the
yang
doctors
review
so.
A
C
Actually
are
quite
older,
doctor
has
been
silent
for
a
half
years.
I
practiced
these
slides
I'd
years
ago
and
I
understand
what
is
already
no
motivation
from
the
office
and
now
I
update
the
tractor
to
adding
those
kinds
of
new
error
types
that
has
been
developed
after
the
previous
working
officer
job
and
keep
the
reference
updated.
Can.
D
B
A
A
Couple
of
documents
are
expired.
We
talked
about
inter
reas
applicability
already
and
we
talked
about
the
GMP
LSP
piece
of
extensions
simply
expired
because
it's
ready
to
go
but
we're
waiting
for
shepard
comments,
so
don't
be
concerned
that
these
are
expired
and
it's
kind
of
expected
that
we
are
hoping
that
they'll
be
revived
soon.
B
Was
having
some
discussion?
One
point:
the
team,
of
course
regarding
the
segment
routing
draft,
so
we
have
our
piece
of
segment
of
India,
as
you
know
that
we
are
ready
to
ship
to
ilg,
but
we
also
have
BGP
tea
policy
and
know
where
the
tea
policy
works
in
its
space,
and
we
also
have
the
piece
of
extensions
there.
But
when
we
talk
to
the
customers
there
is
this
confusion
that
how
does
these
things
work
together
and
there
is
no
space
where
we
have
actually
discussed
that
ever
so.
C
E
E
E
E
We're
going
to
have
a
discussion
from
the
routing
perspective
in
the
MPLS
working
group
on
Thursday
morning,
and
we
are
more
than
we
would
more
than
welcome
hallway
discussions
or
other
discussions
to
understand
whether
this
is
a
real
problem
that
we
need
to
solve.
In
which
case
we
need
to
persuade
the
security
area
that
it
is
not
a
problem
that
needs
solving
or
to
come
up
with
a
solution
that
is
credible
for
those
of
us
who
do
routing
to
the
plot
to
implement
and
deploy.
G
G
G
Then,
basically,
the
way
on
how,
in
the
forwarding
plane
a
sender
can
indicate
that
it
wants
to
send
a
packet
to
a
particular
set
of
destinations
without
having
to
bother
about
the
path
that
takes,
would
be
that
we
do
provide
the
source,
on
the
left
hand,
side
of
the
picture
with
an
information
about
which
set
of
bits
to
set
for
every
receiver.
And
you
know
if
he
wants
to
add
and
remove
receivers.
G
He
can
basically
just
or
the
appropriate
bit
set
for
each
receiver
right
because
that's
just
a
superset
and
that's
what
forms
the
tree
right.
So
that's
basically
I
think
very
crucial,
because
this
type
of
operation
providing
a
source,
a
sender
of
br-2
e
traffic
with
the
list
of
you,
know,
set
of
bits
for
every
possible
receiver.
That's
one
of
the
core
kind
of
functionalities.
Where
that,
within
the
framework
of
the
solution,
we
would
probably
think
would
be
a
core
feature
for
PC.
G
So
basically,
we
have
here
what
we
call
the
sender
PFI,
our
via
forwarding
ingress,
router
midpoint
via
forwarding
router
via
forwarding
egress,
and
so
underneath
that
we
have
the
via
forwarding
we're,
also
thinking
about
IGP
extensions
for
it,
and
we
have
underlying.
For
example,
when
we
tunnel
through
a
unique
house,
we
have
segment
routing,
potentially
underneath
it
and
the
normal
IGP
and
then
toward
the
control
plane.
G
We're
talking
about
having
PCE
controller
may
be
a
separate
provisioning
system
or
integrate
into
the
PCE
controller
monitoring
and
we're
basically
talking
about
what
are
the
different
type
of
protocols
of
interest.
One
obviously
primarily
for
provisioning
is
yang
and
through
net
contrast
con
the
other,
of
course,
the
PCP
which
could
be
used
for
the
provisioning,
I,
think
rooftop
view.
That's
called
PC,
ECC,
yep,
okay
and
then
the
other.
You
know
just
for
the
dynamic
action.
When
a
sender
says,
ok,
I
want
to
have
the
following
amount
of
traffic
to
the
following
set
of
receivers.
G
For
example,
it
would
get
exactly
what
I
said
to
the
last
slide:
a
set
of
fit
sets
back
for
every
receiver
and
he
could
even
individually
add
and
remove
the
receivers
within
those
bandwidth,
contract
constraints
and
paths.
He
got
back
so
that's
kind
of
high-level
the
outline
we
want
to
be
in
the
architecture
so
flexible.
That
different
deployments
can
choose
how
much
they
want
to
rely
on
a
controller
versus
the
IGP
to
do
things
right,
so
the
opposite
of
having
a
controller.
Do
this
could
be
done
through
the
IGP?
G
Having
the
sender
know
the
path
but
I
think
the
solution
to
do
bandwidth.
Management
in
that
case
is
something
we
haven't
done,
I
think
in
the
ITF
at
all
right
now.
Well,
of
course,
we
have
the
good
older,
see
SPF
on
the
ingress
LS
ours,
but
we
all
know
what
the
problems
of
coordination
are
in
that
one.
So
that's
why
I
think
that,
especially
for
the
dynamic
allocation
of
the
bandwidth,
the
PCE
controller
is
going
to
be
the
most
likely
preferred
first
stage
for
that
now,
I
haven't
gotten
a
lot
more
slides
about
the
this.
G
That's
really
something
to
be
worked
out
from
this
part,
but
I
would
like
to
maybe
walk
you
a
little
bit
through
the
topology
model,
which
would
be
used
for
the
configuration
of
the
network,
because
that's
the
first
thing
I'd
worked
out
because
that's
something
that
we
most
likely
need
to
rely
on
for
anything
we're
doing
within
the
controller
enough
to
calculate
path,
and
that's
also
something
that
would
go
into
the
IGP
would
be
used
by
the
PC
ECC
for
provisioning
or
in
the
yang
model
of
provisioning.
So
we
also
skip
here
the
the
beard
equivalent.
G
So
this
is
basically
the
the
overview
of
how
I
feel
the
topology
would
be
good
to
be
handled
right.
So
in
the
first
place,
the
topology
is
every
individual
node
in
the
network
has
a
basically
topology
definition
that
really
defines
the
local
adjacencies
right
for
every
bit
that
is
adjacent
to
this
node.
G
G
The
superset
of
all
these
forms,
the
overall
beard
to
e
network
topology,
because
you
can
now
build
yourself
in
a
PC
controller
representation
of
the
topology
know
how
it
maps
to
the
underlying
network
topology
right
either
it's
exactly
the
physical
hops
or
it's
some
tunnel
through
the
underlying
topology
and
therefore
do
calculations
in
the
PCE
controller
about
you
know
the
bandwidth
available
that
you
have
on
the
virtual
topology
by
deriving
it
from
the
underlying
topology
that
you're
doing
it
across.
So
the
forwarding
table
is
really.
G
You
know
the
stripping
just
all
the
possible
metadata
that
you
want
to
add
to
the
topology
to
create
additional
functions,
for
example,
consistency,
checks
and
the
ability
to
automatically
turn
off
bits
in
the
topology.
Don't
use
them
for
forwarding,
because
you
recognize
they're,
inconsistent
or
even
you
know
in
the
non-pc
ECC
case
automatically
configuring
some
consistence,
some
some
adjacencies
right,
but
in
the
end
the
forwarding
cable
is
exactly
the
same,
except
for
not
having
metadata,
and
here
this
this
is
basically
if
the
ingress
router,
of
course,
has
the
full
network
topology.
G
It
could
do
the
same
thing
as
the
PC
controller
calculating
path,
but
of
course
it
doesn't
have
typically
the
they
aware,
nosov
the
bandwidth
in
the
network.
So
the
other
part
was
really
saying
that
we
have
two
instances
of
the
topology.
One
is
what
is
configured
or
what
let's
say
the
PC
ECC
determines
and
then,
when
you
bring
it
down
into
the
network,
each
network
device
may
figure
out.
Oh
okay,
there
is
inconsistency
here
and
there
is
a
subset
then
of
what
is
being
configured
that
is
going
to
be
actually
operational
right.
G
So
that's
basically
the
two
instances
that
you
want
to
look
into
and
obviously
for
for
path
calculations.
You
want
to
use
the
operational
topology,
so
that's
basically
for
us
also
a
question:
what
is
the
local
decision-making
in
a
network
device
from
what's
being
configured
/?
What's
operational,
or
do
we
also
want
to
stage
in
the
PC
ECC
case?
G
The
operation
topology
make
the
decision
of
that
on
the
PC
controller
itself,
so
that
well,
the
network
device
becomes
a
full
slave
of
the
PC
ECC
and
basically
doesn't
do
any
local
decisions
right,
but
very
clearly
the
path
calculation
must
be
from
what
we
call
the
operational
topology.
That's
actually
what
the
bits
are
being
forwarded
in
right
so-
and
here
is
kind
of
the
abstract
away
to
the
to
define
this.
That
needs
to
be
converted
into
one
of
the
definition
languages.
We
have
a
for
that.
G
Our
roof
was
telling
me
one
of
these
things
that
we
use
that's
different
from
yang,
but
basically
this
is
just
very
high-level
abstract
right,
so
they
are
two-bit,
then
a
tunnel
bit
on
the
receiver
side.
There
is
a
bit
to
basically
say
here.
This
is
for
your
receiver.
This
is
for
traffic
in
the
following
BRF
and
then
here
and
I.
G
Don't
want
the
core
of
defining
the
topology
into
the
different
bits
that
you
have
and
then
maybe
attributed
them
with
metadata
to
provide
the
logic
kind
of
a
little
bit
intent
information
so
that
different
systems
like
a
monitoring
system,
a
graphical
display
system
they
can
from
the
topology,
learn
how
to
represent
it.
How
to
Auto
configure
so
they're
a
bunch
of,
and
that's
in
the
t's
document.
That's
a
bunch
of
I
think
very
helpful,
logical,
metadata
associated
with
the
actual
adjacencies
right.
G
So
this
was
the
example
of
how
to
reduce
the
amount
of
bits
by,
for
example,
having
here
a
bunch
of
nodes
in
the
network,
and
you
really
don't
care
about
replicating
in
this
area,
you're
just
interested
to
select
in
your
pair
some
pairs.
That
goes
from
here
to
explicitly
one
of
these
five
nodes
and
then
from
there
on
into
it
exactly
one
of
these
three
nodes,
and
so
the
midpoints
are
just
unicast
it
through
or
with
tunnels.
G
So
that
was
basically
the
way
on
how
we're
getting
I
think
very
likely
to
overlay
topologies
when
we're
talking
about
be
R
to
e,
so
that
beauty
really
is
a
bunch
of
replication
points,
you're
interested
to
have
bits
for
so
you
can
replicate
through
them
and
the
rest
is
a
bunch
of
you
know,
segments
routing
path
through
the
network
pop
by
hub
right.
So
that's
basically
I
think
already
where
I
was
going
to
so
and
I
think
this
was
obviously
coming
from
questions
to
tease.
G
So
the
request
reply
model
would
really
be
what
I
was
mentioning
with
the
bit
string
set.
You
have
on
the
ingress
router
the
need
for
a
particular
traffic
to
have
certain
amount
of
QoS
guarantees.
You
obviously
would
want
to
send
the
typical
RPC
request
for
these
resources
now,
with
a
set
of
receivers.
I'm,
not
even
sure
if
we
have,
for
example,
the
model
for
let's
say
rsvp-te
point-to-multipoint
if
it
goes
through
a
PC
CC
for
a
point-to-multipoint
I,
think
that
same
request
would
be
used.
Just
the
return.
G
Data
model
would
not
be
an
arrow,
but
just
for
every
receiver,
a
set
of
bits
right.
So
it
could
be
as
easy
as
adopting
and
extending
that
core.
You
know
maybe
possible
first
thing
to
do
with
the
PCC
right,
and
that
was
what
I
was
saying
right.
Local
decision
on
controller
very
easy
fits
into
the
existing
model.
Local
decision
on
BFI
are
well
yeah.
Everything
can
be
done
if
anybody
is
interested.
Please
jump
up.
I
think
this.
Is
there
the
wrong
working
group
for
that
option?
G
Right
so
would
love
to
see
that
we
can
start
discussing
this
right.
So
as
far
as
beer
is
concerned,
we
do
have
virtue
as
a
working
group
document,
but
now
in
February
the
working
group
was
recharged
in
before
it
was
kind
of
experimental,
and
the
working
group
could
do
everything
by
itself,
including
extensions
to
IGP
and
everything
and
now
being
a
standard.
G
A
Comments
for
Taurus,
you
are
well
ahead
of
time
by
the
way.
Yeah,
that's
good
I
mean
thank
you
for
bringing
this
to
our
attention.
I.
Think,
though
it
does
look
like
there
is
some
some
good
overlap,
both
in
terms
of
the
area
of
Technology
and
also
some
of
the
specific
things
that
we
have
developed
for
multicast
already
in
PTA.
I
think
you
definitely
would
be
interesting
for
for
us,
and
you
know,
particularly
the
people.
Who've
worked
on
multicast
in
here
before
now,
to
take
a
closer
look
at
the
the
BIA
te
architecture.
A
C
H
H
So
basically
our
section
two,
we
had
some
context
explain
this
traps
relationship
with
other
drafts,
and
we
added
one
measure
ppthe
for
I'll,
be
able
to
indicate
a
bi-directional
core
out
at
LSP
in
SR
key
object.
I
think
this
was
triggered
by
Adrian
to
suggest,
based
on
some
compensation
in
the
OPC
a
list,
and
then
we
added
modification
for
route
exclusion,
replace
a
pls
PID
to
a
symbolic
pass
name
to
the
emotional
general.
H
To
the
to
the
dependencies,
and
basically
our
this
document
is
built
on
RFC,
a
231
and
pizza
for
gmpls,
so
I
think
a
pizza
for
Jane
fellows
really
need
to
move
after
ship
weddings
comment
and
in
staple
PC.
We
have
a
to
LSP
operation
on
its
active,
stable
PC.
The
other
one
is
passive
or
stable
PC
for
the
active
one.
You
see,
you
know:
PC,
update
messages
sent
from
PC
to
PC
C,
to
update
alerts,
B
and
passive
on
wheels
or
PC
reply,
request
message
to
a
converters
computation
instruction.
H
H
So
I
think
you
know
we
want
to
really
close
on
this
draft
as
well,
but
we
still
have
dependency,
as
I
said
before
are
still
as
gentle.
As
extension,
a
one
spacer
for
stateless
to
in
policy
is
updated.
We
believe
that
the
draft
will
be
stable.
There
are
some
minor
editorial
and
some
issues
that
we
need
to
tell
to
it,
but
don't
you
like
to
push
toward
for
the
which,
towards
the
working
group
last
call.
A
Thank
you.
So,
as
we
get
ready
to
deliver
working
group
last
call
on
this
draft,
it
would
be
really
good
to
see
some
reviews
on
the
list.
If
people
haven't
read
it
yet
and
I
encourage
you
to
go,
read
this
draft.
If
you
have
an
interest
in
gmpls
and
letters
have
any
comments,
because
if
we
need
to
make
changes,
now
is
the
time
to
do
that,
and
then
you
know
hopefully
we'll
you
last
call
on
this.
As
soon
as
we
come.
Okay.
B
I
am
true,
I'll
be
presenting
updates
on
various
piece
of
association
rods
and
we
have
a
bunch
of
them.
This
is
basically
some
of
the
key
ones
that
we
have
listed.
What
you
see
in
the
middle
is
the
our
base
Association
group
draft,
which
has
passed
the
our
working
group
last
call.
We
got
some
comments
from
Adrian
and
Sorrell.
Thank
you
for
that.
So
we
have
made
an
update
based
on
that
as
well,
and
we
hope
the
document
will
see
some
progress.
B
I
will
discuss
those
updates
as
well,
so
that
the
working
group
is
aware
of
those
changes
as
well.
We
have
two
working
group
drafts,
the
diversity
draft
and
the
policy
draft
I
will
give
a
quick
update
on
that,
and
then
we
have
a
bunch
of
still
drafts
which
are
not
yet
adopted.
We
discussed
in
the
last
meeting
the
protection
draft
and
in
at
that
time
we
did
a
informal
poll
of
the
working
group
as
well
and
I
think
there
is
interest,
so
we
we
hope
to
see
this
work
getting
adopted.
B
Apart
from
that,
we
have
a
V,
an
association.
We
have
a
bidirectional
which
rakesh
presented
in
the
last
meeting
and
we
also
have
the
resource
sharing
that
Hyman
high
Buuren
has
been
taken
care
of,
and
apart
from
this
as
well,
there
are
a
bunch
of
other
Association
documents.
So
this
topic
is
quite
important
for
the
working
group
because
they
are
a
bunch
of
documents
coming
in
in
this
area.
So,
let's
start
with
the
base
document,
so
we
got
again.
Thank
you
for
the
comments
that
we
got.
What
are
the
changes
that
we
did?
B
We
tried
to
clarify
the
role
of
what's
the
role
of
Association
source.
How
do
we
make
sure
that,
once
when
an
association
group
is
really
unique
and
just
to
add
more
clarity,
we
created
terms
like
what
is
an
association
parameter
and
what
is
in
Association
information?
This
is
not
a
technical
change,
just
the
editorial
change
to
really
clean
up
the
document
and
try
to
make
sure
that
the
readers
are
aware
of
what
we
are
talking
about.
B
So
association
parameters
are
the
key
information,
association,
ID,
Association
source,
Association
type,
etc,
and
then
Association
information
is
the
extra
tlvs
that
we
carry,
which
is
dependent
on
each
of
the
different
Association
types
that
are
discarded
are
created
in
some
other
documents.
So
by
using
this
terminology,
we
have
tried
to
clean
up
the
document
a
little
bit.
B
Also
what
we
did
was
based
on
the
comments
we
clarified,
the
relationship
to
the
RSVP
Association
object
and
also
when
the
aspec
is
is
used
versus
when
Association
is
useful
and
as
it's
pretty
clear
that
there
is
a
difference,
but
it's
better
to
document
that
as
it
was
suggested.
We
also
allowed
the
Association
object
in
a
reply
message,
so
that
if
there
is
a
no
path
possible,
if
no
path
is
found,
the
PC
can
indicate
that
it's
because
of
this
association
and
along
with
the
no
path
object,
you
can
carry.
B
The
Association
object
as
well
to
clearly
state
that
that's
the
reason
for
path
failure.
Some
error
handling
also
got
clarified
and
we
also
added
an
example
how
the
operator
configured
Association
range
will
be
set
just
to
give
a
very
clear
idea
of
how
to
use
this
value.
So
this
is
a
quick
update
on
the
base
drop
and
we
hope
to
see
this
document
go
to
the
next
step,
which
will
be
maybe
the
chef
but
review.
B
Now,
let's
talk
about
the
working
group
documents
and
we
made
updates
to
both
of
them
before
this
idea.
The
main
of
changes
were
earlier.
We
used
to
have
one
TLV.
We
made
two
tlvs
one
disjoint
configuration,
which
is
what
is
being
requested
and
a
disjointness
status,
which
says
what
the
pc
actually
sets
up.
So
this
gives
a
very
clear
information.
The
format
of
the
tlvs
is
exactly
the
same.
It's
only
two
TLB
types
to
clearly
save
when
it
is
when
the
bits
represent
configuration
and
when
the
bits
represent
the
actual
status.
B
We
also
added
the
disjoint
objective
functions
we
earlier
in
the
document.
We
were
referring
this
from
an
another
document,
but
that
another
document
some
of
the
content
we
have
now
merged
into
the
this
document
itself,
so
that
it
can
go.
This
is
the
main
reason
to
add
those
objective
functions,
so
it's
better.
It's
carried
within
the
Association
diversity
itself.
B
We
also
have
a
new,
a
new
draft
which
helps
how
to
relax
some
of
the
constraints,
so
that
requirement
actually
came
from
this
document
and
instead
of
solving
this
as
a
part
of
this
document,
we
have
put
it
as
a
generic
idea,
and
this
discussion
happened
on
the
mailing
list
as
well
aware
this
idea
were
generated.
So
now
we
have
removed
that
information
from
this
drop
and
anyway
we
will
discuss
how
to
relax
constraints
further
down
in
the
agenda.
Stephan
will
take
care
of
that.
We
also
clarified
the
relationship
to
aspect
now.
B
This
is
the
right
document
to
really
talk
about
it,
because
that's
where
we
are
talking
about
diversity.
So
in
the
base
document,
we
just
put
a
reference
that
the
further
discussion
about
aspect
is
happening
in
this
document,
and
here
we
clarified
when
aspect
would
be
used
and
when
Association
would
be
used
and
what,
if
both
exist,
then
how
the
PC
should
behave
that
is
PC
should
try
to
find
parts
meeting
both
the
constraints,
both.
What
is
being
said
by
the
aspect
which
identifies
the
requests
coming
in
in
this
path.
B
B
We
discussed
this
in
the
last
time
when
we
presented
that
this
was
one
of
the
pending
items
for
us
to
add
a
policy
parameters
TLV,
because
when
we
allow
policy
policy
usually
comes
with
some
parameters
that
needs
to
be
considered
when
we
are
applying
the
policy,
so
we
added
this
opaque
container
within
the
PCF
protocol
to
carry
this
information
and
the
order,
the
meaning
the
format.
All
of
this
is
not
part
of
the
protocol.
It's
needs
to
be
set
on.
B
The
two
participating
piece
appear:
out-of-band
in
the
same
way
how
policy
is
set
out
of,
and
we
we
just
carry
a
policy
ID,
basically
in
form
of
an
association
group
ID.
But
what
does
that
policy
means
is
not
carried
inside
the
piece
of
protocol.
Similarly,
what
are
the
parameters
that
are
used
for?
This
policy
is
not
carried
within
the
PCF
protocol.
We
just
give
an
opaque
container
to
easily
carry
this
information,
but
we
need
to
make
sure
that
they
are
appropriate
error
handling
cases,
since
we
are
allowing
it
to
be
carried
in
our
our
protocol.
B
So
those
are
the
things
that
we
have
done
in
this
document.
So
that's
the
only
update
with
policy
now
I'll
move
to
the
changes
in
the
in
the
non
working
group
document
and
let's
starts
with
pod
protection.
This
was
discussed
in
the
last
meeting.
So
what
is
this
job?
It's
basically
create
an
association
between
working
and
protection
LSP.
B
In
fact,
this
was
the
one
of
the
first
Association
type
that
was
clearly
described,
and
this
in
fact
gave
the
idea
that
maybe
we
should
have
a
generic
Association
object
rather
than
coming
up
with
a
mechanism
for
each
different
type
of
Association.
So
this
has
in
fact
this
same
timeline
as
the
the
base
Association
base
Association.
The
recent
changes
we
talked
about
how
the
disjoint
Association,
which
talks
about
how
you
do
diversity.
B
What
is
the
diversity
requirement
between
the
protection
and
the
working
LSP,
so
that
needs
to
be
carried
in
a
disjoint
Association,
and
this
is
about
marking
what
is
which
is
a
working
LSP
and
we
no
protection
LSB.
So
this
needs
to
work
well
with
both
the
Association
types,
so
that
has
been
clarified
and
basically
other
editorial
changes
to
do,
link
it
with
what
are
the
recent
changes
that
we
did
in
the
Association
group
document?
So
that's
why
we
made
this
update.
So
basically
we
feel
that
this
ID
is
quite
stable.
B
B
So
this
is
just
a
listing
of
some
of
the
other
Association
drafts
and
what
is
their
status
so
the
first
one
was
in
the
AC
TM
context:
try
to
link
a
bunch
of
LSPs
that
belong
to
the
same
virtual
network
and
it
has
a
V
and
Association
which
also
identify
for
which
VN
this
LS
fees
were
created,
and
some
of
this
information
is
captured
in
our
via
a
CDN
applicability
document
etc
as
well.
So
this
dot
one
is
about
that.
No
major
change,
only
alignment
with
the
rest
of
the
changes
that
has
happened.
B
Then
we
have
some
of
the
documents
that
I'm
not
involved
but
I'm
just
listing
them
with
the
help
of
the
author's
so
that
it's
the
working
group
is
aware
of
where
there
are
that
one
is
bi-directional
which
Rakesh
presented
in
the
last
meetings
and
it's
pretty
stable,
no
big
change,
it's
already
aligned
to
the
Association
draft
and
the
changes
that
we
have
done
in
the
past.
We
have
resource
sharing
that
weren't
presented
last
time.
B
He
made
an
update,
try
to
clarify
the
relationship
between
when
and
I
are,
o
XR
o
is
used
and
when
you
would
use
resource
sharing.
Also,
of
course,
the
sharing
and
disjointness
is
two
different
things.
So
it's
also
clarified
that
part.
Clearly
that
when
is
this
association
used
versus
there
is
no
sharing
one.
Apart
from
that,
we
also
have
some
other
association
documents.
One
talks
about
explicit
make
before
break.
This
has
not
been
discussed
since
long.
It
was
earlier
published
without
Association,
so
authors
once
the
association
draft
has
been
updated.
B
Instead
of
defining
new
tlvs
and
new
mechanisms
they
adopted
to
the
Association
group,
so
they
they
are
already
on
the
right
track.
Then
we
had
ecmp
and
multi-layer
and
those
have
not
been
updated
since
the
last
time.
So
this
is
just
a
list
of
everything.
That's
been
happening
within
the
Association
space
in
BC
working
group,
so
next
step
I.
Think
Association
group
based
draft
is
anyway
on
the
right
track.
It's
anyway
moving.
Hopefully
we
will
see
it
published
soon.
We
have
working
group
IDs.
B
There
have
been
changes
as
you
as
I
just
mentioned
in
the
in
the
recent
one.
So
we
would
really
appreciate
more
reviews
as
well
as
start
the
process
of
moving
them
towards
working
group.
Last
call
once
our
association
based
draw
gets
ready.
Then,
within
the
other
documents
we
would
really
want
to
see
the
protection
association
getting
adopted.
I
think
there
is
enough
support
for
that.
B
It's
just
a
matter
of
getting
it
done,
and
then
we
decide
the
order
of
importance
of
what's
being
implemented,
versus,
what's
being
useful,
etc
for
the
rest
of
the
documents
that
we
see
and
decide
the
order
in
which
we
want
to
progress
this.
So
that's
just
a
suggestion
from
my
side
and
off
to
chairs
and
the
working
group.
A
Thanks
Chris:
let's
stay
on
the
slide,
so
so
update
from
me.
I
think
the
Association
group
draft,
having
passed
last
call
needs
a
shepherding,
so
I
think
I'm
in
rotation.
Next
to
do
the
shepherding
I
look
at
that.
It's
ready!
I
agree:
it's
ready
to
move
on
once
we
get
that
moved.
Then
we
look
at
the
last
call
for
the
vehicle
working
group
IDs,
as
you
say
so,
I
don't
see
any
any
anything
blocking.
Those
obviously
more
reviews
are
always
got
the
more
reviews,
the
better
the
easier
it
is
to
Shepherd
a
draft.
A
If
you
can
point
to
reviews
and
say
I
people
have
looked
at
this.
Rather
you
know
it's
just
been
written
and
shipped
adoption.
I
think
I
have
to
apologize
for
the
protection
association
draft.
That's
America
fallen
down
the
cracks
since
the
last
meeting,
but
we
should
have
pulled
that
for
adoption
already
up
and
we
agreed
to
do
that
so.
D
A
That
as
soon
as
possible
after
this
meeting
and
then
yes
I
should
say
for
the
others,
I
think
there's
a
process
of
working
out
the
order,
I
think
I
think.
Actually,
the
question
has
already
been
asked
for
at
least
two
of
these
on
the
the
page.
In
terms
of
what
interest
there
is
I
think
we
we
saw
decent
interest
in
the
binder
and
the
resource
sharing.
I.
Don't
remember
asking
the
question
about
the
N
Association
I'm,
not
sure.
A
If
now
is
the
right
time
to
do
that,
but
this
isn't
really
a
I
think
we
actually
have
plenty
of
things
of
a
queue
already,
but
yeah
I'm
happy
to
discuss
with
you
and
the
other
authors.
What
the
right
order
for
asking
these
questions
would
be.
If
there's
any
dependencies
between
these
drafts,
it
would
be
good
to
know
that
otherwise
I
think
I
just
take
them
in
the
order
they
arrive.
A
Does
anyone
have
any
questions?
Dhruv
comments
on
any
of
these
drafts
observations
about
this
work
in
general
I
mean
I
think
this
is
generally
a
key
piece
of
protocol
for
peace
app.
You
know
the
concept
of
associating
paths
was
fairly
loosely
defined
and
this
really
formalized
as
that
and
as
soon
as
we
formalized
that
we
find
we
actually
have
loads
of
different
applications
for
it,
and
so
we
have
loads
of
different
drafts,
making
use
of
it.
A
But
just
underlines
the
importance
of
getting
my
base
association
group
draft
absolutely
bang-on,
because
we
have
a
lot
of
work
coming
on
top
of
it
which
which
relies
on
it.
We
don't
really
need
to
publish
that
and
then
fighter.
Actually
we
need
to
do
a
change
to
it.
You
know
in
a
year's
time
that
would
be
pretty
painful
to
do
so.
A
I
B
Be
talking
about
stateful
HPC,
so
just
a
quick
recap:
this
is
basically
a
marriage
between
HPC
framework,
which
was
been
there
and
the
stateful
PC,
basically
righty
of
stateful
PC.
So
you
have
a
parent,
PC
and
child
PC
who
are
both
stateful.
Then
what
will
be
the
interaction
between
them?
How
the
message
exchange
that
already
exists
between
PC
and
PC
works
seamlessly
between
child
PC
and
parent
PC.
So
this
is
basically
an
informational
document.
We
don't
have
any
extensions
here.
We
just
kind
of
note
down
clearly
how
these
interactions
are
happening.
B
How
the
report
message
is
the
big
message
initiate
message
that
already
exists:
works
between
parents,
parents,
staple
PC,
as
well
as
the
child
PC,
and
we
also
talked
about
end
to
end
LSPs,
because
anyway,
that's
has
always
been
the
key,
but
in
in
the
context
of
a
CTN,
the
domain
LSP
and
setting
up
of
LSP
is
in
each
domain
and
somehow
linking
them
and
stitching
them
to
form
n,
2
and
LSP.
That's
also
being
described
in
this
document,
the
actual
stitching.
B
B
Since
then,
we
have
made
sure
that
the
document
is
well
aligned,
as
our
other
RFC's
got
published
and
whatever
the
changes
that
were
made
there
during
publications
are
reflected
here.
We
clarified
the
scope
because
and
clearly
said
that
we
support
both
end-to-end
LSP
as
well
as
per
domain
LSP,
and
whether
we
are
setting
up
into
an
rsvp-te
thing
or
whether
we
are
doing
per
domain,
though
this
this
framework
works
for
both.
B
We
also
added
a
details
regarding
how
to
use
the
existing
path,
key
mechanism
to
make
sure
that
the
confidentiality
is
taken
care,
as
which
is
already
there
in
other
messages,
like
request,
apply,
but
how?
What
role
they
play
in
the
report
initiate
an
update
message
as
well
and
idea
being
that,
whether
we
have
ero
how
we
can
hide
them
using
the
pathway
object.
So
that's
been
described
as
a
consideration
in
the
document,
because
that's
something
we
need
to
worry
about,
since
in
the
context
of
into
domain
things,
so
basically
the
documents
has
been
stable.
B
D
B
Also
have
this
document,
which
is
our
basic,
stateless
HPC,
so
until
we
kind
of
publish
this
moving
directly
to
stateful,
HPC
would
not
make
sense.
So
we
need
to
work
this
document
as
well.
I'm,
not
an
author
of
this
document,
but
we
kind
of
worked
with
authors
to
make
the
changes
and
so
that
both
of
them
can
be
progressed
quickly.
So,
basically,
what
is
this
document
based
on
our
RFC
66
805,
which
describes
the
HPC
framework?
B
This
document
provides
in
extensions,
describes
what
changes
needs
to
be
made
to
piece
up,
focusing
on
the
request
and
reply
messages
in
in
scope
for
HPC.
If
just
a
reminder
that
there
was
a
discussion
on
the
mailing
list
and
a
request
made
that
this
work,
though
it
was
experimental
in
the
past,
we
moved
it
to
standards
track
after
confirmation
on
the
mailing
list,
so
which
is
very
well
appreciated,
and
there
was
a
one
pending
item,
which
was
the
domain
diversity
thing,
which
was
there
in
an
other
individual
drought.
B
So
we
kind
of
Club
this
in
into
the
HPC
context,
because
that's
where
it's
useful,
so
a
new
flag
in
s
Beck,
which
kind
of
marks
that,
apart
from
nordlingen
SR
algae,
we
also
are
looking
for
domain
diversity
and
similarly,
an
OS
code
that
maximized
the
domain
diversity.
So
those
are
the
this
is
the
only
big
technical
change
and
this
update,
apart
from
that,
the
content
has
been
remain
the
same.
But
since
this
document
has
not
been
discussed,
just
wanted
to
give
a
quick
recap.
What
are
the
basic
extensions
that
this
document
actually
talks
about?
B
You
need
capability
advertisements
talking
about
whose
parent,
whose
child,
what
what
role
they
are
playing.
That's
during
the
piece
of
open
message,
exchanges,
Utah.
We
have
extension,
which
talks
which
carries
which
domain
a
particular
child
PC,
is
serving
in
form
of
a
domain.
Id
TLV
carried
in
an
open
message.
That's
the
that's
the
one
that
you
are
seeing
here,
then
a
flag
in
an
RP
object
that
says
that
this
request
is
HPC
request.
If
you
may
remember,
there
are
similar
flags
for
VSP
T
used
in
B
RPC,
so
this
is
used
for
HPC.
B
So
a
new
flag
for
that
the
Oh,
F
courts
and
SFX
Lacs
is
the
changes
that
I
just
talked
about.
There
were
some
Oh
F
quotes
which
were
already
existing,
so
we
just
added
one
new,
but
there
are
other
other
Oh
F
coats
which
were
already
defined.
There
were
metric
types
which
were
defined
in
this
document
errors
and
no
paths,
so
new
error
codes
and
no
path
conditions
that
Y
path
was
not
fun.
B
Some
new
code
points
for
that
and
it
has
an
implementation
status,
and
so
this
document
has
been
there
from
within
the
working
group
for
a
while
I
think
it's
stable
here
as
well.
Implementation
exists
and
I
think,
as
it
was
already
pointed
out
in
the
in
the
chair
status,
that
this
document
should
be
moved.
So
if
you
have
not
looked
at
this
document
in
a
while,
please
do
that
and
hopefully
these
two
documents
can
be
moved
together
and
they
are
the
basis
of
a
lot
of
other
work
within
the
working
group
as
well.
A
Thanks
true,
it's
good
to
see
that
the
base
HPC
extensions
is
revived
and
that
you
know
if
some
work
has
been
done
to
you
know,
fix
for
the
pending
action
item
in
that
draft
now
I
see
is
revived.
I
think
it
was
already
in
the
queue
for
last
call.
We
were
just
waiting
for
a
live
draft.
Now
we've
got
one,
so
we
can
last
call
that
you're
absolutely
right
that
we
can't
really
move
to
last
call
the
this
day
for
version
until
we've
until
we've
got
through
there.
A
I
won't
suggest
we
merge
the
drafts
at
this
point.
I
think
we
should
keep
the
way
they
are,
but
it's
but
like.
Let's
do
them
in
that
order
and
I
want
to
make
sure
we
flush
out
any
comments
or
concerns
from
the
iesg
on
on
the
base
HPC
draft
before
we
try
and
do
anything
with
the
staple
version
yeah.
Alright
any
comments
or
questions
from
the
room
you're
required
today.
H
This
is
again
sorry
that
I
got
there
too
often
this
is
applicability
or
PCE
for
a
CTN.
H
Basically,
it
is
kind
of
entity
and
architecture
reference
architecture.
You
know
some
of
you
have
seen
many
times,
I
like
to
just
highlight
that
in
T's
working
group
entity
and
requirement
and
framework
and
info
model.
Now
all
of
them
have,
as
the
working
group
last
current
now
is
in
the
publication
request
stage.
H
H
So
that's
basically
I
sit
here
and
pizza
how
they
are
similar
in
AC,
T
and
M.
Dhcp
NC
relationship
is
equivalent
to
parent
EC
and
charity.
C
and
hierarchy
of
controllers,
basically
addressed
by
HPC
and
tunnel
instantiation
by
controllers.
It
actually
PC
initiated
methods
by
PCE
and
MDS.
A
multi
domain
coordination,
stateful
HPC,
so
we
have
quiet
resemblance
in
may,
not
be
the
same,
but
definitely
PC
can
be
applicable
for
implementing
a
CT
n.
H
H
So
if
we
want
to
build
topology
at
MDRC
or
parent
pc,
yeah
there's
unless
a
report
message
that
can
carry
that
information
from
bottom
up
to
be
able
for
the
parent
ECE
be
able
to
construct
topology
and
the
VN
instantiation
is
actually
what
a
parent
is.
He
can
use
pc,
initiate
message
to
instantiate
a
multi
domain.
D
H
So
basically,
the
point
is
that
this
document
is
useful
to
understand
how
PCE
architecture
and
pizza
extensions
come
together
to
implement
a
CTN
and
ICT
and
framework
is
now
in
RF
RFC
request
stage.
So
I
don't
think
we
have
much
dependency
on
other
document,
because
this
is
just
informational
to
describe
our
pisser
can
be
applied
and
all
those
component
of
pizza
is
in
place
already
so
we'd
like
to
ask
if
this
working
group
and
if
this
document
can
move
to
next
stage.
A
A
We
can
talk
about
where
it
goes
in
the
queue
I
think
that
there
are
a
few
things,
maybe
coming
first,
but
we
definitely
see
that
this
is
probably
ready
to
go
forward
Thanks
and
by
the
way,
if
anyone
is
interested
in
shepherding
this
truck
than
by
all
means.
Tell
me
afterwards
be
grateful
for
the
help
on
that.
A
J
So
I'm
Stephan
from
a
range
so
drew
already
introduced
it
this
document,
when
talking
about
the
Association
diversity.
When
we
were
walking
about
on
this
association
diversity
draft,
we
had
a
requirement
of
being
able
to
relax
with
diversity
constraints
in
case
there
is
no
possibility
to
find
some
Dijon
pass
and
when
we
just
absolutely
want
to
other
paths,
so
we
came
with
a
solution
after
some
discussion
on
the
main
image.
This
is
the
solution
that
is
quite
generic,
so
it
can
work
really
the
Association
object
or
whatever
constraints
that
we
have
annoyed
in
Pisa.
J
J
Yeah,
the
idea
is
to
reuse
a
mechanism
which
already
exists
in
the
stateless
PC
implementation,
so
we
RFC
54:40,
which
is
based
on
the
P
and
I
flag.
So
we
have
P
flag,
which
can
tell
that
a
particular
object
is
optional
or
not,
and
we
have
the
AI
flag,
which
is
able
to
tell
that
the
a
particular
object
has
been
ignored
during
the
path
computation
on
the
in
the
stateful
PC
RFC.
J
J
So
one
example,
so
we
have
the
one
with
the
diversity
when
we
want
to
relax
a
particular
Association
object,
so
we
can
set
the
P
flag
or
unset
the
PFLAG
to
said
that
to
say
that
it
is
optional
and
we
set
it
to
say
that
it
is
mandatory.
We
can
also
do
it,
for
example,
for
other
objects
like
the
metric
object.
If
we
want
to,
for
example,
computer
path
which
is
based
on
the
delay
metric,
we
can
also
want
to
relax
this
constraint
if
we
are
not
able
to
to
find
the
path
without
the
boundary.
J
Solve
the
extension
in
order
to
be
able
to
reintroduce
both
flags
in
the
state
whole
PC,
we
are
proposing
to
introduce
a
new
capability
just
to
ensure
that
we
are
backward
compatible
with
the
existing
stateful
pci
RAC.
So
the
idea
is
to
have
a
capability
will
tell
about
more
about
this
later
and
then
we
are
defining
out.
We
are
ending
the
P&ID
flags
in
the
different
messages.
J
So
what
is
this
capability?
So
we
are
just
adding
a
new
bit
in
the
state
for
a
PC
capability
glv,
which
we
can
call
the
relaxed
bit
and
if
both
and
setting
the
relaxed
bit,
we
can
use
the
new
procedures
to
get
the
benefit
ins
of
the
P&I
flags.
And
if
someone
is
not
setting
via
relaxed
bit,
we
are
falling
back
to
the
existing
procedures,
which
are
to
ignore
the
P&ID
flags.
J
So
in
terms
of
processing
room,
it's
quite
simple.
So,
regarding
the
PFLAG
in
the
pc
report,
we
can
use
it
to
tell
the
PC
that
the
particular
object
is
optional
or
mandatory
in
the
path
computation
and
when
using
it.
In
the
PC,
update
and
PC
initiate
message
we
can
modify
or
tell
the
TCC
that
a
particular
object
must
be
used
during
the
path,
the
path
setup.
J
We
ignore
flag,
it's
a
bit
similar,
so
when,
for
example,
a
PCC
is
setting
an
object
as
optional
using
the
PFLAG,
the
PC
can
reply
with
a
PC
update
with
a
flight
with
a
particular
path
that
has
been
computed
telling
with
the
I
flag
that
this
particular
object
has
been
taken
into
account
or
if
it
has
been
ignored.
So
we
know
the
PCC
will
know
if
a
particular
object
has
been
used
in
the
pair
computation
or
not.
J
J
So,
by
reintroducing
the
P&I
flag
for
the
state
full
PC,
we
are
also
able
to
enter
unknown
object.
So
today,
if
an
object
is
not
supported
by
the
PC,
we
may
have
a
new
PC
or
that
that
will
be
sent.
Now
we
can
tell
that
a
particular
object
is
optional,
so
we
can
compute
a
path
without
taking
every
subject
into
into
account.
J
So
this
is
our
proposal
to
be
able
to
relax
some
constraints
in
the
case
of
stateful
PC.
So
the
question
is:
is
it
the
right
approach
to
use?
Is
it
also
a
good
problem
to
solve,
based
on
the
description
that
we
are
on
the
mailing
list?
It
seems
that
this
was
a
problem
that
needs
to
be
solved.
That,
then,
is
it
the
right
approach
to
use.
K
And
what's
running
through
my
head
is
whether
you
end
up
needing
to
trade
options
in
a
much
more
flexible
and
therefore
horrible
way.
You
know
you
can
write,
you
can
rank
them,
you
can
you
can
give
each
option
a
boolean,
but
then
you
start
to
say
what
these
two
go
against
this
one.
This
one's
slightly
higher
priority
at
this
percentage
and
and
I
agree.
K
A
Are
we
done
sounds
like
it?
Yeah
I
agree
with
you
and
Adrienne.
This
is
a
problem
we
need
to
solve.
I
personally,
think
that
this
approach
is
fine
for
me,
I
agree,
but
in
time
there
may
need
to
be
more
flexibility,
but
for
now
I
don't
see
an
immediate
need
for
that.
So
you
know
this
speaking
is
not
as
the
chair
of
this
look,
but
just
as
an
individual.
It
seems
like
the
right
duration
to
take.
A
J
A
D
John
from
duty,
my
presentation
is
about
the
PSAP
extensions
for
as
RTP
let
works
and
there
as
RTP
networks
is.
The
reason
for
the
requirement
is
that
the
insulin
working
group
from
way
who
has
described
the
draft
about
the
spring
as
segment
routine,
the
a
trusted
name,
is
a
spring
as
the
RTP
use
cases.
D
It
describes
the
use
case
of
segmented
routine
Turner
to
be
destroyed
in
amperes
transport
profile.
So
we
there
s
are
defined
as
RTP
networks.
It
means
the
segmented
routine
technology
in
MPLS
TP.
Let
work
so
based
under
as
RTP
use
cases.
My
document,
if
on
a
general
mechanism
to
create
under
bidirectional
as
our
turner
in
SRTP
lat
works
with
PC,
and
we
propose
a
set
of
extensions
to
be
set
for
SRTP.
Lat
works
lectures,
look
at
their
authority
scenario
with
the
PC.
D
Just
as
everyone
know,
the
pizza
has
and
as
our
a
segmented,
routine
extensions
with
derpy
staff
protocol,
but
the
our
network
is
different
with
SRTP
andr
most.
The
most
important
difference
is
the
SRTP
it's
from
the
MP
RTP
and
you're
it
it's
required
to
create
an
fie
directional
LSP.
D
So
we
define
the
two
scenario
use
case
with
PC.
The
first
one
is
the
cold
duty.
The
bidirectional
SRTP
SOP
Esther
figures
show
the
PCE
will
a
leisure,
the
bi-directional
Astarte
PSP
from
a
waster
PCE
initial
message.
We
can
see
the
PC.
We
all
send
PC
leisure
message
to
the
ingress
and
egress
separately
and
to
Elisha
SRTP
else.
Srt
PSP,
the
in
the
SR,
lateral
interest,
RTP
network,
the
from
A
to
E
and
H,
or
a
tester
forward
direction
under
the
PC
may
assign
her
aside.
D
The
list
like
from
A
to
B,
to
C
to
D
to
e
under
the
cited
list,
is
the
PCT
e
is
the
fourth
direction
and
the
reverse
direction
is
from
the
same
path,
but
is
the
reverse
and
mr.
e
t
C
B
a
and
the
SI
t
lists
a
30
CPA
touch
the
tooth
Direction,
no
Elsa
P.
We
lead
our
past
label
to
bank
and
there
too,
directional
pass
and
the
solution
was
defined
in
green
were
a
working
group
and
today
it
is
called
the
past
segment.
D
They
say,
stir
call
a
rooty
the
bi-directional
SRTP
approach
progress.
Let
us
look
at
the
associative
by
directional
SRTP
LSP
and
the
figure
is
similar
with
the
before.
There
are
not
one,
but
it
is
different.
The
forward
direction
is
the
same,
but
the
reversed.
The
direction
path
is
different.
With
forward
direction
matter,
sico
show
the
fall
direction.
D
D
This
is
this.
Are
this
pure
scenario
is
other
this
case
with
the
PC
in
SRTP
networks,
so
the
pistas
extensions
is
lead
for
the
bi-directional.
The
first
one
is
the
bi-directional
XP
and
third
extension
has
pre
has
been
presented
by
young
Lee.
Just
now,
the
leafless
of
the
SRP
object
lead
to
defined
to
indicate
a
bidirectional
SP
operation
in
the
occur
due
to
the
by
rapid,
bi-directional
SP.
So
the
last
one
we
define
a
SRTP
er,
all
extension.
D
As
we
know,
segment
routing
extension
has
been
defined
in
a
signal
routing
pick
up
extension
to
threat,
but
we
define
another
bidirectional
turner,
because
the
SR
extension
is
just
in
the
elite
directional
scenario,
so
for
bi-directional
Turner
will
lead
to
define
the
bi-directional
terminal
information
in
the
ER.
Oh,
so
we
extend
SR
year
old
to
you
nectar
we
go
show
their
st.
We
extend
the
a
society
type,
an
ad
or
a
psyche,
type
to
indicate
the
type
of
information
associated
with
their
past
label.
D
D
E
D
K
I
D
H
D
K
Lsps
is
all
about
so
yeah.
There's
I
understand
a
marketing
reason
for
calling
it
SRTP,
but
let's
try
to
not
confuse
ourselves
here
with
what
we're
doing
and
then
I
want
to
ask
in
the
general
case.
Does
the
tunnel
in
both
directions
have
to
be
identical
technology?
To
your
use
case
you
have
s
are
one
way
s
are
back
again:
yeah
Colby's
draft
has
got
MPLS
swapping
one
way,
an
MPLS
swapping
the
other
way.
Now.
Could
we
have
a
an
employee,
less
environment,
where
we
go
sr
one
way
and
come
back
on
a.
J
K
B
I
can
agree
with
what
Adrienne
was
saying
and
the
idea
being.
We
already
have
the
s
bi
directional
Association.
You
have
sr
ero,
even
the
extensions
that
are
proposed
here.
It's
not
really
clear
of
what
the
what's
the
benefit
of
that
and
it
isn't
this
already
possible
by
what
we
already
have
if
we
have
an
SR
ero
which
carries
the
path
and
you
can
associate
it
in
bi-directional
way-
carrying
this
path
label
as
a
new
SR
ero
sub-object.
B
L
L
L
D
Think
the
requirement
may
be
longer
list
to
craft
a
stream
MPs
path
segments,
because
the
segmented
routine
has
is
the
newly
direction
and
in
MPs
TP
way
lead
s
are
the
Phi
direction
is
our
so
the
the
SR
is
is
a
unique
direction
or
and
under
the
s.
Id
list
is
the
one
direction,
but
we
lead
to
founder
to
direction
and
there's
the
graph
to
define
a
path
label,
chip
and
the
direction.
So
the
past
label
is
Li.
It
is
required
in
the
segment
a
routine
network
as
well.
D
M
Network
architecture,
using
our
controller,
not
the
heat,
pads,
computation
elements
and
your
computation
computation
element
and
the
kissing
entities
is
a
cooperation
here,
maybe
introduce
a
lot
of
difficulties,
well,
implementation
to
the
real
network.
What
do
you
think
about,
and
so
what's
the
difference
between
your
computer,
implement
this
architecture
or
PPE
be
able
architecture?
What's
a
reference
enter?
What
are
the
other
one
hit
you
send
is
a
lotta
juice.
Thank
you.
E
It's
too
fun,
mostly
when
you
I,
don't
know
what
your
application
that
this
is,
but
mostly
when
you're
running
MPLS,
T
thing
you're
running
a
pseudo
are
over
MPLS
T
carry
a
little
something
like
that,
in
which
case
the
suitor
white
label
gives
you
a
perfectly
by
way
of
binding.
The
two
halves
together.
D
A
Think
I
think
what
people
are
wondering
about
mostly
here
is
why
why
the
requirement
of
the
additional
path
label,
and
why
do
we?
Why
do
we
need
to
add
that
when
we
already
have
the
s
rero
telling
us
the
path
end
to
end
and
and
it's
after
so
it's
not
quite
clear
to
me,
it
would
be
a
good
idea
of
a
draft
decks.
We
kind
of
explained
that
specific
point
about
why
that
is
needed.
E
Because
you've
lost
we
labels
by
the
time
this
thing
has
got
to
the
destination,
because
this
is
SR
right.
So
normally
you
could
tell
from
the
LSP
label
what
the
LSP
was
or
from
the
pseudo
Isle
a
blip.
Is
there
what
the
context
was
if
they're
just
doing
it
with
SL
they've
lost
that,
so
they
do
need
something,
but
quite
at
the
time,
the
pseudo
why
they
I
was.
F
Hello,
everyone.
This
is
a
an
update
of
a
draft
that
we
presented
a
couple
of
IETF
meetings
ago
with
a
good
content
about
wrong
message.
So
we
decided
to
fine-tune
a
little
bit.
Let's
start
with
with
the
ricotta,
since
you
you've
not
heard
about
it.
For
a
while
RSC
55:41
define
an
objective
function
that
is
really
useful,
which
is
maximum
residual
bandwidth
for
paths.
F
The
proposal
is
to
define
two
new
metrics
to
be
used
in
a
piece
of
pottery
surveyed
bandwidth
at
a
given
priority,
so
adding
priority
to
the
reservable
bandwidth,
not
the
physical
one
and
the
path
residual
bandwidth
which
will
be
returned
as
result
of
the
party
competition.
The
first
one
is
the
minimum
value
of
the
eraser
and,
with
at
death,
at
a
given
priority.
Among
all
the
links
along
the
path
you
will
need
to
read,
the
digit,
2
or
3
times
had
to
understand
what
it
means.
F
The
second
one
is
the
minimum
value
of
the
free
physical
bandwidth
among
all
the
links
in
in
the
path.
So
why
defining
these
two
new
things?
First
of
all,
because
T
matrix
R
can
be
returned
as
a
result
of
the
path.
Computation
and
answer
can
be
used
to
know
how
much
traffic
can
be
still
routed
over
that
path.
That
was
just
computed
and
in
addition
to
that,
it
allows
optimizing,
a
path
against
the
are
reserved
it
or
residual
bandit
and
last
but
not
least,
trying
to
prevent
bottlenecks
in
the
network.
F
So
changes
between
the
first
version
and
this
one
as
I
said,
the
focus
was,
was
moved.
This
was
presented
as
something
that
was
sort
of
mandatory
in
hierarchical
PC
scenarios
and
so
on.
They
the
goal,
is
now
not
to
mandate
this
anymore,
in
fact,
that
this
is
defined
as
in
applicability
scenario
as
a
use
case,
where
potentially,
these
extensions
can
be,
can
be
used.
F
Again,
the
focused
is
more
is
moved
from
a
logical
path,
computation
to
the
definition
of
a
new
met.
New
matrix
and
particular
two
sections
have
been
updated.
We
added
a
section
called
the
mode
of
operations
which
describes
how
these
metrics
are
used
within
the
metric
object
and
procedures
are
defined
as
Wella.
Well,
the
only
meaningful
thing
that
the
section
says
is
that
no
changes
to
procedures
and
use
cases,
a
new
action
on
use
cases
is
described
with
applicability
to
a
CDN
and
Iraqi
capital
computation
changes
to
the
protocol.
This
is
very
long
and
boring.
F
F
They
are
expressed
in
a
bytes
per
second
and
actually
define
the
four
four
PS
TSE
technologies.
So
in
case
this
is
something
that
is
useful
and
there
is
the
willingness
to
extend
this
to
layer,
0
layer,
1
alarm
that
diiemma
whatever
it's
it's
very
simple
to
extend
it.
The
priority
is,
is
not
encoded
in
the
in
the
in
the
object,
but
it's
inherited
from
the
palace.
Ta
object,
Samiha
next
steps
so
with
the
new
modification.
It
is
something
very
simple
and
the
no
dependence
is
at
all
on
any
other
object
or
extensions.
F
A
Okay,
yeah
four
or
five
four
and
a
half
okay,
so
I
I'm
happier
with
the
new
presentation
of
the
requirement.
I
think
it
makes
more
sense
to
me
as
a
reader
I
think,
there's
there's
some
my
looks
like
mild
interest,
but
interest
is
there
to
work
on
this
I
guess
I'd
be
interested
to
to
confirm
that
on
the
list
and
see
whether
you
know
there
is
interest
in
taking
this
further
forward,
but
yeah
I
think
the
technical
requirement
makes
more
sense
now,
I
think
it's
clearer.
So.
D
I
So
this
is
the
the
the
second
front
will
present
a
operating
for
our
consideration.
The
PGP
equation
for
native
IP
network.
I
So
here
I
just
give
a
quick
look
for
local
bank
for
a
background
of
the
peace
education.
So
we
held
kill
the
scenario
and
the
solution
for
the
traffic
engineering
unit
white
network
and
the
drug
had
been
adopted
that
he's
working
his
WJ
document.
So
currently
we
have
seen
without
the
help
of
the
PCs
new
controller.
I
Firstly,
the
the
beauty
and
different
VDP
says
a
dynamic
land
directly,
the
secondly,
the
popular
tip
when
the
prefix
so
video
popular
some,
for
example,
pieces
and
pull
tow
to
populate
the
normal
normal
traffic
terrific's-
and
you
know
another
BGP
session
and
to
transfer
the
different
traffic
prefix
as
I.
Sorry,
the
video
manual
purely
to
the
Past
will
be
next
Hawk
to
the
on-demand
based
on
our
networks,
the
Oct
Orissa,
so,
basically
only
requirement.
There
are
three
object.
It
would
be
transferred
here,
I
list,
the
video
notifying
the
PCB
object.
I
So
grant
to
the
defendant:
PDP
object
away.
They
also
sync
the
how
to
Treasuries
object.
There
are
two
abroad
to
approach
approach.
It
is
similar
with
the
LSP
innocent
liquid
and
equation.
Similarly,
the
PC
and
it's
the
LSP,
so
we
do
think
Gregory.
The
objectivity
and
LSP
in
is
the
request
message,
the.
Secondly,
the
verify
my
new
CD
are
related
until
the
quest
message.
So
if
we
select
the
approach
grant
will
finish
this
work.
The
process
will
be
very
similar
with
that
the
procedure
defined
in
RFC
82
80
81.
I
So
considering
implementation
of
what
is
the
object,
we
think
every
user
there.
We
did
not
focus
on
mainly
the
newly
defined
objectivity,
not
considered
the
procedure,
but
you
create
and
define
the
selected
or
protocol.
We
define
the
new
currency,
new
concept,
a
new
procedure,
but
maybe
multi-disc
increased
with
ll
control.
A
opinion
is
the
RSP.
I
Currently
we
are
preferred
to
select
approach
ba
and
I
single
disc
in
select
a
compete,
the
escalator
with
with
device
vendor
for
the
implementation,
so
so
here
I
just
want
to
it
in
our
to
otherwise
GG
adopt
and
you,
if
so,
under,
which
overture
which
publisher
our
approach
and
to
treasure
a
newly
defined
object
is
better.
So
we
can
discuss
the
online
or
offline
okay.
A
Okay,
so,
first
of
all,
if
anyone
has
any
comments
and
then
please
go
to
the
mic
No,
so
I
think
this
is
the
second
time
that
I
John
has
presented.
This
is
that
right,
I
was
young
second
time,
and
so
the
first
time
this
was
presented.
We
had
a
discussion
about
the
overall
problem
that
was
being
solved
here.
This
is
effectively
an
application
of
PCA,
which
is
a
little
bit
outside
of
what
it's
been
used
for
previously.
This
seems
now
to
be
more
towards
using
PCE
to
take
to
decisions
in
an
IP
only
network.
A
So
we
asked
about
time
that
the
work
we
discussed
also
in
T's
from
an
architectural
standpoint,
I
think
that
the
t's
has
been
discussing
this
and
I
see
some
work
adopted
in
T's
now
to
progress
that
architecture.
So
so
thank
you,
for
we
got
instruction
and
taking
by
the
way
to
the
tea,
so
I
think
that
the
time
now
is
right
to
ask
in
PCE
whether
we
we
want
to
consider
taking
this
protocol
work
on
so
I.
A
Think
I'll
probably
want
to
ask
a
few
questions
here
of
the
audience.
The
first
question
is:
who
here
is
aware
of
this
work
already
and
is
aware
of
a
work?
That's
been
done
in
teas
around
this.
This
space
who's
actually
been
following
this
in
tease
anyone
in
this
room
yeah
all
right,
so
this
may
be
10
people,
so
goodbye
gives
me
some
confidence
of
people
are
paying
attention
to
this
problem.
The
next
question
is.
A
A
A
A
So
the
less
the
last
thought
is
me
and
I
want
to
give
an
update
on
what
we
learned
from
the
the
piece
of
SDN
discussion.
If
you
remember,
last
year
around
about
after
the
summer,
I
started
the
thread
on
the
PC
mailing
list
to
ask
about
basically
the
the
overall
scope
of
the
working
group.
The
the
context
of
this
was
that
increasingly
in
PCE,
people
are
bringing
more
work
into
the
working
group
which
take
PCE
away.
There's
a
protocol
away
from
its
original
purpose
of
sort
of
client-server.
A
There
was
a
sense
to
which
I
was
worrying
about
mission
creep
here
and
I
wanted
to
get
some
sort
of
confirmation
and
explicit
discussion
about
that.
This
is
the
direction
that
we
are
consciously
going
in
and
how
far
do
we
go,
so
I
want
to
share
what
I've
learned
and
then
I
want
to
sort
of
take
stock
of
where
that
leads
to
various
proposals
that
the
people
have
brought
to
the
working
group,
so
I
think
what
we
learned
from
them
and
thank
you.
A
Everyone
who
engaged
but
I
had
a
real,
real
good
feeling
from
the
the
responses
that
I
got
back.
People
really
engage
with
the
question,
I
think
I
think
we
did
manage
to
conclude
several
things,
although
it
was
a
fairly
long
but
open-ended
discussion,
we
did
conclude
that
fairly.
Obviously,
using
P
sub
for
Sdn,
like
function
is
reasonable,
is
happening
and
has
actually
already
happened.
I
think
we
can't
say
that
this
is
outside
the
scope
of
a
working
group
when
actually
for
the
years
we've
been
working
on
this,
so
so
it
was.
A
It
was
a
fairly
obvious
conclusion
when
we're
going
to
come
to,
but
anyway
at
least
explicitly
made
it
that
that
is.
That
is
what
we
should
be
doing
in
terms
of
what
people's
goals
are
for
this
type
of
extensions
of
the
protocol.
The
goals
really
I
think
are
that
I
heard
were
to
offer
an
alternative
to
other
southbound
protocols
in
banette
work
like
an
alternative
for
a
controller
to
problem
at
work
out
a
program,
Network
elements
versus
Netcom
or
open
flow
in
some
environments.
A
Pcf
is
a
way
that
people
want
to
do
that
and
that's
and
that's,
what's
really
being
motivating
the
these
extensions.
What
it's
not
trying
to
do
is
replace
anyone's
control
plane,
there's
no
sense
in
which
we're
saying
throw
away
the
control,
plane,
image
issues
PCE.
What
we're
all
we're
really
saying
is
it's
an
alternative
to
the
SPI
protocols,
so
I
think
those
things
became
clear.
As
the
discussion
went
on.
A
What
is
happening
well,
if,
both
before
during
and
after
that
discussion,
some
Sdn
features
have
already
been
adopted,
published
even
so,
the
staple
PCE
is
clearly
the
thing
which
we've
started
all
this
us
now,
an
RSC
PCE
initiated
LSP,
is
also
now
an
RFC.
We
have
drafts
in
various
stages
the
the
LSP
control
request
draft,
which
we
adopted
into
the
working
group
one
ITF
ago,
pc
flow
spec,
which
we've
only
just
adopted
into
the
working
group.
The
pc
ECC
work
going
on
in
t's.
So
this
is
all
going
ahead.
A
There
was
disagreement
quite
a
large
disagreement
on
the
scope
of
how
far
we
take
the
Sdn
features
and
and
there
obviously,
the
the
main
bone
of
contention
was
piece
of
LS
and
whether
that
is
something
that
is
good
for
the
working
group
or
not.
There
were
several
passionate
arguments
on
either
side,
but
I
think
that
the
situation
for
that
remains
unclear,
so
I
think
we
have
to
tackle
that
head-on.
Really
it's
the
next
step
of
this
discussion.
A
A
I
think
that
one
possible
way
forward
would
be
most
just
Paul
for
adoption
and
see
if
people
support
it,
but
I'm
pretty
certain
that
if
I
did
that,
then
we
just
hear
the
same
arguments
but
I've
already
heard
and
I'll
still
be
just
as
confused
about
whether
there
is
consensus
or
not
I,
don't
think
that
would
represent
progress.
I
do
think
we
need
to
finish
the
debate
on
those
open
points
about
P
sub
LS.
A
It
seems
to
me
that
there's
a
disconnect
that
there's
a
proponents
of
saying
you
know
we
need
this
there's
operational
requirement.
We
absolutely
have
to
have
it
and
then
the
people
are
against
it,
saying
just
the
opposite.
Actually,
there
is
no
requirement,
we
don't
need
it
so
I
want
us
to
finish
our
debate
and
I
want
to
understand
personally,
where
the
disconnect
is
coming
here.
I
want
to
put
some
new
energy
into
that.
A
People
point
out.
There
are
at
least
three
other
ways
of
getting
link
states
of
a
controller
IG
PBG,
pls
Netcom.
We
know
this
I,
don't
think
this
yet
being
a
convincing
demonstration
that
there's
a
real
operational
context
in
which
none
of
those
methods
can
be
used
and
that
PCE
has
to
be
used
instead
and
I.
Think
that's
really
the
main
thing
where
they're
still
disconnect.
A
A
A
We
do
have
an
RFC
now
for
experimental
code
points.
Does
that
solve
a
problem?
I
think
that's
a
question.
We
should
ask
as
well
and
then
finally
kind
of
on
a
more
technical
side.
I
think
Jeff
tonzura,
raised
here
today
that
we
haven't
really
demonstrated
PC
has
the
right,
scalability
properties
for
this
type
of
application
of
his
concern
was
BGP
LS,
there's,
not
an
BGP,
which
is
shown
to
scale
to
large
volumes
of
data
is
PC
the
right
vehicle
for
that
type
of
data.
Also,
we
had
a
similar
discussion
about
the
auto
bandwidth.
A
A
For
whatever
time
we
have
left
I'm
interested
in
feedback
now
and
then
feedback
on
the
list,
it's
not
a
fair
summary
of
where
we've
got
to
or
not.
If
not,
please
come
and
give
me
feedback.
Can
we
this
debate
now?
Can
we
progress
it
on
the
list?
Is
there
more
information
that
we
can
share
in
order
to.
K
A
K
A
N
So
the
first
one
I
I
I
to
some
extent
I,
don't
have
to
read
that
so
there's
a
matter
of
choice
for
macro
choice.
We
were
regarded
the
PDP
P
17
states,
because
the
first,
the
the
IDP
was
an
exchange
and
we
wanted
to
use
the
IDP.
We
may
be
the
controller
under
the
device,
so
they
are
smoky
hob.
We
want
to
use
the
IDP.
We
have
to
set
up
a
tunnel
to
direct
the
connect
either
the
controller
under
the
device
yeah.
A
N
The
second,
a
usual
Netcom
I
sing
of
the
Netcom,
would
have
done
the
same.
For
you,
sir.
The
the
performance
of
the
other
note
is
just
not
a
good
enough
to
satisfy
the
requirement
complete
a
comparative.
We
will
be
reinstated.
Itp
under
the
p17
state,
so
I
think
that
we
regarded
this.
One
I
think
that
the
only
the
the
the
candidate
we
will
Ricardo,
we
will
be
regarded
the
g17
state.
You
have
a
trust
that
he
keeps
in
a
state.
That's
my
in
my
point,
under
the
secondary
is
before
the
market
vendor.
N
N
E
A
Yeah
I've
heard
that
operators
are
scared
of
BGP
and
I
know.
Bgp
scared
that
BG
pls
is
not
quite
a
full
BGP
stack,
I,
think
to
ship
state
from
the
device
up
to
a
controller
on
bt.
Pls
doesn't
mean
that
you
need
to
have
the
full-blown
BGP
policy
engine
it
doesn't.
Maybe
you
have
to
have
a
Paquette,
a
mash
of
bgp,
no
to
configure
them
the
monitored
in
your
network.
It's
it's
kind
of
simpler
than
that.
A
You
can
actually
do
it
with
a
fairly
small
module
of
code,
because
all
you're
really
doing
is
shipping
data
up
to
a
to
a
server
but
I
understand
the
saying
BGP
to
an
operator
can
provoke
a
a
reaction
that
you
did
not
intend.
Yep
okay
I
mean
if
you
keep
it
to
a
minute.
Please,
because
we're
absolutely.
C
Calm,
you
know
probably
think
of
her
summarizing
the
list.
I
think
it
covers
the
most
awful
technical
point,
but
to
me
actually
I
understand
that
there
are
some
similar
approaches
to
do
the
same
thing,
but
I'm
wondering
whether
a
number
of
other
ways
would
be
a
affecting
whether
we
leave
this
technical
or
not.
C
Personally,
I
think
people
all
agree
that
there
is
a
functionality
required
for
path
computation
and
we
will
use
the
PC
to
do
this,
but
actually
they
are
so
weak.
Wrestling
state
actually
is
a
kind
of
preparation
on
all
contracts
with
the
database
and
the
Enders
might
make
the
PCB
prepare
to
to
compute
the
path
correctly.
So
absolutely
is
that
proposal
of
PC
PRS
is
not
trying
to
replacing
an
existing
technologies,
but
so
we
just
don't
want
to
probe
for
keep
an
option
that
we
can't
leave.
We
can
do
this
kind
of
stuff,
you
know
and.
E
C
Means
that
PC
need
to
work
together
with
other
kind
of
protocols
in
the
literature
together
to
complete
the
whole
selves,
and
actually,
although
we
have
another
Guardian,
she
can
work
in
groups
talking
about
how
the
different
protocol
works
with
each
other
for
different
specific
scenarios
on,
for
example,
the
power
connection
connection
and
the
service
provisioning,
but
I
believe
PCP.
Is
that
mainly
an
important
piece
of
this?
The
whole
network.
H
You
know,
PGP
LS
is
out
of
the
question
and
you
know
we
don't
implement
that
and
then
I'm
not
sure
any
other
optical
vendor
implement,
pls
and
I
did
regarding
our
eyes
appear.
I
think
it's
ever
less.
What
it
does
is,
instead
of
sending
to
the
neighbor
it's
a
sent
to
the
northbound,
so
it
doesn't
change
much
encoding,
just
a
much
faster
way.
If
you
have
a
lot
of
linker
node
conversions
time
and
a
lot
of
optical
data
being
added,
so
there
might
be
some
actually
there's
a
study
on
that
for
the
logical
networks.
L
Just
I'm
neutral
to
this,
while
I
don't
have
any
opinion
one
way
or
the
other,
but
one
can
argue
and
I
guess.
Maybe
that
is
what
he
was
saying.
Is
that
if
you
already
have
a
PC,
PC
P
type
connection
right,
why
I
need
to
have
a
passive
listening
on
IGP
or
have
a
bgp
another
thing
implemented
on
that
right?
You
can
suck
that
information
right
using
the
pizza
palace
so
that
that
could
be
in
favor
of
that.
A
Okay,
I
think
we'll
thank
you
for
the
feedback
so
far,
we'll
continue
it
on
the
list.
As
I
say,
we
need
to
put
renewed
energy
into
that
discussion
and
try
to
conclude
it
one
way
or
the
other.
So
thanks
for
the
input
and
if
I
was
also
the
last
being
for
the
working
group,
so
we
will
see
you
next
time.