►
From YouTube: IETF112-LISP-20211112-1200
Description
LISP meeting session at IETF112
2021/11/12 1200
https://datatracker.ietf.org/meeting/112/proceedings/
A
A
So
hello,
everyone.
I
hope
you
hear
me
loud
and
clear-
welcome
to
the
lisp
working
group
in
this
itf
112..
We
are
a
couple
of
minutes
late,
but
was
a
little
bit
impossible
to
wait
a
little
bit
in
the
meantime.
You
got
more
familiar
with
the
note.
Well
that
applies
here
the
very,
very,
very
short
summaries
that
whatever
noise
you
do
during
this
meeting
is
a
contribution
to
the
ietf.
A
However,
there
is
also
another
little
piece
of
not
well.
That
is
important
to
detail
is
the
fact
that
we
have
a
code
of
conduct
detailed
in
rfc,
7154
now
lisp.
I
think
that
we
behave
okay
and
this
is
important-
it's
important
to
respect
each
one
another
and
that
we
have
discussion
based
on
technical
argument,
not
nothing
else,
okay,
and
we
we
struggle
to
find
global
internet
solution
and
all
in
operational
environments,
and
we
contribute
to
the
ietf.
A
As
I
said
in
lisp,
I
think
we
we
behave
okay,
unfortunately,
it's
not
in
every
in
each
working
group.
That
is
going
that
way,
but
it's
important
that
the
the
same
behavior
you
have
here,
please
spread
it
in
the
etf,
bring
people
to
be
reasonable
and
respectful.
Okay,.
A
As
for
the
business-
and
this
is
the
usual
pointer,
I'm
luigi,
joel
alpern
is
my
co-chair-
he's
also
online
padma
house
online
is
also
our
secretary.
She
will
take.
She
will
provide
minutes
offline
later
on
as
usual.
A
A
little
bit
of
an
update
since
one
one
one,
the
developing
a
few
documents
that
have
been
pushed
for
publication
so
are
now
in
the
hand
of
alvaro
our
responsible
id,
which
is
also
online
okay.
So
we
are
making
progress
in
a
certain
way,
and
I
say
in
a
certain
way,
because
if
you
see
on
the
your
right
hand,
side,
there
is
a
lot
of
red,
meaning
that
there
are
documents
that
are
sitting
there
for
a
while.
Okay,
now,
the
bottleneck
is
lip
sack.
A
Okay
is
the
the
last
piece
of
work
that
is
missing
in
order
to
unblock
a
lot
of
other
documents,
including
by
the
way
the
lisp
introduction,
okay,
which
has
been
updated
by
damian
susan
de
mental.
This
has
been
done
just
to
to
because
the
document
was
so
old
all
that
there
were
references
to
the
experimental
rfcs,
which
I
mean,
make
sense
to
to
to
update
it
and
put
the
right
references
there,
which
has
been
done
between
1
11
and
9..
Okay.
A
As
for
the
lisp
sec,
the
status
is
the
following:
I'm
shattering
the
document,
so
I
already
prepared
the
write
up,
but
because
I
had
a
few
I
would
say
small
issues
on
the
document
just
to
to
clarify
things
a
little
bit.
I
I
I
wrote
my
review.
I
sent
it
to
the
outers.
A
As
you
know,
albert
is
the
one
holding
the
pen
and
making
the
changes
usually
and
managing
that
he
is
a
little
bit
busy
this
period,
so
he
was
not
able
to
make
any
progress
on
that
side,
so
recently
contacted
back
damien
which
is
willing
to
to
take
the
pen
and
try
to
solve
the
residual
issues
that
are
in
the
document.
A
I
will
work
with
him
to
bring
him
to
speed
about
the
latest
development
hope.
I
hope
that
we
are
able
to
to
finish
this
document
before
christmas.
Okay,
however,
I
invite
all
the
co-authors
to
be
a
little
bit
responsive,
because
any
change
that
damien
does
has
to
be
validated
by
the
other
routers.
Okay,
as
for
the
other
documents,
we
have
the
young
model.
I
think
this
is
quite
ready
and
after
we
unblock
the
lisptec,
this
should
be
good
to
go
as
well
and
go
for
the
last
call.
A
We
have
lisp
vpn
and
lisp
l2
l3
mobility,
which
will
be
discussed
later
on
today.
They
are
on
the
agenda,
and
then
we
have
a
bunch
of
working
group
items
that
so
basically
are
working
documents
that
were
sitting
there
for
a
while
and
it's
time
to
to
pay
attention
to
them
and
review
them.
So
what
I
suggest
to
everyone
is
to
have
a
look
to
them
and
review
them.
We
will
go
over
each
of
one
of
them
in
order
to
see
whether
or
not
we
want
to
publish
them
or
not.
A
Okay,
because
at
the
end,
every
publication
is
the
product
of
the
working
group,
so
we
have
to
agree
to
to
to
move
it
forward.
If
there
is
interest
in
the
document
in
looking
at
the
charter,
there
is
one
one
and
only
piece
of
work
that
is
missing
is
the
traversal
document.
Okay,
but
we
have
a
good
candidate
that
was
around
has
been
around
for
a
while,
so
the
lisp
not
traversal.
A
So
this
is
something
also
to
consider
in
order
to
make
progress
for
113.
Okay.
A
So
as
for
the
agenda,
we
have
two
working
group
items
presentation
so,
as
I
said
before,
this
is
lisp
vpn
and
lisp.
Eid,
mobility,
okay-
and
there
is
a
presentation
about
our
known
working
group
item,
which
is
the
map
server,
reliable
transport,
and
we
will
conclude
with
the
list
fix
okay,
and
this
time
we
have
enough
time
to
discuss.
So
we
we
shouldn't
be
short
in
time,
so
I
invite
everybody
to
to
ask
question
clarification
just
discuss.
This
is
what
we
are
for
here.
A
A
Take
it
as
a
no,
so
the
next
three
presentations
are
from
mark
mark.
You
can
share
directly
the
slides
your
yourself
in
the
sense
that
they
have
been
uploaded
on
the
mythical
and,
if
I
stop
sharing,
you
can
ask
to
share
and
say.
A
B
Yeah
presenting
three
things
today,
but
yeah
hopefully
I'll
take.
Hopefully
I
won't
take
too
much
time
for
them.
Two
of
them,
as
lucy
was
mentioning,
are
leave
mobility
and
and
these
vpns,
these
two
are
working
group
items.
We
have
been
using
them
for
quite
a
long
time
and
would
like
to
to
recover
the
discussion
around
them
and
and
make
some
progress
on
on
these
two
documents:
okay,
the
first
one
is
this
one:
eid
mobility,
so
yeah.
The
title
is
l2
s3
id
mobility
using
a
unified
control,
plane.
A
Questions
when,
when
you
say
we
are
using
them
for
a
while
means
that
it's
it's
it
has
been,
there
is
at
least
one
implementation,
and
you
are.
C
B
B
So
these
drafts
essentially
provides
a
list
of
methods
for
using
a
common
control
plane
to
concurrently
support
layer,
3,
overlays
and
layer
2
overlays,
both
with
eid,
mobility
with
respect
to
layer,
3
overlays.
The
the
draft
mostly
focuses
on
mobility.
I
mean
it
provides
some
forwarding
descriptions,
but
but
the
most
important
part
is
what
to
do
with
mobility
and
with
respect
to
layer,
two
overlays
it.
It
goes
over
everything
right,
the
unicast
and
multi-destination
non-ip
and
ip
inter-subnet.
B
As
I
was
saying
right,
the
the
idea
there
with
mobility
is,
it
has
registered
prefixes
that
are
locally
attached
eads
it
considers
locally
attached
to
the
ids.
B
Then
it
describes
how
to
support
traffic
between
sites
again
here
all
the
rules
are
already
described
in
the
rfc,
but
then
it
puts
the
focus
on
on
what
to
do
when
eids
change
location
and
if
you
want
an
important
part
here-
is
what
to
how
to
update
the
the
network
when,
when
these
changes
happen,
right
and
and
it
proposes
two
methods-
one
is
data-driven,
smart
and
and
the
other
or
pops
out
notifies
okay
next
slide,
please.
B
So
the
next
three
slides
try
to
illustrate
this
with
a
picture
what
to
do
with
l3,
overlays
and
mobility.
B
The
picture
starts
with
what
we
already
know.
Let's
say
we
have
multiple
sides
and
we
have
two
endpoints:
let's
call
it
a
and
b
and
point
a
is
connected
to
side
a
and
point
b
is
connected
to
set
b
and,
and
they
are
talking
to
each
other
right.
So
essentially,
what
we
will
have
is
the
xtr
on
each
one
of
the
sides
register
these
locally
connected
prefixes.
B
These
two
prefixes
will
be
registered
with
the
mapping
system
and
then,
when
a
is
trying
to
send
traffic
to
v
the
xtr
on
on
site,
a
will
have
resolved
a
map
cache
with
for
for
b
with
the
r
log
of
of
side
b.
But
this
is
basically
now
nothing
new
here
next
slide.
Please.
B
And
and
now
we
go
and
what
happens
when,
when
a
prefix
moves,
so
let's
assume
now
here
that
b,
moves
to
from
side
b
to
side
c
now,
side
c,
what
will
happen
first,
it
will
detect
the
presence
of
of
these
endpoint
and
and
the
xtr
or
the
etr
on
on
this
side
will
now
send
a
new
registration
to
the
mapping
system,
updating
the
vr
log
or
the
location
of
of
these
this
node.
B
Now
what
the
document
proposes
or
describes
is
that
the
mapping
system
must
send
a
map
notify
to
the
old
location,
the
the
the
previous
etr
that
registered
this
prefix,
and
when
this
xtr
or
etr
receives
this
magnify,
it
will
create
what
the
document
calls
an
away
entry
that
it's
basically
a
local
registry
that
hosts
or
an
eid
that
was
locally
present
at
the
atr.
Now
it's
not
there
anymore.
B
B
B
B
Traffic
will
will
be
sent,
for
example,
in
this
case,
from
xtr
inside
a
to
steal,
etr
in
in
side
b.
Now,
when
site
b,
the
xtr
receives
this
traffic,
it
will
see
that
it's
destined
to
knee
id
that
it's
it's
in
the
away
end.
So
as
a
reaction
to
this
or
or
to
this
discovery,
what
what
this
site
will
do
is
send
an
data
driven
smr
to
to
the
original
side.
B
Basically,
this
smart
is
telling
the
other
side
hey
you're,
sending
traffic
to
wrong
location
and,
and
following
this
smr,
the
original
site
will
will
refresh
its
its
mapping.
Entry
will
start
a
map
resolution
process
with
a
mapping
system
and
and
find
the
new
location
of
of
the
host
or
the
id
and
start
encapsulating
to
the
new
location.
B
The
second
option
is
take
advantage
of
the
procedures
described
in
the
pops
up
drafts
and
and
whenever
a
site
learns,
a
map
cache
also
subscribes
for
it,
so
the
mapping
system
will
send
I'm
notified
as
a
publication,
an
update
to
all
the
sites
that
that
that
have
this
stalemate
guys.
B
Okay,
next
slide,
please.
B
B
When
it
comes
to
layer,
2
overlays,
the
draft
goes
a
bit
more
specific
and,
and
it
talks
about
what
needs
to
be
registered,
what
it's
all
about
right
and-
and
it
started
by
saying-
okay-
either-
is
in
l2,
overlays
or
mac
addresses,
as
you
all
know,
but
then
what
the
document
proposes
is
that,
in
order
to
separate
or
keep
layer,
2
and
l3
separate
in
in
the
network,
we
dedicate
a
specific
instance
like
this
for
for
l2
and
l3
purposes.
B
B
Then
what
the
document
goes
is
into
talking
about:
how
do
we
do
unicast
traffic
handling,
yeah
bomb
traffic
handling,
rv
and
nd
support
and
mobility
support
and,
and
the
next
slides
go
a
little
bit
more
on
detail
about
these
things
next
slide.
Please.
B
So
first
mobility,
mobility
with
l2
as
described
in
the
document,
is
no
different
from
what
we
do
with
l3
right.
So
the
idea
is
that,
in
in
this
case,
mags
are
moving
within
a
broadcast
domain
or
xtr
is
connected
to
common
broadcast
domain,
but
but
the
concept
of
mobility
is
exactly
the
same
right
and
the
way
we
update
web
caches.
B
B
The
document
document
reports
two
possible
approaches
to
these
when
multicast
underlay
is
supported
in.
In
that
case,
all
participants
must
join
a
common
group.
This
common
underlay
group,
let's
say
multicast
group
and
and
this
multicast
group-
will
be
associated
to
the
particular
instance
id
that
they
are
participating
in
when
multicast
underlay
is
not
available.
B
Then
this
document
takes
advantage
of
the
signal-free
multicast
target
and
and
proposes
that
all
the
members
register
to
a
very
specific
group
right
as
for
zero
and
and
the
group
is
and
group
all
ones,
okay
and
and
the
same
right
following
the
rfc.
The
map,
server
and
and
the
participants
will
will
compile
a
list
of
all
the
participants
that
so,
whenever
there
is
traffic
that
needs
to
be
broadcasted,
it
will
be,
it
can
be
replicated
to
all
of
them
next
slide.
Please.
B
Okay,
there's
one
specific
thing
in
in
l2
overlays
is
that
normally
arv
and
nd
traffic
are
represent
a
lot
of
traffic
in
the
network.
So
one
thing
that
we
normally
want
to
do
is
limit
the
amount
of
this
traffic
that
that
floods,
the
network-
and
this
is
something
that
we
can
also
deal
with
with
with
lisp,
okay
and
in
this
particular
sense,
what
the
draft
proposes
is
that
we
dedicate
one
instance
id
to
to
to
these
mappings.
B
The
idea
here
is
that
xtrs
can
register
with
a
mapping
system
pairs
of
ip
addresses.
We
consider
the
ids
to
our
logs
mac
addresses,
so
whenever
an
xtr
wants
to
resolve
one
ip
to
mac
binding
instead
of
running
the
network,
what
you
can
do
is
just
query
the
mapping
system
and
try
to
gather
this
information.
B
This
is
still
work
in
progress,
but
this
was
one
one
of
the
last
remaining
eating
items
that
we
discussed
in
the
group
that
was
needed
for
for
the
document.
The
idea
is:
how
do
we
provide
multi-homing
services?
One
discussion
that
I'll
open
to
to
the
group
is
that
we're?
Having
is
whether
this
is
something
that
we
want
to
to
document
in
in
the
draft,
or
we
want
to
keep
for
a
separate
document:
okay,
but
but
yeah.
B
Let
me
talk
about
how
we
are
approaching
this,
and
but
again
we
are
still
experimenting
with
this
and
seeing
if,
if
this
works,
the
proposal
so
far
is
that
we
use
an
id
to
to
identify
a
segment
that
is
multi-homed
with
with
multiple
xtrs,
okay
and-
and
the
idea
here
is
that
all
xtr
that
are
part
of
this
l2
multi-homing
group
register
this
segment
id
with
the
mapping
system
with
with
two
specific
flags
right,
the
one
they
always
use.
B
The
merge
request
bit
so
that
through
merge
semantics,
the
the
map
server
consolidate,
consolidates
a
list
of
our
logs
belonging
to
this
group,
and
they
all
also
set
the
one
magnify
bit
so
that
all
xtrs
are
notified
with
our
log
list
that
the
map
server
is
is
compiling
with
this.
We
achieve
two
things
right,
for
example
when,
when,
when
we
need
it
right
and
and
and
a
designated
firmware,
that
needs
to
be
selected
for
this
group.
B
The
the
map
server
can
choose
one
out
of
the
consolidated
list
right
instead
of
having
to
implement
that
distributed
algorithm
between
xtrs
to
to
make
sure
that
they
all
choose
the
same.
B
For
example,
when
we
need
to
apply
split
horizon
the
same
right
based
on
on
these
map,
notifies
all
xtr's
men
know
all
the
other
participating
str's.
So
they
can,
they
can
apply
it.
They
have
the
knowledge
to
apply
this
okay
next
slide.
Please.
B
Some
other
documents
call
it
aliasing.
We
still
need
to
decide
if
this
name
makes
sense
here,
but
but
the
basic
idea
here
is
that,
when
multiple
xtrs
are
participating
in
in
one
of
these
groups,
they
register
eith,
with
with
an
additional
attribute
that
is
this
segment
id
and
and
then
we
we
use
pops
up
procedures
as
as
described
in
the
drafts,
so
that
members
of
the
group
they
are
all
notified
about
yeah
these
that
are
detected
by
other
members
of
of
that
group.
B
A
I
I
have
a
couple
of
just
for
the
clarification,
so
so
you
you
basically
use
the
instance
id
in
order
to
distinguish
distinguish
between
l3
and
l2
overlays.
Basically,
right.
B
A
B
Is
that
yes,
yes
exactly
so,
basically
at
least
how
we
support
it
is
in
configuration
you
go
and,
and
you
start
defining
instance
ids
and
then
you
say:
okay,
you
locally
on
the
router.
Normally
what
you
do
is
you
bind
an
instance
id
to
a
vrf
or
to
to
to
a
vlan
right
and
that's
the
way
the
router
knows
right,
whether
to
link
it
to
an
l3
domain
or
an
l2
domain
in.
C
A
Headers
that
could
be
used
to
to
to
yeah
to
encapsulate
and.
A
Use
different
l2
l3
other
things
inside
basically.
B
B
Actually,
interestingly,
with
vxlan
header
right-
and
I
mean
you
need
an
and
a
header
that
is
able
to
encapsulate
l2
and
l3
and
also
segment
right,
that's
that's
where
the
instant
id
part
comes
into
play.
A
And
just
last
two
things
is
so.
A
But
I
mean
this
is
just
personal
opinion
I
mean,
and
instead,
as
a
chair,
I
have
to
say
that
you
should
revise
the
the
document
in
the
sense
that
I
just
skimmed
through
it
and
it's
based
on
the
old
rfcs.
A
So
so
he
is
good
to
update
to
the
beast
document
and
make
sure
that
he's
coherent
with
the
set
of
documents
that
we
have
now
I
didn't
check,
but
maybe
also
because
lispsec
is
mandatory
to
implement,
maybe
think
about
what
if
there
is
any
implication
or
whatsoever
on
that
side.
On
the
lip
side,
okay,
okay,.
B
Okay,
these
are
good
points,
yeah
yeah,
to
be
honest,
since
the
draft
has
not
changed
much,
we
haven't
been
paying
enough
attention
to
this,
but
I'll
I'll
make
sure
that
that
we
are
good.
Thank
you.
A
Okay,
so
let
me
stop
sharing
this
one
and
we'll
go
to
the
other
one.
That
should
be
this
pvpn.
B
This
is
the
other
draft
that
it's
a
working
group
item
and
and
the
same
that
we
said
before
right.
This
is
extensively
used
in
practice
and
and
we'd
like
to
bring
by
the
discussion
on
these
drafts
and
make
sure
that
they
move
forward
next
slide,
please,
okay,
so
this
code
of
this
drive
is
all
about
segmentation
right
segmentation,
in
particular
of
of
the
iv
space,
and
it
talks
about
how
to
use
instance,
ids
and
extended
tids
right
doubles,
of
instance,
ideas
and
aps
to
to
to
segment
our
our
network
right
it.
B
B
The
document
also
includes
some
considerations
on
segmenting
the
art
lock
space.
From
the
perspective
of
the
document,
most
of
the
the
the
attention
is
on
eith
space.
The
the
segmentation
of
the
airlock
space
is
can
be
considered
more
as
an
opportunity
right
and
how
to
deal
with
it.
But
the
important
part
is:
is
the
id
space
next
slide?
Please?
B
Now
the
document
proposes
a
particular
encoding
for
home
ids,
and
this
this
is
relevant
for
extranets,
right
and-
and
this
is
the
encoding
right.
At
least
we
first
item
that
says
this
is
the
home
id
and
the
second
item,
it's
just
the
alcav
type
2
with
with
the
instance
id
value.
B
Okay
next
is
like
please,
okay,
the
the
next
slides
try
to
go
again
a
bit
through
packet
flows
here,
I'll
describe
them
very
briefly,
not
to
go
too
much
into
detail,
but
the
the
basic
idea
when
we
want
to
provide
segmentation
is
that
we
do
iid
scope,
registrations
and
and
resolutions
right
and
yes,
luigi
was
saying
right.
This
in
some
sense
applies
also
to
to
what
we
were
saying
for
l2
and
l3
right.
So
the
idea
is
that
now
we
scope
everything
within
the
context
of
an
instance
id
wait.
B
What
do
we
mean
by
scoping
is,
for
example,
if
we
focus
in
the
map
registration,
let's
say
that
our
network
is
organized
so
that
we
have
a
couple
of
instance,
ids
and,
and
we
have
endpoints
associated
to
each
one
of
these
instance
id
locally
on
on
each
side.
This
instant
id
can
be
translated.
What
we
were
saying
to
a
vrs
to
a
vlan
or
whatever
we
we
decided
associated
with
the
idea
is
okay.
Now
we
have
an
endpoint,
for
example.
B
In
this
picture,
side
v
will
have
an
endpoint,
let's
call
it
endpoint
b,
that
is
associated
to
instance,
id1
and
and
decide
we'll
register
these
with
the
mapping
system.
We
using
these
extended
eid
right
extended.
The
ids
is
nothing
else
than
registering
as
an
eid,
the
tuple
instance
id
plus
plus
the
eid
and
and
this
will
register
with
the
associated
data
of
the
set.
B
Now,
if
we
turn
to
map
resolution
site
the
same
right,
we
make
use
of
these
instance
id.
So
let's
say
that
endpoint,
a
in
instance,
id1
wants
to
talk
to
endpoint
b
means
id1,
so
so
what
it
will
do
is
when
this
traffic
hits
the
xdr.
The
xtr
will
also
use
this
extended
eid
to
to
express
interest
for,
for,
for
that
particular
destination
right
and
and
the
same
extent
that
the
id
in
this
case
is
instant,
id1
and
and
the
destination
eid
once
map
resolution
completes.
B
All
these
is
stored
also
using
the
segmentation
in
in
forwarding,
let's
say,
or
in
the
cache
and
and
again
right
there,
using
this,
this
tuffle,
or
instance,
ids
and
id,
and-
and
this
is
the
basis
of
the
whole
segmentation
when
traffic
is
forwarded.
We
do
the
same
right
as
we
were
talking
before
on
the
header
of
the
forwarding
of
the
encapsulated
packet.
We
will
stump
the
instant
id,
so
the
the
egress
node,
the
etr
knows
which
segment
this
this
traffic
is
associated
with.
B
Okay,
next
is
likely
extranets
work
a
little
bit
different
here,
but
basically
the
idea
is
okay.
What
if
we
want
to
allow
traffic
to
to
cross
segment
boundaries?
Okay,
so
the
idea
here
is
that
okay,
it
all
starts
extranet,
assuming
that
we
have
a
policy
in
the
network
that
says
okay.
Traffic
from
this
instance,
id
can
be
leaked
into
this
other
instant
id.
B
How
this
is
structured
following
the
document
is
that
the
etr
will
always
have
this
policy
right
and
and,
for
example,
using
the
the
example
in
in
the
picture.
We
have
a
site
v
that
sorry
we
have
a
side
v
that,
for
example,
locally
connected.
It's
only
spawning
instance
id3,
okay,
but
it
has
a
local
policy
saying:
okay,
you
have
to
allow
traffic
from
instant
id
1
and
instant
id
2
to
to
reach
your
destinations,
in
instance,
ac.
In
order
to
do
this,
the
xtr,
what
it
will
do
is
is
replicate
the
registration.
B
With
with
extended
eid,
let's
say
3v,
but
but
now
in
all
other
instances
right,
so
what
what
it
will
do
is
is
replicate
this
registration
we've
extended
the
ids
of
all
the
target
instance
ids
that
it
won't.
It
wants
to
allow
to
communicate
with
with
this
knot,
something
that
is
particular
about
this
registration
is
that
it
carries
the
value
of
the
destination
instance
id
in
this
case
three
as
an
additional
attribute
of
the
registration,
and
this
is
what
the
draft
calls
as
home
id
now.
B
B
The
same
traffic
will
hit
the
itr
on
site
a
and
but
this
traffic
is
coming
in
instant
id1
right.
So
at
that
point,
this
xtr
uses
the
vpn
methods
to
to
resolve
destination
and
we'll
send
this.
B
This
map
request,
let's
say
with
ins
the
extended
id
one
b
right,
because
at
this
point
this
idr
doesn't
know
that
this
is
an
external.
As
a
reply
to
these
map
requests,
the
the
the
mapping
carries
this
home
id,
and
this
is
installed
into
the
map.
Cache.
Okay-
and
this
is
the
important
part
yeah
with
respect
to
the
streamers
now,
traffic
will
be
encapsulated
with
the
destination
instance
id
right.
B
So
traffic
send
on
side
one
instant
id
one
will
be
encapsulated
with
instance,
id3
right,
so
that
when
side
v
receives
this
traffic
directly
delivers
to
the
end
point
in
the
appropriate
vrf
or
vlan,
or
the
proper
segment.
B
B
In
this
case,
everything
more
or
less
works
the
same
with
one
mine
or
not,
is
well
not
minor.
But
an
important
note
is
that,
well,
let
me
go
through
the
flow
and
maybe
can
can
explain
the
difference
at
the
end,
so
the
same
as
before.
Right,
if
we
start
from
the
destination
sides,
the
destination
sides
now
what
what
they
will
do
is:
oh
they
they
see
some
local
nodes
joining
a
particular
group
or
expressing
interest
for
for
a
particular
group,
because
they
have
this
extranet
policy.
B
What
they
will
do
is
register
this
interest
in
the
multiple
instance.
Id
is
that
that
the
policy
is
saying
that
that
they
should
replicate
this
registration?
Okay
and-
and
this
is
what's
happening
in
this
crowd
right,
so
receivers,
bnn
or
or
are
expressing
interest
in
in
in
having
traffic
from
source
a
to
one
particular
group
b,
we
deliver
to
them.
B
Okay,
now
the
important
thing
or
the
important
difference
here
is
that
when
site,
a
in
this
picture
tries
to
resolve
the
list
of
our
logs
that
it
needs
to
replicate
to
it
will
receive
these
replic.
This
list
that
has
been
learned
through
through
signal
field
procedures.
Okay,
now
this
reply
also
carries
this
home
home
ids,
but
replicating
to
every
destination
instance.
Id
would
be
a
bit
prohibitive
in
terms
of
cost
right
at
the
sending
site.
B
So
so,
in
this
case,
what
changes
with
multicast
and
external
is
that
the
source
will
still
encapsulate
with
the
source
iid
to
destinations
and,
and
it
will
be
the
egrecides,
the
etrs
and
the
sites
to
to
decide
to
do
this
conversion
between
instant
id
right
so
that
they
will
re
receiving
traffic
from
from
instant
id1
in
this
case
and
and
they
will
be
the
responsible
to
locally
replicate
to
to
the
corresponding
instance
ids.
B
We've
been
using
it
in
practical
deployment,
yeah
most
of
the
procedures
here
and,
and
the
only
last
addition
that
I
could
find
with
with
respect
to
the
draft
is
that
it.
It
included
some
considerations
on
how
to
calculate
negative
map
replies
when
when
we
are
using
extranet,
okay
and
and
in
order
to
include
the
home
id
in
in
this
replies,
but
but
yeah,
it's
a
minor
note
in
the
draft
so
that
the
rest
of
the
contents
haven't
changed
so
much
next,
slightly.
B
And
as
I
as
we
were
saying
right,
so
the
vpn's
really
constitutes
the
basis
for
everything
that
we're
doing
these
days
for
segmentation
and
extracts,
and
the
solution
has
been
out
in
the
field
code
is
stable,
yeah,
it's
it's!
It's
been
validated
quite
a
bit
right,
so
the
authors
would
like
to
request
a
possible
write.
The
working
group
to
to
make
a
last
call
for
this
document
since.
A
No
comments,
always
we
can
leave
this
one.
So
before
going
to
the
last
call
question:
are
there
any
questions
from
the
audience.
A
Let
me
switch
between
so
here
you
say:
afi
is
a
distinguished
name
and
I
look
to
the
document.
It's
a
distinguished
name
type
but
then
doesn't
seem
to
be
defined
anywhere.
B
I
think
we
use
17
right
for
for
distinguished
names.
A
But
this
refers
to
the
dinos
draft
about
distinguished
names.
D
Okay,
if
you're
going
to
use
distinguished
names,
then
you're
going
to
need
to
put
in
text
about
how
they
are
distinguished
what
keeps
them
separate,
because
your
example
is
just
an
arbitrary
name
that
seems
to
imply
that
they're
going
to
collide
in
the
mapping
system.
That's
not
good,
but
if
you
can
keep
them
separate,
then
specify
how
okay,
okay.
A
I
will
also
start
putting
the
document
in
the
reference,
because
it's
not
in
the
reference
list
and
again
update
them
because
look
if
you
go
on
here,
you
still
have
a
reference
to
rfc
6833.
A
I
had
another
question
here
in
the
the
extranet
I
mean
you
show
how
how
it
goes
in
one
direction.
I
kind
of
understand
how
it
will
go
also
in
the
other
direction.
What
if
there
is
any
mismatch
to
you,
do
you
discuss
that.
A
Yeah
that
that,
by
some
reason
you
you
you
do
not
encode,
you
did
not
encode
all
the
ids
or
something
this
can
happen.
When
you
do
an
update
or
something
you
see.
Yes,
did
you
discuss.
B
A
I
think
the
problem
is
similar
to
when
you
have
several
xtrs
and
then
you
want
to
update
the
mapping
is
just
up
to
the
let's
say
to
the
operator
to
make
sure
that
you
up
update
all
the
extras
at
the
same
time
in
a
certain
way,
so
that
the
mapping
is
coherent
and
you.
You
should
know
that
the
issue
is
not
the
case.
You
have
trouble,
so
you.
B
D
I
just
went
and
looked
at
the
draft.
The
use
you're
making
of
the
name
would
make
me
very
nervous,
please
think
very
carefully
about
it,
a
you're,
creating
a
dependence
on
a
document
that
is
not
yet
working
group
adopted
and
b.
What
you
actually
say
is
that
the
name
provides
semantics
names,
don't
provide
semantics,
so
be
very
careful
about
whether
the
name
is
really
what
you
want
for
this.
B
B
A
A
We
still
have
the
bottleneck
lispsec,
but,
and
we
need
a
revised
version
of
this
document,
because
there
is
a
couple
of
of
things
to
to
to
update
and
fix.
I
guess:
okay,
okay,
okay,
unless
there
are
other
question
or
comments,
I
will
switch
to
your
last
presentation.
B
Yeah
the
last
presentation:
I
probably
said
that
I
let
others
talk
the
the
the
same
right.
None
of
the
others
could
be
here
today,
but
I'm
presenting
on
their
behalf,
but
again
the
these.
B
This
is
kind
we
we
have
yeah
vested
interest
in
in
these
drafts
and
you'll
see.
You
know
at
the
end
I'll
make
another
call
to
to
make
it
a
working
group
document
and-
and
the
reason
we
have
this
interest
is
because
we
have
been
using
these
in
in
practice,
and
it
has
we've
gotten
a
lot
of
benefits
out
of
using
these
these
procedures
here
and
so
I'll
go
through
them
and
give
some
background
on
what
we
have
been
doing
and
and
and
yeah.
Let's.
B
B
So
just
some
background,
the
map
server,
reliable
transfer
is
is,
as
I
was
saying,
extensively
used
in
okay.
Let's
say
our
deployment
right,
the
the
reason
we
have
these
is
because,
when,
when
we
start
experimenting
with
it,
it
showed
very
quick
benefits
to
scale
the
least
deployments,
and-
and
we
consider
that
it's
been
key
to
support
operation
at
scale
for
for
very
large
users
right.
B
So
this
is
true
when
we
have,
for
example,
a
large
number
of
vids
or
or
when
we
have
mobility,
that
what
we
were
discussed
describing
in
the
first
draft
at
large
scale
and
and
also,
for
example,
when
we
try
to
plug
lisp
systems
with
other
systems,
and
we
need
to
do
redistribution
of
database
mappings.
B
This
also
provides
some
stability
at
scale
in
practical
terms,
since
the
draft
proposes
message
reuse
for
many
things
it,
it
was
ideally
implemented
as
an
extension
of
the
registration
process
that
that
it's
well
documented
in
the
in
the
rfc.
Okay.
B
B
So,
as
you
always
know,
no
well
sorry,
the
what
we
use
originally
or
at
least
uses
by
default
is:
is
this
periodic
udp
communication
between
the
xtr
and
the
map
server
to,
and
this
is
to
maintain
some
soft
state
right
between
these
two
entities
in
the
network,
but
yeah
when
doing
experimentation,
especially
at
scale?
We
had
some
right.
B
There
were
some
practical
concerns
on
how
to
do
this
right
and
especially
yeah
when
we
are
handling
a
large
number
of
eid
records
or
when
we
have
to
do
redistribution,
mobility
and
and
something
that,
for
example,
you
can
see
very
quickly
is
that
this
constant
communication
creates
some
load
on
on
the
control
plane
and
and,
for
example,
if
you
start
attaching
thousands
of
records
to
each
xtr
this
this
means
a
lot
of
traffic
and
another
area
of
concern
was
this
lack
of
flow
control
right
between
when,
when
xtrs
and
and
map
servers
span,
multiple
network,
hogs
and
and
our
network
grows
right.
B
So,
what's
reliable
transfer,
so
the
the
what
what
the
document
provides
proposes
is
to
establish
a
tcv
or
http
or
to
be
honest,
any
session
that
it's
considered
reliable
in
some
sense
between
the
xtr
and
the
map,
server
right
and
and
then
use
this
reliable
session
to
communicate
the
id
to
our
lock,
mappings
right
and
also
mapping
notifications
back
from
the
the
map
server
to
the
xtr.
B
The
document
proposes
these
always
a
as
an
optional
alternative
to
udp,
phase,
registration,
right
and
so
udp
mechanism
must
be
supported.
This
is
not
trying
to
replace
anything,
but
but
it's
always
an
alternative
that
that
can
be
used
if
available
next
slide,
please
so
the
next
three
slides
try
to
put
picture
and
how
how
the
operation
proposed
it's
meant
to
work
right.
So
the
idea
would
be
something
like
you
have.
The
etr,
the
map,
server
and
and
dtr
starts
with
the
usual
periodic
udp
registration
with
the
mapping
system.
B
B
B
So
once
this
happens,
let's
say
now:
we
have
a
tcp
session
available.
What
the
map
server
will
do
is
send
the
registration
refresh
message
to
the
idea
right.
What
this
resistation
refresh
message
does
is
is
trigger
ddr
to
send
a
new
refresh
registration
of
everything
that
it
has
in
its
local
database.
B
But
the
important
thing
comes
from
here.
Right
from
that
instance,
all
these
registrations
are
considered
active
as
long
as
the
session
is
up,
so
in
some
sense
we
we
link
the
phase
of
the
registrations
to
to
the
state
of
of
this
session
between
the
map
server
and
the
etr,
and
thanks
to
these,
these
registrations
don't
need
to
be
resent
periodically
anymore
next
level.
B
Okay
and
and
the
registration
refresh
message
is-
is
actually
used
as
a
way
so
that
the
map
server
can
notify
the
ttr
that
hey
things
have
have
changed.
For
example,
now
the
policy
that
rejected
your
registration
is
not
there
anymore
and-
and
you
can
try
again
to
send
me
these
registrations
one.
This
is
one
of
the
last
additions
that
was
made
to
the
document
is
that
these
resistation
refresh
messages
can
can
be
scoped
right,
so
the
map
server
can
specify.
I
want
I.
B
I
would
like
you
to
refresh
everything
that
you
have
only
what
you
have
in
this
instance
id
or
or
just
send
me
this
specific
prefix
that
that,
for
some
reason
I
lost
state
for
it.
Okay
next
slide,
please
yeah
from
here
the
rest
of
the
slides
is
that
what
I
described
was
the
basic
idea
behind
the
draft
right.
What
the
next
slides
go
is
just
okay,
which
are
the
specific
details
behind
all
these,
for
example
right
with
respect
to
registrations,
reliable
registrations
or
our
messages
are
exactly
the
same
as
udp
registration.
B
B
One
interesting
thing
is
that,
if
you
think
from
from
a
reliable
transfer
perspective
mapping,
notifications
are
actually
not
needed
anymore,
unless
there's
there's
information
to
be
conveyed
from
the
map
server
to
to
the
xtr
right.
For
example,
if
we
use
merge
semantics
maven
notifications
would
be
needed
right
or
or,
for
example,
for
mobility.
My.
C
B
Map
server,
operation,
yeah,
repeating
more
or
less
the
same,
but
but
important
things
here
is
that
now
receive
registrations
are,
are
used
to
create,
update
or
delete
state.
So
there
is
no
timeout
anymore
on
the
mapping
system.
As
long
as
the
session
is
up,
the
registrations
stay
so
on.
On
the
other
side,
what
this
means
is
that
the
xtr
needs
to
explicitly
delete
mappings
to
get
them
removed
from
the
mapping
system.
B
Another
interesting
thing
that
the
document
provides
is
that
registration
state
is
not
the
start
discarded
when
the
session
goes
down.
So
basically,
if,
let's
say
the
session
goes
down,
what
the
map
server
does
is
is
fall
back
into
timer-based
mode
of
operation.
So
all
the
registrations
are
it
activates,
a
timer
to
to
let
them
expire,
as
as
they
would
in
the
udp
model.
B
Okay,
and
these
users,
registrations
can
be
rejected
for
a
number
of
reasons,
but
mostly
is
either
either
authentication
or
or
policy
of
configuration
limitation
threat
and
and
what
we
described
in
in
the
flow
right.
The
the
registration
refresh
message
is
basically
used
as
a
is
a
tool
that
the
map
server
now
has
to
obtain
initial
state
or
request
a
specific
refi
registrations
when,
when
something
changes
in
its
configuration,
its
policy,
its
status.
B
From
an
etr
operation
perspective,
okay,
the
the
the
document
provides
a
tail
state
machine
and
transitions
between
states.
But
the
important
thing
to
to
remark
here
is
that
what
we
have
been
repeating
right,
the
the
idea
is
ddr-
starts
in
udp
registration
mode.
Now,
if
a
session
is
possible,
the
etr
will
try
to
switch
to
to
reliable
transfer
mode,
and
but
this
won't
complete
until
the
map
server
sends
this
registration
refresh
right.
That's
the
that's.
B
Some
implementation
nodes,
as
as
we
were
saying
right,
we
have
vested
internet
in
this
because
we've
had
code
running
and
very
stable
for
a
long
time
and-
and
it
has
been
very,
very
effective
to
to
support
large
deployments.
One
important
implementation
node
is
that
since
we
reuse
messaging,
all
these
was
implemented
as
a
okay.
Let's
call
it
minor
extension
to
to
to
the
registration
process
right
so
that
it
could
run
over
over
tcp
and-
and,
as
I
was
saying
before,
right,
this
doesn't
need
to
be
linked
to
tcp
ctv
right.
B
B
A
I
would
go
for
a
no,
but
there
are
two
two
small
questions.
Yeah
you
say
we
we
always
start
a
registration
with
with
udp
and
then,
when
there
is
a
session
up,
then
I
I
switch
to
the
other.
Now
to
me,
it's
not
clear
how
we
understand
that
we
can
set
up
a
session.
B
So
what
we
do-
and
now
we
are
talking
about
our
implementation-
I
guess
we
could
all
do
different,
but
what
we
do
today
is
we
use
the
we
send
the
the
the
etr.
We
will
send
the
map
register
we'll
set
the
one
mum
notify.
Okay,
when
it
receives
the
mum
notify
it
understands
that
it
can
try
to
to
establish
a
tcp
session
right.
It
understands
that
okay,
I've
been
because
my
registration
is
authenticated.
B
C
A
A
Other
methods
are
out
of
the
scope
of
this
document.
At
least
you
have
a
basic
thing
that
says
how
you
you
go
from
one
to
the
other
I
mean
because
otherwise
it
reminds
remains
to
me
a
little
bit
fuzzy,
because
I,
if
I
read
the
document
that
I
said,
oh
you,
you
can
go
from
this
to
that
and
I
have
to
implement
it.
I
will
scratch
my
hands
and
yeah
yes.
But
what
is
this.
C
A
If
we
move
this
document
forward,
chances
are
that
that
security
review
will
come
back
to
us
and
say
this
system
is
not
secure,
so
I
would
suggest
to
look
at
how
lispsec
applies
or
to
to
to
this
system,
or
you
say
I
don't
know
you
set
up
a
session
and
I
put
up
tls
or
in
quick.
You
use
a
quick
security,
I
don't
know,
but
just
authenticating
the
other
side
I
share.
That
is
not
enough.
Then.
Obviously
other
people
can
can
have
a
different
opinion,
but
okay.
A
A
C
A
A
A
There
are
few
updates
that
that
you
can
do
to
this
document
again
on
a
personal
side.
No,
no!
No!
Chair
head.
I
like
the
document,
because
I
I
think
that,
with
a
reliable
transport,
you
can
do
a
few
interesting
things
on
the
map
registration
and
on
the
mapping
system.
Basically,
so
I
I
like
the
work.
Basically,
as
a
chair,
I
told
you
my
my
concerns
and
yeah.
A
I
think
the
trust
should
be
revised
and
I
don't
know
if
it's
clear
but
the
priorities
lisp
sec,
so
because
you
you,
the
co-authors
of
this
set
of
documents,
overlap
with
the
authors
of
lispsack.
You
can
deliver
the
message
that,
as
soon
as
we
are
done
with
one,
we
can
move
the
others.
A
A
B
A
A
E
See
I
will
thank
you.
I
will
jointly
present
with
the
aviv
haskell
we're
presenting
here
list
fix.
This
is
a
second
example
of
using
the
existing
lisp,
rfcs
and
mechanism
established
for
a
use.
E
E
Here
we
are
still
we
just
prototyped
this
thing
and
we
are
gathering
inputs
for
draft
zero.
Zero.
E
E
E
Okay,
another
pre
note
is
that
the
qualities
of
using
lisp
the
formal
specification,
the
breadth
of
the
rfcs,
the
multi-vendor
interoperability,
are
becoming
clearer
to
stakeholders
in
each
domain,
for
example
in
vehicles
or
in
cyber
as
time
goes
by,
and
they
see
how
this
basis
has
more
benefits
than
initially
was
anticipated,
so
specifically
for
ipfix.
E
So
this
a
proposal
has
to
do
with
a
change
in
the
traditional
role
of
ipfix.
If
we,
if
we
thought
of
ipfix
as
some
kind
of
built-in
wireshark
to
log
and
debug
the
network,
it's
now
becoming
a
critical
sampling
tool
for
networks,
so
uniform
sampling
with
ai
outperforms,
a
probing
with
ai
which
outperforms
probing
we're
using
traditional
rule-based
systems.
So
we
know
that
now,
based
on
research.
This
is
a
domain
which
aviv
is
expert
on.
So
I
would
let
him
explain
explain
in
more
in
depth.
Why
is
that
the
case.
E
But
and
of
course
something
is
a
lot
simpler
to
deploy
than
probing
putting
something
in
line
or
pushing
agents
to
various
points
in
the
network.
So
sampling
is,
is
outperforms
and
it's
much
easier
than
anything
else,
but
the
catch
here
is
uniform
sampling,
so
uniform
sampling
of
a
small
sites.
The
like
hospital
school
district
is
very
easy.
You
just
ip
fix
the
firewall
and
the
core
switch,
but
uniform
sampling
of
a
large
virtualized
environment
is
difficult
and
at
least
can
solve
that
so
and
next
slide.
Please.
E
F
Thank
you
so
much.
Thank
you
for
the
intro
hello
everyone
so,
as
shown
described
just
now,
the
advances
in
network
sampling
over
the
last
years
is
incredible.
F
I
did
my
phd
research,
this
specific
problem,
how
to
infer
from
one
percent
about
the
one
hundred
percent
developed
some
regardless
mathematical
theory
about
it,
and
we
see
more
and
more
companies
in
this
field
today
in
the
stamping
field.
Specifically,
the
combination
of
sampling
and
ai
opens
many
possibilities
for
not
only
efficient
but
very
accurate
network
monitoring
and
flex
prediction
in
scale
in
any
application.
F
F
Just
usual
network
samples
arrived
in
our
auto
encoder,
the
next
step.
The
second
step
is
that
the
autoencoder
tries
to
reconstruct
what
is
the
expected
input
and
it
outputs
some
some
loss,
because
it's
not
a
perfect
construction,
of
course,
and
the
loss
is
the
deviation
between
what
was
the
input
center
and
what
was
the
autoencoder
reconstruction.
Very.
Similarly,
to
achieve
signals,
the
third
step
is
that
the
loss
is
normalized
to
one
single
statistical
distribution
across
all
different
client
networks.
F
It
found
out
that
this
approach,
the
sampling
with
normalization,
is
significantly
outperforming
the
probe
of
the
100
of
the
network,
not
only
in
terms
of
performance
but
also
in
terms
of
its
accuracy.
You
can
see
in
the
table
below
the
f1
score,
which
combines
the
recall
and
the
precision
together
the
true
positive,
false,
positive
together
and
you
can
see
a
comparison
in
column.
Three
denotes
forbes
solution
and
column.
Five.
F
You
know
it's
this
sampling
and
normalization,
and
also
in
the
first
quality,
which
is
under
the
recall,
the
second
row,
much
better
results,
so
not
only
in
lab
simulations.
This
approach
that
you
see
here
is
currently
deployed
in
hundreds
of
network
sites
with
radically
different
network
environments
in
volumes,
sizes
and
architectures.
F
However,
in
all
of
these
deployments,
in
order
to
do
the
uniform
sampling,
we
can
do
it
very
simply.
We
just
need
to
activate
the
standard
ipfix
in
one
core
switch
one
firewall,
because
the
sites
are
very
small,
but
when
we
go
to
a
bigger
virtualized,
multi-talent
environments,
we
need
a
better
way
to
aggregate
the
standardized
fix.
In
order
to
achieve
this,
uniform
sampling.
E
All
right,
so
we
understood
sampling
is,
is
good
and
we
we
take
a
look
at
virtualized
cloud
native
environments
and
which
any
process
can
run
on
any
kubernetes
cluster
on
any
server.
E
The
network
facilitates
that
by
having
lots
of
links
between
any
iraq
to
an
iraq
probing
is
is,
is
really
not
an
option
and
these
links
are
very
high,
speed
and
and
probing
all
of
them
is
just
impossible.
E
So
what
do
we
do
so
next
slide.
E
So,
if
probing
is
not
an
option,
server
agents
increases
complexity
and
attack
surface
and
the
default
ipfix
collectors
on
the
switches
will
not
result
in
uniform
sampling
of
any
of
the
apps
running
on
the
send
on
the
on
the
data
center
environment.
We
would
like
to
introduce
a
list
specification
that
will
solve
that.
So
next
slide.
Please.
E
All
right,
so
what
we
suggest
as
a
specification
for
exporters,
ipfix
exporters
and
also
collectors
as
an
interim
step,
is
the
ability
to
steer
traffic
to
eid
collectors
which
are
logical
and
will
result
in
uniform
sampling
based
on
a
specification
of
group
membership
which
is
efficient
in
space.
E
The
the
network
aggregation
itself,
the
iphix
aggregation
can
be
provided
by
the
infrastructure
provider
and
the
eids
will
hide
the
the
equipment
form.
The
sampling
analyzers,
the
sampling
analyzer
can
be
a
cyber
provider
that
provides
a
service
to
detect
anomalies
for
the
application
anomalies
can
be
preparation
for
ransomware
trying
to
disrupt
and
trying
to
leak
information
under
an
ex
something
which
looks
like
a
kosher
exchange
all
right.
So
this
is
the
ask
appreciate
any
feedback.
E
Okay,
here
we
just
summarized:
something
is
good.
Something
in
virtuous
environment
is
hard.
Uniform
sampling
list
can
fix
that.
E
A
C
Yes,
all
right!
Thank
you.
Hey,
that's
a
very
interesting,
a
very
interesting
study
here.
I
wanted
to
ask
you
a
question
about,
as
you
are
actually
making
those
samplings,
and
I
can
see
that
you
are
actually
talking
about
reduction
of
how
much
of
sampling
is
done.
C
F
F
So
this
is
using
the
standard,
simple
protocols
and
ipfix
is
the
itf
standard
and
they're
also
the
net
flow
of
cisco
and
s
flow
standards
as
well.
F
C
E
I
I
think
the
question
is:
after
the
sampling
has
been
gathered
per
application.
The
sampling
records
are
the
high
priority
traffic
just
to
protect
the
the
the
process
of
ongoing
sampling.
So
analysis
will
be,
you
know
protected,
and
I
think
we
can
answer
that
online
and
that's
a
great
point.
A
B
E
That's
a
great
question
so
currently
you
know
it's
a
private
space
of
cyber
cfn
network,
but
that's
a
it
relates
to
your
presentation
also
mark
and
there's
about
space
conservation.
Do
we
match
a
specific
id
to
any
group
testing
or
do
we
simply
algorithmically
generate
eids
and
use.
E
E
Okay,
so
so
this
is
more
mature.
This
is
in
production
and
currently
in
deployment.
The
list
in
hexagon,
in
in
in
thousands
of
drivers
in
new
york
city
and
also
now
by
industry
consortium
in
tokyo,
that's
been
under
construction
right
now,
servers
have
been
allocated,
but
the
other
cities
in
the
us.
It's
full
production.
E
I'd
just
like
to
give
a
quick
brief
learnings
of
what
we
we
see
and
what
the
stakeholders
in
the
industry
see
from
using
lisp
for
this
mobility
in
terms
of
vehicles
use
cases
next
slide.
Please.
E
All
right,
so
what
we
achieved
using
a
lisp
is
really
take
the
full
spectrum
of
mobility
networks
which
were
very
split
between
vehicle
to
vehicle
which
are
based
on
geospatial
networks
like
in
ipy
or
dsrc
for
stuff,
which
is
immediate
and
very
transient
versus
vehicle
to
cloud
which
is
like
you
drive
for
a
couple
of
hours,
and
then
you
upload
overnight
what
you
collected
and
then
you
know
the
cloud
crunches
fresher
maps
so
using
the
hierarchy
and
the
layering
we
are
able
to
unify
using
one
architecture,
all
these
use
cases
and
also
all
the
use
cases
of
stuff
that
fell
in
between.
E
So
what
you
see
here
is
an
example
of
using
the
hierarchy
and
layering
for
a
detecting
parking,
which
is
something
that
has
to
be
done
quickly
and
previously
had
no
answer
in
v2v
or
v2
cloud.
Also,
understanding
the
cycle
of
traffic
lights
or
you
know
doing
some
kind
of
patterns
on
the
curb
activity
in
an
area.
So
all
these
things
fell
between
and
really
the
the
use
case.
Transience
is
really
determined
by
a
the
the
the
mobile
network.
How
much
do
we
have
in
terms
of
capacity?
E
What
is
the
density
and
what
is
the
latency
this?
The
this
layering
works
when,
let's
say
toyota
wants
to
find
parking
for
its
customers,
its
drivers
based
on
its
cars.
So
there
are
some
cars
of
some
toyota.
E
Cars
are
finding
parking
for
other
toyota
cars
using
a
ead
abstraction
of
of
the
geolocation
provided
by
toyota,
but
it
also
works
when,
let's
say
toyota
and
subaru
have
an
agreement
to
jointly
collect
uploads
using
an
h3eid
and
then
have
agreements
with
the
parkopedia
or
bosch
parking
services
using
other
h2ad
same
h3,
64
bits,
different
eid
and
then
parkopedia
has
an
agreement
with
the
city.
Not
only
I
mean
it
detects
parking
for
drivers,
but
it
detects
permit
violations
in
construction
for
the
city,
so
this
is
again
using
the
same
mechanisms.
E
The
same
rfc
and
you
know
people
are
seeing.
You
know
that
this
basis
is
good
to
build
on
so
next
slide.
Please.
E
All
right
so,
as
we
described
the
key
for
unifying
the
use
cases
in
one
architecture,
is
by
obstructing
the
geospatial
network
into
your
special
eid's.
E
It's
virtualized
instead
of
physical
network
and
these
geolocation
services,
they
utilize
areas
based
on
uploads,
but
that
introduces
key
issues
to
the
industry,
which
lists
answers
in
a
very
elegant
manner.
E
One
is
since
we
associate
vehicles
to
geolocation
services,
not
randomly
load
balanced,
but
based
on
where
they
are
then,
depending
on
how
much
traffic
there
is.
You
need
to
dynamically
set.
E
E
The
second
key
issue
which,
as
a
result
of
this
obstruction,
your
special
abstraction,
is
your
privacy.
It's
unlikely
that,
because
I'm
using
a
parking
service,
the
parking
provider
knows
where
exactly.
I
am
every
point
of
the
day.
So
again
here
the
eid
layering
solves
that
the
the
the
network
is
aware
of
eids.
E
E
So
I
have
ip
geoprivacy
also
because
I'm
driving
between
geolocation
areas,
I'm
switching
context
to
where
is
it-
that
I'm
subscribed
to
or
upload
to
and
that
has
to
be
seamless,
cannot
be
done
with
via
dns.
It
takes
too
long
and
again
using
eid's.
E
E
So
these
are
things
that
you
know
the
industry
begins
to
see
begins
to
see
that
it's
good,
that
it's
specified
as
a
standard
as
a
multi-vendor
standard
and
and
can
be
leveraged
in
multiple
tiers
of
the
application.
E
All
right,
so
what
we
see
is
that,
using
this
specification
and
use
of
lisp,
we
are
able
to
scale
a
crowdscale,
actually
a
processing
of
uploads
we're
using.
We
are
able
to
propagate
information
based
based
on
change
or
exception
or
anomaly,
using
a
signal-free
propagation,
and
we
are
able
to
facilitate
the
latency
because
we
pre-select
our
logs
for
h3ids
to
places
where
the
latency
from
the
ip
anchors
is
or
is
known
and
controlled.
E
So
why
is
this
important?
It's
important
because
I
mean
human
reaction
is
a
long
latency.
So
that's
not
the
point.
The
point
is
more
when
a
car
is
driving
in
20
meters
per
second,
if
I'm,
my
latency
is
high,
I'm
missing
a
lot
of
meters
and
therefore
I
can
pre-select
the
rlox
and
then
move
the
geolocation
services,
the
h3
eid
geocaching
services
based
on
a
load
of
traffic.
E
So
that's
it!
That's
the
update
it's
in
publication.
I
wonder
if
we
can
get
some
kind
of
indication
on
when
the
rfc
is
going
to
be
published,
it's
very
hard
for
industry
outside
the
itf
to
work
with
any
kind
of
draft,
so
it
would
be
good
to
know.
F
A
I
have
a
simple
one:
these
are
two
interesting
use
cases
for
lisp.
The
question
is
in
order
to
to
to
solve
these
use
cases.
Do
you
think
that
there
will
be
any
modification
or
extension
to
the
lease
protocol
per
se
or.
E
I
think
right
so
it
may
be,
but
so
far
not
so
far
the
specifications
give
enough
flexibility
I
mean.
Sometimes
you
have
to
think
what
exactly
am
I
using
and
how
before
I
mean,
how
do
I
allocate
the
ideas
as
was
asked
before,
and
you
know
how
do
I?
E
What
meaning
do
I
give
to
things
and
how
do
I
use
signal
free
to
partition
themes
and
subscriptions
and
what
does
it
mean
for
a
replication
which
xtr's
to
use
a
v-switch
or
a
you
know,
full-blown
hardware
that
that
can
do
it
can
handle
like
cities,
but
so
far
the
specification
itself
has
been
good
enough.
B
Mark
so
in
in
practice,
with
signal,
free
and
replication
have
have
you
seen
any
scalability
issues
when
deploying
this,
and
I
don't
know
if
you
have
to
replicate
to
too
many
sites.
B
E
Yeah,
that's
a
good
point,
great
point,
so
actually
for
these
networks,
where
there's
a
production,
a
lot
of
production
of
data
routed
to
somewhere
close
for
reduction
and
then
propagation
based
on
a
subscription.
Usually
it's
a
lot
of
channels
of
very
few
subscribers,
so
signal
three
is
really
good
for
them.
A
B
E
Okay,
so
here's
the
the
situation
on
the
ground
is
like
we
get
a
few,
our
locks
for
h3
services,
let's
say
from
the
oracle
cloud
from
wavelength,
and
we
know
they
all
meet
the
requirements
of
latency
between
them
and
the
mobile
carrier.
Ip
anchors,
okay,
okay,
but
it
doesn't,
it
doesn't
relate
to
where
the
car
is,
because
that,
even
though
the
car
is
moving
as
far
as
ib
anchor
is
not
moving,
it's
mostly
related
to.
E
B
A
Okay,
so
thank
you
very
much
sharon,
so
this
brings
us
at
the
end
of
of
the
presentation
that
we
had
in
the
agenda.