►
From YouTube: IETF113-LISP-20220322-1200
Description
LISP meeting session at IETF113
2022/03/22 1200
https://datatracker.ietf.org/meeting/113/proceedings/
A
Okay,
I
think
we
can
start
it's
the
top
of
the
hour
one
o'clock
and
so
welcome
everybody
to
the
lisp
working
group
session
for
the
people
in
the
room
and
everybody
that
is
online.
I
hope
every
everybody
is
fine.
A
Some
tips
about
this
hybrid
setup,
so
in
person
you
can
log
in
in
the
lightweight
tool.
Midiko
tool
is
the
small
mobile
phone
icon
that
you
have
on
the
agenda
by
that
you
automatically
sign
the
blue
sheets
and
if
you
wish
you
can
actually,
if
you
are
a
presenter,
decide
to
share
the
content,
so
your
slides
and
you
can
control
the
the
slides
plan
b.
Is
I
share-
and
you
just
say
next:
okay,
as
for
the
good
old
times,
remote
participants
is
the
mythical
setup
we
had
in
the
last
two
years.
A
Basically
so
you
you,
you
see
the
the
video
screen
audio
stream,
the
jabber
chat,
okay,
as
usual
for
the
questions
remote
and
here
in
the
room
you
queue
up,
so
you
raise
your
hand
from
the
mythical
tool
and
you
for
the
person
here
in
the
room.
You
go
to
the
mic.
Only
when
it's
up
to
you
to
ask
the
question:
you
don't
need
to
physically
queue
up.
Okay,.
C
A
Just
a
a
small
reminder
of
the
code
of
conduct,
which
is
important
here
in
the
iaetf,
is
about
respecting
everybody
here
in
the
room
and
online
to
having
personal
discussion
always
based
on
technical
points
and
now
that
everybody's
already
configured
here.
Okay-
so
I
forgot-
I'm
luigi
joel
is
online.
Here
we
are
the
coaches
of
the
groups
padma.
Our
secretary
is
also
currently
online
remotely
on
the
medical
system.
A
Here
you
have
the
usual
pointers
for
everything:
the
charter,
the
jabber
room,
three
mythical
agenda
and
slides,
so
here
also
the
material,
the
slides
that
you
are
seeing
right
now,
a
quick
update
on
the
status
that
of
our
working
group.
So
we
have
a
few
documents:
five,
actually
that
are
already
in
the
rfc
editor
queue,
which
is
a
good
point.
Okay,
they
are
just
a
little
bit
stuck
there,
because
that
they
have
references
to
documents
that
are
still
in
the
pipeline.
A
Actually,
we
have
five
that
are
in
the
in
alvaro's
queue
because
they
passed
the
working
group.
Last
call
I
mean
so
they
alvaro
needs
some
time
to
process,
not
only
our
documents,
but
all
the
the
the
working
groups
that
he
is
overseeing
right
and
there
is
the
it's
difficult
to
read.
But
the
last
document
at
the
bottom
is
the
young
model,
which
has
have
been
discussed.
I
think
last
year
and
I'm
sure
we
are
critical
close
to
the
working
group
plus
calls.
So
at
some
point
this
year
we
may
go
for
it.
A
I
would
say:
okay
today,
the
other
working
group
documents
are
the
lisp
l2l3
id
mobility.
We
will
have
a
presentation
today.
The
young
model
I
just
said
will
not
be
discussed
today.
There
is
a
mistake
in
in
the
slides
and
then
there
are
a
few
documents.
A
Actually
that
are
there,
and
we
should
try
this
here
to
discuss
whether
or
not
we
want
to
move
them
forward
and
so
go
for
conclude
the
work
and
go
for
a
working
group
plus
call
or
check
whether
the
working
groupers
want
to
drop
the
this
work.
We
have
a
few
tasks
to
be
accomplished.
I
would
say
there
is
the
the
not
traversal
document
that
should
be
done
and
there
was
a
an
explicit
request
in
the
charter.
A
We
have
it
in
the
chapter,
so
would
be
good
if
we
also
focus
on
on
this
one.
This
year,
the
lisptdt
rfc
so
81111.
A
We
need
to
move
the
document,
the
list
ddt
on
the
standard
track,
so
we
have
to
think
about
have
a
one,
eight
one,
one
one
piece
in
order
to
standardize,
also
the
the
ddt
system.
Okay,
what
does
it
mean?
A
So
there
is
the
fact
that
in
the
ayana
we
have
a
lisp
packet
type
defined
in
this
rfc
is
experimental,
so
could
not
be
permanent
because
is
experimental
now
to
make
it
permanent
and
the
point
is
we
are
renewing
this
for
the
second
time,
which
means
the
first
time
we
just
asked.
Second,
first
renewal:
was
we
with
the
ad
alvaro?
That
said,
that's
fine!
Now
we
have
a
d
and
ist
that
has
to
say
it's
okay,
so
we
don't
have
so
much
time
so
because
I
don't
know
how
much
we
can.
A
A
Okay,
okay,
alberto
beast
will
present
so
funny.
So
you
you
will
present
a
reliable
transport.
Okay,
then
we
have
bernard
heindel.
If
I
pronounce
correctly,
which
will
present
the
crown
based
lisp,
okay
and
then
sharon
will
give
an
update
on
the
lisp
mobility
routing.
So
unless
there
is
anybody
who
wants
to
do
any
agenda
bashing.
D
All
right,
so
this
is
a
quick
update
about
the
eid
mobility
draft
yeah.
So
this
is
the
usual
suspect
of
authors.
D
There
were
a
few
comments
that
came
up
in
the
last
itf
online
and
we
didn't
have
a
chance
to
update
the
document
yet,
but
you
know
there
was
some
work
on
layer,
2
multi-homing.
D
That
needs
to
be
done
to
complete
the
the
last
section
in
the
document
itself.
I
just
have
an
update
on
the
discussion
that
went
in
the
mailing
list,
so
we
can
go
to
the
to
the
next
slide
and
basically
what
this
was
raised
at
the
at
the
last
meeting,
as
I
as
I
said
right.
So
the
question
is:
how
do
we
identify
the
layer,
2
multi-homing
groups
and
the
the
discussion
and
the
problem?
Is
you
know
if
there
is
a
site
that
is
multi-home?
D
How
can
you
identify
universally
the
the
group
when
there
are
multiple
unlock
that
are
present
in
that
site?
So
there
was
some
discussion.
Should
we
use
the
site
id,
or
should
we
go
up
for
a
new
identifier
at
all
so
next
slide,
and
it
seems
that
the
conversation
is
going
toward
using
a
new
identifier,
the
internet
segment
id
it's
a
32-bit
value
that
will
identify
uniquely
the
group
of
xdrs,
the
xcrs
that
are
multi-home.
D
In
addition,
in
this
way,
ethernet
segment
id
can
also
be
associated
to
eids,
not
only
200,
lock,
and
in
this
way
you
can
deal
with
the
alliancing
that
allow
for
load
balancing
when
multi-arming
is,
is
active
and
yeah.
So
this,
I
think,
is
the
part
that
where
progress
was
made,
we
will
update
the
the
text
to
reflect
this
consideration
here
and
I
think
that's
the
last
slide.
There
is
another
one:
okay,
the
last
slide.
E
Me
this
is
dino,
hey
hi
long
time.
You
can
hear
me
okay,
so
I
I
remember
recalling
that
there
was
no
reason
not
to
use
the
site
id.
E
Do
you
know
why
that
has
changed
and
because,
because
now
we
have
an
issue,
because
what
if
the
site
id
is
different
than
the
esid
is,
are
the
are
the
xtrs
known
to
be
in
the
same
site
or
not
so,
and
the
reason
why
at
last
itf
we
talked
about
or
the
ietf
in
the
summer
we
talked
about
using
the
site
idea,
so
we
wouldn't
have
to
change
the
packet
formats.
E
So
do
you
know
what
what
came
up
to
want
to
make
that
change?
Yeah.
F
Can
I
take
that
yes
yeah?
So
you
know
this
is
actually
reflecting.
The
the
discussion
on
the
mailing
list
where
you
set
a
nation,
is
a
good
point
that
an
xtr
may
have
different
vlans,
so
you
may
have
different
segments
on
the
on
the
xtr
and
then
you
may
or
may
not
want
to
put
them
in
the
same
site
id
or
like
the
same,
using
a
single
site.
F
I
need
to
cover
all
those
different
layer,
2
segments,
so
we
were
kind
of
assimilating
your
point
and
trying
to
to
to
to
be
coherent
with
the
discussion
on
the
list.
E
F
E
Yeah,
maybe
you
should
call
it
a
vlan
segment
idea,
something
like
that,
but
and
it
needs
to
be
clear-
and
this
these
are
put
in
registers-
that's
going
to
be
a
long
list
of
it
could
be
a
long
list
right.
E
F
G
E
E
Okay,
it
doesn't
matter
really
what
the
name
is.
That's
just
a
moot
point,
but
I'm
worried
about
the
scalability
of
this
now
can't
can't
we
say
that
one
one
or
more
xtr's
are
selected
as
a
designated
forwarder
for
all
vlans.
E
Because
this
is
the
big
change
of
the
map
register
and
I
don't
know
if
it's
worth
it
for
l2
for
l2
overlays.
That's
the
thing
I'm
worried
about!
There's
there's
a
big
cost
here
in
designing
this
in
for
the
benefit,
so
I'm
making
a
judgment
call
that's
all.
F
Yeah,
I
don't
have
an
answer
for
you
dinner
and
actually
you
are
the
multicast,
especially
so
I
would
one
and
ask
you
so.
The
the
esid
is
intended
to
address
at
least
three
problems
like
this
in
the
frequent
multicast,
the
split
rise
and
then
the
the
alliancing
on
on
the
on
the
80s.
E
F
E
But
I
didn't
suggest
it's
a
all
or
one
issue:
that's
how
we
could
solve
the
problem,
because
now
you
have
now
you
have
to
list
each
vlans
that
are
active.
Well,
you
have
to.
You,
have
to
potentially
have
up
to
4
000
entries
in
the
map
register,
which
makes
the
packet
really
large
right
and
even
if
vlans
are
not
in
use.
E
If
one
gets
configured
at
some
point,
you
have
to
know
who
the
designated
forwarder
is
at
at
the
you
have
to
do
it
before
you
configure
the
vlans
at
the
site,
I
think
or
you're
going
to
have
a
broadcast
loop
right.
F
Yeah
regarding
the
number
of
vlans
another
financial-
I
mean
I
so
can
you
have
really
like,
let's
say
a
registration
where
you
would
have
all
the
vlans
configured
at
once,
because
you
usually
you
send
a
a
registration
which
is
eid
to
unlock
right
and
then
we
need
to
add
an
identifier
to
to
map
the
airbox,
but
also
to
mount
the
the
id
for
the
aliasing
case.
F
E
Albert
it
doesn't
matter
if
it's
all,
it
could
be
50
and
that's
still
a
lot
right,
because
now
you
have
to
list
everything.
F
F
E
F
A
D
D
E
There's
one
there's
one
segment
id
per
map
register
where,
if
it's,
if
you're
going
to
put
multiple
mac
address
eids
in
the
map
register,
then
you
have
to
have
an
e
es
es
id
per
eid,
which
means
it
has
to
go
in
the
eid
record,
which
means
now
you
have
to
specify
wherever
an
eid
record
is
used
in
all
the
messages
you
have
to
specify
what
the
segment
id
is
and
for
layer
3,
you
don't
even
need
it.
So
you're
gonna
end
up
using
up
the
space
inefficiently
for
layer.
E
F
D
So
we
gathered
that
you
support
the
transfer.
We
are
stretching
it
a
bit.
Okay,
that's!
Okay!
I
think
we
have
an
action
dino
if
you
can
post
a
note
to
the
mailing
list,
regardless
scalability
considerations,
and
we
can
take
it
from
there.
F
So
now
very
timely,
right,
reliable
transfer,
solving
some
issues
like
two
large
map
registers,
so
next,
okay
yeah.
This
is
again
trying
to
summarize
or
address
some
changes
that
has
happened
on
the
draft.
Well,
I
mean
no,
no,
no,
but
in
the
mailing
list
that
we
have
discussed
since
last
itf.
Mainly
these
two
points.
F
That
is,
if
an
etf
supports
travel
transfer.
How
does
it
know
that
you
know
the
map
server
supports
it
too,
so
it
can
switch
to
rival,
transfer
and
and
then
the
question
about
what
about
other
transfer
protocols
that
are
not
just
tcp
and
we've
been
there,
the
main
the
main
example?
So
next,
so
the
problem
of
an
etr
that
wants
to
use
variable
transfer
but
doesn't
know
if
the
map
server
supports
it
right.
So
by
default,
the
atr
is
going
to
always
start
with
udp
map
registers.
F
That
is
what
the
protocol
specifies
and
at
some
point
it
needs
to
to
do
something
right,
so
it
can
switch
to
to
variable
transfer
if
the
maps
are
supposed
to
so
so
how
can
we
deal
with
this
next,
and
I
think
this
is
what
was
discussed
as
part
of
the
you
know
the
follow-up
front
from
last
meeting
that
is
okay.
F
We
have
some
bits
available
on
the
map
register
message,
so
we
could
potentially
use
one
to
signal
that
the
etl
wants
to
establish
a
reliable
transport
with
the
map
server
a
real
transformation
with
an
observer.
So
this
is
the
classical
discussion
that
we
have
had
in
you
know
multiple
times
in
the
working
group.
That
is,
we
set
up
a
new
bit
to
one.
If
the
and
we're
gonna
see
the
bits
in
in
the
next
couple
of
slides,
we
set
the
new
bit
to
one.
F
If
the
map
server
supports
drivable
transfer,
it's
gonna
reply
with
with
the
the
equivalent
bit
in
the
modified
set
to
one
as
well.
If
it
doesn't
superior
transfer
or
the
map,
server
is
another
one,
that
or
sorry
if,
if
it
supports
triable
transfer,
but
it
doesn't
want
enable
or
if
the
mapster
is
another
one
that
doesn't
supervise
transport,
then
the
maven
notify
is
going
to
come
back
with
the
with
the
bit
to
zero.
So
that
way
the
etr
knows
if
it
can
or
cannot
establish
a
available
transfer
session
with
the
windows
server.
F
So
next,
so
this
is
showing
the
possible
location
of
the
travel
transfer
bit
on
the
map
register.
We
seems,
which
seems
straightforward.
I
think
the
the
next
slide.
I
think
the
map
notify
one
may
be
more
interesting,
because
one
question
for
the
working
group
is:
where
do
we
put
the
bit
on
the
magnitude
five,
so
this
slide
is
showing
the
beat
in
the
same
position
as
in
the
map
registers,
it's
kind
of
mirroring
the
map
register
methods,
but
we
don't
need
to
put
it
there.
I
honestly
don't
have
a
strong
opinion
there.
F
E
I
think
it
should
be
that
lowercase
r
bit
in
the
map
notify
should
be
next
to
the
record
count
field,
because
if
you
need
to
use
more
bits
in
the
map
notify
you
want
to
keep
the
contiguous
bits,
there
say
you
need
10
bits.
F
F
Okay,
the
the
other
point
to
discuss
is
quick
support.
I
guess
that
there
are
two
questions
regarding
quick
and
I'm
not
a
quick,
especially
so
I
may
miss
some
some
aspects
here,
but
one
point
is
which
port
are
we
gonna
use
for
quick
rebel
transfer
right
for
tcp
travel
transfer
is
evident.
We
use
for
the
d42
in
tcp
and
that's
fine
for
quick.
Shall
we
reserve
a
different
port,
so
we
just
use
4342
udp
with
quick
on
top,
so
we
use
any
port
that
we
specify
as
default.
F
E
F
F
F
E
Let's
see,
if
you
want
give
me
the
phone,
you
don't
send,
an
application
doesn't
send
over
udp
and
then
sends
over
quick.
It
interfaces
with
quick,
directly
right,
but.
A
I
I
think
that
there
is
a
different
difference
between
the
quick
socket
that
you
open
and
you
decide
a
certain
port
number
and
what
is
going
on
the
wire
on
the
wire.
You
will
see
quick
with
the
port
number
quick
port
number.
Somehow,
I'm
not
sure,
I'm
not
an
expert
yeah.
There
is
just
a
wireless,
but
we
need
to
climb.
E
E
So
what
number
one
should
say
should
we
reserve
quick
port
4342.
A
F
E
Yeah
but
the
application
doesn't
care
about
it.
Just
like
the
application
doesn't
care
that
lisp
can
run
over
the
lisp.
The
application
that
runs
over
tcp
doesn't
care
that
tcp
runs
over
ip
just
like
it
shouldn't
care
that
quick
runs
over
udp,
because
it's
a
lower
layer
and
it's
not
it's
modular,
and
it
doesn't
need
to
know
that
information
and
shouldn't
touch
it,
because
the
one
who's
originating
the
udp
packet
is
the
quick
protocol.
G
E
F
So
I
think
that
we
are,
you
know,
going
to
a
more
fundamental
question
and
I
guess
this
may
be
a
quick
discussion,
but
so
tcp
and
gdp.
You
identify
those
by
the
protocol,
identifier,
right,
quick.
As
far
as
I
know,
and
I
may
be
completely
wrong-
it
has
no
protocol
identifiers.
You
have
a
udp
header
so
that
the
protocol.
E
F
On
the
other
side
of
the
question
is:
if
the
etr
supports
more
than
one
variable,
transfer,
typically
tcp
and
quick,
how
does
it
know
which
one
to
use
the
authors
of
the
graph
are
leaning
towards
leaving
this
and
implementation
choice
so
that,
if
you
support
two,
you
could
potentially
pro
four
four
for
those
two
and
and
pick
whichever
server
replies
or
whichever
you
you
like.
If
it
replies
the
two,
I
don't
know,
if
anyone
has
any
specific
opinion
on
on
this,
I
I.
A
Have
a
comment
on
this:
I
do
agree.
This
could
be
a
an
implementation
choice.
The
fact
that
you
don't
necessarily
need
to
implement
tcp.
You
don't
need
to
use
quick
as
long
as
you
have
the
basic
which
is
udp
now.
How
do
I
signal
that
I
can
do
more
than
udp.
This
goes
to
the
periphery
slide.
If
there
is
the
reliable
transport
beat,
it
does
not
tell
me
whether
I
should
use
tcp
or
quick.
A
F
A
A
It's
a
suggestion.
I
mean
this
may
be
I
I
can
send
an
email
on
the
mailing
list
so
that
we
discuss
this
point.
F
Yeah,
that's
that's!
That's
fine
yeah!
I
guess
that
we're
not
gonna
see
a
reset
transport
protocols.
Well,.
A
H
F
Oh!
No!
No!
There
is
a
very
final
question.
Sorry
yeah
yeah
working
group
adoption.
Are
we
fine?
Is
there
anyone
that
wants
to
say
something
before
we
call
for
a
working
group?
Foundation
of
the
document
have
been
sitting
as
an
individual
draft
for
too
long.
I
think
and
and
it's
becoming
more
and
more
relevant.
A
I
have
one
one
final
comments,
just
on
the
content
in
general
on
the
document.
These
are
about
the
security
part.
I
don't
remember
how
is
dealt
with
and
just
came
up.
To
my
mind,
I
mean,
if
we
use
tcp
me,
we
may
want
to
use
tls
in
order
to
secure
the
communication.
A
Okay,
but
I
I
would
put
it
as
a
action
item
that
we
check
whatever
should
be
done.
I
don't
I
don't
remember
to
be
honest,
yeah
yeah,
so
otherwise
we
we
got
stuck
somewhere
else
along
the
path
we
just.
We
know
how
it
works.
A
Yeah,
okay,
okay,
good!
As
for
the
adoption,
I
don't
think
there
is
any
issue
we
can.
We
can
call
for
adoption
here
now
and
then
check
on
the
mailing
list
as
usual.
Okay,
so
we'll
try
to
use
the
the
amazing
tool
that
that
we
have
here
for
to
check
for
adoption
this.
A
A
I
will
close
it
now
and
we
we
have
a
clear
consensus.
I
mean
I'm
not
sure
this
was
it
to
read
it,
but
and
ninety
percent
or
more
of
the
people
arise
there
that
participated
in
the
poll
lies
at
their
hands.
So
I
guess
at
this
stage
we
go.
B
E
Question
on
the
poll:
that's
assuming
yeah.
This
is
dino.
It
assumes
that
the
if
we
go,
the
reliable
transport
document
goes
working
group
document
that
the
best
documents
don't
reference
it
or
otherwise.
We
have
another
dependency,
correct.
A
E
A
I
Name
is
bennett
handle
first
time
at
the
itf
and
I'll
give
you
a
short
update
on
the
draft
handle
this
ground-based
rfc
about
the
mobility
and
multi-link
solution
for
safety,
critical
communication
aviation.
It's
a
specific
use
case
for
lisp
in
in
this
domain.
The
next
slide
please
and
the
search
structure.
I
want
to
give
you
an
overview
about
the
the
the
lisp
scope
in
in
this
specific
solution
and
the
concept
and
how
we
we
using
lisp
to
to
to
provide
multi-link
usage
and
the
local
policy
overwriting.
I
If
you
have
multiple
routing
links
to
the
aircraft-
and
I
want
to
conclude
with
with
some
standardization
requests
for
this
idea
troop
so
next
slide,
please
so
the
ground-based
lisp
soap.
We
are
mainly
working
here
for
safety,
critical
communication
in
aviation
and
the
ground-based
lift
solution
is
implementing
one
mobility
and
multi-link
solution
for
this
safety
grid
communication
aviation
and
we're
mainly
standardizing
this
on
ako.
I
This
system
enables
the
aircraft
and
the
ground
applications
and
hosts
to
use
multiple
air
ground
access
networks
during
all
phases
of
flight.
It
distributes
all
the
relevant
information
to
the
mobility
and
multi-link
decision
elements
which
you
will
just
explain
that
in
the
next
slide
on
ground
and
in
the
airport
ips
system,
so
one
specific
protocol
we're
using
for
exchanging
information
between
the
aircraft
and
the
ground.
I
It's
called
the
air
ground,
mobility
interface
protocol,
that's
a
domain
specific
protocol
and
we
will
only
specify
this
in
iko
and
it's
not
focus
here
in
itf
and
we're
not
planning
to
to
standardize
this
here
and
we
are
using
lisp
here
mainly
to
distribute
all
the
information
from
this
acme
proxy
to
the
egg.
That's
located
in
the
access
networks
to
the
to
the
ground,
ground
border
routers,
which
are
lisp
xdr
routers
and
this
ground
ground
border
routers,
the
multi-link
policy
enforcement
points
for
the
uplink
traffic.
I
I
think
this
will
be
more
clear
in
the
next
slide
when
you
see
the
architecture
things
next
slide,
please.
So
here
we
see
the
reference
topology,
it's
subdivided
in
four
segments.
On
the
left
side,
you
see
the
the
aircraft
segment
where
we
have
an
810
ips
system,
and
we
have
here
a
downlink
decision
and
enforcement
point,
and
the
aircraft
is
typically
connected
to
multiple
via
different
radio
access
technologies
to
multiple
so-called
airground
communication
service
providers.
I
I
I
The
end
point
in
the
aircraft
is
sitting
in
the
in
dayton
ips
system
and
with
this
domain
specific
protocol,
we're
exchanging
all
the
information
to
the
acme
ground
proxy,
which
then
forwards
this
to
the
next
segment,
which
is
the
lisp
segment
and
that
that's
right
called
ground
based
since
all
the
lisp
elements
are
located
here
on
ground,
there's
an
alternative
proposal
where
all
the
lisp
elements
located
in
the
aircraft
and
finally,
the
last
segment
is
then
the
operator
and
the
user
segments-
that's
mainly
nsb,
so
air
navigation
service
providers
like
fva
or
not
or
airlines
like
lufthansa
or
british
airways,
and
so
on.
I
I
So
this
is
a
unique
globally
unique
ipv6,
prefix
administratively
assigned
to
an
aircraft
so
which
the
aircraft
is
using
for
communication
during
all
the
phases
of
flight,
and
this
is
60
ip
version,
6
prefix,
which
is
used
from
the
ip
version
6
area
that
is
iko
asking
from
epic
address
space.
So
next
slide.
Please.
I
Thanks
so
a
few
words
about
the
concept,
so
typically,
the
aircraft
starts
with
attaching
to
one
or
more
of
this
airground
access
networks,
mainly
by
using
specific
radio
access
technology.
Specific
means
it
needs
typically
to
authenticate
to
the
to
the
access
network
and
then
the
access
network
forwards.
Typically,
that
announces
that
this
mobile
network
prefix
is
reachable
over
the
specific
airground
access
network
and.
I
I
In
addition,
where
the
acme
protocol,
we
also
exchange
information
like
then
the
link
status
and
some
specific
traffic
scope,
traffic
scope
here
summarized
by
a
sub
mmp.
I
So
this
information,
then,
is
sent
to
the
acme
ground
proxy
and
the
acme
ground
proxy.
We're
currently
using
a
northbound
interface
to
forwarding
this
and
mapping
this
information
to
the
lisp
control,
plane,
mapping
the
preferences
to
list
priorities,
and
this
can
be
used
by
the
ground,
ground
router.
So
the
list
peaks
they
are
on
the
other
side
to
getting
all
the
preferences
and
can
can
use
this
preference
for
uplink
routing
decisions
for
that
we're
using
the
pubs
up
mechanism.
That
means
the
ground
ground.
Router
subscribes
to
the
mmp.
I
I
So
this
is
the
multilink
usage.
That
means
the
preferences
are
sent
down
and
in
this
example,
the
aircraft
sending
a
preference
for
for
the
sub
network
a1
should
be
using
the
upper
the
lower
the
green
one.
The
lower
axis
network
and
the
sub
prefix
a2
should
use
the
the
upper
access
network,
and
the
decision
in
point
is
the
ground
ground
router.
I
So
it
receives
all
the
preferences,
the
mappings
from
the
eid,
so
the
mobile
network
prefix
and
all
the
sub
mmps
the
sub
networks
at
the
cache
in
the
cache
of
the
ground,
ground
router,
and
it
using
this
to
make
the
decision
that
the
a1
traffic
should
be
forwarded
over
the
airground
xsb
and
then
day.
Two
traffic
should
be
forwarded
over
the
axis
network,
a
so
that's,
mainly
the
multilink
that
we,
how
we're
using
a
lisp
for
for
for
a
multi-link
scenario,
and
so
the
next
slide.
You
have
three
minutes.
A
I
I
It
should
also
go
over
the
access
network,
so
that
means
we
need
for
this,
but
this
a
policy
decision
point
which
is
located
somewhere
in
the
in
the
in
the
atso
domain
and
with
this
it
reads
out
the
preferences
from
the
coming
from
the
aircraft
and
is
able
to
override
this
by
by
the
local
policies,
and
for
that
information
doing
so
we
need
some
additional
information
that
just
results
in
the
last
slide.
It's
the
next
one!
Thank
you.
I
So
this
is
what
we
are
requesting
from
the
our
support
from
the
from
the
itf
from
the
list
working
group.
The
most
important
point
is
that
we
need
in
our
domain
standards
for
the
lisp
control
and
data
blame
protocol,
so
the
lack
of
these
standards
is
currently
the
major
risk
for
our
ground-based
lisp
solution.
So
that's
an
absolute
must
so
that
the
rc,
6830
and
6833
should
go
on
the
standard
track.
Without
that,
it's
very
difficult
for
us
to
use
this
that
pops
up
publish
subscribe
functionality
for
lisp.
I
Digital
signatures
should
be
forwarded
from
the
aircraft
over
the
acme
to
the
ground,
ground
router
over
the
lisp
control
plane.
So
if
there
existing
a
mechanism
to
allowing
that,
that
would
help
to
use
lisp
for
that.
Otherwise
we
have
to
use
an
alternative
solution
for
that,
and
we
would
also
like
to
get
an
advice
from
you.
I
If
you're
either
giving
this
in
a
specific
change
requests
to
the
to
the
to
the
itf
to
the
list
by
deaf
working
group
or
an
alternative
approach,
we
could
create
an
experimental
ifc
for
multi-link
mobility
that
more
or
less
describes
the
needed.
The
additional
needed
additional
needs
and
we
referencing
to
the
all
the
other
rfcs
generic
pops
up
and
mobility
rushes.
I
H
Yeah,
this
is
albert
akavedo.
Thanks
for
your
presentation,
I
think
it's
a
very
interesting
use
case
and
also
thanks
for
the
for
this
slide.
I
think
it's
super
clear
what
you're
asking
and
that's
always
something
which
is
good,
I'm
curious
about
the
well.
The
first
bullet
point.
I
cannot
comment,
maybe
which
you
can
comment.
I
think
it
is
what
it
is
and
the
last
one
I
don't
have
any
opinion
either,
but
regarding
the
public
subscribe,
could
you
elaborate
a
little
bit
further
on
the
selective,
subscribe
and
explicit
selective
and
subscription
and
wildcard?
I
J
H
42.,
okay
and
then
the
digital
signature.
I
don't
understand
it
either.
I
Yeah,
the
digital
signature
is
something
that
some
users
on
ground
would
like
to
verify
if
there
come
preferences
from
the
aircraft
to
the
ground,
how
the
uplink
traffic
should
should
be
sent
that
this
is
forwarded
over
the
acme
over
the
lisp
domain,
to
the
to
the
faa,
for
example,
to
the
absolute
domain,
and
they
want
to
verify
that
this
message
comes
originally
from
the
aircraft.
That
means
it's
signed,
digitally
signed,
and
this
should
be
forwarded
over
all
the
different
protocols.
Currently
we're
doing
this
over
the
domain-specific
acme.
I
But
there
is
no
way
to
forward
this
over
lisp.
It
would
help
us
if
we
have
a
specific
part
of
lisp,
where
we
can
use
a
specific
data,
forwarding
user-specific
data
over
the
mapping
system
to
all
the
extras.
Okay,
but
that's
just
yeah.
It
would
make
it
simpler
for
us,
otherwise
we
need
an
alternative
protocol
yeah.
I
understand
yeah.
Thank
you
so
much.
I.
A
C
G
Okay,
so
the
main
purpose
of
this
discussion
now
is
there
is
no
change
to
the
rfc
draft
list
next
to
a
network
hexagons
it's
in
the
viral
queue,
but
there
is
a
lot
of
progress
in
the
industry
which
I
want
to
update
you
and
experience
we're
getting
by
deploying
with
multiple
carriers
in
japan
in
the
us
with
aws
wavelength.
G
So,
basically,
sorry,
this
thing
doesn't
the
listener
is
not
something
on
its
own.
It
fits
to
industry
consulting
work
in
the
auto
edge
industry
which
aims
to
unify
what
is
termed
vtv
or
vehicle-to-vehicle
architecture
where
vehicles
tell
each
other
about
immediate
problems
which
doesn't
work
and
v2c,
which
is
an
aggregation
into
the
cloud
by
all
vehicles.
G
Overnight
takes
a
few
days,
so
we
are
able
to
unify
with
the
immediacy
and
programmability
the
immediacy
of
b2v
the
probability
of
vehicle
to
cloud,
but
eliminating
the
ability
impossibility
of
v2v
every
car
gets
multiple
points
of
view
over
the
same
things
from
beyond
life
on
site,
which
is
a
big
problem
and
the
lag
of
the
cloud
using
one
architecture.
G
Sorry,
sorry,
the
question
is
was
over
launched,
so
why
do
we
tie
this
whole
structure
with
application
routing
and
not
with
kafka
and
database
queues
and
all
these
mechanisms?
And
let
me
try
to
clarify
that
so
try
to
do
it
as
quickly
as
I
can
so.
First
of
all,
the
volume,
if
you're
talking
about
a
city
of
a
million
active
vehicles
like
paris
la
and
I
want
to
use
10
of
their
vehicles
to
sample.
What's
going
on
for
double
parking
hazards,
blockades
sudden
stops
things
like
that.
G
Then
I'm
talking
about
in
any
given.
Second
10
of
the
vehicles
are
sampling
they're
moving
at
30
meters
per
second,
they
need
10
frames
per
second
in
order
to
capture
a
point
of
interest.
That
means
a
million
frames
per
second
for
the
city
and
half
a
terabit
okay.
These
are
have
to
be
processed
by
gpus.
G
The
best
case
for
gpus
is
a
thousand
frames
per
second.
That
means
I
have
to
really
distribute
between
multiple
sites
in
the
city.
That's
routing,
that's
not
a
kafka
job,
and
then
I
have
to
consolidate
this
amount
of
traffic
in
the
city.
So
I
can
upload
just
the
exceptions
and
changes
to
the
cloud
using
one
gigabit
links,
okay
on
the
downstream
next
time
on
the
downstream.
G
If
I
have
a
million
vehicles
that
over
the
next
second
are
going
to
be
in
10
tiles,
depending
on
the
traffic
pattern,
and
I
have
a
thousand
active
events
in
the
city
of
people,
unloading
loading,
making,
offenses
jaywalking
affecting
a
hundred
tires
each
that
every
second
I
have
to
calculate
a
joint
over
a
million
vehicles
times
a
thousand
events
at
a
billion
times
a
thousand
times.
It's
a
trillion,
that's
impossible
to
do.
The
only
way
to
do
it
is
using
feeds
which
are
already
pre-joined,
multicast
fields
and
scenario.
G
Application
multicast
feeds
that
scales
really
well
all
right.
So
that's
why
application
routing
it
relates
to
a
lot
of
the
discussions,
these
ideas.
What
do
we
get?
We
get
something
like
an
air
traffic
control
for
the
city,
so
just
like
in
air
defense
missile
defense,
I
separate
the
space
into
zones
so
to
know
what's
going
on
in
real
time.
G
G
That's
the
only
way
to
scale
av
density,
not
to
get
avs
into
situations
which
are
hard
to
get
out
of,
because
then
I
can
gridlock
the
city
when
the
number
of
avs
goes
up
and
also
reduce
the
cost
of
an
avr.
I
cannot
have
a
10
000
car
with
a
ten
thousand
dollar
computer.
So
that's
what
we're
after
slide
down
the
way
we
do
it
is.
G
G
There
is
a
nice
animation
here
of
a
car
driving.
You
can
check
it
out
offline.
We
cannot
do
it
here,
but
the
rtrs
are
steering
the
uploads
to
the
hexagons,
where
all
the
uploads
for
a
given
location
are
being
processed
and
consolidated.
G
G
This
is
trying
multiple
providers
there's
a
lot
of
edge
providers
in
the
game
right
now
also
amazon,
but
it's
not
the
only
game
like
in
cloud.
The
oems
have
computational
facilities
in
the
city,
other
companies,
and
this
is
a
trial
going
on
in
japan.
There
is
a
deployment
in
new
york
and
there's
a
big
trial
going
on
in
nevada
with
with
aws
next,
okay,
so
just
to
understand
what
does
application
routing
solve
here
list?
G
So
in
a
cloud
situation,
I
load
balance
clients
between
servers,
okay,
because
it's
all
shared
storage
in
an
edge
situation
like
this,
I
cannot
load
balance
the
clients.
These
clients
have
to
be
in
this
service.
These
clients
have
to
be
in
this
service
because
there,
the
service
is
the
location
has
to
consolidate.
G
I
have
a
problem
of
geoprivacy
associating
with
a
service
means
that
if
I'm
subscribed
to
a
parking
service,
the
parking
service
providers
knows
where
I
am
all
day
long,
that's
impossible.
When
I'm
driving
between
location,
I'm
changing
context,
that's
a
dns
multi-second
break
in
the
service,
that's
unacceptable!
This
is
all
that
and
if
I'm
changing
carriers,
I'm
changing
my
identities
and
that's
unacceptable
and
they
saw
that
sharon.
G
Just
a
few
two
sides
or
three
slides.
So
let's
solve
all
these
problems.
Next,
okay,
if
I
put
this
in
the
mac,
then
I
have
a
terabit
per
second
from
the
mobile
core
split
into
using
metro
ethernet
to
the
local
zones
and
solving
the
capacity
problem.
Well,
next,
I'm
solving
the
queuing
problem.
If
I
have
a
q
per
vehicle
at
5
megabits
per
second
10
microseconds
10
milliseconds
a
way,
and
I
optimize
the
queuing
from
the
uplink
using
rtrs.
G
G
It's
really
important
to
understand
that
this
is
just
one
piece
of
this
industry
specification,
but
it's
the
connector
between
auto
edge
and
3gpp.
Why?
Because
3gpp
interface
is
to
an
application
server.
There
is
no
application
server
for
the
distributed
edge,
application
application
routing
is
the
application
server?
Okay,
that's
it.