►
From YouTube: IETF113-PCE-20220321-1200
Description
PCE meeting session at IETF113
2022/03/21 1200
https://datatracker.ietf.org/meeting/113/proceedings/
A
All
right,
hi
everyone,
julian
just
sent
me
a
message
he
will
be
joining
in
in
a
minute.
So
let's
give
him
some
time
and
looks
like
we
are
mostly
remote.
We
see
a
few
people
in
the
room
and
harry
our
secretary
is
helping
us
on
site
so
I'll.
Let
hari
also
confirm
when
we
are
ready
to
go
so
just
bear
with
us
for
a
few
minutes
we'll
be
starting
soon.
A
B
Okay,
so
hello,
everyone.
This
is
the
best
competition
element
working
session.
First,
one
of
the
two
that
you
can
see
reminded
here.
So,
as
usual,
you
know
the
the
best
practices
when
we
are
remote
attending
remotely
using
metacore.
We
should
have
a
couple
of
people
on
site.
I
guess
I
don't
see
so
many
in
the
room,
but
harry.
Is
there
hi
harry
good
to
see
you
so
the
usual
note
world?
You
should
be
already
familiar
with
them
as
well
you're
supposed
to
be
reading
them.
B
B
So
your
usual
urls
they
have,
we
have
not
taking
happening
so
in
case
you
want
to
join
a
harry
on
the
not
taking
stuff.
This
is
free
to
connect
to
the
note
I
theft
page
and
give
a
hand
to
harry
on
not
taking
especially
in
case
of
names
when
you
take
the
floor
or
may
want
to
check
that
what
you've
been
stating
on
the
mic
has
been
properly
recorded
in
the
midst
next
place.
B
B
B
Taking
part
into
technical
discussion
is
also
the
way
we
progress
work
so
make
sure
that
you
dive
into
it
as
much
as
possible.
We
need
people
sharing
on
the
making
list
to
jet
consumption
as
chairs
as
well
so
try
to
make
use
of
the
list
as
much
as
possible.
We
know
that
sometimes
things
happen
in
the
background.
Why
not?
But
try
also
to
make
major
progress
visible
on
the
main
list.
B
B
We
know
many
of
you
already
know
the
staff,
but
in
case
you
have
not
just
asked
the
chairs
and
we're
there
to
help
and
provide
info
on
trigger
processes
if
necessary,
next
place,
so
at
gender
bashing.
You
see
both
sessions
depicted
here.
Anyone
want
to
say
something
about
the
agendas
for
today
and
tomorrow.
B
B
B
B
Three
of
them
were
renewed
not
far
ago
on
the
new
one
happened
at
the
beginning
of
the
year,
so
the
process
is
quite
simple
in
case
it's
needed
for
some
implementations
about
new
documents.
Please
ask
a
chair
and
talk
about
the
express
the
needs
thanks
so
for
the
working
group,
detailed
status
and
associated
working
group
ids,
I
leave
the
proto
graph.
A
A
We
have
first
document
which
is
stateful
gmpls,
I'm
the
shepherd
for
this
document
and
I
have
done
the
review
and
we
are
now
waiting
for
authors
to
do
the
rework
and
if
any
authors
of
any
of
the
documents
want
to
come
and
say
something
on
the
mic,
please
come
and
use
the
mic
time.
For
this.
I
see
how,
on
the
queue
go
ahead,
how
me
and
if
you
want
to
talk
about
gmp
lists.
A
Thank
you.
Thank
you.
The
next
document
is
vn
association.
Here
also,
we
received
some
good
comments
during
the
working
group
last
call.
We
are
still
waiting
for
the
working
group
last
comments
to
be
handled,
after
which
shepherd
review
would
be
done
by
hari.
So
thanks
hari
for
being
the
shepherd
for
this
document,
we
also
started
one
thread
related
use
of
ascii
in
psep,
so
please
participate
in
that
thread.
A
Let
us
know
your
inputs
and
then
chairs
would
be
like
you
know,
collecting
that
input
and
taking
the
next
step
based
on
the
feedback
that
we
receive
from
the
working
group.
So
please
do
that
how
many
on
any
comments
association,
I
think
you
are
the
editor
for
this
one
as
well.
A
Okay
thanks
next
we
have
pcip
young.
I
am
the
editor
for
this
one.
So
first
let
me
give
the
update,
so
we
posted
a
new
version
in
january.
The
major
changes
were.
One
comment
was
with
respect
to
use
of
ip
address
no
zone,
so
that
change
has
been
made.
A
We
had
a
request
to
add
our
pc
to
reset
all
the
pcp
statistics,
so
that
is
done
as
well.
So
thanks
for
comments
from
tom
petch
and
robert
verga
on
this,
and
julian
has
also
made
a
request
for
the
yang
doctor
review.
A
So
once
we
have
the
yang
doctor
review,
we
will,
like
you,
know,
handle
that,
and
then
I
think
this
document
is
nearing
working
group
last
call
all
our
dependencies
are
also
nearing
working
group
last
call,
so
we
don't
have
any
pending
dependency
as
such,
so
hopefully
this
document
also,
we
should
be
processing
soon
note
that
we
had
an
early
young
doctor
review,
but
that
was
for
much
older
version,
so
it
made
sense
to
request
young
doctor
review
again
much
nearer
to
the
working
group
last
call.
A
A
A
We
had
some
comments
in
binding,
said
related
to
sit
structure,
so
those
were
applicable
to
this
document
as
well
and
authors
have
updated
the
sit,
structured
description
added,
also
handled
one
comment
with
respect
to
how
to
do
the
optional
fields
in
srv6ero.
A
So
how
should
we
maintain
the
order
of
the
various
different
optional
fields
in
srv60?
So
one
section
has
been
added,
so
please
review
this
new
changes
that
have
been
done
and
then
the
binding
sid
actually
has
a
normative
reference
to
this
document,
so
binding
sid
has
to
will
be
in
a
misrep
state
until
this
document
we
send
to
the
isg
and
the
rfc
editor.
A
So
I
think
we
should
prioritize
moving
this
work,
so
everybody
in
the
working
group
kindly
review
this
document
so
that
we
can
progress
it
out
of
the
working
group
soon.
Any
comments
on
srv6.
A
Okay,
more
documents:
we
have
a
pcep
native
ip
extension
here.
We
have
authors
made
two
updates.
This
has
been
presented
in
the
idr
interim
as
well.
Authors
ask
for
request
for
comments
on
the
idr
list
as
well,
where
sue
had
commented
and
authors
have
made
an
update
of
this
document
as
well.
So
I
think
we
would
be
when
we
do
working
group
last
call.
We
will
be
doing
a
cross
posting
in
both
idr
list
and
pc
list,
and
this
document
is
also
nearing
a
working
group.
Last
call
state
itune.
A
Okay,
next,
we
have
flex
grid.
Here
we
haven't
had
many
technical
changes
for
a
long
time.
I
wanted
to
check
with
the
authors:
are
there
any
pending
issues?
Can
we
consider
this
document
also
to
be
ready,
and
if
there
is
any
other
review
steps
that
can
be
done
to
get
more
eyes
on
this
document?.
A
Okay,
let's
move
on
this
document,
we
discussed
last
time
as
well
enhanced
errors.
We
have
had
no
change
and
but
we
are
in
a
limbo
here,
like
you
know,
last
time,
we
thought
that
we'll
ask
the
working
group
to
get
feedback
on
what
do
we
do
with
this
document
and
some
of
the
options
are
listed
here
like?
Should
we
make
this
work
experimental
and
try
to
commit
some
reviewers
and
publish
it
now?
Should
we
wait
for
some
implementations
to
actually
implement
this?
A
The
issue
is
that
we
have
this
feature,
but
this
feature
is
not
currently
being
used
by
any
of
the
document
and
one
document
that
we
kind
of
think
which
can
use.
This
is
the
stateful
interdomain
document.
So
I
hope,
like
the
authors
of
stateful,
interdomain
and
authors
of
this
document,
can
work
together
and
give
some
feedback
to
the
chairs
on
what
should
be
the
next
step
with
respect
to
this
document.
A
So
we
are
still
looking
for
that
feedback
and
we
are
especially
looking
for
feedback
from
stateful,
interdomain
authors
and
other
people
in
the
working
group
as
well
on
what
do
it?
What
do
they
think
should
be
the
next
step
for
this
document,
so
the
window
is
still
open.
Please
let
us
know
if
you
have
any
comments
now
or
on
the
mailing
list.
A
Okay,
so
some
other
documents
that
we
have
is
sr
path
segment.
There
hasn't
been
no
big
technical
change.
The
work
is
aligned
to
changes
that
were
made
in
the
binding
set
recently
there
doesn't
seem
to
be
any
open
issues,
but
I
wanted
to
recheck
from
authors
and
others
in
the
working
group
if
they
have
any
concern
with
the
path
segment
work
that
is
happening
in
psap
and
the
related
work
in
spring
is
also
making
progress.
A
A
A
Next
we
have.
We
have
a
document
related
to
sr
policy.
There
hasn't
been
an
update
since
the
last
itf,
so
authors
are
there
any
pending
issues.
Anything
please
use
the
list
discuss
and
make
sure
that
the
work
is
aligned
to
spring
and
idr
work.
That
is
also
happening
with
respect
to
pcc
sr.
A
We
had
one
update,
it
was
a
minor
update
and
I
think
the
work
is
looking
for
more
reviews
and
more
eyes
on
these
documents.
So
working
group,
we
have
a
lot
of
working
group
adopted
documents
and
we
are
requesting
the
working
group
to
do
more.
Reviews.
Give
us
comments
so
that
we
can
progress
this
document
as
a
part
of
normal
working
group
process.
A
We
have
stateful
interdomain
the
stateful
interdomain.
My
question
to
the
authors
is
the
part
that
we
just
discussed
regarding
enhanced
errors.
If
the
features
of
enhanced
errors
can
be
used
in
stateful
inter
domain,
that
would
be
a
good
entry
point
and
a
feedback
from
the
working
group
on
how
to
progress
both
the
documents.
Together,
we
have
document
related
to
extended
flags
in
lsp.
A
A
The
state
sync
document
there
was
no
update
this
time,
so
I
will
skip
over
it.
We
have
optional
fields,
optional
objects,
marking
some
of
the
psep
objects
as
optional.
That
work
also
has
no
recent
update,
but
the
document
handled
the
working
group
adoption
comments
and
there
are
no
pending
comments.
As
of
now
so
people
who
have
feedback.
Please
use
the
mailing
list
for
this
and
for
sr
p2mp
policy.
A
Since
we
have
adopted
that
work,
they
have
not
been
any
update.
So
are
they
comments?
There
is
changes
that
are
happening
in
other
working
groups.
Related
to
this
work,
so
we
need
to
make
sure
that
the
alignment
is
also
maintained
between
pim
spring
idr,
etc,
are
related
to
this
work
and
recent
adopted
documents.
These
were
just
adopted
between
the
last
itf
and
now
we
have
l2
flow
spec.
A
A
This
was
adopted.
There
were
comments
during
working
group
adoption,
but
they
are
currently
pending,
so
request
authors
to
handle
this
comment
as
well,
and
that
will
bring
me
to
my
last
slide,
which
is
our
working
group
adoption
queue.
This
has
been
updated
in
our
wiki,
so
please
have
a
look.
This
is
the
current
order
that
we
would
be
using
for
the
recent
adoption.
So
next
on
queue
would
be
the
path
mto.
A
We
have
srv6
yang
ifit,
which
is
actually
on
the
agenda
today
as
well,
and
then
pcc
srv6
work
as
well,
and
if
authors
have
they
feel
that
their
document
is
also
ready
for
adoption.
Please
send
a
note
to
the
chairs
and
we
will
discuss
and
update
our
queues
accordingly,
so
I'll
now
would
request
anybody
who
has
any
comments
on
any
of
our
working
group
adopted
work
use
this
time
if
they
want
to
discuss
something,
please
use
it.
Otherwise
we
will
go
back
to
the
main
agenda
from
now.
D
Hello,
everyone
excuse
me,
can
you
hear
me?
Okay,.
D
Yes,
andrew
okay,
perfect
thanks
I'll,
be
just
giving
a
status
update
on
local
production
enforcement
on
behalf
of
well
the
other
co-authors
as
well.
Next
slide,
please.
D
So
this
basically
just
summarizes
really
what
this
document
is
all
about.
The
main
two
things
are
really
that
there's
wording
and
statements
around
the
usage
of
the
existing
local
protection,
but
this
was
really
driven
because
of
interop
misinterpretations
on
how
local
protection
should
actually
be
enforced,
and
so
a
lot
of
the
text
is
really
trying
to
be.
You
know
generally
backwards
compatible,
while
actually
clearing
up
those
misinterpretations.
D
D
D
So
the
current
status
is
well
zero.
Zero
was
uploaded
in
2019.
It's
been
presented
here
to
the
pc
working
group
a
couple
times,
as
I
mentioned
earlier,
it
was
adopted
in
2020.
The
code
point
allowed
implementations
to
move
forward
with
it
and
that
code
has
now
been
reallocated
so
naturally
the
or
renewed
rather
so
now.
Naturally,
the
concern
is
making
sure
that
you
know
the
document
can
progress
before
that.
Early
code
point
actually
expires
again.
D
The
draft
is
pretty
much
stable.
You
know
in
terms
of
the
the
technical
goals
that
it's
trying
to
achieve
the
actual
use
cases.
You
know
the
descriptions
so
really
we're
just
kind
of
seeking
you
know,
moving
towards
working
group
last
call
so
that
way
we
can
kind
of
wrap
this
up
a
little
bit
next
slide,
please,
but
actually
before
doing
that,
I
went
back
and
looked
at
that
now
to
see
if
there
was
anything
outstanding-
and
there
was
really
just
some
kind
of
open
comments
about.
D
You
know
generalizing
the
conflict
of
enforcement,
so
that
ebit
flag,
you
know,
should
that
be
generalized
for
all
object
and
visa
or
all
attributes
and
visa.
D
And
again,
these
are
just
kind
of
generalized
comments,
so
I'm
just
trying
to
address
it
here
in
the
group
and
actually
we
can
take
this
little
list.
So
the
main
question,
I
think,
is
you
know:
is
this
actually
required
by
this
document
or
is
it
safe
and
okay
to
you
know,
proceed
with
that
new
ebit
flag
being
defined
as
it
is
in
the
document?
D
D
So
there
was
an
idea
proposed
on
the
list
to
basically,
you
know,
move
object
flags
into
the
tlv
and
follow
a
similar
pattern
that
rfc
5420
was
doing,
but
it
was
also
an
open
suggestion,
and
so
at
the
current
moment
you
know
you
basically
see
that
it
doesn't
really
seem
necessary
at
this
time,
just
because
we
do
have
bits
available.
D
Naturally,
it
would
be
good
for
the
group
to
you
know,
progress
in
that
direction,
but
I'm
basically
raising
this
topic
that
just
you
know,
get
consensus
on
whether
or
not
we
think
it's
perfectly
fine
to
just
use
the
ebit
as
it
is,
or
if
this
is
like
a
must,
you
know
move
in
this
kind
of
direction
so
again
seeking
just
some
kind
of
consensus
on
that
and
next
slide.
Please.
D
And
that's
everything.
I've
got
so
look
forward
to
any
comments
or
clarification
really
on
this
kind
of
slide.
Thanks.
A
So
just
my
personal
opinion
and
without
any
hacks
I
would
think
that,
like
you
know,
what
you
are
proposing
seems
to
be
rational
is
we
can
keep
this
work
as
a
separate
entity
and
if
there
is
a
need
for
doing
this
thing
for
for
flags,
maybe
that
can
be
handled
as
a
part
of
pce
optional,
because
that
document
is
anyway
focusing
on
how
this?
How
to
do
this
optional
work
for
objects,
and
if
there
is
a
need
to
do
that
per
flag-
and
there
is
some
suggestion
for
it.
A
Maybe
we
can
handle
that
in
optional
document
and
anyway
we
are
a
volunteer
driven,
like
you
know,
organization,
so
the
people
who
have
that
comment
and
have
a
proposal
on
hand.
Maybe
they
can
provide
that
as
input
to
pc
option
and
since
pc
optional
is
now
an
adopted
work.
It
can
be
updated
as
a
part
of
normal
working
group
process.
So
there
is
nothing
that
is
blocking
this
to
be
handled
within
the
working
group,
but
as
well.
A
So
if
anybody
has
any
thoughts
on
this
comments,
if
I
remember
correctly,
it
was
pawan
who
had
this
coming.
So
he
can
also
confirm
now
or
on
the
mailing
list
whether
he
likes
this
approach
or
not.
Oh,
I
see
him
in
the
queue
pawan
go
ahead.
E
Yeah
yeah,
it
was
me
who
made
that
comment.
I
still
would
like
to
see
a
generalized
approach
for
this,
but
yeah
I
mean
I
haven't
put
that
said.
I
haven't,
contributed
any
text
or
published
a
new
new
craft
for
discussing
this,
so
I'm
good
with
whatever
is
currently
being
come,
but
yeah,
but
I
I
would
like
to
see
a
general
way
of
imposing
that.
E
I'm
okay
with
that
yeah.
For
now
I
mean
you're,
saying
for
just
for
this
particular
flag.
We'll
have
this
additional.
There
will
be
an
additional
enforcement
pack,
but
for
any
other
attribute,
if
you
want
to
enforce
it
yeah
I
mean
we
can
transfer
that
as
part
of
the
pc
operations.
E
D
I
just
want
to
say
thanks
and
yeah:
it
does
sound
reasonable
to.
You
know
embed
this
into
the
optional
document,
just
because
it's
really
about
you
know,
do
you
actually
respect
these
attributes
of
these
flags
and
the
optional
just
seems
like
the
natural
place
to
put
it,
so
that
seems
pretty
reasonable.
Yeah
thanks.
A
While
you
were
presenting,
I
saw
one
more
thing
like
you
know,
maybe
we
need
to
do
a
little
bit
more
language
check.
One
thing
which
I
found,
maybe
not
the
best.
The
use
of
the
term
must
constrain
and
may
constraint.
A
I'm
not
sure
that
would
be
the
best
way
to
describe
a
mandatory
field.
An
optional
field,
like
you
know
whether
we
could
use
the
word
must
constraint
as
a
term.
So
maybe
we
can
find
out
what
is
the
best
description
of
this
flag
as
well?
I
think,
as
in
implementers,
you
and
I
understand
what
that
means,
but
is
that
the
best
way
to
frame
this?
That's
something
also
worth
looking
at.
D
Okay,
yeah.
Definitely,
I
guess,
try
to
see
if
there's
a
way,
maybe
to
extend
on
that,
really
can
explain
it
a
little
bit
better.
C
C
D
So
I
I
guess
if,
if
that
was,
I
guess
the
last
comment
that
would
be
kind
of
need
to
be
addressed.
Does
the
group
think
that
we
can
probably
move
towards
working
group
last
call
over
the
you
know
the
next
year
or
so.
A
I
think
we
should
we
should
respect
the
especially
the
renew,
like
the
deadline
that
we
have
in
mind
with
respect
to
the
ina
early
code
point,
so
we
should
definitely
aim
for
getting
this
document
working
with
call
accordingly,
and
I
will
discuss
this
with
julian
and
prioritize
this
accordingly,
once
you
have
updated
the
last
set
of
comments.
A
Okay,
I
don't
see
anybody
else
in
the
queue.
So,
let's.
G
G
Hello,
everyone-
this
is
sean
from
city.
My
presentation
today
is
the
presab
extension
for
srmps
entropy
level
position.
Let's
snipe
this.
G
And
this
draft
has
been
presented
for
three
times
and
we
got
marrying
comments
from
many
lists
and
the
meetings
and
they
are
appreciated
from
stephen,
duke
paris,
vamping,
jeff
and
tom.
Thank
you
very
much.
We
made
updates
before
version
seven.
For
example,
we
moved
the
d-page
to
lsp,
extended
flags
and
we
made
free
clarification
for
the
msd
and
the
erld
limitations
and
requirements
in
pc
in
into
domain
scenario.
G
We've
also
made
a
clarification
for
ingress
capability
and
the
ebay
is
used
to
indicate
the
capability
over
inserting
multiple,
el
ielps
and
pcc
and
the
support
and
the
sr
pass
with
prp
from
pc
at
the
same
time,
and
so
finally,
we
made
clarification
for
their
el
iel
positions
calculated
for
sr
pass.
So
this
time
we
made
updates
actually
version
7.
G
First,
we
made
clarification
for
pc
to
get
msb
and
the
erld
capabilities
and
adding
reference
to
existing
underlying
igp
extensions,
including
ecs
and
ospf.
This
comments
from
the
jeff
and
we've
also
made
a
clarification
and
we
would
remove
the
minimum
er
ldtf,
because
this
is
not
necessary
and
finally,
we
made
a
synchrolized
update
and
keeping
consistent
with
the
extension
of
hp
protocol.
G
G
So,
let's
do
the
recap
of
the
background.
The
rc-862
proposes
to
apply
the
entropy
label
to
simplest
networks
and
provide
the
pla
fly
criteria
to
determine
the
best
er
ielts
placement
in
rfc
8662.
The
ingress
may
not
spend
the
minimum
erld
unknown
path
and
does
not
support
the
computation
of
their
in
minimum
erld
so
controller.
For
example,
the
pc
may
perform
the
the
to
end
possible
computation
as
well
as
well
as
the
entire
entropy
label
position,
including
the
lambo
and
third
place.
G
So
we
can.
The
proposed
psap
extensions
to
contrib
computer
parts
is
especially
in
inter
domain
scenarios
with
the
er
I
l
els
number
and
place
last
slide.
Please.
G
So
we
propose
some
precept:
extensions
first
of
all,
the
pc
could
get
the
information
such
as
msd
and
the
el
rld
through
igp
and
their
compute,
the
minimum
erld
unknown
n2n
pass
first.
For
example,
the
year
erld
value
can
be
collected
for
ease
and
ospf,
and
the
msd
value
also
can
be
collected
for
rc84
like
1
and
ospf
rfc
8476.
G
Then
we
also
proposed
a
e
bit
to
set
to
1
in
srpc
capability
in
open
object
when
the
eb
set
to
one
it
indicates,
as
it
supports
the
as
sr
pass
computation
with
erp
new
configuration.
Also.
It
also
indicates
that
the
it
supports
the
capability
of
inserting
multiple
eri
erpls
at
pcc
last
night.
Please.
G
G
So
this
document
has
been
discussed
many
times
in
details
at
the
meetings
and
the
under
mailing
list,
and
all
comments
have
has
been
resolved
and
thanks
for
your
comments
and
suggestion
and
the
the
according
pgp
extension,
the
draft
idr
bgp
srm
plc
erp.
The
draft
has
been
in
adoption
queue,
and
so
this
this
document
has
made
according
updates
and
being
in
accordance
with
the
bgp
extensions.
A
I
don't
see
any
questions
thanks
for
updating
the
documents
and
handling
all
the
comments
that
you
have
received.
So
the
last
set
of
comments,
as
you
said,
was
related
to
removing
the
minimum
erlt
tlv
and
after
that
there
are
no
other
open,
no
comments
from
sorry.
I
got
little
feedback,
so
let
me
say
that
again:
are
there
any
other
open
issues
from
previous
meetings
or
mailing
list.
H
H
Just
a
few
words
about
background
and
motivation,
so
I
feed
the
first
two
bots
in
c2im
and
alternate
mapping.
The
base
draft
about
methodology
are
quite
stable,
so
you
can
see
the
reference
document
yeah.
We
all
know
that
the
psep
extension
can
be
used
to,
of
course,
to
signal
in
this
case
the
effect
capabilities.
H
These
allow
to
have
the
effect
methods
automatically
activated
and
running
the
draft
proposed
to
define
the
fit
attributes
and
to
be
generalized
as
pld
in
the
lspa
object,
and
the
draft
is
general,
so
it
means
that
it
can
be
applied
for
all
part
type
as
long
as
they
support
the
data
plane
method.
Next
slide.
H
The
first
extension
that
is
proposed
is
the
effect
capability
tld
that
is
an
optional
cld
to
be
used
in
the
open
object.
H
H
H
Of
course,
these
i5
tlbs
are
optional
and
can
be
taken
into
account
by
the
pce
or
by
the
pcc.
Next
slide
yeah.
You
can
see
there
the
five
sub
tlds
that
can
be
included
in
the
fit
attributes.
Tld
four
are
for
iom
feature
and
one
is
for
alternate
masters
next
slide
yeah
in
this
slide.
We
just
summarize
the
lattice
changes
after
ips112,
we
revised
the
iana
considerations,
part
and
we
added
different
sub
subsection
for
the
precept,
qld
type
ip
capability,
tlv
flags
and,
if
it
attributes
of
dlv.
H
In
addition,
we
added
the
new
subsection
for
enhanced,
alternate
margin,
sub
tld
flags
and
also
a
new
subset
subsection
for
psi
period
code
just
to
keep
the
structure
in
line
with
other
pc
documents.
H
Next
slide:
okay,
yeah.
We
consider
this
document
relevant
to
enable
like
feed
for
control
mechanisms.
It's
worth
mentioning
that
synthetic
methods
are
becoming
natural
for
ipv6,
srm,
tls
and
srv6
this.
This
draft
also
complement
the
segment
routing
policy
ct
draft
to
enable
lesser
policy
with
native
by
fee.
H
A
H
A
And
please
please
keep
the
document
aligned
with
the
other
work
that
is
happening
in
other
working
group,
because
I
think
you
have
ifit
work
in
rppm
and
also
proposal
in
idr,
so
just
make
sure
that
the
documents
are
aligned
from
the
start,
rather
than
doing
that
at
the
end
of
the
process.
H
A
We
have
some
time
so
if
anybody
has
any
other
document
from
working
group
document
that
they
would
like
to
discuss
any
other
comment,
we
can
use
that
time.
Otherwise,
we'll
give
you
15
minutes
of
your
life
back.