►
From YouTube: IETF112-PCE-20211110-1430
Description
PCE meeting session at IETF112
2021/11/10 1430
https://datatracker.ietf.org/meeting/112/proceedings/
B
A
So,
let's
start
hello:
everyone
welcome
to
the
past
computation
element
working
group
first
session.
So,
as
you
can
see
here,
as
you
probably
noticed
on
the
agenda,
we
will
have
a
second
session
on
friday
afternoon
or
friday.
Whatever
time
zone
you
live
in,
so
we'll
try
to
fill
on
respect
the
scheduled
agenda,
it's
tied
for
both
sessions,
so
we'll
try
to
move
on
time
next,
please
so
you
should
all
be
familiar
with
the
usual,
not
well
usual
reminder
about
the
ipr
rules
within
the
atf.
A
You
should
be
aware
of
that
when
you
sign
to
the
medical
tool
when
you
book
the
atf
attendance,
I
guess
as
well.
So
if
you
aren't
familiar
with
those,
please
have
a
look
at
the
references
here
remind
that
anything
you
say
share
or
follow,
discuss
within
the
etf.
This
may
maybe
subject
to
some
idf
processes
related
to
the
ipr
rules,
so
please
follow
them.
A
A
The
guidelines
are
for
conduct,
so
we
know
that
since
we
don't
meet
face
to
face,
sometimes
the
relationship
between
people
may
be
a
bit
different
because
we
don't
see
each
other
so
keep
in
mind
that
we
are
all
respectful
young
beings,
we're
all
expected
to
respect
our
colleagues
and
be
kind
with
them.
We
may
have
disagreement
at
some
point,
but
we're
supposed
to
have
in
personal
technical
discussions.
A
A
A
A
A
So
we
have
harry
acting
as
a
secretary
for
a
session
he's
using
the
the
notes,
new
url
notes,
itf.org
the
kodi
md2,
to
take
the
minutes.
If
you
want
to
give
him
a
hand,
please
feel
free
to
connect
to
the
outside
f4.org.
A
The
better
the
more
people
using
it
on
putting
footer
the
better
the
methods
will
be
at
the
end
about
the
session
itself.
If
you
want
to
join
the
queue
you
have
the
mythical
icons
to
raise
your
hand,
you
will
be
given
the
floor
at
your
turn.
Remember
to
state
your
name.
There
is
all
your
recording
in
progress
and
as
usual,
since
we
have
tight
agendas,
try
to
be
mindful
of
your
time
and
try
to
include
the
questions
and
comment
as
part
of
your
slot
when
you're
presenting
thanks
next,
please.
A
Please
try
to
be
as
vocal
as
possible
when
we
are
sending
some
polls
on
the
mailing
list,
working
with
lascal
documented
options.
Ipr
checks,
of
course,
so
make
sure
that
you're
catching
up
with
the
topic
discussed
and
please
feel
free
to
create
new
thread.
If
necessary,
you
don't
have
to
wait
for
a
slot
during
the
meeting
to
start
new
work
or
progress
existing
works,
we
have
a
wiki
which
is
full
of
very
relevant
information.
A
A
And
don't
forget
to
request
cutpoint
early
quarter
location
if
you
feel
that
you
have
implementation
at
stake.
That
may
require
cut
point
before
the
document
is
published
as
an
lc
and
has
gone
through
the
inr.
There.
C
A
D
D
So
a
version
13
was
posted
to
strip
the
blocking
part,
which
was
the
l2
vpn
flow
spec
from
this
id,
because
that
is
now
dependent
on
the
flow
spec
v2
work,
which
is
ongoing
in
idr,
and
a
separate
id
has
been
created
where
we
have
moved
the
content
related
to
l2
vpn
flow
spec
into
a
separate
id.
So
one
option
that
the
authors
asked
was:
can
this
be
quickly
adopted
since
the
content
was
already
in
a
document
which
had
the
working
group
and
in
fact
itf
consensus?
D
So
can
we
do
a
quick
working
group
adoption
call,
so
this
question
is
still
open.
If
anybody
has
any
comments
and
thoughts,
please
join
the
queue,
otherwise,
I
am
sure
julian
will
take
an
action
on
it.
Since
I
am
a
co-author,
the
next
document
that
we
have
is
the
binding
sid.
This
is
the
document
with
with
our
ad.
Our
ad
gave
comments
and
I
think
the
authors
have
updated
it
and
handled
the
comments.
So
now
it's
just
wait
waiting
for
ad
to
go
ahead.
John,
do
you
have
any
comments
on
this?
E
I
know
I
don't
acknowledge
that
I'm
that
you're
waiting
on
me,
so
I
will
get
to
those
soon.
Thank
you.
Thank
you,
john.
D
So
next
we
had
an
erata.
This
was
an
errata
based
on
the
rbnf
ordering
with
respect
to
lsp
object
and
class
type
object
in
pc
request.
D
This
was
rejected
and
john
gave
his
reasoning
clearly
on
the
mailing
list,
and
there
was
some
free,
some
corresponding
discussion
as
well
on
the
thread
on
how
we
can
resolve
such
a
problem.
There
is
a
new
id
proposed
on
it
and
it's
on
the
agenda
on
the
friday
session,
where
we
can
discuss
this
in
more
detail.
D
We
have
three
documents
which
had
asked
for
early
ina
code
point,
and
all
of
these
are
allocated.
Please
note
the
expiry
date,
so
the
expectation
is
that,
if
there
is
a
second
call
needs
to
be
made
for
extending
just
keep
this
in
mind.
Ideally,
we
would
like
to
if
the
document
is
ready
within
that
timeline.
That
would
be
much
better.
Otherwise,
we
would
need
to
request
an
extension.
D
These
are
the
documents
which
are
nearing
working
group
last
call
which
is
stateful
gmpls.
I
think
authors
have
done
their
job
and
it
is.
They
have
confirmed
that
it
is
ready
for
working
with
lascal,
and
I
think
the
chairs
will
take
an
action
on
it
next,
pretty
soon
with
the
second
document.
So
I
request
authors
if
they
disagree
with
what
I'm
saying
and
if
they
have
further
comments,
please
join
the
queue
and
I
will
give
you
the
floor.
D
D
Just
to
recap,
when
we
polled
for
interest
on
this
document,
we
did
not
get
much
interest
shown
on
the
list,
some
of
the
options
that
we
were
thinking
that
maybe
we
can
make
it
experimental,
but
even
if
we
do
that,
we
would
still
need
more
people
to
review
and
send
comments
and
confirm
that
they
feel
like
the
document
is
ready
for
publication
as
an
experimental
document.
D
Another
option
was
that
we
mark
it
in
our
data
tracker
as
waiting
for
implementation
and,
let's
see
if
one
of
the
work
like
maybe
stateful
inter
domain
or
some
other
work,
take
up
this
enhanced
error
mechanism
and
start
using
it
and
implementing
it,
and
at
that
time
it
would
be
a
good
idea
to
maybe
publish
the
two
work
together.
So
we
are
still
waiting
for,
like
you
know,
decision
on
this.
D
If
anybody
has
any
thoughts,
please
reach
reach
out
to
chairs
at
any
time,
and
after
this
itf
most
probably,
we
will
be
making
a
decision
on
this
pretty
soon.
D
Next,
we
have
psep
yank.
This
an
update
was
posted
on
this
last
month.
The
comments
were
there
from
tom
patch
and
thanks
for
him
for
doing
a
good
review
and
always
providing
comments
with
each
update.
The
yang
doctor
review
on
this
document
is
pretty
old,
so
I
think
one
is.
We
can
look
for
a
young
doctor
review
and
even
working
group
last
call
next
the
thing
to
note.
D
On
the
right
hand,
side
is
the
dependencies,
so
it
is
dependent
on
some
documents
like
itf,
tls,
client
and
itf
tls
solver,
both
of
them
in
working
group
last
call
in
netconf
itfte
in
teas,
is
also
in
the
queue
for
working
group
last
call,
so
I
think
psepjank
can
move
and
all
our
dependencies
are
kinda
handled,
and
this
document
could
also
be
moved
to
working
up
last
call
and
yang
doctor
review,
etc.
Pretty
soon.
D
I
wanted
to
highlight
about
native
ip.
We
posted
it
on
the
idr
list
that
we
are
looking
for
feedback,
since
this
is
related
to
bgp
session
establishment
via
psep.
We
have
also
authors
have
asked
for
agenda
time
in
the
idr,
so
in
tomorrow's
session
on
thursday
they
will
be
discussing
and
we
hope
to
get
some
early
feedback
from
the
idea
on
this,
and
whenever
we
do
the
working
group
class
call
on
this
document.
D
I
will
make
sure
that
we
cross
post
it
in
the
both
working
group
so
that
there
are
not
no
late
surprises
when
it
moves
out
of
the
working
group
with
flex
grid.
There
hasn't
been
a
change
for
a
pretty
long
time,
but
authors
want
to
give
a
chance.
Do
you
think
the
document
is
ready?
Is
there
any
open
issues
with
it
if
they
have
any
information
that
they
won't
pass
on?
This
is
a
good
time
to
do
that.
D
D
D
I
don't
see
anyone
coming
in.
I
will
wait
for
a
second,
no,
the
next
one
we
have
vn
association
in
this
authors
have
confirmed
that
this
is
ready,
so
we
will
take
an
action
on
it
accordingly,.
D
The
two
sr
path
segment,
an
sr
bi-directional
document-
these
have
have
been
updated,
but
not
too
much
of
technical
changes,
mainly
sync
up
with
published
documents.
I
don't
see
any
open
issues
on
these
documents,
so
hopefully
these
documents
are
also
nearing
working.
Group
last
calls,
if
any
of
the
authors
want
to
say
something,
please
go
ahead.
Otherwise
this
is
the
status
as
for
working
group.
D
That
this
document,
the
the
candidate
path,
sr
policy
document
it's
on
the
agenda,
so
we
will
discuss
this
next
anyways
with
respect
to
local
protection
enforcement.
There
was
an
update,
no
significant
change.
There
is
an
ina
allocation
for
this
and
I
think
if
the
document
is
ready-
and
there
is
nothing
pending-
I
think
I
request
authors
to
prepare
and
ask
for
working
group
last
call
accordingly
andrew
go
ahead.
F
Yeah
this
is
andrew
yeah.
I
just
wanted
to
acknowledge
that
it's
basically
just
been
kind
of
sitting
in
a
steady
state.
So
if
anybody
has
any
concerns
or
comments,
definitely
I'm
all
ears.
Otherwise
I
mean
it's.
It's
there.
It's
pretty
straightforward,
there's
two
implementations.
D
We
have
a
pcc
sr,
there
was
an
update
and
they
have
done
the
alignment
with
the
published
rfc
1950.
So
thanks
for
that
for
stateful
interdomain,
we
did
not
have
an
update
this
time
for
extended
flags.
D
D
Multipath
is
on
the
agenda.
The
state
sync
was
updated
and
again
the
comments
that
were
received
during
the
adoption
call
were
handled.
So
thanks
authors
for
that,
and
finally,
this
is
our
recent
adopted
working
group
document
on
optional
objects.
The
authors
have
posted
an
update
and
have
handled
comments
during
the
working
group
adoption.
So
thanks
again
for
that
and
finally,
this
is
our
working
group
adoption
poll
queue.
There
is
an
ongoing
call
for
srp
to
mp
policy
and
our
plan
is
to
do
a
reshuffling
of
our
queue.
D
So
after
it
of
112,
we
will
reshuffle
our
adoption
queue
based
on
the
feedback
that
we
get.
So
if
you
have
any
comments,
please
reach
out
to
our
chairs
during
this
time
and
we
will
be
publishing
the
updated
poll
queue
on
our
wiki.
That's
it.
If
anybody
has
any
comments
on
the
working
group
documents.
Please
use
this
time.
Otherwise,
we'll
move
to
the
main
agenda.
B
Thanks
hi
everybody,
I'm
michael
I'm
from
cisco
systems,
presenting
piece
of
extensions
for
signaling
multi-path
information
on
behalf
of
my
co-authors
next
page,
please
so
just
to
give
a
quick
review
of
what
this
draft
is.
You
know
high
level
about
is
that
if
you
have
the
pc
compute.
B
So,
for
example,
if
you
want
like
to
send
just
a
pc
request
with
requesting
a
path,
you
can
use
all
these
extensions
just
as
well
next
slide,
please.
B
So,
basically,
without
this
draft,
pc
can
only
return
either
zero
or
one
forward
pass
in
response
to
a
computation
request.
So
this
was
sufficient
for
rcpt
tunnels
because
they
always
follow
like
each
hop
is
one
link,
then,
with
sr
policy
we
required.
B
That
there
could
be
multiple
forward
paths
for
a
certain
candidate
path,
and
so,
as
our
policy
has
this
concept
of
segment
lists
under
each
candidate
path,
and
so
the
traffic
towards
each
candidate
path
is
spread
out
among
the
different
segment
lists,
and
so
this
draft
was
originally
motivated
by
this
application
of
multiple
segment
lists.
B
B
We
allow
not
only
four
multiple
forward
paths,
but
we
allow
multiple
reverse
paths
to
be
returned
and
there's
a
kind
of
a
detailed
mapping
from
each
forward
path
to
a
set
of
reverse
paths
and
from
each
reverse
path
to
a
set
of
forward
paths
that
I
will
examine
in
the
next
few
slides
next
slide.
Please.
B
So
we
just
defined
this
tlv
called
opposite
direction.
Path,
tlv
and
this
tov
goes
into
the
path,
attributes
object
and
it
specifies
the
one
of
the
reverse
paths,
or
one
of
the
opposite
direction.
Paths
to
the
to
the
path
that
to
the
path
of
the
like
the
current
path
attribute
object.
B
So
basically
there
could
be
multiple
copies
of
or
multiple
instances
of
this
tlv
in
each
path.
Attributes
object
because
there
could
be
multiple
reverse
paths
for
a
given
forward
path,
and
it's
also
not
necessarily
true
that
if
path,
one
is
the
opposite
of
path,
two,
it
is
not
necessarily
true
that
path.
Two
is
the
opposite
of
path
one.
So
basically,
this
opposite:
oppositeness
property
is
not
mutual
and
I'll.
Give
an
example
of
that
later.
B
So
here
we'll
go
through
an
example
of
circuit
style,
as
our
policies,
so
circuit
style,
as
our
policies
are
basically
basically
kind
of
two
policies
from
opposite
head
ends
or
opposite
routers
and
the
the
paths
of
these
policies
are
very
tightly
coupled
so
each
router
when
it
sends
traffic
in
the
forward
direction.
It
knows
that
the
reverse
traffic
will
come
back
in
on
the
same
set
of
links
in
the
reverse
direction.
B
What
we
want
to
do
is
we
want
each
each
of
the
routers.
So,
for
example,
in
this
in
this
picture
here
there
is
h1
and
e1,
which
are
like
the
pe
routers
that
have
sr
policies
so
there's
basically
an
sr
policy
going
from
h1
to
e1
and
the
reverse
sr
policy
going
from
e1
to
h1.
B
B
Is
if
you
look
at,
for
example,
the
blue
ero,
if
you
just
use
that
as
an
as
a
as
a
guide,
you'll
see
that
the
path
attributes
of
that
blue
arrow
have
path,
id
1
and
opposite
path,
id
3.
B
And
then,
if
you
look
at
the
second
instance
on
the
left
of
the
blue,
ero
you'll
see
that
it
has
path,
id
3
and
opposite
path,
id
1..
So
it
means
that
basically,
the
second
instance
of
the
blue
arrow
is
is
actually
a
reverse
arrow
and
it
has
this
r
flag
set
to
one,
which
means
that
it's
basically
not
to
be
installed
into
forwarding.
But
it's
just
for
informational
purposes.
B
And
so
the
same,
the
same
thing
repeats
for
the
for
the
yellow
ero.
So
it's
quite
a
bit
of
information
to
kind
of
to
analyze.
But
if
you,
if
you
just
follow
the
colors,
I
think
it
it
kind
of
makes
sense
and,
for
example,
there's
like
a
purple
ero
in
the
second
candidate
path.
B
B
All
right,
chang
has
a
question.
I'm
not
sure
if
I
should
answer
it.
If
I
can
answer
it
now,
if
you
want.
G
Like
tony
from
holly,
then
I
I
didn't
have
time
to
read
the
detail
of
your
draft
and
it's
right,
but
I
have
a
simple,
simple
question
like
I
guess
that
you
you
know,
you
know
that
we
have
a
draft
of
bi-directional
as
a
pause
and
we
are
using
the
part
segment
to
associate
the
forward
direction
and
the
reverse
direction
pause
into
like
how
say
about
it
by
directional
pause
and
we
can
make
the
the
both
direction
pause
as
like
offside
up
outside
I'll,
say:
reverse
all
the
c
list
like
what
you
mentioned
here.
B
Yeah,
that's
a
very
good
question,
so
basically,
the
the
difference
is
that
this
solution
lets
you
support
multiple
segment
lists,
so
it
still
uses
these
this
bi-directional
association.
If
you
look
at
the
data
model
here,.
B
But
if
you
have
a
candidate
path
with
multiple
segment
lists,
then
it
doesn't
seem
to
work
that
well
or
it
doesn't
fully
cover
everything.
But
we
can
take
that
discussion
offline
as
well.
Next
slide.
Please.
B
B
So
here
I'll
just
give
an
example
of
of
of
of
a
path
that
has
a
forward
path
with
two
reverse
paths,
but
the
reverse
paths
or
yeah.
The
reverse
path
are
not
so
like
the
relationship
is
not
mutual,
so
basically
like
path.
Two
and
three
are
the
our
opposite
direction
to
path
one
but
path,
one
is
not
opposite
direction
to
path.
Two
and
three.
B
So
if
we
look
at
this
example,
there
is
a
head
end
on
on
the
left
and
if
you
look
at
how
the
sr
traffic
with
node
04
would
be
sent,
it
would
be
sent
on
the
green
links
and
the
pc
may
give
you
the
reverse
paths:
a
set
of
adjacency
lists,
for
example,
adjacency
segment,
going
from
four
to
towards
two
and
then
towards
one,
and
then
another
adjacent
label
start
going
from
four
towards
three
towards
one,
and
so
this
is
encoded,
as
I've
shown
below
and
basically
what's
important.
B
Is
that
it's
not
true
that
basically,
the
green
path
is
the
reverse
of
the
yellow
path,
for
example,
or
the
reverse
of
the
blue
path.
But
the
yellow
and
the
blue
taken
together
are
the
reverse
of
the
green.
So
basically,
this
encoding
just
allows
you
to
have
a
very
flexible
way
to
to
encode,
like
relationship
between
paths,
if
you
want
to,
for
example,
send
oem
packets
that
loop,
you
know
that
have
a
double
stack
of
mpls
labels
like
forward
and
reverse
stack.
B
You
know
you
could
you
could
use
this
much
much
much
more
efficiently
right,
because
you
could,
you
could
choose
exactly
which
reverse
path
it's
gonna
take
you
know
the
head
end
can
choose
exactly
which
reverse
path
is
going
to
take
next
slide.
Please.
B
D
Bike
mike
one
comment
that
I
would
have
with
my
chair
hat
on
would
be.
This
is
a
pretty
big
change,
so
do
discuss
this
on
the
working
group
list
like
what
is
the
requirement
for
this
change,
get
working
groups
feedback
on
this?
I
think
it's
okay
to
update
a
working
group
document
and
ask
for
slot,
but
like
keep
the
mailing
list
engaged
as
well,
so
bring
up
this
change
on
the
mailing
list
specifically
and
ask
for
feedback
of
the
working
group.
D
And
second,
I
think,
adding
to
what
cheng
was
saying.
I
think
we
need
to
have
a
section
which
clearly
describe
the
relationship
with
sr
bi-directional
and
have
a
clarity
on
how
that
extension
gets
used,
in
which
cases-
and
in
case
there
is
a
multi-path,
how
the
two
things
will
work
with
each
other
and
of
course
you
can
imagine
there
could
be
error
cases
and
others,
where
you
put
some
information
in
association
and
a
little
bit
different
information
in
your
tlv.
So
how
all
that
thing
will
work
together.
D
B
Yeah,
we
don't
currently
have
an
implementation
status,
but
we
will
add
it
as
soon
as
possible
and
that's
why
iona
code
points
would
also
be
very
useful.
D
I
Everyone,
this
is
from
cisco,
so
just
to
add
to
the
previous
comments
in
the
sr
bi-directional
draft,
we
have
added
a
new
section
that
talks
about
the
relationship
with
this
drop
that
mike
is
presenting
as
well
as
I
think
there
is
a
explanation
in
the
draft
that
mike
is
presenting
with
some
examples
that
also
points
back
to
the
bi-directional,
how
it
could
work,
so
they
both
have
some.
I
D
Thanks
mike,
there
was
also
a
a
point
that
that
kaithin
brought
up
in
idr
working
group
just
before
this,
where
he
was
mentioning
that
some
of
these
changes
needs
to
be
discussed
in
spring
as
well,
and
he
brought
up
the
issue
actually
related
to
a
backup
segment
list
and
where
he
was
saying
that
that's
not
a
part
of
the
sr
policy
architecture
and
it's
something
that
is
missing.
So
we
need
to
keep
the
track
of
that
as
well.
J
B
J
I
See
the
need
to
merge
them,
they
are
quite
different
use
cases,
so
they
solve
different
problems.
There
is
text
for
that
in
the
binder
draft.
Please
review
and
let
us
know
you
think
that
thanks.
B
B
Just
a
like
a
one,
five
second
comment
like
I
keep
this
or
we
keep
this,
this
multipath
draft
as
completely
agnostic
to
any
sr
technology
right.
So
basically,
it's
it's
kind
of
a
generic
psap
extension
that
can
be
applied
to
you
know.
Other
data
planes.
B
D
B
B
B
Only
the
first
two
are
kind
of
not
really
implemented
that
much,
but
we
still,
you
know,
need
to
standardize
them
and
piece
up,
and
we
want
to
make
these
these
mechanisms
generic
so
that
they're
applicable
for
rcpt
tunnels
or
any
other
kind
of
tunnels
in
the
future,
because
that's
what
they
really
are,
they
are
generic
next
slide.
Please.
B
So
the
for
the
drop
upon
invalid,
we
propose
this
tlv
called
invalidation,
tlv
and
basically
just
has
it
lets
the
pce
to
to
to
tell
the
pcc
what
to
do
if
the
if
the
path
becomes
invalid,
so
there's
basically
two
options:
either
redirect
the
traffic
towards
igp,
which
is
the
default
or
drop
the
traffic
when
the
osp
becomes
invalid
and
it
the
steel,
also
has
a
state
field
which
kind
of
has
similar
feel
a
similar
value
of
zero
if
it's
not
dropping
and
one
if
it
is
dropping
traffic.
B
So
just
a
simple
tlv
to
encode
that
next
slide.
Please
and
there's
another
functionality,
that's
that
was
from
the
sr
policy
draft,
where
basically,
we
don't
want
to
bring
up
the
lsp
if
the
bcd
is
not
available
for
programming
and
so
to
cover
this.
We
request
a
bit
in
the
path
by
t
path,
binding
tlv
and
this
bid
will
be
per
tlv
or
per
bc.
And
so,
if
you
have
like
multiple
bcds
for
the
same
lsp,
they
can
have
different
values
of
these
bits.
B
B
So
again,
just
a
simple
extension
next
slide.
Please.
B
And
I
got
this
question
from
privately
and
basically
there's
this
current
rules
is
that
this
sr
policy,
candidate
path,
id
tlv,
is
mandatory
in
the
pc
initiate
message,
but
it
if
you
think
about
it
really
doesn't
have
to
be
mandatory.
Pc
could
emit
it
and
pcc.
Could
you
know
just
choose
the
values
for
it
because
it
owns
kind
of
owns
the
policy.
If
you
will
so,
we
could
make
this
tlv
be
optional
in
the
pc
init
message.
B
B
So
there
is
a
implementation
status
of
cisco
and
juniper.
We
both
have
proof
of
concepts
with
ayana
code
points.
We
had
successful,
interrupt
testing
with
between
cisco
and
juniper
at
the
entc
event.
B
H
Hi,
boris
gale
hi
mike
again
one
question
and
suggestions,
also
so
question.
If
we
will
have
a
look
to
7.4
item
in
the
draft
pc
initiated
this.
Our
policy
with
multiple
candidate,
perhaps
item
one
is
sounds
quite
quite
confusing
because
there
is
no
clear
differentiation
like
should
be,
should
pc
send
one
pce
initiate
message
or
multiple,
maybe
would
be
worth
to
add,
like
more
clearly
like
may,
send
or
shoot
sand
or
whatever.
B
B
I
think
that
you
know
the
unit
of
signaling
in
psap
is:
is
this
p
p
osp
right
posd
id,
so
you
could
have
multiple
plsp
ids
in
the
same
message
or,
but
that
doesn't
really
give
you
anything
except
for
save.
Like
four
bytes
of
message,
header.
H
Yep,
okay
and
a
second
comment
regarding
implementation
status:
we
recently
did
some
testing
with
our
own
controller
prototype
and
actually
both
you
and
I
mean
sister
and
juniper-
you
currently
support
it
in
production
version
of
software.
B
B
Yeah,
that's
correct:
it's
not
a
proof
of
concept
right
yeah!
Maybe
we
should
just
say
that
then
yeah.
B
Like
we
use
this
vendor
tlv,
because
right
now
there.
D
One
comment
that
I
wanted
to
bring
like
get
the
working
group
feedback
on
the
generic
mechanism,
so
right
now
all
these
mechanisms
to
make
it
generic.
They
are
not
part
of
the
association
object
they
are
carried
outside
it,
but
the
main
use
cases
for
these
is
still
sr
policy.
So
now
the
issue
comes
in
that
the
name
of
the
document
is
sr
policy
and
we
are
keeping
some
generic
mechanism.
D
So
it's
okay
to
do
it.
It's
there's
not
a
hard
and
fast
rule,
but
we
want
to
make
sure
that
we
are
doing
the
right
thing
and
the
working
group
is
thinking
about
it.
One
option
could
be
that
we
kind
of
highlight
that,
though,
like
you
know,
this
is
still
sr
policy.
The
main
use
cases
are
coming
from
the
sr
policy
architecture.
D
The
encoding
is
such
that
that
they
are
outside
the
association
object,
and
maybe
we
add
a
paragraph
which
says
that,
oh
by
the
way,
these
can
be
used
pretty
easily
for
other
other
non-sr
policy
cases,
but
the
main
use
case
is
still
sr
policy.
That's
why
they
belong
in
this
document
and
we
don't
want
to
put
them
in
a
separate
document.
So
some
thinking,
I
I
think
authors
should
think
so
that
that
point
come
across
and
I
wanted
to
get
the
working
group
feedback
also,
whether
that's
the
right
approach
or
not.
B
Yeah
thanks
point
taken
yeah
like
sr
policy
architecture
was
the
first
to
kind
of
standardize
these
behaviors
right,
but
they
in
fact
existed.
Even
you
know
before
sr
policy.
So
so
that
was
my
reasoning
of
why
I
put
them
in
this
draft,
but
you
know
I'm
definitely
open
to
whatever
people
decide.
D
So
next
we
have
luke.
C
C
So
it
is
good
again
to
recall
the
motivation
of
this
draft
you
see
in
the
traditional
mpls
the
pattern
to
you
could
be
signaled
by
our
rsvpt
and
ldp.
C
But
now,
when
we
come
to
the
segment
routing
parts,
we
are
not
yet
at
the
additional
signaling.
So
the
sr
tunnel
cannot
currently
support
the
negotiation
mechanism
for
part
mt
and
when,
when
seats
are
pushed
in
a
packet,
the
packet
will
be
dropped,
fragmented
and
forwarding,
since
the
packet
size
might
exist,
the
part
mtu.
So
from
the
operator
point
of
view,
it
is
important
that
using
these
lines
over
multi
domains,
the
mtu
should
be
length
and
to
avoid
drop
in
packets.
C
C
So
in
terms
of
history
of
the
draft,
the
version
2
was
presented
in
the
iitf
108
and
we
received
comments
and
suggestions
and
with
these
comments
were
being
captured
in
the
version
3,
which
were
a
terminology
session
that
was
added
to
clarify
the
confusing
terms,
the
mtu,
the
link
mtu
and
the
pattern
to
you,
a
parent
adjustment
session,
which
was
also
added
in
the
case
of
protection
such
as
dti
lfa,
and
we
did
some
editorial
changes.
C
So
this
version
5
that
we
have
we
are
saying
p
pad
m2,
is
very,
very
important
for
network
operators
and
we
once
again
request
a
working
group
adoption
of
this
of
this
draft.
So
thank
you.
D
D
So,
let's
move
on
to
julian,
you
want
to.
K
Okay,
joseph
you
are
next.
Thank
you,
yeah,
hello,
hello,
yeah.
This
is
an
update
about
the
psap
extension
to
enable
I
feed
so
next
life
yeah.
Just
a
few
words
about
background
and
motivation.
My
feet
refers
to
all
that
are
playing
on
par,
telemetry,
c2im
and
alternate
marking,
and
we
also
include
the
reference
to
the
relevant
document
for
these
methodologies,
so
the
dpsep
extension
they
find.
K
These
documents
allowed
to
signal
the
feed
capabilities,
and
we
address
the
the
initial
comment
and
the
effete
attributes
can
be
generalized
and
included
as
tlb
carried
in
the
lspa
object,
and
so
this
generalized
this
application,
since
it
can
be
applied
to
rupa
types
as
long
as,
of
course,
they
support
the
data
plane.
Telemetry
meter
next
slide.
K
All
these
on
par
telemetry
technology
suggested
that
can
be
applied
in
a
controlled
domain
and,
according
to
this
recondition,
we
also
improve
the
security
sections
considerations
to
to
define
that
ifit
data
must
be
propagated
in
a
limited
domain,
also
always
for
security
to
address
the
security
concerns,
and
this
also
is
discussing
the
relevant
data
plane
document,
and
we
also
include
some
considerations
in
in
this
document
as
well.
So
next
slide
yeah.
This
is
just
a
recap
about
the
what's.
What
is
the
proposal
of
the
draft?
K
K
In
addition,
we
define
the
icitatious
tlv
that
provides
the
configurable
nodes
of
the
features
and
it
can
be
included
as
optional
in
the
lspa
object.
As
a
as
I
mentioned
before,
next
slide
yeah
in
in
this
slide,
we
can
see
the
detail
of
the
subtleties
for
iom.
K
As
I
said,
there
are
four
options
for
option
sub
qd
for
ion
next.
K
Yeah-
and
this
is
the
subtle
d
for
alternate
marquee,
so
next
is
why
isn't
the
last
yeah
regarding
the
discussion
and
next
steps,
we
can
say
that
effect
methods
are
becoming
mature,
also
for
sr
mpls
on
the
36,
and
from
this
point
of
view,
this
the
tlv
here
define
also
complement
the
draft
that
was
presented
before
by
mike
on
pca
segment
routing
policy
cp
to
enable
to
enable
lesser
policy
with
the
natives
by
feet.
K
But
in
the
end
this
is
general,
so
this
can
be
applicable
to
all
the
part
types
when
the
data
plane,
telemetry
techniques
is,
has
been
defined.
So
we
are
also
working
on
ipv6
data
plane
to
to
define
the,
for
example,
the
alternate
marquee
for
at
least
other
places
and
yeah.
That's
all
so.
D
K
No,
no,
I
didn't.
I
didn't
take
action
but
yeah.
To
be
honest.
I
forgot
but
yeah
it's
something
that
we
can
consider.
Yeah.
F
M
M
M
M
M
M
So
what
comes
our
webcam,
so?
In
addition,
we
would
like
to
request
for
work
working,
good
work,
adoptions.
Thank
you.
D
Thanks
for
first
merging
the
the
two
documents,
but
one
query
that
I
have
is
like
first
first,
let
me
ask
you
this
question:
what
happens
to
rsvpt?
Is
this
not
re
useful
for
rhpe.
M
As
I
mentioned,
as
I
said
this
one,
this
can
provide
two
type
of
protections
sr
pass
on
the
blt
pass.
So
if
we
we
wanted
to
extend
this
one
to
provide
protections
for
te
pass,
I
think
it's
easy.
We
just
add
one
flag
and
then
maybe
include
those
tlvs
for
the
tte.
D
Pass
so,
however,
what
I
was
getting
at
is
that
I'm
not
able
to
understand.
Why
do
we
need
to
differentiate
so
much
like
we
have
path,
setup
type
path.
Setup
type
will
tell
me
whether
it
is
an
sr
srv6
beer,
whatever
the
mechanisms
would
be
anyway
the
same,
irrespective
of
what
is
the
path
setup
type,
so
I
know
from
capability.
It
makes
some
sense
that
oh,
I
want
to
have
a
separate
flag
for
each
of
them
so
that
I
can
identify
the
capability,
but
for
rest
of
the
procedure.
D
What
is
the
main
point
to
have
like
you
know,
to
have
different
sections
or
different
handling
for
each
part
setup
type?
I
was
thinking
that
this
could
be
a
common
generic
draft
and
we
don't
have
to
talk
too
much
about
what
happens
for
sr.
What
happens
for
brte
what
happens
to
rsvpt
the
more
most
of
the
psa
encoding
and
psep
procedure
remains
the
same.
So
is
that
correct
is
my
understanding
for
this
correct?
Yes,.
M
You
are
yes,
you're
correct,
I'm
also
thinking
about
the
one
indeed
the
details,
so
this
because
this
is
for
biker
plus
so
for
the
biker
pass.
M
We
can
use
backup
plus
type,
because
when
we
initiate
the
pass,
then
there's
some
indications
for
that
by
the
past
time
right
so
so
that
can
we
have
enough
information
for
the
past
past
hype
and
here
so
we
have
explicitly
indicate
that
this
type,
I
think,
maybe
just
give
a
emphasize
so
this
one
is
okay,
as
I
mentioned
that
we
just
because
we
already
have
those
past
typing
information,
it's
okay,
it's
okay!
M
D
Thank
you.
Let's
take
the
questions
from
the
queue
jeffrey.
D
Thanks,
thank
you
mike
quickly,.
B
Four
comments
just
to
confirm
like
this
is
this:
requires
a
connection
to
the
ce
right
to
it
requires
pc
to
to
talk
to
the
ce
device
right.
B
Okay,
maybe
just
kind
of
elaborate
if
you
could
elaborate
on
that
like
in
the
draft,
and
it
would
be
also
good
to
know
like
which
types
of
service
overlay
this
will
apply
to
like
l3
vpn.
I
assume
it's
not
throughout
to
vpn.
M
Yeah,
yes,
in
the
draft
we
we
mentioned
that
in
some
cases
we
need
a
communication
with
ce.
Yes,
you're
right.
B
B
D
Very
good
comments,
who
am
I
please
handle
there-
are
some
older
comments
as
well
on
this
document
to
just
please
handle
all
the
comments
that
you
have
received
in
the
past
when
you
presented
it.
Thank
you.
Everyone
thanks,
see
you
in
the
next
session.