►
From YouTube: IETF101-SPRING-20180323-1150
Description
SPRING meeting session at IETF101
2018/03/23 1150
https://datatracker.ietf.org/meeting/101/proceedings/
A
A
A
A
A
A
A
A
A
A
There
is
not
a
letter
or
like
a
lot
of
active
resolution
so
for
those
who
restart
the
description,
sent
you
another
one.
Is
the
MSD
see
again
in
ASG
evaluation
on
the
revised
ID
needed
again
one
remaining
discus,
and
here
we
are
pending
a
reply
for
transport
RL
reviewer,
so
I
try
to
bring
in
again
unless
one
is
a
LDP
inter
walking
again
ad
review.
We
need
a
new
new
idea
for
motors
on
some
replies
to
a
virus
comment.
B
So
we
wanted
to
try
to
discuss
what
the
next
steps
for
the
the
working
group
are.
There's
surf
core
documents
that
we've
just
talked
through
and
the
ones
that
have
already
been
published
are
now
you
know
in
the
ISD
or
the
beyond
there,
and
so
one
thing
to
kind
of
gauge
what
the
set
of
technical
items
to
work
on
our
to
determine
what
this
interested
in,
determining
not
what
there's
willingness
to
put
cycles
into
such
that
we
can
capture
these
these
items
in
a
charter
review.
B
If
we
need
one
we've
had
this
discussion
a
couple
of
times,
we
had
started
it
ITF
98
in
Chicago,
and
there's
been
some
discussion
on
the
the
mailing
list,
of
course,
which
will
have
seen
and
now
we're
going
to
discuss
it
here.
So
we're
hoping
to
get
some
some
input
to
to
the
overall
next
set
of
work
items
through
through
this
meeting
and
then
through
discussion
following
it.
B
We've
had
a
number
of
different
areas
discussed
on
on
the
mailing
list
as
bits
of
as
potential
work
items,
and
we
tried
here
just
to
capture
what
the
overall
set
of
things
are.
I.
Think
that
there's
there's
a
few
things
here
that
we
already
have
within
the
work
of
their
working
groups,
OSI
v6
and
the
yang
work-
is-
has
existing
milestones
that
were
working
towards.
So
we
don't
really
need
to
do
anything
to
capture
these
as
new
work
items
the
other
parts
of
this.
B
So
then
it
seems
like
there's
pretty
strong
consensus
that
we
should
work
on
some
OAM
solutions,
as
well
as
the
policy
work
and
as
we
discussed
this
I
think
we
should
assume
that
the
the
base
state
is
that
we
work
on
those
things
that
there's
agreement.
Why
I
would
like
what
we'd
like
to
hear
from
the
working
group
is,
if
this
disagreement,
that,
though
the
OEM
and
policy
are
things
that
we
should
work
on
and
then
there's
some
other
items
in
here
like
the
service,
chaining
work
and
ingress
replication.
B
This
seems
like
there's,
be
some
less
and
less
less
interest
of
less
people
interested
in
working
on
those
items.
So
if
you
strongly
feel
that
those
things
are
things
that
should
be
in
the
working
group
and
work,
the
technical
items
who
will
work
on
next
then
thing
we'd
like
to
hear
here
on
those
so
specifically
on
the
OEM
and
SR
policy
work
is
that
anyone
that
thinks
that
we
shouldn't
buy
a
show
of
hands
work,
be
working
on
those
in
in
spring,
okay,
zero
people.
B
So
it
sounds
like
these
are
pretty
clear,
pretty
clear
things
that
we
should
work
so
then
for
the
service
chaining,
the
English
replication
things
are
their
specific
support.
Is
their
specific
comments
as
to
what
exactly
spring
should
welcome
for
those
and
people
that
are
prepared
to
work
on
those
those
items.
C
Think
so,
assuming
the
regards
to
use
of
SR
Zeffirelli
service
chaining
with
regards
to
use
of
these
segments
as
part
of
the
service
Chapman
encoding
it
as
part
of
this
segment
in
the
early
surfaces
that
could
be
a
76
years
old,
SR,
MPLS
citizen-
that
is
something
that
is
working
group,
should
work
on.
There
is
a
document
on
the
agenda
today
and
that's
clearly
within
the
scope
of
this
working
group.
D
C
E
F
G
C
J
Additional
comments
about
this,
which
hotter
walk
I,
think
the
even
the
phanerozoic
hot
her
walk
is
the
can
be
town
to
incorporate
the
possible
either
murder.
A
date
here
with
the
SR
I
also
had
also
warrior
that,
because
there's
many
working
groups
related
with
the
supreme
working
group,
so
I
hope
that
we
based
on
the
lessons
and
then
the
firm
pasta,
pasta.
Several
master
I
think
that
you
for
some
this,
the
confliction,
usually
you
identified
I-
think
they
usually
will
be
solved
as
soon
as
possible,
after
coordination
with
the
other
working
group.
C
K
C
I
Hi,
my
name
is
maja
we
for
the
morning.
Ceteris
email
is
assisted
that
that
work
should
be
reviewed
and
I.
Don't
think
that
mobility
management
should
belong
to
a
service,
it's
it
should
belong
to
DMM
working
group.
Another
proposals
are
therefore
phi
g,
including
lisp
and
ila,
and
it
is
agnostic
to
data
plane.
It
could
be
a
sir
MPLS
or
it
could
be
anything
so
only
for
the
SR
v6
part.
It
can
be
reviewed
here,
but
the
formality
management
work
should
belong
to
D
I.
B
Think
this
leads
us
on
to
the
to
a
wider
discussion
topic,
though
we
also
wanted
to
cover
so
I
think
a
couple
of
people's
mentioned
that
our
existing
documents
have
been
split
across
multiple
working
groups.
We've
had
this
approach,
whereby
we've
kind
of
do
the
the
use
case,
documents
or
the
overall
architecture
documents
and
then
the
the
individual
protocol
working
groups,
two
extensions.
B
If
the
of
them
this
is
resulted
in
a
few
sort
of
administrative
things
like
we've
ended
up
with
documents
whereby
they
solely
do
use
case,
use
cases
and
then
are
not
considered
as
a
useful
artifact
to
publish
which
is
I,
don't
think
good
for
the
working
group
in
general.
But
we
wanted
to
solicit
some
feedback
on
how
this,
inter
working
group,
where
work
should
should
work.
C
So
it
will
facilitate
the
process
that
will
give
process
and
also
potentially
accelerate
the
work,
but
I
mean
certainly
the.
There
is
no
question
that
the
work
should
be
reviewed
by
the
working
group.
That
is
the
way
the
experts
are
sitting
but
I,
like
the
approach
for
taking
were
careful
to
covert
here.
L
M
As
co-chair
of
the
LSR
working
group,
we've
started
all
these
all
the
work
protocol
working
in
the
highest
and
all
SPF
now
LS,
our
group
and
I
think
it
would
be
a
real
mistake
to
move
it
because
it's
so
intertwined
with
the
base
route,
computation,
the
multi,
topology
and
all
the
cop
and
the
signaling
affects
the
dynamics
and
the
efficiency
of
it
would
really
I
kind
of
preposterous.
Given
that
we're
waiting
for
Miss
refs
on
this
working
groups,
architecture
documents
so
I
think
that
should
be.
The
focus
is
finishing
what
it
started
here.
M
D
Again,
I
agree.
You
know,
certainly
from
the
SFC
working
group
perspective,
we've
taken
the
approach
of
you
know.
We
had
specific
architecture
in
mind
that
we
were
going
to
work
on
there
and
I
think
it
stifles
innovation.
If
you
try
and
do
everything
you
want
working
group,
so
I
think
it
makes
sense
and
we've
seen
that
with
you
know,
there's
work
going
on
in
MPLS
as
well
going
on
here
on
service
chaining,
that's
not
necessarily
taking
the
same
approach
that
we
took
so
I.
N
Stefan
from
Orange
I
think
getting
the
protocol
extension
in
spring
could
have
the
advantage
of
having
the
only
protocol
extensions
for
specific
use
case
to
be
standardized
in
a
similar
time
frame,
rather
than
splitting
them
in
multiple
working
groups.
You
could
have
some
kind
of
an
synchronization,
but
now
we
can
see
that
I
Esiason
OSPF
have
merged,
so
we
can
have
a
better
synchronization.
So
the
only
remaining
thing
is
Buju
pls.
Maybe
so
can
we
put
bt
pls
in
arizona.
O
B
P
P
So
do
you
want
to
say
is
that,
regardless
of
how
this
is
done,
the
coordination
still
needs
to
exist
right
if
the
extension
of
them
here
and
we
still
need
the
other
word
noobs
to
review
or
the
extensions
on
there,
and
we
need
to
review
some
how
the
coordination
needs
to
assist
and
I
think
this
is
a
problem
that
goes
beyond
spring
in
many
charters.
You
have
seen
because
I
know
that
all
of
you
read
everything
that
happens
in
the
writing
area.
You
see
that
it
says.
Oh,
this
is
working.
P
He
was
trained
to
collaborate
with
that
other
working
group
on
a
with
the
other
work
and
wouldn't
be.
You
know,
there's
something
that
we
really
need
to
get
better
and
you
know.
Maybe
this
is
something
that
we
need
to
think
of,
specifically
for
when
we
end
up
with
the
Charter
here
on
how
that
coordination
is
going
to
happen,
so
that
we
can,
precisely,
as
someone
else
said,
avoid
those
confusing
things
that
have
been
happening
over
the
last
couple
of
months
right.
P
So
we
can
put
a
specific
line
and
better
than
a
delineation
of
what
happens
here.
What
happens
somewhere
else
is
even
the
coordination
so
that
we
have
the
working
groups
talking
to
each
other,
the
chairs,
talking
to
each
other.
That
doesn't
mean
that
we
need
to
present
the
same
draft
in
five
different
working
groups
and
every
eights
yeah.
It
means
actual
coordination
right,
not
the
author
walking
around
the
ITF.
L
Commence,
OTS
is
not
a
dirty
word
just
so.
You
know.
There's
significant
amount
of
work
going
on
data
modelling
for
asar
topologists
augmenting
basic
topology
with
the
sir,
so
at
then,
work
here
needs
to
plug
in
into
larger
scheme
of
things.
So,
inter
working
with
tears
is
important
and
please
do
consider
it.
Q
Chris
powers,
juniper
networks,
I
would
actually
support
moving
more
towards
option.
Two
I
mean
AC,
referred
to
the
delay
in
the
segment
routing
based
documents,
but
that
delay
was
actually
quite
useful
because
there
were
many
aspects
of
that
that
were
shown
to
be
not
really
completely
well
explained
in
the
architecture.
Documents
and
Parsons
of
those
extensions
were
simply
removed,
because
no
one
really
understood
what
they,
what
purpose
they
served
and
how
they
were
supposed
to
be
used
so
that
that
delay
could
have
been
less
had
there
been
better
coordination.
C
It
is
one
model
that
can
explain
some
of
the
work,
and
that
is
if,
in
the
spring
charter,
would
bring
in
responsibility
that
any
segment
routing
work
that
is
going
on
other
working
globally
is
bringing
the
responsibility
to
be
plugged
into
that
and
then
review
that
work
and
and
and
sort
of
a
take
ownership
of
that.
From
that
point
of
view,
from
just
maybe
shows
that
that
were
proceed.
So
I
mean
there
are
working
with
charter
that
clearly
state
that
explicitly
and
and
maybe
in
the
Charter.
R
There
is
an
element
of
traffic
engineering
in
there.
There
is
a
combination
of
these
things,
so
I
believe
that
work
is
better
served
here
in
this
working
group,
but
has
to
be
reviewed
with
other
working
group
from
one
perspective.
But
that's
protocol
work
I
believe,
is
better
to
be
done
in
spring
than
any
other
working
group.
C
It
is
the
first
yeah
I
agree
with
were
being
said,
I
mean
essentially.
T
policy
was
a
normative
reference
to
a
sorry
texture.
Just
a
few
months
ago,
they're
normally
reference
was
removed
because
to
proceed.
The
document,
but
it's
T
policy,
work
the
reset
the
SR
policy
work.
That
is
here.
It
is
part
of
the
authority,
texture
and,
like
Jim
said,
is
it
it
actually
grows?
Many
aspects
like
s
all
v6
MPLS
T
is
a
small
Westar
to
that.
But
is
it
lose
the
architecture
together?
C
B
E
S
So
the
purpose
of
this
draft,
as
many
of
you
have
known,
is
to
specify
how
to
instantiate
the
segment
routing
architecture
over
the
MPLS
forwarding
plane.
The
key
modification
in
this
version
is
to
address
the
area
director
reviews
and
thank
you
very
much
for
the
detailed
review
and
to
the
second
part,
which
is
incoming
labeled
collision,
which
is
related,
but
not
identical
to
the
conflict
resolution.
S
So
I
have
already
sent
an
update
about
the
ad
review
comments
a
couple
of
weeks
back,
but
I
will
go
over
them
quickly.
So
why
is
this
document
standard
track
out
there
and
we're
specifying
many
externally
visible
behavior
that
we
need
to
make
sure
that
all
routers
follow
the
term
srl,
be
we
address
the
same
detail
the
term
index
and
how
to
use
the
index
the
if
you
label
I,
think
we
addressed
this
in
detail.
S
P
K
P
The
draft
has
been
revised
where
now
it
is
double
the
size
and
it's
like
I'm,
not
saying
it's
a
bad
thing.
Now
it's
double
the
size
most
of
it
to
answer
some
of
those
questions,
especially
the
first
one
and
I
returned
it
to
the
working
group.
So
the
important
thing
here
I
think,
is
that
now
this
work
is
part
of
the
working
group.
P
S
Yes,
sir
I'm
just
giving
an
update,
this
is
an
update
about
what
is
the
purpose
of
this
version
just
listing
them
here.
That's
why
it's
just
one
slide
and
I'm
not
putting
any
details
here.
I'm
just
saying
it's
addressed:
where
do
I?
Don't
look
up
the
review,
the
email
that
I
sent
a
couple
of
weeks
back
so
what's
a
valid
sRGB,
this
was
replied
to
next-hop
so
on
there
are
a
few
terms
that
will
be
moved
and
we
agree
they're
not
very
necessary.
S
There
are
other
many
comments
which
I
encourage
people
to
look
at
the
mailing
list
or
just
read
the
email
reply.
The
next
big
thing
is
the
incoming
labeled
collision
and
the
object
of
the
labeled
collision.
First
of
all
is
simplicity.
We
want
to
make
this
simple.
We
don't
want
to
over
engineer
it.
We
want
to
make
it
routing
protocol
independent.
If
there
is
anything
that
needs
to
be
done
in
the
routing
protocol,
it
should
not
be
sitting
here.
This
is
routing
protocol.
Specifics
objective
is
to
guarantee
consistent
Feb.
S
S
S
P
Aware
it's
not
a
needy
again,
so
just
to
be
clear
because
I
don't
think.
Maybe
I
didn't
explain
myself
very
well.
When
I
did
my
review
I'm
going
to
be
blunt,
so
I'm
going
to
apologize
when
I
read
the
draft
the
first
time
I
thought
the
draft
said
nothing,
that's
why
I
asked
by
was
even
on
the
standard
track
and
everything
that
I
thought.
The
draft
said
actually
was
already
somewhere
else
like
the
texture
document,
and
so
the
reason
I
brought.
The
IPR
question
was
because
this
draft,
the
MPLS
craft,
has
IPR
against
it.
P
I
can't
judge
whether
it's
good
or
bad,
but
because
it
didn't
say
anything
right,
I
was
surprised
that
it
had
IPR
when
the
architecture
document
doesn't
so
my
question
was
not
about.
Did
you
file
everything?
What
question
was?
Are
you
sure
you
had
to
file
against
this
draft
and
not
something
else?
Here's
again
the
IPR
doesn't
have,
or
the
architecture
story
doesn't
have
IPR
against
there,
the
paramotor
correctly,
but
this
draft
when
I
reviewed
it.
It
reflected
very
much
the
same
thing
as
the
architecture
documented
it
had
IPR.
P
So
it
just
surprised
me
that
not
did
you
file
everything,
did
you
file
it
against
the
right?
One
and
I
know
that
this
traffic
through
a
lot
of
changes
since
the
beginning.
So
maybe
at
the
very
beginning
it
reflected
something
else,
and
maybe
that's
what
you
added
back
again.
I,
don't
know,
but
you
know
my
point
is
that
that
that
was
the
question.
It
wasn't
whether
he
had
more
or
you
know,
etc,
but
really,
whether
it
was
against
the
right
one.
Okay,.
S
Thanks
for
that
clarification,
and
as
you
mentioned,
it
changed
and,
as
you
mentioned,
also
doubled
in
size.
So
probably
now
the
iCard
that
we
made
against
this
will
be
relevant,
but
I
will
still
look
at
the
IPR
to
see
if
there
is
anything
that
is
even
a
little
bit
relevant
and
we'll
make
it
so
we
do
not
guarantee
I
go
back
to
the
incoming
label
collision.
S
There
is
no
guarantee
to
domain
right
to
assistance,
as
I
said,
if
I
were
on
the
network,
I
can
always
configure
a
static
route
that
points
to
me
and
from
me
to
the
other
guy.
There
is
no
way
we
can
do
it,
so
the
idea
is
basically,
we
define
what
is
called
an
SR
feckin
SFI,
just
a
good,
old-fashioned,
MPLS
effect
that
is
related
to
segment
routing.
We
just
need
to
define
this
so
that
people
can
read
through
the
document
basic
MPLS
common
sense.
S
S
U
S
S
Each
MCC,
within
its
own
self,
will
give
me
a
FAQ
and
adjacency
set
and
a
label
an
adjacency
set
is
defined
as
a
outgoing
interface
and
a
next
hop,
and
it
will
give
me
a
label.
This
will
be
received
by
either
the
fehb
and
the
rep.
If
it
sees
the
same
label
assigned
to
multiple
facts,
it
will
basically
pick
one
of
them
only
and
the
others
will
get
either
get
dropped
to
get
downloaded.
This
is
not
really
within
this
document,
because
this
document
talks
about
MPLS
our
instantiation
of
segment
starting
over
MPLS.
S
We
important
thing
is
that
they
are
deterministic
rules
which
means
first-come,
first-serve,
there's
no
good.
If
you
have
the
same
set
of
adjacency
sis
competing
for
the
same
label,
then
that
adjacent
says
it
will
always
get
picked
or
if
I
have
a
prefix
said
and
an
adjacency
set
competing
where
the
same
label
shouldn't
happen.
Really
then
I,
let's
say
I
will
always
pick
the
prefix
it.
S
The
tiebreaking
rules
are
basically
quite
simple,
as
we've
been
doing
with
routing
protocol
for
ages,
each
stack
or
each
cross
connect
or
each
set
of
packets
that
gets
forwarded
the
same
way.
They
are
assigned
an
admin
distance.
We
pick
the
one
with
the
smallest
admin
distance
if
there
are
still
competing
effects.
You
just
pick
the
one
with
the
smallest
numerical
value
as
simple
as
that,
as
I
said,
objective
is
not
to
to
guarantee
domain
wide
consistency.
S
Redistribution
if
to
MCC
is
yet
give
prefix
and
a
prefix
in
index
to
each
other,
then
the
receiving
MCC
bit
less
an
advert
I
am
redistributing
from
OSPF
to
is
is
the
receiving
entity
which,
in
this
case
is,
is
will
only
advertise.
This
index
that
it
got
from
OSPF
if
the
sRGB
are
the
same.
If
the
sRGB
are
different,
it
is
free
to
assign
a
new
set
index,
provided
that
it
downloads
the
corresponding
label
to
the
FIP
or
it
advertise
it
without
an
index
at
all
and
it
may
get
assigned
through
some
other
mechanism.
S
B
Think,
given
the
changes
that
were
in
this,
this
version,
especially
those
of
absorption
of
the
the
conflict
resolution
draft,
it
would
be
definitely
good
to
get
the
working
group
to
review
this.
We
probably
need
to
go,
go
around
another
cycle
of
making
sure
that
it's
it's
stable,
but
this
should
really
be
one
of
our
top
priority.
S
S
S
I
You
know
on
that
router,
going
through
this
notion
of
SR
policies,
as
we
discussed
earlier
in
the
group,
it
applies,
it
has
wide
applicability.
It
applies
to
both
MPLS
and
SR
v6
data
planes.
It
has
traffic
engineering,
but
also
NFB
some
layer.
Two
there
is
a
separate
drive
for
optical
and
multicast,
so
it
has
a
wide
applicability.
I
One
of
the
key
things
that
is
defined
here
is
in
that
in
a
draft
is
also
the
steering,
so
how
are
packets
actually
stirred
on
to
this
SR
policy
or
how
are
they?
How
are
this?
How
is
that
stack
of
segments
associated
or
impose
on
that?
And
it
also
covers
some
traffic
accounting
part
just
at
a
very
high
level.
What
are
the
key
attributes?
It's
for
both
MPLS
and
I
sr
v6
data
planes.
The
key
thing
here
is
the
state
is
only
on
the
head
end
node,
it's
not.
I
You
know
all
over
the
fabric
for
a
particular
policy.
It
does
not
have
to
be
hop-by-hop
or
like
a
circuit
kind
of
a
thing.
It
lies
to
leverage
IP,
ecmp
and
those
attributes.
The
segment's
can
be
a
mix
of
topological
or
service
segments.
There
are
different
types
of
set
which
are
covered
in
the
draft.
I
These
policies
could
be
instantiated
automatically
our
provision
via
controller.
There
are
multiple
protocol
options,
BGP
SRT
P
SEP
to
do
this,
and
what
the
draft
also
talks
about
some
use
cases
where
there
is
this
integration
of
the
overlay
services
and
automated
steering
mechanisms
for
it
using
the
SR
Policy
construct
for
it.
So
it
it
is
an
integration
of
multiple.
You
know
segment
types
here,
bindings
field
is
a
key
concept
that
is
introduced
and
perhaps
defined
more
formally
in
this
document.
You
know
it
provides
scaling
a
kind
of
obesity.
I
It's
really
the
kid
forwarding
entry
Keeffe
to
the
forwarding
entry
for
the
SR
policy.
The
traffic
talks
much
more
detail
about
its
allocation,
various
options,
and
you
know
so
on
and
so
forth,
very
quick
on
the
steering
things.
These
are
all
detailed
more
in
the
draft,
so
I
wouldn't
go
over
it,
but
at
a
high
level
one
simple,
straightforward
way
is
steering
using
the
binding
set.
But
then
there
are
other
mechanisms
like
per
destination,
steering
per
flow
steering.
I
I
The
draft
was
first
presented
a
year
ago
since
then
there
have
been
several
contribution
from
you
know:
multiple
vendors
and
operators,
so
it
has
been
updated
to
with
all
a
lot
of
clarifications
and
details.
Following
those
reviews
there
are
existing
implementations
from
multiple
vendor
it.
Some
of
them
are
still
in
progress
and
also
there
are
deployments
and
trials
ongoing.
So
it's
really
key
work
that
we
are
doing
here
in
spring
in
the
interest
of
time
not
going
into
all
the
details.
I
J
The
proposed
related
with
the
PFD
policy,
is
the
idea
that
whose
SR
policy
so
I
think
for
the
past
year.
So
that's
what
we
also
has
some
a
lot
of
policies
related
with
the
panel
and
the
police
literate
relate
he
that
we,
the
traffic
theory
so
I
worried
about
the
deso
deso.
Just
on
my
worry,
the
scope
may
be
harder
to
be
controlled,
so
I
hope
that
a
user
can
be
a
clarity
finder
in
the
document.
That's
my
concern.
I
Right
so
we've
had
this
stack,
this
notion
in
segment
routing
of
the
stack
of
labels
right,
but
how?
How
does
it
node
define?
What
does
that
mean
and
as
we
have
discussed,
each
segment
could
mean
different
type.
We
have
segments
for
all
kinds
of
things,
so
the
SR
policy,
what
it
means
and
what
it
involves,
is
what
specified
or
described
in
a
document.
So
it's
not
just
you
know
term
out
there.
I
Now.
What
are
the
use
cases
for
it?
I
agree.
Maybe
there
are
many
more
use
cases
the
draft
talks
about
some
of
them,
but
I
don't
think
it's
like
a
use
case
document.
In
that
sense,
I
I
mean
I.
Think
it's
for
the
working
group
to
see
how
the
use
cases
go,
but
it's
more
formally
trying
to
define
the
notion
and
how
it
can
be
instantiated.
There
could
be
more
about
the
protocol
things,
the
BFD
and
those
aspects,
that's
I,
think
covered
in
separate
drafts
that
we
have
coming
up
later
in
the
agenda.
C
I
B
We
do
need
to
agree
what
should
go
into
this
doc.
First,
these
other
things,
though
it's
a
very
long
draft
right
now.
It
covers
a
bunch
of
diverse
things,
so
I
think
having
as
we
have
this
discussion
around
policies,
ensuring
that
we
understand
this
document
tells
you
about
this
and
it's
addressable.
For
that
that
reason,
and
then
you
split
our
additional
documents
and
working
out
what
the
set
of
documents
the
working
groups
should
produce
is
quite
important.
Yeah.
V
V
Thanks
selection,
that
is
quite
straightforward.
I
will
summarize
the
changes,
since
the
last
provision
remind
the
base
aspects,
the
based
on
set
described
in
the
document
and
also
give
an
update
on
where
we
are
in
terms
of
implementation,
particular
open
source
implementation
of
the
various
concept
described
in
the
draft.
V
The
most
important
change
in
this
version
is
that
we
are
actually
merging
to
draft
through
drops
that
have
been
presented
in
previous
ADF.
Both
have
been
presented
in
singapore.
The
first
one
was
more
focused
on
the
mpls
aspects
of
service
training
for
segment
rating,
while
the
second
one
was
segment
in
neutral
and
describe
some
proxy
behaviors
to
support
segment,
routing,
incapable
or
unaware
services.
V
V
V
Another
option
that
is
new
with
a
services
that
is
enabled
by
bio
services
is
to
have
really
a
segment
routing
awareness
service
that
will
have
its
own
local
soup
table.
So
it's
the
only
list
of
our
segment
and
could
have
different
behavior,
depending
on
the
active
segment
in
the
packet
that
it
receives.
V
V
The
service
segment
can
be
integrated
with
all
the
types
of
segments
such
as
VPN
or
traffic
engineering
segment
in
in
the
same
segment
list,
and
also
one
important
thing
is
that
it
is
a
part
to
the
end
and
the
intermediate
nodes,
the
head
and
we'll
just
push
a
list
of
segments
onto
the
packet
either
via
SSH
for
services
or
an
MPLS
level
spot
and
I
believe
we
have
a
question.
Yes,.
T
T
That
to
scale
because
the
idea
of
nsh
in
architecture
of
nsh
that
SFF
resolves
the
next
hop
and
that's
instantiated
in
a
control
plane.
So
you
you
do
define
the
service
function,
but
by
identifying
the
service
chain
and
then
each
SFF
as
notion
of
where
the
next
hop
with
this
service
function.
Gene
is
yeah.
V
In
that
case,
the
whole
service
train
will
be
defined
from
from
the
head
end
as
a
list
of
segments,
possibly
possibly
computed
by
a
controller.
So
when
the
packet
arrives
at
at
the
head
end,
if
the
hidden
that
doesn't
have
a
route
for
for
the
on
the
BGP.
Next
up
on
with
the
example
of
of
BGP,
it
can
use
mechanisms
such
as
on-demand
next
that
have
been
defined
for
the
s,
our
policy
to
to
query
a
controller
that
will
reply
with
a
CID
list,
encoding
the
best
service
train.
Okay,.
S
D
Q
D
V
We
need
we
need
a
separate
interface
as
it
is
described
today,
for
each
service
train
or
for
each
segment
list
and
in
the
future
we
may
have
some
other
type
of
kind
of
reclassification
on
the
process,
but
this
is
just
basic
basic
behavior
to
start
with,
and
obviously
it
can
be
extended
if
needed.
Yeah.
D
The
second
question
is:
do
you
take
care
of
the
cases
where,
like
some
some
of
the
the
pictures
that
I
saw,
what
kind
of
were
simplistic
pictures?
It's
a
it's
an
SF
F
to
an
SF,
but
in
reality
you
could
have
multiple
instances
of
these
service
functions
hanging
off
the
same
forwarder?
Yes,
so
and
I
want
to
be
able
to
load
balanced
my
traffic
across
and
pick
a
particular
instance.
So
when
you
do
the
proxy
function,
what
that
means
is
that
you're?
D
V
If
you
need
a
proxy
and
if
you
use
one
of
the
proxy
mechanism,
this
part
in
the
draft,
you
may
have
some
some
scalability
issues.
If
a
lot
of
a
lot
of
service
function,
instances
are,
behind
the
same,
the
same
router
or
service
function
for
mother
time,
pretty
it's
kind
of
the
same.
You
know,
signature
in
architecture.
D
My
only
concern
is
that
we've
spent
the
last
four
years
trying
to
persuade
service
vendors
to
implement
an
encapsulation
to
do
change,
and
now
what
we're
gonna
do
is
ask
them
to
implement
yet
another
encapsulation
which,
by
the
way
in
four
years
by
the
time
they
get
to
it,
there'll
be
another
encapsulation
wait.
So
what
I'm
trying
to
say
is:
let's
reuse
what
we
actually
have,
so
we
can
actually,
you
know
separate
the
problem.
D
There's
there's
the
forwarding
element
to
it,
but
then
there's
the
service
plane
element
to
it
and
the
service
vendors
are
interested
in
the
service
plane
element.
They
don't
care
about
the
forwarding
aspect.
So
that's
why
it's
important,
maybe
that
we
can
integrate
with
some
other
work
that
we've
already
done
in
IETF
and.
W
Hi
Alan
silica,
just
very
briefly
on
your
single
classification,
just
to
point
out
that
if
you
have
multiple
services,
you
can
get
an
explosion
in
your
classification
space.
If
you
have
to
do
this
product
across
all
the
classifications,
each
service
wanted
and
then
subsequent
to
that.
If
any
of
those
services
happen
to
modify
the
packet
in
a
way
that
the
initial
classifier
can't
predict,
then
your
initial
classification
begins
to
fall
down
as
well.
V
V
So
now
yeah,
it's
the
ultimate
slide
and
I
will
be
I
will
be
very
fast,
and
so
in
terms
of
implementation.
We
have
some
implementation
of
the
proxy
functions
that
are
open
source
in
Linux,
using
the
SRX
kernel
module
and
also
in
FG
dot,
IO
VPP,
and
we
now
have
also
some
very
well-known
and
use
services
that
are
segments
using
v6
capable,
which
are
IP
tables
and
of
tables
and
in
in
the
case
of
these
two.
The
segmentation
capability
is
even
in
in
mainstream,
so
it's
supported
today
really,
and
it's
not
is
coming
as
well.
V
U
Ok,
hello,
everyone,
I'm,
Carmen,
Rosa,
I'm,
introducing
present
in
this
draft
a
services
yang
model
for
base
and
Static,
just
a
very
quick
history
of
this
draft.
This
was
zero.
Zero
version
posted
last
ITF
and
this
is
version
zero,
one
which
merges
two
drafts.
This
draft
rasa
for
service
six
yang
and
drafts
who
from
Holloway.
So
this
is
the
one
combined
draft
that
I'm
presenting
now
ok,
so
this
is
kind
of
companion
document
or
companion.
U
Yang
models
for
SR,
v6
and
network
forming
document,
so
so
familiar
with
this
document
is,
is
most
needed
in
order
to
understand
this
yang
model.
It
fine
so
over
the
overview
of
the
yang
that
we
have
that
we
have
this.
This
model
basically
defines
two
things:
one
is
a
base
model
for
SI,
v6,
SRV,
six,
sigma
roaring,
as
well
as
a
static
application
that
could
use
that
you
could
use
to
configure
static,
sets
your
static
and
point
behavior
in
the
base
model.
U
Basically,
you
know
it
defines
my
procedures
and
configuration
leaves
for
managing
your
service
except
system
as
well
as
we
expect
that
this
base
model
that
we
have
defined
here
will
be
extended
by
the
relevant
technology
models
which
are
already
in
works
for
a
service.
Six
area
for
IES
is
bgp
service
function,
chaining
and
whatnot.
So
so
it
defines
three
modules
really
in
in
this
specification
bail
at
the
types
model,
which
is
a
common
definition
for
a
service.
Six
constructs
the
base
model
which
defines
the
base.
U
You
know
items
to
configure
as
displaced
as
states
for
a
given
service
except
system
and
a
static
model.
So
in
the
base
is
these
are
the
base
items
from
a
service
6
net
program
document
that
this
more,
this
young
yang
model
defines,
and
we
expect
this
to
be
reused
and
and
applied
in
other
yang
models,
as
we
go
further
in
the
base,
config
instancing
model?
What
we
really
have
is
a
simple
thing
that
how
do
you
enable
Sigma
routing
what
different
parameters
you
specify
for
the
data
plane
for
encapsulation
TTL
procreation?
In
future?
U
Perhaps
some
qsr
items
as
well
as
well
as
the
fundamental
piece
for
the
yang
for
a
service
six
is
a
locator.
So
how
do
you
specify
a
locator,
you
know,
and
how
do
you
enable
it?
So
that's
a
base
config
and
with
the
base
configured
as
a
state
model
for
the
base
as
well,
which
really
captures
three
main
things:
the
the
state
for
the
node
state
for
the
node
capabilities
for
the
locator
as
local
said.
Node
capabilities.
Just
basically
tells
you
what
what
this
node
can
do
about
a
service,
each
different
type
of
end
functions.
U
It
can
support
signal
parameter
which
a
GPS
will
signal
for
services.
Capabilities
as
well
as
different
rules
and
counters
that
are
given
played
from
a
hardware
could
support.
So
this
is
just
straight
for
the
node
straight
for
the
locator
is
simple,
but
I.
Think
most
interesting
is
state
for
a
given
state,
so
you
can
have
a
state
for
a
given
set.
You
know
how
this
set
is
allocated.
What
are
the
endpoint
behavior?
How
which
is
being
forwarded?
U
You
know
path
structure
for
the
forwarding,
as
well
as
a
per
state
counter
or
aggregate
counters
are
defined
at
this
point
in
time,
so
I'm
going
fast
because
we
all
relate
and
I
have
only
five
minutes.
This
model
also
defines
this
notification.
They
are
only
two
of
them
defined
right
now,
probably
there
will
be
room
for
more
and
we
will
extend
as
we
go
along
and
we
find
a
use
cases
so
this
this.
So
this
basically
concludes
what
the
base
defines.
U
The
second
part
of
the
document
is
a
static
application,
as
our
v6
currently
defines
how
you
can
configure
a
local
set
using
a
static
in
a
static
manner.
You
know
and
different
type
of
endpoint
behaviors
you
can
use,
and
then
you
know,
as
said
of
course,
you
have
to
use
forwarding
construct
in
order
to
not
only
allocatable
also
forward
traffic
on
your
local
set,
so
it
defines
a
construct
to
to
allow
you
configure
a
local
set
and
and
also
specify
encapsulations
and
encapsulation
could
be
a
service
6
or
could
be
an
pls.
U
If
you
just
to
recall
n
dot,
BM
allows
you
to
have
a
services
of
cassette
but
forward
an
MPLS
tables.
So
just
to
conclude
next
step
for
this
draft,
we
have
a
couple
of
pending
items
which
we
have
captured
in
section
5
q
s,
things,
argument,
support
in
your
model
and
more
and
function
support
in
our
static
model.
B
C
So
when
we
started
this
was
the
first
thing
that
was
a
reality
that
s
our
v6
network
would
be
sitting
alongside
classic
ipv6.
So
you
would
have
nodes
that
would
be
a
service,
a
cable
and
you
will
have
nodes
that
are
ipv6
capable
and
we
want
to
start
with
something
base
that
can
work
in
a
mixed
network
in
various
interworking
scenarios.
As
we
start
to
roll
s
or
v6.
C
C
So
you
don't
have
to
upgrade
the
classic
note,
whether
that
classic
note
being
the
destination
node
or
that
classic
note
being
a
transit
classic
note
it
will
it
will?
It
will
just
work
seamlessly
for
those
and
same
thing
applies
for
traceroute,
so
this
would
be
like
a
classic
trace
route
that
we
use
with
SRH
inserted.
C
So
the
packet
can
route
through
the
route
that
we
want
the
packet
to
go
through,
or
we
think
the
package
should
be
going
through,
and
but
if
we
have
a
classic,
no
TTL
X
pairing
of
a
classic
mode,
it
will
work
seamlessly.
It
would
not
know
the
rest.
So
the
only
changes
that
we
would
really
need
is
it's
not
the
transit
node,
not
the
destination
node,
but
the
ingress
node,
which
knows
that
it
is
trying
to
construct
a
trace
route
or
a
ping
via
a
Sibley's.
C
C
So
one
of
the
things
that
in
the
bank
behavior
that
we
need
is
a
CID
which
is
in
this.
We
define
a
sip
behavior
in
the
network,
programming
document,
as
Anderson
n
dot
OTP
said,
and
the
construct
for
the
Enduro
TP
stated
that
you
can
actually
have
that
said
in
the
SRH
and
have
the
target
node
burn
the
packet
for
further
processing.
So
in
this
case
the
target
node
is
the
destination
road,
where
the
a
for
:,
:,
PC,
45
set,
is
implemented.
C
X
Aren't
you
have
a
10
second
question
or
last
couple
of
scope,
questions
is
there
this
am
from
Google?
Is
there
a
way
you
can
determine
MTU
or
MOU?
And
the
second
question
is:
is
the
scope
captures
where
you
have
known,
as
so,
whatever
you
call
the
green
node
in
the
front
and
still
do
the
esrom
yeah.
C
T
T
T
The
problem
that
might
be
exists
here
is
a
similar
problem,
the
same
as
with
the
generic
traffic
engineering
path,
that
there
are
paths
at
being
monitored
from
the
ingress
of
be
if
this
session
is
disjoint
from
the
return
path
of
the
be
of
the
session
from
the
egress
the
ingress.
So
thus
failure
on
the
reverse
path
may
be
constant,
may
be.
Oops
may
be
seen
by
the
ingress
as
a
failure
of
the
path
that
being
monitored,
because
no
being
this
diagram
will
report
it
as
a
failure
in
the
diagonal.
T
So
in
order
to
minimize
this
possible
false
negative,
it's
good
to
control
the
reverse
path.
The
reverse
path
can
be
controlled,
using
extensions
to
LSP
thing,
that's
defined
in
MPLS
working
group
document,
BFD
directed
or
it
could
be
done
using
non
FAC
element
that
explicitly
lists
SIDS.
That
should
be
used
for
the
reverse
path.
T
Another
out
to
controlling
the
reverse
path
could
be
to
use
BFD
demand
mode,
the
nice
feature
of
being
the
demand
mode
that
it
could
be
done
on
and
off
dynamically,
and
the
note
that
is
put
in
big
demand
mode
would
not
be
sending
periodically
of
de
packets
so
thus
in
its
construct
that
we
consider
for
the
traffic
engineer
at
path,
unidirectional
being
monitored.
Note,
a
and
B
can
bring
B
of
this
session
to
the
Upstate,
and
then
ingress
puts
egress
in
a
demand
mode.
T
Thus,
it
B's
ceases
to
send
periodic
messages,
but
weaved
B
note
consent
messages
with
a
pole
bit
set
that
changes
its
status,
namely
when
it
detects
the
failure
from
a
so.
This
is
covered
in
b
FD,
/,
NK,
less
demand
mode,
which
is
in
its
individual
draft
and
b
FD
working
group.
So
this
is
just
shows
their
everything.
So,
let's
hope
do
I
have
time
for
one
question.
V
C
C
Talks
about
looking
into
some
of
the
requirements
that
starts
by
looking
at
some
of
the
requirements
in
terms
of
the
SR
policies
and
when
we
are
trying
to
run
VFD
session
on
top
of
the
SR
policies.
What
sort
of
consideration
we
need
to
make
so
few
things,
one
thing
that
the
SR
policies
does
not
require
any
hop
by
hop,
signaling
or
any
similar
mechanism.
So
the
previous
mechanism,
like
say,
for
instance,
of
bootstrapping,
be
every
session.
C
Really
we
don't
know
a
luxury
for
doing
something
like
that.
Second,
is
that
s
our
policy
states
by
fundamental
design
are
only,
and
only
at
the
head
of
the
English
node.
No
other
node
in
the
network
has
those
states
so
for
B
of
D
over
SR
policy.
We
should
not
be
creating
a
state
at
the
tail
end
of
the
policy.
So
that's
one
of
the
requirement.
C
Other
thing
is
that
in
many
deployment
scenarios
or
a
mostly
the
most
of
the
deployment
scenarios,
the
BFD
s,
our
policies
are
ancient
cherry
on
demand
basis,
like
odeon
use
case,
which
means
that
the
mechanism
for
BFD
has
to
be
fast
because
the
policy
before
it
starts
to
send
the
packet
on
to
the
policy.
The
ingress
node
light
to
verify
if
I
have
data
plane
connectivity.
C
So
when
we
look
at
from
this
angle,
like
we're
going
to
look
at
the
classy
PFD
and
also
as
BFP
so
classic
PFD
has
has
the
issue
of
bootstrapping
the
session
on
the
remote
end
and
it
will
slow
down
the
process
and
and
then
we
don't
have
any
signalling
mechanics
to
do
that
so
they're
two
issues,
second
part
is
that
is
bi-directional
by
design.
So
you
have
BFD
States
on
the
tail
end
of
the
router
which
s
our
policy
does
not
have
any
state
actually
with
the
tail
end.
C
Second
part:
let's
look
at
s
BFD
from
that
perspective,
so
SB
FD
is
faster
in
terms
of
session
activation
and
because
we
don't
have
to
bootstrap
anything
and-
and
then
second
part,
is
that
the
it
does
not
create
any
state
at
the
tail
end.
So
scale
would
be
completely
stateless
for
the
VFD,
which
is
the
desirable
goal
for
this,
our
policy
architecture.
C
T
Greg
Muskies
T,
so,
as
you
saw
it
was
in
the
previous
presentation.
If
you
have
traffic
engineer
SR,
then
you
cannot
guarantee
that
your
forward
and
reverse
path
of
SB
FD
session
are
corroded,
and
thus,
if
IP
network,
that
you
return
your
s,
B
of
the
packet
fails
and
doesn't
converge
with
your
detection
time,
your
you
will
have
false
negative.
Another
thing
is
that
will
we
we
will
be
bringing
we
try
to
bring
it
to
this
meeting.
But
agenda
was
to
fill
full
discussion
of
bi-directional
certain
O's.
C
I
think
this
is
their
eye.
I
think
the
first
comment
regarding
return
path,
not
having
a
return
path
towards
the
source.
We
should
discuss
more
offline
because,
as
this
so
I
think
that's
got
that
offline
and
for
the
bi-directional
policies
we
did
notice
cope
here
in
this
work,
but
we
can
discuss
that
offline
and
and
talk
more
about
even
and
have
it
here.
Thanks.
H
H
Okay,
here's
a
motivation.
We
know
that
opinion
has
been
widely
deployed
to
support
multi-tenancy
service
in
the
operators
networks.
Recently
we
have
facing
then
new
and
emerging
services
which
have
more
stringent
isolation
and
the
performance
requirement,
such
as
the
bandwidth
latency
Jeter,
on
the
shared
and
network
and
I.
Think
Stuart
has
given
a
presentation
about
the
framework
of
yeah.
He
has
repealing
the
RTG
WG
this
day.
H
Also,
as
we
are
talking
about
5g
and
whistling,
can
be,
although
this
in
technology,
this
map
is
anjana
useful
for
the
in
the
5g
context,
it
can
be
used
as
a
underpin
for
the
narrow
slicing.
Well,
you
should
be
noting
that
it
is
not
our
God
hooray,
totally
replace
its
existing
VPN
service,
because
we
should
try
to
reuse
existing
technology
as
much
as
possible
if
it
is
good
enough
for
the
service.
But
the
purpose
here
is
to
designed
a
new
service
for
the
high
demand,
elation
and
performance
for
that
kind
of
customer
service.
H
So
let's
take
a
look
at
the
existing
VPNs.
We
can
go
through
it
quickly
and
the
overlay
VPN.
Basically,
this
has
very
limited
requirement
on
the
underlay
as
the
NHS
provided
connectivity
and
this
kind
of
service
that
can
provide
the
isolation
in
the
address
space
and
the
routing
of
forwarding
tables.
But
this
kind
of
services
of
different
customers
live.
You
share
another
resource
in
the
network,
so
this
will
result
in
the
uncertainty
in
the
performance.
H
So
the
what
is
that
the
enhanced
VPN?
We
think
the
principle
here
is
that
it
will
provide
a
tighter
integration
between
the
overlay,
VPN
and
another
natural
resources.
I
think
this
characteristic
is
independent
of
the
overlay
between
signaling.
So
it
will
apprise
to
others
the
vaping
types
like
a
looser
VPN
layer,
2
VPN,
a
VPN
and
would
believe
the
order
in
order
to
achieve
this
kind
of
enhancement.
H
Some
technology,
innovation
in
the
forwarding
plane
will
be
needed
because
there'll
be
the
beautiful
nation
for
the
unguaranteed
natural
resource
for
each
VPN
service,
and
please
refer
to
the
technologies
mention
the
framework
document
and
by
the
way
we
need
to
mention
at
this
draft
will
be
moved
to
his
working
group
later
and
how,
once
we
have
this
enhancement
in
the
data
plane?
How
about
control
plane
and
basically
the
control
plane,
should
provide
the
capability
to
create
a
customized.
H
The
virtual
network
with
dedicated
natural
resource
and
this
the
control
plane
should
be
agnostic
to
the
specific
forwarding
plane
technology
used
to
guarantee
the
resource.
And
although
we
think
that
the
number
of
the
enhanced
Lybian
will
be
much
less
than
the
existing
traditional
VPN
service,
still,
we
should
consider
the
scalability
in
the
beginning,
so
the
same
routing
with
resource
reservation.
We're
saying
currently,
this
segment
out
in
to
provide
the
natural,
virtualization
and
resource
partition
is
covering
the
current
charter,
but
still
within
the
country.
H
A
sonic
technology
does
not
fully
support
this
resource
reservation,
because
services
passing
through
the
same
links
on
note
was
share.
The
result
in
the
data
plane
will
cause
the
resource
contention
due
to
the
nature
of
the
IP
traffic
like
the
traffic
burst,
needs
et
cetera,
so
we
need
to
extend,
extend
and
segment
outing
to
support
its
kind
of
resource
reservation,
our
resource
partitioning.
H
H
We
will
allocate
different
settings
CCC's
to
represent
different
partitions
of
the
resource
on
this
segment
for
allocated
for
each
different
topology,
and
then
a
group
of
the
series
associated
with
the
same
topology
can
be
used
to
construct
a
certain
route
inversion
network
with
the
resource
resource
in
the
underlay
then
can
map
to
between
services
to
the
dedicated
same
around.
In
virtual
network
depends
on
the
service
requirement,
it
can
be
very
flexible,
you
can
do
it
one
by
one
one
to
one
mapping
or
one
to
an
end
to
one
mapping.
H
This
is:
it
depends
on
the
requirement
of
the
service,
isolation
and
performance.
So
here's
an
example
about
how
to
do
the
city
allocation.
In
this
approach
we
can
see
in
this
network
we
can
use
dedicated
seats
to
represent
partitioned
link
on
know
the
resources
and
the
seats
in
the
same
color
represent.
This
is
used
in
the
same.
Topology
will
be
used
to
construct
the
isolated
virtual
network
and
this
kind
of
different
virtual
networks.
H
They
are
truly,
as
would
allocate
isolated
in
the
data
plane,
and
this
it
shows
how
this
packet
of
different,
enhancer
e-peen
are
treated
in
the
data
plane.
Basically,
we
can
see
that
a
different,
enhanced
VPN
the
service
parts
of
the
differently
has
VPN
will
be
constrained
to
the
its
own
virtual
network
topology,
and
so
it
will
only
consume
his
own
resources
reserved
in
the
network.
You
can
support
the
straight
path,
forwarding
and
also
the
load
path,
forwarding,
okay,
here,
the
over
overall
procedures
of
this
mechanism.
H
I
think
I
don't
need
to
go
through,
go
through
the
details.
Basically,
we
need
a
controller
on
the
top
to
do
the
topology
and
the
resource
computation.
Then
it
we
need
to
do
the
topology
resource
allocation
and
a
niche
network
element
in
the
network,
and
then
we
need
to
advertise
to
see
it
and
the
associated
resource
information
in
the
natural,
so
that
each
node
is
aware
of
this
but
apology,
virtual
networks.
And
finally,
we
will
find
a
VPN
service
to
these
virtual
networks.
To
achieve
this,
enhance
my
pian.
L
Jeff
ensure
inertia,
clarification
and
clarified
this
when
the
presentation
was
done
at
routing
working
group
while
talking
about
restore
reservation,
you're,
actually
talking
about
extending
path,
computation
logic
on
the
controller
to
be
topology,
aware,
there's
no
resource
generation
in
seconds
routing.
What
server
you.
L
H
H
H
Yeah
I
think
this.
We
can
see
this
a
picture.
Basically
you
use.
For
example,
only
one
link
will
have
three
C's
its
it.
Actually,
it
represents
a
partition
resource
on
this
link,
so
you
need
to
allocate
as
a
particular
resource
in
the
data
plane
for
this
link
for
this
seed
and
another
seed
on
the
same
link.
We
represent
another
portion
of
the
net
resource
on
this
link,
so
they
are
isolated
and
in
the
post
in
the
control
plane.
Also
in
the
data
plane,
I.
H
Y
A
I
Kate
internal
record
Cisco,
we
discussed
this
draft
offline,
but
I
would
like
to
echo
what
Jeff
said
whatever
is
been
presented
in
this
slide.
All
these
things
are
not
there
really
explained
in
the
draft.
The
exact
mechanisms
so
I
think
the
draft
needs
all
this
clarification
and
I'm,
also
confused
about
where
exactly
and
how
these
resources
are
reserved
and
how
it
is
done.
The
trafficker
n't
Lee
does
not
clarify
so
I
think
it's
important
that
you
describe
and
put
all
those
things
so
that
spring
working
group
can
review
it.
C
J
This
clarification
so
the
first
day
you,
the
resource,
reservation,
I,
think
so
now
the
as
Harvey
can
assume
that
a
is
always
to
do
the
bias
at
the
Mission
Control
in
the
QC.
U
controller
but
I
use.
They
are
sonoda
Axford,
the
Budweiser
guarantee
you
know
forwarding
plane.
So
the
this
is
the
messer.
The
explainer
here
used
not
only
for
the
panel.
Why
sodomy
other
means
admission
control,
but
also
the
finalized,
the
reservation
in
the
forwarding
plane.
This
is
a
first
point.
J
The
second
point
I
think
that,
regarding
the
kittens
kittens
the
comments,
because
I
think
that
I'm
Charles
te
RC
BT
at
the
item,
you
can
to
the
resource
reservation,
but
the
in
fact
is
not
a
explain
how
to
use
to
implement
a
resource
reservation,
but
I
understand
that
you
so
we'll
be
done
in
the
data
plane.
So
I
think
that
this
may
be
the
seminar
definition
or
description
for
the
for
this
draft
so
that
season.
My
okay.