►
From YouTube: IETF101-ILA-20180322-1810
Description
ILA meeting session at IETF101
2018/03/22 1810
https://datatracker.ietf.org/meeting/101/proceedings/
A
B
Welcome
everyone
to
the
identifier
locator,
addressing
a
la
boeuf,
I'm
samhita
Chakrabarti
co-chairing
with
Joelle
Halpern
and
responsibilities,
suresh
krisshnan
and
IB
Shepherd,
a
CEREC
node
mark.
We
have
mini
taker,
Thank,
You,
Marcin,
duty
and
jabber.
Scribe
is
evangelist.
Thank
you
and
we
have
the
online
agenda.
Deborah
miracle
I
thought
Pat
on
this
slide
and
next
is
not
well,
so
you
are
probably
familiar
with
all
the
notable
rules
and
notes,
so
identifier
locator,
addressing
aisle
above.
B
Basically,
this
is
a
protocol
to
implement
over
overlay.
You
know
without
an
encapsulation,
so
using
ila
mapping
in
the
ipv6
address.
You
can
use
the
similar
whatever
you
can
achieve
the
instant
capsulation
when
transporting
the
packets
between
the
nodes.
It
has
some
additional
benefits,
control,
plane
and
data
plane
separation,
as
well
as
anchor
free
routing
in
many
use
cases.
B
B
Lots
of
work
has
been
done
in
this
space
in
IETF
I,
don't
want
to
name
them
separately
and
because
I
might
miss
someone
some
some
protocols,
but
basically
separation
of
control
and
data
planes,
ID
and
locator
separation
and
address
mapping
has
been
also
worked
out
here
so
today
our
purpose
is
not
going
to
compare.
Those
solutions
are
not
going
to
go
into
solutions
in
any
way.
B
A
B
The
agenda
is
simple:
we
will
have
Tom
presenting
Tom
Harbert,
presenting
a
problem
statement,
scope
and
the
issues
I
believe
he
is
also
dis
going
to
discuss
the
data
center
network
use
case
at
during
the
same
presentation
and
then
Kalani
buggy
Nene
will
be
presenting
on
the
5g
user
mobility
use
case,
and
then
we
will
do
that
Q&A.
We
request
that
during
the
presentations
due
to
the
short
the
shortage
of
time,
we
would
only
accept
the
clarification
questions
and
then,
at
the
end
of
the
presentation,
we
will
have
enough
time
for
Q&A.
B
C
C
I'll
start
with
a
goal,
so
the
goal
is
to
provide
seamless
mobility
for
multiple
use
cases
using
highly
efficient
identifier,
locator
techniques,
that's
a
pretty
short
statement:
that's
actually
packed
with
four
different
components:
seamless
mobility,
multiple
use
cases
highly
efficient
and
identifier
locator.
So
we'll
look
a
little
bit
at
those
the
use
cases.
So
we
have
multiple
use
cases.
It's
inherently
mobile
protocol,
so
anything
to
do
with
mobility,
actual
mobile
networks,
which
is
first
use
case,
and
we
also
have
use
cases
in
data
center.
C
Virtualization
network
virtualization
I
only
was
actually
born
from
the
point
of
view
of
network
virtualization
and
in
particular,
container
virtualization
as
a
more
efficient
means
of
doing
encapsulation.
So
you
can
also
consider
that,
as
we
move,
there
may
be
converge
networks
that
have
one
more
than
one
of
these
kind
of
use
cases
inside
the
network.
Hence
we
have
the
possibility
of
converged
use
cases
so
the
problem
statement.
So
we
what
we
did
here,
whereas
we
listed
the
problems
and
the
applicable
use
cases.
C
So
this
goes
kind
of
from
the
general
problems
to
more
specific
use
case
problems.
So,
as
I
mentioned,
encapsulation
is
expensive.
As
a
data
plane
protocol
and
the
way
to
think
about
it
is
when
you're
encapsulating
a
an
application
that
requires
high-performance
encapsulation,
basically
becomes
a
tax
on
every
packet,
so
there
are
certain
circumstances.
Low,
latency,
high
performance
use
cases
where
even
that
encapsulation
becomes
problematic,
and
it
also
contributes
to
bandwidth
on
the
wire.
C
So
every
byte
that
I'm
putting
into
encapsulation
is
about
taking
away
from
MTU,
for
instance,
there's
a
related
issue
which
we
see
a
lot
in
IETF,
which
are
tunneling
considerations.
So
in
the
network
when
encapsulation
occurs,
we
consider
that
tunneling
and
then
several
considerations
kick
in.
For
instance,
what
happens
if
your
encapsulation
exceeds
the
MTU?
At
that
point?
Do
you
fragment?
Do
you
not
fragment?
So
there
is
an
RFC
on
that
just
previously
in
PSV
WG
they
were
talking
about
ecn
and
tunneling.
So
how
do
you
deal
with
ecn
and
tunneling?
C
Disserve
has
an
equivalent
consideration
if
you're
doing
UDP
encapsulation,
then
you
need
to
worry
about
UDP
checksum.
So
the
short
story
here
is
whenever
encapsulation
or
tunneling
occurs
in
the
network.
There
are
more
considerations
than
just
creating
a
new
packet,
another
one,
that's
sort
of
general,
and
this
is
kind
of
well-known
in
IETF.
Also
identity
is
tied
to
location.
So
this
goes
back
to
the
original
definition
of
ipv4.
When
you
have
an
ipv4
address,
it
exposes
both
identity
of
who
you're
talking
with
and
also
location
where
they
are
so.
C
This
coupling
makes
it
difficult,
especially
in
mobility,
to
separate
out
those
notions.
So
that's
one
of
the
one
of
the
things
we
are
intending
the
the
next
one
support
for
alternate
protocols.
This
actually
has
to
do
with
encapsulation.
What
we
found
is
whenever
we
diverge,
especially
in
the
data
center
from
using
plain
UDP
plain
TCP
over
the
network
and
start
using
capsulation
or
extension
headers.
C
Inevitably,
some
network
device
will
not
like
that,
and
usually
this
is
not
breaking
connectivity,
but
what
it
does
is
it
reduces
a
number
of
optimizations
and
that
obviously
gets
us
into
the
whole
arena
of
vendors
trying
to
support
various
encapsulations
and
an
endless
endless
stream
of
that.
So
anytime.
We
we
try
to
come
up
with
a
new
encapsulation
or
new
scheme.
We
do
consider
the
effects
of
existing
network
devices
in
the
middle
of
network
privacy
in
addressing
so
this
I
touched
a
little
bit
on
in
in
area
discussion.
C
So
this
goes
more
into
what
kind
of
addresses
are
we
exposing
to
the
Internet?
And
it's
not
so
much
that
this
is
a
problem
to
be
solved
in
identifier,
locator,
addressing
it's
more
can
identify
our
look
at
our
addressing
kind
of
solve
this
or
contribute
to
the
solution.
If
we
can
split
location
from
identity
that
in
itself
already
gets
us
some
distance
to
this
mobile
anchor
points.
This
is
an
issue
and
mobility.
C
There's
a
lot
of
design
in
3gpp,
for
instance,
Franco
Mobility
Kayani
will
go
into
a
lot
of
the
more
rational
how
to
get
to
anchor
lists
and
the
benefits
of
that
and
the
last
one
low
latency
applications.
So
this
is
a
kind
of
under
the
assumption
that,
as
we
go
forward,
a
RvR
new
applications
will
come
in
low
latency
will
become
more
and
more
of
an
issue
in
real
networks.
So
we
classify
that
as
mobile.
It's
it's
already
kind
of
an
assumption
in
data.
E
E
C
C
So
this
is
one
slide
that
just
basically
shows
the
process.
If,
if
you're
not
familiar
with
ila,
it
is
what
we're
calling
address
transformation
as
opposed
to
nate'll.
Explain
the
difference
there.
But
the
idea
is
part
of
the
ipv6
address
is
an
externally
visible
prefix
and
when
we
go
to
send
that
to
a
specific
location,
we
do
transformation
of
the
upper
bits
in
the
address
to
what's
called
a
locator.
C
Locator
is
something
that's
routable
in
the
network
to
the
actual
location
of
the
node
we're
talking
to
so
this,
for
instance,
could
be
a
host
that
has
a
VM,
that's
running,
which
is
our
location
or
the
know.
We're
talking
to
could
be
a
device
in
the
network
where
we
need
to
route
to
an
e,
node
B.
So
there's
some
concept
here
that
the
node
has
a
persistent
identity
and
a
location
and
the
the
upper
bits
in
the
address
are
used
to
express
the
location
so
to
transmit.
C
We
transform
those
upper
bits
to
locator
packets
sent
through
the
network
at
a
peer
point.
The
reverse
transformation
is
done.
So
the
important
thing
here
is
that
to
the
sender
and
the
receiver
of
the
packet
they
do
not
know.
This
is
happening,
it's
transparent
to
them.
So,
in
that
regard
it's
kind
of
has
the
place
of
encapsulation.
It
has
the
same
function
out
or
at
least
a
similar
functionality,
so
some
of
the
properties
of
ila.
C
So,
as
I
mentioned,
it
is
an
identifier,
locator
split
protocol,
so
location
and
identity
are
kind
of
separate
concepts
in
the
addressing
it
performs
network
transformation.
It's
not
NAT
on
the
basis
that
transformations
are
always
paired,
so,
unlike
NAT,
whatever
you
transform
into
a
locator
address
will
be
reversed,
transformed
to
the
original
identifier
address
at
some
peer
before
you
its
receive
the
packet.
It
is
completely
contained
within
the
network
layer.
There
are
there's
no
parts
of
this
that
affect
the
transport
layer.
C
It
just
happens
to
have
a
different
address,
any
stateless
mechanism,
the
network
ecmp
segment-
all
floats
things
like
that
will
not
care
that
it's
not
actually
a
the
endpoints
address,
so
the
scope
of
ila
there's,
basically
two
main
parts
before
we
get
into
the
use
cases,
so
the
data
plane.
This
describes
all
of
the
protocol
processing.
It
does
not
change
the
on
the
wire
protocol.
It
is
only
changing
or
rewriting
addresses.
We
do
consider
transport
layer
checksums.
C
So
when
we
modify
the
destination
address,
for
instance,
in
a
packet
that
in
theory
chain
or
invalidates
a
transport
layer,
checksum
that's
doing
a
suitor
pseudo
header
checksum.
We
do
want
to
keep
the
checksum
correct
at
all
times
in
order
in
order
to
satisfy
say
some
intermediate
device
is
actually
checking
the
checksum.
So
there's
relatively
easy
mechanism.
I
think
it
was
invented
in
routing
group
was
called
checksum
neutral,
simple
idea,
look
it
up,
but
it
allows
us
to
keep
the
checksum
valid
even
after
address
transformation.
C
Also,
data
plane
has
a
different
number
of
address
encodings
when
we
started
we
kind
of
assumed
class
64,
64
split,
so
64-bit
locator
64
bit
identifier,
much
like
I
LMP
over
time,
we've
kind
of
relaxed
that
to
allow
different,
encodings
the
control
plane.
This
has
a
lot
to
do
with
the
mapping
system.
There's
been
discussion
on
mapping
systems
in
various
groups.
The
idea
of
the
mapping
system
is
basically
it's
a
distributed
database
of
identifiers
to
locator
mapping.
So
this
is
the
thing
that
kind
of
the
equivalent
of
virtual
to
physical
address
mapping
in
NV
o3.
C
How
do
you
find
the
location
of
the
node
that
you're
looking
for
so
the
control
plane
that
can
be
managed
by
standalone
protocols?
For
instance,
there
is
a
list
control
plane
that
potentially
could
be
used
while
with
ila.
Also
we
want
to
leverage
existing
control
planes.
For
instance,
3gpp
has
a
lot
of
control
plane
that
we
would
also
like
to
use.
So
we
want
to
be
a
little
flexible,
a
little
bit
flexible
on
the
control
plane,
so
ila
does
have
some
interesting
limitations.
C
It
is
important
to
realize
it's
important
to
realize
that
I
la
is
not
extensible
in
that
and
from
that
point
of
view,
it's
in
a
sense
it's
anti
encapsulation,
so
whatever
we
can
fit
into
the
bits
of
the
address
in
the
transformation,
that's
as
much
information
as
we
can
put
into
ila.
So
if
you
really
need
encryption
or
fancy
authentication
a
whole
bunch
of
things,
Iowa
may
not
be
for
those
use
cases.
It
is
designed
to
be
fast,
efficient
and
have
minimal
minimal
impact
on
the
network
and
the
host
complexity
of
the
data
plane.
C
So
one
of
the
side
effects
of
it
not
being
extensible.
This
may
push
backs
some
more
complexity
in
the
control
plane.
In
order
to
keep
the
data
plane
kind
of
very
simple,
it
does
not,
naturally
support
multicast.
This
is
something
we
could
talk
about
as
we
go
forward
how
to
integrate.
Multicast,
but
most
of
the
use
cases
initially
really
unicast
is,
is
the
more
compelling
thing
to
look
at
right
now.
Icmp
does
need
consideration.
The
problem
here
is,
if
there's
an
ICMP
error
in
the
network,
that's
generated
after
a
transformation.
C
So
there
are
a
number
of
considerations
that
have
to
be
considered
a
lot
of
these
have
to
do
more
with
any
sort
of
technique
or
scheme
to
build
a
large
scalable
mo
mobile
network.
It's
a
scalability
security
privacy
possibility
essentially
the
four
pillars
of
a
mapping
system,
so
in
terms
of
scalability
some
things
to
consider
the
number
of
mappings
in
the
system.
Right
now
we
have
maybe
a
hundred
million
nodes
in
some
network
that
could
be
100
million.
Obviously
we
want
this
to
scale
with
IOT
coming
onboard
in
the
data
center.
C
We're
going
to
be
talking
about
giving
more
and
more
things,
not
just
task,
but
objects
addresses,
so
the
number
of
mappings
will
need
to
scale.
In
addition
to
the
number
of
mappings,
we
have
to
consider
the
rate
of
mapping.
So
everything
if
we
assume
everything
is
mobile.
A
lot
of
these
things
are
gonna,
be
moving
around.
That's
gonna
require
changes
to
the
mapping
system
database.
What
is
that
rate?
And
how
do
we
absorb
that
right?
C
Kind
of
related
to
both
of
those
a
throughput
of
the
data
plane?
Obviously,
we
expect
throughputs
to
go
up
packets
per
second,
so
that
we
have
kind
of
feedback
into
how
we
extraor
at
least
the
mapping
system
and
the
data
plane.
We
consider
the
the
total
state
in
the
mapping
system
how
that's
managed
so
the
protocols
that
you
use
to
manage
the
state
those
have
to
be
scale
of
one
themselves
and
then
one
of
the
trickier
things
actually
will
be
caches,
and
this
is
a
little
controversial
because
we
know
caches
are
inherently
in
some
sense.
C
They
can
be
dust,
and
things
like
that.
So
there's
obviously
a
lot
of
history
with
caches.
So
we
need.
We
do
need
special
consideration
if
we
need
a
cache
in
order
to
scale
say
the
number
of
mappings
or
to
get
the
latency
down.
We
won't
need
considerations
for
that.
I'm
particularly
concerned,
for
instance,
in
a
public
network.
What
are
the
dosing
thoughts
mitigations
on
a
cache
system,
so
security
spec's
mapping
system
contains
personally
identify
identifiable
information.
Locators
may
contain
geophysical
location,
so
they
need
to
be
hidden.
C
Identity,
IP
addresses
could
be
mapped
to
devices
and
devices
in
the
case
of
personal
devices
mapped
to
user.
So
this
becomes
personally
identifiable
information.
So
the
mapping
system
needs
to
be
secure,
secure
protocols.
We
need
to
limit
the
visibility.
The
data
I
tend
to
think
this
kind
of
precludes
having
one
gigantic
global
mapping
database
for
the
whole
world
and,
of
course
we
need
to
consider
law
enforcement
considerations.
What
are
their
requirements
that
has
to
be
part
of
the
mapping
system,
security
considerations,
inter-domain
solutions?
This
is
obviously
a
whole
nother
ball
of
wax.
C
When
you
consider
what
happens
within
domain,
we
can
fairly
control
that,
but
if
you
want
to
have
two
domains
speaking
a
protocol
like
this,
the
requirements
is
a
security
between
them
become
very
interesting.
So
those
are
considerations
I'm,
not
saying
that
we
necessarily
have
solutions
or
have
to
have
all
these
solutions,
but
in
the
mapping
system
these
will
come
up
in
discussion
privacy,
as
I
mentioned.
This
can
be
viewed,
as
can
we
help
privacy
like
with
identifier,
locator,
ila
and
I,
mentioned
that
a
to
talk
about
privacy
and
addressing
on
in
an
Ariane
on
Tuesday.
C
So
you
may
want
to
look
at
that
draft
fundamentally
at
giving
us
last
64
to
a
device
that
prefix
that
you
give
that
device
becomes
an
identifier
for
that
device.
So
there
are
security
potential
privacy
issues
with
that
privacy
quickly
becomes
a
balance
between
scalability.
So
in
a
perfect
world
world,
if
you
want
a
perfect
privacy,
everybody
would
always
use
a
different
address
for
every
flow.
That's
obviously
a
scaling
issue,
so
there's
gonna
be
some
interesting
discussion
and
trade-offs.
C
Potentially
their
locator
privacy,
as
I
mentioned
locator,
say
in
a
mobile
network,
may
actually
indicate
physical
location.
If
that's
like
the
locator
refers
to,
and
then
you
know
B
or
something
to
that.
So
this
is
another
tricky
thing:
how
do
we
prevent
locators
from
revealing
identity
to
third
parties?
C
Doubts
ability,
I
mentioned,
and
so
I
think
this
is
going
to
have
a
lot
to
do
with
the
mapping
cache.
If
we
have
a
cache
in
a
public
network,
it
will
be
target
of
attack,
especially
if
it's
being
driven
by
third
party
activities.
So
this
is
one
thing
we
need
to
do.
My
recommendation
is
to
have
qualitative
quantitative
explanations
of
why
a
dust
mitigation
works
and
hopefully
that
that
kind
of
narrows
down
some
of
the
issues
so
I
will
cover
the
virtualization
in
data
center
use
case.
C
Kalyana
will
go
a
lot
more
into
the
mobile
use
case,
which
is
kind
of
primary
focus
for
this
exercise,
but,
as
I
mentioned
for
data
center
virtualization,
the
concept
here
is
initially.
We
wanted
to
have
every
task
in
the
data
center,
every
unit
of
execution
have
its
own
IP
address.
There
were
several
reasons
for
that.
One
of
those
was
we
want
a
seamless
container
migrate
migration
and
that
would
allow
it,
but
eventually
everything
gets
its
own
IP
address.
C
One
of
the
critical
things
in
that
environment
is,
if
we
introduce
this
concept,
everything
having
its
own
address.
That
mechanism
to
do
that
has
to
really
be
performant.
Applications
really
don't
care
if
infrastructure
is
changing,
for
instance,
infrastructures
benefit.
So
this
is
the
give
the
network
more
malleability,
but
applications
already
running
with
a
certain
performance.
They
don't
want
to
see
a
degradation,
so
ila
had
that
aspect
from
the
beginning
that,
in
that
model,
performance
has
to
be
really
tight.
So
we
have
tight
bound
on
performance
expectations.
Network
virtualization
is
kind
of
similar.
C
I
did
present
ila
in
nvo
3
a
couple
of
times.
It
does
have
some
different
aspects
because
of
the
performance
may
not
be
balanced,
may
not
be
so
tight,
but
there
is
aspects
of
tenant
isolation,
so
we
need
ila
to
make
sure
that
it
can
convey
tenant
IDs
within
the
addresses.
There's
also
an
interesting
application
in
ila,
using
ipv4
to
ipv6,
address
translation
where
we
can
allow
say,
VMs
or
tenants
to
contact
common
data
center
tasks
without
using
that,
what's
kind
of
a
benefit.
F
F
C
Yes,
it
is,
if
you
look
at
the
ILA
protocol
graphing
the
appendix
we
gave
some
mechanisms
to
do
that.
We
actually
implemented
something
clever
in
the
data
center.
We
actually
use
a
combination
of
a
timestamp
and
a
registry
number.
The
nice
thing
about
ipv6
address
is
even
if
you
split
them
into
64
bits,
you
still
get
a
big
chunk
to
work
with,
so
the
identifier
fits
into
64
bits,
there's
quite
a
bit
of
flexibility
to
do
there,
I'm
hoping
we
don't
have
to
do
anything
like
duplicate
address
detection.
G
C
C
D
B
Okay
by
samhita
is
trying
to
PDF
version.
The
mobility
use
case
is
the
one
that
I
will
be
describing.
We
have
had
a
lot
of
conversations
with
several
other
operators
as
well,
and
I
would
like
to
thank
my
colleagues
within
Verizon
who
participate
actively
in
3gpp
for
explaining
the
5
g
5g
system,
architecture
on
the
ranch
side
on
the
services
side,
on
the
services
based
architecture,
side
and
the
variants
over
there
and
I.
Also
thank
my
transport
side,
because
this
use
of
ila
for
mobility
management,
which
has
two
kinds
of
architectures
here.
B
B
What
I
will
cover
is
a
use
case
and
why
ila
and
how
does
the
I
live
fit
into
the
5g
architecture?
Anchor
less
mobility
is
a
topic
that
constantly
comes
up,
so
I'll
try
and
explain
something,
and
then
maybe
there
is
a
recommendation
for
the
way
forward.
The
use
case
is
really
looking
at
the
release:
15
core
architecture
that
3gpp
has
specified,
and
this
is
using
the
services
based
architecture.
As
you
can
see,
the
top
part
of
the
diagram
shows
the
control
plane
functions
and
the
lower
part
of
it
shows
the
user
plane
functions.
B
Mobility
management
is
there
on
the
radio
side,
the
left
side,
you
can
see
the
radio
access
network
in
AMF
those
remain
the
same.
The
focus
of
where
ila
would
fit
in
is
on
the
core
network
side.
The
mobility
management
in
the
core
network
that
is
depicted
by
the
session
management
action
and
they
use
a
brain
function
in
the
middle
that
is
blocked
over
there.
B
It
means
that
there
will
be
requirement
of
radius
backhaul
capacity
and,
as
we
go
into
the
5g
networks,
the
network
densification
is
happening,
and
this
means
that
we
will
have
antennas
covering
smaller
and
smaller
areas
very
distributed
into
the
areas,
and
we
need
to
have
backhaul
capacity
that
gets
us
to
the
services
and
the
control
plane
functions
as
well
as
getting
to
the
internet
and
other
applications,
so
reduce
backhaul
capacity
helps
us
in
the
5g
network
in
operations
as
well.
The
second
reason
for
ila
is
it
promises.
I
anchor
less
mobility.
B
The
current
file,
g3
architecture,
uses
the
anchor
point
in
a
way
that
makes
it
difficult
for
us
to
offload
traffic
locally
to
support
education.
Where
we
are
trying
to
get
to
the
low
latency
applications,
we
will
need
to
have
a
separate
anchor
point
closer
to
the
radio
access
network
or
some
time
since
in
the
cell
site.
In
order
to
make
something
like
the
1,
millisecond
latency,
so
having
anchor
less
mobility
helps
in
simplifying
the
network,
and
it
also
reduces
the
state
information,
and
this
goes
to
the
Third
Point.
When
we
have
no
encapsulation.
B
If
1
millisecond
is
a
requirement
on
the
radio
exercise,
they
are
trying
to
get
rid
of
many
say,
microseconds
and
so
on
and
so
forth.
But
once
we
hit
the
packet
side,
we
are
having
so
many
other
network
functions
and
conversions
and
encapsulations,
which
does
not
help
in
the
low
latency
application.
B
So
there's
reduced
packet
processing
and
no
additional
network
functions
comes
by
the
fact
that
ila
can
be
provided
in
the
Linux
kernel,
and
if
we
do
it
right,
the
you
know:
DRG
node
B
can
be
implemented
on
that
and
that
would
help
us
get
rid
of
some
network
functions
at
the
edge.
This
is
the
protocol
stack
diagram
from
3gpp
the
bottom
right.
The
shows
how
the
encapsulation
works
there
is
the
gtp
and
all
that
stuff.
What
ila
promises
is
that
you
can
remove
the
encapsulation.
B
The
backhaul
that
I
mentioned
in
the
previous
slide
is
the
entry
interface
over
there
and
the
anchor
point
part
comes
into
picture.
When
you
see
the
two
ups
in
the
diagram
when
you
have
to
offload
locally.
The
second
UPF
is
placed
alongside
the
access
now
access
to
network,
and
you
will
also
need
to
support
some
anchor
point
over
there
in
order
to
support
mobility.
B
Then
here
is
a
proposal,
architecture
that
we
are
targeting
for
release
16.
We
took
the
3gpp
services
based
architecture.
What
we
show
here
is
the
ILA
mapping
system.
Aisle
in
Odin,
ila
are
are
connected
to
the
services
based
architecture
and
the
rest
of
the
system
remains
the
same,
and
what
the
proposal
here
is
to
have
ila
as
a
network
slice
for
some
of
the
applications
that
do
need
the
reduce
do
need
the
high
performance
benefits
the
ila
can
be
used.
B
If
there
are
things
that
need
to
go
back
to
the
gtp
based
slice,
we
can
do
that,
so
the
premise
is
ila
would
be
used
as
a
slice
in
the
whole
system
and
the
gold-plated
gtp
based
high
reliable
system
can
continue
to
be
used
for
voice
over
I
am
as
for
roaming,
and
things
like
that.
The
proposal
here
is
to
have
the
control
brain
interactions
using
restful.
E
F
B
F
B
B
A
C
C
So
so
this
is
why
I
wanted
to
put
ila
in
parentheses.
Here,
it's
not
actually
a
layer.
It
is
in
this
picture,
I
guess
the
PD.
You
would
actually
be
the
IP
at
IP
header
from
the
user.
That's
what
we're
modifying
so
when
say
the
say,
we're
sending
in
a
packet
to
the
end
and
host
it
comes
into
the
network.
As
an
ipv6
packet,
we
modify
the
destination
address,
traverses
the
network
at
a
point
close
to
the
the
end
host.
It
gets
reversed,
transform
there.
F
H
B
B
H
I
I
I
know
it's
checks
of
neutral
and
that's
great
one
of
the
things
I'm
not
understanding
is
I
know
you
passed
the
eye
lamp
stuff
so
that
the
other
side
knows
how
to
map
it
back
to
the
same
address
what
happens
in
the
case
of
dynamic
routing
or
asynchronous
communication,
and
how
does
it?
How
does
it
handle
using
this?
You
don't
getting
the
same
address.
B
B
3Gpp
has
worked
with
multiple
mobility
management
protocols
in
the
past
we
may
penci,
TP
and
so
on
and
so
forth.
This
is
no
different
if
one
Operator
suppose
one
mobility
protocol
and
the
other
one
supports
anything,
the
common
ones
will
still
be
gtp,
and
so
those
kinds
of
principles
can
be
reused,
security
and
privacy.
Today's
mobile
operator
network,
we
have
the
same
kind
of
issues
that
we
have
to
saw.
We
have
addressed,
and
those
principles
will
be
reused
here
regarding
scalability
mapping
and
control
plane.
B
B
Similarly,
as
you
w2e
not
B,
we
will
try
to
use
the
same
principles
for
the
ILA
nodes
that
will
be
used
to
closer
to
the
radio
access
network,
and
here
is
the
bus
like
that
talks
that
I'm
trying
to
depict
the
anchor
less
mobility.
But
it
also
tells
you
how
the
operator
network
is
designed.
So
on
the
left
side,
you
see
the
radio
access
network
and
that's
where
you
have
all
the
air
interface,
but
then
you
convert
it
into
the
IP
packet
and
then
you
try
to
get
it
to
the
other
side
onto
the
internet.
B
So
this
one
is
a
very
managed
to
domain
on
the
right
side
between
the
internet
and
the
mobile
core.
We
do
have
the
traditional
IP
MPLS
network
in
there,
so
we
have
the
Peter
two-speed
outers
and
the
choke
routers
everything
in
there,
so
the
IAR
will
be
behind
that
one
and
what
we
have
on
the
radio
access
side
in
the
past.
B
We
could
not
see
the
IP
packet
till
we
hit
the
point
where
we
are
connecting
to
the
internet,
so
it
is
a
tunneled
one,
but
in
the
low
latency
cases,
if
you
want
to
break
it
out,
we
had
to
bring
the
the
current
architecture
suggest
that
we
bring
the
Gateway
down
to
the
inaud,
be
a
scaled-down
version.
But
this
one
allows
us
to
see
the
native
IP
packet
as
soon
as
we
get
it
out
of
the
radio
access
network.
B
So
I
try
to
show
one
of
the
flow
of
the
top
flow
is
showing
when
you
go
into
the
internet
or
UE
request
something
from
the
Internet.
When
the
response
comes
back,
the
packet
has
to
go
to
the
place
where
the
UE
is
so
it
looks
up
the
mapping
table
in
the
il
layer
and
then
it
directs
it
to
the
place
where
the
UE
is
located.
The
second
one
is
UA
to
you
via
communication
and
that
one
uses
the
caching
in
the
hi
la
nodes.
B
A
B
J
National
comment-
and
you
proposed
the
solution-
can
tests
of
the
issue
of
the
mobility
issue
in
the
faculty,
but
the
your
part
for
another
issue
is
not
considered
for
the
Q
s
investments
now
in
the
faculty.
We
use
the
cure
for
I
ID
in
each
CPU
header
for
identify
which
case
follow.
This
pathway
belongs
to.
In
such
case,
the
green
cell
and
the
anchor
I
can
decide
how
to
do
the.
J
A
A
A
There,
the
discussion
at
this
point
and
Tom
and
Kalyani
are
staying
available
because
they
really
can
answer
most
of
the
questions
that
are,
if
you
don't
understand
these,
but
the
things
I
will
try
at
the
very
end
to
find
out
from
folks
is:
do
you
understand
the
problem
space
they're
trying
to
address?
If
not
ask
questions
about
that?
Do
you
understand
the
intended
scope?
If
not
ask
questions
about
that?
Are
there
issues
that
you
think
any
further
work
on
this
will
need
to
address
if
so
bring
those
up,
so
we
get
the
minuted.
A
K
C
A
64
allocation,
that's
a
very
good
question.
Let's
remember
the
part
where
I
said
that
we
had
to
relax
on
the
canonical
64
64
split.
The
solution
for
/
64
assignment
is
to
use
an
encoding
in
the
upper
64
bits
that
both
encodes
a
locator
and
identifier.
There
is
a
level
of
indirection
at
the
locator
node
that
we
have,
that
is
described
in
the
ILA
protocol
draft
I
believe.
C
Forget
the
exact
encoding,
but
the
idea
was
the
identifier
is
not
global:
it
really
is
an
index
and
they
locator
specific
table.
So,
depending
on
how
many
users
you
need
say
in
that
particularly
note
that
would
have
to
do
with
the
size
of
that
table.
So
I
think
we
wanted
20
bits
for
that
plus
some
number
of
bits
for
the
network
prefix.
It
seems
to
work
out
so
to
take
a
look
at
the
the
drafter
I.
Don't
remember
the
specifics,
but
there
is
there
is
an
algorithm
described
there.
Okay.
F
Next:
okay,
data
on
Ericsson,
tea,
I
guess
the
Keith's
concern
I-
would
have
is
I
understand
some
of
the
problems
ila
is
designed
to
solve,
but
I
have
not
seen
an
elucidation
of
the
full
set
of
require
for
each
of
the
use
cases
it
is
proposed
to
address
and
until
I
see
that
and
can
understand
that
mapping
then
I'm
not
prepared
to
say
that
I
fully
understand
the
problem.
Space
at
ila
is
attended
to
address
in
all
of
the
applications
it's
proposed
to
address.
Okay.
L
Yeah
suresh
krisshnan,
so
Eddie
all
right,
so
the
thing
is
to
see
if
these
problems
are
real
and
there's
like
a
community
willing
to
solve
the
problem
right
like
ila
may
or
may
not
fit
as
a
solution
like
we
don't
know
that.
So
let's
do
the
first
step.
This
is
not
a
working
group
forming
Boff
just
to
see
like
you
know,
if
people
agree,
there's
a
problem
like
what
solving
and
then
the
province
can
go
and
work
at
not
the
past.
At
this
okay.
F
Take
on
that
yeah,
this
is
a
solution
that
would
fit
into
a
5g
slicing
framework
is
expected
to
support
the
business
of
mobile
broadband,
etc.
There's
actually
a
long
list
of
things
I
have
not
seen,
and-
and
that
does
concern
me
and
I-
would
like
to
see
that
before
I
went,
I
want
to
rush
off
and
do
this
next
person.
Please.
M
C
M
C
Think
that
would
go
under
the
the
requirements
for
that
specific
use
case
right.
So
what
are
the
requirements
for
that?
You
exceed,
and
it
also
depends
on
whether
you
you
have
to
support
multicast
in
this
exact
mode,
so
you
can
also
say
well
you're
using
native
multicast
anyway,
that
already
works.
So
how
do
you
deal
with
with
multicast?
So
it
may
actually
be
a
slightly
different
problem.
That's
being
targeted
to,
but
I
do
agree
as
as
a
whole
solution.
Yes,
we
have
to
consider
multicast.
So
my
statement
was
native.
C
C
M
C
C
To
the
specific
specific
node,
so
from
that
point
of
view,
it
actually
is
it's
pretty
good
at
any
caste
I'm
doing
I
can
do
the
mapping
and
then,
instead
of
doing
encapsulation,
to
get
it
to
an
any
caste
node
I
can
just
do
ila
and
that's
like
no
encapsulation
overhead.
So
from
that
point
of
you
would
actually
work
well
and
I.
Believe
that's
one
of
the
use
cases
that
that
Facebook
act
is
actually
deploying
right
now
is
any
cast
with
ila.
N
Let's
see
I
think
the
problems
faces
is
kind
of
varied
I
think
is
a
great
fit
in
the
data
center,
but
there's
a
lot
of
things
that
are
being
proposed
here.
So
I
guess
I'm
really
unclear
about
the
about
the
scope.
I,
don't
know
you
know
because
there's
a
lot
of
problems
that
intend
to
be
solved
and
also
can
you
go
back
to
the
slide
where
we
talked
to
the
Internet.
No.
N
Right
but
that
slide
doesn't
work
all
right.
There's
like
basically
insoluble
scaling
problems.
We've
had
we've
had
conversations
on
the
on
the
five
gang
IP
list
and
my
assessment
is
at
three:
it's
three
orders
of
magnitude
away
from
the
technology
that
we
have
today
in
terms
of
memory
bandwidth
in
readers
and
forwarding
table
size.
So
if,
if
that's
the
use
case,
I
think
Kalyan
is
prepare
is
proposing
that
we
start
with
that
use
case,
but
I
don't
think
it
can
actually
be
made
to
work,
and
so
that's
that's
sort
of
an
important
consideration.
B
I
had
conversations
with
my
Transport
colleague
he's
actually
sitting
over
there
and
we
talked
about
it.
So
we
do
have
the
I
understand
what
you're
saying
for
the
facing
to
the
internet
kind
of
a
thing
so
are
the
routers
that
are
over
there
that
deal
with
that.
This
one
is
towards
the
access
network
side
and
we
do
not
have
the
you
per
user
kind
of
router
advertisement
going
over
there
and
then
we
there
are
also
the
new
kind
of
routers,
where
you
can
go
to
tables
that
are
80
million
and
so
on
so
forth.
A
Me
paraphrase
his
concern:
I,
don't
believe
the
documents
have
described
a
workable
way.
It
may
well
be
possible
to
make
it
work,
but
at
the
very
least,
I
don't
think
the
documents
have
captured
a
workable
way
and
it's
important
for
taking
things
forward
that
people
actually
be
able
to
look
at
common
descriptions.
N
That's
a
subset
of
my
concerns.
Yes,
I
would
challenge
anyone
to
make
it
work,
but
yes,
the
documents.
It
is
a
fact
that
the
documents
do
not
describe
how
to
make
this
work.
Yes,
but
but
it's
important
before
we
decide
to
say
we're
gonna
start
with
this
and
make
this
the
primary
use
case
like
I,
said
I
personally,
don't
think
we
can
make
it
work.
This.
O
O
Has
to
be
okay,
so
that
means
I
can
ask
this
question
okay,
question
for
Tom:
if
a
surface
is
a
source
in
a
packet
and
a
destination
is
not,
and
the
packet
goes
all
the
way
to
an
ipv6
host
when
it
returns
it's
going
to
come
back
to
the
locator
address
in
the
destination.
How
does
the
Isle
a
node
know
to
translate
the
destination
address,
to
surf
prefix
and
not
the
source,
because.
C
O
A
P
A
A
Q
Tony
Lee
Arista
networks,
so
what
you're
trying
to
do
here
is
to
change
the
fundamental
architecture
of
the
host
and
yet
you're
not
changing
the
fundamental
architecture
of
the
network.
What
are
you
gonna
end
up?
Doing
is
you're
gonna
end
up
with
a
mismatch
and
you're
starting
to
see
that
already
because
of
ICMP.
This
is
this
is
a
clear
thing,
clear
indication
that
you
have
prop
architecture
problem.
C
C
Starts
to
come
and
I
can
also
I
can
also
mention.
So
if
you
look
at
the
data
center
use
case,
it
was
it
was
pretty
clear.
The
architecture
is
for
mobility
was
fundamentally
pretty
simple.
We
need
to
know
where
someone
is.
We
know
how
to
get
the
packets
to
them
as
quickly
as
possible,
and
they
can
move
around
so
in
the
mobile
use
case
in
data
center
was
very
clear
and
I.
Think
there's
a
lot
of
analogs
in
the
mobile
use
case.
So
what
we
don't
want
to
do
it.
C
Q
C
A
We're
not
comparing
alternatives,
but
I.
Don't
ok,
let's
move
quickly,
because
I
do
want
to
have
a
few
minutes
to
take
a
home
of
what
people
understood,
at
least
in
the
room,
I'm
not
expecting
resolution
but
I,
but
I
do
want
to
let
the
three
people
on
the
line
ask
and
yeah
Maya
IAB
Shepard
gets
to
tail
it.
I
am.
I
I
think
I
do
understand
both
the
general
problem,
space
and
and
the
two
use
cases
that
you're
suggest
well.
I
can't
say:
I
understand
everything
about
the
5g
one,
but
I
think
I
understand
the
two
use
cases
that
you're
talking
about
and
I
think
I
understand
what
your
intended
scope
is.
Yes,
one
of
the
things
I'm
unclear
on
is
pictures
where
this
goes
out
on
the
internet.
I
think
you're
gonna
run
into
problems.
I
wrote
a
similar
I
started
to
write
a
very
similar
draft
in
2008.
I
It's
called
draft
Wasserman
Ram
trip,
and
that
draft
used
the
same
mechanism
and
it
tried
to
solve
this
problem,
but
I
ran
into
intractable
problems
that
I
don't
see
that
you
solve.
One
of
them
was
ICMP.
One
of
them
was
what
happens
when
you
have
dynamic
routing.
The
other
was
around
nodes
out
there
that
don't
have
a
translator
and
how
you
know
how
they
perceive.
One
of
the
problems
is
that
you
don't
have
the
zones.
You
say
you
have
in
your
draft,
you
don't
have
where
an
identity,
space
zone
and
we're
in
global
zone.
I
You
have
we're
in
identity
space.
For
my
addresses
and
global
for
everyone
else,
all
global
and
identity
space
for
somebody
else's
addresses
and
global
for
everyone
else,
including
the
other
end
of
the
connection,
and
that
has
some
some
ramifications
that
aren't
really
captured
at
your
drafts
and
I
would
love
to
work
with
you
on
this.
If
there's
a.
C
Question
about
how
to
get
how
to
make
sure
you're
hitting
a
trend
transformer
the
locator
itself
is
an
address
of
a
note.
So
when
you,
the
packet,
has
to
route
to
that
note
what
you
can't
route
anywhere
else,
because
you're
overriding
that
with
basically
prefix
that
says,
that's
that's
the
note
ICMP
problem.
C
So
that's
the
mapping
system
I
acknowledge
the
ICMP
problem.
Icmp
is
going
to
be
tricky
in
any
state,
I
mean
imagine,
we
know.
Tunneling
has
the
same
sort
of
issues.
Segment
rolling
has
issues
with
ICMP.
Icmp
is
a
pain,
and
the
third
thing
was
about
identifier,
spaces,
yes
I,
and
that
kind
of
goes
back
to
my
statement.
I,
don't
believe
in
the
global
identifier.
Space
I.
I
R
R
You
discuss
about
privacy,
which
was
a
big
topic
last
last
a
few
months
ago
on
the
mapping
system.
I
do
see
you
put
identity,
and
this
was
a
big
discussion.
So
I'd
like
to
understand.
One
of
the
questions
was
about
long
lived
identity,
and
here
it
looks
to
me
that
the
solutions
proposed
before
on
actually
having
the
identity
of
the
skating,
the
real
identifier,
is
this.
What
you're
doing
or
is
this
something.
C
So,
identity,
it's
always
a
little
ambiguous
to
me,
but
let
me
say
that
we
have
identifiers
which
identify
something
we
can
give
multiple
identifiers
x'
to
a
note
and
to
the
outside
world.
If
they
see
say
two
addresses
with
two
different
identifiers,
they
should
never
be
able
to
tell
those
refer
to
the
same
note
so
identity.
If
identity
expresses
the
who
it
cannot
specifically
the
who,
like
that
device,
my
claim
is,
it
cannot
be
in
an
externally
visible
address
for
privacy.
R
We
are
on
the
same
page,
because
I
think
I
think
I'm
happy
to
see
that,
because
I
think
now
there's
a
real
understanding
that
identity
is
needed
for
privacy,
or
else
it's
very
difficult
to
achieve
privacy,
especially
if
you're
keeping
your
IP
address
as
one
fixed
everybody
who
look
up
this.
So
that
would
be
one,
and
the
second
thing
I
wanted
to
ask-
was
I
see
that
you're
actually
having
a
lot
of
similar
requirements
that
we
actually
put
it
in
our
ideas.
Can
you
confirm
that
or
no
on
the
requirements
of
the
mapping
system?
I.
C
A
R
E
So
tunnel
remodel
is
one
of
the
key
objectives
here,
right
and
I
assume
you
want
to
achieve
that
by
just
with
the
approach
of
transformations
or
des
transformations
right.
So
now
today,
if
you
look
at
gtp,
U
or
GRE,
and
that
we
carry
a
number
of
fields
right
essentially
here
the
GRE
key
right
and
now
within
this
128-bit
space,
you
need
to
put
the
identifier
you
need
to
put
the
locator.
You
need
to
put
the
cost.
If
you
want
to
do
cost
reservation,
you
need
to
the
DAC.
E
B
Mobility
use
case
we
are
looking
at
it
as
a
managed
domain
within
an
operator
network
and
it's
some
cases.
There
may
be
some
hops
in
there,
but
most
of
the
time
it
is
like
trying
to
get
everything
from
the
antenna
or
the
radios
to
the
one
of
the
centers,
where
we
can
make
it
in
convert
it
into
the
packets.
B
B
G
Not
Mike
just
a
quick
comment:
I,
don't
think
I
need
to
respond
to
this,
but
you
just
want
to
make
sure
it's
on
the
list
of
things
to
consider
is
yeah.
If
you
care
about
doing
ingress
filtering
inside
the
network,
maybe
you
need
to
some
additional
awareness
that
we
have
this
si
RS
as
well
as
regular
prefixes,
so
something
dad
to
the
list
to
go.
Look
at
so.
A
A
A
Okay
did
people
understand
the
scoping
that
was
laid
out.
Please
hum
if
you
did
understand
the
scoping,
not
as
many
please
hum.
If
you
didn't
understand
the
scoping
I'm
noticeable
hum
I'm
restating
this
of
the
room.
I
can
get
these
in
the
minutes.
We've
dealt
with
other
issues
that
need
to
be
addressed.
I'm
not
gonna,
go
into
the
use
cases
Suresh
you
get.
The
final
word.
L
Okay,
suresh
krisshnan,
so
the
idea
was
to
like
get
the
proponents
to
understand
like
the
scope
of
things
they
need
to
do
in
case.
They
come
back
here
with
like
a
better
proposal
and
I
really
encourage
people
here
to
sign
up
on
the
mailing
list
and
send
any
concerns
that
you
have
because
I
know
you
have
a
lot
of
concerns.
Looking
at
like
the
questions
that
came
in
there's
like
still
people
who
have
issues
understanding
like
how
this
is
gonna
work.