►
From YouTube: IETF106-ANIMA-20191119-1710
Description
ANIMA meeting session at IETF106
2019/11/19 1710
https://datatracker.ietf.org/meeting/106/proceedings/
B
C
A
A
B
A
A
Hopefully
we
could
you
know
fish
that
onyx
neatness
Oh,
because
eternally
for
press
key,
we
actually
has
to
finish
that
before
we
can
really
process
the
lots
following
up
work,
and
then
we
have
the
cross
a
guy
about
twitter
twitter.
We
article,
then
that
one
is
I
believe
which
state
impurity
a
working
group
stage
and
we
have
a
constraint
virtual
adopt
last
year
and
all
these
tapes
which
we
could
ship
okay.
E
E
So
in
ITF
105,
basically,
we
updated
the
ACP
document
to
version
20
and
at
that
point
in
time
there
was
the
video
from
the
security
Directorate
outstanding
and
the
the
Jen
art
was
also
not
closed.
So
that
was
an
oversight
by
Alicia,
so
that
was
closed
and
then
I
try
to
work
with
the
remaining
discusses
from
Bankhead
book
and
he
also
taken
over
the
review
of
I
referred
all
her.
The
other
security
AE,
but
I
hadn't
received
any
any
response
after
I
hear
from
him.
E
I'll
get
back
to
that
point
at
the
little
bit
later
and
then
I
try
to
close
all
the
open
encryption
detail,
gaps
and
that's
basically
what's
in
SS
21
I
wanted
to
quickly
go
through
those,
so
basically
in
the
ACP
certificates.
There
were
a
lot
of
updates
me
reading
through
a
lot
of
documents
trying
to
ensure
that
we
have
the
right
requirement
about
RSA
and
EC
BH
support
in
these
certificates
and
ultimately,
the
high-level
gist
of
the
requirements
is
as
little
as
possible,
but
also
that
we
can
leverage
the
new
technology.
E
So
we
must
do
RSA
because
it's
still
more
widely
used
and
the
latest
standards
security
track.
Rfc's
are
referred
to
also
are
asking
for
RSA
as
a
mess.
Ec
th
would
be
better
because
it
achieves.
You
know
with
shorter
key
links,
the
same
security,
but
we
would
reasonably
only
be
able
to
do
it
in
networks
where
the
certificates
are
only
used
within
the
ACP,
so
that
you
know
that
all
the
devices
would
be
able
to
support
it.
E
So
it's
not
widely
enough
spread
if
we
wanted
you
to
use
these
certificates
for
other
authentication
like
applications
running
within
the
ACP.
So
and
that's
basically,
what
the
text
says
in
so
many
words
and
all
these
magical
details
likely
elliptic
curve
sizes
and
all
that
stuff
was
hopefully
correctly
stolen
from
other
RFC's
that
are
at
upcountry
and
the
feedback
from
them.
E
In
verbally
when
I
mention
here
seem
that
this
is
fine
6:7
security
associations,
simply
added
that
we
must
have
a
perfect
forward
security,
and
also
everyone
know
about
the
fact
that
we
made
for
go
actually
encryption
in
the
secure
channel
protocol
is
a
secure
channel
is
defined
to
leverage
underlying
layer,
2
security
Association
like,
for
example,
mexic,
and
then
the
secure
channel
itself
might
only
be
required
for
the
authentication
and
the
derivation
of
the
underlying
layer.
2
encryption
function
so
in
that,
of
course,
would
avoid
us
to
duplicate
encryption
efforts
that
were
already
doing
it.
E
So
so
then
also
TLS
for
brat,
so
that
was
not
specified
in
before
and
then
being
the
expert
on
TLS
suggested
some
specific
profiles
of
which
I
selected
also
the
minimum,
hopefully
equally
a
sufficient
subset
in
support
of
also
AES,
and
then
our
RSA
and
EC
DHA
GCM
wala
counter
mode
also
is
known
to
be
better.
So,
basically
because
we
don't
have
backward
compatibility
needs
for
graphs
with
all
the
new
it's
it's
hopefully
sufficient
to
have
the
very
small
things.
E
E
So
all
that
kind
of
turn
up
when
I
brace
the
question
with
the
is
g
and
the
reason
why
we
don't
have
an
owner
by
the
way
is
that
the
logical
owner
would
be
the
AG
of
the
group
Ignace,
but
he
had
to
recuse
himself
from
the
document,
and
so
the
new
owner
to
be
selected
would
also
have
to
define
the
process.
So
what's
the
current
status,
so
the
security
review
needs
to
be
closed.
Benjamin
said
that
he
pretty
much
likes
all
the
things,
except
for
IPSec
parameters
seem
to
be
missing
one
or
two
pieces.
E
He
is
not
an
expert
on
that,
but
he's
given
me
the
specific
name
of
a
person
I
should
work
with,
for
whatever
IPSec
parameters
may
be
missing,
I
hope
not
much,
and
then
he
wanted
to
actually
discuss
with
the
working
group.
The
RFC
822
address
and
I
told
him
that
I
think
this.
This
would
be
so
important
that
we'll
make
a
slot
for
him,
but
he
doesn't
have
time
right
now,
but
he'll
have
time
tomorrow.
E
So
that's
basically
a
slot
that
we
need
to
discuss
the
ACP
domain
information
element
with
him,
so
the
proposed
new
ad
owner
of
the
document
is
going
to
be
Erik.
Venky
I
was
talking
yesterday
with
him.
He
can
only
finish
his
review
in
January,
but
in
December
to
prepare
for
that,
and
he
would
then
be
submitted
to
the
IHG.
Hopefully
he
could
already
start
getting
two
additional
reviewers
beyond
him
that
we
need
right
now
and
I'll
also
push
out
another
revision
right
now
this
week.
E
Just
to
summarize
the
changes
since
we
entered
the
is
G
in
13,
because
there
is
a
lot
of
textual
change,
but
it's
you
know.
95%
of
that
is
a
lot
more
explanation,
but
in
a
very
few
small
limited
technical
changes,
I
think
for
other
stuff
in
those
were
refinements.
So
really
no
major
technical
change.
E
E
E
F
Thank
you,
so
just
a
quick
reminder
for
people
to
reread
that
draft.
Recently
it
talks
about
a
model
in
which
there
is
a
functional
library
called
by
autonomic
service
agents
that
communicates
by
some
inter
process
communication
magic
with
the
core
functions
of
the
grasp,
implementation
and
underneath
those
core
functions,
there
is
going
to
be
one
or
multiple
demons
it
could,
depending
on
the
implementation
model
and
those
demons,
do
things
like
listening
for
X,
unexpected
unicast
communications
and
listening
for
multi
costs
and
so
on,
and
there
are
going
to
be
some
various
caches.
F
F
One
of
the
reasons
for
that
is,
my
skill
set,
doesn't
include
event,
loop,
programming
or
callbacks.
It
includes
my
skills
that
includes
threading,
which
I
personally
use
a
computer.
Scientists
find
much
more
satisfying
than
event
loops
and
callbacks,
but
hopefully
now
the
document
covers
both
ways
of
implementing
the
asynchronous
operations.
F
We
were
asked
for
more
explanation
of
the
two
nonces
that
appear
in
the
API
when
that
explanation
is
in
the
text.
Basically,
the
aasa'
nonce
is
a
way
of
saying
yes,
I
am
the
same
autonomic
service
agent.
That
caught
called
you
10
minutes
ago,
and
the
session
nonce
is
a
way
of
tracking
a
session
when
there
are
multiple
sessions
going
on
in
parallel,
which
is
fairly
standard,
in
fact
in
in
an
event,
loop
environment,
at
Michael's
request,
we
added
an
age
limit,
parameter
to
the
discover,
primitive
because
in
fact,
he's
absolutely
right.
F
F
This
is
an
informational
document.
It
says
it's
a
conceptual
outline
of
an
API
for
a
grasp.
It's
not
meant
to
be
a
tight
spec.
You
can't
code
directly
from
it
at
least
I
can't-
and
it's
not
at
all
clear
to
me
that
this
stage
in
the
life
of
our
software,
that
it
would
be
even
be
a
good
idea
to
define
anything
like
a
definitive
spec
for
an
API
which
in
any
case,
isn't
something
the
IETF
is
very
good
at.
F
E
F
Believe
so
yeah
I
mean
bingo.
We
got
good
comments
from
Michael
and
from
Guangdong
and
I
think
we
addressed
both
of
them.
That
was
the
intention
yeah.
So
if
the
people
who
thought
they
read
it
and
thought
and
didn't
put
their
hands
up
for
ready
for
Law
School
I
would
like
to
hear
the
reasons
why
email
is
better.
A
E
E
September,
sixth,
when
the
second
Charter
was
approved,
so
I
wanted
to
talk
a
little
bit
about
what
that
means
for
us.
So,
first,
just
a
quick
rundown
over
the
Charter
I,
it's
actually
three
slides
so
I
I.
Think
I
don't
want
to
necessarily
read
the
first
two
slides
because
they're,
mostly
the
explanation
for
people
who
are
kind
of
not
engaged
in
the
working
group.
E
E
A
new
section,
brueski
features,
including
proxies
enrollment
at
a
adaptions
over
various
network
protocols,
variation
of
ultra
formats,
generic
use
of
autonomic
network
and
new
grasp
extensions
options
for
them,
including
bulk
transfer,
an
SSD
interworking,
autonomic
resource
management,
autonomic,
SLA
assurance
autonomic,
multi-tenant
management,
autonomic
network
measurement
and
finally,
integration
with
network
operations
entries,
including
autonomic
discovery
connectivity
to
knock
yung
based
Ani
or
a
SA
management
and
reporting
autonomic
functions
from
notes
to
Knox.
So
that's,
basically
a
really
good
set
of
areas
where
we
can
explore
work.
E
So,
let's
try
to
see
where
we
stand
with
the
work.
So
as
a
reminder
of
where
we
stand
with
at
least
working
group
adopted
work
right
now,
it's
we've
got
two
RFC's.
We've
got
these
three
documents
that
are
waiting
for
the
next
two
documents,
the
ACP
and
brewski,
and
we
have
two
of
these
working
group
documents.
Right
now.
We
just
heard
the
grasp
API
and
there's
also
the
constraint
ultra
document
that
we
already
adopted
because
they
already
fit
into
charter
round
one.
So
we
also
have
milestones
and
I
think
they're
Ignace
there.
E
There
was
something
miserably
bad
happening
in
transferring
before
105
I
put
milestones
in
and
when
I
was
looking
them
up
right
now,
a
lot
of
them
look
like
there
is
a
mixture
between
dates
that
were
meant
for
call
for
adoption
and
the
actual
submission
to
the
iesg,
which
was
always
meant
to
be
about
a
year
after
adoption
for
the
working
group.
So
somehow
would
be
good
if
we
can
sit
down
and
try
to
fix
these
ones,
because
the
red
ones
are
kind
of
seemingly
not
correct.
G
E
G
E
And
then
I
did
put
all
the
milestones
for
adoption
and
then
kind
of
about
a
year
later
for
each
of
them,
from
my
understanding
talking
to
the
authors
for
submission
to
isg.
So
there
is
a
lot
of
missing
and
the
dates
of
these
so
in
any
case
right
I
just
wanted
to.
Let
the
working
group
know
that
this
is
these
milestones
are
I,
think
not
correct
right
now,
so
we'll
kind
of
need
to
fix
them.
E
Okay.
So
now
what
are
the
target
draft
for
working
through
the
adoption?
So
the
ones
that
we
did
mention
in
in
the
discussion
for
the
Charter
are
exactly
the
information
distribution
over
grasp.
That's
going
to
be
presented
here,
the
guidelines
for
developing
autonomic
service
agents
and
the
constraint
adjoined
proxies.
So
basically,
we're
going
to
you
know,
ask
for
their
adoption
as
well,
for
the
joint
proxy
I
haven't
seen
Peter
yet,
and
I
sent
an
email
out
to
him
figure
out,
because
there
was
not
even
a
presentation
scheduled,
but.
A
E
He
is
registered
to
be
here
in
person,
but
he
hasn't
arrived.
That's
what
I
read
from
the
attendance
list
so
we'll
see,
but
otherwise
we'll
just
take
it
to
the
list.
That's
fine,
of
course,
so
that
would
result
with
the
two
ones
that
we're
having
right
now
in
a
first
round
of
follow-up
documents
in
fund
five
drafts
for
the
working
group.
But
of
course
there
is
more
so
here
is
basically
the
documents
that
are
currently
not
expired
and
associated
with
the
animal
working
groups
so
for
the
ones
being
presented
here.
E
Obviously,
you
know
express
your
opinion
about
how
much
you
think,
they're
already
in
state
ask
for
adoption.
If
you
think
that's
appropriate
right
now
and
as
the
working
group
member,
please,
you
know
consider
when
you
know
we
have
a
list
of
more
documents
to
be
adopted,
which
ones
you
think
would
be
highest
priority,
so
that
we
also
make
sure
that
we
work
on
the
things
and
you
provide
the
feedback
to.
That
is
most
important
for
you.
E
There
are
more
expired
documents,
so
for
the
authors
of
those
are
please
refresh
and
then,
if
you,
if
you
want
to
have
them
taken
up
now
with
the
new
charter,
if
you
have
any
I
think
that
all
the
documents
that
we
had
reasonably
discussed
in
the
past
and
that
expired
because
they
were
out
of
charter
I,
think
90%
of
them
would
be
within
the
Charter
I
think
there
are
several
from
the
same
author.
So
the
author
should
pick
what
they
would
like
to
work
on
first,
but
I
think.
E
A
A
E
By
myself,
I
mean
I
think
maybe
to
rephrase
your
question:
is
there
even
a
risk
in
adopting
brewski
enhancements
as
long
as
brewski
isn't
done,
right,
I
think
we
can
make
a
bet
whether
any
change
that
could
still
happen
through
the
ice
to
review
of
brewski
would
have
an
impact
on
this
other
documents.
But
I
would
think
in
many
in
most
cases
of
my
understanding
about
these
follow-on
documents
that
wouldn't
even
be
the
case
I.
H
H
So
that's
the
only
thing
someone
will
come
up
with
a
this.
Doesn't
work
it
since
we
don't
like
this
blah
blah
blah
I
says
we'll.
Just
don't
do
that
right,
no
can't
we'll
cross
and
text
out
or
something
I
don't
know.
That's
the
only
thing
I
can
see
at
this
point
and
I
think
that
after
August
and
September
's
endless
threads
that
we're
done
with
that.
I
So
my
name
is
Archer
I
can
presenting
for
the
audience.
So
we
have
this
document
around
for
quite
a
while,
and
this
document
essentially
describes
the
way
how
grass
can
be
extended
such
that
we
can
do
information,
distribution
or
let's
say
it,
is
some
kind
of
publish/subscribe
service
within
a
and
I.
I
So
what
we
actually
did,
we
defined
two
specific
modules
inside
there,
so
in
in
the
other,
you
would
have
essentially
an
information
distribution,
sub
module,
let's
say
which
has
three
sub
modules
additionally,
and
all
that
is
then
broken
down
to
past
Isis,
who
usage
of
synchronization
messages
across
all
through
extensions
of
trust.
So
this
is
what
is
described
in
the
draft
now,
specifically
in
the
latest
version
to
version
12
that
we
uploaded
recently,
we
have
extended
some
classes
in
the
queue
management,
sub
module,
which
is
probably
not
very
important-
to
discuss
right
now.
I
What's
more
important,
I
guess
is
the
question
of
the
relevance
to
the
rich
heart
ring
so
that
what
Turrell
is
presented
before
you
have
seen
information
distribution
as
one
of
the
key
points
in
the
reach
out
at
aneema,
and
this
document
actually
addresses
this
information
distribution
in
a
specific
way.
So,
while
we
can
discuss
the
quality
of
the
document,
certainly
rewrite
it
improves
the
language
and
all
the
things
the
toriel
things
can
be
done.
I
A
lot
to
this
document,
it's
by
far
not
finished
I
would
say
that
we
need
this
document
to
become
a
working
group
document,
and
this
is
the
major
point.
Essentially
so
we
can.
We
can
refine
many
technical
things.
We
can
even
see
you
know
where
whether
we
are
using
grasp
as
we
should,
whether
there
are
alternatives
to
this,
but
we
have
a
requirement
session
which
identifies
why
we
needed
at
all
how
it
can
be
done.
I
J
I
The
point
is
that
we
have
some
kind
of
understanding
of
Raza,
either
instantaneous
transfer.
But
let's
say
you
already
know
to
whom
you
want
to
send
information.
Okay,
then,
essentially
the
node
can
directly
say
these
are
my
recipient
notes
and
then
essentially
it
can
go.
This
can
be
implemented
with
grass
without
many
changes
today.
Okay,
music,
synchronization
messages,
then
again
you
can
have
a
completely
different
model
where
you
can
say:
okay,
I
have
some
information.
J
I
The
point
is
I
think
the
answer
is
probably
no
okay.
This
document
does
the
following:
we
first
discuss
what
needs
to
be
done
and
why
we
actually
need
the
information
distribution,
as
you
know,
supported
service
from
the
other
and
not
just
on
some
kind
of
random
thing,
because
right
now
it's
undefined
and
we
clearly
have
it
as
a
need.
You
know
just
for
intend
distribution,
for
example.
I
We
always
discussing
this,
but
now
it's
in
the
Charter,
so
we
then
went
on
to
define
also
a
specific
implementation,
but
this
is
probably
a
specific
implementation
which
I
guess
we
can
discuss
later.
But
we
need
some
kind
of
document
like
that.
To
start
this
discussion
and
to
have
people
contributing
agree.
I
So
in
principle,
yes,
but
grasp
has
of
course
obvious
advantage
of
already
being
there
and
somehow
being
natural
is
suitable
for
some
things,
and
we
do
not.
You
know
it's
it's
kind
of
signaling
protocol,
very
generic,
and
we
do
not
mean
to
use
it
for
bulk
transfer
of
data,
but
we
certainly
mean
to
use
it
so
to
say
as
notification
that
oh
there
is
a
new
information
element
available
right
or
you
know
download
it
there.
Something
like
you,
yep.
G
There
is
for
several
years
there
have
been
discussions
coming
from
either
side
on
documents
which
specify
use
cases
applicability
and
things
like
that,
and
while
there
is
no
strict
single
answer
to
that
in
general
such
documents
they
are
not
seen
to
positively
and
not
with
this
I'm,
not
saying
what
you're
doing
is
plain
wrong.
The
question
that
I'm
raising
is
what
is
the
value
of
specifying
implementation.
Details
of
the
API
IDF
certainly
is
not
a
place
to
standardize
implementations
and
for
that,
the
vendor
that
that
wants
to
do
that.
They
don't
need
ATF.
G
They
they
need
a
market
for
that,
and
market
will
decide
whether
that
API
is
applicable
or
not.
Trying
to
specify
the
protocol
mechanics
and
the
functionality
of
that
certainly
is
within
the
scope.
Now
there
the
way,
how
I
see
the
CPI
document
and
extensions
to
that
they
are
going
find
deeper
into
the
implementation
domain
again,
I'm,
not
saying
that
this
is
wrong,
but
I'm
just
saying
that
this
will
raise
questions.
So
what
benefits
you
see
going
this
path?
Is
this
really
needed?
G
I
I
I
So
we
have
grasped
there,
which
is
required
to
set
out
the
Ani
and
it's
working
already
right
and
if
we
want
to
have
some
kind
of
pub/sub
service
or
this
information
distribution
in
general,
then
we
need
some
additional
bits
and
flags
within
grasp
which
are
absolutely
not
api
relevant
but
which
are
relevant
to
the
protocol
on
the
wire.
That
is
what
is
being
specified
then
again
again
in
this
document.
We
do
firstly,
analysis
of
requirements.
We
say
yes,
that's
why
we
need
it
and
then
we
specify
a
solution.
As
we
just
said,
we
could
discuss.
I
Probably
the
you
know,
details
of
the
solution,
but
certainly
it's
about
the
protocol
on
the
wire,
because
we
need
to
enable
an
additional
functionality,
completely
I
would
say
orthogonal
to
what
is
so
far
in
there.
It's
not
only
about
opening
communication
channels
or
secure
communication
channels
right,
but
it's
about
storing
some
data
within
the
autonomous
network
infrastructure
for
some
short
while
or
for
longer,
while
and
so
on.
It's
about
the
pops-up
integration
inside
of
it.
G
That
part
I
so
I
think
we
both
understand
that.
But
if,
if
we
read
the
document
without
this
prior
understanding,
this
question
naturally
arises
and
if
you
look
from
a
perspective
of
ayesha
review,
there
are
those
who
are
not
following
what
is
happening
here.
Certainly
will
raise
that
question.
So
maybe
this
needs
to
be
explained
rather
detailed
in
in
the
scope
of
the
document,
what
it
is
trying
to
define
and
what
it
doesn't
try
to
define.
Okay.
I
Understood,
in
any
case,
the
document
for
me
from
my
perspective,
the
co-author
is
not
yet
ready
for
any
kind
of
a
house
calls,
so
we
absolutely
need
to
revise
it
several
times
several
rounds,
because
this
is
obviously
probably.
This
is
true.
If
this
is
the
impression
that
the
reader
is
getting,
then
we
need
to
get
rid
of
this.
Indeed,
yeah.
A
They
stand
on
along
API
document
is
informational
document
which
provides
some,
you
know
extra
information
and
how
may
may
you
know,
implement
the
grasper
and
how
that
may
help
the
you
know
Apple
a
year
asa
to
use
it
so
that's
useful,
but
for
this
document
I'm
with
you
I
I
think
this
document
shouldn't
depends
on
the
you
know,
grasp
API
document
or
all
the
API
I.
Just
look
at
through
your
document.
There's
a
not
part
machine.
G
I
E
If
you
know
the
API
was
specified
in
something
like
a
rest
specification,
as
opposed
to
the
more
informal
approach
that
we
have
chosen
in
the
document
and
then
I
think
it
would
become
very
clear
that,
just
because
the
two
components,
the
provider
and
the
consumer
of
the
API
are
sitting
on
the
same
system.
It's
still
an
interoperability
issue
that
we
want
to
solve
right.
So
that's
my
answer.
The
the
second
is
for
for
your
document.
E
I
think
that
I've
only
superficially
read
it
so
I'll
need
to
spend
more
cycles
on
that,
but
it
seems
to
me
that
it
also
only
gives
very
coarse
guidelines
as
there
are
some
extensions
right.
So
that's
basically
a
real
specification
part,
but
there
is
not
even
a
single
let's
say,
example:
interoperable
solution.
You
could
build
out
of
that
right,
not.
E
Not
notwithstanding
the
fact
that,
obviously,
the
idea
of
this
document
is
to
allow
multiple
different,
independent,
you
know
information
distribution
solutions
to
be
built.
It
might
be
helpful
to
have,
let's
say
the
minimum
single
reference,
one
included
in
the
document
to
basically,
you
know
make
it
clear
that
we're
really
talking
about
integration
at
two
levels:
generic
things
to
be
applied
to
multiple
solution,
and
then
one
example.
Maybe
that's
that's
a
solution.
Yes,.
I
So
to
the
second
comment:
I
guess
we
wanted
to
do
something
like
that.
That's
why
we
adopted
grasp,
because
by
by
essentially
saying
grasp,
can
do
this
in
extending
Ross.
We
are
going
for
something
quite
standard
as
at
least
as
some
kind
of
minimum.
You
know
denominator,
which
is
common,
then
to
an
Ani.
I
Then
there
could
be
other,
like
maybe
out-of-band,
ways
for
information
distribution
as
well,
where
grasp
could
be
just
setting
up
the
channels
okay,
so
this
is
also
possible,
but
the
indeed
I,
understand
and
I
fully
agree
that
this
document
is
not
ready
for
publication.
We
need
more
contributions
to
this.
That's
exactly
the
point
so
fight.
Somehow
you
know
a
personal
draft
which
is
more
or
less
evolving.
With
the
authors,
we
never
received
any
kind
of
review
or
comments
from
the
community.
Okay,
so
please
do
not
be
surprised.
I
E
So
maybe
maybe
one
suggestion
for
the
API
document
in
and
we
can
take
it
offline,
it's
just
brainstorming
right
I
mean
we
have
some
successful
work
about
api's
and
taps
right,
and
they
also
don't
have
you
know
a
concrete
API
but
they're
all
abstract,
api's
and
I.
Think
that
was
also
the
goal
of
what
Bryan's
document
is
trying
to
achieve.
So
as
not
to
you
know,
forego
different
intentions
like
rest
being
a
possible
one,
but
shouldn't
be
constrained
to
that.
F
Deployable
autonomic
network
needs
more
than
an
ACP
and
grasp
it
needs
to
achieve
management
goals
that
the
network
operation
center
cannot
achieve
manually.
Otherwise,
why
are
we
here
my
opinion,
that
requires
a
library
of
autonomic
service
agents
and
if
we're
using
the
grasp
model
and
our
library
of
grasp
objective
definitions
and
it
requires
tools
to
deploy
and
oversee
the
ASA's,
we
have
some
documentation.
F
It's
sort
of
addressed
some
of
these
questions,
including
the
one
I'm
Thea
reticle
II
talking
about
I,
won't
read
out
the
list,
but
we
got
no
clear
working
group
goals
in
that
area.
In
my
opinion,
and
then
we
have
the
question
of
what
ecosystem
issues
can
the
IETF
tackle
missing
standards,
operational
guidance,
implementation
guidance
and
what
he?
What
issues
are
out
of
scope
for
the
IDF
and
who
should
be
encouraged
to
deal
with
them?
F
If
we
just
stop,
you
know
at
the
on
the
word
protocol
we
in
the
sense
of
the
industry,
then
nothing
will
happen.
So
someone
has
to
make
this
ecosystem
stuff
happen,
but
there's
a
limit
to
what
we
can
do
in
the
IETF,
and
that
means
in
practice
is
a
limit
to
what
the
isg
will
will
will
let,
through
the
ballot,
there's
other
IETF
work.
F
We
might
want
to
consider
that
conference
in
an
autonomic
Network
net
confer
over
ACP
that
conf
over
grasp
I
just
added
this
line
this
week,
use
of
muds
for
authorization
in
an
autonomic
network.
So
the
concrete
examples
of
things
probably
need
to
play
nicely
with
an
autonomic
network
which
are
going
on
to
to
efforts
that
are
going
on
in
the
ops
area
working
group.
H
Michael
Michael
Richardson,
so
I
had
a
question.
I
guess
you're
working
along
Apple
days
ago,
and
someone
wants
to
know
about
the
animo
stuff.
What's
that
all
about
right
and
you
know
I
realized
I-
didn't
have
a
really
good
elevator
pitch
at
the
moment,
but
the
question
that
they
asked
was:
is
this
going
to
permit
permissionless
ipv6
network
extensions
in
in
the
same
way
that
we
typically
an
ugly
Lee?
You
know
plug
not
for
forced
into
v4
networks
and
just
extend
them
without
permission
right
because
it's
gonna?
H
H
Yes,
exactly
so
the
the
part
of
the
and
whether
we
succeeded
or
not
is
a
good
question,
but
maybe
the
permission
lessness
of
the
of
that
not
for
for
scenario
that
it
was
completely
permissionless
and
also
unmanageable,
was
a
bad
thing.
Okay,
but
maybe
we
need
to
find
some
intermediate
point
and
so
I
go
back
and
I
was
sitting
there.
Looking
your
list
of
slides
and
so
what
happened
with
our
address
assignment
AAS
a
spec.
It's.
H
We
need
to
let
our
queue
empty,
also
that
our
mine,
you
know
our
collective
minds
kind
of
empty
with
some
of
the
issues,
and
we
also
need
to
let
some
of
the
running
code
catch
up
to
the
whole
scenario,
and
so
I
would
ask
our
area
directors
and
ASG
to
please
not
take
our
lack
of
activity
is
a
sign
that
we
have
no
work
to
do,
but
rather
that
we're
too
busy
working
to
bother
talking
about
it
for
a
while,
fair
enough,
that's
my
opinion.
Okay,.
H
Yes,
I
think
the
topic
matters
I
also
want
a
point
that
I
think
that
that
the
many
of
the
participants
in
this
working
group
have
have
gone
through
forcible
job
changes
or
employer
train
jizz,
with
the
result
that
there's
at
least
a
couple
major
vendors
that
are
essentially
not
in
this
room
anymore,
mm-hmm.
Okay,
so
that's
a
pretty
significant
thing
and
the
argument
for
why
we
need
standardization
if
we
only
don't
have
any
as
many
large
vendors
in
the
room
is
maybe
a
good
one,
but
I
don't
think
it's
I
mean
I.
E
You
know,
services
in
existing
network,
so
really
the
pragmatic
stuff
I
think
that
allows
you
know
people
with
existing
networks
to
see
the
biggest
value
as
opposed
to
the
things
that
I
find
cool.
Like
all
these,
you
know,
how
do
I
structure
Asin
these
things,
which
are
more
researchy,
which
I
love
but
I,
don't
think
that
they
necessarily
give
us
the
you
know
shortest
term
extraction.
You
know
with
the
industry,
which,
unfortunately,
is
very
backward
facing.
Well,
that's
just
my
personal
opinion.
That's.
E
L
Diaphragm
Vict,
because
you
shall
mention
that
the
animal
is
a
guillotine,
so
I've
got
two
questions.
One
continues
because
animal
is
lost,
I
killed
him
then
I
think
the
implementation
and
obligation
scenarios
are
very
important.
Then,
can
you
give
some
examples
for
the
application
scenarios
and
implementations?
Another
quality
is
because
animal
is
legacy
demon
and
if
they
want
to
be
lazy
shield
between
the
animal
and
at
a
I/o
anniversary
learning,
then
my
question
that
my
talk,
religion.
F
As
far
as
I'm
concerned,
that's
still
a
research
topic
which
the
NMR
G
is
looking
at
I,
don't
know
how
we'd
integrate
it
I
feel
that
we
should
do
right,
but
I
don't
know
yet
how
we
would
do
it.
Yeah
I
agree
with
you
that
it
should
be,
should
be
there.
The
idea
there
would
clearly
be
that
you
would
have
an
autonomic
service
agent
that
would
be
connected
to
the
AI
system
and
could
talk
to
other
autonomic
service
agents
that
were
not
connected
to
the
AI
system.
F
A
That,
when
we
did,
our
reach
other
way
actually
leaves
the
AI
out
of
scope
intentionally
and
actually,
as
brown
also
explained,
80s
possible.
You
know
we
here's
the
machine,
learning
or
AI
mechanism
with
sit
in
the
some
certain
autonomic
service
agent,
but
that's
nothing
to
do
with
the
protocol
or
the
signaling.
We
are
standardized
here,
so
basically
that
just
means
some
logic
for
favoured
by
the
machine,
learning
or
AI
use
the
anima
infrastructure.
A
J
At
the
point,
when
you
say
requires
a
library
of
a
size,
I
will
say:
I
agree
with
that.
I
think
we're
on
e
ma
he's
right
now
we
have
developed
some
protocols
framework
different
things
that
are
useful.
Now
we
need
to
have
a
bit
more
like
the
guy
before,
but
examples
use
cases
application
areas.
So
I
think
this
is
important
to
understand
what
what
could
be
then
the
require
the
summarization
requirement
or
the
sanitation
needs
to
address
different
areas.
J
So
maybe
we
need
some
kind
of
use
case
document,
so
a
phase
where
we
try
to
see
what
are
the
application
of
what
could
be
the
types
of
Aiza
I'll
just
finish
on.
That
is
also
because,
but
on
that
thing
that
we
need
to
have
use
cases.
For
me,
this
is
where
we
reach
a
bit
the
limit
of
what
I
ATF
is
used
to
do
with
respect
to
your
question
and
in
ecosystem,
because
then
aisa
for
the
security
space
Oryza
in
IOT
or
is
it
and
then
this
is
not
anymore,
a
NEMA
or
even
anymore?
J
It's
a
bit
like
cross
cross
area
or
even
application
space
that
can
be
copied
outside
IETF.
So
for
me
this
is.
We
need
to
investigate
that.
This
could
be
channeled
in
the
ayah
in
the
working
group
through
a
set
of
documents
or
discussion
points,
but
I
am
Not
sure
the
IETF
I
mean
to
develop
an
ecosystem
understood
the
IHF
is
the
right
place
for
that
and
I'm
saying
it's
not
feasible,
but
I
don't
have
good
example
is
in
mind.
J
E
We
do
yes
I,
probably
for
this
note
should
be
sitting
up
front,
but
I
think
just
a
general
note
to
you
know
all
the
co-authors
of
the
current
drafts
or
drafts
to
be
looking
into
this
problem.
Right
I
mean
they're
there,
a
lot
of
other
working
groups
where
there
could
be.
You
know,
help
and
interest
in
in
what
we
specifically
are
doing
so
when
I
started.
The
DNS
stuff,
of
course,
also
went
to
the
DNS
working
group,
as
I
said.
Maybe
you
know
for
API
things.
E
Something
taps
could
be
helpful
right,
I
think
there
is
nothing
stopping
us
from
proposing
to
talk
about
the
subjects
that
were
interested
in
in
what
we
think
is
the
best
working
group
to
you
know,
create
more
feedback
or
also
you
know
in
these
other
examples
that
were
showing
that
that
may
have
the
use
cases
and
create
you
know
more
advancement
through
that.
So
that's
definitely
also
some
additional
work
for
authors,
not
simply
thinking
that
we
can
operate
in
a
silo,
but
you
know
create
contacts
elsewhere
in
the
idea.
A.
J
Remark
more
it's
a
about
what
aces
are
or
could
be,
I
usually
take
the
comparison
with
a
virtual
network
function
or
network
function.
I
could
see
a
parallel
between
an
ASA
and
network
function,
but
typically
network
function.
This
is
not
really
IETF,
which
is
developing
network
functions
you
go
to.
There
are
many
other
places
where
people
are
building
or
proposing
those
functions
and
also
the
require
the
standardization
needs
on
these
network
functions.
It's
a
I
mean
needs
to
be
clearly
understood
and
defined,
and
this
is
part
of
I
mean
one
point.
E
I
think
that's
a
very
interesting
comparison,
because
the
reason
why
things
like
vnfs
are
so
managed
to
to
the
largest
X
tends
to
be.
You
know
something
the
ITF
can
ignore
is
because
it
didn't
really
change.
You
know
the
api's
and
the
protocols
use,
but
it
just
changed
the
shape
of
the
individual
notes
right
from
hardware
to
software.
G
Big-Nose
McDonough's
now
main
thing
is
I'm,
really
happy
that
this
type
of
a
discussion
is
happening,
and
this
is
clearly
needed
now.
Let
me
expand
a
little
bit
on
that
with,
with
a
few
say,
rules
for
assumptions.
First,
this
is
ITF
working
group,
not
IRT
F
working
group
and
therefore
the
deliverables
should
be
say,
tangible
engineering
components
now
IETF
is
good
at
working
on
components
now
and
that
that
is
what
the
individual
working
groups
produce.
G
Idf
is
not
that
good
and
working
on
combining
those
components
together
and
then
building
something
like
a
system.
That's
one
second
thing,
my
impression
from
from
from
especially
reading
the
slide
that
is
in
front
is
that
it
is
at
this
point
of
time
it's
a
question
more
about
the
requirements
and
understanding
the
problem
space
and
where
that
problem
lies,
and
only
then
trying
to
address
the
components
which
can
be
addressed
here
in
some
other
working
group.
G
G
G
G
There
were
similar
discussions
in
here
this
meeting
to
about
the
IOT
IOT
systems
or
work
more
on
a
more
broader
scope
than
just
an
individual
product.
The
protocols
and
components
in
IOT
domain.
I
think
this
has
a
lot
of
binding
together,
and
maybe
that
could
be
one
place
where
both
the
anima
and
I,
which
he
related
topics,
are
being
discussed
and
and
and
of
sliced
for
the
further
work.
G
But
the
starting
point,
at
least
in
my
view,
appears
that
we
need
to
reach
out
to
the
potential
user
base
of
of
these
deliverables
potential
deliverables
to
understand
whether
what
we
are
trying
to
do
is
a
problem
for
them
and
whether
we
understand
what
is
a
problem
for
them
now.
This
is
definitely
not
ITF
community.
Now
we
have
severe
problems
of
operator
participation
in
90f
and
that
will
not
get
better
anytime
soon.
Therefore,
this
is
an
outreach
question.
G
The
question
to
what
what
organization
of
what
venue
do
we
need
to
outreach
and
again
I
think
this
is
one
of
the
topics
that
needs
to
be
addressed
first
before
trying
to
do
something
on
a
protocol
work.
Yes,
we
are
engineers
and
dealing
with
protocols,
it's
fun
and
easy,
but
the
fundamental
question
is:
what
do
we
need
to
do
from
a
problem
perspective.
F
E
H
Need
a
tangible
demo,
okay
and
and
may
say
that,
sends
you
the
ietf,
but
the
point
is
that
that's
the
next
step
for
the
work
and
we
can't
come
back
to
the
rest
of
the
stuff
until
we
get
those
guys
excited,
and
that
requires
work
that
that
is
of
a
different
kind
right.
So
that's
all!
So
that's
why
I'm
saying
please
don't
shut
us
down
if
we
doesn't
look
like
we're
actually
doing
something
at
the
IETF,
because
it's
just
not
happening
here.
G
H
Need
to
meet,
but
that
doesn't
mean
we're
not
gonna
meet
we're
inactive
is
what
I'm
trying
to
say.
Okay,
we
might
not
need
face
time
as
much
for
a
little
while,
but
but
we
have
a
lot
of
documents
that
are
it
that
are
still
processing,
and
we
probably
might
need
face
time
for
that.
But
we
might
not
be
adding
new
documents
because
we
just
it's
it's
just
not
it's
just
not
ready.
G
Yet
right
you
are
the
working
group
you
have
reach
at
it.
You
have
your
milestones
now.
It
is
for
you
to
work
on
those
milestones.
Well,
if,
if
you
are
looking
at
an
ad
who
will
guide
you
for
all
of
that,
I
think
I
can
help,
but
this
is
for
you
to
do
that
once
we
are
six
years
old
with
you,
the
milestones
dates,
then
probably
the
question
of
shutting
this
might
be
raised,
but
there
are
no
such
intentions
at
this
point
of
time.
E
So
this
was
a
great
philosophical
discussion.
We
need
to
come
to
the
close
of
this
I
wanted
to
remind
that.
The
starting
point
of
all
of
this
was
the
draft
that
is
talking
about
the
guidelines
for
ASAS
and
I.
Think
as
much
as
we
understand
that
this
is
at
the
fringes
of
you
know
the
actual
ability
to
create
interoperating
running
code,
but
really
at
the
starting
point
of
that.
E
J
Okay,
thank
you,
so
I
would
like
to
present
work
that
is
being
done
in
a
another
group
in
Etsy,
some
not
representing
this
group
I'm
participating
in
this
HC
group,
but
it's
real
individual
view.
So
don't
take
this
as
an
official
communication,
but
I
think
it's
related
to
the
discussion
as
initiated
by
Brian
on
this.
A
cycle
system
and
I
mean
how
to
approach
this,
and
maybe
the
fact
that
other
groups
are
doing
something
could
could
help
us
in
this
process.
So
just
very
quickly.
J
I
have
a
lot
of
slide,
but
I
will
not
present
all
of
them.
This
is
in
the
slides
for
your
reference.
If
you
want
to
look
a
bit
more
but
to
give
you
some
context,
so
it's
either
SM.
It's
an
industry.
Standardization
group
in
at
C
stands
for
zero
touch
network
and
service
management,
so
you
can
see
with
the
relationship
with
anima.
It
was
created
roughly
two
years
ago.
J
The
idea
is
really
to
have
something
workable
after
links
if
you
want
to
have
more
documentation,
so
this
may
look
a
bit
complex.
But
again
the
idea
is
not
to
go
into
the
data
market
texture,
but
just
to
explain
a
few
aspect
of
that.
So
the
group
has
been
developing
a
framework
architecture,
one
of
the
some
of
the
key
elements.
It's
a
service
based
architecture.
J
We
are
more
used
to
see
a
functional
based
architecture,
so
there
are
some
good
advantages
to
that,
and
especially
if
we
think
about
a
Z
as
agents
or
services,
we
could
see
a
good
fit
with
some
potential
reuse
of
these
aces
in
this
architecture.
So
you
have
management
services.
This
is
the
atomic
entity
by
providing
a
management
service
that
is
offered
service
based
approach,
and
the
management
function
is
a
implementation
that
is
providing
the
user
role
to
consume
or
produce
a
service.
So
this
is
quite
also
software.
We
hunted
approach.
J
Integration
fabric
is,
in
fact,
a
bus
to
connect
all
these
services
on
the
management
functions
together
and
so
to
provide.
Also
some
utility
services
to
discover
to
register
to
connect
different
forms
of
communication
patterns
can
also
be
provided
by
the
integration
fabric.
So
the
idea
is
really
to
provide
a
lot
of
Independence
between
the
components
and
not
to
have
each
of
the
companies
to
win
and
then
to
implement
different
communication
interfaces
or
discover
interfaces,
but
to
rely
on
the
shared
components
cross
domain
that
has
services.
This
is
to
be
able
to
collect
data.
J
Of
course,
if
you
want
to
have
automation
and
close
the
loops,
you
need
to
know
what's
happening
so
to
collect
data,
collect
data
from
multiple
sources,
but
also
share
those
data
between
the
different
consumer
of
those
data.
This
relates
well
to
the
work
that
I
was
mentioning,
and
so
this
to
make
this
available
through
this
bus
website,
typically
or
whatever
form
you
would
like
to
support
management
domain.
This
is
since,
as
LSM
aims
to
be
applicable,
end
to
end
I
mean
typically
different
network
segment,
so
administrative
network.
So
there
is
this
notion
of
domain.
J
This
is
where
arbitrarily
whatever
deployment,
you
will
group
your
services
and
functions
together.
So
if
you
say,
I
have
a
mobile
run
a
type
of
domain
and
it
connects
with
the
core
domain
and
transport
and
cetera
so,
but
each
of
the
functions
will
be
handle
at
the
scale
of
the
domain,
and
then
you
have
this
end-to-end
service
management
domain,
which
is
to
provide
the
entrant
service
view
where
you
will
point
to
the
different
domains
in
order
to
realized
or
your
service
deployments
and
service
management.
J
This
is
just
I
will
not
go
through
these
three
slides,
highlighting
a
bit
more
the
different
components
of
the
management
domain,
the
entering
service
management
domain,
some
typical
services
that
have
been
also
specified
in
the
architecture,
so
you
can
see
for
the
different
domains:
data
collection,
analytics,
intelligence,
orchestration
control,
integration,
fabric
services
also
for
registration,
discovery,
data
services,
type
of
of
services,
storage,
persistent
services,
so
this
is
typical
type
of
services.
One
link
I
would
like
to
make
now.
J
This
can
be
partially
seen
as
a
component
of
aces,
so
we
can
also
borrow
from
that,
if
needed,
infant
aggression,
fabric
details,
so
now
a
bit
relationship
to
the
Ada
and
closed
groups
aspects.
So
there
have
been
so
this
notion
when,
if
this
is
an
automation
framework
to
rely
not
mandatory
but
at
least
to
use
a
closed
loop
operation,
we
are
not
binding
to
any
form
of
closed
loop
model.
This
is
just
to
illustrate
with
that
type
of
hope.
J
It's
available
publicly
on
the
on
this
link.
What
more
recently
has
happen?
Also
in
June,
the
the
group
has
adopted
three
documents
on
closed
loop
automation,
so
one
document
is
called
enablers.
This
is
typically,
what
are
the
generic
components
that
compose
a
a
closed
loop
and
how
these
components
needs
to
interact
together
in
order
to
be
I,
mean
very
flexible
and
fulfill
different
types
of
deployment
use
cases.
So
this
is
where
I
see
the
most
relationship
with
Asia
in
anima
the
second
document
on
solution.
J
This
is
to
take
the
generic
enablers
on
specific
use
cases
and
then
to
try
to
say
if
I
need
to
deploy
a
network
slice
and
to
enlarge
cycle
of
network
slice
over
different
domains.
What
are
the
typical
protocol
that
exist
today
to
fulfill
this
dis,
this
use
case
and
to
reuse
the
enabler
specified
and
see
if
there
are
things
existing
in
Fiji
PP
in
HC,
in
ITF
in
BBF,
to
realize
these
solutions?
J
If
there
are
some
gaps,
this
will
be
pointed
out,
could
be
developed
in
the
less
mo
could
be
sent
back
to
the
different
SEO
s2
to
make
the
necessary
changes,
and
the
last
documents
is
so.
The
first
two
documents
are
specification,
so
equivalent
of
external
tracked
documents.
The
last
one
is
a
informationally
to
report.
J
J
What's
important
here,
these
are
great,
advise
I
mean
that's.
Usually
we
have
this
also
in
animal
view
of
asa
or
close
to
being
a
kind
of
integrated
components.
What
we
are
pushing
in
the
rest
time
is
also
to
say
now.
This
needs
to
be
a
bit
more
disaggregated.
They
constructed
so
that
you
can
have
the
different
components
and
how
to
compose
this
component
will
be
a
key,
a
key
aspect
of
these
enablers,
enabling
a
synchronous
operation
between
the
components
and
also
enabling
multiple
input
and
outputs
between
the
closed
loop
stages
on
function.
J
This
is
not
the
kind
of
single
path
in
the
closed
loop.
You
can
really
see
the
service
based
approach
that,
if
you
have
a
data
collection
service
that
can
be
used
by
multiple
analysis,
functions
for
multiple
closed
loops.
So
this
is
to
address
the
the
key
challenges
of
interoperability
and
composition
of
closed
loop
in
a
region
rich,
even
though
environment
there
isn't
true
so
progressing
on
the
list
of
scenarios
exchange
between
the
closed
loop
stages
for
different
use,
case,
provisioning
of
new
resources
and
sensation
of
backup
resources,
dynamic,
monitoring,
cetera.
J
J
The
output
interface
convey
the
other
way
cover
governance
information,
such
as
exposure
of
capabilities
constraints
and
requirements,
different
actions
that
were
taken
or
the
status
reports
again
also
providing
the
knowledge
that
has
been
discovered
or
produced
and
reactions.
This
closed-loop
manager
closed-loop
agent,
is
a
logical
function
responsible
for
managing
the
closed-loop
external
interaction.
So
this
is
how
to
interface
with
something
that
is
not
the
closed-loop,
but
we
have
also,
which
is
more,
the
the
focus
of
the
activity,
this
white
box
closed-loop
model.
J
So
this
is
still
represented
as
a
single
component,
but
in
fact
we
you
can
remove
this.
This
Square,
this
dotted
square
to
imagine
that
the
different
stages
are
really
independent
functions
and
we
need
to
connect
them
to
compose
them.
So
this
is
why
we
have,
in
that
case
the
same
interfaces
as
the
black
box
was
do,
but
we
want
also
to
support
way
to
compose
the
different
stages,
the
steps
of
the
closed-loop
and
also
to
have
a
capability
description
and
pairwise
characteristic,
information
between
acquisition,
analysis
decision
and
implementation.
J
Now,
making
a
bit
the
link
between
this
work
of
closed
loop
in
zsm
and
animal
on
the
Aces.
Can
you
come
to
an
end
after
the
last
Latin?
So
roughly
my
understanding
is
that
the
closed
loops
that
are
being
investigated
in
the
Risa
equivalent
of
the
autonomic
service
agents
in
in
in
anima,
the
resin
will
develop
specification
for
closed
loop
automation,
so
how
these
different
stages
can
interact
using
different
forms
of
mechanism
and
what
needs
to
be
specified
for
that.
J
So
on
your
neighbors
generic
components
of
the
closed-loop
interaction
patterns
and
composition
means
for
the
solutions
so
applying
on
different
use
case
those
enablers
and
we
using
standard
based
components
or
protocols
and
for
the
alvin's
topic.
This
is
more
to
investigate
next
generation
close
to
design
and
operations
and
in
identify
potential
area
for
future
sterilization.
F
F
The
theory
is
that
a
simpler
layer-2
solution
to
the
ACP
could
be
used
on
a
very
small
enterprise
or
in
a
large
enterprise
that
actually
wants
to
chop
its
network
up
anyway
and
then,
therefore,
would
be
willing
to
use
over
to
ACP
in
each
segment
of
the
network.
The
other
thing
which
is
different
from
the
real
ACP
is
that,
at
least
for
a
small
network,
some
degree
of
pre
configuration
of
the
ACP
nodes
would
be
acceptable
because
of
that,
that's
something
that
doesn't
scale
to
a
large
network,
but
would
be
okay
in
a
smaller
network.
F
F
All
of
this
was
in
the
document
before
I
just
wanted
to
mention
the
updates.
Since
last
time
we
added
a
discussion
of
Mexico,
which
is
got
an
a
I
Triple
E
magic
number.
It's
the
good
news
is
that
it
supports
multicast,
including
group
authentication.
The
point
of
our
group
authentication
is
some
trust.
One
trust
also.
There
know
that
there
is
a
single
trust
model
that
covers
all
the
multi
casting
nodes.
F
A
K
Mark
Smith
some
for
the
Indian
society
for
this
ITF
I
work
in
the
v6
ops
and
there
are
six
main
groups
and
one
of
the
thoughts
I've
had
about
RV
v6
is
in
addition
to
solving
lots
of
addresses
problems
potentially
in
the
future.
People
will
actually
build
much
bigger
VLANs
because
there's
there's
it's
been
traditional,
do
slash
24s,
which
implies
a
limit
of
255
nodes.
Obviously,
v6
with
such
64's
can
support
much
bigger
than
that,
so
I
think
the
constraint
on
size
of
VLANs
will
really
just
be
multicast
traffic.
K
M
F
M
F
M
K
M
F
M
F
M
F
M
E
F
G
A
quick,
quick
information
update
there
is
a
less.
We
are
working
group
link,
state,
vector,
routing,
they're,
working
on
what
called
layer
free
discovery
and
liveness,
and
that
is
a
mechanism
for
bootstrapping
latch
fabric
based
apologies.
I
would
recommend
to
take
a
look
into
that.
You
might
find
a
lot
of
good
ideas
there.
Thank.