►
From YouTube: IETF111-LISP-20210729-1900
Description
LISP meeting session at IETF111
2021/07/29 1900
https://datatracker.ietf.org/meeting/111/proceedings/
A
So
I
think
it's
it's
time
to
start
and
so
welcome
everybody
to
the
lisp
working
group
session,
I'm
luigi
online.
We
have
virtual.
We
are
the
co-chairs
of
this
working
group.
There
is
also
patma
our
secretary
that
will
help
taking
notes
online.
You
have
the
not
well
which
you
read
during
the
registration
procedure,
my
videos
just
to
say
hello,
everybody,
and
now
I
stop
to
to
save
some
bandwidth.
Okay,.
A
The
usual
pointers,
if
you
are
connected,
you
are
aware
of
them,
I
guess,
and
just
to
to
go
quickly
through
our
agenda.
This
is
the
last
time
we
met
the
situation
in
109,
okay-
and
this
is
about
today,
so
we
don't
have
any
red
dots
anymore.
A
These
documents
are
in
the
rfc
editor
queue.
What
we
have
now
is
lisp
security.
The
chef
of
the
review
has
been
done.
The
shepherd
and
conducted
the
routers
for
basically
editorial
correction.
That
needs
to
be
done,
and
this
will
go
soon
through
the
pipe.
We
have
the
nexagon
document
as
well
he's
waiting
for
the
write-up.
I
plan
to
do
it
next
week,
so
that
we
can
push
that
forward
as
well.
I
think
we
are
pretty
close
with
the
young
model
document,
but
yeah.
A
We
will
move
it
forward
after
this
meeting.
Okay-
and
there
are
a
few
just
working
group
drafts
that
need
to
be
moved
forward.
I
guess
we
will
come
back
a
little
bit
later
on
on
the
last
presentation
on
this
point
in
the
last
couple
of
years.
A
Obviously,
we
put
a
lot
of
effort
on
the
biz
documents
now
it's
time
to
look
at
what
is
still
in
the
data
tracker
as
a
working
group
item
and
see
what
is
the
interest
from
the
working
group
and
what
should
be
done
in
order
to
move
this
island
item
forward
or
drop
them
if
there
is
no
not
interest
anymore
from
the
group.
A
So
what
we
plan
to
do
is
between
this
meeting
and
then
and
one
one
two
is
to
a
little
on
the
mailing
list
on
the
specific
documents
in
order
to
check
what
the
the
group
wants
to
do
with
with
each
and
every
document.
Okay,
this
is
the
agenda
today,
okay,
so
we
have
a
first
presentation
about
pim.
This
is
a
document.
Actually
that
is
the
which
is
part
of
the
pim
working
group.
Okay,
but
it's
good
to
have
an
idea.
A
What
is
going
on
there,
the
so
stick
should
present
it
to
to
us.
They
say:
stick
is
online
very,
very
good.
Then
we
have
a
lisp
transport
for
policy
distribution,
michael
we're,
gonna
present
it
list
fix
finally,
an
update
on
overlay,
even
if
we
don't
have
a
document.
Yet
and
mark
wants
to
to
present
a
little
bit
the
open
items
that
are
in
lisp
from
the
perspective
of
of
commercial
implementation.
A
A
I
see
in
the
in
the
in
the
chat
fabio
asking
lisp
sec
is
blocking
the
beast
document
or
they
will
proceed
in
parallel.
A
As
far
as
I
remember,
the
lisp
sec
is
blocking
only
the
console
plane
document
directly,
but
because
the
the
two
biz
documents
are
inter-independent,
they
basically
are
both
blocked.
So
as
soon
as
we
have
the
lisp
sec
pushed
forward
and
and
when
passed
the
ietf
review
blabla
until
the
rfc
then
leads
goes
to
the
rfc
editor.
Then
everything
is
unblocked.
A
A
B
Yeah
hi,
this
is
stig
here
I
have
like
an
audio
issue:
I'm
not
able
to
listen
at
the
same
time
as
I'm
talking,
it's
kind
of
half,
duplex,
so
I'll
start
presenting
and
then
I'll
pause
occasionally
to
check.
If
there
are
any
comments,
does
that
sound
okay.
A
B
Draft
that
has
been
presented
in
a
pin
working
group,
but
it's
also
lisp
related.
So
it
would
be
good
to
discuss
it
here
so
yeah
if
you
go
to
next
slide.
B
So
there
is
like
this
rfc
8059
that
describes
how
to
do
multicast
with
lisp.
B
So
there
is
a
there
was
a
draft
that
was
done
before
forget
the
rfc.
Actually,
that
is
80
59..
That
was
done
in
the
pim
working
group,
but
it
was
also
discussed
here
in
in
lisp
and
when
we
made
it
an
rfc,
it
was
basically
last
call
in
both
working
groups
and
so
on,
but
it
was
a
product
of
the
pin
working
group.
B
There
is
some
limitation
in
that
draft
that
we
want
to
to
solve
and
yeah.
Likewise,
like
with
the
previous
draft
on
rfc,
we
would
like
to
discuss
it
in
both
pin
and
lisp,
and
we
want
to
make
sure
that
it
makes
sense
from
this
perspective,
but
we
also
want
to
make
sure
that
it's
correct
from
pim
perspective,
so
from
pin
perspective,
it's
more
about
exact,
encoding
and
stuff.
Well,
this
I
feel,
like
it's
more
the
use
case,
any
comments
so
far.
B
B
So
basically,
the
the
itr
like
the
yeah
and
they
and
the
source
site
can
replicate
and
send
packets
to
each
of
the
destination
are
locks
that
need
to
get
the
packets.
B
Currently,
in
implementations,
I
know
it's
just
basically
hard
coded
or
you
have
to
configure
it
on
the
ingress.
What
groups
to
use
what
you
would
like
with
this
new
draft
is
to
have
the
receiver
xcrs
like
the
etrs
specify
which
grip
to
use
for
the
end
cap.
B
A
If
there
is
anything
that
people
ask,
they
can
raise
their
hand
and
we
will
manage
the
question.
Okay.
B
Okay,
great
so
so,
as
I
was
saying,
there
is
no
no
way
today
for
the
the
receiver
etrs
to
specify
what
what
grip
they
would
like
to
be
used
for
the
end
cap.
So
that's
what
they
want
to
solve
here.
B
So
we
have
some
use
cases
where
we
might
want
say
for
various
reasons.
You
might
want
a
particular
group
to
be
encapsulated
in
in
different
groups
in
the
in
the
core
so
so
like.
If
you
have
an
eskoma
g
in
the
like
a
multicast
source,
you
might
want
to
encapsulate
that
into
two
different
group
addresses
when
it
goes
through
the
course.
Basically,
you
know,
replicate
them
and
have
like
two
copies
of
the
packet
with
each
with
a
different
encapsulation,
or
there
could
be
cases
where
we
also
want
to
say
that
yeah.
B
So
in
many
implement
implementations.
I
know
it's
kind
of
hard
coded
that
if,
if
you
have
a
certain
group
in
the
you
know
for
the
multicast
source
in
in
the
source
side,
you
want
to
encapsulate
that
into
a
specific
group
in
the
underlay.
B
But
you
would
like
to
have
the
freedom
to
say,
maybe
even
for
the
same
group.
Two
different
sources:
you
might
want
to
encapsulate
them
differently
in
in
the
core
it
might
be
because
so
or
the
bandwidth
used,
for
instance,
but
the
key
thing
is:
we
want
the
flexibility
where
the
receiver
etr
can
can
signal
this
script
address.
That's
what
it's
all
about.
B
Yeah
more
or
less
skip
this,
but
this
is
what
it
looks
like
you
know.
You
have
like
multiple
list
sites
and
you
have
like
the
source
in
one
site
and
then
you
might
have
multiple
receiver
sites
and
each
of
the
xtrs,
like
the
border
routers
here,
might
want
to
specify
different
group
addresses
they
want
to
to
join
next
slide.
Please.
B
So,
just
to
go
into
the
the
exact
details,
the
rfc8059
defines
what
we
call
a
pin
joint
attribute,
and
it's
formatted,
like
we
see
on
the
diagram
here,
and
what
we
are
proposing
in
this
draft
is
to
keep
the
same
exact
same
format.
The
only
thing
is
that
the
receiver
are
lock
can
be
a
multicast
group
address
when
you
do
multicast,
and
only
so,
it's
not
changing
any
format.
It's
just
like
relaxing.
B
What
can
you
put
in
that
receiver
or
log
field
so
been
looking
at
existing
implementations,
and
I
think
this
should
be
fine,
so
today,
implementations
that
do
multicast
replication,
I'm
sorry
multicast
in
the
underlay.
They
they
don't
look
at
this
or
lock
attribute
at
all,
while
implementations
that
would
support
like
this
new
extension,
they
would
basically
start
checking
what
is
what
what
group
address
to
use
by
checking
this
attribute.
B
B
So
my
question
for
the
list
working
group
is
really
are
you,
okay
with
us
moving
on
with
this
in?
In
pim
and
adopting
it
in
pim
any
concerns
from
the
lisp
site,
and
we
can
of
course
keep
you
updated
on
on
any
further
changes.
If
there's
any
and
and
and
also
when,
it's
the
last
call,
we
can
do
that
in
the
list
group
as
well
all
right.
Any
questions,
comments.
A
C
D
Now
we
can
hear
you,
okay,
okay,
sorry
about
that.
I
click
the
long
button.
So
do
you
allow
lispa,
noda
and
known?
Listen,
know
that
to
join
pim
distribution
tree
at
the
same
time,.
B
So
we
we
do,
allow
that
I
will
say,
there's
no
easy
way
to
prevent
that,
so
in
theory
yeah,
any
router
could
for
those
could
join
that
that
grip
and
possibly
receive
the
traffic.
Of
course
it's
listed
encapsulated
and
they
may
not
know
what
to
do
with
it.
So,
ideally,
you
should
have
some
fixed
grip,
addresses
and
underlay.
That
is,
you
know,
only
used
for
this
purpose
and
ideally
only
his
brothers
to
join
but
yeah.
It
cannot
really
be.
A
B
Yes,
yeah,
I
might
say
you
know
we
might
also
look
into
how
we
can
do
this
better,
with
signal
free
multicasts
in
the
future,
but
but
yeah
thanks.
A
A
F
Yeah
all
right
cool,
yeah
so
mark
and
I
are
actually
cope
yeah
mike
mark
and
I
are
going
to
co-present.
We
we
just
have
a
few
slides,
so
maybe
save
the
questions
for
the
end,
so
that
way,
mark
doesn't
get
messed
up
in
the
queue
for
speaking
so
yeah
thanks
luigi.
This
is
list
transport
for
policy
distribution.
We're
going
to
talk
about
the
motivation
proposed,
encoding
and
mark
will
describe
some
of
the
process
for
distributing
this
policy.
F
So
the
motivation
actually
was
born
out
of
a
discussion
or
discussions
with
multiple
lisp
operators.
Two
in
particular
the
one
on
the
left
is
a
list
operator
who's
more
like
a
service
provider
providing
internet
connectivity
to
you,
know,
n
number
of
customers
and
their
internet
edge.
Routers
are
actually
running
lisp,
there's
a
another.
F
You
cust
there
there's
another
use
case
that
was
born
out
of
a
discussion
with
an
operator
who's
managing
a
private
lan,
so
there's
multiple
remote
sites
that
are
connected
over
commodity
internet
back
to
a
a
hub
site
and
in
both
cases,
oddly
enough.
At
the
same
time,
they
both
had
asked
that
you
know
if,
if
we're
using
the
lisp
architecture
to
return
our
locs
for
these
itrs
to
use,
could
we
also
return
other
bits
of
information
to
these
itrs?
F
So
that's
that's
kind
of
a
broad
request
and
when
we
got
down
to
it,
we
found
that
they
were
really
asking
for
things
like
simple
policy
stuff
like
qos
or
some
access
control
lists,
for
example,
this
internet
edge
use
case.
We
found
that
multiple,
numerous
customers
that
were
using
of
the
service
fighter
were
connected
to
their
transport.
Using
sublime
rate
speeds
and
they
had
no
qos
configured.
F
Similarly,
with
this
private
land
use
case,
they
also
wanted
some
basic
security
acls
pushed
out,
so
they
were
asking
well.
If,
if
our
our
needs
for
distributing
things
are
somewhat
lightweight,
you
know,
could
we
could
we
reuse
the
list
of
architecture,
because
it
would
give
us
an
advantage?
We
can
keep
everything
kind
of
in
one
architecture.
We
don't
have
to
invest
in
any
other
areas
to
push
to
push
simple
things
out,
so
next
slide.
F
So
in
order
to
do
that,
this
is
pretty
much
the
encoding
that
we're
proposing
here.
It's
using
this,
this
naming
convention
we're
where,
as
an
eid,
key
to
look
up
in
the
mapping
system.
This
is
an
example.
This
is
policy
dash
ce
dash,
rtr01
and
that
lookup
returns
a
a
locator.
That's
using
this,
this
json
lcaf
and
here
we're
encoding
it
as
a
string.
F
So
what
essentially,
what
happens
here?
Is
you
know
if
you
can
imagine
this
this
customer
connected
to
that
to
that
list
service
provider?
You
know
they
would
register,
have
basic
information
configured
on
this,
this
itr,
where
they
can
communicate
with
the
map.
Server
and
after
they
register,
they
would
basically
also
receive
a
policy
that
that
would
be
programmed
on
that
our
lobe,
and
here
it's
basically
all
right.
We're
going
to
shape
do
some
sublime
rate
shaping.
So
it's
it's,
it's
it's
pretty
elementary.
F
So
how
we
do
that
next
slide
mark
is
going
to
describe
that
hi.
Can
you
hear
me.
A
E
G
So,
in
terms
of
packet
flow
that
is
proposed
in
in
these
drafts,
when,
when
investigating
this
issue
and
testing
it,
we
realized
that
this
is
a
perfect
match,
with
the
pops
up
specification
that
it's
about
to
go
out
right
and
so
yeah
in
very
simple
terms
or
trying
to
illustrate
the
idea.
G
We
have
this
sphere,
where
you
would
have
a
mapping
system
and
multiple
routers
that
are
coming
up
in
terms
of
how
to
specify
the
policy.
G
The
draft
assumes
that
particular
policies
are
either
conflict
directly
directly
configured
on
the
mapping
system
or
or
you
could
have
a
controller
that
uses
the
map
registration
interface
to
to
onboard
these
policies
on
the
marketing
system
and-
and
the
next
step
is
it's
just
that
when
the
routers
come
come
up,
they
would
have
these
procedure
by
which
they
send
a
map
request
to
the
mapping
system,
asking
for
a
specific
known
string
right
in
this
example
policy.
Rtr01
saying:
okay:
can?
Can
you
give
me
the
policies
that
apply
to
me?
G
If
you
could
go
to
the
next
slide
and
why
puffs
up
is
a
perfect
match
is
is
because
then,
with
the
subscription
system,
any
change
in
the
in
the
policy
registration
on
the
mapping
and
mapping
system
would
just
be
published
right
through
an
additional
magnify,
with
the
updated
json
to
to
the
rtr.
That
has
sorry
to
the
router
that
has
subscribed
to
this
policy
yeah.
G
G
C
Okay,
I
put
myself
in
the
queue,
so
I'm
first.
C
I
was
hoping
to
hear
some
explanation
from
you
as
to
whether
you
are
assuming
this
is
a
dedicated
lisp
system,
where
the
list
mapping
system
is
only
being
used
for
this
purpose
or
whether
these
are
actually
distinguished
names
and,
if
they're,
actually
distinguished
names.
What
is
the
mechanism
to
make
the
policy
names
distinguished.
F
Yeah,
hey
joel
great
question.
I
I
think
in
in
this
use
case
the
the
semantic
of
distinguished
in
most
cases
may
not
may
not
apply,
and
let
me
explain
it
is
assume
that
you
have
a
a
a
deployment
like.
I
was
showing
in
the
the
motivation
slide,
where
you
have
a
hundred
lisp
sites
and
50
of
them
all
connect
or
using
circuits
of
like
200
meg.
F
So
so,
instead
of
creating
50
different
names
to
identify
ever,
you
know
those
50
different
itrs.
C
C
We
have
to
keep
the
names
separate
and
yeah.
The
other
purpose
seems
to
produce
names
that
are
likely
to
be
different
until
there's
yet
another
purpose
and
yet
another
purpose,
and
then
that's
why
they're?
In
the
other
context,
they're
called
distinguished
names
and
there
doesn't
seem
to
be
any
mechanism
here
to
keep
it
distinguished.
C
I
suggest
you
think
about
it
and
comment
on
the
list.
I
won't
insist
on
comment
here.
The
other
thing
I
would
like
you
to
deal
with
on
list
and
in
the
draft,
but
don't
try
to
answer
today,
is
to
spell
out
the
relationship
between
these
policies
and
pce,
driven
policies
and
sr
policies
and
bgp
based
policies.
C
H
But
let
me
respond
to
joel's
question
first,
the
question
was:
can
it
use
the
same
lisp
system
or
the
same
mapping
system?
Of
course,
if
it
uses
the
same
mapping
system
and
different
instance
ids
and
the
instance
id
for
the
policy-based
stuff
is
used
only
for
that,
then
there's
no
name
conflict.
Of
course,
if
it's
registering
to
an
instant
id,
that's
using
names
for
other
things,
then
obviously
the
names
have
to
be
unique.
So
I
agree
with
that.
H
Another
question:
guys:
can
you
go
back
to
the
to
the
slide
where
the
map
notify
was?
If
you
can
do
that?
H
Okay,
you
can't
do
that
I'll
start
the
question
while
you're
trying
to
do
it
so
guys,
I'm
not
sure
we
put
this
in
the
draft,
but
we
might
have
an
mtu
problem
with
the
map
notify
if
the
json
is
really
large.
The
json
is
great
because
it's
it's
supported
by
so
many
different
types
of
systems
and
apis,
but
depending
on
what
the
names
are
it
can
be,
it
can
be
rather
lengthy.
I
have
a
lot
of
experience
with
json
and
found
out
that
I
ran
into
mtu
problems
right
away.
H
So
I
would
say,
let's
use
fragmentation
where
the
map
notify
is
sent
once
by
the
list
module
ip
fragments.
It
gets
reassembled
on
rtr01
and
then,
when
it
gets,
reassembled
lis
is
presented
with
a
large
datagram.
So
we
can
map
notify
that
act
that
now
it
turns
out
that
the
map
notify
ack,
I
believe,
has
the
same
arloc
record
in
it.
So
it
may
have
the
same
problem
with
mtu.
So
I
think
we
should
have
a
look
at
that
and
update
the
spec
comments.
H
F
F
A
Late,
maybe
we
we
can
take
it
offline.
I
K
3Am
all
right,
so
the
list
fix
is
about
in-network
analysis
of
flow
information,
so
it
might
ordinarily
be
belong
to
the
ipfix
working
group,
but
it
has
more
to
do
with
computing
network
or
compute,
first
networking
or
contextual
networking,
which
is
an
area
that
I
know
luigi
at
the
both
on
and
it
was
in
coin
rg
and
something
I'm
very
interested
in,
and
if
there
is
interest
we
will
see
if
it's
possible
to
pursue
it
on
the
list.
So
next
slide
all
right.
K
So
all
these
protocols,
iphix
net
flow
s,
flow
flow
logs,
they're,
basically,
gathering
stats
about
packets
that
share
a
characteristic,
a
flow
and
aggregate
based
on
some
time
slots
or
volume
loss
slots
and
from
an
exporter
to
a
collector
next
slide.
Please.
K
Next
slide,
please,
okay!
So
what's
new?
What's
new
is
in
the
cyber
world,
as
you
can
hear
in
look
in
wall
street
journal
every
other
day,
the
attacks
are
very
sophisticated.
They
penetrate
using
any
application
layer
to
some
a
random
device
and
and
device,
but
then
start
lateral
movement
and
the
latter
movement
builds
up
a
dos
attack.
Sql
attack,
an
ssh
attack,
port
scan,
leaking
information
or
preparing
for
ransomware,
so
the
attacks
are
are
digging
in
it's
not
like
something
which
is
a
one-shot
one
place.
K
On
the
other
hand,
the
new
capabilities
are
that
with
ai,
it
is
now
possible
in
real
time
to
recognize
and
normalize
patterns
of
applications
and
see,
if
there's
lateral
movement
hiding
behind
it.
So
there's
a
very
nice
paper.
I
can
send
it
to
you
if
you're
interested,
but
after
normalization
networks,
neural
networks
that
were
trained
on
completely
different
organizations
are
able
to
detect
non-kosher
patterns
of,
let's
say,
backup
or
crm,
or
whatever
application
pretends
to
run
there
and
see
lateral
movement
behind
it.
K
Another
thing
which
is
a
new
challenge
is
that
traffic
from
anywhere
to
anywhere
anywhere,
google
can
show
up
on
any
layer,
3
port
because
of
virtualization,
vpns,
vlans
and
and
so
forth,
and,
and
that
makes
it
very
hard
to
track
who
is
talking
to
who,
in
a
specific
application
context.
On
the
other
hand,
the
same
technologies
that
allow
for
virtualization
are
also
able
to
steer
the
the
sampling
to
different
buckets
and
therefore
to
collect
differently.
K
Even
though
a
subnet
is
now
scattered
all
over
the
network,
it's
able
to
collect
samples
per
subnet
or
per
work
group
very
effectively.
Last
thing
is
distribution.
Applications
are
especially
cloud
native.
Are
very
distributed:
there
is
a
lot
of
east-west
traffic
for
every
north-south
request,
and
that
creates
a
huge
load
and
virtually
impossible
to
put
probes
in
that
data
path.
K
On
the
other
hand,
we
know
how
to
distribute,
and
therefore
we
can
also
distribute
the
analysis
logic
better
than
we
used
to.
So
we
don't
have
to
concentrate
the
logic
in
order
to
analyze
the
information
and
with
the
lisp
approach.
This
can
help
us
battle
that
challenge
of
of
high
volume
next
slide,
please,
okay.
So
what
is
the
idea
exporters
instead
of
sending
to
a
collector?
K
K
This
is
sort
of
in-network
protection
and
therefore
we
don't
we
don't
concentrate
the
logic
or
the
sampling
traffic,
which
may
be
very,
very
heavy
just
to
aggregate
samples
next
slide,
please
what
what's
the
value
of
this
approach?
K
Basically,
instead
of
putting
probes
where
we
can't
put
probes,
for
example
in
spines
or
cores,
or
it's
very
hard
to
put
probes
like
in
highly
regulated
industries
such
as
hospitals
and
utilities
or
the
and
enterprises,
don't
have
anywhere
to
put
probes
because
it's
5g
lan,
it's
all
and
none
they
don't
have
any
access
to
the
to
the
line.
We
can
now
put
these
probeless
probes
on
a
tangent
network
which
will
scale
just
like
inline,
but
without
being
inline.
K
The
algorithms
themselves
have
been
tested
and
are
tested
in
about
100
installations.
What's
not
yet
mainstream.
Is
this
sort
of
net
native
aggregation
that
can
be
applied
next
slide?
Please?
K
So
what
do
we
suppose?
What
do
we
propose?
Is
it's
a
use
case
of
leveraging
lisp
for
computing
network
and
just
like
the
other
cases
where
we
leveraged
it
for
that
list?
For
that
we
leverage
the
eid,
the
logicalness
of
that
that
we
can
just
define
the
ids
as
compute
context
algorithmically
or
with
the
rules
and
signal
free,
which
is
once
there
is
a
computation
you
can
subscribe
to
it
its
results
and
and
therefore
distribute
the
entire
logic
without
concentrating
it.
K
So
per
flow
will
have
to
define
how
you
set
up
rules
and
that
can
apply
to
ipfix
or
flow
logs
or
any
of
these,
and
then
a
per
collector
analyzer
will
have
to
specify
subscription
for
things
like
ssh
attack,
ddos
http
things
like
that
injections,
sql
injections
and
so
forth,
so
to
know
whether
to
block
that
flow
right
away.
K
If
it's
detected
and
that's
it
basically
next
slide.
Please
if
I
have
two
minutes,
I
just
like
to
give
you
and
if,
if
people
are
okay
with
proceeding
with
this,
let's
take
it
on
the
list
and
I
will
specify
the
draft.
If
it's
not
the
right
place,
then
you
know
we
can.
We
can
decide
that
too.
K
I
want
to
give
you
a
like
a
quick,
a
quick,
a
summary
of
what's
going
on
with
this
nexagon,
which
is
also
a
computing
network,
a
draft
using
the
same
principles
basically
next
slide.
Please
very
quick,
very.
K
Sorry
yeah,
so
it's
basically
having
a
very
nice
impact
on
industry
in
the
auto
industry,
specifically
the
ace
and
just
to
give
you
an
idea
of
how
computing
network
using
lisp
is,
is
being
used.
It's
used
for
realizing
geolocation
services,
which
is
everything
which
is
in
done
in
in
geospatial
context,
and
that
means,
for
example,
cues
for
elements
picked
up
from
the
road,
so
the
queues
can
now
be
for
cues
for
picking
up
detections
from
vehicles.
K
Multiple
uploads
can
be
corroborated,
and
then
you
can
subscribe
for
events
like
hard
stops
or
other
detections.
Again,
that's
an
eid
using
signal
free.
So
by
that,
basically
the
acc
accepts
edge,
aggregation
and
push
notifications
and
a
lot
of
things
which
lisp
enables
so
next
slide.
Please.
K
This
is
the
last
one
I
promise.
So
basically,
my
point
is
what
what
enables
this
context.
Switching
while
you
drive
to
punch
stuff
to
different
queues
without
dns
resolutions
and
without
worrying
about
what
did
you
cache
as
a
resolution?
If
something
changes
and
what
allows
cars
to
keep
on
being
subscribed
to
things
and
be
identified
as
as
reliable
sources,
even
though
their
modems
may
switch
ips
is
lisp.
K
While
you
switch
ips
allowing
for
point
to
point
and
pull
to
point
to
multi-point
signal
free
over
mobile
and
networks
which
don't
support
it
and
also
lisp
enables
the
geo
privacy,
while
you're
using
geolocation
services
because
of
the
coupling
of
the
layer.
The
point
is
it's
very
hard
for
the
industry
to
connect
the
dots
to
list
without
the
least
hexagon
type
specification.
So
that's
the
value
of
these
use
case.
K
A
A
J
Let
me
lower
the
volume
a
little
bit:
okay,
that
should
be
better,
hopefully,
okay,
so
hello,
hello,
everyone,
let's
quick
get
into
this,
we've
been
postponing
the
update
on
overlay
for
a
while
and
last
time
we
spoke,
there
were
a
series
of
requirements
that
emerged
in
one
of
the
deployment
scenarios
of
the
overlay
and
the
requirements
are
barely
merely
around
the
backbone
and
multi-as
backbone.
So
that's
what
I
would
like
to
focus
on
here.
J
They
have
a
network
which
is
built
by
multiple
providers,
and
these
networks
provide
different
radio
services
for
different
reasons
to
to
the
aircraft,
but
they
do
meet
in
that
backbone
and
they
need
a
mechanism
to
actually
appear
in
that
backbone
and
there's
a
series
of
peering
agreements
that
are
pretty
stringent
because
of
the
nature
of
these
organizations
and
of
the
because
of
the
fact
that
they
belong
to
different
countries.
In
some
cases
they
are
defense,
networks
and
so
forth.
J
So
so
a
series
of
interesting
requirements
came
from
that
so
as
if
we
go
to
the
next
slide,
please
there
are.
This
is
a
diagram
of
basically
what's
happening,
very
simplified,
but
a
plane
may
connect
to
one
or
more
radio
regions
at
any
given
point
in
time
and
each
one
of
these
communication
service
providers
actually
provide
these
radio
services,
and
then
they
bring
them
onto
an
ip
backbone.
J
In
that
ip
backbone
they
will
actually
have
bgp
pairings,
just
like
any
service
providers
would
and,
and
they
basically
govern
any
connectivity
or
any
prefixes
that
they
may
or
may
not.
Service
are
governed
by
enforcing
in
those
pgp
pairings
what
is
allowed
and
what
is
not
allowed.
So
we
go
to
the
next
slide
in
our
environment.
What
we
did,
because
we
needed
mobility
and
we
needed
multi-homing.
J
We
suggested
the
use
of
lisp
and
because
of
the
regionalization
of
things
we
suggested
the
use
of
the
overlay,
but
it
didn't
matter
how
much
you
you
broke
it
down
into
side
overlays.
The
net
effect
of
it
was
that
at
the
at
the
center,
it
was
all
meeting
in
in
the
overlay
with
basically
that
that
circle
that
you
see
in
the
middle
and
and
as
you
can
see
the
underlay
for
that
overlay
portion
of
the
network
is
basically
where
those
peerings
exist.
So
if
we
go
to
the
next
slide,.
J
So
we
end
up
basically
with
a
federation
of
mapping
systems
and
that's
where
we
left
things
last
time
we
talked
so
if
we
go
to
the
next
slide,
I
think
we're
going
to
get
into
into
what
we
really
want
to
talk
about,
which
is,
if
I
have
to
simplify
this,
whether
it's
in
the
context
of
an
overlay
or
just
in
general,
when
I'm
actually
trying
to
deploy
lisp
over
a
multi-as
backbone.
J
Some
of
the
requirements
that
were
put
forth
are
that
each
organization
has
its
own,
as
and
in
that,
yes,
they
must
have
both
all
the
control
of
all
the
assets
in
the
underlay,
but
also
control
of
all
the
assets
in
the
overlay,
which
meant
basically
assigning
a
map
server
to
each
one
of
these
organizations
and
the
the
requirements
go
further
in
specifying
that
if
an
aircraft
or
an
eid
was
to
be
registered,
it
would
have
to
be
registered
from
the
perspective
of
the
xtr
that
it
is
connecting
to,
and
that
meant,
for
instance,
if
I
am
connecting
to
xdrc.
J
I
would
actually
have
to
register
to
map
server
c
and
if
I
moved
to
to
another
as
and
connect
to
an
xtr,
and
that
is
then
I
would
actually
register
with
the
map
server
in
that
area.
So
so
the
the
ids
were
being
relocated
yeah.
At
the
same
time,
we
have
now
moved
all
the
eid
information
out
of
the
underlay
and
into
into
our
list
mapping
system,
so
the
bgp
peerings
no
longer
have
information
to
enforce
any
of
the
peering
agreements
of
allowing
or
disallowing
any
of
these
prefix.
J
So
that
poses
an
interesting
challenge,
because
the
expectation
is
still
that
if
a
tunnel
is
carrying
traffic
for
a
particular
prefix
that
that
tunnel
should
not
traverse
in
a
s
where
that
prefix
is
not
allowed
to
be
serviced.
Okay,
so
we
go
to
the
next
slide.
J
So
these
pairing
agreements
refer
to
the
eid
prefixes,
that's
the
first
thing
and
they
also
specified
terms
of
service,
so
cost
of
using
the
the
providers
network
is
one
example
level
of
service
that
will
be
provided
if
it's
preferential
or
best
effort
and
so
forth.
So
so
there's
an
entire
contract.
That
is,
that
is
formed
and
it
does
govern
both
the
use
of
the
overlay
resources
but,
more
importantly,
all
the
infrastructure
that
is
underneath
right.
J
J
One
type
is
transit
policies
where
basically,
it's
the
standard
permission
or
denial
of
use
of
a
backbone
section
for
the
purposes
of
transporting
information
to
a
particular
eid
prefix
and
the
other
type
of
policy
is
that
which
is
effectively
enforced
at
the
ingress
into
the
network,
where,
from
the
perspective
of
an
ingress,
as
I
may
have
multiple
as
paths
that
I
could
follow
to
a
particular
destination,
and
I
can
evaluate
what
the
terms
are
for
those
services
and
based
on
those
terms
determine
which
would
be
my
preferred
path
for
a
particular
connection.
J
J
So
if
you
look
at
the
different
scenarios
that
we
had
to
cover,
if
I
go
from
top
to
bottom
in
this
slide,
if
from
the
perspective
of
a
connection
between
asa
and
asb,
which
are
the
two
asses
that
are
towards
the
center
of
the
diagram,
one
of
the
scenarios
is
I
for
because
of
the
policy
defined.
I
would
like
to
actually
go
through
asd
and
ase,
so
I
have
two
as's
to
traverse
before
I
can
get
to
my
destination.
J
We
would.
We
would
need
a
mechanism
to
enforce
that
and
to
evaluate
the
existence
of
that
aes.
Note
that
I'm
not
suggesting
that
there
are
any
rtrs
in
the
middle.
So
the
aspirational
goal
is
that
we
keep
this
as
simple
as
possible
for
the
operator
and
and
not
have
to
create
explicit
locator
paths
or
anything
like
that.
In
any
case,
the
the
four
scenarios
that
you
see
there
are
one
is
multi-as,
which
is
illustrated
by
the
blue
line.
J
The
other
one
is
just
direct
back
to
back
aes
connectivity,
which
is
that
green
line,
and
then
we
have
a
single
as
traversal,
and
then
there
are
also
regions
within
the
aes.
So
I
could
have
a
service
provider
have
an
east
region
and
a
west
region,
and
that
is
included
for
completeness.
J
I
don't
know
that
it
has
many
implications
in
us
having
to
generate
new
machinery,
but
the
reality
is
that
you
will
have
mapping
servers
assigned
to
each
east-west
of
that
region,
so
so
just
something
to
keep
in
mind
as
we
document
requirements.
J
So
so
so
this
is
the
interesting
proposition
here.
How
do
we
steer
traffic
through
an
underlay
in
a
particular
way,
based
on
information
that
we
have
in
the
overlay
next
slide?
Please.
J
So
this
is
an
attempt
at
summarizing
the
requirements,
so
the
scope
is
per
as
the
as
is
an
underlay
focused
construct.
Basically
it
maps
to
the
plot
to
the
topology
in
the
underlay.
J
J
Eads
must
move
across
asses
or
have
the
ability
to
move
across
lasers
and
be
multi-homed
as
well,
and
we
want
to
enforce
the
policies
derived
from
those
peering
agreements
and
yeah,
ideally
not
require
rtr.
So
we
go
to
the
next
slide.
That's
my
last
slide,
so
my
apologies
to
the
work
group
for
being
so
tardy
with
this.
J
It's
been
a
challenging
year
to
say
the
least,
but
there
is
a
draft
as
of
this
morning,
and
I
was
I
I
anyway,
it's
a
long
story,
but
there
is
a
draft
as
of
this
morning
where
all
this
is
captured,
hopefully
in
a
structured
enough
way
that
we
can
initiate
conversations
step.
One
I've
been
discussing
this
with
dino
and
others
step.
One
is,
let's
see
what
we
have
on
the
on
the
truck
right
now
and
see
if
that
fits
the
bill,
and
we
can
actually
address
these
requirements
and
first,
stop
would
be
ddt.
J
So
I
think
that's
our
next
step
to
actually
put
our
heads
to
seeing
if
ddt
actually
will
give
us
enough
machinery
to
do
what
we
need
to
do
here
and
if
not,
then
there
are
alternative
approaches
to
to
value
that,
that's
it
from
from
my
perspective.
Hopefully
this
helps
you.
A
Thank
you
victor
and
finally,
we
will
have
a
document
to
discuss
sorry
about
that.
Dino,
quick,
very
quick.
Please.
H
J
J
List
but
there's
there's
been
conversations
around
dedicating
ip
addresses
to
different
interfaces
so
that
that
doesn't
become
a
multi-homing
of
an
eid,
but
it
just
becomes
the
most
harming
of
the
host.
But
we
can
talk
about
that
in
more
detail
as
we
discuss
the
draft.
G
Okay,
let
me
let
me
go
ahead
and
you
stop
me
when
we're
done.
Okay,
at
least
we
have
a
slide
where
we
have
the
full
list
of
drafts.
We
want
to
talk
about
and.
A
G
Okay,
so
yeah
for
this
last
presentation.
What
we
wanted
to
do
is
basically
list
or
compile
a
list
of
open
items
in
the
list
protocol
that
that,
yes,
things
that
are
still
open
and
but
that
are
working
in
a
commercial
implementation
of
of
the
protocol
and
are
being
shipped
these
days,
and
we
wanted
to
see
if
we
can
recover
the
conversation
on
on
some
of
these
items
and
yeah
promote,
promote
it.
G
Yeah
presentation
is,
we
have
a
list
of
usual
success
here,
the
victor
fabio
valazi
alberto
that
helped
compile
this
list.
If
you
go
to
the
next
slide.
G
Yes,
the
motivation,
as
we
are
saying
saying,
these
are
items
that
have
been
discussed
in
the
past,
but
we
haven't
had
well
for
some
of
them.
We
haven't
had
much
discussion
lately
and
what
we
wanted
to
do
here
is
use
this
presentation
to
to
trigger
discussions
again
on
in
the
working
group
so
that
we
can
progress
on
the
development
of
some
of
these
documents.
G
So
this
is
a
short
list
of
of
all
the
documents
that
we
found
right
on.
The
working
group
item
bug
at
least
the
two
most
important
ones
are
eid
mobility
and
leaves
vpns
I'll
go
through
them.
Next,
there
are
some
other
documents
like
vendor
elkaf
pops
up,
but
these
are
already
requested
for
publication
and,
if
I
understood
well
you
this
young
model
will
also
be
in
in
that
list
soon
enough.
G
So
I'll
keep
talking
about
them
today
and
on
the
non-working
group
item
list,
there
is
one
that
is
very
important
from
this
commercial
implementation
perspective
is
the
reliable
transport
draft.
We
had
discussions
in
the
past
quite
intense,
but
we've
parked
these
ones
for
a
while
now
and
we
wanted
to
bring
it
back.
G
Then
we
have
the
distinguished
name
discussion
this.
This
is
a
recent
discussion,
but
we
wanted
to
contribute
at
least
explaining
the
use
cases
that
that
how
we
have
been
using
it
overlay
has
been
addressed
by
victor
just
a
moment
ago,
and
then
we
have
this
not
reversal
and
side
external
connectivity
I'll.
If
I
have
time
I'll
give
a
short
note,
india,
exactly.
G
So,
with
respect
to
least
vpns
and
eid
mobility
yeah,
the
most
important
thing
about
them
is
that
they
specify
the
basis
of
segmentation
and
mobility
support
that
we
use
in
all
our
least
commercial
offerings
in
particular.
Well,
you
guys
know
know
well
these
drugs
leave.
Vpns
applies
to
the
approach
taken
for
l2
segmentation,
lc
segmentation,
as
it
describes
the
use
of
instance,
ivs,
extended,
ivs
and
and
how
to
operate
extranet
with
respect
to
the
mobility
drafts.
G
It
also
describes
how
mobility
is
architected,
which
mechanisms
are
we
using
and
and
also
very
important,
different
mobility
approaches
with
different
combinations
of
l2
l3
or
how
we
use
our
pan
nd
or
how
we
process
urban
md
messages
yeah.
These
two
drafts
are
kind
of
important
and
we'll
be
working
to
promote
them
in
in
the
next
meetings
and
then
also
in
the
mailer.
Just
as
a
final
note,
both
drafts
apply
to
all
areas
of
application
where
we
have
been
receiving
lists
right.
Campus
networks,
data,
centers,
iot
deployments,
one
and
even
cloud
extensions.
G
Yeah,
just
I'll
I'll
go
quickly
through
these
two.
This
is
just
to
say.
Instead,
this
vpn's
draft
was
last
discussed
in
1998,
so
when
it
was
adopted
by
the
working
group
updates,
it
hasn't
had.
G
It
didn't
have
many
updates
since
then,
but
one
of
them,
for
example,
latest
one
victor
uploaded
the
drafts
and
and
we
have
updated
how
negative
map
replies
are
calculated
when
when
we
have
extranet
in
the
picture,
but
I
we
would
like
to
highly
encourage
the
group
to
to
read
this
draft
and
and
provide
some
feedback
if
to
make
it
go
forward
next
slide
and
the
same
with
the
id
mobility
last
discussed
in
idea
98
when
it
was
adopted
as
a
working
group
item,
this
one
has
really
had
small
changes
since
then,
and
we
had
one
outstanding
item
that
we
were
still
discussing,
whether
to
include
l2,
multi-homing
or
not,
but
but
again
the
same.
G
A
Mark,
if
you
don't
mind,
we
are
two
minutes
late
and
would
be
better
maybe
to
stop
right
now:
okay,
okay,.
A
I
think
joel
agrees
with
me.
We
listen
to
your
presentation,
the
the
the
the
list
of
drafts
that
you
are
interested
in.
Obviously,
as
I
said
at
the
beginning
for
the
working
group
items,
we
will
move
forward
between
now
and
one
one,
two
okay.
If
we
we
get
to
that,
we
will
also
start
to
look
at
the
the
other
trust
that
you
you
mentioned.
A
G
G
A
Okay-
okay,
good!
I
don't
think
we
have
time
for
a
question
from
the
for
the
audience
I
just
want
to.
Maybe
there
is
something
from
dino.
I
A
A
So
what
I
can
say,
thank
you
very
much
everybody
for
the
presentation
for
the
question
we've
taken
down
the
mailing
list
and
we
will
try
to
resume
all
the
the
the
documents
that
were
a
little
bit
on
hold
for
these
documents:
okay
and
enjoying
the
last
two
days
of
the
ietf
online
meeting.
Okay,
hopefully
we
can
meet
physically
soon,
okay,.