►
From YouTube: IETF113-PCE-20220322-1200
Description
PCE meeting session at IETF113
2022/03/22 1200
https://datatracker.ietf.org/meeting/113/proceedings/
A
Hi
everyone-
this
is
trove,
let's
start
and
I'm
sure,
by
the
time
we
welcome
everyone.
There
will
be
more
people
joining
in
so
welcome
to
the
second
session
of
the
pc
working
group
julian
and
I
are
not
on
site
and
we
have
hurry
taking
care
of
on-site
if
there
is
any
need
that
arises.
A
A
All
your
contribution,
the
things
that
you
do
on
chat
or
on
the
mic
are
contributions
to
the
itf
and
our
other
itf
ipr
rules
are
applicable,
so
please
take
care
of
that.
You
are
also
agreeing
to
working
in
a
constructive
environment,
so
take
care
of
the
anti-harassment
policies
and
other
rules
of
code
of
conduct
in
the
itf.
So
please
go
through
all
these
important
documents
which
describe
the
idea
of
processes
and
rules
that
we
live
by
so
kindly
noted.
A
Well
now,
I
think
you
must
be
getting
familiar
with
participation
both
for
in-person
as
well
as
remote.
Please
make
sure
to
join
the
meet
echo
queue
for
in-person
participants
as
well,
that
we
will
be
calling
the
cube
based
on
meet
echo
and
not
person
standing
on
the
mic,
so
we
will
have
a
common
queue
on
meet
ago.
Please
follow
that
and
kindly
take
care
of
your
audio
and
video.
A
Please
do
not
send
without
joining
the
queue
and
make
sure
to
respect
like
the
av
rules
that
we
have
with
respect
to
idf
guidelines
and
conduct.
We
must
extend
respect
and
courtesy
to
all
our
colleagues
at
all
times.
A
Sometimes
we
have
impersonal
discussions,
but
the
aim
is
always
to
contribute
to
the
global
internet
that
needs
diverse
needs
of
various
different
technical
and
operational
environment.
So
please
go
through
bcpe
54
and
follow
these
itf
guidelines
and
code
of
conduct
both
on
site,
as
well
as
on
our
mic
lines
as
well
as
jabber
and
chat.
A
A
As
I
was
mentioning.
Please
use
the
meet
echo
etiquette
join
the
queue
be
mindful
of
the
agenda
time,
though
we
have
enough
time
for
discussions
between
talks,
so
please
use
them.
Let's
have
a
good
discussion
on
today's
agenda.
A
This
is
our
part
two
of
our
agenda.
The
only
change
that
was
requested
was
a
swap
of
order
in
our
first
two
presentations
as
per
authors,
so
we
have
done
that.
Otherwise,
the
agenda
is
the
same
and
we
did
the
agenda
bashing
in
the
previous
session,
so
I
will
move
on
and
now,
let's
start
with
our
first
presenter
christian,
who
is
on
site
christian,
please
welcome.
B
Okay,
hello,
everybody.
This
is
christine
schmutzer,
I'm
standing
here
as
a
representative
for
all
the
authors
and
the
contributors
of
this
draft
and
I'm
gonna
introduce
circuit
style
segment,
routing
policies.
So
next
slide
please!
B
Those
services
generally
have
a
set
of
requirements
which
are
different
to
the
traffic
that
you
normally
run
to
carry
you
know:
internet
traffic
or
connectionless
traffic
generally
traffic,
engineered
paths
in
a
persistence
manner
are
required.
B
Strict
bandwidth
commitment,
because
this
is
generally
delivered
by
tdm
switched
networks
like
sonnet,
sdh
or
otm,
and
then
with
that
comes
also
the
requirement
for
end-to-end
path
protection,
because
that
allows
you
to
have
end-to-end
bandwidth
commitment
for
not
only
the
working
but
also
the
protect
path
and
switch
over
your
traffic
in
less
than
50,
milliseconds
and
last
but
not
least,
oem
or
path
integrity.
For
the
you
know,
engineered
paths
is
a
requirement
that
has
to
be
addressed
next
slide.
B
So
what
are
the
characteristics
of
segment,
routing
circuit
style
policies?
Essentially,
we
are
taking
two
as
our
policies,
one
in
the
forward
and
one
in
the
reverse
direction,
and
we
are
bundling
to
together
those
two
policies
in
a
bi-directional
association.
B
What
also
comes
here
in
play
is
that
for
those
sr
policies,
we
request
a
bandwidth
to
be
administ,
administrated
and
committed.
We
also
want
the
path
in
the
forward
and
the
reverse
direction,
routed
along
the
same
path
through
the
network.
So
core
routing
is
indicated
as
a
requirement
and
a
characteristic
in
order
to
make
the
path
deterministic.
B
We
actually
enforce
that
the
segment
lists
used
for
those
sr
policies
are
supposed
to
be
a
list
of
strict
hops
with
unprotected
adjacency
seats,
and
I
will
come
to
the
point
about
the
unprotected,
the
chases
it
sits
in
a
second
also
because
in
these
environments
for
those
services
generally,
the
path
should
never
change.
Up
until
an
an
operator
would
request
a
change.
B
No
path.
Re-Optimization
shall
be
applied
to
those
segment
lists
for
protection,
in
particular
end-to-end
path,
protection
or
restoration.
We
use
multiple
candidate
paths
to
build
the
recovery
schemes.
I
will
talk
in
a
second
and
because
we're
using
un
end-to-end
path
protection,
no
local
lfa,
like
protection,
is
supposed
to
happen
and
that's
why
the
segment
lists
shall
be
constructed
using
unprotected
adjacency
sits
in
order
to
of
observe
the
proper
operation
of
each
path.
B
So
what
are
we
proposing
here
in
this
informational
draft?
It's
not
you
know
any
extensions,
but
really
a
summary
of
already
defined.
You
know
mechanisms
or
constructs
to
be
grouped
together
in
order
to
form
a
solution.
B
The
network
is
expected
to
be
configured
with
unprotected
adjacency
seats
on
all
the
links
they
could
be
manually
configured
to
make
them
persistence
across
router
reloads.
They
could
also
be
allocated
by
the
system
that
this
is
an
implementation
detail.
B
Igb
and
bgbls
extensions
would
be
used
to
disseminate
the
topology
information
so
that
the
pce
used
for
the
path
computation
is
aware
of
those
adjacency
sets
with.
That.
Also
comes
that
for
each
and
every
link.
We
want
to
know
what
the
available
bandwidth
is
per
link
in
the
topology,
so
that
the
requested
bandwidth
for
the
you
know
path.
Delegation
can
be
properly
administered
in
the
topology
the
pcc.
Basically,
each
endpoint
of
the
pair
of
policies
will
delegate
the
path
computation
to
the
pce.
B
The
bi-directional
association
object
will
be
used
with
the
c
bit
set
to
one
so
that
co-routing
will
be
honored
in
the
pce
when
doing
the
path
computation
and
if
you
want
protection
recovery,
which
I
will
detail
in
the
next
slide.
We're
going
to
use
the
sr
policy
association
to
associate
multiple
candidate
paths
with
a
particular
policy
oops.
C
B
I
guess
this
was
a
test
without
whether
I
remember
what's
in
my
slide,
when
we
have
multiple
candidate
paths.
We're
gonna
use
this
joint
association
in
order
to
to
have
the
path
computation
be
done
in
a
disjoint
manner,
which
is
particularly
important
for
one
for
one
protection
and
then
again
the
strict
hops
and
no
re-optimization
will
be
covered
by
samuel
in
the
following
presentation.
B
B
So
one
very
important-
and
let's
say
the
more
comprehensive
aspect
of
circuit
style
segment,
routing
policies
are
the
recovery
schemes
because
of
those
connection,
oriented
networks
generally
giving
us
all
sorts
of
flexibility
to
operators
to
to
build
the
coverage
schemes.
We
want
to
honor
those
requirements
and
provide
solutions.
B
But
still
we
are
requesting
bandwidth
for
that
delegation.
So
the
operator
has
the
opportunity
to
recover
the
traffic
if
a
failure
happens
not
in
less
than
50
milliseconds,
but
at
you
know
an
acceptable
time
to
overall
provide
a
good,
high
availability
for
strict
topsy
for
strict
50
millisecond
protection.
The
one
for
one
protection
scheme
would
be
used.
This
is
the
bottom
left.
You
have
two
candidate
paths
again
with
two
preferences.
The
higher
preference
path
will
be
active.
If
that
one
fails,
the
second
one
will
be
activated.
B
B
B
This
is
all
I
have
to
to
share.
We
appreciate
your
comments
and
discussion,
and
we
hope
that
this
introduction
was
interesting.
E
So,
actually,
I'm
trying
to
understand
one
question
for
clarification
about
the
term
used
for
the
circuit
style
because
I'm
coming
from
the
circuit
site.
So
are
you
trying
to
approximately
following
the
kind
of
bandwidth.
D
B
Yeah,
so
maybe
one
thing
that
I
may
not
have
clearly
mentioned
so
what
I
indicated
before
is
that
for
each
and
every
link
in
the
topology
we
allocate
a
bandwidth
to
the
path
computation
element
right
and
what
the
assumption
here
is
that,
in
the
segment
routing
network,
only
circuit
style
segment,
routing
policies
have
strict
bandwidth
guarantees
and
those
guarantees
will
be
called
admission
controlled
against
the
bandwidth
that
you
have
on
a
per-link
basis.
B
Any
other
traffic
will
not
have
a
strict
bandwidth
guarantee
and
for
that
manner,
also
be
mapped
to
diffserv
queues
in
the
links
at
a
lower
priority.
So
only
what
gets
a
strict
bandwidth
guarantee
will
have
the
highest
priority
and
will
get
a
strict
commitment.
Anything
else
will
be
lower
priority
and
hence
not
have
a
strict
benefit.
E
B
F
Thanks
john
scudder
as
an
individual,
I'm
just
curious
about
you.
You
spoke
a
couple
times
about
50,
millisecond
restoration,
and
if
we
look
at
your,
maybe
it's
the
next
slide
with
the
a
and
the
z
or
well
yeah
that
one.
So
so
in
your
one
for
one.
Presumably,
you
can't
guarantee
50
milliseconds
unless
you
have,
unless
you
bound
the
the
latency
between
anz
right,
if
you're
excluding
any
kind
of
midpoint
protection,
because
all
the
protection
has
to
be
engaged
from
the
head
end.
B
Yes,
I
mean
the
the
I
guess,
the
well-known
latency
and
notification
aspect
of
you
know.
A
very
long
path
would
would
be
applied.
So
maybe
in
that
sense,
my
you
know,
goal
from
sub
50
milliseconds
was
not
100
appropriate.
I
guess
the
notion
is
that
both
paths
should
be
established
operational
in
the
data
plane
and
once
lifeless
detects
a
problem.
You
switch
over
to
the
second
path
immediately.
G
Sad
with
juniper,
my
question
is:
is
there
an
assumption
that
there
is
one
pce
managing
only
sr
paths
in
the
network,
and
is
it
only
one
pce
in
the
network
or
there
will
be
multiple
or
can
be
multiple.
B
Yeah,
that's
that's
a
quite
complex
question.
I
would
say
in
the
in
the
most
simple
consideration:
it
would
be
one
pce
responsible,
for
you
know,
placing
sr
policies
that
that
have
strict
bandwidth
guarantees.
B
Of
course
someone
could
consider
multiple
pces
somehow
collaborating,
but
the
the
problem
then
appears
is
how
to
get
a.
You
know
consistent
view
of
what
has
been
already
admitted
in
terms
of
bandwidth
guarantee
and
what
not
and
to
avoid
race
conditions,
but
I
would
say
from
a
concert,
perspective
circuit
style
segment.
Routing
policies
are
somewhat
independent
from
the
let's
say,
pc
architecture.
If
you
will.
A
Okay,
actually,
there
is
the
state
synchronization
draft
which
does
talk
about
this.
There
is
a
working
group
draft
that
we
have
pc
state
sync,
so
have
a
look
where
this
kind
of
problem
is
being
discussed
where
multiple
pc
collaborate
and
exchange
the
bandwidth
information,
yeah
fan
yank
go
ahead,
you're
next
in
queue.
H
A
Fan
are
you
able
to
speak,
maybe
use
the
chat
window
instead,
and
I
also
have
one
comment
here.
My
first
comment
would
be
at
the
at
the
very
high
level
that
if
we
are
defining
something
like
circuit
style,
sr
policy
or
whatever
we
name
it
later
on
where
this
could
be
not
just
signal
signaled
in
psap,
but
in
future
there
could
be
a
use
of
this
being
signaled
in
bgp
as
well.
A
So
first,
my
question
would
be:
is
it
really
psep
specific
or
is
this
a
generic
work
that
later
on,
can
use
signaling
in
bgp
even
yang
or
something?
And
if
it
does,
then
maybe
we
need
to
find
spring
as
a
better
home
for
the
overall
idea
of
this
circuit
style,
sr
policy,
and
only
maybe
the
next
document,
what
we
have,
which
is
the
psep
extension
that
could
focus
on
pc
work.
So
my
question
to
authors
would
be
that
is
this
really
psap
specific.
B
I
don't
think
it's
necessarily
100
psap
specific,
but
for
more
I
would
I'm
pretty
new
to
itf.
So
I
I
can't
you
know
properly
answer
your
question.
I
think,
but
I
think
what
you're
saying
is
something
that
definitely
can
be
can
be
considered
and
is
making
sense
to
me.
A
Yeah
and
also
one
thing
which
stuck
me
a
little-
we
are
saying
that
we
don't
want
pc
to
do
decomputation
here
then
the
idea
of
why
delegate
why
give
control
to
pc
when
we
actually
don't
want
pc
to
recompute
parts?
That
was
not
very
clear
to
me.
Maybe
we
should
do
stateless,
then,
and,
like
just
com,
ask
pc
to
give
us
the
path
and
no
need
to
delegate
the
path
to
pc.
So
this
part
also
was
not
clear.
Maybe
either
you
want
to
answer
now.
That's
fine!
B
Yeah,
I
probably
can't
answer
the
stateless
versus
stateful
per
se,
but
I
think
what
I
can
tell
you
from
my
interactions
with
operators
is
that
in
the
transport
world
you
know
people
like
to
have,
let's
say
a
computation
done
by
a
controller
or
a
system
and
don't
want
to
deal
with
it
manually
but
the,
but
once
it
was
chosen
it
should
be
staying
the
same
and
and
that's
where
the
requirement
is
coming
from.
A
C
Hi,
all
I'm
samuel
cyril
from
cisco
I'll,
be
presenting
draft
about
piece
of
extensions
for
silken
style
on
behalf
of
outdoors.
It's
new
draft,
so
it
was
not
presented
before
next
slide.
Please
doubt
contains
piece
of
extensions
needed
to
satisfy
requirements
of
connection
oriented
transport
services
piercing,
as
our
policies
also
called
circus
style,
as
well
as
our
policies.
C
C
The
next
slide
is
this
draft
contains
two
parts.
First,
one
is
introducing
ability
to
to
request.
State
parts,
so
part
consists,
consisting
only
from
straight
hopes
for
specific
osp
for
hazard.
That
means
do
you
swift
of
adia
senses,
it's
only
for
stateful
messages.
C
New
flag
was
introduced
and
for
stateless
messages,
just
clarification
of
existing
flag,
forcing
my
routing
well
done,
because
flight
was
introduced
in
one
of
the
initial
pc
rfcs,
and
no
clarification
was
done
as
part
of
rfc's
rfc
with
srx.
Extensions
second
part
is
about
adding
ability
to
control
part
computation
triggers
so
opera
operator
on
pcc
can
explicitly
control
part
computation
figures,
for
example,
if
that
computation
should
be,
or
if
paths
should
be
recomputed
in
case
of
topology
change
or
in
case
of
any
periodic
figure.
C
Next
slide,
please,
as
mentioned
before,
instead
was
messages.
There
was
already
offload
in
rp
object,
which
was
specified
if
the
state
part
is
requested
or
loose,
but
is
acceptable
as
well
in
pc
request
message,
but
it
was
not
explained
what
that
means
for
azar.
So
we
are
adding
the
explicit
statement
now
to
clarify
that,
in
case
of
increase
of
state
part
on
the
adsense
seats
must
be
used.
C
For
stateful
messages,
we
are
adding
new
plugin
lsp,
extended
flex
tlv
to
cover
a
similar
functionality.
Kov
is
applicable
to
both
srn
rsvp
in
pc
port
message.
Flag
is
indicating
if
pcc
requested
straight
path
and
pc
is
supposed
to
reflect
very
low
that
flag
in
pc
update
message,
so
it
will
indicate
if,
if
participation
was
done,
considering
state
power
requirement
or
not
the
name,
all
flag
was
chosen
just
because
the
offline
was
used
in
instagram
messages
as
well
on
rp
object
next
slide,
please.
C
C
Basically,
if,
if
pc
received
any
any
change,
for
example,
from
igp
or
from
vgplus
second,
is
for
blocking
any
periodical
optimizations.
So
we
are
open
to
introducing
any
other
flex
to
cover
other
takers
you
need.
Basically,
the
plea
is
extensible.
So
if
there
are
other
takers
which
can
cause
the
computation,
then
then
the
ple
can
be
still
extended
purpose.
C
All
these
dlvs
to
decay's
number
of
computations
and
part
changes
done
for
specific
lsp,
so
to
achieve
path
persistency,
even
even
though
flake
is
set
in
the
dlv
or
the
pov
gaps
and
then
all
part
computations,
all
part
communication
figures
are
allowed
and
it
is
just
on
pc
and
local
policy
of
the
pc
to
decide.
If
part
computation
should
be
triggered
or
not,
it
is
done
that
way
for
the
future,
so
any
new
flag
can
be
ended
in
background
compatibility
next
slide.
Please.
C
G
Yes,
tariq
sad
with
juniper
my
question:
it
seems
that
you
want
to
lock
the
path
after
it's
set
up.
You
don't
want
it
to
change.
So
why
not
have
one
bit
to
say,
lock
or
pin,
pin
down
the
path
instead
of
multiple.
C
C
A
I
Ahead,
yeah
just
kind
of
echoing
a
little
bit
what
character
said
is
I
really
do
like
three
computation
triggers
tlv,
but
the
idea
of
a
bit
for
pin
to
path
is
kind
of
nice,
but
in
that
same
token,
I
do
like
the
flags
that
you
have
here.
I
The
only
thing
that
I'll
just
kind
of
reiterate
that
I
had
mentioned
in
the
chat
was
it
wasn't
quite
clear
to
me
that
when
it
says
about
don't
recompute
due
to
updated
topology
information,
let's
say
something
happens
in
the
network
or
there's
uncontrolled
traffic
right.
So
if
we're
trying
to
guarantee
bandwidth
for
a
given
path
for
a
given
canada
path
and
maybe
there's
a
traffic
surge
on,
I
don't
know
legacy
ldp
traffic
or
maybe
a
lag
member
dropped,
which
means
the
capacity
dropped.
C
So
I
would
say
that
I
can
clarify
in
the
drought,
but
I
would
say
that
if
lsp
should
be
should
be
really
down,
then
basically
the
trigger
can
be
considered,
as
as
the
report
with
all
flag
indicating
that
the
pub
is
down
and
based
on
that
pc
can
potentially
still
recompute.
So
even
if
I
was
speeding
down
just
because
of
the
topology
change,
we
can
still
pc
can
still
trigger
the
part
computation
based
on
osp
going
down
and
because,
in
case
of
cs
policies,
we
have
weho
backup.
C
So
if
primary
part
is
going
down,
then
the
cup
can
still
take
over
and
primary
part
can
be
reported
as
down.
Pc
can
compute
it
because
it
can
see
lsp
reported
with
all
flag
set
to
down
and
and
then
again,
both
both
candidate
parts
can
be
up.
So
maybe
we
can
introduce
one
more
flag
here
to
indicate
if,
if
pc
can
recompute,
if
lsb
is
down
or
if,
if
it
can
recompute,
if
original
pad
is
still
valid,.
I
Yeah,
I
think
I
think
the
is
still
valid
is
the
important
part,
because
in
this
case,
if
there's
a
bandwidth
invalidation
in
the
network,
the
pcc
wouldn't
actually
be
aware
of
it,
because
naturally,
there's
no
signaling.
So
if
pc
is
doing,
let's
say
telemetry
collection,
it's
only
the
pc
that
can
actually
say
hey.
You
know
what
I'm
sending
your
traffic
flow
across
a
link
that
doesn't
support
that
capacity
anymore,
unless
of
course,
you're
doing
packet,
loss,
detection
or
something
as
well.
I
Yes,
I
I
like
the
idea
of
saying
you
know
is
pat
still
valid.
You
know
you're
permitted
to
do
something
as
long
as
you
know,
the
path
is
no
longer
valid.
I
think,
would
be
a
good
kind
of
concept
to
introduce
here.
H
I
see
I
see
all
beats
in
the
rp
object
in
of
rfc
54
50
50
right.
So
can
we
reuse
that
feat
or
do
we
have
any
reason
to
okay?
Okay,
I
saw
that
is
this
thing.
C
D
J
Okay,
just
clarification
questions
I
actually
also
did
to
the
previous
draft
preview
previous
presentation,
I
I
I
see
that
the
the
previous
draft
is
the
informational
draft.
So
can
I
understand
this
cs
policy
is
a
is
this
it's
based
on
the
sr
policy
button.
There's
no
extension,
there's
no
extension
to
the
as
our
policy.
J
Maybe
this
question
is
not
for
you,
but
for
the
previous
presenter,
but
I
I
see
I
I
am
I
correct
to
understand
this-
that
the
cs
policy
is
not
extended
by
controlling
protocol
in
terms
of
controlling
control
particle
compared
to
sr
policy,
and
I
understand
that
the
the
the.
D
J
Pc
pce
protect
protocol
extensions
to
the
sr
policy
actually
is
not
extended
and
is
inherited
as
it
is
inherited
attached
to
this
cs
policy.
C
Yeah
so
so
the
extension
itself
is
or
the
cs,
policies
are
basically
implemented
using
existing
existing
rfcs,
and
there
are
just
these
few
smaller
changes
which
are
done
which
are
needed
in
but
from
as
a
policy
perspective,
we
are
using
existing
concepts
and
I'm
not
sure
education.
Do
you
want
to
add
anything?
On
top
of
that,
I
can
see
that
we.
B
Yeah,
this
is
christian,
so
thanks
for
the
question.
Yes,
the
circuit
style,
as
our
policy
draft
is
informational,
because
we
are
not
changing
the
sr
policy
architecture
right,
so
we
are
using
existing
constructs
like
you
have
one
candidate
path
or
multiple
candidate
paths.
You
could
have
oem
or
liveness
on
the
candidate
paths
and
things
of
that
nature,
circuit
style.
B
Sr
policies
are
really
let's
say,
a
description
of
using
many
different
mechanisms
that
are
based
upon
this
policy
architecture
as
well
as
already
defined,
pcip
extensions
and
samuel's
extension
is
extensions.
Are
extensions
that
haven't
been
defined
so
far,
but
are
also
needed
to
overall
make
circuit
cell
policies
possible.
J
Yeah.
Thank
you.
I
understand
one
last
question:
if
this
cscs
policy
actually
is
targeted
to
both
srv6
and
sr
amperes
right.
J
Okay,
thank
you
and
this.
This
work
is
actually
experientially,
bringing
very
it's
very
it's
very
interesting
work
and
it
provides
a
approach
to
to
to
carry
this
the
legacy
services,
but
I
I
think
there
are
more
considerations
or
more
questions.
We
can
confirm
in
other
working
groups.
It's
also
pce
related.
B
A
Just
one
point,
just
one
point
that
I
wanted
to
also
bring
when
I
was
discussing
this
with
samuel.
My
initial
reaction
of
looking
at
this
tlv
felt
very
much
like.
Oh,
it's
a
policy
and
we
have
policy
association,
and
maybe
we
can
just
reuse
it,
but
his
reply
was
and
based
on
what
I'm
hearing
in
the
room
as
well.
A
People
would
like
not
to
use
like
you
know,
generic
policy
association,
where
you
need
to
configure
this
as
a
policy,
but
rather
have
a
sort
of
like
a
way
to
signal
this
well-known
policies
as
a
tlv
outside.
But
I
want
the
working
group
to
think
about
it,
a
little
bit
that
if
we
have
this
kind
of
well-known
policies,
what
is
the
best
way
for
us
to
signal
in
long
terms?
A
Do
we
define
tlvs
like
this,
or
should
we
come
up
with
a
way
of
defining
well-known
policies
that
can
and
still
use
our
policy
association
mechanism,
so
something
to
think
about,
and
I
would
also
be
interested
in
feedback
from
the
authors
as
well
as
others
in
the
working
group
on
that.
K
So
hello
experts,
I'm
you
from
china
telecom.
I
will
introduce
our
draft
and
some
essential
updates
next
slide.
Please.
K
K
This
document
defines
the
psap
extension
for
the
line
basis,
tractive
wording
in
native
american
network,
compare
with
the
rfc
8821,
which
describes
an
architecture
for
pc-based
traffic
engineering
in
native
lp
networks.
This
draft
describes
the
processes
of
data
packet
forwarding
system
based
on
vlan
info.
Okay.
Next
up,
please.
K
K
Based
on
the
scenario
about
the
actuator
requirements
can
be
generalized
as
follows,
which
can
which
are
consistent
with
our
fc
8821,
the
first
one
same
solution
for
native
ipv4
or
ipv6
traffic,
the
second
one
support
for
intra
or
int
and
into
domain
scenarios
step.
The
third
point
achieve
end-to-end
traffic
assurance
with
determine
determine
the
chaos
behavior
for
trafficking
requiring
a
service
assurance.
K
K
As
shown
in
this
figure,
the
procedures
are
for
vlan
based
traffic.
Forwarding
are
other
flows,
step
1
the
pc
calculates
the
explicit
route
and
sends
the
route
information
to
the
pcc
through
the
pc
initial
messages
step.
Two,
the
ingress
pcc,
like
r3
forms
the
vlm
forwarding
routine
table
and
the
transit
pcc
like
r1,
r2
and
r4,
and
the
egress
pcc,
like
r5,
forms
a
vlan
crossing
routing
table,
step,
3
the
packet
to
be
guaranteed,
matches
the
table
and
then
be
labeled
with
corresponding
with
land
tag
as
marketing
the
red
line.
K
K
The
data
packet
e-calculation
processes
is
shown
in
this
slides.
When
the
original
data
packet
was
sent
to
the
ingress
node,
it
will
look
at
the
vfr
table
of
r1.
If
matched
the
packet
will
be
labeled
with
corresponding
with
land
tag.
The
labeled
packet
will
then
will
be
sent
to
the
transient
node.
Similarly,
it
will
look
up
the
vcr
table,
which
only
contains
the
in
and
out
vlan
and
then
be
forwarded
to
the
ingress
node.
The
output
of
the
vcr
table
is
zero,
so
the
vlan
will
be
unlabeled
and
under
returns
to
the
normal
forwarding.
K
K
K
And
we
specified
the
vlan
forwarding
and
vlan
crossing
routing
table
like
the
figure
showing
in
this
site.
The
landform
routing
table
should
be
maintained
in
the
ingress
bcc
and
you
to
match
the
packet
to
the
guaranteed
base
to
to
be
guaranteed
based
on
the
source
and
destination.
Pgp
prefix
the
land
crossing
routine
table
should
be
maintained
in
the
transit
pcc
and
the
egress
pcc
through
the
mapping
of
the
in
and
the
outly
land.
K
K
K
A
One
comment
which
I
would
also
ask
is
which
I
kind
of
alluded
to
during
the
last
last
last
time
when
this
was
discussed
as
well.
But
the
thing
is
like
when
we
did
the
native
ip
work
in
pce,
we
had
the
document
in
teas
working
group
and
it's
already
an
rfc,
and
there
was
a
consensus
behind
that
approach
and
for
pc
to
add
an
extension.
It
was
pretty
straightforward
in
this
case.
A
We
are
just
defining
new
terms
here
and
I
was
still
not
sure,
and
I
wanted
to
get
a
feedback
from
the
working
group
as
well
on
whether
they
consider
this
as
a
part
of
pce
or
whether
this
idea
of
how
this
vfr
tables
and
vcr
tables
needs
to
be
described
in
some
other
place.
And
then
the
extension
should
be
done
here.
So
any
feedback
from
the
working
group
would
also
be
nice,
as
well
as
from
the
authors
on
this.
K
Yep
we
have
discussed
with
the
cooperators
and
I
think
we
have
discussed
already
and
we
made
some
updates
on
the
newly
discussed
draft
and
maybe
we
can
discuss
further
in
the
mailing
list.
L
Hello,
yes,
we
can
hear
you
yeah,
I
think
we
vcr
table
is
implementing
the
device.
So
here
the
main
point
is
the
instruction
sent
from
the
pce
to
the
pcc.
So
I
think
such
work
should
should
be
included
in
the
pc
working
group.
Okay,.
A
D
A
Tables
are
populated
and
how
they
are
maintained.
Is
that
a
part
of
pc
charter?
I'm
not
sure-
and
I
will
take
this
up
with
our
ad
and
discuss
with
julian
as
well
and
we'll,
and
we
are
looking
for
feedback
from
the
working
group
as
well.
So
please,
let
us
know
what
feedback
that
they
have
about.
This
document.
L
Okay,
I
think
we
can
treat
the
table
as
a
space
of
policy
traffic
policy,
so
it
is
using
the
existing
mechanism.
Okay,.
A
Okay,
let's
continue
that
discussion.
Let's
move
on
to
the
next
presentation.
M
M
In
this
update,
we
want
to
use
a
pce-based
document
to
include
the
management
processes
of
ipml
ip
mrdp
and
sr
multicast
trees.
The
same
idea
based
on
bgp,
has
has
already
been
accepted.
The
overall
process
includes
three
aspects.
The
first
is
multicast
tree
information
discovery.
When
a
pce
calculates
a
multicast
tree,
it
needs
to
collect
three
information
of
fruit
and
leaves
we
have
designed
corresponding
signaling
to
spot
days.
M
M
M
In
the
multicultural
trade
information
discovery,
processing
process,
ingress
cells,
source
registration
to
pce,
where
report
message
carry
multicast
source
registration
objects,
the
send
message
it
needs
to
carry
tray
identifier
to
use
used
to
identify
a
specific
multicast
tree
and
the
information
of
source.
In
this
message,
the
d
flag
needs
to
be
set
to
request
the
pce
to
calculate
the
p2mp
path
for
ingress.
M
Pce
will
respond
with
a
message
confirming
the
requests.
The
egress
is
the
multicast
receiver
joining
or
leaving
requests
to
pce.
Where
report
message
carrying
multicast
receiver
information
objects
to
send
messages
need
to
carry
three
identifiers
of
the
multicast
tree
that
accuracies
requested
to
join
or
leave,
and
the
vpn
of
receivers
and
selectively
carry
bfr
information
of
egress
in
in
their
multicast
scenario,
for
different
multicast
trees.
The
tree
identifier
is
different
for
ip
multicast.
It
is
sg
or
star
g
tuple
for
mrdp
multicast.
It
is
mrdp
flag
for
sr
multipast.
M
M
In
document
pcep
extension
for
p2
and
psr
policy,
different
from
p2mp
paths,
in
some
cases,
each
related
nodes
need
to
be
assigned
a
portrait
label
to
identifiers
to
identify
the
multicast
tree
in
vpn
scenario.
It
is
also
necessary
to
assign
vpn
forwarding
identifier.
Therefore,
we
defined
trade,
tris
failable,
static,
trv
and
vpn
forwarding
identifier
trv.
M
M
Okay
for
beer
for
beer
trade,
it's
for
pr
trade.
Firstly,
it's
a
pc,
combine,
bfr
information
of
egresses
into
with
into
b
string,
then
pc
is
sent
between
forwarding
identifier
to
egress,
verb,
update
message,
informing
some
tool
for
words.
Finally,
pcie
send
b
string
and
vpn
forwarding
identifier
to
the
ingress,
where
three
forwarding
three
forwarding
states,
synchronization
objects
to
inform
ingress
to
incur
to
encapsulate
and
forward
packets
accordingly,
depending
on
whether
to
create
or
update
a
view
tree,
the
united
message
and
update
message
as
selectively
used
in
this
message.
M
So
the
rsp
object
needs
to
carry
ip3
identifier
to
associate
tree
identifier
and
these
strings
due
to
due
to
time
constraints.
Multicasters
static,
test
synchronization
will
not
be
described
for
the
time
b
and
we
can
discuss
it
later.
That's
the
main
content
content
of
our
document.
Only
any
comment:
our
work
are
welcomed.
Thank
you.
A
Thank
you,
please
pass
the
comments
on
the
list
and,
let's
welcome
our
last
speaker.
Thank
you.
D
Hello,
can
you
help
me.
D
Okay,
thank
you,
hi,
hello,
everyone!
I'm
I'm
going
to
introduce
pcep
procedures
and
protocol
excuses
for
using
pcep
as
a
pcc
of
the
next.
Please
next
is
the
introduction.
This
draft
specifies
a
new
mechanism
where
pce
allocates
the
beer
information
centrally
and
uses
pcep
to
distribute
them
to
all
nodes.
Then
pcc
generates
a
bit
indexed
forwarding
tables.
D
There
are
two
ways
in
our
draft
to
generate
a
bit
index
forwarding
table.
The
first
is
the
pce
pcc
allocate
allocate
parameters,
for
example,
beer
sub
domain
id
bfr
id
will
be
algorithm
and
itp
algorithm
carried
by
cci
object
and
the
parameters,
for
example,
bfr
prefix
bsl
in
calculation
type,
a
bift
id
and
maxed
aside
carried
by
beer
in
capitalism,
troa
and
bfr
prefix
carried
by
efficacy
objects
to
the
pcc
on
receiving
the
beer.
Information's
allocations,
species
use
idp
protocol
to
distribute
vr
related
information
to
other
nodes.
D
The
node
calculates
the
next
hope
in
this
case,
each
tcc
only
needs
to
allocate
its
own
beer
information
by
the
pcecc.
Another
is
in
scenario
where
the
idp
protocol
is
not
used
or
available.
Each
pcc
is
allocated
its
own
and
enable
your
information
by
the
pcecc.
The
npc
pcc
generates
a
bit
based
on
the
information
that's
received.
D
The
brevis
include
a
beer
sub
domain
id
and
bfi
id
card
by
cci
object,
bfr,
prefix,
psr
bsl
in
and
incorporate
recent
type
with
the
fifth
id
and
max
si
carried
by
the
encapsulation
toa,
a
bfr
neighbor
carried
by
address
tl
and
bfr
prefix
carried
by
fpc
objects.
Next,
please,
for
this
case,
is
talk
about
the
protocol
distance.
It
includes
a
beer
capability
advertisement,
we
add
b
bit
capabilities
of
toy
to
extend,
build
capability
and
we
also
defined
a
new
pass
pass
set
up
type
for
blt
for
cci
objects.
D
We
defined
a
new
cci
object
type
for
beer
and
defines
all
the
the
uses
to
obviously
know
absolutely.
Why
is
beer
in
cap
in
calculations
after
a
way
to
carry
the
people,
the
beer
and
license
information?
And
the
other
is
addressed
to
always
carried
the
bfr
interface
and
next
hope?
Information
for
fec
object,
which
we
use
is
fgc
opposite.
One
and
f
is
object,
two,
which
is
defined
in
rfc
rfc
8664
to
carry
the
bfr
prefix.
D
Next,
please
next
is
the
extension
in
details
of
this
is
for
pcc
capabilities
of
troy.
I
knew
just
like
the
picture.
The
format
we
we
defined,
we
defined
a
new
bit.
This
is
a
b
bit
in
capability,
a
pce
cc
capabilities
of
troa.
D
If
it
said
two
one
by
a
pc,
tcp
speaker
that
indicates
that
the
pcep
speaker
is
is
a
capable
for
pcc
beta
capability
on
the
pc.
You
would
allocate
via
information
on
this
station.
Next,
please
next
is
a
new
path.
Statement
type
is
defined.
Next,
please
next
is
cci
objects.
We
define
a
new
object
type
for
beer
purpose.
It
includes
subdominant
id
the
algorithm,
itp,
algorithm,
bfr
id
and
optional
tray
next
place.
We
defined
two
optional
oppositional
ways.
Why
is
a
beer
in
cavaliers
in
some
tio?
D
It
includes
the
bt,
the
et
flag,
which
is
identifies
mps
in
captive,
incapable
lesson
of
no
mts
in
cavaliers,
listen,
and
it
also
includes
max
si
local
business
list
and
the
bift
id
next
please
next
is
the
address
to
we
will
use
address
tl.
It
carries
the
b,
auto
interface
and
next
top
information.
Next
clicks.
D
As
we
know,
beer
information
is
always
associated
with
a
host
prefix,
so
we
use
fec,
obviously
one
and
obviously
two
to
carry
the
bfr
prefix
next
place.
Next
is
next
step
is
comments.
Welcome.
Thank
you.