►
From YouTube: IETF100-INTAREA-20171115-1520
Description
INTAREA meeting session at IETF100
2017/11/15 1520
https://datatracker.ietf.org/meeting/100/proceedings/
A
A
D
D
Not
well,
everyone
should
be
familiar
now
with
not
well
yeah.
So
would
you
guys
mind
taking
your
conversation
outside
the
room?
Thank
you.
Sorry
Ari
should
be
familiar
with
not
well.
If
not,
please
do
read
it.
This
an
IETF
meeting
in
interior,
as
you
know,
minutes
are
taken
thanks.
So
much
for
trillion
for
that
the
min
meeting
is
being
recorded
and
your
presence
is
locked.
Blue
sheets
are
passing
around
the
on
line.
Minutes
will
be
on
this
etherpad
link
if
you
want
to
take
a
look
and
contribute
during
the
meeting.
D
E
D
Okay
and
thanks
he
and
for
the
40
minutes,
so
the
agenda
will
gonna.
Give
you
a
quick
update.
Then
we're
gonna
have
updates
from
the
TSV
from
Gauri
is
Gauri
in
the
room.
Okay,
great
perfect.
So
then
we
have
the
provisioning
domains
from
Eric,
Tao,
Tom
and
bloody
near
and
Jin
way.
At
the
end,
we
have
a
couple
of
remote
presenters,
so
we're
gonna
try
to
make
it
as
smooth
as
possible.
Moving
on
to
the
working
group
status,
update
the
privacy
considerations
for
IP
broadcast
and
multicast
well,
he's
been
submitted
for
IES
gene
for
publication.
D
C
D
F
Hi
I'm
Cory,
Cory
first
from
TS,
vwg
and
I,
will
try
and
take
you
through
four
drafts.
This
is
interesting,
I'm
going
to
try
and
move
further
back,
so
I
can
read
with
my
bifocals.
So
the
think
on
the
screen
in
front
of
me.
Okay,
so
I'm
going
to
look
at
three
drafts
in
TS
vwg
and
quickly
highlight
them
because
they
may
be
of
interest
to
you
or
they
may
be
of
interest
to
things
that
you're
going
to
develop
in
the
future.
F
F
So
if
yer
understand
diffserv
and
you're
interested
in
the
use
of
diffserv
core
points
in
your
networks,
then
please
pay
attention
to
that.
Last
line
there
that
we're
going
to
talk
about
this
on
Friday,
okay,
probably
good
enough
EC,
ends
probably
a
bit
more
something
that
people
have
been
talking
about
recently
and
we
have
a
draft
called
EC
and
experimentation
which
is
about
to
be
finally
published
as
an
RFC.
F
So
this
is
heads
up
of
work,
that's
been
done,
but
it
has
implications
for
many
people,
the
changes
it
makes
our
first
of
all,
it
changes
the
use
of
ECT
one,
the
ECT
one
coal
point
in
all:
IP,
v6
and
v4
packets
now
is
repurposed.
It
specifically
is
being
allocated
for
use
for
experimentation,
and
the
important
thing
is
that
equipment
must
not
now
interpret
the
cee
mark
in
the
ec
n
field
to
mean
that
the
packet
is
lost
equivalent.
It
doesn't
indicate
the
packets
as
being
lasting.
F
It
indicates
only
the
packet
as
being
congestion
marked
that
may
make
difference
if
you're
monitoring
networks
or,
if
you're,
using
that
information.
It
also
makes
different
to
the
transport
protocols,
so
the
transport
protocols
are
being
updated.
Separate
updates
are
in
progress
in
TCP
M
to
do
an
update
for
the
marking
when
EC
T
0
is
set.
The
first
EC
encore
point:
that's
the
aid
work
that
also
is
very
near
working
group
last
call
so
look
at
TC
p.m.
F
for
that
and
the
work
on
EC,
M,
plus
plus,
and
a
family
of
drafts
referring
to
l4
s
which
are
progressing
through
the
TS
vwg
group.
All
of
this
is
transport
stuff,
but
if
you're
interested
in
network
layer
headers,
the
bits
are
carried
at
the
network
layer
and
people
look
at
the
network
layer.
So
there's
an
interaction
here
and
that
interaction
has
changed
next
slide.
F
So
let
me
just
talk
a
little
bit
slowly
through
this
one,
and
we
all
know
that
TCP
can
send
big
segments
through
the
network
and
that
even
works
when
using
pppoe
or
any
other
encapsulation,
because
magically
TCP
figures
out
how
big
a
packet
to
send
and
how
it
does
that
there
is.
Sometimes
it
takes
path
to
big
messages
and
that's
good
when
that
works.
Sometimes
it
uses
MSS
clamping,
that's
common
in
DSL
networks.
F
They
simply
rewrite
the
field
and
eventually
endpoints
learn
the
right
way,
and
many
TCP
stacks
also
use
path,
layer,
MTU
discovery
which
sends
big
packets
through
and
checks
using
the
transport
protocol
when
those
packets
get
through
and
therefore
as
a
firm
understanding
of
what
actually
works.
Of
course,
all
these
three
things
are
usually
using
combination
and
I,
don't
know
anyone
who's
actually
looked
at,
which
ones
are
the
most
important,
because
we
tend
to
do
all
three
of
them
and
hopefully
between
them.
F
We
get
a
good
answer
because
TCP
kind
of
works-
oh
but
oh
dear-
and
some
people-
don't
think
we're
going
to
use
TCP
much
anymore
and
there
are
tunnels
and
other
things
out
there
that
don't
use
TCP.
Surprisingly,
so
what
I'm
saying
you
don't
use
TCP?
Well,
of
course,
the
ICN
path,
ICMP
path
to
big
messages,
still
give
you
advice
or
sending
a
to
bigger
packet,
so
that
part
of
the
algorithm
works,
but
it's
not
universally
supported
in
the
network.
Many
paths
to
big
messages
get
filtered
black
holes
occur.
F
So
wouldn't
it
be
nice
if
you
could
do
a
similar
sort
of
treatment
for
UDP
packets,
and
that
brings
a
whole
lot
of
issues
like
how
do
you
choose
probe
sizes?
What
sort
of
do
you
probe
with?
How
do
you
react
when
you
lose
a
probe,
and
some
of
these
paths
are
unidirectional,
so
we
have
to
provide
some
sort
of
feedback
mechanism
to
make
this
happen,
and
you
may
even
have
to
probe
to
see
whether
the
data
is
getting
through.
F
It's
all
a
little
bit
of
a
tricky
mess,
but
we
were
brave
and
we
something
so
next
slide.
I'm
going
to
talk
about
this
on
Friday
in
TS
vwg,
what
we're
proposing
is
a
state
machine
which
tries
to
find
a
good,
effective
path,
MTU
for
a
UDP
or
a
protocol
running
on
top
of
UDP
and
the
ones
were
actually
targeting.
The
moment
are
the
SCTP
based
and
calculations,
because
we
have
running
code
in
bsd
that
actually
does
most
of
this.
We
can
adapt
that
and
bring
that
up
to
date
to
make
it
work.
F
We
have
worked
with
UDP
options,
which
is
job
touches:
draft
in
TS
vwg
to
stick
a
few
bytes
between
the
UDP
payload
and
the
IP
header.
Some
people
think
that's
gloriously
good
and
the
people
think
it's
horrible,
but
it
is
a
way
of
transporting
the
information
you
need
for
this
particular
piece
of
work.
F
If
the
work
is
adopted,
then
we'd
like
to
pan
it
out
to
look
at
other
transports
and
that
could
also
include
tunnels
and
anything
else,
perhaps
even
wonderful,
quick
if
they
want
this
way
of
doing
it,
currently
an
individual
draft
and
is
to
be
discussed
on
friday
at
TS
vwg.
Maybe
we
won't
adopt
this
time,
I,
don't
know
and
but
I
think
in
future
we'd
like
to
do
some
work
in
this
space.
D
D
D
G
Okay,
here's
an
update
on
the
PVD
draft.
It's
the
first
time
we
are
presenting
the
zero
zero
since
it
has
been
accepted
to
the
working
group.
I
came
around
September
last
time,
so
there's
a
draft
for
couple
of
people,
although
at
the
author's
I,
think
this
room
as
files
and
rows
of
maybe
except
David
and
Marcus.
G
So
what
are
pvd's?
There
is
an
RFC
that
explain
it
and
basically
we
spend
two
three
minutes
explaining
what
the
PVD
is
and
then
we'll
jump
to
some
more
discussion
and
updates.
So
PVD
is
a
set
of
related
information,
think
about
DNS
name,
servers,
Pio
next
stop,
and
so
that
works
together
and
pvd's
can
be
identified
by
what
we
call
the
PVD
ID,
both
on
the
network
transmission
as
well
inside
the
host.
G
We
also
think
that
we
can
go
much
deeper
or
much
further
than
playing
DNS
information.
We
can
provide
information,
for
instance,
about
whether
there
is
a
captive
portal,
whether
there
is
a
walled
garden
and
to
which
a
piece
set
of
IP
address
the
wall
garden
is
limited
to.
We
can
provide
maybe
on
some
bandwidth
measurement
or
settings
for
the
first
stop.
G
The
current
proposal
is
to
use
into
ipv6
routers
attachment
only
so
that's
mainly
targeting
ipv6.
We
can
work,
maybe
as
well
with
ipv4.
If
we
want
to
do
it,
I
will
describe
mainly
the
v6
part.
So
in
the
array
we
use
a
neighbor
discovery
option
the
start,
of
course,
with
the
time
the
length
we
have
a
couple
of
bits
that
are
reserved
and
tour
them
as
important
with
a
sequence.
Number
I
shall
come
back
on
this
and
we
have
the
PVD
ID.
G
The
PvdA
ID
itself
is
a
DNS,
fully
qualified
domain
name,
that's
very
important
because
it
allows
you
to
fetch
additional
information.
Two
things
to
note
here.
It's
so
simple,
simple!
It
requires
as
well.
If
you
have
multiple
pvd's
inside
the
same
network,
it
needs
to
be
sent
in
different
arrays.
So
it's
one
array,
/
p,
VD,
that's
the
current
set,
and
that
will
come
back
on
your
comment
on
this
two
flags
H
signals
that
you
can
use
the
fully
qualified
domain
name.
That's
there
to
fetch
more
information
from
a
server
over
HTTP,
the
alb.
G
Obviously
you
can
add
one,
and
only
one
PVD,
with
this
bit
set
right
sequence
number
R
for
what
simply
because
we
use,
if
you
had
the
H
flag,
we
use
the
fully
qualified
domain
name
to
fetch
additional
information
once
and
then
you
forget
about
it
with
the
assumed
and
the
sequence
number
is
changing,
the
oath
is
required
or
should
at
least
to
fetch
a
refresh.
So
if
you
change
the
additional
information,
let's
say
in
one
hour,
then
you
pushes
array
with
the
castle
unique
ass
with
a
different
sequence
number.
G
G
We
can
use
as
well
and
link
the
information
that
you
can
receive
by
dhcpv6,
simply
by
assuming
that
the
dhcpv6
relay
or
server
is
the
same
link
local
address
as
your
router.
It's
not
perfect,
but
what's
most
of
the
time,
so
more
information
as
soon
as
you
have
the
edge
bits
set,
what
you
do
at
it.
So
should
it's
not
a
masked
by
the
way
the
host
can
use
HTTP
over
TLS
and
fetch
this
well-known
URI
and
the
PVD.
This
basically
information
retrieval
HTTP.
It's
a
JSON
file,
some
example.
G
That
basically
say
this
PVD
applies
to
all
those
addresses
so
kind
of
to
make
sure
that
there's
no
miss
configuration
there.
Then
you
can
add.
The
properties
like
in,
for
instance,
I
put
the
a
characteristic
for
the
first
up,
so
something,
let's
say
between
your
VDSL
router
and
the
dis
llama,
indicating
the
maximum
throughput
that
you
can
achieve,
and
so
on
other
example
below
I'm
all
about
the
whether
it
is
a
captive
portal
or
garden
and
so
on,
and
so
on,
pretty
flexible
here.
G
The
OSB
area
is
basically,
if
you
support
the
PVD,
you
can
ask
an
application
or
everyone
to
basically
use
one
PVD
or
another
of
a
set
of
them.
Now,
with
the
current
status,
if
you
receive
three
PV
DS
and
you
are
non
PVD
aware
oast,
you
will
route
process
those
three
arrays
and
you
will
basically
mix
all
the
information
together
leading
to
the
classical
issue
that
we
have
right
now.
So
PVD
does
not
serve
this
problem.
Does
it
make
it
worse?
Yeah.
H
In
fact,
Archie
Telecom,
so
yeah
I
read
the
draft
and
first
of
all,
thanks
for
picking
this
one
up,
it's
been
kicking
around
a
long
time,
rich
uncle
Addison's
having
another
guard
the
case
that
you've
got
there
of
it'd,
be
no
worse
than
things
at
the
moment
that
one's
a
problem
to
me,
I
can't
solve
this
at
the
moment-
and
you
know
here
comes
another
solution
that
actually
doesn't
work
in
this
case.
I
think
it
would
be
really
good
if
we
could
discuss
you
know
possible
ways.
H
G
I
I
It
would
just
send
you
one
RA
with
all
three
prefixes,
and
so
the
behavior
of
the
host
could
be
expected
to
be
different
in
that
case,
and
that's
really
the
concern
that
I
have
and
I
think
possibly
ian
has
so
I'd
really
like
to
see
a
solution
that
allows
us
to
basically
make
the
PVD
options
invisible
to
a
host
that
doesn't
support
PVD.
So
the
host
doesn't
see
a
change
in
behavior
on
the
router
and
only
PVD
supporting
host
see
something
new
okay,
Dana.
J
Lorenza
cool
EDI
I
am
NOT
a
fan
of
the
idea
of
having
implicit
pvd's
be
specific
to
the
link-local
address,
because
it
would
break
users
case
use
cases
that
exist
today.
One
use
case
that
was
used
in
the
ITF
network
a
couple
of
meetings
ago
was
you
had
one
reader
doing
you
know,
arrays
and
and
with
pios
and
one
we
were
doing
our
dns
s,
because
the
main
Rooter
didn't
support
our
DNS
s
at
the
time
and
the
behavior
and
existing
host.
J
All
existing
hosts
was
to
take
those
two
and
put
them
in
the
same
PVD
and
use
them
consistently.
And
if
you
have
a
new
PVD
aware
host
and
you
put
them
into
different
pvd's,
you've
got
two
implicit
dvds
that
have
in
broken
configuration
and
suddenly
you
have
an
implementation
problem,
so
you
have
to
decide
what
to
do,
and
so,
basically,
your
new
host
on
an
unmodified
network
behaves
differently.
Okay,.
J
K
Polly
Apple,
so
as
a
co-author
one
thing
to
respond
to
Lorenzo
I
think
that's
a
good
point,
I
think
it's
part
of
this.
You
if
you
say
that
if
we
want
them
to
be
distinct,
then
just
add
your
PVD
name,
make
it
explicit.
You
can
do
that
all
the
time
and
so
and
then,
if
you
want
to
join
them
explicitly,
you
can
put
the
same
name
in
them
and
that's
great
so
I
think
we
probably
weaken
the
implicit
one
to
say
that
you
know
this
can
work.
K
If
you
have
one
implicitly
D
that
gets
the
other
options,
it
may
be
full
of
dragons.
If
you
don't
know
what
you're
doing
explicitly
so
be
aware
that
it
has
the
same
problems
it
has
today,
but
essentially
we're
giving
you
a
name
for
the
PVD
to
rationalize
it.
If
you
so
sleepy
yet
and
then
to
Ted's
point,
definitely
I
think
this
is
something
that
needs
to
be
addressed
and
I.
Think
that's
the
main
weak
point
here.
K
There
have
been
two
general
ways
of
solving
this
problem
that
we've
discussed,
one
which
I
think
is
kind
of
come
up
more
in
the
past,
but
I
think
we
don't
like
as
much
is
going
the
approach
of
having
kind
of
containerized
PVD
options
in
which
I
imagine
still
the
the
main
that
can
the
legacy
v4
PVD
would
probably
still
want
to
be
a
name
and
all
the
other
are
a
bits
would
be
exposed
on
the
outside.
But
then
you
could
have
other
areas
essentially
just
be
PVD
containers
that
can
work.
K
If
we
need
to
go
that
route,
we
can
there's
a
little
bit
more
ugliness
there,
because
then
we're
kind
of
stuck
long
term
with
a
solution
which
some
things
are
containerized.
Some
are
not,
and
it's
essentially
a
long-term
compromise
for
a
short-term
problem.
While
we're
dealing
with
devices
that
don't
know
about
this.
One
other
option
that
Eric
client,
I
and
the
runs
were
discussing
earlier
was
if
we
can
essentially
change
how
on
one
hand
when
the
router
solicitation
is
sent
out.
K
If
we
expressed
in
a
bit
that
we
are
PVD
aware
as
a
client,
we
could
receive
unicast
our
A's
for
the
extended
pvd's
that
would
not
go
out
to
other
clients
and
then
on
the
advertisement
side.
We
could
essentially
define
that
there
is
another
multicast
address.
That
is,
the
other
RAS
are
sent
out
to
all
the
time
and
that
PVD,
where
clients
will
listen
to
both
and
accept
RS
from
both
and
treat
them
completely
equally,
and
they
don't
really
care
where
they
come
from.
K
But
then
anyone
who
is
not
Peabody
aware
would
only
be
looking
at
the
traditional
multicast
address
and
they
would
only
see
the
same
view
that
they
would
see
today,
and
so
it
means
that
you
have
a
lot
of
flexibility,
but
then
he
also
can
end
up
having
a
relatively
sane
and
simple
deployment.
When
you
know
you
don't
have
legacy
clients
in
the
future,.
I
Ted
lemon
again
so
the
way,
the
way
that
we
contemplated
solving
this
problem
back
when
there
was
an
if
working
group
was
that
we
would
just
have
PVD
options
in
the
our
a
in
the
in
the
prefix.
There
would
be
sub
options
of
the
prefix
option
and
those
options
could
in
turn
contain
some
options
that
had
information
about
which,
to
which
name
servers
to
contact.
I
G
That
space
constrained
in
the
RA
yeah
it
teaches
busy
yeah,
of
course,
because
Eric
couldn't
be
fragmented.
So
that's
already
an
issue.
That's
one
issue
we
see
with
this,
which
is
what
we
call
the
Eric
on
the
PVD
container.
That's
nothing
roughly
the
same
thing,
the
same
concept,
basically
making
PVD
unaware
people
ignore
the
set
of
information.
So
there
is
one
issue
the
size
we
can
be
limited
in
the
amount
of
information
on
the
amount
of
errors.
Pvd
you
put
there
and
pretty
much
like
Tommy
said
we
are
basically
making
a
solution.
J
Had
to
respond
the
earlier
comment,
I
think
one
of
the
main
things
are
an
improvement.
I
think
that
we
one
of
the
main
things
that
we've
improved
over
the
thinking
that
we
had
in
the
myth
time
frame,
was
that
the
ACP
over
TLS
has
never
need
length
limits
and
it
can
be
like
much
more
easily
extended
right
and
I
hate.
J
L
L
You
know
because
it's
way
going
way
out
of
the
just
the
internet
layer
up
to
you,
know
to
the
application,
layer
and
I'm,
not
convinced
that
you
really
need
to
have
that
much
data
that
you
can't
put
in
you
know
datagrams,
and
the
other
issue
is
I
raised
on
in
my
comments
during
the
adoption
call
is
there's
Appendix
B
with
a
bunch
of
stuff
about
billing.
There's
nothing
in
the
rest
of
the
document
that
uses
the
word
billing,
I
and
I
think
it
should
be
removed.
L
L
G
It
so
you
will
take
it
out.
I
will
take
it
away.
That's
no
problem
again!
Please
take
off
night
and
now,
when
we
disagree,
I
think
we
need
to
agree
that
we
disagree
on
the
fetching
of
HTTP
and
some
other
the
application
layer,
because
that's
really
important
to
store
a
lot
of
information
there
that
you
cannot
put
in
the
single
array.
Yeah.
L
Well,
I'm
again,
I
I
think
it's
a
bad
idea.
I
think
this
will
be
very
fragile
and
it
can
have
all
kinds
of
odd
behavior.
You
know
I
mean
this
is
information
in
a
router
advertisement,
you
know
or
an
ende
and
it
seems
then
having
to
go
and
get
stuff
from
the
web
is
is
like
that
makes
my
head
hurt,
so
I
I
think
you
should
really
think
hard
about
finding
another
way
of
doing
it.
Maybe.
J
Lorenza
clearly
to
that
point,
I
am
we
thought
about
this
at
some
length
and
we
thought
about
many
options,
and
one
thing
that
was
very
clear
in
the
mind
of
the
implementers
of
this-
and
this
has
been
true
for
months
years
and
since
he
said
has
been
kicking
around,
is
that
the
initial
configuration
in
the
RA
must
be
atomic
and
must
be
sufficient
to
give
you
everything
that
you
need
to
do.
Networking
right.
J
This
stuff
is
a
complete
disjoint
set
of
configure
information,
which
is
ocular,
config
information,
and
it
is
at
best
metadata
about
networking,
if
not
like
entirely
separate
config
information.
It
will
never
be
a
goal,
and
maybe
we
should
just
write
this
in
very
big
block
letters
and
that
it
will
never
be
a
goal
that
you
are
not
provisioned
until
you
do
this,
you
must
have
full
connectivity.
Well,
you
know
things
like
captive
portal
accepted
that
aren't
on
your
control,
but
you
must
have
full
connectivity
atomically
upon
receiving
this
RA
right.
J
You
have
to
have
network
layer
connectivity,
and
this
is
the
rest.
This
is
all
metadata
right,
which
you
might
not
even
ever
want
to
care
about.
Fetching
so,
and
so
I
think
we
do
understand
your
concerns,
but
but
we
felt
that
you
know
if
we
had
this
hard
separation
between
the
two.
It
did
make
sense
to
use
these
other
mechanisms
other
than
the
fact
that
we
already
do
HTTP
for
provisioning
in
the
sense
that
the
captopril
check
has
already
HTTP
but,
like
you
know,
but
but
there
is
even
conceptually
solid
I.
M
On
the
same
topic,
oh
I
was
about
to
say
about
the
same
thing.
The
idea
is
that
everything
that
is
going
to
influence
the
networking
stack
of
a
host
is
going
to
be
in
the
RA.
We
are
not
going
to
put
anything
in
the
in
the
additional
information
that
it's
going
to
modify.
The
IP
stack
the
way
the
hosts
pH
on
the
IP
layer.
The
additional
information
is
really
intended
for
applications.
Behavior
the
weight
application
work.
The
way
applications
decide
on
which
DVD
to
use
this
kind
of
stuff.
G
G
C
K
K
J
C
Text
in
the
drafts
would
be
useful.
I
have
another
area
where
I
think
additional
text
is
is
required
so
HTTP,
it's
not
clear
exactly
what
what
this
provides
you
other
than
confidentiality,
they
basically
the
equivalent
of
anonymous
diffie-hellman,
and
it
talks
about
doing
some
additional
checks,
but
I,
don't
know
whether
the
the
entity
on
the
host-
that's
retrieving.
This
stuff
has
a
list
of
routiers
that
it's
gonna
validate
against
or
not
whether
justice
also
entered
is
sufficient.
C
G
I
So
I,
just
the
reason
I
got
up,
is
because
I
was
reading
the
slide
I'm
thinking
of
myself
Wow.
What's
the
trust
model
for
all
that
information
that
you've
got
on
that
slide,
it's
not
clear
to
me
that
you
have
a
trust
model
and
that's
something
it
needs
to
be
addressed
in
this
document.
I,
don't
know
exactly
what
the
trust
model
should
be,
but
I
tend
to
get
a
little
paranoid
about
this
stuff,
like
you
know
who
can
claim
the
name
through
Hotel
a
Poli
Wi-Fi,
you
know
I
mean.
G
That's
a
huge
problem,
yeah
that
this
one,
you
can
say
whatever
you
want,
but
the
point
is
well,
it
depends
upon
the
user,
the
user
interface,
which,
if
you
have
multiple
PVD
to
select,
will
you
show
the
fully
qualified
domain
name
that
ends,
for
instance
like
Verizon,
calm
or
cisco.com
or
whatever.
So,
and
you
know
it's
been
in
fact
reverse
SSL,
so
you
can
trust
somehow
right.
Okay,
do
you
display
the
localize
name
there?
Well,
this
is
exactly.
I
O
K
The
names
like
certain
attributes,
like
the
captive
portal
API
URL,
is
useful
because
it
essentially
is
a
way
to
communicate
from
the
network
that
you
know.
This
is
what
it
says
you
can
do
if
that
doesn't
pan
out,
because
that
server
isn't
really
there.
Well,
then,
you
know
that
there's
something
wrong.
Yes,
exactly
right,
so
I
do
believe
that
most
of
the
keys
and
stuff
in
here
I
think
from
the
key
document
do
need
to
be
stripped
out.
K
I
think,
as
we've
been
discussing,
there
probably
should
be
some
like
I
own,
a
registry
for
how
we
register
keys
and
we
leave
it
much
more
agnostic
for
now
putting
stuff
in
the
UI
very
problematic
if
that's
not
represented
to
the
user.
What
this
really
means
right,
where
it
comes
from
one
use
case,
for
something
like
a
name
or
identifier
we
were
discussing
with
Michael
earlier
about.
You
know
situations
in
which
you
say:
I
have
my
generic
internet,
PVD
and
I.
K
Have
a
video
streaming
PVD
some
attribute
like
a
name
in
there
would
allow
not
a
user
but
an
application,
but
say
that's
written
for
that
network
to
say
you
know,
find
me
a
PVD
that
claims
it
has
this
name.
You
know
it
could
be
lying,
but
at
least
I
will
try
it
and
you
know,
do
my
own
authentication
with
the
actual
end
application
server
and
it
is
a
hint
for
which
one
to
use
so
I
believe
use.
Cases
like
that
are
a
little
bit
safer
or
more
useful.
So
we
should
look
at
that.
P
Suresh
krisshnan,
like
ad
hat
off
I,
think
one
of
the
things
that
could
like
kind
of
handle
all
of
this
questions
raised
is
like
a
scoping
statement
which,
like
try
to
say
like
what
the
document
doesn't
address
like
because
there's
like
bunch
of
things
that
it
doesn't
address
and
I
think
it's
by
design
right
like
because,
if
you
add
like
this
container
stuff,
like
you
know,
PVD
aware
non
Aware's
stuff
and
you
had
the
origin
authentication
for
this
thing,
you
end
up
with
the
same
myth
draft
right
like
that.
We
had
so
I.
P
Think
if
you
have
a
clear
scoping
statement,
saying
like
these
are
the
known
failure
modes
for
this
other
things
like
non
goals
for
this
document.
I
think
that
would
set
the
tone
for
the
rest
of
the
document.
So
people
don't
expect
to
find
something
further
John
and
then,
like
you
know,
a
working
group
can
make
the
decision
on
whether
that's
the
right
set
of
things
to
do,
but
I
think
that
clearly
specifies,
like
you
know,
what's
getting
covered.
Thank
you
for
the
advice.
G
Indeed,
so
come
back
on
the
document,
so
what
we
changed
since
the
adoption
by
the
working
group,
we
I
rewrote
the
INR
consideration
because
you
are
asking
for
new
by
discovery:
option
they're
the
PVD
ID
inside,
which
is
a
fully
qualified
domain
name
at
the
very
beginning.
It
was
encoded
internally
as
a
DNS
name,
so
kind
of
compress.
If
you
know
what
I
mean,
then
we
make
it
plain
ASCII
and
then,
based
on
some
comment
from
the
working
group,
we
moving
back
to
a
DNS
format.
Okay,
so
I
think
we
are
there.
G
J
G
G
And,
of
course
they
are
inside
and
outside
and
blah
blah,
but
the
point
right
now
is
to
be
able
to
specify
to
scope
the
world
garden
PVD.
We
could
do
it
by
addresses,
maybe
as
well
that.
I
And
just
to
expand
slightly
on
the
controversy
that
might
come
up
there.
If
you
specify
that
you
that
a
particular
PVD
supports
a
particular
zone,
isn't
that
doesn't
that
imply
that
that
so
that's
the
PVD
to
use
for
that
zone
sure
so
that's
a
really
great
way
to
capture
all
the
traffic
for
that
zone.
L
Q
G
There
are
other
security
sentences
in
the
tank
by
the
way.
So
it's
not,
as
I
said,
one
big
change
compared
to
the
previous
one,
at
least
for
the
existing
implementation,
is
that
we
changed
the
way
we
write
the
fully
qualified
domain
name,
which
is
a
PVD
ID,
was
ASCII.
Now
it's
following
RFC
1035:
we
do
it
more
complex
methods.
Okay,
there
was
a
huge
amount
of
decision
of
privacy
in
Prague,
so
we
try
to
address
it.
G
One
thing
to
note
is
that
when
we
fetch
the
JSON
file
over
FTP
over
TLS,
it's
typically,
this
server
will
be
with
venue
a
Miss
rative
domain.
It
will
not
traverse
the
wild
Internet
and
you
will
get
anyway
information
by
the
oath
when
the
oath
is
accessing
your
DNS
server
or
is
accessing
your
radio
server
directly
because
you
is
authenticated
or
your
DHCP
server
is
using
DHCP
because
you
are
within
one
immensity
of
domain.
G
So
we
make
it
clear
in
the
text
that
is
with
typically
within
an
initiative
domain,
and
we
all
know
that
all
operating
systems,
whether
it's
laptop
base
or
mobile
base,
they
try
to
discover
whether
there
is
open,
Internet
access
or
whether
there
is
a
captive
portal.
So
they
use
a
variation
of
the
scheme
which
is
described
here.
They
go
and
open
a
connection
to
someone
on
site
and
see
whether
what
they
receive
is
correct,
yes
or
no,
and
then
they
detect
whether
it
is
a
captive
portal,
yes
or
no.
So
what
is
the
more
private?
J
J
G
J
G
G
G
Easily,
because
that's
implementation
status,
so
nothing
will
change
compared
to
Prague,
except
that
the
accattone.
We
have
opened
the
a
chippies
that
also
serving
now
array,
and
there
is
one
router
vendor
and
you
can
get
the
name
I
guess
which
is
implemented.
This
version
of
the
PVD
as
in
the
2d
array,
next
step.
So
that's
the
one
of
course
base
already
on
the
feedback
will
receive
today.
We
need
to
get
some
applause
coming
out
of
the
sky,
find
a
solution
in
this
piece
with
the
group
regarding
this
multiple
array.
G
What
we
do
with
the
legacy
host
and
something
I
would
really
really
love,
because
we
have
multiple
implementations
running
right
now
and
we
are
currently
using
the
code
which
is
2
5
3,
which
is
experimental,
and
now
again
somebody
from
the
University
in
Japan
came.
Can
I
get
the
code
to
run
in
my
place?
Ok,
so
we
meet
and
I
would
love
to
get.
The
consensus
within
the
working
group
to
get
through
Jana
earn
every
discovery
option
for
the
PVD
ID.
J
On
this
point,
actually
going
back
to
your
previous
slide,
where
it
says
Linux
implementation
has
the
kernel
patch
been
sent
for
review
upstream?
It's
such
that
I'm,
not
upstream
it.
Yet
please
send
a
rep
stream
ASAP,
because
our
lead
time
is
measured
in
years
and
do
bear
in
mind
going
back
to
the
point
that
you
have
on
the
next
slide.
That.
J
The
Linux
kernel
uses
a
version
of
by
default,
uses
a
truncation
of
sha-1
256,
that
is,
that
is
invalid.
They
implemented
draft
whatever
and
the
RFC
changed
the
final
value,
and
we
still
can't
fix
it,
because
the
backwards
compatibility
upstream
is
rejecting
patches
too,
to
take
the
RSC
value.
So
if
this
can
it
well
that's
backwards?
J
G
R
But
mark
Townsley
I
think
I'm,
just
gonna
echo
a
bit
of
what
Lorenzo
said
so
in,
but
it
should
be
obvious
that
in
order
for
us
to
upstream
it,
we
need
a
real
code.
I,
don't
think
they
take
it
with
253,
and
this
section
1348
61
is
perfect
for
our
case
I
think.
So
what
what
we
need
is
a
consensus
call
from
a
working
group
that
says
yep.
P
So
so
I
kind
of
explained
the
procedure
to
Eric
a
little
bit.
So
the
request
needs
to
come
from
the
working
group
so
once
like
they
are
ready
to
make.
The
request,
like
the
chairs,
can
do
like
a
consensus,
call
and
ship
off
a
request
to
me
and
I'll.
Do
it
like
as
fast
as
Marc,
can
get
leaner
so
also
do
something.
A
L
You'll
have
to
confirm
it
on
the
list
anyway,
but
I
sort
of
wonder
if
this
seems
to
me
like
it's
a
long
way
from
being
done,
and
so
you
know,
I
worry
a
little
doing.
The
allocation
too
soon
might
create
a
whole
nother
set
of
problems,
especially
if
there
starts
to
be
running
code
that
gets
deployed
and
then
we're
going
to
need
another
one
later
and
so
I'm
not
sure
seems
like
a
little
fast
to
me.
L
R
It's
not
like
this
just
appeared,
it's
been
it's
been
going
on
for
years.
There's
multiple
hackathons,
there's
running
code.
There's
multiple
implementations:
there
are
implementations
popping
up
from
people
that
we
are
not
directly
in
contact
with.
All
we're
talking
about.
Here
is
a
code.
If
we
completely
screw
up,
we
can
get
another
code,
but
I
I,
don't
think
that's
gonna
happen.
I'd
like
to
hear
from
you
know.
Maybe
Lorenzo
has
an
opinion
on
that.
R
J
Is
there
a
process
for
calling
back
the
code?
No,
they
are
see
I,
just
read
it.
It
says
like
one
when
the
options
base
is
85%,
full
we're
gonna,
look
at
all
the
reclaimer
ones
to
see
which
ones
are
not
in
use
anymore
and
I
can
imagine
how
somebody
with
you
know
how
concerns
like.
Well,
you
know,
we've,
you
know,
that's,
you
know
not
gonna
happen
in
next
few
decades.
Maybe
so
what
do
we
have
you
know?
J
Are
we
gonna
have
multiple
implementations
that
don't
talk
to
each
other
or
have
like
incompatible
packet
formats
or
something
right,
I
think
if
there
were
a
process
to
reclaim
the
code
or
to
call
it
back,
then
you
know
that
would
make
it
easier
for
us
to
actually
devote
a
temporary
code.
Look
if
we
could
can
we
have
a
code
with
an
expiry
date.
I
don't
know.
R
P
They
do
like
it's
not
in
that
place
over
there,
but,
like
iesg,
keeps
getting
the
early
allocation
like
report
every
sometime
and
I
think
like
I,
think
it's
a
year
or
something
where
the
explorations
just
go
away
like
if
it's
just
an
early
allocation
which
doesn't
follow
up.
It
just
goes
away
Thanks,
so.
S
S
S
Okay,
so
the
intended
audience
of
this
draft
is
network
protocol
designers
and
the
idea
is
that
there
are
actually
two
purposes.
One
is
the
draft
defines
a
set
of
recommended
time
stamp
formats,
relatively
small,
set
of
recommended
time
stamp
format,
which
should
typically
be
enough
for
anyone
who
needs
to
integrate
a
time
stamp
into
a
packet
in
most
cases,
for
the
specific
cases
where
none
of
these
recommended
time
stand
formats
fit
what
you
need
in
your
new
time
protocol
or
your
new
network
protocol.
S
Sorry,
this
draft
specifies
guidelines
of
how
to
define
a
new
time
stamp
format,
so
the
history
of
this
draft
it
was
submitted
a
few
months
ago.
It
was
originally
submitted
to
the
internet
area
working
group
in
the
last
ITF
meeting.
We
presented
it
here
and
also
an
NTP
and
based
on
the
suggestion
from
our
ID.
It
was
finally
submitted
to
the
NTP
working
group
and
it
was
recently
adopted
by
the
NTP
working
group.
S
So
one
thing
the
draft
talks
about
in
the
new
version
beyond
the
two
main
goals
which
I
talked
about
two
slides
ago,
is
things
you
need
to
consider
before
you
define
time
stamp
format
or
before
you
decide,
which
time
stamp
format
to
use.
So,
for
example,
if
you
need
a
time
stamp,
you'll
need
to
think
about
things
like
a
time
stamp
resolution
the
wraparound
period,
the
time
stamp
size
number
of
bit
and
also
coexistence
with
other
protocols.
S
S
So
one
of
the
things
we
do
in
the
current
draft
is
we
specify
some
of
the
existing
RFC's
that
use
time
stamps,
for
each
of
them
will
show
which
of
the
recommended
time
stamp
formats
is
used
in
some
cases,
none
of
the
recommended
time
stamp
formats
is
used,
and
also
the
draft
includes
a
couple
of
examples
of
how
you
would
use
recommend
the
time
stamp
format
when
you're
defining
a
new
network
protocol,
so
it's
kind
of
a
cookbook
for
how
to
define
a
network
protocol
with
the
timestamp
okay.
So
the
next
steps
we're
expecting.
S
First
of
all,
we've
had
a
few
comments
on
a
mailing
list
which
we'll
need
to
address
in
the
next
version.
We
plan
to
do
that.
Another
aspect
which
we
started
working
on
and
still
needs
to
be
expanded,
is
creating
a
control
field,
an
optional
control
field
which
can
be
attached
to
the
time
step
and
describes
information
which
is
related
to
that
time
stamp.
S
T
U
S
U
D
D
W
F
Y
Y
Going
to
give
you
an
update
on
our
latest
work
on
Sox
version
6,
so
next
slide,
please
so
I'm
gonna
give
you
a
quick
refresher
on
what
Sox
6
does
as
compared
to
version
5.
The
main
thing
that
we
do
is
wish
that
we
shave
our
party
tees,
so
the
client
is
very
optimistic
and
sends
as
much
information
upfront
as
possible.
I
mean
it
advertises
its
supported,
authentication
methods.
Y
It
requests
that
the
proxy
openers
suck
open
our
connection
to
a
certain
server
they're
also
sent
some
data,
and
it
also
tries
to
authenticate
itself
it
had
if
it
had
previously
communicated
with
the
proxy.
It's
also
extensible
with
TCP
like
options
in
TLB
format,
and
it
also
has
support
for
TFO.
So
next
slide.
Please.
Y
Alright,
so
here
you
can
see
how
Sox
6
compares
to
be
5,
so
NB
5,
the
client
first
says
what
authentication
method
supports
and
then
the
authentication
process
proceeds,
and
then
it
makes
the
request,
and
only
after
it
gets
a
reply
back.
Can
it
send
some
data
in
such
B
6?
It
sends
a
request
that
contains
your
sentation
methods
whatsoever
to
connect
to,
and
also
some
initial
data.
Afterwards
the
authentication
process
proceeds,
and
then
it
gets
operation.
Reply
back
next
slide.
Please.
Y
Y
Let
me
just
switch
to
the
next
slide,
so
the
focus
of
the
latest
revision
of
the
draft
has
been
on
security.
I
mean
achieve
Li.
We've
chiefly
concerned
ourselves
with
protection
against
replay
attacks.
Well,
first
up
Sox
version.
5
lets
you
do
encryption
within
the
protocol.
We've
decided
to
deprecated
that
and
just
run
stocks
over
TLS.
That
is
the
encryption
de
facto
standard
in
use
today,
and
we
should
request
a
new
port
for
from
my
Anna.
For
that.
Y
Y
However,
this
early
data
is
prone
to
replay
attacks
and
since
it's
likely
to
contain
a
full
Sox
request-
and
you
don't
really
need
a
report-
wait
for
a
reply
from
the
server
in
order
to
send
some
data,
so
Sox
over
TLS
is
now
prone
to
to
replay
attacks,
so
I
mean
so
we
kind
of
need
a
mechanism
that
can
ensure
item
that
can
show
idempotence
for
requests
and
in
order
to
do
that.
Yeah.
That's
like
this.
So
in
order
to
do
that,
we're
gonna
leverage
the
Sox
options,
so
this
is
for
authenticated
clients.
Y
Y
First,
the
client
sends
the
request
to
get
some
authentication
reply
back
and
then
an
operation
reply
next
slide,
so
he's
gonna
include.
It's
gonna
include
a
token
request
as
part
of
a
normal
Sox
request.
It
doesn't
really
have
to
open
a
socket
anywhere.
You
can
just
use
an
OP
and
send
the
token
request
as
part
of
the
knob.
Then
it
gets
a
window
advertisement
back
which
basically
tells
it
what
which
tokens
are
usable.
So
nice
slide.
Y
So
the
token
request
is
pretty
state
straightforward.
The
the
client
basically
asks
for
a
number
of
tokens
with
the
server
might
may
or
may
not
grant
next
slide.
Please
and
the
token
advertisement
token
window
advertisement
contains
two
fields:
a
window
based
on
the
window
size.
So
the
window
base
is
basically
the
force
token
and
the
window
size
is
the
number
of
tokens
in
the
window.
So
if
we've
got
a
base
of
10
and
a
size
of
five,
that
means
that
tokens
10
through
14
are
usable.
So
next
slide,
please
so.
Y
Afterwards,
the
client
is
free
to
spend
those
tokens
on
on
connect
own
socks
requests,
so
it
includes
talk
and
expenditure
options
as
part
of
its
requests,
and
it
gets
an
expenditure
reply
as
part
of
the
operation
reply
and
optionally.
The
server
might
may
include
an
unsolicited
window
advertisement.
So
next
slide,
please.
Y
So
the
token
expenditure
option
is
really
straightforward.
It
contains
only
one
field,
which
is
the
token
that
the
client
is
trying
to
use.
Now.
Clients
should
attempt
to
use
those
tokens
in
order
next
slide.
Please
the
token
expenditure
reply
basically
contains
response
code,
which
indicates
whether
or
not
the
token
expenditure
was
successful.
In
case
the
token
was
out
of
them
was
not
within
the
window
or
if
it
was
a
duplicate,
the
client
will
get
a
will,
get
will
get
an
error
code
and
the
Sox
operation
is
going
to
fail.
Y
This
can
usually
be
done.
If,
if
the
client
has
spent
all
of
its
lower
order,
tokens
and
the
class
and
the
proxy
basically
shifts
the
window
as
though
spent
tokens
and
generates
new
spendable
tokens
at
the
end
of
the
window,
otherwise,
if
the
client
ends
up
spending
higher-order
tokens,
but
there
are
gaps,
the
proxy
can
can
decide
to
discard
those
gaps
and
shifter
when
the
window
passed
them
anyway.
So
next
slide
please.
So
this
is
what
we
plan
to
do
in
the
next
revisions
of
the
draft.
Y
We
plan
to
include
some
options
that
let
the
client
request
certain
behavior
from
the
proxy,
like
in
case
we're
using
an
HPC
what
as
manager
and
what
scheduler
to
use
we're.
Also
thinking
about
about
adding
better
reverse
proxy
support,
so
we
would
like
so
as
it
currently
stands,
you
can
only
you
can
only
accept
one
incoming
connection
or
socks
request.
Y
Y
There
are
some
there's
some
similarity
between
his
proposal
and
mine,
so
they're
similar
in
that
there's
all
the
control
data
is
at
the
beginning
of
the
connection.
Afterwards,
data
flows
verbatim
via
the
proxy.
However,
there
are
some
important
differences
between
our
two
proposals.
So
socks5
is
purely
a
layer,
5
protocol,
so
all
control
data
flows
over
TCP
or
or
over
whatever
reliable
it
as
XI
byte
stream.
You
want
to
use,
it
can
be
run
over
TLS.
Y
D
V
Very
much
the
the
window
system
that
the
token
window
system
looks
a
little
bit
over
engineered
for
the
purpose
of
just
rejecting
duplicate,
TFO
requests.
Is
it
really
intended
for
something
else
like
like
access
utilization
limits,
because
if
it's
just
for
rejecting
duplicates,
then
it
seems
like
the
window
system
is
unnecessary.
We
could
just
have
an
incrementing
identifier
in
a
fixed
size,
space.
Well,.
Y
Y
Y
V
Okay,
that
that's
very
helpful.
Thank
you.
It
still
seems
to
me
in
that
case
that
it
should
be
sufficient
to
associate
a
nonce
with
each
essentially
in
process,
every
active
command,
a
very
open,
socket
or
something
like
that,
or
there
might
be
some
way
with
so
anyway.
I
think
we
might
be
able
to
find
another
design
for
this,
but
it's
helpful
to
understand
more
about
why
you
chose
this
design.
Thanks
yeah.
C
W
Was
the
last
1%
that
you
want
I
cheated
I
looked
on
the
website,
I'm
sorry
I
said:
I
cheated
I
looked
on
the
ITF
website,
just
very
quick,
minor
point:
I,
don't
know
what
was
in
the
draft
as
well,
but
on
the
last
line
there
you
mean
if
X
is
less
than
or
equal
to
Y.
If
you
think
about
the
case
where
x
equals
y
y
minus
x
is
0,
which
is
certainly
less
than
2
billion,
so
you
mean
less
than
or
equal.
Q
B
B
So
a
quick
introduction,
I
guess
this
is
review.
I-
have
presented
this
before
so
ila
is
an
identifier,
locator
split
protocol.
We
anticipate
use
cases
in
data
center
and
mobile
some
of
the
important
properties.
So
this
is
address
translation,
not
encapsulation,
there's
no
processing
beyond
the
IP
header,
so
we
don't
use
extension
headers,
for
instance,
for
encapsulation
there
is
a
checksum
neutral
mapping
that
will
preserve
the
layer
for
checksum,
and
this
can
run
either
on
n
host
or
in
network
next
slide.
Please.
B
Recently
we
updated
the
draft,
we
changed
the
name
to
reflect
that.
We
think
this
is
more
appropriate
for
interior
than
nvm
3.
So
previously
this
had
been
presented
in
a
10,
vo
3.
Also
some
of
the
changes
in
the
latest
draft.
We
clarified
the
intent
identifier
format
as
being
optional,
so
in
ila
we
had
actually
had
to
find
four
bits
of
the
identifier
to
be
formatting
and
that
checksum
bit
those
are
actually
optional.
We
made
that
very
clear
that
that's
an
optional
format
that
can
be
used
per
site
or
per
deployment.
B
B
We
add
a
description
of
mobility,
use
case
and
relaxed,
really
relaxing
requirement
for
the
exact
64
64
split.
So
there
are
going
to
be
used
cases
where
we
want
the
identifier
locator
to
maybe
have
different
sizes
than
64
bits
and
explain
one
of
those
use
cases
and
a
couple
slides
next
slide.
Please.
B
So
what
more
is
needed
so
Suresh?
A
couple
of
ietf
Segoe
asked
this
with
relation
to
ila
and
a
potential
working
group
item
and
we've
clarified
the
use
cases
and
provide
a
reference
architecture,
the
addressing
models
in
privacy.
Also,
we
clarified
for
the
control
plane
we're
looking
more
that
this
is
kind
of
a
database,
more
than
anything
we've
added
running
code
and
we
have
some
deployment
so
next
slide,
please
so
the
next
slide
is
some
use
cases.
So
this
is
something
we
presented
previously
in
illustrate
the
various
use
cases
next
slide
please.
B
So
this
is
a
reference
to
apology.
The
important
thing
here
is
that
we
consider
this
to
be
an
ila
domain
at
the
border
or
ila
routers.
They
will
do
translations
for
packets
coming
into
the
domain
and
those
are
translated
and
directed
to
ila
nodes
via
the
underlay
Network
and
in
Iowa
nodes.
Reverse
translation
is
done
next
slide,
please.
So
when
we
look
at
the
data
center
very
similar,
there's
Gateway
host
and
now,
instead
of
having
nodes
generic
knows,
those
are
vans
or
tasks
next
slide,
please
and
similar
in
mobile
network
topology,
very
similar
architecture.
B
B
So
we
have
three
addressing
modes
now
singleton
addresses
this
is
kind
of
where
the
point
we
started
from
this
is
the
canonical
identifier,
locator
split,
where
64
bits
is
used.
As
the
identifier
we
have
added
slash,
64
bit
assignment.
This
is,
for
instance,
used
heavily
in
the
mobile
use
case,
where
devices
are
getting
/
64
s.
I
haven't
documented
this
in
the
draft.
B
B
So
the
control
plane,
as
I
mentioned,
we're
really
looking
at
this
as
a
key
value
store
and
as
such,
it's
a
database
and
security
act
calls
replication
pub/sub
many
of
the
things
in
a
database
become
important
and
there's
some
very
various
examples
of
how
this
might
be
implemented.
X-Lite,
please
so
running
code.
We
continue
to
support
the
code
in
Linux.
There
were
some
patches
recently
that
fixed
a
couple
of
things.
We
have
an
aisle,
a
router
implementation
in
xgp
and
we
did
one
in
DPD
k3
high
80s
ago
the
hackathon.
B
We
will
be
open
sourcing
reference
control
daemon
soon
that,
as
I
mentioned,
implemented,
database
sort
of
control
plane
for
real
deployment.
Peter
can
probably
fill
you
in
more
on
this,
but
Facebook
is
using
ila
as
virtual
replay
virtual
addresses
to
replace
VIP
injection
and
for
mobility.
We
are
currently
working
on
a
proof-of-concept,
basically
has
an
alternative
to
GTP
user
plane
and
mobile
networks
next
slide.
B
P
Thanks
thanks
Tom,
so
today's
share,
so
one
of
the
questions
he
asks
is:
is
one
off
or
not?
I
still
don't
have
an
answer
for
that
right,
like
is
this
a
one-off
document,
or
is
there
gonna
be
like
a
bunch
of
documents
to
follow,
so
the
answer
to
this
question
would
be
different
based
on
answer.
You
give
me
right,
and
so
that
is
the
first
thing.
I
I
kind
of
asked
for
right.
P
B
See
so
my
my
feel
right
now
is
I
prefer
to
be
one
document
if
possible,
I
think
it's
simple
enough
and
since
there's
no
actual
change
on
the
wire
protocol,
I
think
that's
a
benefit.
The
control
plane
is
obviously
the
obviously
the
interesting
question
whether
or
not
we
actually
need
a
formal
aisle,
a
specific
control
plane
or
if
it's
sufficient
to
say
that
say,
for
instance,
we
do,
we
do
have
the
database
control
plane
or
use
Sdn
or
open
or
some
something
like
that.
P
Right
like,
and
that
requires
scoping
right
so
like
one
of
the
things
we
talked
about
probably
couple
of
meetings
ago
in
office
hours,
was
that
if
you
want
to
run
this
at
internet
scale,
you
need
different
things
right.
Then,
if
you
do
it
in
a
controlled
omein
so
like.
If
you
scope
the
document
properly
I
guess
you
can
probably
get
away
from
like
doing
anything
larger
than
like.
Just
today
the
base
we
talked
about,
or
they
are
using
a
same
controller
but
there's
no
Sdn
controller,
that
works
and,
like
you
know,
different
administrative
domains.
B
And
and
I
think
you
know
going
back
to
the
reference
to
architecture.
Those
really
are
scope
to
be
within
a
single
domain.
It
is
possible
to
use
this
inter
domain,
but
I
think
the
initial
deployments.
The
initial
design
is
really
going
to
be
around
bringing
this
and
bringing
this
up
in
a
network
more
or
less,
as
a
replacement
for
encapsulation
or
segment
routing
or
equivalent
to
segment
routing.
Or
what
have
you
so
really
would
be
constrained
within
a
good
main
for
the
most
part?
Ok,.
Z
B
It
would
be,
it
would
be.
You
have
to
be
shorted,
so
the
database,
like
any
other
large
database.
We
can't
fit
the
whole
thing
into
one
device,
so
you'd
want
to
short
it
and
the
shorting
would
be
based
on
the
what
we
call
this
her
address.
So
the
server
address
would
hit
different
routers
that
contain
a
different
part
of
the
shard
or
different
shard
of
the
data
before
database.
Z
Okay,
maybe
a
last
point
like
I,
think
it's
not
a
standalone.
You
know
I
think
so
Suresh
as
question.
It
appears,
like
a
you,
know,
number
of
extensions.
It's
not
a
just
a
point.
You
know
one
simple
specification
right:
you
need
a
mechanism
for
populating
the
does
mapping
entries.
You
need
a
lot
more
infrastructure
for
this
entire
thing
to
work
at
a
high
level.
I
eat
appears
like
a
nitrate
solution.
It's
fine
I
I
can
understand
that.
But
you
need
lot
more
for
the
entire
system
to
work.
You
need
the
many
other
things
in
place.
Z
B
J
Things,
firstly,
it
does
really
sound
a
bit
of
hand
wavy
to
say:
well,
you
know
we're
gonna
shard
it
and
you
can
chart
it.
You
can
share
the
database,
but
if
the
nodes
that
are
doing
inline
forwarding
have
to
afford
at
line
speed-
and
you
want
to
have
a
fishing
port
or
utilization
on
network,
you
can't
just
shard
the
database
arbitrarily
because
you'll
end
up
with
a
lot
of
capacity,
loss,
I,
think,
and
so
basically
that
goes
back
to
suresh's
point
is
this:
it
seems
kind
of
hand
wavy.
J
So
you
would
want
to.
You
know,
have
a
clearer
deployments
Ament.
I
think
the
other
thing,
the
other
question
is
and
I
really
have
to
ask
you
this
question,
because
it
you
said
does
not
run
down
on
draft.
How
do
you
do
mobility
with
64
is
when
you
have
a
hundred
million
64?
It's
like
how
do
you
even
do
that?
It
seems
to
me
that
there's
not
enough
bits
in
the
IP
address,
so
the.
J
B
This
also
was
mentioned
in
il
NP.
Basically,
what
you
do
is
you
encode
into
the
locator
and
index
also,
and
the
index
refers
to
a
locator
specific
table
that
resolves
to
the
prefix.
So
it's
the
locator
plus
some
index,
which
is
in
the
upper
64
bits
that
actually
indicates
the
prefix,
but
that
has
to
go
to
the
locator,
because
the
table
specific
so
I
figured.
B
J
B
W
A
O
O
You
know
this
topic
kind
of
came
up
about
five
years
ago
in
a
sock
with
the
workshop,
essentially
we're
now
at
a
point
where
we
want
to
look
at
some
of
the
emerging
5g
use
cases
and
applications
and
requirements
that
are
coming
out
of
various
European
projects
and
start
investigating
what
tools,
architecture,
capabilities,
the
ITF
and
other
organizations
have
for
solving
quite
a
broad
range
of
critical
requirements.
Now,
clearly,
the
use
cases
are
many.
O
This
particular
document
takes
a
number
of
these
low
latency
use
cases
essentially
three
and
tries
to
expand
specifically
on
bandwidth,
endpoints
QoS
determinism
capabilities
and
look
at
sort
of
considerations
for
how
these
might
be
deployed
and
operated
across
public
Internet.
So,
of
course,
you
could
mitigate
sort
of
latency
issues
with
dedicated
links
and
maybe
sort
of
lower
layer,
traffic
engineering
technologies.
But
you
know,
as
mentioned
in
the
title
we
want
to
see
if
these
are
actually
sort
of
feasible
across
public
internet.
O
So
if
you
could
look
at
the
draft,
you
know
with
something
like
input
from
the
working
group.
Of
course,
this
topic
is
is
much
broader.
It
spans
multiple
working
groups,
multiple
protocol
mechanisms,
interfaces,
maybe
there's
some
kind
of
template
definition,
that's
required
for
application
to
network
interaction.
There
may
be
extensions
required
to
existing
QoS
mechanisms,
so
our
our
plan
is
at
some
point
next
year
to
have
a
workshop
either
through
sort
of
the
IETF
iltf
or
external
are
co-located
with
one
of
the
academic
events.
O
So
you
know
that
there's
the
guaranteed
delivery,
our
packets
for
application,
specific
environments,
remote
surgeries,
kind
of
an
interesting
example
where
actually
latency
is
actually
critical
or
important,
but
actually
delivery
of
every
packet
is
more
important.
So
it
really
depends
on
on
the
specific
use
case.
O
Yeah,
exactly
and
so
there's
kind
of
a
macro
aspect
of
the
Internet
service,
and
there
are
mechanisms
that
we
can
use
to
measure
latency.
But
it's
just
as
important
to
look
at
the
micro
aspects
of
latency,
whether
it's
link
segment
interface,
maybe
even
switch
fabric,
and
and
it's
not
just
about
setting
up
and
reserving
this
sort
of
relation
C
or
latency
bounds.
But
it's
also
measuring
and
what
tools
do
we
have
available
there?
That's
those
are
open
issues
as
well.