►
From YouTube: IETF115-PCE-20221111-1200
Description
PCE meeting session at IETF115
2022/11/11 1200
https://datatracker.ietf.org/meeting/115/proceedings/
B
A
A
A
A
A
A
A
A
Okay,
mixed
meeting
again,
people
are
joining
both
from
the
room
on
mythical,
so
we
use
the
medical
tool
to
manage
the
cues.
So
that's
the
main
impact
for
people
on
site
remember
to
learn
the
queue
using
the
medical
tool.
There
is
a
light,
one
that
is
appropriate
for
mobile
phones
or
laptops
for
Riemann
participants.
You
know
the
deal
you
you're
already
using
the
medical
app
whatever
thanks
next.
C
A
So
we
have
Harry
acting
as
a
mini
taker,
but
as
usual,
if
you
want
to
give
him
a
hand,
it's
always
useful,
especially
if
you
were
involved
in
discussion
for
people
on
site
name,
spelling
checking
could
be
useful,
so
you
may
join
the
minutes
on
the
link
there
and
give
Harry
a
run
when
you
feel
like
it.
Thanks.
A
Usual
reminder
on
the
process
in
the
ATF,
especially
on
the
use
of
the
mailing
list.
We
know
that
from
time
to
time
there
are
many
things
happening
in
the
background,
so
remind
let's
remind
that.
Itf
process
is
based
on
touching
consensus
to
progress
work,
so
this
needs
to
be
visible
at
some
point
on
the
mailing
list.
There
are
also
some
critical
steps
on
the
ATF
process
related
to
the
main
Linux
use.
So
when
it
comes
to
working
with
last
calls
document,
adoption
and
so.
D
A
The
more
people
are
involved,
the
easier
it
is
for
the
chairs
to
judge
on
the
consensus
on
the
support
of
a
given
work
item.
We
also
manage
a
Wiki,
especially
to
keep
an
eye
on
the
existing
queue
for
document.
Adoption
on
working
of
last
calls
there's
still
some
backlog
there,
but
it's
improving
so
feel
free
to
update
in
cases
we
missed
any
item
there.
A
There
are
some
opportunities
to
request
a
code
point
from
the
Ayana,
so
it's
been
used
in
the
past
for
a
few
drafts
and
please
don't
forget
to
go
through
that
process
in
case
there
are
interoperability
at
stake
in
the
short
term,
because
it's
easier
to
get
a
record
point
and
modify
existing
deployment
later
in
the
process.
So
you
don't
necessarily
have
to
wait
for
full
RFC
status
to
use
that
code
point
from
the
Ayana
the
agenda,
no
change
from
the
published
one,
any
one
want
to
bash
anything
hope,
not
okay.
A
So,
let's
move
on
hello
reviews,
so,
as
you
may
be
aware,
there
has
been
some
suggesting
process
about
early
reviews
in
the
rooting
area.
The
good
news
is
that,
from
the
PC
standpoint
we
will
use
the
earlier
review
process
from
time
to
time,
so
nothing
brand
new
from
the
PC
perspective,
but
it
good
to
see
that
it's
a
jewelry
guideline
that
we
are
already
following
and
that
it's
another
that
is
enlarging.
A
We
feel
it's
a
very
useful
process
step
to
consider
early
reviews
from
the
rooting
area
perspective.
As
you
may
know,
we
usually
get
interesting
feedback
from
the
reviewers.
A
In
case
yeah
documentary
referring
to
balance
the
work
on
how
the
the
chairs
flushed
the
queues
using
Shepherd
for
the
last
stage
of
the
document,
is
a
useful
way.
So,
if
you're
interested
please
contact
the
chairs
we'd
be
happy
to
discuss
with
you.
What
document
would
be
relevant
for
you
to
Shepherd?
That's
a
useful
way
for
the
shepherd
to
to
understand
the
ATF
process,
especially
in
the
last
stages
and
for
the
chair
to
balance
the
work
we
thank.
A
A
So
working
good
status,
we
have
no
numeracy
since
the
last
ITF
meeting,
but
the
work
has
still
been
progressing
quite
well.
Three
of
the
documents
and
the
in
the
RFC
editor
queue
one
of
them
is-
has
been
blocked
for
a
while,
pending
for
a
spring
document
or
no
segment
voting
document
which
is
work
in
progress.
So
we
hope
to
resolve
that
dependency
in
a
short
term
or
reasonable
term.
A
The
other
ones
are
progressing.
So
we
can
hope
that
by
the
next
ITF
meeting
we
will
have
several
addresses
published.
We
have
to
order
a
documents
in
the
iuc
hand,
so
that's
him.
The
regular
level
of
cues
in
working
group,
which
is
live,
which
has
a
document
progressing
towards
iot
studies,.
A
Apart
from
that,
we
have
a
recent
Collision
that
came
from
the
it
UT,
so
we
need
to
join
the
routing
array
for
there
to
update
the
list
of
relevant
documents
that
we
will
point
to
the
igut
when
responding
to
their
license.
So
it's
a
usual
communication
between
the
gsdu,
so
nothing
special
to
mention
there.
If
you
feel
there
would
be
something
to
point
out
specifically
ready
to
given
work,
please
contact
the
chairs,
otherwise
we
will
probably
just
send
an
updated
list
of
relevant
documents
for
them.
A
We
also
have
a
reminder
of
the
existing
heli
code,
Poitier
location
from
the
Ayana
there
with
the
deadlines,
so
everything
in
2024
for
the
next
steps
some
have
been
renewed.
Some
are
progressing
towards
Seas,
so
everything's
fine.
So
far
at
this
stage
for
corporate
allocation,
okay,
so
a
little
flow
to
my
co-chair.
B
Hi
everyone
we'll
now
talk
about
all
the
working
group
documents.
Just
a
reminder
in
our
agenda,
we
had
only
one
working
group
document
with
status
is
being
presented,
but
working
group
documents
are
very
important.
This
is
where
we
have
the
consensus
to
progress
the
work,
so
please
use
this
time
if
there
is
any
open
issue
that
you
have
with
these
documents
or
if
there
is
any
feedback
that
you
want
to
provide
to
the
working
group.
It's
very.
B
This
is
the
key
work
that
we
want
to
progress
as
part
of
our
working
group
activities
and
that's
why
I
have
put
a
little
bit
time
on
the
agenda
for
all
our
working
group
documents
as
well.
So,
let's
start
with
the
first
one.
This
I
am
a
co-author
and
Julian
is
shepherding
the
the
document.
The
document
is
currently
still
in
the
working
group
last
call
stage.
It
has
not
been
closed.
B
We
got
comments
from
Tom
patch,
specially
related
to
the
use
of
TLS
1.3,
and
there
is
a
document
today
on
the
agenda
which
talks
about
how
psip
can
use
TLS
1.3,
as
well
as
from
the
Yang
point
of
view.
It
also
has
a
slide
there,
where
how
we
plan
to
how
we
have
already
handled
the
comment
that
came
from
Tom
and
then
once
that
is
done,
most
likely
I'll
ask
my
co-chair
to
progress
the
document
to
The
Next
Step.
B
As
far
as
update
is
concerned,
apart
from
TLS
1.3
issue,
the
main
changes
was
we
had
a
new
RFC
for
flow
spec
capability,
so
that
capability
flag
was
missing
so
that
got
added
and
related
to
security.
Also
in
the
igp,
we
had
a
recent
document
that
went
through
igp
they're,
also
based
on
the
comments
in
the
Ops
section.
Some
some
things
was
pointing
out
which
we
have
updated
in
the
Yang
model
as
well,
so
everything
is
well
aligned
and
we
hope
that
this
document,
which
is
a
very
important
document
for
p
sub.
B
B
So
this
is
the
document
on
which
the
binding
set
is
waiting.
This
is
the
our
srv6
document.
The
authors
have
made
an
update.
B
There
was
also
a
comment
from
midmoy
regarding
some
error
codes
that
were
misaligned
between
srmpls
and
srv6,
and
authors
did
a
pass
for
not
just
that
error
code,
but
all
the
error,
codes
and
I
think
in
the
latest
update
they
have
handled
this
well,
so
please
review
and
we
need
to
progress
this
document
next
because,
as
we
just
talked
about
it,
that
it's
blocking
one
of
the
documents
in
RFC
editor
queue
as
well.
B
As
this
document
has
Ina
allocation,
which
is
going
to
expire,
though,
we
can
of
course
ask
for
renew
no,
this
one
I
think.
Maybe
we
cannot
ask
for
a
new.
It's
like
two
things
already
run,
so
we
should
progress
this
and
get
it
out
in
the
normal
process.
Of
course,
we
can
ask
ads
permission,
but
let's
try
to
do
what
we
promised
to
the
working
room
and
if
anybody
has
any
concerns,
please
let
us
know
the
other
set
of
documents
which
are
almost
nearing
working
group
plus
call.
B
We
have
a
document
related
to
Native
IP.
This
RFC,
the
corresponding
RFC,
is
already
published
in
teas
working
group.
There
was
there
is
it
has
things
related
to
bgp
and
John
in
past?
It
have
pointed
out
to
the
IDR
mailing
list
it
got
discussed
in
the
IDR
mailing
list.
B
B
The
other
document
that
is
nearing
working
group
last
call
is
flexgrid.
This
one
has
been
refreshed.
We
haven't
received
many
comments.
The
authors
haven't
made.
Any
big
changes
looks
to
be
okay,
but
if
you
have
any
concerns,
please
use
this
time
and
let
us
know
otherwise
we
will
be
progressing
this
work
soon.
B
This
one,
which
is
enhanced
error.
This
is
one
which
we
have
kind
of
stuck.
We
presented
the
same
slide
in
the
last
1114
meeting
and
I'm
have
to
repeat
the
same
slide
again
in
one
one:
five,
we
have
no
inputs.
The
document
is
still
not
being
used
by
other
things,
which
is
also
giving
a
signal
that
we
could
see
what
to
do.
But
again,
this
is
your
opportunity.
B
B
So
rest
of
the
working
group
IDs,
we
have
path
segment
document.
This
has
been
updated,
mainly
editorial
change,
be
asked
an
explicit
question
in
114
that
currently
this
document
has
two
ways
of
doing
the
same
thing.
It
uses
PCC
mechanism
as
well
as
using
the
tlv.
We
have
done
that
in
the
past.
It's
still
aligned,
but
we
wanted
to
give
the
opportunity
to
the
working
group
to
make
sure
that
they
are
aware
that
there
are
two
mechanisms
being
standardized
and
if
there
is
an
issue,
please
voice
it
out
now.
B
Otherwise,
the
author's
preferences
to
use
both
the
mechanisms-
and
they
have
Justified
that
in
the
document
as
well.
So
please
review
and
give
your
feedback.
That's
the
only
issue,
otherwise
I
think
path.
Segment
in
Spring
is
progressing
quite
well,
so
we
should
be
doing
that
in
PC
as
well
and
Publishing
this
soon.
A
similar
document
is
about
bi-directional
path.
Again,
mainly
editorial
changes
looks
to
be
pretty
stable.
Has
a
similar
work
is
already
done,
so
we
will
be
progressing
that
soon.
So
I
think
we
have
a
question:
Ahmad
go
ahead.
B
Oh
looks
like
it
was
by
mistake,
so,
let's
continue,
then
we
have
a
documents
related
to
Sr
policy,
Sr
policy,
candidate
path.
This
has
been
mainly
a
refresh
from
our
look.
It
seems
to
be
ready,
like
we
haven't,
had
a
major
update
in
a
while
it
was
presented
in
the
past.
Itf
has
good
support,
so
we
will
be
putting
this
into
almost
ready
for
working
group
last
call
queue.
So
if
people
have
any
thoughts
comments
implementers,
please
give
your
feedback
on
this
document
soon.
B
The
second
one
is
PCC
Sr
again,
no
major
update
looks
like
nearing
working
plus
call.
If
you
have
an
issue,
please
let
us
know
so
with
the
idea
of
presenting
the
statuses.
We
just
want
to
know
what
our
thinking
is.
So
it
gives
you
gives
the
working
group
an
opportunity
also
to
to
align
and
review
and
give
feedback
timely,
rather
than
at
the
wait
for
the
working
group.
Last
call
only
better
to
do
handle
comments
as
a
part
of
working
group
process
itself.
B
A
multipath
has
not
seen
an
update,
but
it
is
being
used.
It
has
been
implemented.
The
implemented
multiple
vendors
claim
to
implement
this.
So,
which
is
good,
so
we
would
like
to
progress
this
as
well.
Soon
State
synchronization
not
have
been,
has
not
been
updated.
One
issue
which
I
it
might
be
a
personal
issue
that
I
have
is
that
document
doesn't
talk
about
how
to
set
primary
and
secondary.
B
B
The
next
set
of
documents
are
PC,
optional,
no
update
looks
to
be
ready.
We
have.
If
anybody
has
any
objection.
Please
use
the
mailing
list.
We
have
a
document
stateful
into
domain.
It
has
expired,
it
has
not
been
updated,
but
the
authors
have
told
that
they
have
planned
to
make
an
update
soon
and
also
they
plan
to
handle
the
comment
related
to
enhanced
error,
which
I
was
earlier
talking
about
that
whether
this
document
can
use
the
extension
that
is,
that
is
suggested
in
the
enhanced
error
for
stateful
interdomain
I.
B
Also,
there
was
a
document
in
the
spring
working
group
as
well,
which
was
talking
about
interdomain.
Currently,
they
focus
only
on
a
single
PC
case.
I
did
bring
it
up
that
if
they
want
to
handle
multiple
pce,
this
will
be
the
approach
of
stateful
interdomain
that
they
can
explore.
So
that
is
also
something
worth
checking
across
working
group
as
well.
B
With
respect
to
SRP
to
employee
policy,
there
has
been
no
update,
but
this
is
one
of
the
recent
adopted
working
group
documents.
So,
let's
give
it
time
for
people
to
adjust
and
Implement
Etc
L2
flow
spec.
This
was
the
document
that
was
moved
out
of
the
original
flow
spec
document,
mainly
because
of
IDR
flow
spec,
V2
work.
It
is
basically
pending
the
flow
spec
V2
work
to
happen
in
IDR,
as
well
as
the
L2
flow
spec
being
published
in
IDR.
Once
those
two
are
done
in
the
idea.
B
Working
group
then
I
think
psap
work
can
also
progress
so
right
now
we
are
on
the
waiting
stage.
As
far
as
the
L2
flow
spec
document
is
concerned,
the
Sid
algo
was
adopted
I
think
two
ideas
ago.
Currently
it's
in
the
expired
state,
so
it's
a
zero
zero
draft
that
that's
been
expired.
They
are
even
pending
comments
from
the
working
group
adoption
stage,
so
I
really
request
authors
to
refresh
this
work
like
there
is
all
this
energy
during
adoption,
but
after
adoption,
authors
kind
of
forget
about
the
work,
so
that
should
not
happen.
B
B
And
some
recent
documents
we
had
peace
up
path
MTO
when
we
adopted
this
work,
we
we
are.
We
pointed
out
that
there
should
be
a
work
in
Spring
that
should
coordinate
this.
That
should
Define
what
path
MTO
is
in
Sr
policy
context
and
both
IDR
document
and
P
sub
document
should
refer
to
that.
The
new
ID
has
been
published
in
Spring,
it's
been
presented
twice
now.
Hopefully
it
will
get
adopted
there
as
well,
and
then
the
dependencies
will
also
be
clear
and
we
can
progress
the
work
in
peace
up
as
well.
B
We
have
a
document
iFit,
which
is
anyway
on
the
agenda,
so
I
will
leave
it
out
for
the
for
the
actual
presentation,
a
recent
adopted
document
we
have
srv6
Yang,
which
is
adopted.
It
is,
of
course,
being
dependent
on
our
peace
of
yank.
So
let's
publish
that
and
then
we
can
make
progress.
Good
thing
is
that
it's
been
updated
and
the
alignment
work
between
PCP
and
srv6
yang
as
ongoing
one
thing
to
note
is
the
document
is
called
srv6
yank,
but
it
has
Sr
policy
as
well
as
srv6
stuff.
B
So
please
take
a
note
of
it
that
the
document
name
may
not
actually
reflect
what
what
it
actually
it
contains
both
the
things.
So
please
be
aware
of
that.
B
We
have
a
working
group.
Adoption
called
queue.
It's
in
the
wiki.
Please
give
us
feedback
if
you
have
a
need
for,
for
instance,
you
are
implementing
it
and
you
need
code
points
and
you
want
to
fast
track
something
your
chairs
are
listening.
Please
reach
out.
We
try
to
keep
our
Wiki
up
to
date
so
that
you
have
visibility
on
where
the
cues
are.
What's
the
priority
that
we
are
thinking,
so
please
use
our
Wiki
as
well.
B
So
we
have
two
discussions.
The
key
discussions
that
happen
between
the
meeting-
and
we
wanted
to
just
highlight
that
in
the
working
group
session
as
well
and
give
people
time
if
they
want
to
talk
about
it
further,
there
was
a
proposal
for
how
to
enable
BFD.
There
were
multiple
suggestions,
whether
we
use
Association,
whether
we
use
some
other
mechanism,
but
all
those
things
are
currently
still
only
on
the
mailing
list.
B
So
I
have
sent
a
personal
message
also
to
the
authors
that
let's
bring
the
work
into
ITF
by
writing
your
first
internet
draft,
so
that
we
can
follow
ITF
process
and
give
comments
rather
than
like.
You
know,
exchanging
Word
documents
and
doing
this.
That's
not
how
we
do
work
in
ITF,
so
I'm
waiting
for
the
internet
draft
to
be
published,
and
then
we
can
move
work
forward.
B
The
second
discussion
that
was
happening
was
with
respect
to
PC
operational
draft.
This
was
presented
in
the
last
meeting
and
we
did
discuss
what
should
be
the
next
step,
whether
we
should
break
the
document
into
two
have
a
very
clear
standards
track
document
which
clearly
says
what
needs
to
be
updated
and
have
a
much
more
bigger
clarification
document
that
talks
about
how
to
apply
PC
in
various
different
stateful
PC
in
various
different
scenarios,
give
clear
description.
This
has
been
discussed.
B
C
Thanks
John
scooter
excuse
me
yeah,
so
I
I
saw
your
your
comment
and
thanks
for
teeing
this
up
and
went
and
just
very
quickly
glanced
through
the
current
state
of
the
draft
I.
C
We
can
speaking.
You
know
in
terms
of
like
sort
of
progressing
it
through
the
iesg.
We
can
do
it
either
way.
As
you
know,
one
unified
draft
or
as
two
separate
drafts,
as
as
you
proposed
through,
but
I
will
say
that
I
think
it
will
go
more
smoothly.
I
mean
often
I
would
prefer
to
have
one
draft
just
to
progress,
fewer
documents,
but
I
think
it
will
actually
go
more
smoothly
to
have
one
tiny
standards
track
document.
That's
very
crisp
and
clear
and
one
informational
document
that
can
provide
as
much
color
commentary
and
detail.
C
As
you
know,
the
working
group
deems
necessary.
So
just
you
know,
from
sort
of
my
selfish
perspective,
of
of
wanting
to
have
an
easier
time
of
being
able
to
move
it
through
the
iesg
I
would
encourage
you
to
consider,
encourage
the
working
group
to
consider
the
the
two
document
option.
Thank
you.
Thanks.
B
B
Anyone
no
let's
move
on
this
is
again
in
our
Wiki,
a
page
that
we
created
mainly
focusing
on
coordination
with
other
working
group
and
research
groups.
So
again,
Wiki
is
open
to
everyone-
it's
not
just
for
chairs
and
securities
to
maintain
it's
for
the
whole
working
group.
So
when
we
have
any
work
that
you
are
similarly
doing
in
some
other
working
group
where
the
coordination
is
needed,
please
come
and
keep
this
Wiki
up
to
date.
For
instance,
we
have
a
lot
of
work
coming
from
beer
from
detnet
from
various
different
things.
B
We
want
to
coordinate
as
as
much
as
possible
because,
as
you
know,
we
have
noted
problem
later
in
this
thing,
where
IDR
does
the
same
thing,
but
in
a
different
way,
and
we
miss
out
something
in
PC.
So
we
want
to
avoid
those
things
going
forward.
So
one
of
the
steps
that
we
thought
that
we
could
do
this
coordination
visibility
much
more
much
more
better
by
using
our
Wiki.
So
please
keep
them
up
to
date.
B
I
have
put
many
documents
list
already,
but
I
would
prefer,
if
authors
do
that
and
they
have
the
best
visibility.
So
please
use
this
so
I
just
want
to
send
a
reminder
there.
Thank
you
and
that's
it
any
last
thoughts
from
anyone
on
any
of
the
working
group
documents.
Otherwise,
we'll
go
to
the
agenda.
E
E
It's
very
odd.
This
microphone
is
at
the
right
height
almost
thank
you
very
much.
E
Get
away
from
everybody
hey
so
Russ,
Housley
and
myself
are
writing
this
draft
in
net
cloth
and
we
said
hey.
What
are
we
going
to
do
about
TLS,
1.3
and
the
use
of
net
cloth?
And
it's
got
some
dragons
and
drove
rightly
noticed
that
maybe
this
draft
pretty
much
equally
applied
here.
E
So
he
was
like
hey
what
about
this
draft,
so
we
pretty
much
said
Hey.
How
do
we
get
together
and
do
this
draft
together?
So
we
took
the
text
tweaked
like
very
slightly
and
over
here,
so
next,
so
basically,
the
motivation
is
that
8253
defines
how
to
protect
PCP
cap
with
TLS
1.2
and
with
1.3.
You
can
just
say
something
as
well.
You
can't
just
say
next
version,
because
this
little
tweak
that
we've
defined
called
zero
rtt
and
with
zero
RTG.
E
There
are
some
dragons,
because
this
particular
mode
of
using
TLS,
the
the
the
the
flight
of
messages
includes
some
Badness.
So
it's
replayable
and
you
have
to
make
sure
that
you
have
you
have
the
ability
to
like
protect
against
that
and
depending
on
your
protocol,
you
also
don't
need
it.
So
the
idea
that
you
can
essentially
profile
a
particular
version
of
the
of
the
protocol.
You
can
do
that.
So
that's
what
this
draft
is
all
about.
E
So
the
idea
is
to
basically
be
explicit
about
the
protocol
profile
and
it's
really
about
like
mostly
it's
like.
Don't
use
this
particular
mode,
and
you
know
otherwise
just
basically
be
exactly
like
the
other
version
next,
so
early
data
is
really
simple
again.
So
the
idea
is
that,
like,
if
you've
connected
to
a
site
before
when
the
next
time
you
talk
to
them,
you
don't
have
to
worry
about
reauthenticating.
You
can
just
use
this.
E
E
If
you
don't
have
a
lot
of
reconnection
options
or
you
don't
use
it
that
way,
just
don't
use
it
so
because
you
don't
have
to
worry
about
it
because
to
set
it
up,
you
essentially
have
to
like
do
a
lot
of
Replay
protection
and
it's
not
needed
so,
and
the
comments
during
the
discussion
of
the
working
group
was
actually
really
interesting
because
Tom
was
like
hey,
you
don't
need
this
and
he
said
a
lot
of
very
strong
things
which
I
don't
agree
with
everything
he
said,
but
I
was
kind
of
like
all
right,
he's
kind
of
right.
E
At
the
end
of
the
day,
it
basically
said,
like
hey,
if
you're
going
to
run
this
you
don't
if
you're
going
to
run
TS
1.3,
you
could
do
it,
you
just
don't
need
it.
So
actually
we
reported
the
comments
from
this
we're
in
group.
Adoption
back
into
netcomf
and
the
net
conf
working
group
was.
E
E
And
then
Cypher
Suite,
so
that
they're
slightly
different
in
the
way
that
you
actually
specify
The,
Cypher
Suites,
you
specify
less,
which
is
okay,
because
the
actual
like
mandatory
Implement
cyber
Suites
went
from
like
a
long
list
to
like
four,
and
so
we
picked
less
and
that's
better
because
it's
you
know
the
the
ones
that
were
picked
by
the
overall
ITF
or
better,
but
there's
less
to
pick
from,
and
that's
in
some
respects
better,
because
that
means
people
concentrate
on
the
ones
that
you're
picking
and
so
go
with
those
and
and
there's
there's
this
little
option
about
forward
secure
forward
security
which
people
may
or
may
not
care.
E
So
the
idea
is
that,
if
the
force
security
is
that,
if
you
are
able
to
capture
a
connection
or
a
sequence
of
of
flights
of
messages
and
then
later
on
break
it,
you
can't
later
go
back
and
break
it.
So
it's
good
that
you're
able
to
ensure
that
the
things
that
are
that
were
done
in
the
future
are
all
right.
So,
at
the
end
of
the
day,
the
protocols
is
better.
It's
more
provably
secure.
E
B
Just
one
slide
since
I'm
the
author
for
the
piece
of
Yang.
Let
me
just
explain
what
we
did
here
so
basically
we
use
the
netcon
document,
which
has
the
all
the
groupings
related
to
how
we
configure
TLS,
client
and
TLS
server,
and
that
grouping
basically
says
we
can
configure
any
version
of
TLs.
But
we
are
going
to
recommend
that
you
use
TLS
1.3
and
we
know
that
in
psip
there
are
still
implementations
that
are
currently
using
TLS
1.2.
B
We
want
our
Yang
model
to
be
able
to
be
used
in
those
scenarios
as
well,
and
we
just
want
to
clarify
in
our
document
that,
yes,
it
is
still
possible
to
do
that.
You
have
a
feature
tls12
that
can
still
be
enabled,
even
though
the
Yang
model
says
it's
not
recommended,
but
that
doesn't
mean
that
it
cannot
be
used.
So
we
added
this
description,
a
specific
section
on
how
to
use
how
to
handle
this
TLS
version
issue
in
our
precept,
Yang
and
hopefully,
via
this
update.
B
G
A
A
As
a
result,
I'd
be
happy
to
see
a
show
of
hands
for
the
Abduction
of
the
document
and
the
progress
of
this
work.
So
if
you
agree
on
support
this
item,
raise
your
hand
if
you
oppose
don't
raise
your
hand
and
ideally,
if
you
don't
care,
just
don't
respond.
A
A
F
F
Contain
a
planting
seed
PC
will
send
the
data
bonding,
which
is
a
contains
binding
seed
plus
these
services
to
the
node,
for
example.
Here
we
have
a
path
from
pe1
to
P1,
to
node
n
and
then
to
node
P3
P6
and
then
to
p
4.
So
basically,
this
is
Sr
pass,
contains
blue
segments
and
green
segments
and
then
blue
segments.
F
So
when
node
n
receive
a
package
with
a
binding
seat,
note
n
will
replace
that
button
sheet
with
that
list
of
seats,
which
here
is
node
n,
will
replace
brightness
seat
with
S1
and
S2,
so
SL1
S1
S2
determines
that
Grim
per
segment.
So
note
n
well
sit
in
the
package
along
that
green
past
segment
and
then
the
package
was
sent
along
the
path,
green
per
segment
and
then
blue
segment
to
the
destination.
Pe
4..
F
So
here
when
a
Sr
pass
contains
abundant
PC,
we're
sending
to
Notre
n.
So,
in
order
to
provide
protection
for
the
failure
of
lot
n
with
the
binding
binding
seat,
PC
will
be
extended
to
send
the
funding
information
plus
the
load
ID
of
load
n
to
the
adjacent
node
of
node
n.
So,
with
this
information,
the
adjacent
node
of
node
n
can
provide
protection
for
the
failure
of
load
n
regarding
to
The
Binding
seat.
F
It's
failed
and
then,
but
for
the
bundling
seat
on
No,
10
P1
will
just
acting
as
a
proxy
level,
then
replace
that
abundance
sheet
with
the
list
of
seat,
for
example,
S1
and
S2,
and
then
send
the
package
along
the
S1
as
S2,
for
example,
to
P3
and
then
P3
version
packaging
along
the
Korean
paste
desolation
here
in
the
last
Angel
Stone
Research.
Some
questions
regarding
regarding
this
one.
F
So
so
first
question
is
that
so
for
the
adjacent
node,
so
that
node
need
to
figure
out
something,
for
example,
if
a
segmentalist,
for
example,
S1
S2
here
is
adjacent,
is
adjacent.
So
in
this
case,
because
as
Jason
city
is
local,
so
P1
need
to
do
something.
So
in
this
case,
if
second
list
for
bonding
contains
the
adjacency,
basically
the
first
one,
which
we
just
considered
a
we
just
care
about
the
first
seat,
whether
it's
a
adjacency.
F
F
So
that's
one
question
raised
by
Angel,
Stone
and
then
I
just
answer
here:
do
you
have
any
questions
for
regarding
this
part.
H
Foreign
yeah,
so
I
saw
your
reply
this
morning.
Thank
you
for
that.
I
think
I've
got
a
few
comments
on
just
the
general
solution.
So
what
you
commented
on
yeah
totally
great
makes
sense
in
that
situation.
F
H
You
thank
you
I
think,
though,
it
creates
an
assumption
that
P1
in
this
situation
actually
has
the
capability
of
pushing
the
node
Sid
to
reach,
in
this
case,
for
example,
P3
as
well
as
the
remaining
SIDS
that
are
in
the
stock
being
provided
by
The,
Binding
Sid.
So
imagine
if
your
binding
Sid
is
instructed
with
five
labels
or
five
SRV
six
labels.
H
The
assumption
is
now
P1
can
do
you
know
four
plus
one
to
work
around
that
or
three
plus
one
to
work
around
that
so
I
I
think
that
kind
of
creates
an
implied
assumption
that
the
neighboring
node
has
the
sufficient
Hardware
capability
to
push
all
of
those
labels
of
the
path,
and
so
I
think
this
brings
probably
a
more
fundamental
question
of.
H
If
we're
trying
to
protect
n
and
The
Binding
Sid,
do
we
still
want
to
route
along
the
complete
path
that
the
Bindings
that
has
taken
or
do
we
want
to
rewrote
where
the
writing
set
terminates
because
you've
got
those
label
in
position
on
that
neighboring
node,
and
so
it
could
be
possible
that
your
neighboring
know
that
you're
transiting
through
P1
in
this
case
actually
can't
carry
all
of
that
traffic.
That
The
Binding
set
is
providing,
which
is
why
The
Binding
sit
exists
in
the
first
place,
so
it
kind
of
leads
then
into
I.
H
Think
another
open
question
of
or
another
open
challenge
is
that
the
assumption
is
P1
can
resolve.
Where
n
is
going
to
go
right,
so
the
local
adjacency
said
I
agree
with
you.
If
it's
you
know
an
igp
adjacency
SID,
it
can
figure
it
out
from
the
igp
information.
But
if
it's
in
a
different
domain
it
can't
if
it's
a
epe
sid
it
can't.
F
Yeah,
that's
a
good
question
yeah!
So
right
now
we
assume
that
igpe
will
distribute
those
kind
of
adjacency
and
then
the
P1
figure
out
that
one,
and
so
you
you
imply
that
maybe
pce
can
do
something
if
the
the
planting
segment
is
contain
the
adjacency
and
then
PC
may
just
figure
out
the
node
seat
of
a
P3
right.
So
that
notice,
since
then
notice
it
to
P1
and
that
is
P1
can
make
Poise
work.
Easy
right
is
that
your
comments.
H
Yeah
and
it
yeah
and
it
handles,
and
it
handles
other
situations,
especially
with
multi-domain
or
pcecc,
and
just
situations
where
P1
doesn't
know
where
that
said
is
going
to
go
and
and
it
and
it
opens
up
the
door
for
PC
to
decide
like
as
I
mentioned.
Instead
of
rerouting
to
the
next
node,
you
can
rewrote
somewhere
Downstream,
which
can
even
be
traffic,
engineered
right,
it
or
other
binding
sets.
It
opens
up
a
lot
more
flexibility
and
I.
H
You
know
descriptions
in
both
PC
and
IDR
and
so
I'm
wondering
if
the
solution
should
be
taken
out
into
let's
say
routing,
working
group
or
even
spring,
and
then
worry
about
the
encoding
after
the
fact,
because
the
encoding
between
bgp
and
P
sub
is
going
to
be
very
similar
situations.
It's
just.
How
do
you
actually
want
to
solve
the
problem
and
I
think
in
our
discussions
right
now,
I
think.
There's
a
few
different
ways
to
solve
it
and
I
think
there
needs
to
be
some
consistency
on
how
we
want
to
solve
it.
Yeah.
F
In
fact
that
this
is
a,
we
have
a
protection
drop
in
Spring
and
then
child
suppose
I
think
in
order
to
provide
protection
for
node
failure
responding
seat,
and
then
we
need
a
PC
or
igp
IDR
extension.
That's
why
we
come
here.
We
already
have
a
draft
for
protecting
the
planting
seed
in
Spring
group,
okay
and
then
we
need,
and
then
we
did
a
support
from
the
other.
H
Have
missed
that
I'll?
Take
a
look
for
that,
but
I
think
clarifying
exactly
how
we
want
to
protect
it
and
then
deal
with
the
encodings
after
because
there's
some
weird
quirks
here,
especially
when
you
start
talking
about
multi-area
multi-domain
different
types
of
Sids,
if
if
it
was
just
node
SIDS
in
the
stock
and
if
P1
had
enough
Hardware
capacity,
that's
not
a
big
deal,
but
unfortunately
that's
not
the
reality,
sometimes
so
anyways.
Thank
you.
F
Yeah,
thank
you
for
your
for
your
comment
on
the
suggestions.
I
think
this
is
for
the
SS
Angel
mentioned
that
this
is
so
for
the
node
n
is
which
in
the
domain
is
easy.
So
if
that
note
n
is
a
border
node
yeah.
That
case
is
even
tougher
because
border
node
and
then
the
previous
over
the
uptrend
node,
do
not
know
the
past
segment
because
that
domain,
so
in
in
that
case,
so
we
needed
to
have
equals
production,
because
that
no
10
is
an
eagerness
node.
F
So
we
need
to
have
a
backup
equals
node
to
be
assigned
to
protected
node
end,
and
then
we
have
those
kind
of
a
that's
the
requirement.
You
you
said
question.
So
if
node
N
is
a
border
node
and
then
the
board
node,
we
have
a
backup
border
node
and
then,
in
that
case
and
then
backup
buttoners
know
the
information
about
another
domain
with
same
information
as
another
n.
H
D
H
The
Binding
Sid
is
still
part
of
that
end-to-end
packet
that
n10
path,
there's
no
de-encapsulation
at
that
point.
So
at
that
point,
when
it's
leaving,
you
know
a
domain,
it's
still
part
of
that
tunnel.
So
it's
not
necessarily
egressing
the
tunnel.
It's
just
egressing
the
domain
or
the
forwarding
instructions
where
the
control
plane
in
that
domain
has
a
view
and
perspective
of
what's
beyond,
but
it's
still
in
the
same
tunnel.
So
I
think
the
egress
protection
is
more
applicable
onto
egressing
of
a
tunnel.
F
H
F
B
F
F
F
For
distributed
bonding
to
the
adjacent
node,
so
because
this
is
not
a
really
funding,
so
we
need
to
have
indications
to
indicate
that
this
is
just
for
funding
protection.
So
here
we
have
extensions
to
RP
and
the
SRP
object.
So
in
this
object
we
have
a
percent
of
POV,
so
this
is
tlv
will
contain
a
new
password,
PhD
type,
which
indicate
that
this
is
just
for
distributed
abundant
for
protection.
F
So
next
page
I
think
that's
all,
and
then
we
would
like
to
have
a
comment
from
all
of
you.
B
Let
me
put
myself
one
comment
as
a
contributor,
especially
I,
think
I
agree
with
a
lot
of
things
that
Andrew
mentioned
so
I
think
we
need
to
take
at
least
the
core
of
the
work
in
spring
or
in
rtgwg,
where
we
describe
how
this
thing
process
needs
to
work,
and
there
are
various
options
as
well
like.
Should
we
only
node
IDs
needed?
Do
we
need
destination?
Do
we
need
path?
B
Do
we
need
what
we
are
protecting,
what
all
the
information
that
we
need
to
exchange
from
a
PC
or
from
IDR
point
of
view
that
we
need
a
little
bit
more
clarification
on
that
and
then
once
we
come
to
the
extension.
B
That
work,
of
course,
will
belong
in
the
PC
working
group
and
even
with
the
extension
part,
we
can
debate
on
what
will
be
the
best
way
to
encode
this
information.
But
that
is
premature
because
we
don't
really
know
right
now
what
all
information
it
is
if
it
is
just
node
ID,
maybe
what
you
have
makes
sense,
but
if
we
also
put
paths
and
all
so
what
you're?
B
B
C
John
Scudder,
actually
I,
think
all
I
really
want
to
say
is
plus
one.
Please
do
the
work
once
in
a
group
that
has
the
the
core
expertise
to
get
the
architecture
right
and
then
it'll
be
really
easy
to
do
the
rest
of
it
here
after
that's
done.
Thank
you.
I
Hello,
everybody:
this
is
an
update
about
this
draft
that
has
been
adopted
just
last
ATF,
so
next
slide
I'm
present
I'm
Joseph
I'm,
presenting
on
behalf
of
the
co-authors,
so
yeah
few
words
about
the
background
and
motivation.
So
with
iFit
with
the
notes,
the
data
plane
on
path
Telemetry
in
particular
in
c2im,
that
is
defined
in
the
RFC
9197
and
Alternate
marking
that
which
the
standard
track
documents
are
in
NFC
area,
editor,
2,
the
8321
bits
and
8889bs.
So
let's
say
the
data
plane
methodology
are
stable.
I
So
here
we
want
to
define
the
psap
extension
to
distribute
paths
carrying
iFit
information,
so
a
PCC
can
indicate
which
I
fit
features
it
supports
and
the
PCA
can
configure
the
specific
behavior
at
the
PCC.
So
the
effect
attributes
can
be
generalized
and
include,
as
tlv
carried
in
the
ls
in
the
lspa
object.
So
next
slide.
I
I
In
addition,
we
Define
also
the
attributes
dlv
that
provide
the
configurable
option
for
the
features
for
the
fit
feature
and
it
can
be
included
as
an
optional
tlb
in
the
lspa
object,
as
I
also
mentioned
before,
and
so
the
five
sub
tlbs
that
are
defined
are
the
four
tlv
for
nc2m
and
one
for
alternate
marking
more
details,
of
course,
are
within
the
draft
time.
I
missed
here
the
details
because
we
already
presented
last
time
so
next
slide
yeah
I
just
this
is
maybe
the
last
slide.
I
I
just
want
to
summarize
the
changes
from
the
zero
zero
version,
because
we
had
some
comments
after
the
adoption
and
during
the
adoption.
So
we
we
addressed
this
comment.
We
clap
mainly.
We
clarify
that
the
head
end
needs
support
the
if
it
capability,
and
it
is
supposed
that
at
least
two
nodes
on
the
path
support
the
fit
capability.
I
We
also
clarified
that
the
fit
methods
are
more
mature
for
srv6
compared
to
SRM
apls,
in
fact,
in
in
the
implementation
of
bought
in
c2im
and
Alternate
marking
for
mpls
are
still
under
discussion
with.
So
there
was
a
comment
to
remove
all
the
references
to
this
draft
that
are
not
stable,
so
we
only
keep
the
references
for
the
srb6
implementation
that
are
the
the
references
are
quite
stable.
I
I
You
know
that
bot,
psap
and
bgp
can
be
used
to
instantiate
Sr
policy,
so
it
is
reasonable
to
have
the
same
mechanism
for
both
psap
and
bgp,
so
we
are
also
trying
to
keep
the
two
drafts
aligned
and
we
also
clarify
the
methodology
with
regard
to
the
framework,
and
then
we
had
also
added
additional
editorial
comments,
so
next
slide
yeah
we
found.
Let's
say
this-
is
a
document
relevant
to
enable
bottom
and
Alternate
marking
control
mechanism.
I
A
No,
no!
Thank
you
Elizabeth.
Okay,
thanks
for
the
follow-up,
so
the
next
presentation
is
for
control
identifier,
space
by
Han.
G
G
Should
be
able
to
okay,
hello,
everyone,
my
name
is
Hunter
and
I'm,
going
to
talk
about
the
psap
controlled
ID
space,
an
extension
to
the
PC
yeah.
As
we
all
know,
we
use
pce
to
allocate
the
srmps
enable
and
the
srv6
seat,
but
this
route
assume
the
naval
and
ID
range
to
be
used
by
the
VC
is
normal
and
set
on
both
PC
peers.
G
So
our
document
specified
the
intention
to
support
the
advertisement
of
the
IDS
base
to
the
PC
to
control
yeah
basic
news.
It
drops
is
very
simple
to
to
delegate
in
the
ID
space.
The
ID
space
TRV
is
included
in
the
open
message
and
the
etlv
corresponding
to
each
ID
type
should
be
included
only
once
in
the
open
message.
If
it
appeared
more
times,
only
the
first
one
will
be
used
and
we
Define
two
kinds
of
ID
controls
with
TRV.
G
The
first
one
is
for
srmps
enables
it's
called
enable
control
space
and
the
second
one
is
for
SRA
6
C
functional
ID
space
is
called
the
functional
ID
control
space
yeah,
the
the
first
one
is
the
naval
controls
with
TRV.
It
contains
the
following:
Fields:
the
first
field
is
the
number
of
the
ID
blocks
and
the
flags
is
zero
and
follow
the
apply,
the
various
the
enable
range
and
for
the
srv6
function,
ID
control,
space
TRV.
G
It's
including
the
the
Nokia
tournaments
the
functions
and
arguments,
and
then
we
have
see
the
range
and
if
the
air
bit
in
the
flag
is
that
the
locator
will
included
if
the
lbs
is
not
set,
that
means
the
the
seed
function
range
is
applied
to
all
locator.
G
And
basically
it
says
it's
a
Samsung
update
from
the
NASA
presentation.
We
expanded
the
sra6
pass
ID
to
various
function,
ID
and
we
add
the
C
structure
to
describe
the
the
seed
and
we
add
the
block
of
field
for
better
expensibility.
Then
add
me
as
a
new
new
co-author,
so
we
are
I.
Always
we
think
the
content
is
stable,
so
we
are
asking
for
the
working
group
adoption
opposite
draft.
B
D
J
C
G
So
my
second
draft
is
about
a
pce
initiated
IP
IB
terminal
yeah.
Basically,
the
motivation
is
that
in
the
sty
use
case,
ipturnal
is
needed
to
Traverse
the
one
and
pce
can
use
as
a
control
protocol
to
initiate
this
IP
terminal,
and
this
is
also
a
simple
draft.
Basically,
you
need
to
divide
advertise
the
the
hypertonal
compatibility
and
to
set
up,
maintain
and
tear
down
the
IP
kernels
initiated
by
the
pce,
since
this
is
only
the
first
draft.
G
We
do
not
include
the
internal
stage
synchronization
and
various
timeout
process
session
final
process
in
the
in
this
draft
yeah
the
PC
initial
internal
capability
TR
we
designed
as
follows:
yeah
there
is
a
32-bit
Channel
type.
If
a
PCC
can
support
this
kind
of
Kernel
One
beta
is
set.
We
pick
the
we
pick
the
mostly
used
terminal
in
the
in
the
right
table,
foreign.
G
With
design
the
following
message,
the
first
one
is
the
PC
internally
initiate
message
to
initiate
alternator
tunnel
PC
is
sent
to
the
PCC
and
there
is
a
flag
that
we
indicate
if
it's
initiate
what
it
did
and
the
second
one
is
the
PC
terminal
update
message
to
modify
the
parameter
of
the
kernel.
It's
also
sent
by
the
pce
to
PCC
and
the
third
one
is
this
internal
report
message
is
for
the
PCC
to
report
the
state
of
the
terminal
to
the
pce,
and
this
message
compromise
the
SRP
object.
G
It
contains
the
ID
to
coordinate
it
between
the
initiate
and
Report
or
the
PC
error.
Message
under
Arsenal
indicates
that
in
initialization
origination
and
the
message
also
contains
Eternal
objects
yeah
for
the
kernel
object.
There
is
many
some
TRV
for
the
first
one
is
the
internal
ID.
Trv
contains
the
source
stress
that
designation,
dress,
internal
type,
internal
ID
and
the
second
one
is
the
internal
name
TRV
and
the
third
one
is
the
internal
parameter.
It
depends
on
the
ternal
type.
G
We
reuse
the
tunnel
parameter
from
the
bgp
Eternal
type,
so
it's
basically
in
the
same
format
and
the
terminal
attribute
TRV
contains
the
metric
or
the
T
metric
The
Matrix
is
used
as
a
kind
of
the
T
metric
used
as
the
the
requirement
and
the
metric
is
used
for
the
for
the
report
yeah,
since
this
is
only
the
the
first
basically
the
first
round.
We
would
like
to
solicitate
the
feedback
on
this
route,
for
example,
which
type
of
alternative
support
in
this
in
this
kind
of
five
internal.
G
H
H
I
I
guess
the
root
question
I
have
is
why
use
piece
up
for
this?
If
there's
no
path
to
compute.
G
H
Guess
I
just
see
what
is
the
benefit
of
using
psup
to
do
it
compared
to
something
just
you
can
program
anything
with
netcon,
for
example.
So
it
just
seems
like
a
lot
of
defining
to
be
done
for
just
essentially
at
the
end
of
the
day,
just
basic
configuration
because
you're
not
doing
make
before
break
path.
Calculations
you're,
not
doing
state
tracking
in
order
to
react
to
those
States
information,
so
it
just
it
just
feels
heavy
to
me.
G
H
J
Years
ago,
because,
but
later
we
found
that
we
found
identify
this,
the
new
user
cases
that
use
the
ip800
to
transfer
this-
the
network,
for
example
in
the
sd-1
use
cases,
because
maybe
that's
used
to
utilize
this
IP
tunnel
to
Traverse
this
underlying
Network,
so
that
we
need
to
initiate
this
IP
tunnel
by
the
controller.
So
we
think
use
the
pce
that
is
has
achieved
this
better
sustainability
and
performance.
So
we
we
start
this
work
and
the
comments
will
come.
Okay,.
K
As
for
the
presentation
in
the
introduction
section
of
the
draft,
the
the
use
case
or
what
is
what
is
mentioned
there,
is
that
this
tunnels
help
in
addressing
the
label
stack
depth
issue
MSD
issue
I
mean
it's
different
from
what
was
presented
today
and
my
question
is:
how
does
it
help
there
and
is
that
really
the
use
case.
K
Okay,
so
what
I
would
suggest
is,
if
you
could
kind
of
put
some
more
text
to
explain
or
Justify
those
use
case
and
how
these
things
would
help
there.
That
would
be
helpful.
I
I
concur
with
what
Andrew
mentioned,
so
we
need
to
probably
help
understand
if
this
is
really
needed
or
a
right
way
to
go
about
it.
Thank
you.
Okay,
foreign.
J
B
Let
me
have
myself
in
the
queue
then,
thanks
for
thanks
for
your
comment,
but
I
think
the
motivation
is
needed
in
the
draft
itself.
We
need
to
clearly
specify
why
we
need
this
functionality
and
not
just
because
why
we
need
IP
tunnels.
B
That
part
is
clear
basically,
but
why
we
need
to
use
psip
as
the
interface
for
that
IP
tunnel
and
that
we
need
a
Clarity
before
we
progress
this
then,
when
it
comes
to
encoding
again,
we
have
to
make
a
choice
is:
do
we
want
to
go
through
new
messages
for
this
or
we
have
path
setup
type?
We
already
allow
path,
setup
type
to
handle
srv6,
which
is
sort
of
an
IP
tunnel
in
a
way.
So
do
we
need
a
brand
new
set
of
messages
to
go,
or
should
we
use
our
existing
Machinery?