►
From YouTube: IETF108-LISP-20200729-1300
Description
LISP meeting session at IETF108
2020/07/29 1300
https://datatracker.ietf.org/meeting/108/proceedings/
A
Okay,
it
looks
like
it's
the
top
of
the
hour
and
we
have
a
good
number
of
people
just
on,
and
this
is
your
co-chair,
joel,
halper
and
luigi.
You
want
to
get
get
us
started.
C
C
C
Well
albert
will
give
us
a
quick
update
which
leads
us
to
the
agenda
so
actually
just
for
clarity.
There
was
no
call
for
agenda
items
this
time,
because
we
we
thought
that
the
interim
meeting
was
pretty
good
because
it
was
short
and
focused
on
few
items,
so
we
we
decided
to
keep
it
in
that
way.
So
we
will
have
just
part
of
the
session.
We
will
talk
about
the
not
traversal
problem
and
the
other
part
is
the
least
overlay.
C
Okay,
just
after
the
update
on
the
beast
documents
by
albert
okay,
so
I
will
move
forward
and
go
directly
to
the
slides.
B
D
A
Perfect
and
just
so
folks
know,
I
will
be
monitoring
the
chat
and
monitoring
the
queue
and
when
people
want
to
talk,
I
will
give
you.
I
will
enable
you
and
tell
you
you're,
enabled.
E
Great
thanks
so
hello,
so
this
is
the
usual
update
on
the
documents.
I
will
be
super
brief
because,
as
we.
A
E
Out,
I
think
it's
worth
to
put
time
into
the
discussion
so
next
slide.
Please.
E
So
I
just
posted
the
two
new
versions
a
few
hours
ago,
so
this
is
number
33
for
the
data
plane
and
number
28
for
the
control
plane,
and
this
is
addressing
the
new
ilg
comments
and
discuss
that
we
have
received
which
were
not
a
bunch
of
them.
They
were,
I
will
say,
quite
minor,
so
next
slide.
E
So
this
is
a
summary
of
the
changes
for
the
data
plane,
so
I
have
added
a
section
stating
the
guidelines
for
deployment
over
the
public
internet,
which
means
that
in
the
data
plane,
the
n,
l,
e
and
b
bits
needs
to
be
zero,
because
you
must
not
so
we
have
elevated
from
should
not
to
must
not
use
a
locators
attribute
switch
equinox
cleaning
map
versioning
and
instead
you
should
rely
on
control
plate
mechanism.
This
is
by
re
per
request
of
the
reviewers.
E
Also,
the
stateful
mtu
algorithm
only
now
works
for
ipv4
and
not
for
ipv6,
and
also
a
recommendation
to
consider
the
ipv6
flow
label
for
load
balancing
hashing
when
you
hash
towards
different
lock
when
you
load
balance
towards
different
locators
and
then
a
bunch
of
editorial
and
minor
updates.
So
next
slide
please.
E
So
this
is
for
the
control
plane.
Similarly,
to
data
plane,
we
have
added
a
section
stating
that
what
communicating
over
the
public
internet
list
this
must
be
implemented.
E
So
you
need
to
set
the
s
bit
on
map
reply,
map,
resistor
and
ecm,
and
also
by
request
from
the
reviewers
that
we
should
use
the
stronger
hmac
and
kdi
function
and
and
in
those
cases,
must
not
use
an
algorithm
that
does
not
use
a
kdf
function
and
then
a
bunch
of
minor
editorial
updates.
E
So
that's
it
from
my
site.
I
don't
know
if
there
is
any
comment
or
question.
F
G
No,
I
just
wanted
to
maybe
add
about
this
gp.
We
are
also
done
with
all
the
comments
I
believe
the
last
one
were
from
magnus
and
roman
that
have
been
addressed
in
the
version
published
on
monday.
G
C
H
Can
you
you
can
hear
me,
though
right
yeah,
we
can
hear
you:
okay,
okay,
I'm
just
gonna
give
a
pretty
brief
presentation
on
the
whispers.net
nat
traversal.
How
much
time
do
I
have.
C
H
Okay,
so
this
is
a
net
implementation
that
I've
done
next
slide.
H
The
purpose
of
the
I
so
I
wrote
a
a
small
draft
and
the
purpose
of
the
giraffe
is
to
describe
a
simple
version
of
nat
traversal
and
it's
a
it's
based
on
a
subset
of
procedures
and
message
formats
from
the
list
that
traversal
that
veena
and
company
there's
many
authors
on
it,
wrote
many
years
ago
and
the
lispers.net
deployment's
been
around
since
2014,
and
it's
been
used
pretty
heavily
in
and
daily.
It's
it's
still
quite
a
bit
in
use
next
slide.
H
Okay,
so
the
the
requirements
to
do
adequate
natural
traversal
is
to
have
an
xctr
function
according
to
6830
bis
and
33
bis
when
it
sits
behind
a
on
that
device.
H
So
the
requirements
that
I
set
out
that
I
thought
was
important
for
robust
deployments,
was
to
have
an
xtr
function
when
it
sits
between
itself
and
the
infrastructure
via
that
device
that
can
be
directly
connected
to
it
or
multiple
hops
away.
H
The
xtr
must
function
when
it
runs
in
a
list:
mobile
node,
in
other
words
running
not
just
as
a
router
type
device,
but
it
when
it's
running
in
a
host
in
either
bare
metal
form
on
a
mobile
device
in
a
vm
or
a
container,
like
I
said
logically
or
physically,
the
xtr
must
function
when
it
resides
behind
multiple
nat
devices
between
itself
and
the
rtr.
H
So
double
and
triple
nats
are
kind
of
the
norm
today
on
the
internet,
so
it
must
function
in
that
sort
of
scenario
as
well,
usually
when
an
xtr
is
like
behind
a
home
gateway,
it's
behind
the
nat
that
it's
at
its
house
and
if
it
needs
to
talk
to
an
rtr,
that's
in
a
cloud
provider,
it's
yet
behind
another.
The
rtr
is
behind
and
that
has
been
protecting
the
cloud
infrastructure.
So
the
double
nat
is
is
quite
a
popular
deployment
scenario.
H
The
xtr
must
function
when
it
is
multi-home
between
different
nat
devices.
So
I've
done,
my
house
has
two
internet
connections,
or
at
least
it
did.
One
was
cable
and
one
was
dsl
and
I
would
have
nat
devices
from
each
of
those
service
providers
and
had
an
xtr
that
was
dual
home.
The
ethernet
to
each
one
of
those
very
much
like
a
single
site.
H
Router
would
be
dual
home
to
different
service
providers
on
a
lisp
site,
but
then,
of
course,
there's
nats
connecting
these
also
rtrs
and
pxtr's
must
function
behind
nats
because
of
how
cloud
deployment
has
developed
over
the
last
decade,
or
so.
The
lisp
internet
groper
list
lig
function
must
send
requests
when
it's
behind
a
nat
regardless,
if
it's
a
lispex,
tr
or
not
the
tool
is
an
independent
tool
that
can
run
anywhere.
H
Okay,
so
this
is
just
a
simple
protocol
exchange
sequence
before
we
look
at
a
visual
of
it.
Basically,
when
an
xdr
comes
up,
it
periodically
will
send
an
info
request
message
that
was
that
info
request
is
defined
in
the
nat
traversal
internet
draft.
That's
been
sitting
as
a
individual
contribution
for
a
while.
It
sends
the
info
request
to
a
destination
port
of
4342
to
the
map
server
ip
address.
H
This
is
so
the
map
server
can
reply
with
a
list
of
our
rtrs
in
an
info
reply
message.
The
list
of
rtrs
is
usually
a
policy
parameter
and
configuration
information
on
the
map.
Servers
that
this
xtr
is
using
once
the
list
of
rtrs
is
returned
from
the
map
server.
The
xtr
then
sends
an
info
request
to
the
destination
port
4341
to
each
rtr.
H
This
is
probably
the
most
critical
part
of
the
nat
traversal,
because
this
allows
the
nat
to
install
forwarding
entries
or
access
list
entries,
whatever
you
want
to
say
so,
when
an
rtr
then
has
to
forward
back
it
forward
packets
to
the
xdr
through
the
nat
that
it
would
send
packets
from
port
4341,
the
source
port
of
4341
and
the
destination
port
would
be
the
translated
port
that
was
translated
by
the
nat
device
sitting
in
between
so
remote
rtrs
that
want
to
send
to
eids
behind
this
xtr,
that's
behind
the
nat
encapsulate
to
rtrs
and
the
rtr's
d-cap
and
re-encap,
so
they
can
send
to
the
xtr's
translated
arlo.
H
So
the
rtr
is
encapsulated
to
the
translated
address
and
port
that
would
be
in
the
destination
address
field
of
the
ip
header,
as
well
as
the
destination
port
of
the
outer
udp
header
and
then
xtrs
will
map
register
the
list
of
rtrs.
They
were
given
as
well
as
translated
our
loc.
It
knows
what
it's
translated.
Our
looks
are
from
the
info
reply
that
comes
back
from
the
map
server
and
the
port
number
that
is
in
the
payload
of
the
info
reply.
H
So
it
knows
how
to
register
the
translated
address
information
and
then
xtr
is
for
sending
packets.
We
everything
we
explained
so
far
is
so.
Packets
can
come
to
the
xtr
from
the
infrastructure
into
the
private
area
behind
the
net
when
an
xtr
wants
to
send
packets
the
other
way
it
just
has
a
default
set
of
map
cache
entries
where
it
just
simply
encapsulates
to
rtrs.
H
But
you
know
the
xtrs
can
encapsulate
to
any
other
devices
anywhere
else
if
they
are
not
sitting
behind
x
behind
gnats,
so
they
could
have
either
shortcut
entries
or
direct
entries
to
those
non
nat
xtrs.
As
I
indicated
on
the
last
bullet.
Okay,
let's
go
to
the
this
slide.
The
next
slide.
I'm
sorry.
H
So,
let's
look
at
a
time
sequence
here,
basically
explaining,
but
now
you
can
see
it
in
visual
form,
I'm
explaining
everything
I
did
on
the
last
slide.
Let's
look
at
the
white
lines
first,
because
that's
basically
the
controlled
traffic.
You
see
the
xtr
on
the
bottom.
H
H
That
happens
at
time,
one
it
sends
it
to
the
mapping
system
when
I
say
it
sends
it
to
the
mapping
system.
It's
configured
set
of
map
servers
that
it's
registering
to
is
where
the
info
request
is
sent.
So
multiple
info
requests
could
be
sent
to
multiple
map
servers.
The
map
server,
like
I
said,
is
configured.
If
you
I
don't
know,
if
you
could,
you
can't
see
my
pointer
as
I'm
moving
it
is
that
true?
H
Yeah,
okay!
Okay,
so
if
you
see
the
right
under
the
mapping
system,
I
I
I
say
the
map
server
rtr
list
is
artr1
artr2
and
artr3.
H
That's
just
a
configured
list
of
what
it's
going
to
return
in
info
replies.
So
at
time,
2
in
white,
you
see
that
list
being
returned
so
at
at
time.
Three,
then,
basically,
what
the
xtr
has
is
a
list
of
rtrs,
as
well
as
the
translated
information.
So
now
we
can
register
eid1
with
four
locators
in
the
in
the
locator
center.
H
The
irlok
set
the
three
rtrs
as
you
see
that
I
set
to
priority
254,
because
that's
a
way
to
identify
rtrs
that
are
in
the
list
versus
translated
our
logs
and
the
last
rlok
that
you
see
there
called
tr,
loken,
p
and
tr
loc
is
the
translated.
Our
look
only
not
the
port
number.
The
port
number
is
learned
by
the
rtr
when
the
info
requests
are
sent
to
43
41,
which
is
the
other
three
in
the
bottom
bottom
left-hand
corner
at
time.
Three,
there,
okay,
so
the
mapping
system,
obviously
stores
what's
being
registered.
H
You
see
that
on
the
upper
right
hand,
side
of
the
diagram,
so
the
info
requests
then
are
sent
to
4341,
and
it's
you
see
the
three
white
arrows
going
for
the
from
the
xtr
to
a
rtr1,
rtr2
and
rtr
iii.
That's
to
allow
the
nat
to
install
state,
so
those
guys
can
encapsulate
to
the
xtr
behind
the
nat,
and
that's
that
happens
at
those
white
lines
right
there.
Now.
H
Let's
use
an
example
where
eid
3
wants
to
send
a
packet
to
eid1,
so
that
eid
3
is
an
xtr,
and
I
show
it
there
that
it's
not
behind
in
that
it's
just
a
remote
itr
out
on
the
internet
somewhere,
that's
part
of
the
overlay
and
when
it
wants
to
be
able
to
send
the
eid1,
it
doesn't
have
a
map
cache
entry.
What
it
does
is
it
looks
up
eid
one
in
the
mapping
system,
so
it
sends
a
map
request
to
the
mapping
system.
What
the
map
server
will
do.
H
The
top
number
four
returns
a
list
of
rtrs
and
does
not
return
the
translated
r
log.
So
what
I
call
this
is
the
map
servers
return
a
partial
arlo
set
depending
on
who's
requesting,
since
xtr
is
not
the
ip
address.
That's
in
the
lex
list
of
rtrs
the
map
server
will
return
the
list
of
rtrs,
so
that
xtr
then
could
encapsulate
to
one
of
the
three
rtrs
and
it
load
splits
based
on
a
five
tuple
hash
across
those
rtr.
So
you
have
a
cluster
and
can
spread
on
the
load
if
the
xtr.
H
If
the
okay,
I
think
I
that
the
other
number
four
points
to
the
rtr,
but
it
oh
yeah.
That's
that's
correct!
If
x,
if
eid,
two
that's
sitting
behind
an
xtr,
that's
behind
in
that
makes
the
same
sort
of
request.
He
gets
the
same
map
reply
back.
It
doesn't
matter.
If
he's
from
behind
a
nat
or
not,
he
gets
the
same
type
of
reply
as
the
eid
3,
because
the
only
way
he
could
get
packets
through
the
nat,
where
eid
1
is,
is
by
encapsulating
to
the
rtr
one
two
and
three
okay.
H
So
both
eid,
2
and
eid
3
have
to
encapsulate
at
red
number
line,
1,
okay
and
use
the
services
of
the
rtrs
if,
if
a
packet
comes
to
okay,
so
let's
say
this
packet
comes
to
rtr3
and
rtr3
doesn't
have
a
map
cache
entry
for
eid1.
H
What
it
does
is
it
sends
a
map
request
to
the
mapping
system.
In
this
case,
the
mapping
system
returns
just
the
translated
our
lock
information,
because
rtr3
is
in
the
list
of
rtrs
and
the
map
server
assumes
that
he
has
pierced
the
hole
through
the
the
through
the
nat,
because
the
xtr
sent
the
info
request
so
when
he
simply
receives
a
packet
from
either
the
eid2
or
the
id3,
he
can
encapsulate
to
tr
lock,
which
is
the
translated
our
look
and
he
has
the
translated
port
number
from
the
info
request.
H
E
Yeah
thanks
so
good
morning,
dino!
So
is
there
any
authentication
between
the
xtr
and
the
rtx.
E
Yeah,
but
my
understanding
is
that
we
went
through
through
several
discussions
regarding
public
internet
deployments
and
in
my
video.
Clearly
not
traversal
is
super
important
when
you
are
dealing
with
mobile
nodes
which
are
on
the
white,
meaning
that
rtr
should
be
deployed
on
the
public
internet
and
access
not
deployed
accessible
through
the
public
internet
and
the
fact
that
there
is
no
authentication
means
that
and
correct
me.
If
I'm
wrong,
that
anyone
can
use
it
as
a
sort
of
a
proxy
right
to
hide
its
own
ip.
H
Well,
we
can.
We
can
authenticate
map
requests
and
map
register
messages
using
the
by
signing
them
using
the
the
ec
dcs
authentication
draft
that
we
put
out.
So
not
anybody
can
get
a
map
reply,
eid,
3
and
eid
2.
if
their
public
keys
are
in
the
mapping
system
and
they
sign
those
map
requests.
That
means
they
may
they're
allowed
to
use
this
particular
eid
that
and
the
map
map
servers,
which
are
also
map,
resolvers
verify
the
signatures
in
the
map
request.
H
If
they
verify,
then
that
means
they're
allowed
they've
authenticated
and
are
part
of
a
some
kind
of
access
list
to
be
permitted
to
use
those
rtrs.
So
we
could
use
that,
and
I
and
my
implementation
does
support
that,
because
I
support
the
authentication,
regardless
of
what
of
what's
being
returned
to
any
itr.
If
it's
behind
in
that
or
not.
E
So
what
the
other
draft
is
doing
is
that
the-
and
I
hope
that
I
recall
correctly-
is
sending
the
map
resistor
through
the
rtr
encapsulated
and
then
the
rtr
is
looking
at
the
bum
notify
and
we
are
using
the
secret
association
between
the
hdr
and
the
map
service
and
the
map
server
to
authenticate
the
rtr.
H
Yeah
now
you
have
to
put
the
rtrs
as
part
of
the
control,
plane,
authentication
path,
and
we
never
had
to
do
that
before.
So
I
wanted
to
stay
with
the
current
model,
where
we
don't
have
a
third-party
hairpin
in
terms
of
control.
Plane
rtrs
up
to
now
have
always
done
data
plane
only
stuff
and
they
get
all
their
control
information
directly
from
the
mapping
system
as
well
as
all
xtrs.
So
I
stayed
with
that
homogeneous
model.
H
Well,
I
mean
somebody
has
to
ask
the
question:
is
lists
going
to
work
on
the
public
internet
or
not
in
general,
and
if
you're
going
to
say
no,
because
the
the
best
drafts
are
saying
pushing
back
a
little
bit
by
saying
it's
not,
then
why
would
the
nat
traversal
document
have
to
support
the
public
internet
so,
and
I
think
we
need
to
be
consistent
about
that
on
both
ends,
so
obviously
by
using
by
nat
traversal
you're.
H
Assuming
that
you
have
some
form
of
protection,
you
know
security
throughout
purity
and
that
you
want
to
go
into
public
environments.
But
you
know
public
environments
could
also
be
an
enterprise
network.
That's
using
that
for
whatever
reason,
because
of
it,
it
doesn't
have
enough
ipv4
addresses
or
whatever
or
it's
not.
E
Using
the
problem,
I
need
to
make
a
circular
classification,
so
the
base
documents
are
not
saying
that
lisp
is,
cannot
work
over
the
public
internet,
but
rather
that
some
mechanism
expected
in
that
specified
list
must
not
be
deployed
when
using
it
when
using
it
over
the
public
internet.
But
this
can
work
over
the
public
internet
with
lisp
sec
and
so
on.
H
So
these
are
some
design
observations
that
I
can
conclude
with.
So
the
first
point
is
that
the
the
itr
has
a
very
small
map,
cache
it
since
the
itr
behind
and
that
virtually
runs.
H
I
can't
see.
I
can't
read
it
because
it's
too
small
hold
on
a
second
okay
run:
snow
control,
plane.
It
has
a
very
simple
data
plane.
All
it
does
is
arlo
probe
the
rtrs
in
the
common
set
and
maintains
a
very
small
map
cache.
So
you
could
put
very
lightweight
devices
behind
nats,
which
we
may
want
to
do
for
cell
phones
or
dash
cams
or
iot
type
gateways
and
devices
that
we've
tried
to
deploy
over
the
years.
H
So
it's
nice
to
have
a
a
small
map.
Cache
point
number
two:
is
that
the
xtr
that's
behind
it.
Nat
can
tell
another
xtr
behind
the
same
set
of
nat
devices
so
by
by
returning
by
returning
private
our
locks
in
the
info
reply,
you
could
determine
that
a
net.
Another
xtr
is
behind
the
same
nat
as
you,
and
then
you
can
actually
encapsulate
to
the
local
to
the
local
private,
our
loc,
and
then
you
have
a
short
cut.
H
So
that
means
any
packets
between
two
xtrs
don't
have
to
hairpin
through
the
nat
to
the
rtr
and
back
because
they're
actually
at
the
same
site
and
that's
been
proven,
useful,
useful
to
determine
to
use
more
optimal
paths.
H
Point
number
three:
if
an
xtr
has
a
direct
path
to
a
lisp
site,
it
could
then
send
directly-
and
that
was
the
case
where
this
xtr
behind
and
that
wants
to
be
able
to
talk
to
a
remote
etr.
But
since
it's
not
behind
a
a
nat.
It's
our
look
is
a
global,
our
loc
and
doesn't
ask
to
traverse
the
nat
on
that
side.
So
you
can
encapsulate
directly
to
it
without
having
to
go
to
the
rtr.
H
Okay,
yeah,
I'm
pretty
much
done.
I
just
have
to
go
through
these
couple
bullets
and
I'll
be
done
by
sending
info
requests
to
map
servers.
If
they're
also
used
as
map
resolvers,
you
can
use
the
info
request
info
reply,
exchange
as
a
reachabil
as
a
simple
pinging
or
keep
a
live
reachability
mechanism
to
know
that
map
resolvers
are
up,
and
if
you
don't
get
replies,
you
could
time
them
out
and
avoid
sending
map
requests
to
those
down
map
resolvers.
H
I
also
implemented
list
crypto
through
this
as
well,
because
you
there's
no
reason
why
you
can't
do
a
diffie-hellman
exchange
between
these
global.
Our
look
addresses,
as
you
see
them
locally,
so
you
can
encapsulate
encrypt
and
then
encapsulate
packets
that
go
through
one
or
more
gnats
or
gnats
on
one
side
and
and
no
nets
on
the
other
side.
H
The
second
to
last
point
is:
what's
really
interesting
is
since
the
rtrs
are
the
only
ones
that
are
keeping
the
global
arlo
information
of
xtrs
behind
gnats
as
those
xtrs
move
around
which
they
do
in
containers
in
cloud
environments
or
list
mobile
nodes
when
they
register
their
new
rlok
because
of
the
movement.
Only
the
rtrs
have
to
be
updated.
So
if
there's
thousands
of
remote
itrs
that
are
sending
eid
to
eid
to
this
xtr,
they
keep
sending
to
the
rtrs
so
that
level
of
indirection
helps
for
square
scale.
H
Quite
a
bit
and
the
protocol
procedures
in
this
document
could
be
used
when
the
list
site
has
multiple
xtr's
each
connected
via
separate
net
devices
to
the
public
internet,
the
xtr
registers
their
global
rloks
and
can
do
merge
semantics.
What
the
original
draft
had
was.
Each
xdr
behind
separate
gnats
could
register
their
net
information
unilaterally
and
with
merge
semantics
that
we
added
to
the
mapping
system
at
that
time.
Because
of
that
draft,
the
mapping
system
could
get
multiple
translated.
Our
looks
at
the
same
time
so
that
works
quite
next
nicely
next
slide.
A
D
Okay,
much
better
yeah.
They
know
two
two
quick
questions.
One
is
so
when
the
xtr,
so
an
exterior,
is
behind
that
has
a
default
mask
entry
towards
the
rts
right.
So
when
it
is
going
to
decide
to
cinema
request,
because
all
the
traffic
is
going
to
hit
that
default
map
cache
entry.
H
You
can
install
more
specific
routes
in
the
map
cache.
My
implementation,
you
can
install
static
map,
cache
entries
and
the
our
loads
that
are
configured
for
that
is.
Some
is
an
action
that
says
send
map
request,
so
a
forwarder
would
would
match
on
the
more
specific
entry
which
instructs
it
to
send
a
map
request,
rather
than
using
the
more
coarser
entry.
That
has
our
looks.
D
H
Yeah
you
do,
you
can
figure,
you
can
figure
a
set
of
prefixes,
that
you
know
that
are
not
behind
nas
and
that
and
that's
easy
to
do
mostly
because
when
you
have
when
you
want
to
talk
to
server
systems
that
are
out
in
the
public,
you
you
can
configure
those
prefixes
and
those
are
prefixes
of
eid.
So
they're
the
service
addresses
not
in
our
local
directory.
D
H
Yes,
as
long
as
it
as
long
as
it
registers
to
the
same
map
servers,
which
is
what
the
the
general
list
architecture
wants
to
do,
the
answer
is
yes
right
now
what
what
the
original
nat
traversal
said
for
future
reference
is.
Do
you
want
the
map
server
to
give
you
a
different
set
of
rtrs,
depending
where
you're
moving?
If
you're
moving
from
say
you
know
one
service
provider
or
to
another
or
a
long
geographic
area?
H
You
may
want
the
rtr
to
be
close
to
the
xtr,
but
you
know,
arguably
you
might
want
the
remote
etrs
to
be
close
to
the
rtrs,
but
what's
most
important,
is
you
want
your
set
of
encapsulators
and
decapsulators
to
have
the
rtrs
relatively
in
the
center
of
gravity,
so
there's
no
hair
pinning
that
they're
somewhat
on
route
and
usually
that's
in
where
the
usually
those
rtr's
are
deployed
in
an
access
provider
for
one
or
four
either
the
itr
etr
and
each
and
the
packets
are
flowing
in
those
directions.
C
Sorry
to
interrupt
you
guys,
but
we
have
to
move
forward.
Otherwise
we
will
need
too
much
time
to
to
victor
is
an
interesting
discussion.
We
should
anyway
take
him
to
the
list,
because
the
working
group
has
to
discuss
a
little
bit
on
this
approach
for
not
reversal
the
other
approaches
for
not
versa,
lens,
especially
look
at
the
security
stuff.
Okay,.
H
H
Unless
the
working
group
wants
to
do
something
different
with
it,
but
what
the
last
slide
said
was
I
wanted
to
get
an
opinion
from
the
working
group
if
it
should
be
published,
if
I
can
publish
it
as
an
informational
rfc
now
I
know
I
don't
need
the
working
group
approval
for
that,
but
I'm
still
asking.
A
Discuss
this
question,
but
let
me
just
say:
if
you
take
it
to
the
ise
and
ask
to
do
it
published
as
an
individual
informational,
it
will
be
punted
back
to
us
to
ask
if
this
is
an
end
run
around
the
working
group,
and
we
would
probably
say
yes,
this
is
an
end
run.
Please
hold
this
off
until
after
we
have
published
the
working
group
not
reversal.
H
F
Thanks
so
good
morning
or
good
evening,
wherever
you
may
be,
so
this
is
a
follow-on
on
the
discussion
we
had
on
the
at
the
interim
meeting.
We
we
discussed
a
little
bit
of
the
federation
requirements
and
they
weren't
quite
clear.
So
hopefully
I
got
a
little
more
context
on
what
the
requirements
are
for
federating
mapping
systems
in
in
the
civil
aviation
organization
network.
If
we
can
go
to
the
next
slide,
please
so
I'm
going
to
do
a
very
quick
refresher
and
focus
mainly
on
the
requirements.
F
If
time
allows-
and
we
may
not
get
there
I'll
discuss
a
potential
mechanism
that
could
be
used,
but
it's
it's
not
complete
by
any
stretch.
So,
let's
focus
on
the
requirements.
If
we
go
to
the
next
slide.
The
context
of
this
is
that
we
have
basically
a
worldwide
network
for
aviation.
A
F
And
we'll
see
that
that
poses
different
requirements.
In
a
nutshell,
we
have
a
series
of
radio
networks,
whether
that's
radio
or
satellite,
and
the
aircraft
connect
to
different
networks
either
simultaneously.
F
So
you
can
see
the
bottom
aircraft
is
simultaneously
connected
to
two
radio
services
or
it
roams
between
them
and
there's
a
combination
of
the
of
those
those
two
cases,
in
any
case,
the
ip
network
that
these
radio
regions
feed
into
is
an
ip
network
where
we're
proposing
the
use
of
lisp.
F
F
F
And
it's
it's
done
on
a
per
application
basis,
but
we'll
get
into
that
in
a
second.
In
any
case,
the
the
metric
propagates
from
the
aircraft
through
the
radio
regions,
all
the
way
to
what
we're
calling
the
airground
routers.
Those
airground
routers,
are
our
xtrs.
F
Those
xtrs
will
actually
and
I'm
going
from
left
to
right
by
the
way
those
xcrs
which
are
in
in
dark
blue.
Those
pucks
in
dark
blue
will
actually
register
with
the
mapping
system
and
they
would
register
with
a
set
priority
and
weights
that
are
reflective
of
the
metrics
that
we're
receiving
from
the
aircraft,
and
that
gives
us
the
registration
picture
that
you
see
on
the
far
right.
F
Then
the
process
is
as
usual,
I
do
a
map
request,
get
them
up
reply,
cache
it
and
we
see
how
the
ground
on
the
right-hand
side,
the
ground
facilities
that
maybe
the
airline,
for
example,
can
actually
either
spread
the
traffic
across
the
different
radio
regions
by
reaching
different
xtrs,
which
are
airground,
router,
1
and
airground
router
2,
or
understand
that
there's
been
a
move.
So
if
we
go
to
the
next
slide,
you'll
see
that
now
the
the
aircraft
kind
of
disconnects
from
radio
region
2
and
connects
to
radio
region
3.
F
and
what
how
that
is
expressed
is
by
sending
lesser
metrics
on
radio
region
2
and
better
metrics
on
radio
region
3,
so
that
the
priorities
on
radio
region,
2
and
agr
2
are
now
set
to
2,
and
the
priority
on
on
agr3
is
set
to
1.,
so
that
basically
overrides
the
use
of
a
air
ground.
Router
2..
So
that's
that's,
basically
how
we
they're
tackling
mobility
in
in
this
particular
case.
F
So
and-
and
this
is
important
because
the
those
registrations
will
be
funneled
through
different
service
providers
in
that
network.
And
that's
where
the
impact
on
the
federation
comes
into
play,
so
so
just
remember
that
we're
going
to
be
getting
the
information
on
an
eid
from
different
angles,
from
different
service
providers
with
different
priorities
and
weights,
and
we
need
to
make
a
decision
on
what
the
consolidated
mapping
looks
like
when
that
happens.
F
The
other
aspect
of
this
is
that
the
registrations
are
they
can
be
per
prefix
and
that's
what
we're
recommending
to
the
to
the
civil
aviation
mobility
work
group
that
each
application
has
its
own
prefix.
What
they've
done
is
they've
assigned
a
subnet,
an
ipv6
submit
to
each
aircraft
and
therefore
it's
conceivable
that
each
application
could
have
its
own
ip
address
within
that
subnet,
but
there
there
are
many
proponents
of
simply
tagging
the
applications
with
dhcp
values.
F
Sorry,
with
a
green
dhcp
value
will
have
a
preference
for
going
on
the
south
side
of
the
slide.
So
so
there
may
be
extended.
The
ids
that
need
to
be
propagated
into
the
overlay
and
the
federation
is
basically
what
the
implication
of
this
is.
If
we
go
to
the
next
slide,
okay,
so
they
have
basically
a
consortium
of
different
providers
right
now
the
number
is
relatively
small.
There
are
about
three
or
four,
but
that
is
growing
and
we
have
proposed
the
overlay
model
as
a
way
to
architect
the
mixed
environment.
F
There
is
a
hierarchy
of
regions,
but
there's
also
a
set
of
peerings
between
the
csps,
so
those
peerings
are
subject
to
all
sorts
of
regulation
and
policies
and
rules,
and-
and
we
need
to
make
sure
that
we
are
meeting
those
those
rules
and
that
we
are
able
to
enforce
the
policies.
So
if
you
go
to
the
next
slide,
I'll
show
you
in
a
diagram
what
I
mean
by
this.
F
So
we
have
here
three
global
networks.
Some
examples
of
those
are
sita
and
aaron.
Those
are
two
of
their
global
networks
and
those
have
presence
in
in
different
regions
so
on.
F
If,
if
you
look
at
this
geographically
on
the
left
side
and
the
right
side,
we
can
just
say
we
have
an
a
west
operation
of
each
csp
and
an
east
operation
of
each
csp.
That's
an
oversimplification,
of
course,
but
but
the
csps
will
also
connect
to
each
other
on
on
a
global
basis.
F
They
may
have
more
than
one
peering
point,
I'm
showing
one
a
single
peering
point
for
simplicity-
and
this
is
all
based-
they're
base
ip
network
and
we
would
have
the
ability
to
move
from
the
west
side
of
the
csp
to
the
east
side
of
the
csp.
F
We
can
move
our
association
between
csp,
b
and
cs
pc,
for
example.
So
all
all
possible
combinations
are
are,
are
in
flight
now,
the
way
the
way
we've
suggested
we
structure
this.
If
we
go
to
the
next
slide,
we
please
the
way
we
suggested
we
structure.
This
is
if
we
over
put
on
top
of
this
list
network
on
the
west
regions.
We
are
suggesting
we
use
site
overlay,
so
those
would
have
their
own
xtrs,
which
are
the
airground
routers
and
the
ground
ground
routers.
F
It
would
have
its
own
mapping
system,
which
is
that
little
green
puck
that
you
see
and
focus
on
the
west
side
right
now,
so
on
each
dotted
blue
dotted
line.
You
have
a
map
server
assigned
to
this,
so
this
is
the
site
overlay
map
server
per
the
overlay
draft,
and
then
you
have
a
re-encapsulating
tunnel
router
that
connects
this
to
the
overlay
right.
F
So
in
the
overlay,
each
each
of
these
regions
has
a
a
map,
server
presence
and
we
could
have
had
one
map
server
system
per
per
csp
and
then
worry
about
how
we
federate
the
map
servers
amongst
the
csps.
F
But
there
is
an
interesting
set
of
requirements
that
that
became
clear
in
talking
to
the
civil
aviation
or
personnel
further,
which
was
that
there
may
be
constraints
or
policy
in
which
you
may
opt
to
not
have
the
east
regions
have
knowledge
of
everything
on
the
west
region,
even
within
a
csp.
F
F
So
so
what
you
see
there
in
the
middle
is
is
basically
a
set
of
map
servers
that
are
reflective
of
the
site,
overlays
that
that
are
present
in
in
the
different
networks,
and
the
task
at
hand
is
to
design
a
model
in
which
they
confederate
in
such
a
way
that
we
can
enforce
the
policies
that
that
are
required.
If
we
go
to
the
next
slide,
we.
F
So
this
is
a
potential
view
of
what
the
federation
relationships
could
look
like.
So,
as
you
see
there
within
the
csps,
which
are
the
horizontal
lines
we
have,
we
have
a
a
relationship
and
then
across
across
csps,
we
have
relationships
and
if
you
see
the
way
I've
drawn
this,
the
the
relationships
between
csps
are
are
drawn
as
local
meaning.
F
I
have
relationships
on
the
east
side
between
a
and
b,
b
and
c
and
a
and
c
so
I
have
a
full
mesh
on
the
east
side,
but
I
don't
necessarily
have
to
establish
a
full
measure
across
across
regions.
This
is
just
hypothetical
and
and
an
initial
reaction
to
to
the
information
gathered
so
far.
This
is
some
of
the.
F
These
are
some
of
the
things
that
the
work
group
could
actually
explore.
Now
I
think,
as
as
a
as
a
provider
of
technology,
for
this,
what
we
would
want
to
do
is
have
a
model
where
those
constraints
can
be
implemented.
I
could
I
should
be
able
to
have
a
system
where
I
can
implement
a
full
mesh
of
federation
or
or
constrain
it
in
in
ways
like
what
we,
what
we're
showing
here
right
and
the
constraint,
would
be
in
the
form
of
what
is
registered
as
well
as
what
is
what
is
shared
and
coordinated.
F
So
if
we
go
to
the
next
slide,
please
I
I'm
going
to
go
to
the
next
slide.
This
is
just
a
generalization.
We've
talked
about
this
about
three
or
four
times
so,
if
we
just
skip
this
slide,
okay,
so
so
they
have
mainly
three
three
types
of
traffic:
they
have
air
traffic
control,
which
is
basically
the
communication
with
the
towers
and
the
air
traffic
controllers.
F
This
is,
and
they
have
what
they
do.
F
Oh
okay,
let
me
let
me
say
it
so
so:
three
types
of
traffic,
air,
air
traffic
control,
airline
operations
and
community
communications
and
and
drones
right
so
for
air
traffic
control.
What
happens?
Is
the
the
csps
on
the
on
the
regions
need
to
be
informed
of
everything
that
is
happening
with
with
the
aircraft?
F
So,
even
though
you
register
with
one
of
the
one
of
the
csps
and
you
get
registered
to
the
csp
uber
lake
mapping
system,
they
need
to
peer
with
and
and
communicate
that
information
to
the
other
csps
in
the
region.
So
for
air
traffic
control,
it's
critical
that
all
csps
are
informed,
but
it's
not
critical
that
the
east
side
of
the
csp
or
any
of
these
csvs
have
any
of
the
information
about
that
aircraft.
So
that's
one
of
the
requirements,
so
local
local
peering.
F
If
we
go
to
the
next
slide
for
the
aoc
traffic,
which
is
the
airline
operations
control,
the
airline
may
partner
with
one
csp
and
and
they
may
as
a
policy
not
want
any
of
their
reachability
information
to
be
on
other
csps
other
than
the
one
chosen
right.
So
a
very
different
policy
for
federation.
Here
across
across
the
different
csps
and
also
across
the
regions,
so
the
next
slide
is
basically
probably
where
we
should
have
started.
It's
like
well,
one
of
the
main
points
of
discussion
was
we
need.
F
The
civil
aviation
organization
is
requesting
that,
as
the
aircraft
moves
between
regions,
the
registration
of
the
aircraft
must
move
with
the
aircraft,
meaning
I
can't
anchor
the
aircraft
in
a
particular
region.
If
I
move
to
a
different
region,
we
want
that
to
move
that
registration
to
move
so
that
there
is
a
a
clear
sense
of
authority
and
accountability
and
auditability
of
where
an
aircraft
is
registered.
F
So
for
many
reasons,
as
the
aircraft
moves
around,
it
will
actually
move
between
different
service
providers.
It
would
move
across
countries
even
within
the
same
service
provider
and
for
auditability
accountability
reasons.
The
registration
of
the
aircraft
is
requested
to
be
kept
within
that
country
within
the
mapping
system
or
the
mapping
servers
that
are
assigned
to
that
country
or
to
that
service
provider,
so
that
an
audit
can
actually
be
completed,
there's
also
limited
trust
across
governments
and
csps,
etc.
F
So
all
of
these
things
that
are
not
technical
items
but
more
administrative
items
and
and
things
that
have
to
do
with
regulation
and
audit
trails
are
the
main
reasons
why
they're
asking
us
to
actually
have
these
eids
re-home
from
one
map
system
to
another,
and
if
I
have
one
more
minute,
the
next
slide
is
important
in
this,
and
I
don't
know
if
I
have
that
many.
So
we.
C
C
The
topic
starts
to
have
a
form.
Certainly
we
need
more
discussion
in
the
working
group
and
to
better
understand
the
problem
but
at
hand,
but
it's
erratic
testing.
F
Yeah,
so
what
I
would
say,
luigi
and
team,
that
is,
that
the
the
requirements
are
becoming
clearer,
so
maybe
it
might
be
an
opportunity
to
to
write
some
text
and
summarize
the
requirements,
and
maybe
that's
one
way
of
actually
moving
this
forward,
or
we
can
have
a
follow-up
on
an
interim.
Whichever
way
you
want
to
do
it,
I
think
the
it
would
be
more
conducive
to
the
mailing
list
to
put
it
in
a
short
filter.
C
F
And
and
and
maybe
the
text
could
be,
could
live
in
the
ground-based
lift
draft
or
or
we
could
make
it-
I
because
it's
specific
to
the
industry.
I
think
the
ground-based
list
draft
might
be
a
place
to
move
that
text
versus
trying
to
put
the
requirements
in
the
overlay
draft
yeah
yeah,
yeah
yeah.
I
would.
F
C
Yeah
yeah
anyway,
I
thank
you
all
for
the
participation
we
are
really
overcoming
any
second
can
the
meeting
can
be
cut
by
by
mitigates,
so
we
will
take
it
to
the
list,
maybe
organize
an
interim
meeting
specifically
on
the
uber.
Okay.
Thank
you
again
victor
and
thank
you
all
for
the
participation
see
you
virtually
in
bangkok.
Maybe
hopefully
thank
you.