►
From YouTube: IETF96-I2RS-20160720-1130
Description
I2RS meeting session at IETF96
2016/07/20 1130
A
C
C
We're
going
to
just
start,
this
is
going
to
be
much
more
informal
and
discussion
oriented
even
monday,
we're
going
to
look
at
version
7
of
the
text
to
try
to
close
it
off,
because
after
that,
oh
just
minute,
I
should
do
the
note
well
shouldn't
I.
Here
comes
a
note:
well
guys
how
many
people
haven't
ever
seen
a
note.
Well
maybe
he
needs
to
know
well,
here's
the
note
well
do
read
it
any
submission
to
the
ITF
as
a
contributor.
C
D
E
A
C
C
C
A
A
C
D
Joel
did
agree
with
me.
I
I
mean
we're,
saying
that
the
he's
saying
and
I
I
tend
to
agree
that
it's
not
the
entire
FML
config.
We're
saying
that
that
the
client
that
comes
in
has
a
priority
of
this
rights,
a
femoral
config
with
priority
of
that,
and
then
we're
saying
we
want
to
be
able
to
override
that
with
local
configuration.
C
D
C
Okay,
well,
one
that
one
more
time
on
the
list
and
make
sure
it's
okay.
Thank
you.
Okay,
that
sounds
great
okay,
so
the
rest
of
it
is
fairly
simple.
Today,
after
that
discussion,
we're
going
to
go
we're
going
to
go
through
a
couple.
Discussions
on
the
model.
Tell
you
what's
good
bad
and
changed
and
see.
If
anybody
can
give
us
some
discussion,
feedback
I
hurry,
I
was
hoping,
maybe
on
the
rib
you
do
it.
C
Alexander
and
then
G
on
the
topology
things,
because
we're
trying
to
close
off
the
discussions
on
the
bottle
and
decide
if
we're
ready
to
send
it
to
working
group
last
call
okay,
I
combined
all
of
your
model
stuff
into
one,
hopefully
I.
Didn't
she
sent
me
a
note
that
said
hi
you
have
the
wrong
file,
so
I'm
going
to
give
the
combined
file,
but
if
we
don't,
if
you
think
your
slides
are
wrong,
just
let
me
know
so.
C
C
He
said
why
didn't
we
put
in
a
rip
ID,
you
know
we
put
it
in
a
name
but
not
a
rib,
ID
and
everyplace
else.
We
had
a
name
in
a
a
rib
and
in
reality,
looking
at
the
code.
That
might
be
a
better.
So
that's
a
suggestion
to
the
through
the
working
group.
Any
questions
about
the
suggestion,
I
think
we'll
give
it
a
shot
with
code
and
see
what
happens.
Why
are
the
restrictions
on
the
next?
You
know:
where
are
the
restrictions
on
the
next
hop
change?
C
C
It's
unclear
in
the
text
and
I
think
that
maybe
editorial
while
the
next
hop
is
problems.
It
also
is
unclear
how
and
Nick's
hops
are
chosen.
Okay,
so
I
think
these
are
pieces
that
we
need
to
discuss
on
the
list.
Did
anybody
see
any
of
these
in
the
list
and
the
ribbon
sort
of
want
to
discuss
otherwise,
I'll
take
this
to
the
list,
but
I
thought
many
of
these
were
really
good.
Why
is
the
reason
for
change
their
reason
for
change
notification
and
them
for
next
hop
change
notification?
I.
I
found
that
encoding.
C
F
The
a
drink
or
Dido,
so
this
was
a
comment
because
two
documents
they
were
giving
different
structures
for
one
example:
the
all
the
next
hops
were
attached
directly
to
route
match
and
for
the
implementation
it
was
a
little
bit
strange.
So
what
we
were
proposing
is
that
they
were
in
the
same
are
key
and
you
would
point
to
the
next
hop
because
then
the
next
hops
could
be
chart
and
the
new
version
of
the
document
seems
to
be
better,
representing
that
right.
C
So
that
the,
when
you
add
and
delete
the
next
top
and
it's
shared,
it
might
be
shared
between
a
whole
bunch
of
routes.
You
need
to
inform
other
people
right.
It's
attached,
it's
one,
the
other
question
I
have
and
that's
when
I'll
float
on
the
list
is
our
next
hop
basic
is
not
is
fairly
extensive.
You
know
it's
got
every
type
of
encapsulation.
Should
it
just
be
ipv4
and
ipv6,
it
should
be
all
the
encapsulations.
E
C
G
C
E
G
E
C
I
was
looking
in
efficiency
of
code,
but
we'll
put
out
the
code
and
leave
that
one,
but
the
informing
of
the
shared
route
and
some
of
these
other
comments,
I
think
we've
got
to
take
care
of
these
are
just
you
know:
high
we've
implemented
pieces
or
John's
looked
at
it,
who's
actually
done
a
lot
of
coding.
We
should
at
least
have
answers.
We
can
say
that
the
ribs
fine,
but
the
code
should
inform
this
stuff.
C
H
Robert
rizzo,
the
most
powerful
feature
of
next
hop,
is
actual
recursion,
so
it
doesn't
really
makes
too
much
sense
to
load
it
with
all
the
attributes
of
the
tunnel.
Let's
say
because
it
will
recourse
any
way
through
the
one
with
the
tunnel.
So
if
I
have
thousand
route
in
the
overlay,
I
put
it
with
the
I
to
RS
and
one
route
with
the
channel
and
next
hub.
That's
what
the
information
belongs,
not
to
the
overlay
layer
and
that's
a
big
gain
to
actually
keep
it
I'm
different.
G
Impeller
and
I
think
it
is
marriage
and
I
would
really
need
to
think
about
that.
But
I
rather
I
have
seen
that
even
when
you
recurse
at
the
very
end,
you
end
up
by
ending
in
a
point
which
might
be
a
vrf
linked
or
something
that
it's
not
basic,
happy
before
nope
I
I
have
to
think
about
that.
But
I
think
it's
not.
C
Ok,
so
the
idea
is,
we
will
code
pieces
and
then
send
out
both
code
and
comments
on
changes,
in
other
words,
we'll
keep
will
make.
Some
of
these
are
unclear,
like
other
restrictions
in
the
next
top
chain,
that
should
at
least
be
covered
some
place
in
the
document
and
how
are
they
in
next
hops
chosen?
The
rest
will
try
to
give
code
examples
and
try
to
actually
be
practical
because
it
may
not.
C
We've
done
the
informational
draft
for
a
long
time
and
logically,
that
holds
together,
but
these
pieces
are
code
and
how
the
yang
model
holds
together.
So
we're
not
going
to
go
switch
over
from
sort
of
a
theoretical
and
we'll
start
a
mail
list
and
I'll
sort
of
put
code
snatches
out
and
and
when
will
put
code
snitches
out,
we'll
see
what
we
can
do,
but
this
is
just
to
tell
you
we're
sort
of
transitioning
into
a
yang.
That's
saying
what
does
the
code
do?
C
C
Don't
we
you
can
take
it
out
of
you
can
take
it
out
of
the
you
can
also
take
it
out
of
the
my
clinical
yeah.
It
walks
and
work.
Ok,
so
I'll,
oh
I,
spaced
it
out
so
I
could
read
because
I
your
instead
of
tiny
print
it.
You
have
several
pages
because
I
made
the
print
big
enough
to
see
in
the
back.
So
all.
I
Ok,
just
as
a
reminder,
basically
topology
in
the
model
we
define
the
topologies
can
be,
can
be
layered,
so
you
can
have
a
thing.
You
can
have
it
apology
81
they
aren't
busy.
You
have
an
overlay
topology
on
top
of
that
and
with
Beijing
means
at
the
topologies
and
nodes
and
links
the
termination
points
and
so
forth.
10
reference
supporting
nodes
links,
termination,
the
lower
levels
of
the
of
the
model
and
the
prodigies
themselves
can
be
provisioned
by
a
controller
or
they
can
also
be
discovered
by
Z,
come
into
being
really
from.
I
E
I
I
And
they
were
very
solution
that
were
discussed.
Actually,
we
went
now
actually
finally
full
circle
if
you
will
and
came
basically
back
to
the
pretty
much
to
the
original
model
that
we
had
again
quite
quite
a
while
ago,
and
basically
the
solution
is
that
we,
but
is
also
now
in
the
document
in
the
draft
that
we
have
the
same
model,
whether
the
topology
is
discovered
or
whether
it's
configured
by
client
applications
or
they
all
basically
instantiate
the
same
part
of
the
you
know
the
same
yang
module.
We
do
have
a
leaf.
I
I
Is
the
original
solution
that
is
also
went
into
the
original
opendaylight
enjoy
patient?
So
we
had
other
solutions.
I
not
sure
I
keep
is
on
the
other
pivot.
We
had
this
this
we
had
discussed
basically
a
number
of
alternatives.
One
thing
must
have
split
the
model
into
state
portion
and
clay
into
a
configuration
portion
that
have
various
issues
having
to
deal
with
how
you
are
and
how
you
extend
the
model
and
then
the
last
item
that
we
were
here.
I
K
I
One
of
the
questions
were
raised
recently
on
the
issue.
This
were
also
very.
Why
do
we
model
network
types
as
container
notnot
samosa,
please,
identity,
refs.
I
think
that
the
teacher
is
closed,
but
basically,
but
fundamentally
it's
a
one
thing
that
he
it's
a
design
choice,
but
it
facilitates
allowing
networks
to
have
multiple
types,
martinis
and
also
automatically.
This
essentially
been
reflecting
the
the
hierarchy
and
the
inheritance
hierarchy,
basically
of
the
topology
that
basically,
a
topology
is
also
part
of
a
up
with
super
types.
I
I
Did
undergo
a
young
doctor
review
and
was
deemed
in
reasonable
shape?
There
are
few
updates
needed.
Actually,
we
are
well
that
particularly
many
of
the
yeah
sophia
is
is,
and
so
both
objects
actually
require
updates
in
terms
of
the
description
and
so
forth,
and
so
ready
some
of
the
draft
updates
that
need
our
editorial
clarifications
and
yeah
with
some
of
the
others
here.
So
hopefully,.
I
Some
time
to
meteor
during
this
week,
and
the
other
suggestion
that
was
made
to
also
coordinate
with
the
young
authors
of
the
ospf
and
I
is,
is
working
groups
because
there
are
submodels
defined
in
the
alias
late
apology
to
talk
about
ospf
and
is
is
specifically
so.
That
is,
we
need
to
make
sure
that
we
have
a
consolidated
picture.
C
Questions:
okay,
I
want
it
is
the
intent
to
the
next
step
to
be
to
go
to
working
group
last
call
and
based
on
discussions.
We
had
with
Benoit
yesterday
to
go
ahead
and
do
this
in
advance
of
even
the
net
confident
mod
working
group
settling
on
their
off
state
versus
non
op
state.
So
we
can.
That
is
the
chairs
antennas
to
do
a
working
group
last
call
once
these
editorial
pieces
come
in.
Are
there
questions?
C
L
So
here
are
some
brief
update
about
the
layer
do
topology
model.
We
received
some
comments
from
the
routing
director
review
so
in
some
update
accordingly,
specs
is
this:
a
leer
tu
topology
model
is
based
on
the
generic
network
and
the
network
topology
model
some
alimentation
for
the
little
specific
attributes.
L
So
this
time
in
this
latest
update,
we
add
the
system
MAC
address
in
the
little
to
no
attributes,
and
also
the
VN
ID
is
added
for
knows
which
support
of
excellent
for
the
layers
to
termination
point
I
should
be,
we
add
a
layer
to
address
for
the
legacy
termination
point
types.
This
is
a
the
most
of
the
updates
in
this
version
of
the
model
and
in
the
description
we
clarify
that
this
layer,
2
topology
model,
can
be
used
for
both
the
physical
virtual
network
topologies
and
also
the
logic
and
watch
virtual
there's.
L
C
Ok,
I
think
we'll
send
through
the
ones
with
implementation,
and
we
can
always
augment
this
as
we
get
an
implementation
or
an
initial
idea.
Thank
You
G
for
your
time.
Ok,
so
on
our
agenda.
For
today,
we've
made
good
progress
against
our
time
frame,
which
was
very
short.
We've
done
our
model
discussion
and
we're
about
five
minutes
early.
G
Okay,
that
want
to
thank
you
super
much
for
the
introduction
and
for
the
possibility
of
sharing
this
insights
with
the
group
this.
As
you
see,
this
comes
from
a
no
no,
no
that
it's
it's
good,
that
okay,
like
that,
it's
fine!
It
would
be
fine
with
me,
so
this
comes
out
from
a
project
which
is
called
net
ID
part
of
the
fp7
framework
in
the
European
Union
and
although
not
specific
I
to
RS.
G
G
It
was
very,
very
open
flow
centric
at
the
beginning,
but
we
are
extending
it
but
where
they
have
been
extended
to
cover
other
protocols,
so
current
status
open
flow,
we
r
version,
oblivious
and
all
the
things
we
are
doing,
and
we
are
extending
that
to
anything
that
is
supported
on
netconf
and
as
a
protocol.
Next,
one
short
recap
of
the
architecture
and
I
think
there's
some.
G
It
was
partially
in
even
inspired
with
by
the
architectural
you
have
been
working
here
on
in
in
I
to
RS,
so
we
have
an
open
flow
controller
in
the
bottom,
which
is
what
we
call
this
servo
controller
framework
that
has
a
short
shim
layer.
Then
we
have
a
core
layer
or
the
magic
regarding
computer
solution
and
application
composition
and
then
at
the
book
at
the
top,
we
have
a
three
wonderful.
G
We
have
another
layer
which
has
the
control
controllers,
the
client
controller
soaring,
and
those
climb
controllers
are
those
that
are
actually
executing
the
applications
for
the
different
applications.
Actually,
we
go
into
more
further
step
and
say
that
the
applications
that
are
being
executed
in
the
are
actually
just
modules
of
something
bigger
and
that's
what
we
call
our
a
net
ID
application.
G
But
if
you
want
to
go
to
a
bigger
production
environment,
you
need
something
at
the
bottom,
something
facing
the
network
that
is
more
reliable
and
that
basically
the
work
my
team
did
was
more
on
open
daylight
and
within
the
project
we
have
PA
partners
who
are
very
proficient
in
honors
and
they've,
also
been
working
on
the
network
controller
facing
the
network
elements
being
honest
and
all
the
things
you
see
here
very
much.
What
the
onf
is
saying
about:
sdn,
architectures
and
next
slide.
G
Please
so
our
model
is,
you
have
a
module,
ok
that
might
be
receiving
an
input,
an
event
or
no
input
or
multiple
input.
This
is
why
I
put
am
putting
here
that
famous
star
in
the
events
and
that
module,
which
is
basically
a
small
as
the
end
application,
may
generate
zero
or
more
commands.
That's
the
general
model
of
the
of
the
OpenFlow
application,
and
you
say
you
can't
receive
events
or
not
and
you
can
produce
commands
or
not
I,
don't
know
if
that's
a
model
or
non
model.
That's
my
first
question.
G
Or
simplifying
that
please
next
slide,
so
we
wanted
to
look
at
a
complete
resolution
right,
so
we
had
to
do
some
assumptions.
First
of
all,
is
that
if
you
have
the
network
state
as
such,
any
command
isolated
with
no
context
will
not
produce
any
kind
of
conflict
akin
to
the
network
state,
because
you
really
cannot
tell
whether
the
is
a
conflict
or
not.
G
There
are
things
that
may
sound
like
conflicts
like,
for
example,
you
have
a
network
interface
and
you
want
to
shut
it
down,
despite
this
being
currently
active,
but
there
are
applications
that
do
that
for,
for
example,
energy
efficiency,
there's
no
conflict
than
that
for
us
another
thing
is
you
have
a
prefix
and
you
may
want
to
change
the
network.
The
next
stop
for
whatever
reason,
for
example,
the
you
have
a
link
that
is
overflowing.
G
The
other
thing
we
said
is:
ok,
if
you
have
a
nun
result,
that
is
not
what
you're
really
intended
by
doing
this
actions,
if
that
was
an
isolated
come
on,
you
have
to
look
into
the
application
erode.
You
cannot
rely
on
someone
on
telling
you
that
this
is
a
an
actual
conflict.
You
have
to
look
up,
and
the
other
thing
is
that
in
this
case,
for
us
at
least,
the
network
element
should
not
try
to
resolve
any
kind
of
complex
there.
So.
I
G
G
Had
a
long
discussion
on
so
you
really
need
to
have
a
neck.
That
would
be
the
next
slide,
as
you
really
need
to
have
more
than
one
this
one
yeah.
You
really
need
to
have
more
than
one
command
that
is
generated
by
the
same
event
to
start
speaking
about
conflict.
If
you
have
an
event
that
generates
a
command
with
one
module
and
that
same
event
generates
another
command
on
another
module,
then
you
can
start
talking
about
a
complete
resolution.
G
So
what
we
wanted,
what
we
did
was
actually
binding
the
resulting
commands
to
it
to
the
event
that
generated
them
in
the
module
and
that's
what
we
call
a
transaction
and
for
that
we
actually
went
into
some
of
the
controllers
and
started
implementing
books
so
that
you
can
actually
delimit
one
a
water
transaction
is
next
slide.
Please.
G
So
when
you
have
a
transactions
and
when
you
start
doing
for
a
working
with
transactions,
then
you
can
start
to
talk
about
conflicts
between
kelan's.
Why?
Because,
when
you
have
two
or
more
transactions
that
are
triggered
by
the
same
network
event
and
sent
to
the
network,
then
you
can
actually
define
what
a
conflict
is.
For
example,
if
one
applications
tells
me
to
activate
an
interface
and
another
one
tells
me
to
take
to
turn
it
down
to
shut
it
off,
then
there's
a
conflict
there
and
that's
something
that
you
can
actually
start
doing
actions
it.
G
That
would
be
another
one
or
set
I
always
say,
shut
up,
shut
down
or
activate
an
interface.
But
the
next
stop
is
a
wonderful
secondary
example.
Yeah,
it's
it's
a
it's!
It's
you
in
a
better
example
of
the
not
turning
on
and
off
the
interfaces,
a
Joe
Clark,
but
meaning
to
request,
with
the
same
priority,
to
request
for
the
same
priority
generated
by
the
same
event.
So.
C
G
E
G
The
classical
examples,
if
you
have
a
firewall
that
is
facing
the
internet
and
then
you
have
a
layer
to
switch
that
is
the
your
functionality
in
in
a
in
a
deliver
in
a
DMZ
in
a
data
center.
You
may
want
to
implement
those
things
as
as
the
end
and
then
suddenly,
you
find
a
couple
of
very
interesting
effects.
Next
slide.
G
Next,
like
please
so
one
of
the
things
we
are
currently
doing.
All
these
things
in
open
flow,
less
code
available
in
our
github.
We
have
a
github
in
thee
with
all
the
code
there.
If
you
want
to
experiment
with
that,
we
have,
we
are
working
currently
with
the
air
with
a
integration
of
net
compass,
they're
carrying
protocol
and
then
looking
what
is
inside
there
and
the
other
thing
where
I
really
need
to
have
some
sort
of
help.
Here
is
what
happens
when
you
have
applications
that
are
proactive
ie.
They
they
don't.
G
E
B
G
B
G
Send
reflect
on
me,
english,
yep
again,
the
code
is
available.
You
can
mix
and
match
all
kinds
of
of
the
applications
there
and,
although
it's
open
flow,
specific
I
think
the
concept
the
concept
might
be
interesting
for
for
the
group
to
discuss
on
to
further
elaborate,
so
the
the
github
is
and
net
ID.
If
FPS
and
anetta
fp7
/
net
ID
and
there
you'll
find
everything.
Oh
the
code,
we
have
if.
G
C
You're
welcome
one
thing:
that's
really
been
interesting.
Another
part
of
his
group
was
looking
at
firewalls
and
looking
in
resolution
of
firewall
conflict
rules,
which
applies
to
our
filter
based
rib,
because
in
the
end,
what
how
do
you
define
if
two
filters
are
conflict
right
now?
We
just
have
two
entries
based
on
a
prefix
and
a
priority,
and
that's
about
what
the
basic
grip
is,
but
their
group
went
on
and
and
tried
to
talk
out
at
a
higher
level
for
the
application.
What
does
it
mean
to
have
rules
conflict?
C
What
are
the
ways
that
people
resolve
it?
For
example,
if
you
have
a
global
security
policy
and
then
a
local
security
policy,
there's
a
resolution
for
security
devices.
Now
that's
above
r2s
work
for
just
setting
the
filter
based
policy,
but
it's
interesting
to
know
the
applications,
because
it
may
help
us
understand
what
we're
doing
yeah
and.
G
C
And-
and
so
these
filters
and
the
conflict
resolution
provide
a
way
to
compare
policy
and
way
to
compare
pieces.
One
of
the
things
we
had
in
our
early
discussions
about
priority
and
priority
resolution
was
how
could
it
really
deal
with
the
filter
base
trip
where
you're
actually
putting
in
essentially
an
extensive
of
ACL
or
a
a
packet-based
ECA
policy?
C
So
I
just
ask
Pedro
if
he'd
go
ahead
and
give
this
presentation,
because
we
talked
about
initially
what
happened
right
now,
we're
treating
all
of
the
ephemeral
work
as
a
single
pane
of
glass,
but
in
the
future
we
may
want
to
reconsider
how
clients
work
and
that
had
to
do
with
how
you
do
resolution
within
the
pain,
the
set
of
panes
of
glass
that
are
ephemeral.
Okay,.
M
One
okay.
Thank
you.
Please
go
ahead.
Thank
you.
Thank
you
for
giving
me
the
opportunity
to
present
our
chart.
This
is
about
a
day
Center
fabric
topology.
So
the
scenario
is
what
we
want
to
talk
about
here
is
state
center
networks
actually,
nowadays,
with
the
increase
of
big
data
and
many
applications
at
the
data
in
the
network
is
much
more
important,
so
they
met
at
a
center
network
is
also
a
big
market
for
no,
no,
not
only
the
enterprise
but
also
the
operators.
M
M
So
when
the
new
overlay
technologies
or
and
new
technologies
applying
to
this
kind
of
big
network
and
also
for
the
scale
of
this
network
sighs
we
are
here
to
the
administrators
have
to
do
much
work,
they
have
to
care
about
each
notes
and
it's
applied
technologies
which
causes
the
complexity
of
network
management.
As
we
may
know,
the
center
is
composed
of
fabrics
which
also
know
as
spots
when
the
skin
are,
when
the
dissenters
gears
at
the
operators
or
the
enterprise
has
to
add
new
pots
into
this
kind
of
network.
M
So
each
part
will
have
the
similar
overlay
technology
in
the
similar
structures.
So
the
only
thing
they
have
to
care
about
is
what
is
for
this
and
also
these
ports?
How
this
part
can
be
connection
to
other
port
in
the
network.
So,
with
this
concept,
we
define
a
fabric
to
party
for,
on
top
of
the
existing
physical
infrastructures,
to
let
emanate
administrators
to
care
about
the
network,
link,
fabrics
and
the
connection
between
these
fabrics.
M
So
the
detail
challenger
or
the
requirements
of
this
topology
staff
can
be
found
on
the
another
draft
which
is
in
SD
energy.
It's
from
operator
requirements
next,
so
what
we
want
to
do
here
is
we
want
to
ease
the
day
center
network
management
while
providing
capacities
capability
and
the
technology
extensibility,
which
means
we
win
the
day,
Center
skills.
They
only
have
to
add
a
new
fabrics
into
this
whole
network
and
only
cares
about
what
this
specific
drag
fabric.
I
used
the
technology,
also
the
fabrics
connected
to
existing
fabrics,
so
the
second
wise
to
build.
M
The
second
ability
is
to
say
to
build
a
objective
fabric
topology
for
the
day,
Center
overlay,
which
maps
to
phila
coat
apologies.
So
this
is
a
common
fabric
topology
with
common
attributes
for
this
Center
networks
or
where
we
have
imports.
So
the
last
one
is
to
is
finally
to
ease
the
network
configurations
to
users.
Next,
it's
thank
you.
M
So
this
is
how
we
use
this
topology
model,
so
we
can
use
it
by
controller
to
configure
the
spine
and
leaves
the
physical
notes
in
the
networks
to
let
the
physical
notes
choose
to
know
what
kind
of
role
it
plays
in
the
whole
network,
and
also
it
can
be
used
by
a
networking
manager
system
to
Terra
controller.
How
this
whole
network
looks
like
so
next.
M
Thank
you.
So
this
is
the
relation
to
existing
model.
Seeing
eye
two
is,
as
you
may
see,
a
fabric
apologies
eyes
and
kind
of
new
things
based
on
the
network.
Topology
bottle
next,
so
also
potential
models
is,
since
we
have
the
different
day
centres,
fairy
types:
maybe
we
have
trio
fabric
and
the
excellent
fabric
or
future
GPU
fabric.
The
party
in
the
next
14
steps
next.
M
So
this
is
how
fabric
paster
the
center
topology
management
look
like.
So
while
it
does
is
the
fabric,
storage
models
collect
a
set
of
physical
nodes
into
the
fabric
and
the
fabric
will
care
about
its
connection
to
other
fabrics,
and
it
manages
its
internal
fabric
connection
and
also
care
about
the
connection
to
other
fabrics,
so
it
were
leaving
the
administrators
with
details
of
the
physical
layer
stuff.
M
C
One
thing
that
we
have
stopped
our
models
of
you
stopped
it
to
the
basic
l2
l3
topology
and
you
notice
we
sort
of
stopped
our
service
topology
work,
because
we
had
lots
of
questions
from
Michael.
Some
of
the
presentation
that
we're
going
on
here
is
to
look
and
where
that
expansion
should
be
for
topologies
either
in
service
model
forward.
So
this
is
not
directly
in
our
charter,
but
could
be
as
we're
sort
of
getting
to
the
end
of
the
basic
charter
model,
rib,
filter,
rib
and
topology.
C
I
C
I
C
The
process:
that's
a
process,
question
on
the
topology
model,
so
you
can
have
a
comfortable
seat.
Thank
you
so
much
so
the
process,
a
good
question.
What
is
the
process
model
on
the
topologies?
You
had
a
few
things
for
the
layer,
three
topology,
which
has
been
implemented
in
the
base
topology,
which
has
been
implemented.
You
need
to
correct
those
drafts
and
then
send
a
note
to
your
working
group
chair,
saying,
I'm
ready
for
my
working
group.
Last
call
chairs.
Excuse
me
so.
I
I
C
I
C
I
Muffin
would
be
I
think
we
have
package
and
we
could
do
that
separately,
because
I
feel
also
the
general
topology
is
a
foundation
or
busy
the
base
model
for
some
of
the
other
things
in
there,
whereas
the
l3
is
kind
of
like
in
parallel
with
the
other.
So
I
think
so.
I
feel
it's
probably
important
to
get
the
pacing
food.
We
should
not
have
the
layer.
3
progress
holds
the
base
model
up.
Okay,.
K
N
One
interesting
suggestion
that
loom
8
and
RT
g
WG
that
the
routing
architecture,
design
teams
considering
is
suggesting
that
for
models
that
have
the
applied
and
intended
that
you
could
use
the
intended,
isn't
like
that.
Basically,
you
could
treat
the
extra
tree
as
an
augmentation
so
that
you
can
sort
of
have
your
cake
and
eat
it
too.
They're
still
talking
about
that,
but
it
might
be
interesting,
was
actually
going
to
request
is,
as
we
develop
knowledge
of
implementations,
particularly
for
the
models.
It
would
be
really
nice
to
put
that
up
on
the
wiki.
N
One
of
the
tricks
here
is
making
sure
all
the
models
are
going
to
interoperate
and
connect
up
properly
and
so
getting
some
sense
of
the
implementation
state
and
how
their
what
what's
been
played
with
together
will
be
really
helpful
for
assessing
it,
I'm
very
eager
to
have
the
yang
models
in
mark
ingram
afford.
Thank
you.
Okay,.
C
K
C
So
the
I
I
had
a
lively
discussion
with
Benoit
and
my
his
answer
to
me
when
I
said:
do
you
want
me
to
just
wait
until
you
decide
what
you're
going
to
do
is
not
to
wait,
and
he
would
help
us
if
we
had
to
refactor
things
in
the
subsequent
version.
So
we're
not
gonna
wait.
We're
just
gonna
approve
and
go
on
Joe
Joe.
D
Clark
may
I
make
a
context
switch.
Yes,
so
Andy
commented
on
the
list.
Ne
Biermann
commented
on
the
list
regarding
the
new
text
407
bringing
up
he
didn't
say,
but
bringing
up
the
multi-head
text
in
11
requirement,
11,
where
we
do
not
necessarily
in
fact
it's
a
lot
of
maize
there.
We,
the
the
data
node,
may
store
the
client.
Id
does
not
need
to
store
the
priority.
His
comment
is
well.
D
If
the
priority
can
change
for
a
client,
be
it
via
triple-a
and
we
only
store
the
client
ID,
then
the
priority
could
cause
us
to
reevaluate.
What
the
the
final
state
is.
The
that
client
a
is
ephemeral.
Config
may
dynamically
overwrite
client
bees
he's
suggesting
we
also
require
of
the
net
comp
working
group
that
we
store
priority
in
addition
to
client
ID
I
haven't
fully
digested
it
I'm
just
bringing
it
up
here
unless
a
that
we
probably
may
want
to
revisit
requirement.
11
I'll
text
in.
C
That
having
actually
taken
time
to
write
the
code
for
that
I,
don't
really
think
it
matters,
because
it
really
is
a
pointer
to
a
particular
set
of
client
IDs
and
priority
where,
if
you're,
storing
it,
if
you're
storing,
is
set
of
essentially
a
transaction
session
ID
that
is
created
out
of
your
just
pointing
one
to
the
other.
It's
I
don't
see,
having
actually
taken
the
time
early
on
to
write
that
code,
knowing
we'd
sort
of
need
to
know,
I,
don't
see
where
he's
coming
from,
but
I'm
glad
to
engage
him
on
the
list.
Yes,
okay,.
E
C
N
Sorry,
oh
yeah,
let's
just
as
an
individual,
so
we've
been
around
this
circle
before
and
a
piece
of
the
discussion
was:
if
the
priority
changes
for
a
client,
do
we
go
back
and
apply
that
priority
to
everything
the
client
has
previously
said,
and
my
understanding
of
the
end
of
the
discussion
was
no.
No,
it's
a
change
and
you
take
it
for
new
pieces
coming
forward,
but
you're
not
going
back
and
reapplying.
N
N
C
C
Other
thing
is
in
reality:
what
you're
talking
about
is,
if
you
say
that
you're
going
to
go
back
and
reevaluate
it
the
most
efficient
way,
if
you
do
route
tables,
is
to
consider
the
priority
to
change
a
route
change
that
goes
across
all
the
pieces,
which
you
would
probably
set
up
a
change
list
and
walk
through
it.
Anyway,
it's
really
just
the
standard.
C
N
C
We'll
probably
have
to
confirm
we'll
start
with
what
we
have
and
then
go
on
without
the
final
working
group.
All
but
I
will
look
again
Joe
any
questions.
You
can
think
that
I
mean
I
tried
to
give
you
my
personal
answer,
but
not
the
working
group
chair
answer.
Ok,
ok,
any
other
things
that
we
should
think
about
specifically
on
the
requirements
or
the
topology
working
group.
Last
call
thank
you
for
coming
in
and
putting
the
extra
time
into
this.