►
From YouTube: IETF111-PCE-20210726-2130
Description
PCE meeting session at IETF111
2021/07/26 2130
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
A
A
The
use
of
a
headset
is
recommended
because
it's
better
to
get
your
votes
clearly
avoid
the
noises
and
so
on,
so
especially
for
the
mic.
If
you
want
to
take
the
floor,
there
is
the
automated
which
is
integrated
with
the
medical
tool
now,
so
you
shouldn't
worry
about
it.
If
you're
logged
in
using
your
data
tracker
account,
we
have
a
chat
available,
we
can
see
that
are
already
making
use
of
them
yesterday.
A
The
slide
scaling
is
probably
related
to
the
fact
that
we're
using
the
new
pdf
sharing
feature,
which
probably
uses
a
low
resolution-
and
I
think
there
have
been
a
couple
of
messages
on
the
list
related
to
that.
Probably
we
can
expect
a
change
till
next
atf
on
meticulous,
sorry,
okay,
so
thanks
mithiko,
we
have
harry
taking
minutes,
there's
a
cody
md
tool
available.
So
if
you
want
to
help
him,
give
some
additional
info
that
he
may
lose
or
add
anything
that
seems.
A
A
B
A
A
So,
as
usual,
we
remind
you
that
everything
we
do
at
the
etf
is
supposed
to
happen
using
the
mailing
list.
So
you
don't
have
to
wait
for
the
meeting
whether
or
not
or
face
to
face
to
progress.
Your
work
use
amazingly
such
must
as
possible.
A
The
working
group
polls
are
also
significant
steps
in
the
life
of
the
working
group,
so
please
try
to
be
vocal
during
those
polls,
whether
it
be
at
adoption
last
call
reviews
whatever
the
group
needs
people
to
be
a
group,
so
please
contribute
not
only
has
contributed
to
your
documents,
but
also
as
working
group
members.
A
All
the
also
we
track
on
the
wiki,
the
yearly
apart
allocation
that
you
may
have
to
consider.
As
soon
as
you
need
to
progress.
A
specification
towards
interrupt
testing
helicopter
location
may
be
useful,
so
we
have
a
couple
of
existing
ones
in
the
pc
working
group.
Currently,
if
you
believe
that
implementation
do
need
some
common
code
points,
you
may
consider
this
step.
It's
been
working
well
for
a
few
specifications
so
far,
so
please
remind
keep
in
mind
that
we
have
this
option
available
next
project.
A
A
A
We
have
a
fourth
one
within
the
lcd
which
is
related
to
flow
spec
in
psep,
and
there
is
a
dependency
to
the
idr
document,
which
is
specifically
related
to
the
layer
2
vpn
extension
for
floor
spec
idr
is
moving
for
prospect
b2
for
this
this
part,
so
one
possible
option
could
be
to
strip
this
currently
existing
layer,
2
vpn
from
our
pcep
id
id
and
maybe
move
with
another
document
later
to
follow
frostback
from
the
idea
working
group
and
I
see
sue
in
the
queue
so
sue.
A
C
Hi,
can
you
hear
me
now?
Yes,
okay,
idr
is
moved
flospec
l2vpn
to
flowspec
v2.
We
will
be
holding
an
interim
on
flowspec
the
13th
of
september,
at
least
tentatively.
We
haven't
had
our
our
idr
meeting
until
tomorrow,
but
we
anticipate
moving
the
fee
to
flow
spec
quickly.
However,
it
probably
is
six
months
out,
even
if
we
move
quickly,
so
you
should
know
that
the
flow
spec
v2
is
simply
handling
some
problems
with
the
tlb
and
you'd
be
wise
to
pick
up
l2
vpn
from
that.
That's
that's!
C
Choice
of
either
yet,
but
we
will
be
moving
fast
on
v2,
there's
a
lot
of
people
who
want
us
to
move
fast.
Now
that
we've
made
a
decision.
Okay,.
A
A
D
A
The
editorial,
the
other
one
is
related
to
fc
8231
related
to
the
the
order
of
the
objects
within
the
grammar
in
pixel
extensions.
So
we've
faced
this
kind
of
issue
between
different
documents
in
the
past
already,
so
the
question
is:
how
would
we
handle
these
ones?
We
may
consider
an
update
at
one
moment.
It
could
be
a
way
to
address
it,
so
we
still
need
to
think
about
how
we'll
address
this
errata.
A
A
E
Let's
start
with
some
of
our
working
of
documents,
which
are
nearing
to
the
working
group
last
call
we
have
the
stateful
gmpls
document.
If
you
would
remember,
that's
actually
a
merge
of
two
separate
ids
merging
stateful
and
pc
initiated
for
gm
pls,
so
authors
have
indicated
that
they
are
ready
for
working
group
last
call,
so
the
chairs
will
start
the
process
soon.
E
E
We
could
progress
this
as
an
experimental
work
or
we
can
wait
for
implementations
and
see
who
which
inter-domain
or
some
other
documents
start
using
this
enhanced
error
mechanism
and
there
are
actual
implementation.
Then
we
can
make
progress
until
that
time.
We
can
wait.
So
we
were
discussing
this
among
the
chairs.
If
you
have
any
suggestion,
you
can
still
reply
to
the
same
email
thread,
but
chairs
will
be
making
a
decision
on
this
soon.
E
For
the
yank
draft
there
has
been
no
update
since
the
last
type.
Here
there
are
pending
comments
that
needs
to
be
updated.
The
authors
will
work
on
it
soon
and
then
we
will
do
another
yang,
doctor
review
and
then
mostly
working
group
last
call
next
all
the
other
dependencies
that
this
document
have
are
also
progressing
well.
So
I
think
we
are
on
good
track
with
having
our
yang
model
published
pretty
soon.
E
The
other
ids
native
ip
is
on
the
agenda,
but
the
part
that
we
wanted
to
highlight
was
that
we
requested
feedback
from
the
idea
working
group
just
now
sue
mentioned
on
the
on
the
chat
that
she
would
be
sending
a
feedback
onto
the
list.
So
if
it's
important
that
we
get
that
feedback
early
on
before
we
do
a
working
group
last
call
processing
anyway,
this
document
is
on
the
agenda.
So
if
there
is
any
comments
related
to
that,
we
can
discuss
it
in
the
agenda
type.
E
We
have
a
document
on
flexgrid.
This
has
not
been
updated
in
a
while
there's,
no,
not
many
changes.
So
we
wanted
to
get
a
confirmation
from
authors
that
whether
all
work
is
done
or
are
they
waiting
for
some
other
event
to
happen?
If
it's
done,
we
can
you
can
let.
E
How
much
go
ahead.
F
Oh
yeah,
speaking
of
from
the
perspective
of
the
flex
grade
that,
yes,
I
I
think
is
mainly
stable,
so
we
may
move
forward
and
or
or
we
need
more
comments
to
move
forward.
E
Moving
ahead,
we
have
srv6
recently
the
management
fee,
consideration
and
implementation
status
has
been
added.
Otherwise
the
documents
looks
pretty
stable,
so
hopefully
srv6
would
also
be
ready.
Soon.
We
have
another
association
called
vn
association.
This
is
related
to
acpn.
E
This
looks
like
really
as
well,
because
it's
been
stable
for
a
while
we'll
check
the
authors
on
what
they
feel
about
progressing
via
association
yeah.
How
me
and
again
go
ahead.
F
Yeah,
sorry
for
not
updating
the
status,
this
one
would
be
quite
stable
as
well,
but
I'm
not
sure
whether
there
is
any
dependency
on
the
action
we
end
dropped
from
this
working
group.
So
if
yes,
we
will
wait
for
a
while
until
the
extreme
vienna
is
stable.
E
F
E
Then
we
have
a
path
segment.
There
has
been
no
update
path.
Segment.
Work
is
progressing
in
spring
as
well.
So
I
think
once
the
spring
works
happen,
the
pc
can
take
the
lead
from
there
bi-directional
sr
path.
There
has
been
an
update.
The
update
was
mainly
to
sync
with
the
published
rfc,
and
this
document
also
is
nearing
a
working
group.
Last
call
and
we
have
got
the
confirmation
from
the
authors
that
maybe
by
the
next
ipf
will
be
there.
E
Some
of
the
newer
documents
are.
We
have
our
sr
policy
candidate
path
document.
There
has
been
an
update.
There
was
a
request
for
an
earlier
location
which
was
done
and
there
was
discussion
on
the
list.
We
have
one
pending
item
when
we
were
moving
the
binding
set.
There
were
comments
to
remove
two
of
the
flats
which
were
related
to
sr
policy
from
binding
sid
and
our
plan
was
to
add
it
into
the
sr
policy
document.
E
E
The
new
other
newer
documents
are
pcc
sr.
There
has
been
an
update.
The
update
was
to
align
with
the
pcc
based
rfc
recently
published
rfc9050
stateful
interdomain
was
also
updated.
This
was
a
significant
update
based
on
the
comments
that
were
received
during
the
adoption
time,
and
they
are
now
reusing
the
binding
tlv.
So
that
was
one
of
the
pending
items,
which
has
been
done
request
the
working
group
to
look
at
the
document
and
please
provide
their
feedback
as
this
work.
E
E
Okay,
so
last
two
are
our
very
recent
working
group
ids.
They
have
been
recently
adopted
in
last
couple
of
months,
so
we
we
are
still
yet
to
see
an
update
on
these.
E
And
finally,
this
is
our
working
group.
Adoption
poll
queue.
You
can
always
refer
to
the
wiki
to
see
where
we
are.
There
is
still
some
backlog,
but
your
chairs
are
working
and
trying
to
clear
them
as
soon
as
we
can.
So.
Please
help
us
give
us
feedback
when
we
request
on
the
on
the
working
group
mailing
list,
so
that
we
can
all
move
all
your
documents,
all
our
documents
together
and
with
that
I'm
done.
G
G
The
motivation
is
we
introduce
updates
for
for
the
preset
session
for
network
network
and
send
back
his
feedback
from
the
for
the
overall
updated
solution
we
think
after
the
application.
His
document
is
ready
for
the
working
group
classical
next
slide.
G
G
I
started
this
dear
traffic
towards
the
particular
route
by
the
physique
next
talk
with
the
pc
based
setup.
After
these
three
steps,
the
recon
also
the
traffic
priority
traffic
go
along
with
the
operative
path
from
end
to
end,
the
detailed
explanation
can
be
delivered
for
the
last
practice
in
the
potential
in
last
idea,
meeting
or
next
play.
G
G
G
You
know
if
we
want
to
observe
traffic
from
r1
or
r7,
but
if
the
the
same
traffic
to
our
pull
the
prefix
on
r7
come
from
with
the
r2
once
running,
traffic
came
to
the
our
neutral
i5,
then
the
traffic
will
be
will
be
folded
along
the
priority
path.
So,
although
the
the
theoretical
control
is
not
very
in
strict,
so
that
is
some,
some
advanced
atomic
may
pass
the
priority
path.
G
So
if
we
want
to
use
the
once,
you
control
the
audio
coding
path
strictly,
we
can
kind
of
traffic
between
the
source
and
the
destination.
G
So
the
traffic
for
different
cube
that
is
from
different
store
store
because
the
station
pair
will
be
put
into
the
different
tunnels.
So
if
the
traffic
come
from
another
router,
for
example,
the
in
the
r2
router
and.
G
G
To
to
achieve
the
strict
past
control
we
under
we
handle
another
flag.
That
is
the
t
in
the
vdp
peering
for
object,
so
the
if
this
player
is
flagged.
Instead,
there
is
a
ton
of
source
and
the
contextualization
ipo
test
will
be.
G
So
next
slightly
and
we
we
also
update
the
explanity
in
pure
load
object
if
the
ppi
either
key
flag
in
pdp
object.
Instead,
then,
the
the
next
proper
test
will
be
indicated
and
will
indicate
the
the
tunnel
test.
G
So,
from
the
point
of
view
of
the,
there
is
no
difference
between
the
two
objects.
The
exon
is
based
on
the
object.
G
Okay,
this
is
the
overall
update
our
institute's
introduction
of
the
update
content.
So,
in
any
comment.
E
Hi
mike
go
ahead.
H
I
just
had
a
couple
of
questions.
First
question
is:
is
it
true,
is
it
correct
that
a
route
injected
via
this
ppa
route
is
going
to
be
flooded
into
every
single
node
in
the
domain?
Even
if
that
note
doesn't
you
know,
doesn't
have
any
practical
chance
of
carrying
that
traffic.
G
H
H
So
if
you
have
a
million
say
you
have
a
million
prefixes
right,
and
is
it
true
that
every
single
node
in
your
domain
is
going
to
have
a
million
bgp
routes.
H
Yeah
epr,
but
I'm
talking
about
the
prefixes,
so
the
ppa
peer
prefix
advertisement,
those
are
injected
at
the
at
the
tail
end
and
at
the
head
end
right
and
then
the
tail.
The
tail
end
would
send
that
prefix
route
into
the
route
reflector
and
I
think
the
router
reflector
would
spread
it
out
to
every
single
node.
Is
that
correct
or
not.
D
E
But
I
would
like
I
joined
to
confirm
from
my
understanding
I
don't
think
so.
There
are
flooding
information
everywhere.
This
is
basically
only
using
psap
to
to
program
what's
needed
on
those
individual
nodes.
So
there's
no
flooding
involved
here.
That's
my
understanding.
H
Okay,
maybe
I
don't
know
if
I
can
take
that
to
the
list,
then.
H
H
E
E
So
I
think
we
we
are
losing
him
so
mike.
Why
don't
you
take
the
both
these
questions
to
the
list
and
we'll
make
sure
ijun
answers
them?
Thank
you
for.
E
C
C
Okay
june,
if
you
hear
this,
one
of
the
problems
that
I
was
gonna
send
to
the
spec
may
help
mike's
previous
comment.
C
C
G
Yeah
rc
in
the
right
house,
reflector,
okay,.
C
C
C
G
C
Okay,
that's
good!
Then
our
r5
and
r6
simply
forwarding.
C
C
E
E
C
This
is,
this
is
true
mike
then
the
previous
speaker.
Then
it
is
the
stuff
that
comes
from
the
front.
Reflector
goes
to
r1
and
r7
as
clients.
There
is,
if
that's
all
the
farther
it
goes.
B
C
It
if
it
sends
routes
to
rf1
and
r7,
then
the
routes
are
there.
Then
you
have
to
know
what
r5
and
r6
are.
They
can't
be
bgp
peers
that
the
route
reflector
client
sends
things
to
and
if
it's
using
classic
route
reflection,
so
that's
an
unclear
portion
in
the
draft.
I
will
send.
B
C
E
So
thanks
ijun,
please
do
answer
the
questions
from
mike
and
sue
on
the
mailing
list.
Thank
you.
D
You
hello,
can
you
hear
me?
Yes,
yeah
yeah,
hello,
everybody
yeah!
This
is
the
an
update
about
the
psap
extensions
to
enable
live
feed.
So
next
slide
yeah.
Just
a
few
words
about
the
background
and
motivation.
I
feat
refers
to
data
playing
on
path,
telemetry
techniques,
including
in
c2im
and
alternate
marking,
and
you
can
see
the
relevant
documents.
D
The
scope
of
this
draft
is
to
define
the
psep
extensions,
to
allow
to
signal
the
ipit
capabilities
in
order
to
make
them
automatically
activated
and
running
how
we
can
do
that.
So
we
generalize
this
through
the
application,
as
is
carried
inside
the
lspa
object,
and
these
can
be
applied
to
all
part
types
as
long
as,
of
course,
as
long
as
they
support
the
relevant
data
plane,
telemetry
method
next
slide.
D
Yeah
in
this
slide,
we
just
summarized
the
changes
from
the
zero
two
version:
yeah
zero.
Three
was
just
changed
about
the
authorship
of
the
document,
so
we
just
had
two
version,
so
the
main
changes
are
the
we
specified
the
usage
scenario
of
by
feed.
In
particular,
we
highlighted
that,
according
to
rfc
8799,
all
the
a-fit
methodologies
need
to
be
applied
in
specific
network
domains,
so-called
controller
domains.
D
So
we
clarify
these
usage
scenarios,
as
also
mentioned
in
rfc
8799,
and
also
in
the
relevant
in
c2im
and
alternate
marketing
documents.
D
According
to
this,
we
also
improved
the
security
consideration
sections,
so
we
highlighted
that
the
afib
data
must
be
propagated
in
limited
domains
to
avoid
malicious
attacks
and
these
solutions
to
ensure
this
requirement
are
also
discussed
in
the
c2m
draft
and
alternate
marking
draft.
That
is
in
last
call
next
slide.
D
Four
are
dedicated
to
in
c2m,
and
one
bit
is
dedicated
to
alternate
marking
the
flag
must
be
set
to
one
by
both
pcc
and
pc
in
order
to
support
the
instantiation
of
the
methodology.
Next
slide.
D
Yeah,
this
is
just
the
last
type
5
related
to
alternate
marking
subtle
v.
We
also
added
two
flags
indicated
that
the
measurement
can
be
hoped
by
up
or
entwined
next,
okay
yeah.
This
is
the
last
slide
yeah
since,
as
I
said,
the
the
this
draft
is
general
for
all
the
part
types
in
any
case
since
I
fit
methods
are
becoming
mature
for
srm
pls
and
srv6.
D
E
A
No
but
fair
to
hear
you
when
you,
you
ask
about
questions.
E
Okay,
there
was
one
comment
from
the
last
last
meeting
regarding
some
of
the
flats
and
whether
we
need
to
create
a
registry
or
not.
I
think
that
we
never
discussed
further.
Whether,
like
you
know,
the
plan
was
whether
we
we
just
need
to
define
the
flags
and
no
registry,
because
I
remember
this.
Similar
discussion
was
happening
in
lsr
working
group
as
well
about
when
we
create
flags.
E
Do
we
also
immediately
create
a
registry
so
that
any
future
document
can
update
it
without
having
to
like
to
just
update
the
registry
without
having
to
update
the
document
and
and
change
the
metadata
as
well
and
in
pc
working
group
and
pc
protocol?
Usually
we
have
always
for
all
our
flags
created
the
registry.
So
is
there
any
specific
reason
for
iom
and
this
document
that
we
don't
want
to?
So
I
think
if
there
is,
we
need
to
discuss
this
on
the
list.
D
Okay,
I
I
think
that
we,
we
can
be
aligned
with.
Let's
say
how
in
pc,
you
manage
this
kind
of
registry,
so
we
can.
We
can
update
the
draft
accordingly,
no
problem.
I
Okay,
I'm
john
from
dt.
My
presentation
today
is
the
new
t
constraints
for
psep,
and
let's
please,
as
the
vegas
show,
the
attributes
with
the
lateral
topology
are
advertised
among
the
domain
by
igp
such
as
isis
or
ocpf,
and
then
reported
to
the
controller,
for
example
their
pc.
So
the
pc
will
perform
past
computation
based
on
the
information
collected
through
bgpls
and
as
divided
in
rfc.
I
So,
first
one
is
the
source
protocol
id,
which
identified
the
igp
instance
and
it
is
defined
in
released
version
of
ecs
ospf
and
the
bhprs
second
is
the
multi
topology
id,
which
can
it
can
identify
the
the
tour
network
it
will.
It
also
has
been
defined
and
the
last
one
is
the
application
id
which
and
that
find
a
sub
of
a
network
with
a
specific
application
and
it
is
defined
in
rfc8919.
I
Finally,
we
defined
the
rfa
id
for
flash
argo
function,
so
we
will
introduce
the
trv
for
details
in
the
following
slides
last
night.
Please,
the
first
one
is
the
source
protocol
id.
As
the
figure
shown
we
define
our
source
protocol
tree
to
carry
the
source
protocol
constraint
and
it
is,
and
the
ospf
may
run
multiple
routing
protocol
instances
over
the
same
link,
so
the
pc
may
compute
the
t
parts
within
one
of
the
instances
such
as
it
is
level
1,
left,
2
and
os
ospf
version,
two
version
three
and
so
on.
I
Let's,
let's
please,
the
second
one
is
the
multi
topology
id
and
we
carry
the
multi
topology
id
in
multi-topology
trwe
and
the
pc
may
compute
the
t-pass
within
one
of
the
sub
topology,
which
defined
which
identified
by
a
multi
topology
id.
So
we
define
a
multiplicative
power
to
carry
the
constraint
for
the
future
network.
Next,
please,
the
third
one
is
the
application
id
the
easiest
link
attribute
application
and
that
files
has
been
defined
in.
I
Irfc8919,
the
sub
topology
pro
provides
the
application
specific
specific
information.
We
define
our
application
application
tle
to
carry
the
constraint
next.
Please,
the
subtop
topology
may
also
be
identified
by
this
specific
slice.
Id
in
slash
network
need
is
discussed
in
the
draft
itf
t's
idf
network
slice
stabilization
this.
So
this
document
device
a
slice
doe
to
carry
the
snipes
id
constraint
for
the
dual
network
last
place.
I
So
the
fifth
one
is
the
sub
topology
and
may
also
be
identified
by
this
specific
color
template
which
carried
specific
color
parameter,
and
it
is
suitable
for
lnt
instance
such
as
rcbt
rsrt
and
sr
policy.
It
is
defined
in
as
defined
in
rfc
9012.
I
The
counter
trv
can
be
carried
to
identify
the
color
template,
which
is
the
color
extended
community
divided
in
rc
9012
nest,
the
final
one,
the
the
last
one
is
the
fa
id.
We
defined
the
fa
id
to
carry
the
flash
argo
countries,
so
this
says
order
a
new
t
constraints
we
proposed
next,
please.
I
F
J
I
just
you
guys,
yes
go
ahead.
I
just
had
a
general
question
about
or
comment
I
guess
about
the
color
extension
there's
a
draft
after
this
document.
Actually
that
discusses
color
for
attaching
it
to
rsvp
lsbs
and
that
context
that's
about
steering,
whereas
this
one's
in
the
context
of
constraints
requirements.
J
If
I
understand
correctly
part
of
me
wonders,
is
that
a
little
bit
of
an
overlap
with
association
policy.
So
if
a
color
is
encoded
to
carry
some
kind
of
traffic
engineering
requirements
or
goals
which
the
controller
is
aware
of
and
not
used
for
explicit,
steering
or
binding,
like
the
other
draft,
that's
actually
being
discussed
after
this?
Is
there
not
a
collision
there
between
association
policy
and
this
color
plv.
I
Yes,
I
have
reviewed
you,
the
draft
you
mentioned
and
I
think
it's
a
useful
use
case,
so
I
think
we
defined
the
quality.
Are
we
and
it
can
be
used
in
many
scenarios?
So
I
think
it's
referred
referred
to
the
child
at
the
pc
chari.
I
think
if
we
can
cooperate
or
cause
or
a
new
draft
or
other
other
solution
to,
I
think
the
colonel
toe
is
we.
We
can
only
define
the
one
counter
to
e
and
it
can
be
carried
in
mailing
objects.
J
One
is
to
carry
traffic
engineering
requirements
with
a
path
calculation
demand,
whereas
the
other
one
was
for
color
steering
so
yeah
I
mean
if
we
can
merge
them
into
one
kind
of
tlb
that'd
be
great,
but
I
guess
I
just
see
the
purpose
of
this
being
different
than
the
other
one
and
the
purpose
as
an
overlap
with
association
policies.
In
my
opinion,
loosely.
E
And
yeah
and
you
just
to
add
that
the
association
policy
is
already
an
rfc,
so
it's
already
a
published
work
where
this
color
template
work
could
be
done
with
just
creating
a
policy
id.
So
we
need
to
have
a
stronger
justification
for
why
we
need
something
new,
then
something
which
already
is
standardized.
J
Yeah,
because
this
this
reminds
me
a
little
bit
of
the
draft
past
profile
right
where
you
just
have
an
id
that
associates
back
to
profile
and
association
policy,
really
kind
of
supersedes
that,
and
this
kind
of
just
kind
of
slips
in
another
mechanism
to
achieve
something
very
similar
which
which
again
the
idea
of
the
color
I
totally
get
from
a
binding
and
a
steering
point
of
view
from
a
calculation
requirement.
It's
not
quite
doing
me
yet.
K
K
Okay,
my
first
comment
is
about
the
scope
of
this
document.
Is
this
a
document
about
a
generic
constraint
extensions
for
pce
or
is
it
it
is
specific
to
network
slicing?
K
K
Okay,
so
perhaps
the
text
could
be
cleaned
up
to
make
it
like
a
generic
document.
Another
comment
is
about
the
slicing
trv.
Actually,
I
think
there's
currently
there's
no
slice
id
defined
in
the
teeth,
another
slice
definition
draft
and
there's
the
ongoing
discussion
about
the
terminology
and
also
the
concept
about
the
slice
id.
Maybe
we
will
have
another
term
for
it,
so
maybe
just
need
to
align
with
the
progress
in
the
test
working
group.
I
Yes,
okay,
thank
you.
I
I,
I
think,
there's
nice
idea
there.
The
format
of
the
smash
id
is
not
confirmed
in
teas.
So
have
do
you
have
suggestions
for
the
the
format
of
the
smash
id
tre.
K
Actually,
not
only
the
format
but
also
the
terminology,
so
if
you
you
think
it's
a
generic
document,
I
I
would
suggest
maybe
to
remove
this
tlv
at
this
moment.
E
Yeah
we
are
over
time
as
well,
so
I
think
everyone,
let's
just
keep
your
questions
very
short,
so
turret
next
go
ahead.
L
My
comment
is
that
there
are
cases
where
a
path
is
crossing
multiple
topologies
and
the
constraint
is
a
union
of
you
know
like
the
igp
topology
id
that
you're
proposing
it
can
be
union
can
be
intersection.
It
can
be
more
elaborate
than
just
one
instance
of
a
source
protocol,
topology
id
and
so
on.
Coincidentally,
we
have
published
a
draft
in
teas
me
and
pavan
talking
about
topology
filters.
L
It
has,
it
has
what
you
have
there
with
more
elaborate
union
intersection
cases.
So
that's
not.
You
know
I'll
I'll,
provide
a
link
in
case
you're
interested
in
that
that's
number.
It
was
a
comment,
the
the
second.
I
have
a
question
on
the
flex
algo
id
on
next
to
the
the
last
slide.
L
So
I
think
this
is
we.
We
need
more
information
in
there
to
identify
what
flex
I'll
go
and
I'm
willing
to.
You
know
work
offline
with
you
on
that.
If,
if
you're
interested.
H
E
B
B
The
the
motivation
is
fairly
straightforward.
This
extension
is
needed
for
the
same
reasons
why
color
is
useful
for
sr
policies
for
sr
policies.
It's
it's
currently
sitting
under
the
sr
pack
sr
policy
association
group
yeah
I
mean.
Ideally,
we
would
have
had
a
common
tlb
for
both
but
yeah,
given
that
that
that
tl,
that
current
extension
is
very
sr
specific.
We
need
something
else.
B
The
idr
document
referenced
here
discusses
in
detail
how
color
markings
can
be
carried
across
domain
boundaries,
and
the
proposal
discussed
in
this
slides
can
coexist
with
that.
So,
irrespective
of
what
mechanism
is
used
to
carry
the
color
across
domain
boundaries,
we
do
need
a
way
to
specify
the
color
associated
with
an
rsp
lsp
in
psap,
and
that's
what
this
document
focuses
on.
Next
slide.
B
All
that
this
illustration
is
trying
to
convey
is
that
if
you
have
two
types
of
services,
a
cold
service
and
a
silver
service-
and
you
need
them
to
be
steered
separately
over,
say
a
gold
transport
tunnel
or
a
silver
transport
tunnel.
You
need
a
way
to
provide
that
marking
on
the
tunnel
and
the
mechanism,
as
I
said,
is
oblivious
to
the
to
what
happens
in
the
service
layer.
Next
slide,
the
color
tlv,
that's
being
proposed,
is
carried
in
the
lsp
object.
B
It's
carried
in
both
directions,
server
to
the
client
client
to
the
server
to
avoid
unnecessary
complications.
We
are
saying
that
the
color
is
a
property
of
the
tunnel
and
not
the
lsp.
You
could
simply
carry
it
and
carry
it
only
for
the
primary
lsp
and
not
for
anything
else.
B
We
did
think
about
adding
adding
a
new
association
for
this
but
seemed
like
an
overkill,
but
you
have
your
open
decisions.
Next
slide.
B
There
is
a
capability
bit
that's
being
introduced.
If
the
client
can
support
colors,
but
the
server
cannot
it's
a
it's,
not
a
big
deal.
Since
service
mapping
typically
happens
on
the
client
side.
If
the
server
supports
the
color
but
client
doesn't
service,
mapping
cannot
happen
and
that's
where
this
capability
really
comes
becomes
useful.
Next
line,
this
just
talks
about
how
the
pc
extension
works
in
conjunction
with
the
bgpct
work
being
bgbct
prefixes
select
resolution
schemes;
in
other
words
they
don't
directly
select
the
underlay
color.
B
So
there's
a
level
of
indirection
there.
Resolution
scheme
in
turn
is
associated
with
an
ordered
set
of
colors,
and
that's
where
this
draft
fits
in
the
color
is
mapped
to
a
specific
transport
towel.
That's
all
I
have
in
this
deck.
It's
a
new
draft.
We
believe
it's
necessary
to
have
this
defined
in
the
psep
toolkit.
B
We
believe
it's
necessary.
I
mean
it
would
be
useful
to
have
like
one
document
that
talks
about
the
steering
construct.
I
still
have
reservations
about
using
color
as
a
constraint,
but
yeah
I
mean
that's,
I'm
not
gonna.
Go
there
in
this
tech.
In
this
presentation.
H
B
Oblivious
to
what
is
used
in
the
server
service
layer
yeah,
we
just
need
something
in
p
sub
to
carry
this.
That's
all.
This
draft
is
trying
to
say
thanks
andrew.
B
Right
yeah,
if
you
have
say
if
you
do
want
to
have
like
a
on
demand,
next
top
kind
of
application,
and
you
want
to
do
automatic,
steering
based
on
the
external
color
community,
then
yeah.
We
do
need
something
in
the
pace
of
message.
That's
going
down
to
say
that
this
is
this
tunnel.
Has
this
color
associated
with
it.
C
Yes,
just
might
include
that,
as
you
do
further
visions
of
this
initial
draft.
Thank
you.
E
J
We're
going
to
start
a
quick
one,
yeah,
sorry
guys.
I
changed
my
head
to
that.
I
was
just
curious
about
the.
There
was
a
paragraph
that
commented:
if
there
was
lsp
paths
with
primary
and
secondary,
it
should
choose
one
as
deemed
as
the
primary
and
if
you
try
to
program
essentially
the
secondary,
it
should
fail.
B
B
So
as
long
as
that's
true
as
long
as
there
is
at
least
one
primary
and
you
carry
the
color
with
that
primary,
I
think
you,
you
get
the
behavior
as
I
guess.
The
reason
why
I'm.
J
B
J
J
B
A
tunnel
attribute-
and
we
don't
want
to
signal
it
for
every
lsp.
That's
there.