►
From YouTube: IETF111-ANIMA-20210726-2130
Description
ANIMA meeting session at IETF111
2021/07/26 2130
https://datatracker.ietf.org/meeting/111/proceedings/
B
Okay,
welcome
everybody.
This
is
itf
111
animal
working
group.
If
this
is
not
what
you
sign
up
to,
please
try
to
find
a
different
room.
Otherwise
you
know
enjoy
the
ride.
B
So
I,
if
you
have
any
problems,
please
you
know
chime
in
on.
You
know
on
the
audio
channel
or
anything
because
I'm
sharing
the
slides.
I
can't
see
the
chat
right
now,
just
looking
at
the
queue.
Let's
get
started
with
the
usual
stuff.
Itf
note:
well,
I'm
not
going
to
read
everything.
You
know
just
be
aware
everything
you're,
saying
here
doing
public
and
so
on
all
the
other
stuff.
You
should
know
logistics
share
chairs
here,
giving
this
slide
there
shang
and
myself.
B
There
are
no
blue
sheets,
but
it's
automatically
done
in
the
in
the
minutes.
There
is
no
jabber
scribe
being
asked
for
that's
the
the
chat
has,
thankfully
stepped
forward
to
be
the
minute
tracker
and
then,
of
course,
these
license
streams.
You
know
that
so
the
one
thing
that
we
started,
the
last
itf
is
the
early
ipr
disclosure
process.
So
ipr
disclosure
early
means
when
we
adopt
a
working
group
draft
we're
also
already
asking
for
ipr.
B
Yep
so
major
achievement,
we
finished
after
you
know,
felt
hundred
years.
In
reality,
I
think
it's
five
six
years
our
chart
around
one
after
last
itf
in
may,
the
cluster
was
resolved,
so
we
now
have
eight
rfcs
representing
a
I
and
its
validation
use
cases,
and
you
should
know
all
these
documents.
B
Obviously,
if
you
don't,
if
you
joined
enema
late
and
I
just
trying
to
figure
out
what
the
heck
we're
doing,
then
I'd
recommend
you
to
listen
to
the
presentation
I
gave
an
hour
ago
at
sakham,
a
working
group,
and
there
is
an
another
one
at
ops
area
on
friday,
so
first
and
last
sessions
of
the
week
providing
the
background
of
what
we
did
so
far
and
yeah.
So
congratulations
to
everybody
involved.
Many
things.
You
know
from
the
authors
to
the
contributors
and
supporters.
B
If,
if
we
did
mention
your
name,
our
bad
and
then,
of
course,
also
all
the
you
know,
itf
process,
which
was
really
great
itf
review,
isg,
review,
painful,
but
very
good
rfc
editor
and
the
tools
team
to
that
allowed
us
to
actually
write
these
documents.
So,
all
right,
if
we
were
here
in
person,
I
would
you
know,
try
to
open
a
champagne
bottle.
So
you'll
just
see
the
visual
representation
of
that
how
it
opens
autonomously
all
right
back
to
work.
So
where
are
we
at?
B
So
we
have,
I
think,
seven
or
eight
active
working
group
documents
which
we
are
now
my
screen
is
so
small
that
I
can't
even
see
what
I
wrote
here
so
the
asa
guidelines
there
is
not
going
to
be
an
update.
We
think
that
the
document
is
ready
for
last
call.
We
discussed
that
with
the
authors
before
the
the
ietf
brian
is
here
online.
B
So
if
there
are
any
questions
or
so
please
jump
up
and
ask
them
here,
but
we'll
just
schedule
a
last
call
after
the
itf,
this
document
has
gone
through
many
yep.
You
want
to
talk,
please
go
ahead,
nope
you're,
not
talking.
B
I
am
yeah
great
and
with
video
excellent
yep
and
the
audio
is
working
so
yeah,
so
the
the
document
went
because
we
couldn't
adopt
it
before
charter
round
two.
It
went
through
a
lot
of
you
know,
working
group
feedback
and
and
revisions
while
it
was
still
individual
contributions.
So
that's
why
it's
pretty
much
it's
it's
finished
now
then
we
have
s
n
roll
and
where
we
split
out
the
jws
voucher.
So
all
this
stuff
is
happening
on
thursday
when
it's
related
to
brewski.
Also,
the
constraint
voucher
that.
B
D
Okay,
just
just
to
have
a
little
correction
there,
the
ietf,
anime
jws
voucher,
wasn't
a
split
out
of
other
gun
role.
It
was
a
separate
or
a
video
individual
submission
and
it
just
became
working
group
item.
So
we
were
talking
about
a
split
that
we
will
talk
on
on
thursday.
I
think.
B
B
B
Okay
right
so
constrain
joint
proxy
that
that
is
also
going
to
is,
is
ready
for
last
call.
We
think
the
grass
distribution
is
being
presented.
B
So
that's
the
working
group
documents,
then
the
non-working
group
documents
there
are
several
new
or
revived
works
that
have
all
slots
here.
So
I'm
not
going
to
talk
about
them,
they're
also
one
that
was
updated.
I
haven't
received
slides
from
bernardo
so
that
the
sixth
slot
today
will
probably
skipping
so
more
time
for
the
rest
and
then
the
l2
friendly
acp.
There
was
no
ask
so
probably
also
below
the
line
of
work
priorities
right
now.
Oh
carlos
you're.
There.
E
B
B
All
right
so
yeah,
that's
basically
the
work,
there's,
obviously
a
lot
of
stuff
below
the
line
that
that
has
expired.
B
Just
a
general
reminders.
We
have
a
weekly
almost
most
of
the
time
weekly
brewski
design
team
on
thursday
morning
with
the
information
here
and
the
people
that
most
regularly
show
up.
That's
also,
what
did
the
hackathon
that's
also
going
to
be
report
on
thursday
we
also
have
our
github
that
you
are
more
than
welcome
to
put
any
anima
related
work
into
it,
just
send
email
to
get
invited
to
it
if
you
haven't
been
using
it
and
yeah.
So,
let's
go
to
the
agenda.
B
F
B
B
F
A
F
Yeah
so
yeah.
This
is,
although
it's
probably
late
right
now
in
munich,
so
now
I'm
only
the
one
here
from
munich
to
provide
updates.
F
So
this
is
the
update
for
the
third
version
of
our
working
group
draft
for
the
graph
distribution
machine,
shell,
okay,
this
is
just
a
record
to
to
sketch
the
main
scope
of
our
draft.
F
We
focus
on
the
the
information
distribution
module
in
the
ami,
and
we
also
involved
with
the
grasp
extension,
try
to
reuse
all
the
the
grasp
apis
and
that
have
been
proposed
so
that
we
can
really
reuse
the
functionalities
you
know
below
there
and
try
to
maximize
the
the
utilization
and
also
try
to
get
more
enriched
information
distribution
functionalities
above
there
to
support
the
uplay
application.
F
Okay,
I
will
skip
this.
This
is
actually
the
the
page
that
shows
that
this
working
working
group
document
was
adopted
last
year,
and
this
is
the
main
change
from
zero
to
one.
We,
actually,
you
know,
merged
the
the
box
zero
from
brian
and
also
try
to
talk
about
how
to
do
the
information
distribution
for
the
block
information
and
after
that
we
try
to
focus
on
address
the
comments
about
use
case.
This
is
the
last
version,
and
this
is
the
new
updates
from
the
last
version
right
now.
F
We
actually
change
the
the
change,
the
first
warsaw,
because
I'm
right
now
mainly
responsible
for
the
updating
things,
many
versions
already,
and
so
I'm
taking
the
first
lesson
right
now
and
in
this
version
we
still
focus
on
polishing
our
use
case
and
the
requirement
so
so,
specifically,
what
we
each
change
from
the
last
version
is
that
this
is
still
the
old
slice.
F
I
would
directly
move
to
the
new
one,
the
new
changes
that
we
we
still
focus
on,
addressing
the
comments
about
use
case,
because
this
is
very
very
important
to
to
motivate
this
work
so
that
people
can
can
easily
easily
understand
we
or
why
we
are
proposing
the
information
distribution
for
the
ami.
F
So
what
we
exactly
changed
is
that
we
changed
the
use
case.
If
previously,
it
was
named
as
distributed
computing
to
in-network
computing,
because
we
think
this
scenario
or
use
case
is
more
suitable
for
for
any
anemone,
because
in
anemia
in
anima
in
an
ani.
Basically,
all
the
ass
is
providing
a
kind
of
computing
functionality
and
services
for
the
network
service
and
those
a
ass
were
supposed
was
supposed
to
run
inside
of
the
network.
So
that's
why
we
think
it's
more,
maybe
more
appropriate
to
call
it
to
motivated
by
in-network
computing.
F
You
know,
scenarios
and
use
cases,
so
basically
this
that
can
better
generalize
the
requirement
of
the
modes
application
scenario.
So
out
of
that,
we
we
basically
modified
the
section
two
in
the
use
cases
and
we
further
generalized
the
requirement
for
the
in-network
computing
use
cases.
Basically,
right
now
we
developed
two
types
of
requirement.
F
F
We
may
have
backup
ass
asa
or
afs
in
the
network,
so
basically
those
backup
or
copy
of
the
original
ss
may
want
to.
Basically
you
know,
backup
or
synchronize
all
the
data
when
running
the
service
is
provided
to
the
user.
So
we
think
information
distribution
should
consider
how
to
support
data
backup
as
a
new
kind
of
a
requirement
for
the
information
distribution
and
basically
it
can
can
involve
master
slave
synchronization.
F
F
These
kind
of
you
know
data
back
off
information
distribution,
so
for
the
second,
for
the
second
use
case
we
are
right
now,
considering
is
that
maybe
information
distribution
should
consider
how
to
support
sorry,
how
to
support
data
aggregation
data
aggregation
basically
means
that
two
asa
here,
afa
and
afb
may
generate
different,
may
generate
different
set
of
data,
and
basically
these
two
as
a
a
and
b
here,
may
cooperate
with
each
other,
so
eventually
they
would
like
to
merge
or
aggregate
their
individual
data
set
so
that
they
will
get
an
aggregated
one.
F
So
this
also
has
many
many
many
examples
so,
for
example,
right
now
the
very
popular
in
artificial
intelligence.
F
So
we
are
considering
how
this
can
be
and
how
this
kind
of
work
or
jobs
tasks
can
be
further
supported
in
our
ami
by
the
information
distribution
module
so
right
now
we
we
think
the
the
e-network
computing
use
cases
are
really
really
matching
the
the
a
I
and
the
ass.
You
know
applications
at
the
higher
layer,
and
we
think
this
is
very
important
functionalities
that
we
should
really
think
about.
F
Maybe
this
cam
can,
can
you
know
better
revise
our
current
draft
in
order
to
address
some
of
the
comments
that
appears
in
our
main
mailing
list.
So
a
further
question
here,
I
actually
didn't
have
too
much.
You
know
information
for
that
right
now.
So
if
we
are
talking
about
data
backup
or
data
aggregation,
maybe
we
should
further
think
about
whether
information
distribution
should
consider
you
know
consensus
among
those
apps
or
assets
asa
okay.
F
So
this
is
the
main
updates
from
you
know,
for
this
draft
and
and
of
course,
we
will
further
update
the
current
text
and
we
will
focus
on
the
the
other
set
of
comments
to
prepare
the
next
version,
because
maybe
we
are
we
are
thinking
about.
Maybe
after
two
more
updates
or
one
major
update,
maybe
we
can
consider
to
submit
to
the
external
review
yeah.
Okay
thanks
any
questions.
B
Or
comments
or
suggestions,
thank
you
very
much
yeah.
So
I
was
wondering.
B
Sure
sure
that's
fine,
okay,
are
there
any
other
specific.
You
know
working
groups
or
so
you
could
think
of
that.
That
would
have
feedback,
then
just
reach
out
to
them
or
let
us
share
snow,
and
we
can
help
just
to
expand
the
scope
of
reviews,
bring
it
up
on
the
mailing
list
again.
So
yeah.
Definitely,
let's
plan
to
have
this
in
you
know
last
call
before
next
ietf,
I
think,
and
from
my
side
I
think
it
should
be
getting
close
to
that.
So
I'll
also
yeah
check
it
out
again,
yeah.
E
A
Updates,
so
is
there
many
outstanding.
A
F
B
No
problem:
okay,
let's
get
to
the
next
slot,
so
this
is
work
that
I
had
started
in
before
you
know
we
we
went
into
round
one
around
itf
100
101,
so
we
let
it
expire
to
concentrate
on
our
round
one
work,
which
obviously
is
now
finished
so
now
I
revived
that
work
right
now.
There
is
only
minor
textual
improvement,
co
and
the
co-author
started
to
also
provide
input
on
that.
B
So
I
just
wanted
to
give
a
reminder
which
about
this
work
and
hope
that
people
are
start
getting
interest
and
provide
feedback
and
help
to
finish
this
fairly
quickly,
because
it's
not
really
that
difficult.
So
this
is
really
about.
What
are
we
missing
for,
let's
say
rfc
8368,
which
is
you
know,
using
enema
for
existing
networks
through
the
acp
and
the
the
main
issue
is
really
to
bring
up.
B
B
So
what
what?
What
do
we
really
need
for
that
most
fundamentally
right?
So
how
does
the
knock
learn
about
newly
enrolled
devices?
I
wouldn't
necessarily
assume
that
the
enrollment
service
is
tightly
integrated
with
whatever
has
to
come.
Next,
so
certainly
would
be
good
if
this
can
be
independent
of
each
other,
and
so
one
of
the
simple
answers
that
we've
used
in
pre
standard
implementation
is
to
simply
rely
on
syslog.
So
if
a
device
becomes
available
on
the
acp,
it
syslogs
itself
so
question:
where
does
it
find
the
syslog
server
right?
So
then?
B
The
other
thing
is:
how
do
we
make
the
certificates
actually
work
and
get
renewed
correctly?
We
need
time
synchronization
already
part
of
the
ask
and
requirement
in
rfc
8994
acp,
but
not
specified
how
so
auto
configuration
of
ntp,
finding
ntp
server
and
using.
That
would
be
the
second
key
issue
and
then,
finally,
you
know:
how
do
you
get
operators
to
access
the
device
so
ssh
for
cli
netconf
via
ssh
or
tls,
for
automated
system?
B
Netcom,
zero
touch
callback
as
well
all
of
these
something
to
auto
discover
in
the
case
of
explicitly
ssh
or
netconf
into
a
device.
One
of
the
problems
is
that
the
domain
certificates
themselves
do
not
provide
really
authorization
support
and
privileges.
B
How
do
we
do
dns
compatible
service
discovery
because
we
don't
need
all
the
normal
dns,
and
so
that
is
basically
done
with
grasp,
which
is
one
of
which
is
the
other
draft
that
I
have
some
slides
at
the
end
of
this
deck
right
and
obviously
this
service
discovery
can
be
reused
for
a
lot
of
additional
services,
firmware
update,
even
om
dns,
a
lot
of
other
services,
ipfix
netflow
dhcp
parameters,
snmp
traps
and
so
on.
So
there
are
a
lot
of
infrastructure
services
for
which
you
know
auto
enhancement.
B
B
So
as
far
as
the
dns
how
it
works
right,
so
there
is
basically
you
know
a
an
update,
I'm
giving
tomorrow
for
the
dns
sd
working
group.
But
I
don't
want
to
repeat
all
the
stuff
we
know
here
in
enema,
but
I
think
the
one
important
thing
to
remember
is
that
the
ani
is
designed
so
that
it
does
not
require
dns,
because
we
don't
need
dns
names
for
nodes,
because
the
acp
addresses
are
pretty
much
the
names
right,
but
we
do
need
services
discovery
and
we
don't
you
know,
have
that
other
than
you
know.
B
That
grasp
is
a
very
generic
solution
that
we
want
to
use
for
it
so-
and
here
is
kind
of
a
couple
of
explanation-
why
really
reusing
existing
unicast
or
multicast
dns
is,
is
difficult
and
and
not
really
what
we
want.
So,
ultimately,
the
the
the
planned
architecture
is
that
really
what
we
want
to
do
is
to
have
something
which
is
compatible
with
dns
sd.
B
Add
the
service
api
layer
to
the
applications
that
are
announcing
and
trying
to
discover
services
through
through
that
api
and
then
grasp
dns
ssd
is
going
to
be
an
equivalent
alternative
to
rfc
6763,
which
is
the
mapping
of
the
service
requests
and
announcements
to
dns,
which
is
fairly
convoluted.
You
know
using
multiple
at
least
four
different
type
of
resource
records,
whereas
in
grasp
it,
it
really
is
very
simple,
a
single
graph
objective
to
announce,
discover
services
and
then
use
grasp
across
the
acp.
B
So
I
show
this,
you
know
this
is
basically
the
the
cddl
for
the
dns
sd
compatible
grasp
objective
proposal,
and
that
has
all
the
you
know,
well-known
parameters
that
you
know
from
dns
sd,
the
name
of
the
service,
the
instance
name
and
then
the
priority
the
weight,
an
additional
extension
key
value
pairs,
which
is
defined,
indian
ssd
and
then
also
you
know
extensions.
B
We
can
only
do
in
grasp
because
we're
flooding
it
hot
by
hop
and
that
I
think,
is
one
of
the
important
things
to
do
a
decentralized
solution
which
is
the
distance
of
the
announcer
of
the
service
to
the
consumer
of
the
service.
We
can
track
that
as
well
through
the
gras
ttl.
So
that's
something
we
couldn't
do
through
unicast
dns,
for
example,
so
this
is
kind
of
the
obviously
the
core
of
the
specification
of
that
draft,
and
I
don't
want
to
go
into
too
many
more
details
here.
B
The
other
part,
of
course,
that
comes
out
of
it
is
that
we
for
most
of
the
things
we
would
do
across
grasp
if
they
really
are
meant
to
be
services
in
the
same
way
as
dns
sd.
We
don't
need
separate
registry
for
it.
B
So,
finally,
then
you
know
this
is
all
cool
stuff
for
networks,
and
maybe
not
all
of
the
networks
will
want
to
have
a
full
acp
and
the
acp
is
just
the
you
know,
transport
and
security
infrastructure
for
grasp.
So
maybe
there
is
some
other
follow-up
work
that
would
be
useful
to
figure
out
a
more
lightweight.
B
You
know
transport
for
a
grasp,
so
that
especially
the
service
discovery
could,
with
grass,
would
be
a
good
reason
for
networks
to
deploy
grasp,
even
when
it
cannot
have
the
full
acp,
and
one
of
the
ideas,
of
course,
is
that
you
know
we
just
need
to
match
the
security
of
existing
networks
where
it
is
the
biggest
attack
vector
in
most
of
the
networks.
Today.
B
This
is
the
igp,
which
is,
you
know,
typically
just
protected
by
acls,
forming
a
clam
shell
around
the
network,
and
so,
if
we
simply
define
a
you
know
a
transport
that
says
well
we're
just
going
to
build
tcp
connections
to
any
neighbor.
That
is
also
an
authorized
igp
neighbor.
Then
we
can
very
simply
deploy
grasp
without
any
of
the
other.
B
A
B
So
so
the
one
document
which
is
the
what
was
called
knock
auto
config,
I
renamed
when
I
uploaded
it
after
a
really
good
session
with
ignas,
where
you
know
a
lot
of
networks,
don't
necessarily
have
something
called
a
knock,
but
would
you
know
call
it
differently
so
then
I
was
going
back
in
the
name,
but
I'm
not
aware
that
I
uploaded
any
old
slides.
So
maybe
we
can
take
that
offline
on
unless
it's
you
know
of
interest
to
the
whole
working
group.
Now.
B
Good
all
right,
then,
let's
have
the
next
person
step
up.
I
think
that
should
be.
Let
me
look
at
the
codemd
that
should
be
yuju.
Do
you
want
to
share
the
slides
yourself.
C
Okay,
just
very
briefly
the
prototype
code
that
I
wrote,
the
hard
part
was
interpreting
the
dns
sd
records,
which
are
just
you
know.
It's
it's
a
retrofit
on
top
of
the
dns,
it's
really
not
very
clean,
because
you
have
to
look
at
different
record
types
and
figure
out
how
they
relate
to
one
another,
and
I
it's
just
a
mess.
C
To
be
honest,
the
rest
of
it's
trivial.
B
Yeah,
that's
why
the
the
proposal
doesn't
really
use
any
of
the
dns
record
types
right,
so
I
think
the
functionality
that
you
have
might
be
for
translating
dns
sd
when
somebody
announces
dns
sd,
but
when
we
actually
do
native,
you
know
grasp
announcers,
then
it's
that
simple
record
that
I
showed
on
the
prior
slide
and
obviously
the
idea
would
be
to
have
an
api
where
you
can,
instead
of
using
actual
dns
records
directly
just
create
the
graph
record
yeah,
translating
that.
B
Yeah,
I
wasn't
aware
that
you
were
trying
to
get
into
that
mess.
I
remember
that
I
did
several
years
back
and
yeah.
That's
that's
really
very
complicated,
but
remember
that
was
this
original.
The
the
the
service
originates
from
apple
talk
and
that
was
fairly.
E
B
E
B
Very
well
extensible,
so
that's.
B
B
E
A
G
Okay,
good
hello,
I'm
this
is
I'm
this
user,
I'm
going
to
present
this
autonomic
ip
to
access
access,
control,
group,
mapping,
information
via
the
grasp
objective,
so
the
first
page
is
going
to
a
little
bit.
Excuse
me
a
little
bit
background
of
the
group-based
policy,
because
in
the
campus
network
we
are
moving
we're
kind
of
moving
from
the
traditional
subnet
based
seo
to
the
group-based
policy.
G
So
though,
traditionally
we
are
using
the
pre-known
vlan
and
the
subnet
plus
the
ip
prefix
basic
based
acl,
as
the
access
control
mechanism
in
a
such
mechanic
mechanism
is
relatively
static.
So
it
is,
it
is
tying
the
same
set
of
groups
of
hosts
by
assuming
that
they
are
accessing
from
a
pre-assigned
switch,
an
ostrich
ports
in
the
assigned
vlan
and
the
tide
subnet
or
ip
prefix.
G
But
it's
no
longer
the
case
because
most
of
most
of
the
campus
networks
now
allowed
their
employees
or
guests
to
bring
their
own
devices
and
trying
to
access
the
laptop
from
either
from
any
location
in
the
campus
network.
So
it
is
no
longer
the
case
that
the
people
accessing
from
maybe
the
same
floor
of
a
building
are
belonging
to
a
same
group,
say
the
engineering
group
accounting
group
and
also
in
the
conventional
provisioning
and
the
ip
prefixes
are
used
as
the
source
or
destination
rules
in
the
acl.
G
G
When
these
prefixes
of
the
end
hosts
is
known
owned,
it
is
not
known
in
advance,
so
the
group-based
policy
is
emerging
and
actually
is
being
widely
used
as
a
replacement.
Now
the
the
admin
defines
the
groups
and
the
rules
based
on
those
groups
in
advance
and
those
groups
and
policies
all
the
other
rules
ie
respective
of
the
end
users,
ip
or
ip
prefixes.
G
At
the
same
time,
the
group-based
policy
would
require
the
policy
execution
point
pep
to
locally
store
the
ip
prefix
to
access
control
group
id
information,
the
mapping
information.
Because
for
the
pep
point
you
need
to
check
against
the
data
packet
and
try
to
map
from
the
ip
address
to
a
grouper
address
then
check
against
the
rule,
then
using
this
group
based
rule
to
execute
the
policy.
So
that's
the
basic
usage
scenario
of
the
group
group
based
policy.
G
Then
here
comes
to
two
topologies.
Actually,
this
one
is
a
simple
one.
This
is
a
simple
topology
which
we
normally
used
in
a
campus
network.
If
we
look
at
the
left
hand
side
here,
we
show
the
three
layers
of
the
switches.
Of
course
it
can
be
two
layers
or
more
layers.
Maybe
so
we
defined
two
terms
here.
G
The
first
one
is
called
the
path
policy
enforcement
point,
depending
on
the
different
scales
or
of
the
of
the
network,
also
different
deployment,
for
example,
whether
the
uplink
of
of
a
certain
layer
of
the
switches
is
a
dual
home.
They
are
single
home
also,
depending
on
the
layer,
2
or
layer
3
topology.
G
G
Another
term
we
define
is
called
aap
access,
authentication
point
in
this
picture.
Each
of
the
access
switch
is
in
aap,
it's
responsible
for
its
attaching
and
users,
so
as
it
at
the
same
time,
the
places
to
put
aap
also
vary
and
the
functionality
of
the
aap.
There
are
two
functionality.
The
first
one
is
the
aap
need
to
obtain
the
ip
address
or
prefix
information
assigned
to
its
attaching
and
host.
G
G
So
the
aap,
the
access
authentication
point
and
keep
can
keep
the
ip
and
the
group
bindings.
So
here
comes
a
requirement
for
the
grasp
defining
animal
working
group.
The
perhaps
the
policy
for
some
enforcement
points
would
like
to
get
the
ip
prefix
to
group
information
group
mapping,
information
from
the
aap.
G
There
are
two.
Basically,
there
are
two
reasons
why
it
is
would
be.
It
is
required.
The
first
one
is
the
pep.
The
pep
points
in
the
aap
are
normally
on
the
different
nodes.
So,
of
course,
if
there
is
in
some
cases,
if
they
are
on
the
same
nodes,
then
such
information
distribution
would
not
be
required.
G
G
So
this
is
a
simple
topology
show
of
a
campus
network,
and
then
I
will
move
to
the
element.
Sorry
now
this
is
a
more
complex
topology
here,
the
left-hand
side.
The
picture
shows
a
more
complex
topology
for
campus.
We
have
a
headquarter,
we
have
a
branches
and,
and
on
the
top
we
have,
we
have
the
internet
user
access
campus
via
the
tunnel
via
the
vpn
tanoami.
G
So
there's
no,
no,
actually
the
implications
are
similar.
The
paths
are
located
can
be
located
on
different
places
and
specific
traffic
can
be
directed
to
a
certain
path.
For
example,
if
you
look
at
the
headquarter,
there
is
a
firewall.
We
call
the
pep1
that
that
that
pep
is
designated
only
for
the
intro
headquarter
traffic,
so
that
means
it's
normally
using
normally
using
together
with
some
of
the
traffic
direction
and,
of
course,
more
complex
group
definition
or
policy
enforcement
rules
would
be
would
be
defined.
G
For
example,
a
single
user
may
belonging
to
more
than
one
group,
but
anyway
the
the
implication,
the
requirements,
I'm
understanding.
G
I
still
want
to
ip2
group
mapping
information
from
the
aap,
given
these
two
example
topology.
So
here
is
a
proposal
we
are
we
are
having
in
the
document.
We
want
to
define
a
new
grasp
objective,
to
distribute
the
ip
address
or
prefix
in
to
sorry
to
distribute
the
mapping
information
from
the
ip
address
or
prefix
to
the
access
control
group
id.
So
I
roughly
show
the
objective
defined
here.
Basically,
I
think
there
are
maybe
two
points
to
be
required
to
be
brought
up.
G
The
first
one
is
we
allow
the
single
ip
address
or
prefix
to
map
to
more
than
one
group
id.
The
second
one
is
thanks
to
the
contributors
we
are
using.
The
itf
receiver
network
address
draft
definition
for
the
ipv4
and
ipv6
address
and
prefix.
G
So
that's
the
that
that's
a
format
we're
going
to
use
the
procedures
we
have
the
provi
nominate,
the
providing
node
should
be
the
x
authentic
should
be
the
aap
access
authentication
point.
It
sends
unsolicited
synchronization
message
to
the
policy
enforcement
point
port
tab
upon
a
new
binding.
The
binding
means
the
actually.
The
binding
here
means
the
ip2
group
id
tie
so
either
upon
a
new
binding
or
there
is
updating
of
the
old
binding
or
there
is
a
withdrawal.
G
The
second
possibility
is
can
is,
it
will
send
a
synchronization
message
as
a
response.
Whenever
it
receives
a
request,
the
requesting
node
would
be
a
pap
point.
It
will
send
a
request
for
the
mapping
information
when,
when
either
the
source
or
the
destination
group
is
not
available
from
the
data
packet.
G
The
the
the
reason
we
show
or
the
the
reason
why
we
say
either
source
or
destination
group
is
because
for
some
of
the
data
packet
encapsulation,
the
source
group
id
can
be
injected
directly
to
the
data
plane.
So
it
it
really
depends
on
how
the
encapsula,
what
the
encapsulation
is
so
sometimes
some
of
the
time
both
of
the
source
and
end
destination
should
be
requested
by
some
of
the
time.
Only
one
of
them
should
be
requested.
G
Yeah,
so
there's
one
more
thing
I
think
was
to
be
discussed,
maybe
in
the
mailing
list
or
direct
to
me.
So
currently
we
are
having
the
aap
talk
to
pep,
whether
we
should
allow
the
pep
cascaded,
perhaps
to
not
represent
two
requested
and
any
response
among
themselves.
So
this
is
the
thing
that
may
be
yeah.
G
Okay,
you
can
feedback
to
the
mailing
list.
I
think
that's,
that's
all
the
next
steps.
We
are
going
to
revise
it
and
yeah
edit,
based
on
the
comments
we
have
received
and
going
to
be
going
to
receive
in
the
main
list.
I
think
that's
all
any
questions.
B
Yeah,
thank
you
very
much.
I
I
think
high
level,
I'm
I
didn't
have
the
time
to
go
into
the
details,
but
if
this
is
primarily
policy
distribution,
I'm
wondering
if
this
could
ride.
On
top
of
the
grasp,
information,
distribution
thing
or
whether
it
needs
to
be
a
complete
stand-alone
grasp
objective
definition.
G
Yeah
the
thing
is
it
this
one
actually
doesn't
propose
to
to
do
the
policy
itself.
It
is
just
assuming
the
the
the
cameras
network
has
already
trying
to
use
the
group-based
policy,
so
this
is
only
trying
to
distribute
the
mapping
information
from
the
ip
prefix
to
the
group,
so
the
policy
itself,
the
distribution
of
the
policy
rules
itself.
Doesn't
that
doesn't
I
mean
it's
not
in
this
document
right.
B
G
A
Quick
comments,
one
is
you,
may
I
find
out,
you
can
benefit
from
use
the
sap
directly
to
secure
your
communication.
Secondly,
is
what
you
described
looks
to
me
like
some
kind
of
autonomic
service
agent.
If,
yes,
you
can
describe
in
that
way,
that
will
make
us
better
to
judge
whether
you're
fetching
animal
or
not.
B
Johanna,
do
you
want
to
share
your
slides
yourself
or
should
I
share.
B
I
I
I
Oh
okay,
your
a
confirmed,
auto
screen
button,
so
you
help
me
to
share
screen.
B
I
I
The
grasp
is
running
in
asap
to
exchange
the
information
among
autonomic
node,
so
that
the
results
among
the
service
plans
can
be
coordinated,
and
what
is
services
is
one
is
an
unicast
or
multicast
flow,
which
has
a
source
and
designation.
What
is
network
services,
a
new
services
flow
control,
one
or
more
service
flow.
A
resource-based
network
services
has
a
reference
requirement,
which
has
extremely
assured
the
minimum
bandwidth
maximum
and
to
end
deliver,
latency
and
so
on.
I
I
I
The
objective
flank
is
about
the
is
valid
for
discovery
and
negotiation
and
synchronization.
The
objective
value
is
a
date
structure
and
follow,
for
example,
a
service
identifier
which
used
to
distinguish
different
network
services.
Maybe
one
grasp
message
contain
more
than
one
service
network
services
service
deployment
deployment
type,
which
indicates
that
is
new
or
updated
or
deleted.
I
B
Joanna,
can
you
can
you
speed
up?
We
we
need
to
finish
this
within
five
minutes
to
to
still
have
the
last
slot.
If
you
can
stay
high
level,
I
think
you
know
most
of
us
have
problems
to
grasping
all
these
tiny
details
within
a
presentation,
so.
I
Okay,
I
got
it
okay,
this
new
dropped,
objective
option
is,
is
running
along
the
network
service
panes
among
the
ingress,
p
and
sp
node,
p
node
and
the
linguist
and
the
ingress
pe
this.
This
definition
is
the
same
as
the
previous
definition.
Okay
I'll
introduce
how
to
use
it.
E
I
Process
of
network
service
auto
deployment
if
a
new
or
updated
network
service
deployment
occur,
the
network
service
initiatives
and
the
spe
grasp
request
negotiation
negotiation
message:
the
deployment
type
field
with
a
new
or
update
type.
I
The
icp
first
detect
detects
whether
the
uri
interface
meets
the
resource,
the
service
resource
information
and
then
detect
whether
the
network
plans
meet
the
parents
resource
information.
If
they're
all
satisfied
the
results,
information,
the
spu
will
send
the
bank
a
grasp
negotiation
with
a
service
department
status
field
deploy
deployment
success.
I
If
one
of
the
proceeding
item
does
not
meet
the
requirement,
the
spu
will
send
bank
a
grasp
negotiation
message
with
a
service
deployment,
state
field,
deployment
theory
and
really
little
reason.
If
you
withdraw
network
service
deployment,
the
network
service
initiates
to
notify
sp
to
release
the
related
information.
I
This
is
about
the
results
based
network
pass
deployment,
the
the
different
from
the
previous
precise,
the
sp
sender,
the
standard
grasp
request
negotiation
along
the
down
node
along
the
along
the
pens.
So,
if
the,
if,
if
the
line
network
node
found
out
the
resource,
information
account
satisfy
the
resource
information,
it
will
send
the
cinema
bank
the
grasp
negotiation
message
to
the
to
the
upstairs
node.
I
I
I
I
Therefore,
the
bandwidth
parameters
carried
in
a
grass
group
as
the
negotiation
message
along
the
path
can
be
the
same
if
it
is
the
maximum
and
to
and
deliver
the
literacy,
because
it's
the
sum
of
the
following
delay
under
the
link
delay.
Therefore,
the
latency
results
requirement
currently
in
a
grasp
request.
Negotiation
center
can
be
different
next.
I
I
E
B
B
Please
you
know
sounds
very
interesting.
Please
check
if
you
find
time
to
to
read
it
and
comment
on
the
list.
Carlos
can
you
step
forward
and
also,
if
you
can
stay
high
level,
we're
already
at
the
end
of
the
official
time.
So
maybe
just
do
a
good
spin
of
why
people
should
be
interested
in
read.
It
is,
instead
of
just
explaining
all
the
details
again.
E
B
E
Okay,
perfect,
so
let
me
very
quickly,
so
this
is
the
presentation
of
a
draft
that
we
wrote
some
time
ago
about
autonomic
setup
of
monitoring
agents.
So
the
motivation
for
this
presentation
was
basically,
we
did
already
first
presentation
two
years
ago
and
we
received
some
feedback
from
michael.
Even
we
had
some
offline
meetings
discussing
potential
things
to
do,
but
at
that
time
we
couldn't
really
continue
the
work,
also
because
the
charter
did
not
really
allow
to
do
or
to
to
cover
the
the
kind
of
work
that
this
draft
does.
E
So
we
like
to
resume
now
this
effort,
basically
under
the
charter
item
that
is
shown
in
the
in
the
screen,
so
basically
document
a
potential
generic
use
of
autonomy,
networking
and
grasp,
and
the
idea
here
today
that
I
will
be
very
very
brief
because
we
are
over
time
is
to
see
whether
there
is
interest
in
the
working
group
to
explore
this
further
and
I
had
to
say
a
disclaimer.
Even
I
mean,
though
we
brought
this
draft,
we
are
not
experts
in
in
grasp
and
in
anima,
so
it's
it
was
try.
E
The
idea
is
that,
well,
we
have
virtualization,
I
think
we
all
of
us
are
probably
very
much
aware
of
this.
We
have
sfc
and
we
may
have
now
virtualization
going
to
mobile
devices
getting
to
the
actual,
even
in
the
into
the
end
user
devices.
So
we
have
this
concept
of
fog.
That
is
extending
the
virtualization
into
the
into.
C
E
The
edge
and
into
even
the
the
final
user
devices,
so
we
may
have
sfcs,
composed
of
functions
that
running
on
fixed
infrastructure,
nodes
and
also
on
mobile
nodes.
For
example.
We
have
here
in
this
simple
scenario:
different
nodes
and
we
have
functions,
function
one
and
function,
two
that
originally
was
running
function,
one
in
fog,
node,
a
and
faction
two
in
focus
b,
but
because
of
the
mobility
or
whatever
other
reason,
we
need
to
move
function,
1
to
function,
2.,
so
basically
to
support
this
kind
of
very
dynamic
and
volatile
environments
that
differ
from
data
center.
E
E
So
in
our
particular
solution,
that
is
an
example.
We
have
four
gradients
running
on
the
nodes
with
resources
and
we
have
a
centralized
controller
that
is
gathering
the
input
or
we
may
have
a
set
of
controllers,
gathering
the
input
and
based
on
that
triggering
orchestration
actions.
So
if
we
are
here
well,
that
will
be
the
architecture.
I
will
not
go
into
the
details,
but
if
you
have
to
use
grasp
to
do
this,
autonomic
setup
of
the
fog
agents
running
on
the
devices
and
the
controller
and
in
the
document
we
have
a
potential
solution.
E
Well,
basically,
this
is
the
idea
will
be
whether
this
type
of
a
scenario
about
setting
up
monitoring
this
is
for
for,
but
it
could
be,
for
any
type
of
virtualization
environment
could
be
of
interest
as
a
thing
or
use
case,
to
document
the
use
of
grasp
for
for
this
type
of
scenario
and,
if
so,
just
to
provide
fiba.
So
we
can
continue
working
on
this
now
that
we
feel
that
it
could
fit
the
the
charter
and
that's
it
very
beautifully.
E
B
Thank
you
very
much,
also
for
being
short
and
crisp
any
questions.
A
Yeah,
carlos,
I
do
have
a
little
problem
with
the
term
knowledge
you
use
for
fork,
because
I
I
didn't
find
it
in
any
other
idea
of
documents.
It's
more
commercial
terminology,
technology
com
technology
for
me.
So
for
my
understanding,
what
you
are
working
on
is
more
like
artwork
network,
which
is
more
technical
words.
So
if
that's
right,
I
would
like.
A
Nick
for
next
time,
otherwise
I
I
saw
it
interesting
work.
E
E
A
Commercial
words,
but
but
what
I
say
is
we
don't
have
such
definition
in
idf
in.
E
A
B
B
E
We
have
presented
some
stuff
on
folk
stuff
in
sfc
in
coin.
Not
yet,
although
we
did
well,
we
did
some
some
related
work
on
on
discovery
of
resources,
so
we
did
something
but
not
specifically
to
this,
but
I
can
also
say
that
we,
we
are
doing
research
on
this,
the
use
of
anima
and
related
stuff
in
in
some
european
projects.
So
we
had
research.
We
have
additional
results
that
we
could
present
in
other
working
groups.
This
was
just
specifically
about
the
autonomous
bootstrapping
and
setup
of
the
monitoring
part.
H
B
Cool
yeah.
Thank
you
very
much
yeah.
So
I
think
that
brings
our
monday
agenda
to
the
close.
If,
if
there's
anything
else
feel
free
to
ping
us
during
the
week
and
then
see
you
back
on
thursday
hold.
A
On
a
second
one,
last
words
from
chair
this
season,
we
receive
a
lot
interesting
new
works
thanks
to
others,
but
I
would
like
to
remind
the
others.
Please
invoke
the
discussion
in
the
violinists,
the
more
you
know,
attraction
you
get
from
in
the
marines
the
more
possibility.
You
know
the
chairs
looks
like
it
more
seriously
and
has
more
possibility
to
adopt
in
the
future.
Thank.