►
From YouTube: IETF97-INTAREA-20161116-1520
Description
INTAREA meeting session at IETF97
2016/11/16 1520
A
B
A
C
B
D
B
D
F
D
F
E
B
Not
well,
please
be
aware
that
this
is
an
official
ietf,
so
we're
under
the
IDF
not
well.
If
you
are
not
familiar,
please
take
a
look
and
read
it
so
the
usual
reminders
minutes
having
taken.
Then
the
meeting
is
recorded.
Your
presence
is
locked,
the
blue
sheets
are
around
feel
free
to
contribute
to
the
to
the
minutes
and
the
etherpad
this
will
be.
Public
blue
sheets
should
be
going
on
right.
Now
we
have
a
note
taker
thanks
in
jabber.
B
Hey
Chet,
can
you
do
the
job
for
us
yeah
thanks.
Thank
you.
Thank
you
perfect.
So
the
agenda,
it's
pretty
full.
Actually
we
got
a
couple
of
last
minute
ones.
So
we
start
with
the
document
status
as
usual
some
announcement,
then
tom
is
going
to
give
us
a
an
update
on
the
on
the
GUI
and
isla
drafts.
We
have
the
IP
broadcast
considerations
by
Ralph.
B
B
Ok,
none!
So,
let's
start
with
the
status
updates
so
or
the
interior
tunnels.
So
we
had
the
some
slides
presented
remotely
from
Joe
and
Mark
in
Berlin.
Since
then,
there
was
some
discussion
on
the
list
about
the
status
of
the
document,
whether
this
should
be
informational
or
PCP,
and
there
was
I
believe
an
update
to
the
document.
I
don't
see
is
his
mark
in
the
room
he's
nuts
okay,
so
he
was
going
to
give
a
quick
update
to
that.
B
So
we'll
skip
it,
I
guess
until
he
shows
up,
but
we
basically
want
to
advance
that
document
I.
They
think
it's
in
a
pretty
good
condition,
so
their
intention
would
be
to
to
move
it
forward
and
again,
if
Mark
shows
up
we'll,
let
them
give
a
one-minute
update
about
it.
But
otherwise,
please
take
a
look
and
10
comments.
If
you
have
any
other
documents,
we
have
the
IDF
interior
house
named
practice,
which
is
has
been
requested
publication.
It's
currently
in
the
is
G
Q.
B
Then
we
have
the
interior
ad
hoc
wireless
communications,
no
update
since
since
July
I.
Guess,
if
you
have
no
comments
Charlie
do
you
hook,
you
want
to
say
anything
more.
B
B
So
more
updates
calls
for
adoption.
We
have
a
couple:
the
ITF
entire
broadcast
consideration,
but
Rawls
is
going
to
give
a
comprehensive
presentation
about
it.
Then
we
also
have
the
env
03
that
we
inherited
now
it's
here
and
tom
is
going
to
present
and
we
have
one
announcement
for
my
tripoli,
which
I'm
going
to
give
you
next.
B
B
So
last
week
there
was
the
I
Triple
E
ADA
to
meeting,
and
you
may
remember
that
there
is
this:
a
specification
called
Omni
run,
which
defines
a
network
architecture
for
I
Tripoli
802
technologies,
meaning
something
going
a
little
higher
layer
than
what
they
usually
do,
defining
an
interconnection
of
802
technologies,
and
we
have
a
coordination
group
between
I
Tripoli,
an
ietf,
this
being
a
novel
lap.
It
was
decided
that
we
should
give
an
update
here
in
the
internet
about
the
status
of
the
of
the
specification.
B
B
So
again,
network
reference
model
for
an
functional
description.
Important
part,
is
the
scope.
So
the
document
specifies
an
arc
access
network
interconnecting
terminals
to
the
access
router.
So
that
is
the
important
part
you
have
a
in
this
light.
A
detailed
description
of
the
table
of
contents
in
the
information
that
it's
right
now
in
the
in
the
spec
and
the
the
scope
is
basically
the
blue
part
and
the
lower
picture
so
connecting
the
terminal
to
the
to
the
access
router
debate,
all
the
connectivity
between
the
terminal
and
access
router,
the
first
top
layer
to
envelope.
B
That's
that's
what
the
specification
is
about
again
some
basics:
there
there's
a
reference
model,
some
interfaces
that
hadn't
defined
some
functionalities,
discovery
subscription
and
so
on.
There's
more
details
in
the
in
the
latest
version
where
we
also
define
network
management
coordination
services.
This
is
generic
nomenclature,
but
it
maps
to
basically
a
and
d
SF
or
that
those
type
of
protocols
that
are
used,
let's
in
802
11
networks,
to
discover
what
kind
of
services
the
network
provides
or
there
could
be
like
if
you
do
white
spaces.
B
What
kind
of
frequencies
that
are
available
for
you
to
connect
so
again
describing
a
lot
of
details
on
the
the
composition
of
the
functions,
the
new
topic
that
they
added
is
network
virtualization.
So
that's
something
that
it's
also
being
hot
in
this
in
this
group.
The
idea
is
a
specifying
the
model
that
allows
network
virtualization,
so
some
mastic
surface
is
en
and
nav
and
how
they
can
be
applicable
to
raid
0
2
technologies
and
the
reason
why
we're
giving
this
announcement
here
is
because
the
the
current
draft
is
a
little
more
readable.
B
Now
it
provides
text
for
all
sections,
but
still
ongoing.
There's
mean
some
letter
ballots,
which
is
like
internal
calls
in
the
group
over
there.
But
now
they
are
looking
for
network
expertise
to
provide
comments,
and
that's
why
we
are
presenting
it
here
now
the
specification.
The
way
I
triple
e
works
is
this
wouldn't
be
available
to
anyone.
B
That
is
not
a
member
of
the
group
until
is
finished
and
published
by
I
triple
e
now,
because,
where
they
are
asking
for
input
specifically
form
network
experts
like
here
I
ETF,
there
is
a
way
and
there's
a
an
agreement
between
I
Triple,
E
and
IETF.
So
if
you
are
interested
in
reading
this
specification,
you
have
to
contact
the
I
Triple
E
80,
two
dot,
one
chair,
Glenn
Parsons,
and
there
is
the
the
email.
B
B
H
B
I
Just
start
so
this
is
about
the
privacy
considerations
document
on
the
chest
like
you
saw.
This
is
an
adoption
call,
but
it
has
already
been
adopted
by
the
working
group.
I
hope
not.
You
have
reverted
the
decision
next
item,
so
the
they
are
just
a
quick
recap
where
we
coming
from
the
origin
of
this
work
is
basically
we
did
experiments
on
not
wireless
networks.
I
We
did
not
our
campus
network
and
we
did
it
also
here
the
ITF,
where
we
found
a
lot
of
broadcast
and
multicast
protocols
a
lot
of
them
proprietary
and
what
we
could
do
with
that
is.
We
could
identify
people
their
devices,
but
we
could
also
identify
groups
of
people
and
how
they
share
data
and
busy
build
the
social
graph
of
the
of
the
network
I'm
just
by
looking
at
broadcast
and
multicast
data.
I
That's
really
not
good,
because
there's
PII
in
there
and
a
lot
of
other
information
and
that
justice-
it's
not
just
harmful
to
the
privacy
of
people,
but
it's
also
bad
for
a
couple
of
things
that
happen
in
in
this
organization,
but
also
not
eyes.
Deals,
for
example,
mac
address
randomization.
So
if
you
randomize
a
mac
address,
but
you
have
static
identifiers
and
broadcast
protocols,
there's
no
use
in
in
changing
your
mac
address
because
you
will
be
identifiable
I'm
constantly
next
slide,
there's
a
paper
if
you
want
to
see
all
the
details.
I
So
since
the
last
meeting
the
document
has
been
adopted
by
the
working
group
and
this
there
were
three
revisions
where
we
address
mostly
meting
this
comments.
There's
a
couple
of
comments
outstanding
I
get
to
that,
but
most
of
them
have
been
addressed
and
we
extended
the
document
content
neck
slide.
So
this
is
what
we
did.
We
edit
examples
and
per
request.
We
we
never
mentioned
any
company
names
or
anything
that
that
use
certain
protocols
in
a
weird
way.
So
these
are
anonymous
examples.
I
I
We
thought
that
is
useful
for
the
reader
and
we
moved
second
secondary
considerations
to
the
back
of
the
document,
for
example
that
when
you
broadcast
a
lot
admit
also
means
that
frequently
that
devices
cannot
go
to
sleep
and
your
own
device
cannot
go
to
sleep
and
that
potentially
drains
batteries,
but
that
has
nothing
to
lose
privacy's
who
removed
it
into
a
separate
section.
We
also
specify
the
attacker
more.
So
we
said
it's
a
large
receive
a
group
by
design.
I
So
next,
up
with
this
document
is
there's
two
comments
that
we
aware
of
that.
We
still
need
to
factor
in
this
there's
one
discussion,
somebody
wanted
about
the
general
usefulness
of
broadcast
and
multicast
and
that
we
will
add
and
that's
another
reference
we
should
include
and
the
concepts
and
there
that's
something
we
will
add.
But
basically,
from
our
perspective,
we
are
done.
I
If
there's
more
comments
from
the
group,
we
were
happy
to
receive
those
comments
and
factor
them
in,
but
other
than
that
we
were
about
to
finish
up
this
document
so
expect
one
or
two
more
and
releases,
and
then
we
from
our
perspective
or
down
nameless.
You
guys
have
more
comments.
If
you
have
any
comments
now,
you
can
give
them
to
me
directly.
Otherwise,
I'm
done.
I
J
J
Be
a
useful
thing:
it
looks
very
interesting
works,
that's
actually
being
discussed
in
dns
SD
tomorrow.
So
there's
two
drafts
one
describes
the
privacy
issue
and
the
general
framework
for
addressing
it.
The
other
describes
a
pairing
protocol
that
allows
two
devices
to
initiate,
initiate
a
pairing
and
then
when
they
communicate
using
obfuscating
names
and
they
use
dns
sorry
they
use
TLS
for
mdns
to
get
the
information.
So
it
looks
quite
encouraging.
J
H
H
Say
for
a
minute
that
you're
building
a
green
field
network,
you
would
really
like
to
use
unnumbered
interfaces
on
your
point-to-point
links
between
routers
or,
if
it's
v6,
you'd
like
to
leave
those
with
just
link
local
addresses
and
nothing
better.
People
would
like
to
do
this.
The
reason
they
don't
is
because
they
need
to
be
able
to
ping
an
interface
and
it's
really
hard
to
ping,
an
unnumbered
interface
or
an
interface
that
has
only
link
local
addresses,
so
X
ping
to
the
rescue
next
slide.
H
Okay,
how
does
X
ping
work
well
x,
things
an
application,
and
it
is
not
only
very
similar
to
it's
a
perfect
analogue
to
ping.
It
does
exactly
what
ping
does
it
sends
a
probe?
It
waits
for
a
response.
The
probe,
instead
of
an
ICMP
echo,
is
an
ICMP
extended
echo.
Instead
of
an
echo
response,
it's
an
extended
echo
response.
H
The
interesting
thing
is
that
X
ping
makes
a
distinction
between
the
destination
interface
and
the
probe
to
interface.
The
second
bullet
point
is
the
only
important
part
of
this
presentation.
Pay
attention
then
go
to
sleep
for
the
rest
of
it.
Let's
say
for
a
moment.
You
have
a
router,
it
has
a
loopback
address
that
is
globally
reachable
and
it
has
a
bunch
of
unnumbered
interfaces.
You
send
your
echo
to
the
destination
address
to
the
loopback.
H
You
send
your
echo
to
the
loopback
and
the
echo
has
in
it
an
identifier
to
tell
you
what
interface
you
are
probing
now.
Obviously,
it
can't
identify
the
probit
interface
by
a
dress,
because
the
probed
interface
doesn't
have
an
address.
It
identifies
it
by
port
name
or
by
if'
index
or
maybe
by
MAC
address
or
maybe
by
link
local
address.
It
identifies
at
some
other
way,
so
you
send
up
you,
send
your
echo
your
extended
echo
message
to
the
destination
address
to
the
one
that
has
a
real
global
address.
H
The
echo
message
includes
an
identifier
that
tells
you
what
what
interface
you're
probing
and
then
the
response
comes
back,
giving
you
information
about
the
probed
interface
and
not
the
destination
interface.
Anyhow.
Okay,
next
slide.
H
The
recipient
of
the
ICMP
message
determines
whether
the
queries
well-formed,
whether
the
query
type,
is
supported,
for
instance,
if
you
probed
by
name
if
it
will
answer
to
a
probe
by
name
on
whether
the
query
uniquely
identifies
an
interface
instance.
You
might
have.
You
know,
tried
to
query
by
link
local
address,
but
guess
what
two
interfaces
on
this
router
have
the
same
link
local.
H
Okay,
we
have
an
implementation.
This
is
what
it
looks
like,
and
this
should
look
vaguely
familiar.
The
ex
pain
command
looks
kind
of
like
paying
except
the
command
lines.
A
little
different.
The
minus
I
tells
you
that
I
am
probing
the
interface
with
the
name,
Giggy
0000
and
the
destination
address.
H
Okay,
here
again
we're
doing
the
exact
same
thing
except
this
time.
The
probed
interface
is
identified
by
its
ipv6
link,
local
address
we
sent
and
also
notice
that
the
destination
address
you
know:
10
10,
10,
dot
2
is
an
ipv4
address
and
the
probed
address
were
identifying
by
its
ipv6
linked
local,
it's
perfectly
legal.
For
that
matter.
We
we
could
have
identified
the
probed
interface
by
its
MAC
address
too,
or
any
other
kind
of
address
it
might
have
had
next
slide.
H
Okay,
here's
a
look
at
what
the
ICMP
extended.
Echo
looks
like
this
looks
phenomenally
like
the
old
echo,
except
you
have
an
extent
extension
structure
at
the
end
of
it
next
slide.
The
extension
extension
structure
has
this
interface
identifier
object.
It
identifies
the
probed
interface
either
by
name
I,
f
index
or
address,
and
we
have
a
question.
I
And
yes,
so
I
have
to
admit:
haven't,
read
the
document,
but
so
irregular
ping
is
nice
because
it
gives
you
reach
ability,
information
as
well
right,
because
you
reach
the
address
that
you
actually
paint.
This
is
different
right,
so
think
about
this.
For
a
second.
H
I
I
Address
a
different
it
might
have
might
but
you
same
probability.
Nobody
this
is
I
mean
the
information
you
get
is
the
same.
You
get
from
the
command
line
right
with
you
type
in
the
command
by
okay,
it's
up
is
active.
You
have
I,
be
496,
just
that
you
send
a
message
and
not
log
into
the
box,
but
the
only.
H
I
And
of
a
second
question,
if
you
that's
far
away,
I
have
a
second
question
so,
and
this
also
allows
you
something
else
that
you
can
do
a
thing,
because
you
can
basically
try
to
it's
a
little
bit
of
guesswork,
but
you
can
try
to
figure
out
all
the
interfaces
that
are
up
on
that
from
the
outside
that
are
up
on
that
box.
You
can
basically
introspect
the
sales.
L
M
H
Okay,
next
slide:
okay,
the
the
interface
identifier
object
when
you're
probing
by
address
you
can
probe
by
any
kind
of
address.
That's
why
we
have
this
a
fee
and
reserved
and
the
address
as
a
variable-length
thing.
So
if
this
has
a
night
ipv
106
address,
1
ipv
106
is
defined,
you
can
probe
by
it
next
slide.
H
Okay,
the
echo
response
looks
suspiciously
like
the
old
echo
response,
except
it
has
an
S
bit
and
some
protocol
flags
the
protocol
Flags
map
to
the
protocols
that
might
be
running
on
the
box
and
the
SB.
So
now,
I
can't
even
remember
what
it
what
it
tells
you.
Oh
it
tells
you
that
at
least
one
protocol
is
up
on
the
box
next
slide.
H
H
Ok,
talk
a
little
bit
about
error
messages,
no
error,
X
ping,
not
enabled
malformed,
query:
query
type,
not
enabled
the
question
about
security
came
from
here.
If
you
are
configured
so
you
cannot
accept
a
probe
say
by
interface
name
and
you
probed
by
interface,
name,
you'll,
get
that
error
three.
This
time
type
of
query
isn't
supported.
Also,
there's
possibility,
there's
no
such
interface
and
there's
a
possibility
that
multiple
interfaces
wouldn't.
I
H
M
Comer
knows
one
additional
question
on
the
security
part
you
you
are
able
to
to
filter
on
what
you
provide
that
reply
at
response
or
not,
but
for
example,
for
anything
that
do
you
provide
a
reply.
You
provide,
for
example,
this
ipv4
ipv6
up
so
I'd
you're.
Probably
information
is
dropping
in
with
ipv4.
Do
it
bro
information,
whether
that
interface
is
running
at
36
or
not
as
the.
H
N
A
couple
questions
so
this
point:
if
I
understand
this,
this
is
I'm
bobien
didn't
this
works
in
one
node.
It.
N
H
H
N
This
could
easily
the
same
interface
and
the
same.
You
know
CLI
command,
it's
not
clear.
Anything
would
have
to
change.
It
would
just
do
something
slightly
different.
If
it
wasn't
a
note
on
the
BOK,
you
would
just
send
a
packet
to
that
address
and
it
you'd
have
to
know
that
it
could
reach
it
uh-huh.
So
let
might
think
about
it.
Let's
let.
H
H
Okay
and
finally,
a
reminder
about
what
the
f
it
is,
I
couldn't
remember
that
the
S
field
is
set
if
the
code
is
equal
to
no
error
and
the
probe
dinner
faces
up
protocol
flags
indicate
which
protocols
are
running
on
the
interface
next
slide.
Next
slide,
we
ought
gem.
O
O
Up
I
most
likely
will
be
pink
in
from
neighboring
node,
because
I'm
looking
at
the
link
status,
oh
I,
can
get
that
information.
Another
way
right
so
but
I
assume
someone
might
have
a
use
case.
I
still
think
about
specifying
ipv6
address.
I
would
say
if
you
specify
link-local,
you
must
include
zone
ID.
O
H
O
Think
I
looked
in
there
how
you
form
replies,
I
said
coming
into
bob
yeah,
who
there
are
some
requirements
on
how
not
generates
icmpv6.
For
example,
I.
O
O
H
H
B
So
I
think
we
ran
out
of
time,
but
maybe
we
can
take
that
to
the
list.
They
definitely
creating
a
lot
of
interest
well
at
least
questions.
So
so,
okay.
H
B
P
Yeah
does
this
work?
Hiya
sorry
was
out
of
the
room
earlier
yeah
the
tunnels
document.
There
was
some
feedback,
some
sentiment
towards
moving
forward.
Joe
and
I
have
agreed
to
meet
up
after
this
meeting.
We
can't
meet
at
the
meeting
because
he
never
he's
not
able
to
attend
the
meetings,
so
that
would
probably
be
in
like
in
november
december
and
provide
another
update
and
maybe
it'll
be
finally
time
for
working
group.
Last
call
after
that.
What
do
you
think.
B
Q
P
P
C
Q
P
P
Wait
till
we
get
to
the
next
Rev
right,
but
if
it's
not
ready,
then
it
won't
be
then
it's
not
I
would
like.
There
was
some
sentiment
expressed
of
time
to
move
this
forward.
It's
been
a
long
time,
so
I
think
that
it's
probably
good
for
us
to
collect
the
feedback
that
we
have
eliminate
the
sections
that
aren't
finished
and
try
to
move
it
forward.
But
you
know
please
give
feedback
to
the
list
because
Joe
is
holding
most
of
the
pen
here.
Yeah.
B
B
R
So
generic
UDP
encapsulation
I
presented
this,
I
believe
last
IETF
in
area
and
the
idea
is
a
basic
encapsulation
format.
That's
extensible!
We
request
it
working
group
adoption.
Apparently
it
has
been
so
we
now
have
a
working
group
draft
one
of
the
different
one
of
the
happenings.
Since
last
IETF.
We
got
an
in-depth
review
by
Bob
Brisco,
so
I
didn't
respond
to
most
of
those
comments.
The
second
draft,
thats
related
to
goo,
is
goo
extensions
draft.
This
is
a
set
of
fundamental
extensions
for
generic
UDP
encapsulation.
R
The
primary
difference
from
last
IETF
is
that
we
added
a
bit
to
security
to
create
a
larger
number
of
possible
security
fields
and
that
required,
rearrange
rearranging
the
header
just
a
little
bit
and
one
of
the
security
fields
is
defined
to
be
more
like
an
H
Mac
field.
So
we
have
a
hundred
and
thirty
two-bit
field
that
can
do
authentication
in
a
similar
way
to
segment
routing
security
next
slide.
R
So
the
GU
extensions.
Currently
we
have
six
defined
the
first
five
here:
the
security
field,
header
checksum,
remote
checksum,
offload
fragmentation,
payload,
transform
those
are
in
the
primary
GU
extensions
draft.
That
I
mentioned
a
virtual
networking.
Identifier
is
in
a
separate
draft
which
we're
looking
at
in
indigo
three
and
then
there's
some
number
of
other
possible
extensions
that
we
we
may
look
at
in
the
future.
Thanks
like
so
one
clarification,
I
wanted
to
make
primarily
based
on
some
of
Bob's
input,
was
to
point
out
that
in
GU
the
model
of
extensibility
is
not
TL
VZ.
R
It
is
flag
fields
much
like
jury
and
the
rationale
that
we
have
for
that
is
tlv.
Zat.
Later
three
protocols
and
below
have
historically
not
had
a
lot
of
success,
as
we
know
from
ipv4
options
in
ipv6
extension,
headers
and
terms
of
processing.
We
know
there
have
a
lot
of
complexity
associated
with
them
wire
overhead
hardware
processing.
One
other
aspect
of
this
that
was
kind
of
input
was
a
number
of
expected
options
that
we're
going
to
have,
and
we're
kind
of
basing
this
number
on
how
TCP
options
and
IP
options
unfold
it.
R
R
This
is
something
came
up
in
NV
03
just
now,
but
in
terms
of
the
options
that
we
would
intend
on
standardizing,
we
don't
expect
a
lot
of
them,
so
they
should
fit
into
the
the
framework
of
the
flag
fields
for
the
at
least
Im
into
the
foreseeable
future,
looks
like
so
next
steps
on
GU
we're
going
to
ask
that
the
GU
extensions
become
a
working
group
item
in
an
area
and
also
more
feedback
from
this
working
group
would
be
appreciated.
Thanks
like
so
turning
to
ila,
we
updated
the
draft,
the
the
iolite
main
IL.
R
A
draft
is
really
about
the
data
plane.
The
control,
plane
and
mobility
will
be
another
drafts
and
I'll
a
also.
I
presented
last
time
in
an
area
refresher.
This
is
identify
our
locator
address,
saying
it's
a
way
to
within
a
ipv6
address
in
code
identifier,
locator
kind
of
like
an
encapsulation
we're
also
in
the
process
process
of
deploying
this
and
Facebook
as
our
data
center.
No
data
center
virtualization
solution
next
slide.
R
One
I
think
I
wanted
to
mention.
Is
the
mapping
function?
This
we
clarified
a
little
bit
in
the
latest
draft,
so
we
separate
ila
host
from
ila
routers
the
host
perform
kind
of
what
we
think
more
of
host
functionality,
so
they
can
maintain
a
mapping
table
the
routers
maintain
more
of
the
complete
set.
This
will
have
impact
on
the
control
plane.
R
It
doesn't
affect
the
data
plane
too
much,
although
we
did
add
checksum
offload
or
checksum
adjust
and
things
like
that
to
compensate
for
or
faster
translations
on
the
host
next
slide,
so
the
control
plane
work
is
being
done
in
parallel.
It's
not
really
clear.
Yet
if
this
is
routing
area
work
or
in
area
we're
also
looking
at
some
alternative
solutions,
they
may
provide
input.
The
ideas
Lisp
may
help
us
with
a
control
plane.
So
that's
we
expect
that
will
be
defining
this
as
we
move
forward
next
slide.
R
There
are
a
few
caveats
to
ila
that
we
did
kind
of
elaborate
on
in
latest
draft.
Icmp
can't
have
some
some
difficulties,
so
the
problem
is
when
we
send
a
packet,
if
it's
translating
the
network
that
actually
changes
the
destination
address.
If
an
ICMP
error
is
subsequently
generated
for
that
packet
and
it
goes
back
to
the
source
without
anyone
looking
within
the
ICMP
air,
it's
possible
that
the
source
season
ICMP
air,
for
a
destination
that
it
didn't
actually
send
to.
So
there
are
two
mitigations
to
this.
R
One
is
if
the
host
itself
supports
ila,
it
can
potentially
do
the
reverse
translation
and
recover
the
original
destination
in
the
ILA
or
in
the
ICM
here,
and
the
second
one
is
more
to
do
what
has
done
in
nadan
RC
5508,
which
is
to
actually
in
the
path
somewhere.
If
we
hit
an
IL,
a
router
can
do
the
reverse,
translation
and
again
deliver
the
original
ICMP
or
packet
with
the
original
destination.
To
the
sexy
to
the
source.
R
Multicast
is
also
another
kind
of
difficult
one,
so
in
ila
we're
modifying
the
destination
address
with
the
locator.
Obviously
in
multicast
we
really
can't
do
that
would
have
to
be
the
source
address,
but
this
creates
some
convolutions
modifying
the
source.
Address
affects
non
multicast
receivers
now
have
bad
source
address
to
send
replies,
so
I
mentioned
this
this
morning
in
Lisp,
and
some
lifts
guys
think
this
might
be
solvable.
P
P
R
That's
fine,
so
both
I
langu
or
means
to
do
network
virtualization
overlay
networks
in
a
sense,
locator
identifier,
separation,
so
GU
is
an
encapsulation.
It
allows
extensibility
in
particular.
Security
is
probably
one
of
the
the
stronger
points,
at
least
within
a
data
center
aisle
a
no
extensibility,
but
the
advantage
there.
That
means
no
on
the
wire
overhead
and
in
fact,
and
I
la
in
ila,
a
TCP
IP
packet
looks
like
TCP
em
tcp/ip
on
the
wire,
and
so
we
have
complete
on
the
wire
k.
P
Every
question
you
mentioned
data
center
virtualization:
do
you
see
active
migration
of
containers
as
something
facebook
wants
to
do?
Yes,.
A
P
R
So
there
are
other
reasons
why
we
want
this
in
the
data
center
even
earlier
than
that
live
migration
and
implies
a
lot
of
other
stuff
has
to
happen
most
of
that
sexually
implemented.
It
turns
out,
but
gluing
all
that,
together
into
an
actual
full
scale,
data
center
solutions
a
little
bit
of
a
challenge.
We've
been
looking
at
this
problem
for
for
many
years
right
now,
these
job
schedulers
there
what
they're
doing
is
pretty
crazy.
They
have
to
optimize
all
of
these
jobs
and,
like
I,
said
if
they're
wrong
and
something
higher
priority
comes
along
right.
R
Now
we
do
a
lot
of
task
killing
and
losing
progress.
So
there
is
some
value
in
that,
but
the
other
the
earlier
advantage
of
ila
is
that
giving
them
an
address.
/
cask
actually
simplifies
a
lot
of
the
management.
The
service
look
up,
and
things
like
that.
So
that's
why
we're
implementing
it
now
really
is
to
get
that
first
step,
which
is
a
dress.
/
task
does
some
interesting
things.
Every
task
now
has
an
address,
which
means
it
has
a
full
port
space
that
it
can
use.
R
I
R
Difference
between
go
and
the
envy
of
three
protocols
is
that
goo
is
really
a
generic
product,
which
is
the
primary
reason
why
we
asked
to
put
it
into
Ontario.
The
network
virtualization
component
of
goo
is
really
just
a
32-bit
identifier
that
makes
it
a
network
virtualization
protocol,
but
for
goo
proper
we're
actually
finding
a
lot
of
use
cases,
just
as
basically,
a
extensible
replacement
for
GRE
honestly
is
kind
of
what
it's
like
Jerry.
I
B
S
S
Is
no
like
do
that
right
and
but
I
do
have
a
different
question
about
ila
right,
like
so:
I
went
through
the
RAF,
and
this
really
no
scoping
for
the
draft
so
where's
the.
Where
is
it
applicable
and
stuff
like
that
right?
So
the
way
it's
written
today,
it
cannot
work
on
the
internet
right
like
it
works
very
well
in
the
data
center,
but
like
it
needs
like
more
work
to
work
on
the
internet
like
the
control
plane.
R
I'm
not
sure
we'd
agree
that
it
can't
work
on
the
internet.
I
think
we
would
need
to
define
what
that
means.
One
of
the
use
cases
we're
looking
at
is
the
5g
and
the
mobility
as
a
solution,
but
I
la
as
a
solution
for
mobility.
The
question
is:
where
do
you
need
to
do
translations?
So
the
translation
is
basically,
you
can
think
of
them
as
tunnels.
R
So
if
I
need
a
tunnel
over
part
of
the
internet
as
long
as
I
have
an
ingress
point,
an
egress
point
under
your
control
I
under
my
control
and
what
we
think
will
happen
in
say,
a
mobile
carrier
is
that
when
packets
enter
into
the
network
from
the
internet,
we
can
do
translation
there
and
within
the
carrier's
network,
actually
get
it
to
the
right
base
station
and
where
the
the
ue
is
located.
So
that's
not
a
data
center
sort
of
implementation,
that's
actually
for
carriers,
then
that
will
get
us
into
the
possibility.
R
If
two
different
carriers
are
talking
with
each
other,
can
they
exchange
enough
information
so
that
I
can
do
the
translation
in
one
carrier
that
takes
a
packet
all
the
way
into
another?
Because
remember
once
the
pack
is
translated
to
any
note
on
the
path.
It's
just
a
packet.
They
are
just
routing
this
based
on
the
upper
64
bits
so
that
they
won't
know.
So
we
don't
need
explicit
ila
support
anywhere,
except
the
end
points
that
are
actually
dealing
with
it.
Right,
like.
R
B
Ok,
just
fine,
no
question
wrapping
up,
then
sorry,
we've
had
that
discussion
and
we
have
to
move
on
quickly
to
the
to
the
next
topic.
You
say:
you're,
going
to
request
a
working
group
draft.
We
got
gooey
inherited
from
mb
l3
here
and
now
we're
having
this
discussion,
whether
this
is
applicable
to
to
internet
or
specific.
So
strange
are
you:
are
you
assuming
that
it'll
be
adopted
here
or
in
nov
03,
the
the
ILA?
Yes,.
L
So
can
we
have
30
seconds
before
miss
my
grades?
Just
sure
I
did
this
review
for
tolman
and
there
was
like
two
month
one
way
to
lay
on
the
reply
and
I'll
give
a
two
month.
One
way
delay
on
me
because
it's
got
to
be
a
symmetric
path.
It's
just
it
takes
that
long
to
read
all
that
stuff.
Ok,
ok,
thank
you
will
get
a
respond.
I.
P
C
C
There
are
typically
so
that
hose
can
talk.
The
routers
and
routers
can
talk
to
host,
but
host
can
talk
to
host,
to
simplify
and
there's.
There's
at
least
two
examples
of
this.
One
is
split-horizon
being
used
in
dsl,
where
the
router
thinks
it's.
A
single
link
sees
it
as
a
single
IP
prefix
assigned
to
that,
but
the
host
can
actually
talk
to
each
other
and
the
other
one
is
private
vlans,
which
is
a
bit
more
complicated
and,
as
a
result,
is
a
superset.
C
So
the
document
talks
about
that
as
the
sort
of
model
for
this,
where
you
have
three
different
classes
of
ports,
promiscuous,
community
and
isolated,
and
in
particular
this
allows
for
having
multiple
promiscuous
port.
So
these
are
the
ports
that
can
talk
to
everybody
and
that's
where
you
would
connect
your
routers
so
next
slide.
C
C
You
might
not
actually
learn
the
way
you
expect
them
and
in
some
earlier
revision,
I
dotted
text
about
proxy
ND
that
dave
taylor
had
asked
for.
So
I
don't
know
if
people
want
to
have
more
refresher
at
the
document.
The
last
slide
has
some
about
that
or
you
can
go
read
the
document,
it's
not
very
long,
but
it
seems
like
I,
haven't
gotten
any
negative
feedback
of
their
stuff.
C
There
hasn't
been
that
many
comment
other
than
the
ones
have
responded
here,
but
it
seems
like
this
is
operating
a
bit
like
a
working
of
document
in
terms
of
getting
going
through
the
revision
cycle
and
whatever.
But
my
biggest
question
is:
is
this
something
that's
useful
and
if
so,
can
we
go
through
the
the
process?
Motions
making
it
work
in
your
blast,
call
as
to
something
that
sorry
make
it
a
working
of
document
and
then
is
there
something
that
people
can
read
and
see?
Is
it
ready
for
a
working,
a
blast
call
it?
B
B
B
H
Ok,
special
registries,
a
few
years
back
well,
every
once
in
a
while,
the
ITF
allocates
a
block
of
addresses
for
a
special
use,
things
like
10,
/,
8
or
192
168,
/,
16,
you're,
all
familiar
with
those
addresses.
Well,
once
upon
a
time,
every
few
years
we
used
to
write
a
document
that
talked
about
all
of
the
special
addresses
and
superseded
the
last
one.
About
five
years
ago,
Brian
Haberman
and
Michelle,
cotton
and
Leo
Vigoda
and
I
wrote
a
document
that
catalog
them
all
said.
H
This
was
going
to
be
the
last
document
and
from
now
on,
we
would
just
update
iono
registries
when
you
allocate
a
new
special
address,
and
this
this
whole
document
6890
said
when
you
do
this.
These
are
the
pieces
of
information
that
you
must
put
in
the
registry.
So
people
will
know
what
the
address
is.
That
way.
We
don't
need
to
write
the
document
to
get.
You
know,
we
don't
need
to
update
this
document
every
few
years.
Well,
anyway,
we
wrote
this
RFC
6890.
H
It
was
a
very
boring
document
and
nobody
read
it
and
it
had
a
bug
in
it
and
nobody
noticed
it
for
five
years.
Basically,
here
is
the
bug.
One
of
the
attributes
that
I
said
you
needed
to
describe
when
you
posted
a
new
registry
is
an
attribute
called
global
and,
in
my
mind,
what
that
meant
is
this
prefix
is
likely
to
be
found
in
the
global
routing
tables.
H
Anyway
years
later,
people
will
use
the
document
they
looked
at
this
global
field
and
said:
hey
wait
a
minute,
this
special
address,
you
say
its
global
and
it's
really
not,
and
we
all
scratched
our
head
a
little
while
and
thought
about.
Well.
Why
are
we
having
this
argument?
Well,
it's
because
our
definitions
of
the
word
global
or
different
when
I
use
the
word
global
writing
the
document.
The
very
first
time
I
thought
it
meant
you're
likely
to
find
this
and
the
global
routing
tables.
H
What
other
people
thought
is
global
in
the
sense
of
the
IP
addressing
architectures
global
meaning.
It
has
significance
beyond
the
administrative
domain
global
scope.
Exactly
anyway,
we
updated
the
document
to
be
specific
about
what
we
meant
by
global
and
the
meaning
is
global
scope,
because
we
change
the
definition
of
that
word.
Global
scope.
For
a
couple
of
the
addresses
we
changed
their
global
setting
from
true
to
false.
You
know
we
were
false
to
true
we.
H
You
know,
we
thought
it
was
false
because
it
doesn't
show
up
in
the
global
routing
tables,
but
if
you
use
the
other
definition,
this
is
true.
So
anyhow
this
we
can
skip
all
the
way
through
the
slides.
You
know
this
document
reiterates
what
the
rules
are
well.
First,
it
talks
about
all
the
special
addresses.
It
reiterates
the
rules.
What
is
it
you
need
to
say
about
an
address
when
you're
going
to
register
it?
And
here
are
the
things
you
have
to
say,
look
back
up
up
back
up
back.
You.
H
Minute
there
see
okay
I'll
be
through
this
finished.
These
are
the
things
you
have
to
say
about
an
address
next
slide.
Next,
one,
here's
here's
an
example
of
what
an
entry
looks
like.
In
any
event,
this
update
is
very
similar
to
the
other
one,
except
for
the
this.
The
use
of
this
word
global.
It's
still
very
boring,
so
I
assume
no
one
will
read
it
just
progress
it
just
tensing.
O
B
S
S
Document,
so
it's
a
it's
a
sit
anyway,
so
I
don't
mind
doing
either
one
the
last
one
was
like
80
sponsored
by
ralphs,
so
like
I
can
pick
it
up
like
it's
up
to
the
group
to
the
side.
So
if,
like
you
want
to
bring
it
to
me,
just
bring
it
I'm
happy
either.
One
just
gonna
run
it
through
group
anyway.
So,
okay,
okay,.
N
K
K
But
on
the,
on
the
other
hand,
the
quality
of
experience
depends
on
which
access
you
are
selecting
and
what
is
the
core
network
and
what
is
the
part
in
the
network?
So
Phi
Phi
has
totally
different
of
different
characteristics
than
LT
in
in
terms
of
scalability
and
coverings
and
I'm.
Similarly,
the
core
networks
did
they
differ,
what
kind
of
services
they
offer
so
in
order
to
guarantee
the
best
combination
for
quality
of
service
consistent
quality
service,
we
need
some
sort
of
mechanics
to
combine
these
different
pieces
of
the
connectivity
next
slide.
Please.
K
So
the
mums
is
addressing
to
that
kind
of
problem
and
what
it
proposes
is
the
ability
to
select
access
and
core
network
parts
independently,
so
that
that
we
can
dynamically
adapt
this
election
based
on
network
conditions.
So
we
have
visibility
in
the
network
paths.
It
is
a
negotiation
mechanics
between
the
host
and
the
network
here
at
the
requirements.
K
What
the
draft
lists
lists
properly,
the
main
ones,
are
the
ones
that
the
uplink
and
downlink
accesses
need
to
be
able
to
be
selected
differently,
and
there
is
a
Caucasian
component
in
there
I
be
anchoring
in
terms
of
allocating
the
IP
address
for
the
mobility
events
needs
to
be
flexibly.
You
should
come
in
depending
on
on
the
axis,
on
over
different
core
networks
and
what
else
and
the
path
selection
it
needs
to
be
based,
based
on
on
the
analytics
of
the
network
and
change
based
on
the
status
of
the
network.
K
Next
word
here
is
the
architectural
framework.
The
components
were
what
what
is
mom's
proposal
brings
into
other
are
the
connection
managers.
We
have
network
connection
manager
which
sees
the
network
internals
as
a
visibility
across
these
access
networks,
which
are
depicted
here,
dsl,
LTE
and
Wi-Fi,
for
instance,
and
it
has
a
controlled
bath
negotiation
path
with
the
corresponding
entity
at
the
client
side,
connection
manager,
their
client
connection
manager
as
it
is
called
and
and
then
we
have
two
proxies
data
data
would
use
a
plane
proxies
that
the
deal
with
a
multiple
user
claim
protocol.
K
So
the
solution
is
not
coupled
with
any
of
the
transport
protocols,
but
but
it's
providing
this
capability
of
nicosia
switch
IP
address
and
which
encapsulation
and
which
transport
protocol
is
to
be
used.
Next
slide,
please
so
in
in
terms
of
that,
other
IETF
work
on
on
this
area
is
the
control
mechanisms
for
negotiating
between
the
client
and
the
network.
The
proper
configuration
to
pick
up
the
correct
path
in
a
dynamic
way.
It
is
agnostic
to
the
transport
protocols.