►
From YouTube: IETF97-I2RS-20161116-1520
Description
I2RS meeting session at IETF97
2016/11/16 1520
B
C
E
B
B
C
A
C
A
C
Flying
after
microphone,
yes
and
and
and
saying
wonderful
things,
so
I
have
a
amia
Copa
welcome
to
the
r2s
meeting.
This
is
the
agenda.
Now
we
are
going
to
do
a
little
more
aggressive
agenda
bashing,
because
I
added
two
topics
late
in
the
game
and
they
are
at
the
end
of
the
session,
and
so
my
ad
we're
to
make
sure
we
have
time
for
timing,
Oh,
yep,.
C
C
C
L
M
C
According
I
I
had
to
move
it
because
of
the
request
for
my
ad
and
so
I:
don't
have
an
option:
I,
don't
I
I
know
I
would,
unless
all
the
working
group
feel
sorry
welcome
back
them
unless,
but
actually
I
can
do
it.
This
way,
folks,
does
anybody
mind
if
we
move
the
OP
state
discussion
to
the
beginning?
C
C
Okay,
this
is
simply
a
status.
I
will
try
to
do
this
within
a
few
minutes,
so
at
the
RC
editors
is
the
arduous
protocol
security
document
at
the
IHG,
probably
at
its
last
at
it's
been,
was
the
last
holder
and
he
says,
looks
good,
but
he
hasn't
cleared
yet.
So
I
think
we're
about
to
go
to
RFC
publication
with
the
ephemeral
state.
C
In
the
beginning
of
december,
we
are
going
to
the
isg
with
the
draft
yang
l2
topology
we're
waiting
for
revision
on
both
of
those
and
then
then
was
decided
to
said
that
he
would
press
that
through
quickly.
Now,
how
important
is
our
topology
model
kudos
to
the
folks
in
this
working
group
that
the
topology
model
has
actually
been
the
center
of
many
creative
things,
and
thanks
to
is
pavan
here,
yeah
or
many
of
the
t's
folks
have
been
very
collaborative
along
with
other
people.
So
we
appreciate
that
we
are
waiting
for
implementation
reports.
C
At
this
point,
my
suggestion
to
the
working
group
is
we
get
a
little
bit
more
implementation
details
on
the
rib
and
the
filter
based
rib
and
maybe
even
the
topology
model
for
l2.
The
reason
is,
we
need
to
know
how
complex
or
non
complex
these
are
now.
What
is
what
have
been
wah
and
alia
agreed
for
the
protocol
work.
The
protocol
work
should
go
to
thee
for
the
ephemeral
state.
Yang
changes
should
go
to
net
mod.
The
protocol
were
excuse
me.
The
yang
data
modeling
work
for
a
femoral
state
should
go
to
net
mod.
C
C
Is
needing
to
be
discussed,
it
should
be
discussed
within
those
groups,
and
we
are
an
incubator
protocol,
a
discussion
we
will
give
help.
We
will
do
the
femoral
datastore
discussions
and
then
they
will
go
back
for
final
revision
there.
Now
if
this
doesn't
work,
of
course,
our
friendly
ad
will
help
us
figure
out
what
to
do
next,
but
a
multiple
stream
approach
usually
works
better,
including
having
lots
of
hallway
discussions
that
I
just
had
when
I
sent
out
a
draft
this
morning.
How
much
fun
can
one
happen
one
day?
C
Okay,
now
this
is
just
a
hackathon
report,
which
I
indicated.
One
of
the
things
I
wanted
to
indicate
is.
I
have
been
working
in
the
security
area
to
see
about
filters
to
see
what
happens
and
the
eye
to
NSF
group
has
picked
up
the
IUS
group
and
and
by
that
picked
up
the
net
mod
rest,
comp
and
protocol
and
the
yang
data
modeling.
C
C
We
may
want
to
think
about
factoring
things
into
simple
and
complete
and
have
a
model
in
which
case
it
it
will
be
something
to
discuss,
but
it's
just
a
piece
of
reporting
on
I'm
hoping
that
each
time
we
have
a
report
on
the
feasibility
now,
let
me
go
on
to
the
next
topic.
Aaliyah,
the
working
group
asked
to
hold
the
off
state
discussion
in
a
different
order.
Okay,
so
let
me
go
to
the
off
state
and
I'm,
going
to
use
the
S.
C
L
C
N
C
C
C
The
blue
is
the
in
configuration
portion
of
life
wherein
configure
8,
I'm
just
going
to
go
through
the
diagram
that
is
in
the
new
op
state
model
and
draw
a
few
ideas
for
I
to
RS
and
engage
in
some
discussion.
This
is
not
a
formalization.
This
is
a
discussion
that
hopefully
will
help
you
discuss
further
with
on
the
mail
list
and
discuss
further
with
the
net
mod
group.
If
you
have
the
confute.
C
Is
the
configuration
portion
of
the
model
and
the
purple
with
the
applied
and
off
state
is
the
actual
read-only
portion
of
the
model
that
might
be
used
by
the
configuration
on
the
right
hand?
Side
is
still
part
of
the
model.
Is
a
control
plane
data
store,
1,
&
2,
which
might
be
done
by
a
femoral
state
we
might
have
to.
It
is
potentially
possible
in
their
model
to
have
one
ephemeral,
state
data
store
or
a
second.
This
is
in
their
model.
C
I
C
Under
for
intended,
yeah
attended
is
read
right.
Thank
you,
nevermind,
it's
it's!
It's
read
right
under
intended,
my
bad!
Thank
you,
okay,
so
the
concept
would
be
that
the
IRS
protocol
would
fill
up
these
data
stores
and
then
these
data
stores
for
control
plane
would
be
merged
with
intended
and
installed,
and
the
implied
would
actually
have
the
data
remaining
ok.
So
if
have
a
box
and
the
box
has
the
intended
config
and
it
decides
it's
going
to
implement
our
to
us.
It's
like
a
box
that
says:
okay
I
have
my
intended.
C
I
have
my
our
truest
protocol,
creating
my
femoral
data
store
and
now
the
box
has
to
decide
how
to
put
it
together.
Okay,
we
might
have
in
in
the
architecture
document
we
said
we
would
have
some
operator
knobs.
It
might
tell
how
we
did
compared
between
local
config
and
a
femoral
state.
There
is
definitely
room
for
knobs
in
this
diagram.
C
We
also
said
that
any
conflicting
rights
for
a
single
ephemeral,
datastore-
we
would
one
have
one
pane
of
glass
and
the
power
and
the
two
rights
to
the
same
environment
would
would
use
the
policy
system
to
decide
which
right
were
one
and
the
rest
would
be
given
an
event
and
I'm
sure
you've
read
all
of
that
in
the
IR
2's
work.
Okay,
any
questions
on
this
data
model
because
I
just
wanted
you
to
see
it
and
think
about
it,
because
this
may
factor
in
our
decisions
on
the
list.
Okay
go
ahead.
C
This
is
work
we
have
to
work
on
and
the
second
item,
the
caching
of
iOS
client
data,
is
something
that
we
need
to
think
about.
One
of
the
things
we
decided
with
our
first
archer
s.
Protocol
definition
was
to
go
with
a
set
of
features
and
the
features
that
are
in
the
requirements
say
one
day
to
store
one
pane
of
glass,
but
many
of
you
were
patient
as
a
working
group
and
asked
about
caching
of
iOS
client
data.
C
Andy
has
always
maintained
that
it
is
really
difficult
to
go
back
and
get
the
data
at
someplace
else
and
reinstall
it.
This
multiple
data
stores
may
allow
that,
but
we
would
have
to
sit
down
and
have
a
working
group
discussion
on
anything
that
would
be
into
the
next
generation
of
the
protocol.
Ok,
so
this.
The
second
topic
is
something
I
am
bringing
up
to
you
to
think.
I
will
float
on
the
mail
list
discussions
and
we
may
have
interims
if
there
is
interest
the
first
one
on
configuration
validation
as
you
notice
in
the
diagram.
C
There
is
much
more
onus
put
on
the
ire
2's
protocol.
If
you
would
go
back
kindly
to
the
previous
slide,
where
you
see
the
IRS
data
protocol
setting
up
the
data
stores,
we've
had
many
discussions
in
the
past
about
right,
validation
and
how
we're
going
to
do
that
in
the
actual
data
store.
At
this
point,
the
model
says
that
that
really
depends
on
r2s.
Instead
of
being
a
set
of
configuration
rules,
however,
we
must
do
it
on
and
have
some
understanding
of
what
that
means
in
yang.
C
If
you
will
go
back
so
we're
in
the
best
of
all
worlds
and
the
worst
of
all
worlds,
the
best
of
all
worlds
is
the
net
mod
designers
of
op
state
have
given
us
what
we
asked
for
that.
We
asked
for
freedom
to
be
able
to
set
up
the
validation
and
to
set
the
implementation.
We
are
the
worst
of
all
worlds.
C
Now
we
get
to
design
validation,
so
this
is
another
topic
I'm
introducing
these
topics,
because,
thanks
to
the
good
work
from
that
mod,
we
now
have
a
new
framework
to
begin
discuss
as
Kent
will
indicate.
This
is
still
an
individual
draft,
so
we
are
going
to
let
their
discussions
go
a
little
farther
this
week.
But
if
it
goes
to
adoption,
then
that's
what
we
really
need
to
see
start
talking
about
now.
I
have
finished.
The
introduction.
I
will
go
to
the
questions
next
and
just
get
a
sense
of
the
room.
C
C
N
C
N
C
C
Thank
you.
That
is
a
very
good
input
to
the
chair
that
I
need
to
get
use
cases
for
that.
I
will
ask
anyone
with
that
proposal
to
provide
use
cases
and
examples
is
there
anyone
else
would
like
to
give
suggested.
This
is
a
to
the
chair
on
looking
at
new
topics,
because
we've
completed
the
first
round
of
requirements
for
protocol
one
and
I'm
reopening
in
this
discussion.
Some
of
these
topics.
N
On
the
policy
knobs
to
resolve
multiple
data
store
view
to
the
applied
configuration
view.
So
if
I
understood
correctly
from
your
previous
picture
of
you
know
the
multiple
data
stores,
so
you
have
the
control
plane,
data
store
one
and
two,
and
those
are
the
panes
of
glass
that
you
know
are
being
essentially
one
over
the
other.
That.
C
N
C
That
is
what
is
being
defined
in
the
net
mod
model.
As
far
as
I
understand
am
I,
correct,
kemp
that
that
the
control
plane
they
the
datastore
and
the
dynamic
configuration
protocols
and
the
intended
would
have
to
be
munched,
like
maybe
three
panes
of
glass,
to
come
out
with
a
final
answer.
I
Joel
I'm
not
saying
what
we're
doing
I'm
just
saying.
What's
in
the
model,
so.
O
O
O
C
N
My
issue
is,
there
is
how
we
had
this
discussion
for
over
two
years
about
panes
of
glass
and
how
will
emerge
all
together
into
a
you
know,
single
unified
view
and
how
we
will
do
it.
You
know,
and
we
will
will
we
just
allow
two
unidirectional
or
x
direction
from
from
both
ways
and
I
see
it
here
and
in
this
picture,
couldn't
figure
it
out
so
I
want
to
get
some
clarification
on
that.
That's
all
I
guess.
O
We
have
the
ephemeral
requirements
draft
which
we've
already
agreed,
which
you
said
it's
almost
done.
It
spells
out
an
approach
to
all
of
these
things.
Yes,
and
it
is
the
other
thing
that
strikes
me
is
it
is
not
the
I
Torres
working
groups
remit
to
spell
out
exactly
how
net
modern
that
conf
in
yang
get
my
rest
can't
forget,
modified
it
I'm
very
sensitive
in
other
wearing
other
hats
to
other
work
group.
C
O
C
C
I
I
That's
not
where
I'm
going
with
this
yeah.
It
has
a
line
that
feeds
into
applied
and
says
control,
plane,
protocols
mm-hmm.
So
what
is
what
I
think
intended
there
is
that
that
would
be
I
to
rest,
for
instance,
so
I
trust
is
feeding.
It
is
a
control,
plane
protocol
and
is
feeding
into
applied,
but
within
the
I
Torres
control
play
protocol,
there
could
be
multiple
data
streams
with
with
whatever
mechanisms
you
want
for
resolving
between
them
or
whatever
right.
But
all
that
resolution
happens
to
the
side
and
then
feeds
it.
C
Even
in
that
dressed
all
the
resolution
occurs
to
the
site,
as
we
agreed
in
protocol
version
1.
Okay,
let
me
go
back
to
the
questions
Joel.
Thank
you
for
your
feedback.
I
want
to
make
sure
if
there's
someone
else
and
Joel
I
think
the
last
point
is
what
you
were
emphasized.
We
need
more
implementation
input
on
current
stuff
before
we
go
to
one
and
two
and
I
I
do
now
take
that.
Is
there
anyone
else
that
would
like
to
provide
input
it
this
time
on
the
next
steps?
C
J
Yes,
this
is
a
fabric
based
management
for
the
Sentinel
network.
So,
before
details
of
this
work,
this
is
a
non
protocol.
Topology
thoughts
on
what
I
two
iced
part
you
can
do.
Also.
This
is
an
implementation
application
of
the
existing
I
twice
to
park
models,
and
it
is
the
idea
of
this
work
is
implemented
in
the
in
an
open
source
project.
So
it
has
some
codes
for
you
to
review.
J
So
next.
Thank
you
so
why
we
come
out
with
these
sorts,
why
we
will
provide
the
fabric
based
management
for
the
day,
Center
networks.
So
this
on
the
screams,
there
are
three
shots:
three
points
that
we
sink
eyes
important.
So
the
first
one
is
faster
users
of
its
deployment
so
for
the
dates
in
the
network's,
there
are
many
tenants
and
the
itch
tenants
has
their
requirements
of
new
applications
and
new
services
deployed
on
the
networks.
J
So,
in
this
case,
the
center
network
should
be
dynamically,
be
asked
to
provide
their
service
installation
on
the
networks
and
the
second
one
is
with
the
size
of
the
data
network,
increase
the
devices
and
technology
involved
where
we
increase,
which
also
complex
complicated
at
work
of
the
network
management
and
the
service
deployment,
and
the
third
one
is
the
new
technologies
can
be
used.
So,
as
we
know,
the
MBO
three
are
talking
about
the
new
technologies
for
I
for
day
Center.
J
So
the
next
one
is
what
we
would
like
to
do:
the
motivation
of
their
management.
So
if
we
put
all
the
things
you
just
one
pocket
or
in
one
box,
it's
a
can
be
many
complex.
So
in
our
concept
we
would
like
to
divide
the
whole
network
management
into
three
pieces.
Each
piece
is
where
we
divided
our
pediat.
We
added
by
the
different
type,
odd
of
administrators
so
for
the
service
layer
is,
it
is
for
the
user
service
representation.
J
It's
only
cares
about
water
users
wants
for
the
network
and
we're
not
taking
too
much
knowledge
about
the
real
devices
and
the
rear
topology
of
information,
while
the
second
one
is
the
fabric
topology
layer
which
is
used
to
manage
it.
They'll
send
the
network
fabric
topologies
and
then
the
button.
Why
is
the
physical
topology,
which
cares
about
the
real
devices
in
the
network
and
how
to
deploy
these
devices
so
the
how
to
deal
we
start
to
pour?
J
But
the
problem
is
we
divide
is
the
whole
problem
into
three
layers
and
the
each
layers
can
be
managed
by
different
administrators
using
by
using
the
models
that
we
are
defining
this
job.
So
the
objectives
of
this
to
draft
is
to
the
first
one
is
to
provide
a
date,
the
fabric
body
model,
to
manage
it.
Fabrica,
topology
and
second
why's,
the
ferry
service
to
body
model
to
represent
what
kind
of
services
for
users
they
want
over
the
net
day
centre
networks.
J
J
There
are
device
motoring
things
at
this
layer
and
the
on
the
second
layer
is
the
topology
layer,
which
is
the
fabric
to
party
layer
in
our
scenario,
so
for
this
center
network
that
ordered
a
center
network
is
composed
of
several
pots,
or
we
can
see
several
fabrics,
so
each
fabrics
can
be
considered
as
a
basic
note
for
this
net.
Welcome.
J
So
as
this
way
are
we
care
about
what
is
a
fabric,
what
type,
what
kind
of
technology
the
fabric
used
and
also
the
fabric
inter
connection,
so
at
the
a
player
which
is
the
Soviets
layer,
its
provides
a
logical
topology
information
for
the
users
and
the
lesson
to
express
how
their
networks
are
connected.
As
we
can
see,
there
are
two
end
points
on
the
screen.
End
points
can
be
considered
as
a
host
used
by
the
tenants.
The
hosts
is,
where
be
user,
to
connect
these
layers,
the
endpoints
were
provided
to
attachment
in
this
architecture.
J
The
first
active
attachment
is
at
the
physic
light
layer
and
the
second
Weiss
at
the
logical
layer.
So
by
when
the
host
sir
is
initiated
for
some
tenants
right
were
indicated,
two
positions
in
the
architecture
in
the
end
whole
system,
where
know
which
port
which
device
and
which
partying
the
underlay
network
is
mapped
to,
is
bounded
to
the
fab
reports
in
the
favorite
layer
and
also
bound
to
the
logical
layer
pots.
J
So
this
is
the
whole
process
for
the
whole
earrings
structure
of
the
work.
So
next,
so
this
is
using
the
architecture
where
we
can
use
the
fabric
topology
model
and
also
the
service
model.
So
the
there
is
a
topology
manager
which
provides
the
topology
information.
So,
as
you
can
see,
the
fabric
service
module
a
model
where
not
to
have
any
idea
about
the
topology
information,
but
only
cares
what
kind
of
connect
shun
between
this,
our
user
endpoints.
So
next?
J
Yes,
this
is
a
fabric
service
model.
It
combines
it
contains
the
two
modules
the
most
important.
Why
is
the
fabric
service
module?
It
described
a
logical
network
for
users,
so
there
are
the
basic
noting
this
module
is
the
logical,
routers,
logical
switchers,
and
there
are
also
some
logical
TPS,
which
acted
as
a
logical
pots
to
this.
Teepees
are
all
have
different
roles.
Some
of
them
are
represented,
a
layer
2
connection
and
some
of
them
are
presented
represents
the
layers
reconnection.
J
Also,
there
are
connection
to
the
endpoints,
so
it's
a
sister
from
the
logical
network
it
can
represent,
or
just
ratios
connection
between
the
endpoints.
What
the
user
look
like
their
network
is
look
like
so
next,
so
it's
also
provide
some
info
are
functions
as
in
this
module.
The
most
important
thing
in
this
module
is
I
bound
ideological
ports
to
only
pots.
So
it's
the
three
layers
can
work
together
to
so
I
just
say:
some
configuration
on
the
logical
part
can
be
mapped
to
the
physical
layer
pots
at
the
physical
networks.
J
So
next,
so
this
is
the
fabric
topology
model.
What
is
fabric
support?
You
look
like,
as
we
said
the
day
center
network
is
composed
of
the
several
pots
or
several
fabrics.
So
in
this
concept,
we
gesture
consider
each
fabric
as
a
basic
note,
so
for
the
fabrics
there
are
three
type
of
pots
are
we
which
we
call
the
fabric
pots?
This
part
can
be
connection
to
the
connect
to
the
endpoints,
and
also
this
two
audits
part
can
be
connected
to
other
fabrics
or
it
can
be
mapped
to
the
underlay
devices.
J
So
this
is
what
is
the
fabric
top
Oh
Julia
looks
like
so
next
yeah.
This
is
a
yeah.
This
is
implemented
in
a
open
source
project
and
which
is
also
released.
So
you
can
find
the
detail
of
this
project
on
the
link
on
the
screen.
Also,
there
are
some
codes
available
at
a
key
hub
which
can
be
found
at
that.
You
have
almond
daylight,
fast
project,
so
so
we
just
show
some
comments,
resolution
and
debates
since
last
meeting.
J
So
there
are
technical
changes,
we
added
how
to
our
configure
and
they
represent
a
fabric
interconnection
into
these
current
models
and
also
we
use.
We
have
another
chapter,
which
is
the
fabric
service
module
modeled
after
to
explain
how
to
use
this
fabric
model
to
deploy
your
network
in.
This
is
really
a
concept.
We
also
provide
the
better
extensibility
of
this
work,
so
also
we
can
our
send
for
the
new
also
to
join
our
work.
So
next.
C
C
You
thank
you
very
much
on
for
the
presentation.
Do
we
have
any
questions
on
the
technical
content
of
the
presentation
not
not
on
where
it
belongs
in
which
working
group,
but
on
the
technical
content
I
want
to
break
the
two
apart
these
questions,
but
I'm
specifying
the
type
of
questions
chef.
Please
don't
ask,
does
it
belong
in
tease
or
someplace
else,
we'll
deal
with
that
in
the
second
set
of
questions?
This
is
just
clarification
or
questions
about
the
technology.
Thank
you.
P
J
J
P
My
question:
how
how
do
you
plan
to
represent
it
within
the
model,
which
is
the
second
question-
the
notification
flow
I
think
very
similar
to
work.
We
are
trying
to
do
in
TS
in
multi
layer
model.
How
do
you
provide
workflow
of
notifications
from
lower
level
to
higher
level,
and
how
do
I
do
create
feedback
reactionless?
You.
J
Architecture,
one
yeah,
ok,
so
actually
the
end
point
where
provided
two
points
to
attach
points
from
the
device
at
the
physical
layer
and
also
another
from
the
logical
layers.
So
when
the
the
end
point
is
online,
so
these
three
devices
at
the
three
pots,
the
one
post
at
the
logical
layer
and
ideas.
The
second
part
is
the
fabric
layer
and
also
the
device
layer
port
where
be
bonded
together.
So.
C
Q
Q
J
C
Any
additional
comments,
technical,
wise
good
I,
encourage
the
people
of
make
comments
and
yanka
top
afterwards,
because
that's
one
of
the
reasons
we
go
through
models
is
to
see
where
your
stoop
locations,
where
there's
not
the
real
neat
thing
about
data
models
is
hopefully
that
makes
it
a
little
bit
clearer.
Okay,
I
am
going
to
go
through
the
next
one,
which
is
feedback,
as
Joel
suggested
on.
F
C
This
is
some
learning
from
the
hackathon,
as
Joel
suggested.
We
need
to
work
on
learning
things
from
what
we
had
so
I'd
like
to
go
through
the
the
filter
based
rib
and
some
conclusions.
We
have
from
the
i2
and
SF
demo.
Just
I've
mentioned
it
in
the
beginning,
but
I
want
to
get
some
feedback
from
the
working
group.
Could
you
go
to
the
next
one?
C
Ok,
so
I
think
I
went
through
all
of
this.
We
found
that
what
we
actually
implemented
it
was
initially
the
IRS
filter
based
rib
was
linked
to
the
ECA
policy.
The
ECA
policy
came
out
of
some
of
the
super
work
and
match
nicely
with
the
capabilities
of
firewalls.
What
we
found
when
we
implemented
was.
Maybe
we
should
take
a
simple
approach
and
it
was
necessary
to
be
able
to
get
a
quick
scalable
implementation
out
now.
C
That's
what's
in
the
packet,
ECA
event
condition
policy
and
we
don't
have
a
CLS,
because
we
were
going
to
try
some
implementation.
The
real
question
is,
we
really
do
need
to
put
acl's
in.
We
are
also
waiting
for
some
of
your
draft
to
sort
of
then
yeah
I
know
I
agree
it's
now
time
to
do
something
useful
like
add
to
it,
you
were
still
changing
it.
Last
last
couple
months.
C
So
we
made
some
additions
to
the
filter
based
rib.
We
added
some
events.
Should
we
have
added
them?
Should
we
put
a
CLS
in
the
current
draft
link
it
in
where
we
have
regular
filters,
or
should
we
put
it
in
a
different
one?
I
am
looking
for
some
feedback,
yeah
dan.
If
you
have
some
feedback
on
how
you
might
extend
it
or
how
you
might
work
with
policy,
routing
I
would
be
glad
to
take
that
this
is
general
high-level
feedback
that
we
learned
as
we
implement
I
haven't.
N
Read
the
draft
the
you
know
among
the
events,
so
I
can
tell
you
that
in
general
the
filters
the
ACL
drops
has
been
designed,
just
as
they
essentially
match
and
action
containers
that
you
are
putting
into
a
single
container
and
then
you
augmenting
with
the
match
and
match
in
action
statements
that
are
supported
by
that
hardware
platform.
So.
C
I
agree,
and
it's
nicely
documented
look:
that's
a
really
good
documentation
and
the
acs.
The
question
is
whether
we
should
subsume
them
under
the
the
more
complex
packet
or
put
them
on
a
side
model.
It's
just
is
its
its
model,
refactoring
questions
and
if
no
one
has
a
strong
thing,
we'll
try
some
implementation
and
see
how
it
goes.
I
just
was
looking
for
any
comments
on
the
refactoring
right
that,
right
now
it
goes
filter-based
ribs
to
the
pack
of
dca
to
the
actual
match
conditions
right.
C
Here's
a
packet
match,
here's
a
condition,
and
what
to
do
it
only
does
direct
matching,
because
that's
what's
designed
in
the
packet
eca
and
matches
the
policy
filters
in
many
boxes.
If
I
put
acl's
underneath
it
becomes
something,
that's
an
alternative
mechanism,
because
many
people
do
use
ACLs
in
that
fashion.
The
other
option
is
to
just
put
a
sales
at
a
different
place.
If
you
don't,
if
there's
no
real
strong
somebody's
implemented,
it
will
leave
it
as
is,
and
try
ACLs
and
then
update
the
model.
Well,.
N
C
C
This
time
we
tried
I
got
someone
to
work
on
a
firewall.
Next
time
we
may
be
able
to
get
a
second
implementation,
entre
pology
I,
don't
think
we've
had.
Is
anyone
had
any
two
implementations
to
work
on
the
topology
datamodel
right
now,
all
I
know
is
the
OTL
and
I
don't
know
of
anyone
else.
I
have
some
people.
Fung
said
he
might
work
with
another
mechanism.
C
L
At
the
same
time,
we
may
have
some
temporary
congestion
either
on
the
top
left
link
or
on
the
top
right
link.
Next,
please,
ok!
So
if
we
could
update
both
routers
at
the
same
time,
we
could
avoid
this
congestion.
Okay,
so
that's
one
example:
let's
see
the
next
slide,
so
we
have
a
second
example
again.
We
want
to
switch
from
the
before
to
the
after
state
and
we
have
three
routers.
We
need
to
update
r1,
r2
and
r3
next,
please.
L
So
we
want
to
perform
a
set
of
operations,
not
necessarily
at
the
same
time
in
this
example.
Next,
please,
for
example,
we
could
perform
the
three
operations
at
three
different
update
times:
t1
t2
t3,
so
that
t3
is
greater
than
t2,
which
is
greater
than
t1,
and
if
we
could
do
that,
maybe
it
would
help
us
out
next,
please.
So
what
are
we
proposing
here?
So,
first
of
all,
earlier
this
year,
RFC
7758
was
published
as
experimental.
L
It
defines
the
time
capability
in
net
conf
and
what
we're
proposing
here
is
to
leverage
the
time
capability,
and
actually
we
may
be
able
to
apply
it
to
the
rib
data
model,
to
the
data
model,
which
is
defined
in
a
current
working
group.
So,
for
example,
we
can
have
a
route
add
operation
which
includes
the
scheduled
time
operation,
so
it
the
scheduled
time
parameter.
So
this
can
define
for
this
route.
Add
when
the
router
is
expected
to
perform
the
right
ad.
L
C
N
Damn
Bogdanovic,
so
the
only.
How
will
you
know
or
how
the
system
will
know?
What
is
the
current
load
of
the
control
plane
on
the
device?
And
how
long
will
it
take
to
process
that
and
push
it
down,
because
this
is
an
unknown?
So
you
can
time
it,
but
you
still,
you
don't
know
when
that
will
be
active
on
the
wire
and
that
time
difference
between
the
applied
config
you
know,
and
you
are
what's
getting
down
on
the
wire-
is
an
unknown.
N
L
Let
me
see
if
I
understand
a
question
you're
saying
that
we're
not
sure
what's
the
propagation
delay
between
the
client
and
the
server,
so
this
may
affect
the
internal
delay
in
the
device.
Okay.
So
so,
basically,
it's
an
implementation
question
of
how
do
we
guarantee
that
the
server
or
the
router
actually
performs
the
update
exactly
at
the
time
it
was
meant
to
perform
the
update?
L
N
That's
not
the
question.
No,
it
is
a
question,
but
that's
not
the
answer,
because
this
is
you
know
the
silicon
level,
but
I'm
asking
you
when
you
hit
the
cut
the
CPU
on
the
device
that
cpu
on
the
device.
The
question
is,
how
will
I
know
from
the
CP
on
the
device
to
your
silicon
down?
That's
one
question:
once.
O
J
O
A
point
of
view
of
a
protocol
design.
We
can't
design
around
that
assumption,
and
that
was-
and
if
you
don't
make
that
assumption,
if
you
assume
there's
a
route
control
processor
that
is
controlling
the
line
card
and
changing
its
state
when
it
wants
to
change
its
state,
which
is
the
way
we
normally
think
about
these
things.
There
is
a
time
delay,
but
I
actually
have
a
much
bigger
problem
here.
O
O
For
example,
wait
a
minute:
I
have
a
preemption,
so
this
is
gone,
but
maybe
by
the
time
it
really
takes
effect,
the
preemption
its
will
be
gone,
and
so
it
should
take
effect,
and
so
we
looked
at
keeping
whole
piles
of
state
and
so
the
unwinding
state-
and
we
said
no
we're
not
doing
that.
I'd
really
like
us
to
finish
the
current
work
before
we
create
something
with
that
large.
O
C
O
L
O
L
L
L
So
this
solves
it
at
the
silicon
level.
So
there
is
software
and
there's
silicon.
The
software
installs
the
update
ahead
of
time,
a
second
ahead
of
time,
half
a
sec
ahead
of
time.
The
silicon
actually
makes
the
decision.
That's
the
idea
here
and
that's
why
we
guarantee
that
the
update
is
actually
performed
exactly
at
the
time
we
wanted
it
to
be
performed.
N
L
The
software
can
cancel
the
I
mean
once
its
installed
in
the
silicon
software
can
access
and
cancel
it.
I
mean
these
are
I
agree.
These
are
implementation,
questions
that
we
do
need
to
think
about
an
address.
But
if
you're
asking
me
as
an
implementer,
is
it
possible?
Yes,
it's
possible?
We
we
can't
dismiss
it
saying
it's
not
possible.
Is
it
difficult,
maybe.
M
Souvenir
from
quadrant
and
not
part
of
the
use
case
so
about
the
mechanism,
and
yesterday
we
presented
the
scheduling,
configuration
scheduling,
mechanisms
draft
in
the
night
mode
working
group,
and
so
you
may
want
to
check
and
see
if
that
satisfy.
For
this
kind
of
thing
we
have
a
several
separate,
different
use
cases.
You
know
man,
we
want
to
schedule
resources
on
the
particular
schedules,
so,
like
RSP
t
links
for
that's
that's
what
being
implemented
in
t
is
working
group,
but
the
pad
the
scheduling
mechanism
is
similar
right.