►
From YouTube: IETF114 PCE 20220727 1730
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
first
of
all,
people
on
site
are
supposed
to
wear
masks.
So
I'm
the
the
picture
this
too
far
to
to
check
if
everyone
is
doing
it,
but
I
guess
harry
can
have
a
look
at
that
and
there
are
some
available
at
the
registration
desk.
If
I
understood
correctly,
if
you
need
one
so
please
try
to
follow
that
people
for
safety
of
everyone-
okay,
so
usual
not
well.
This
is
an
etf
meeting.
There
are
rules
about
ipr
you're
supposed
to
follow.
B
A
A
You
read
them
okay,
so
there
are
many
people
remote
again
this
time.
So
the
tool
that
we're
using
to
share
remote
session
is
a
new
version
of
mythical
there's,
a
new
mythical
client
that
may
help
people
on
site,
but
for
most
people
remote.
I
think
the
heavy
mythical
client
is
still
the
the
one
to
use
make
sure
your
audio
is
off.
When
you
aren't
supposed
to
talk
to
avoid
glitches,
we
have
a
queueing
rule.
There
there's
a
single
queue
that
mixes
both
the.
A
A
So
the
usual
links,
so
if
you
want
to
go
over
the
agenda
and
other
useful
information
there
in
the
slide
deck
usual
kind
of
conduct
within
the
etf,
I
hope
everyone
is
familiar
with
them,
nothing
new
there,
but
make
sure
that
you
are
familiar
with
them,
so
travel
now,
our
remote
again.
A
John
already
is
already
there
in
case
of
a
strong
issue
for
the
session
on
site,
so
harry
on
top
of
being
on
site
will
be
in
charge
of
taking
notes.
So,
if
you
want
to
give
him
a
hand,
there
is
the
link
here
to
the
notes,
ietf.org
feel
free
to
add
your
own
notes,
especially
in
case
of
mix
up
with
names
or
if
something
you
may
have
set
on
the
mic,
isn't
properly
noted
in
the
minutes.
A
A
We
know
that,
following
the
values,
lockdowns
travel
constraints,
the
involvement
in
some
work
in
the
etf
is
not
the
same
as
before,
but
working
group
still
needs
some
involvement
to
make
sure
the
work
progresses
efficiently.
So
please
try
to
evoke
as
much
as
possible,
especially
at
adoption
polls.
Working
glass
call
document
reviews.
The
ietf
working
group
documents
need
some
people
to
be
involved
all
along
the
process,
so
make
sure
that
when
you're
involved
or
interested
in
some
topic,
you
voice
your
opinion
contribute
on
even
if
it's
more
remotely
than
it
used
to
be.
A
For
some
of
us,
it's
still
very
important
to
make
proper
use
of
the
mailing
list
on
get
involved
into
the
threads
on
the
mailing
list.
There
is
the
new
delete
tool
for
the
the
chat,
so
it's
turned
out
to
the
medical
chat
there
onto
the
former
jabber
service.
So
far.
If
you
want
to
join
using
the
client,
it's
another
way
to
to
chat
with
the
working
group.
A
A
A
Working
group
status:
okay:
there
is
no
newer
test
in
the
the
last
ietf
meeting,
but
the
walking
route
has
been
producing
some
document
anyway.
One
of
them
has
been
in
the
rfc
editor
queue
for
a
while
and
is
waiting
for
a
reference
to
another
document.
A
A
A
A
A
A
We
have
several
documents
that
have
been
following
this
process
to
get
early
code
points
for
early
implementations,
so
we
have
those
four
already
identified
within
the
ayanna
virtue
for
the
required
cut
points.
Some
were
already
renewed,
depending
on
the
progress
of
the
document
within
the
working
good
process.
D
D
So
first
we
have
a
document
that
we
have
recently
done.
A
working
group
last
call
on
that
is
the
local
protection
enforcement.
Currently
it
is
waiting
for
shepard
review
it's
in
julian's
hand,
so
you
should
be
expecting
the
review
of
this
pretty
soon
and
then
we
will
be
sending
it
out
to
our
ap
piece
up.
Yet
we
have
a
recent
update.
This
update
handles
the
second
yang
doctor
review
that
was
done
for
this
document
as
a
part
of
yang
doctor's
review.
D
There
was
a
comment
on
bicep
mip
that,
since
we
borrow
a
lot
of
elements
from
psep
map,
it
would
be
good
to
have
a
clear
relationship.
So
we
have
added
an
apple
x
where
we
have
relationship
between
the
pset
gang
and
a
psep
mip,
so
which
would
be
quite
useful.
D
Some
groupings
which
were
used
only
once
were
collapsed
and
since
we
had
completed
work
on
stateful
gmpls,
we
also
added
stateful
gm
plus
capability
into
the
yang
model,
and
some
examples
were
updated
and
with
the
help
of
a
tool
they
were
validated
as
well.
So
at
this
stage
this
document
is
quite
ready
for
working
group.
Last
call
we
can
see
all
the
dependencies
on
the
right
hand,
side
as
well
and
even
the
dependency
that
we
were
worried
about,
which
was
itf,
tls,
client
and
server.
D
D
The
next
one
is
our
srv6
document.
It
underwent
two
updates.
There
is
already
an
ina
allocation
which
is
done,
be
enhanced.
The
authors
enhanced
the
security
consideration
section
and
mainly
all
other
changes
were
editorial,
and
since
we
were,
we
already
have
one
document
in
rfc
editor
queue
which
is
waiting
for
this.
We
should
prioritize
this
and
last
call
this
and
send
it
out
of
the
working
group
pretty
soon.
D
So,
if
anybody
has
any
comments,
doubts
like
you
know,
please
feel
free
to
join
the
queue
and
authors
or
anybody
else
who
has
concerns
on
these
documents.
This
is
your
time
to
use
it.
Otherwise
I
will
continue
with
the
next
document.
D
Some
of
the
documents
which
are
almost
ready
but
did
not
have
much
update
between
the
two
itfs
are
the
native
ip
and
flex
grid.
We
will
be
taking
them
up
soon,
so
if
you
want
to
review
them
and
make
sure
that
they
are
up
to
date,
this
would
be
a
good
time
to
do
that.
D
One
document
which
did
not
see
any
progress,
neither
from
the
chair
side
or
from
the
working
group.
In
the
last
meeting,
we
asked
for
more
feedback
on
what
we
could
do
about
the
enhanced
errors
document.
We
still
have
no
id
which
is
currently
using
it.
We
thought
stateful
interdomain
could
be
won,
but
there
hasn't
been
an
update
on
that
and
we
haven't
received
any
feedback,
but
as
a
working
group,
we
have
to
make
a
decision
on
what
we
are
going
to
do.
With
this
document.
D
We
are
still
listening
so
reach
out
to
us.
If
you
have
an
opinion
on
this.
D
The
other
working
group
ids,
we
have
a
path
segment
with
this
path
segment.
There
has
been
no
change,
but
one
thing
which
I
wanted
to
from
the
chairs
point
of
view
we
wanted
to
highlight
is
currently
this
document
is
listing.
Two
mechanisms
via
it
allows
path
segment
allocation
via
path
segment
tlv.
D
It
also
allows
the
pcc
mechanism
to
allocate
a
path
segment,
so
we
want
to
make
sure
that
that
we
have
the
working
group
backing
that
both
these
mechanisms
should
be
supported
or
do
we
need
to
discuss
and,
like
you
know,
support
only
a
single
one
of
these,
so
this
discussion
has
not
happened
and
we
feel
that
this
document
is
otherwise
ready.
So
this
is
the
only
open
issue
that
we
could
see.
So
if
the
working
group
or
the
authors
have
any
opinion
on
this,
please
come
now
or
use
the
mailing
list
to
discuss
this
further.
D
And
seeing
nobody
jumping
the
queue
I'll
continue.
The
next
one
is
the
bi-directional
sr
path.
It
had
no
change
and
we
feel
this
document
is
quite
ready
for
last
call
as
well.
So
if
anybody
has
any
concerns
or
authors
have
any
opinion,
please
let
us
know,
and
all
this
information
is
also
captured
in
the
wiki.
So
if
you
would
like
to
go
and
update
the
wiki,
please
do
that
it's!
The
wiki
is
for
the
whole
working
group,
not
just
for
the
chairs,
so
please
provide
inputs
in
the
wiki
as
well
as
your
document
is.
E
Can
you
hear
me?
Okay,
yes,
okay,
perfect,
so
no
comments.
Just
thank
you.
Thank
you
for
the
work
we
we
do
really
think
the
segment
and
as
a
bi-directional
past
drafts
are
ready
for
the
working
rascal.
So
thank
you
for
the
work.
D
Yep,
that's
it
cheng.
Regarding
the
question
that
we
have
on
the
just
that
we
have
two
mechanisms,
is
there
any
opinion
of
the
authors
that
yes,
we
need
to
continue
with
the
both
mechanisms
in
the
draft?
That's
the
current.
E
Let's
go
for
both
mechanism
right
now
and
if
someone
propose
some
comments
on
the
main
list,
let's
discuss
it
directly.
D
D
So
next
one
we
have
sr
policy
drafts.
This
one
had
an
update.
This
update
added
I've
made
an
update
in
the
invalidation
tlv
for
traffic
steering
for
a
down
and
an
invalid
lsp.
So
please
review.
If
you
have
any
concerns
with
this
update
with
pcc
sr,
there
was
another
update
and
the
main
technical
change
was.
There
was
text
added
for
any
cast
sid
allocation,
which
was
missing.
D
So
I
think
this
is
a
good
update
that
they
have
done
and
please
review.
D
Regarding
the
multi-path
draft,
there
were
multiple
updates.
Main
updates
were
in
multipath,
opposite
direction,
path,
dlv.
They
also
added
an
implementation
status
section
which
lists
three
existing
implementations,
which
is
very
good
to
know,
and
the
earlier
location
has
also
been
done
for
this
draft.
So
good
progress
is
being
made
in
the
multipath
document.
D
The
other
document
that
we
have
is
the
state
sync
between
the
pce's
two
updates,
adding
implementation
status,
adding
manageability
consideration
and
one
open
issue,
at
least
from
the
chairs
point
of
view-
is.
This
document
has
a
section
on
how
primary
and
secondary
pcs
are
selected,
but-
and
it
is
done
based
on
priority,
but
how
this
priority
is
advertised
is
currently
out
of
scope
of
the
document.
D
So
we
want
to
get
feedback
from
the
working
group
that
whether
it
is
acceptable
that,
yes,
let
that
be
outside
this-
could
be
done
via
configuration
or
yang
and,
like
you
know,
of
course,
in
future
it
can
also
be
done
by
capability
like
advertisement
etc.
But
it's
okay
to
be
out
of
scope
of
the
current
document,
so
we
want
to
hear
inputs
from
folks,
especially
on
that
point.
D
Next
document
we
have
is
optional.
This
is
like
marking
objects
as
optional
to
process
in
case
of
stateful
pc
and
implementation
status
was
added,
but
it
currently
lists
there
are
no
known
implementation.
D
The
stateful
inter
domain
saw
no
change
between
the
last
itf
and
the
sr
p2mp
policy
had
update
and
it
was
on
mainly
editorial
changes
so
far,.
D
And
now
we
are
coming
to
the
I
think
the
final
sets
of
the
document
which
were
kind
of
recently
adopted.
We
had
the
l2
flow
spec.
This
document
was
updated,
they
added
a
manageability
consideration
and
they
are
trying
to
keep
in
sync
with
flow
spec,
v2
work
that
has
been
done
in
idr,
so
that
is
good.
We
have
the
document
for
algorithm,
said
algor
algo.
D
F
Yeah
I
just
wanted
to
comment
the
update
for
cdw
draft.
I
collected
the
feedback
from
multiple
sources
and
there
were
some
conflicting
opinions.
So
basically
I
tried
to
bulk.
The
update
in
you
know
answer
to
so
that's
that's
causing
the
delay
but
as
as
discussed
between
the
authors,
it
we
will
change
the
strategy
and
video
update.
We
will
do
partial
updates
to
at
least
updated
updates
on
the
comments
that
you
have
received
during
the
option
and
and
basically
to
sim
to
make
progress
faster.
D
Perfect
one
suggestion
I
I
would
also
make
is
like
wherever
you
guys
are,
have
not
able
to
make
a
conclusion.
You
can
put
an
editor's
note
in
the
document.
It
would
be
easier
to
track
for
chairs,
as
well
as
other
working
group
members
on
where
the
disagreement
is
and
easy
to
provide
you
inputs
as
well.
D
Thank
you.
Next,
we
have
path
mtu.
This
is
sr
path,
empty
document.
When
we
adopted
this
document,
we
made
a
decision
that
a
companion
document
in
spring
needs
to
be
produced,
and
authors
have
produced
this.
They
presented
this
in
the
spring
session
today
as
well,
and
some
of
the
text
from
the
pcep
document
has
now
moved
to
spring,
and
it
will
now
be
making
progress
in
the
spring
document
as
well.
D
So
thanks
authors
for
tracking
this
and
closing
one
update
that
has
happened
in
the
document
is
there
is
a
section
which
now
updates
rfc
5440,
especially
with
the
handling
of
metric
pound
sp,
because
path
mq
is
little
different.
The
other
metrics
usually
look
for
maximum.
Here
we
have
to
look
for
minimum,
so
some
text
change
had
to
be
done
to
allow
sr
path
mq
to
be
carried
inside
a
metric
object.
So
please
review
this
part
and
provide
comments,
and
the
authors
also
added
a
section
for
multipath,
which
is
pretty
good.
D
The
ifit
document,
which
was,
I
think,
our
latest
document
that
we
have
adopted
it's
also
on
the
agenda,
so
no
point
discussing.
Let's
move
on
to
the
adoption
queue
so
that
option
queue
is
in
the
wiki.
Some
of
the
documents
are
listed
here.
Please
give
feedback
to
the
chairs.
If
you
feel
some
other
documents
needs
to
be
put
up.
D
First,
give
your
reasoning,
and
we
would,
of
course
be
open
to
reshuffling
things
as
and
when
so,
please
be
more
vocal
reach
out
to
us
so
that
we
can
help
make
progress
in
the
working
group
pretty
soon
and
with
this
I
think
this
would
be
the
last
slide
open
mic.
Any
working
group
status
related
things
that
we
want
to
talk
about.
Otherwise,
we'll
move
to
the
first
presentation.
D
F
Hi
old,
I'm
samuel
from
cisco
I'll,
be
presenting
doubt
about
piece
of
extensions
for
circuit
style.
On
behalf
of
outdoors,
it
was
presented
on
last
ipf
as
well
as
well
just
summarize
content
of
this
draft
and
updates,
which
were
done
after
that.
F
Develop
these
extending
pieces
to
satisfy
requirements
of
connection
oriented
transport
services
using
segment
routing
policies
also
called
also
called
circular
style.
As
our
policies,
there
is
second
route
which
was
presented
in
spring
working
group
and
which
was
presented
in
pc
working
group
in
last
itef,
so,
which
is
disturbing.
Those
requirements
like
state
bandwidth,
guarantee
endpoint
protection
by
hope,
behavior
and
how
existing
features
should
be
used.
Existing
features
defined
in
existing
pset,
rfcs
or
drops.
F
This
drought
is
covering
gaps
in
pset
for
two
specific
requirements
from
the
least
which
I
mentioned
more
specifically
path,
persistency,
which
means
also
sticking
to
over
the
computed
part
and
not
modifying
it
in
case
of
various
triggers,
like
topology
updates
or
periodical
optimization
and
this
kind
of
stuff
and
for
buy
hope,
behavior,
which
practically
means
that
computed
pub
will
use
ideas
and
c6.
Only,
although
I
will
describe
details
later.
F
So
do
that
introduce
new
dlv
for
blocking
powder,
computation
or
other
optimization,
based
on
various
triggers
like
pc,
topology
or
periodic
computation,
and
we
have
received
feedback
that
there
is
not
many
use
cases
for
such
grammarity,
so
tlv
was
simplified
by
removing
those
flex.
F
There
is
a
recent
comment
from
peru
to
actually
move
it
back
to
the
lsp
object,
so
maybe
another
discussion
will
be
needed,
but
yeah,
that's
that
will
be
done
after
after
this
rtf
new
flags
were
introduced
to
cover
scenarios
which
are
not
specific
to
circuit
style
policies,
but
which
logically
belongs
to
functionality.
Discovery
in
this
draft
or
b
flag
for
allowing
or
blocking
modification
of
computed
part
if
original
part
is
already
invalidated.
F
So
the
tlv
now
allows
both
options
stick
to
completely
part.
Even
if
path
is
invalid
and
keep
lsp
in
downstate
or
allow
pad
modification
if
lsp
would
be
down.
Second
flag
is
for
controlling
it.
Explicit
explicit
request
request
from
operator
for
updating
parties
allowed.
Here
we
are
talking
about
requests
coming
from
pc
side,
for
example,
some
sale
executed
on
pc
site,
any
normal
interface
request
received
on
pc
site
or
anything
like
that.
F
One
one
more
additional
minor
qualification
was
made
in
the
draft
we
allowed
modification
of
computed
part
if
actual
ads
and
cs
are
not
changed.
So,
for
example,
operator
will
change
manually
assigned
adsense
it
to
different
one
on
same
topology
link.
Then
pc
can
still
compute
the
part
or
basically
update
the
path
to
to
new
seed,
which
is
assigned
to
same
same
increasing
snc.
F
Second
requirement
covered
by
this
graph
is
clarifying
usage
of
existing
gold
flag
in
stabilized
messages
and
introducing
new
flag
for
stateful
pc
messages.
Only
minor
changes
were
done
in
india
since
last
itf.
We
generalized
definition
of
state
path
to
make
it
more
future
proof.
For
example,
for
cases
the
new
city
type
will
be
introduced
and
which,
which
will
not
be
defined
in
this
draft
original
definition,
specified
explicitly
usage
of
ibsense
assets
only
for
state
hopes.
Now
we
are
using
them
only
as
an
example,
and
we
are
quite
qualifying.
G
F
Thanks
for
listening
and
any
comments,
any
questions
are
welcome.
We
are
still
discussing
backward
compatibility,
handling
and
addition
of
new
couple
and
potential
additional
new
capabilities
to
negotiate
support
for
these
features,
and
we
have
also
received
some
feedback
after
publishing
last
version
of
the
draft,
so
new
changes
will
be
coming
soon.
H
Hello,
that's
it
hello!
It's
adrian!
Thank
you
for
presenting
some
just
looking
at
the
recompute
bit
of
this
and
trying
to
understand,
and
I
just
re-skimming
the
draft
it's
applying
to
a
delegated
path.
Yeah.
So
that's
a
path
that's
been
established
in
the
by
the
pcc
and
then
delegated
back
to
the
pce
and
saying
okay,
pce
you're.
Now
the
owner
of
this,
but
you're
not
allowed
to
recompute
a
path
in
that
case,
why
would
you
delegate.
F
So
there
are
multiple
facts,
as
you
can
see
on
this
slide.
There
is,
for
example,
for
slack
which
still
allows
a
pc
to
update
the
part,
but
only
if
operator
explicitly
requesting
it
from
pc
side
and
also
there
is
permanent
flag,
which
basically
means
that
pc
can
still
recompute,
but
it
will
recompute
only
if
original
part
is
invalidated.
F
So
basically,
if
if
but
if
there
is
better
part,
then
pc
will
not
will
not
be
allowed
to
to
send
any
updates
for
the
part.
But
if
pad
is
invalidated
that
it
can
still
update
the
parts
to
basically
fix
it
to
make
sure
that
policy
or
our
speedometer
will
not
be
animated
or
it
will
not
go
down.
H
Right
and-
and
you
have
a
I-
I
suppose
I
could
construct
use
cases,
but
you
you've
got
a
a
use
case
that
is
actually
driving
this
distinction,
for
you.
F
So
I
mean
the
main
use
case,
which
we
originally
tried
to
cover
by
the
computation.
Dle
was
still
keeping
delegation
that
the
pc
can
can
drive
the
drive
apart,
so
it
can
still
peel
down
the
lsp.
It
can
still.
It
can
still,
for
example,
tear
down
one
candidate
part
of
the
policy
if
it
considered
that
that
another
candidate
part
is
better
for
some
reason.
So
the
intention
here
was
just
to
make
sure
that
that
pc
will
not
change
the
part.
D
Next
is
andrew
and
while
andrew
is
walking
in
this
is
the
second
time
this
comment
has
come
in
and
if
you
remember
like,
I
think,
one
of
the
first
time
when
this
was
presented,
the
same
comment
was
made,
that
why
are
we
delegating
when
not
re-optimization?
So
I
think
it's
best
to
add
some
text
in
the
in
the
document
so
that
this
question
key
not
doesn't
keeps
coming
up
andrew,
go
ahead.
I
Yeah,
I
figured
I'd
just
add
a
bit
of
a
concrete
example.
So
you
know
you've
got
your
pc
in
the
network.
You've
got
your
lsps.
You
want
to
establish
them.
You
want
to
establish
primary
secondary,
diverse
paths.
I
However,
under
certain
conditions
like,
for
example,
bandwidth
pc
is
aware
of
the
bandwidth
reservations
in
the
network,
the
local
node
isn't
so
you
might
have
bfd
running
on
the
lsps
everything's
happy,
but
the
pc
can
detect
a
use
case
where
well,
I've
got
you
established
on
a
path.
I've
been
instructed
to
not
move
you
around
because
traffic
fluctuations,
but
I'm
allowed
to
tear
down
so,
for
example,
if
your
primary
path
is
active,
let's
tear
down
the
primary
so
that
we
go
through
the
secondary,
because
the
secondary
slows
enough
capacity.
D
One
thing
which
came
up
during
the
spring
presentation
as
well
was,
I
think
we
need
to
be
a
little
careful
with
what
content
we
are
putting
in
the
spring
document
and
what
is
going
to
be
in
this
current
document
is
focusing
on
extensions,
which
is
very
good,
but
I
think,
even
from
the
spring
document,
things
which
are
very
pcb
specific,
where
we
are
talking
about
how
pcc
delegates
things
to
pce
or
more
piece
of
specific
things,
I
think
could
be
moved
to
this
document,
and
my
suggestion
would
be
to
keep
spring
document
as
general
as
possible
and
if
you
want
to
use
psup
use
it
as
an
example,
but
the
spring
document
should
be
not
specific
to
pce,
so
that
in
future,
if
somebody
wants
to
do
bgp
work
for
this,
it
is
pretty
straightforward
and
the
document
doesn't,
like
you
know,
seem
very
pce
heavy.
D
G
F
We
we
can
discuss
that,
but
basically
even
original
idea
was
to
keep
the
spring
document
or
keep
second
round
as
informational,
which
is
describing
all
the
technologies
with
all
the
features
which
needs
to
be
connected
together
for
the
for
the
cs
policies.
And
then
this
drought
will
basically
cover
any
extensions
which
are
delivered
on
top
of
existing
droughts
or
existing
implementations.
F
Rs
so
yeah
we
can
discuss
that
any
other
separation
would
make
sense,
but
maybe
maybe
even
another
development
would
be
needed
in
such
case
to
basically
split
the
informational
part,
which
is
videos
connecting
all
the
all
the
features
together
and
and
the
extensions
which
are
needed
yeah.
But
we
can.
We
cannot
start
the
discussion
and
we
can.
We
can
try
to
qualify
if
there
are
any
arguments
against
or
or
for
this
specific
approach,
which
was
already
taken.
D
Thank
you
and
one
last
point
which,
which
is,
I
think,
the
continuation
of
discussion
that
we
had
during
the
last
time.
D
Should
we
think
of
defining
some
well-known
path,
profiles
or
well-known
policies
and
then
using
our
policy
framework
as
a
way
to
do
this,
or
should
we
do
separate
tlb
separate
flag
as
currently
being
done
in
this
document?
So
I
just
want
a
working
group
to
think
about
it
and
currently,
I
think
most
of
the
authors
and
the
working
group
likes
what's
there
in
the
draft.
But
I
would
like
us
to
be
cognizant
that
if
this
is
the
direction
that
we
are
taking,
it
might
have
an
impact
for
us
in
future
as
well.
D
I
I
was
just
going
to
mention
something
that
we've
tried
to
do
in
this
document
is
try
to
make
you
know
these
bit
flags
reusable
in
other
use
cases.
So
while
the
document
is
described
as
circuit
style
as
our
policy,
obviously
the
overall
solution
now
has
been
moved
to
spring,
so
I
think
from
the
pce
side.
I
F
C
J
And
here's
some
background
of
the
redundancy
protection
and
redundancy
policy
and
the
redemptive
protection
is
a
generalized
protection
mechanism
that
used
in
the
context
of
the
segment
routine
paradigm
and
as
shown
in
this
figure,
and
it
replicates
the
packets
on
the
redundancy,
node
and
transmits
through
transmit
the
copies
of
the
packets
over
the
multiple
destroying
paths
and
on
the
merging
node
it
transmits
the
first
accurate
and
eliminate
the
redundant
packet
in
overall,
we
have
four.
Currently
we
have
four
drafts
introduced.
J
This
redundancy
protection
mechanism
and
the
first
draft
introduced
the
redundancy
seat
and
redundancies,
redundancy
segment
and
merging
segment
in
the
data
plane
to
specify
the
the
behavior
of
the
replication
and
illumination
and
second,
second
draft
introduced
this
redundancy
policy
in
control
plane
to
instruct
the
multiple
fantasy
forwarding
pass
from
the
controller
to
the
redundancy
node
and
the
third
draft
introduced
the
btp
extensions
to
advertise.
The
redundancy
policy
attribute
and
the
last
one
is
these:
this
disrupted,
the
pcb
extensions.
J
Actually,
it
includes
several
content
and
first
is
the
is
the
request.
First
is
to
request
the
pass
computation
and
the
protection
method
from
pcc
to
pce
and
also
advertise
the
redundancy
policy
attribute
from
pce
to
pcc
in
counterplay.
J
Actually,
it
is
enhanced
by
import
a
new,
a
new
optional
flag
attribute
at
the
candidate
pass
yeah
they
can
to
the
candid
pass
and
we
we
think
it
should
be
applied
for
for
both
sr
mpls
and
srv6.
J
So
I
summarized
the
pcp
extensions
here
first
to
firstly
and
two
new
tlvs
of
the
request
parameters
object
to
support
this,
to
support
the
request
of
the
redundancy
pass,
computation
and
protection
method
and
another
utrv
to
distribute
the
the
flag
attribute
of
the
redundancy
policy
from
pce
to
pcc.
J
And
the
first
sub
tlv
of
these
rp
object
is
called
redundancy
detection,
trv
and
actually
there
are
two
fields
in
this
two
two
fields
in
this
trv.
The
first
is
the
flag
that
we
use
eight
bit
bitmap
to
indicate
the
the
constraint
of
the
past
computation
and
one
flag
is
used
to
indicate
it
is
the
redundancy
computation
requirement
and
the
the
second
is.
J
The
number
is
the
number
two
to
indicate
how
many
redundancy
forwarding
pass
in
pcc
requires,
and
this
message
is-
and
this
tlb
is
carried
from
by
the
the
request
and
respond
to
between
the
between
the
pcc
and
pce.
J
The
second
subtly
is
called
the
protection
type
trv
we
use
to
protect.
We
use
four
bit
value
to
indicate
the
protection
type
of
the
protection
type
of
this
past
computation,
because
the
redundancy
protection-
actually
it
is
a
protection
mechanism.
J
So
we
think,
based
on
the
previous
protection
mechanisms,
we
actually
introduced
a
new
mechanism
for
the
protection,
so
it
might
need
some
some
modification
to
the
to
the
2d
and
to
define
the
protection
type.
So
here
we
introduce
a
new
dlv.
We
I
also
see
the
there
are
there
is
there.
Is
there
are
requirements
there
are?
J
There
are
comments
from
from
to
roofie
on
the
mainly
list
and
to
discuss
that
if
we
need
to
define
a
new
treat
or
we
need
to
do
some
research
to
the
to
to
backwards
compatible
to
the
existing
implementations,
I
think
we
will
discuss
it
among
the
coursers,
but
right
now
we
propose
a
new
tsatri
to
to
enhance
the
protection
type.
J
The
last
tier
we
see
is
this:
it
is
defined.
It
is
encoded
in
the
in
the
sr
policy
association
group.
It
is
called
the
the
the
candidate
pass
flag
tlb
because,
as
we
as
we
just
introduced
in
the
redundancy
policy
to
one
attribute,
one
optional
attribute
flag
is
introduced
to
the
candidate
pass.
J
So
so
in
pcp
that
we
introduce
a
new
kind
of
past
black
trv
to
carry
the
the
the
flag,
the
flag
of
the
of
the
canteen
pass
and
in
the
in
the
in
the
current
design
of
the
redundancy
policy,
only
one
bit
of
the
of
the
flag
is
defined.
J
So
that
is
the
the
redundancy
flag.
So,
and
similarly,
here
that
we
use
one
flag,
one
bit
of
the
flat
to
differ
to
indicate
the
redundancy
flag.
J
So
this
is
a
zero
zero
elevation
of
the
of
the
draft.
So
we
we
are.
We
seek
for
the
discussions
on
many
lists
from
working
group
and
we
will
also
keep
aligned
with
progress
in
spring
the
progress
of
the
relentless
policy
discussion
and
thank
you
for
listening.
D
D
D
J
J
So,
but
in
that
net
there
is
already
rfc
discussed
the
the
npr's
data
plane
at
this.
The
similar
functions
in
ikea
state
plane,
so
we
we
didn't
think
we
we
haven't.
We
haven't
dabbing
too
into
this
into
the
space
specifications
of
the
of
the
npr's
data
plane.
J
So
I
think
it
it.
It
is
some
kind
of
missing
there,
but
we
will,
I
think,
we'll,
discuss
and
find
a
better
way
to
to
to
fill
in
the
gap
here,
and
I
I
see.
G
D
J
J
C
Hi
anthony
somerset
liquid,
can
you
just
go
back
to
the
tlv
slide?
I
think
the
second
one
is
there
a
maps
issue
because
it
says
reserves
24
bits,
but
the
diagram
says:
there's
the
next
one:
the
diagram's
saying
that
there's
28
bits
reserved.
D
So
some
other
points
that
we
also
want
to
discuss,
something
that
we
started
on
the
mailing
list
as
well,
which
is
further
discussion
on
whether
we
should
use
rp
object
or
try
to
put
this
inside
sr
policy.
I
think,
let's
continue
that
discussion
and,
of
course,
with
protection.
You
use
the
wood
that
this
is
little
different
protection
than
what
is
already
defined
in
psep.
So
it
would
be
good
to
tell
what
do
you
really
mean
by
that?
D
What
what
is
the
difference
between
redundancy
protection,
and
maybe
the
diversity,
work
or
protection
type
that
we
already
have
in
psep?
So
if
you
need
to
define
something
new,
just
be
very
clear
on
how
it
is
different
from
what
is
already
there
and
how
it
will
work
with
what
is
already
defined
that
if
somebody
encodes
both
of
these,
how
would
how
would
how
would
it
interact
with
each
other?
So
you
need
to
be
more
careful
at
the
time
of
introducing,
especially
for
the
protection.
D
J
The
suggestions
yeah
we'll,
have
some
internal
discussions
with
the
coursers
and
come
back
with
with
the
yeah
with
the
answers
yeah.
Thank
you
perfect.
B
B
What's
about
the
latest
versions,
we
update
our
draft
based
on
the
comments
from
adobe
and
join.
Thank
you
very
much
and
we
use
reflect
instead
of
attended
with
like
and
remove
equal
one.
The
format
of
the
siero
sub
object
and
I'd
say
the
verification
process,
and
I
use
a
two
2pd
code
point
for
repeat
section.
B
Draft
itf's
principal
road
policy
describes
the
state
verification,
build
usage,
seed
verification
is
performed
when
the
hard
end
is
explicitly
requested
to
verify
state
by
the
controllers,
while
the
signaling
protocol
used
and
fc8664
specifies
extensions
to
the
pcep
that
allow
a
stateful
pce
to
compute
and
initiate
t
pass,
as
well
as
a
pcc,
to
request
a
past
subject
to
slaughtering
constraints
and
optimization
criteria
in
isr
networks,
and
this
draft
defines
a
new
flag
for
indicating
the
height
and
is
explicitly
requested
to
verify
seat
by
the
pce,
and
this
is
for
seed
verification.
B
The
reflect
has
no
meaning
in
the
srro
and
is
ignored
as
we
see
it,
and
the
pce
next
is
the
state
verification
process
process
I
was
receiving.
I
I
saw
yeah,
I
saw
v6
yahoo
with
the
flag
inside
sorry.
This
is
on
receiving,
I
saw
yao
with
the
reflect
inside.
A
pcc
must
verify
seat
if
a
pcc
verification
fails
forward
seat.
B
It
must
report
this
arrow
by
including
the
srp
iron
code
tlv
without
spiro
value,
state
verification
fields
in
the
iosp
object
in
the
pc
report,
mouse
message
to
the
pce
and
under
the
and
the
under
the
I
comments
we
occur
and
and
the
ieti
one
was
there
was
meetings
we
discussed
why
the
the
policeman
of
the
rebate
is
appropriate
pro
88
and
this
draft
aligned
with
the
extension
of
draft
pc
e
srv6
and
dropped
bdps
are
polls,
so
we
extend
a
new
flag
as
a
young
object
and
we
have
accepted
all
the
comments
from
from
the
mail
list
and
how
updated
the
draft.
B
F
D
Anyone
else
I
just
wanted
to
plug
in
this
new
wiki
page
that
I
have
created,
it
is
still
work
in
progress,
but,
like
this
document
was
something
that
got
missed
in
pce
one
fun
flag,
and
now
we
have
to
update
the
document
to
add
that
flag
in
psep.
Similarly,
we
have
algo
confusion,
so
we
need
to
do
a
little
better
job
with
coordinating
between
our
documents.
So
we
have
started
this
page
that
can
help.
D
I
put
the
link
in
the
chat
where
we
would
request
the
authors
when
they
are
working
on
multiple
documents
in
bgp
in
spring.
In
it
they
can
update
this
wiki
and
we
can,
like
you
know,
as
a
working
group,
track
all
of
this
in
a
much
better
way,
so
that
we
can
avoid
these
issues
like
one
bit
not
being
present
in
psep,
etc.
So,
let's
try
to
do
better
job
as
a
working
group.
All
of
us
together.