►
From YouTube: IETF106-INTAREA-20191121-1550
Description
INTAREA meeting session at IETF106
2019/11/21 1550
https://datatracker.ietf.org/meeting/106/proceedings/
A
Hello,
everyone
so
I
guess
we
can
get
started.
This
is
a
interior
working
group
like
if
106
and
not
well
as
usual.
As
you
know,
we
have
to
comply
this
an
official
I
Triple
E
meeting.
So
if
you're
not
familiar,
please
take
a
look
at
it.
We
have
few
references
there,
but
it's
pretty
much
about
this
closing
any
knowledge
of
intellectual
property
that
you
could
have.
A
About
that,
okay
I'm
just
going
to
speak
closer
to
the
mic,
so
not
well.
If
you're
aware
of
any
patent
related
to
any
of
the
topics
we
are
going
to
discuss
here,
please
mention
it
and
if
you
have
doubts
about
the
node
well,
you
have
references
here
as
a
reminder.
The
minutes
are
taking
blue
sheets
are
going
around.
The
meeting
is
being
recorded.
Your
presence
is
locked
and
described.
Please
contribute
online
minutes
to
etherpad.
Do
we
have
someone
that
can
help
us
take
the
minutes
on
the
etherpad?
A
A
So
agenda,
as
I
said
as
a
pretty
light
this
time,
the
usual
bashing
of
the
agenda,
we're
going
to
have
a
presentation
from
Tommy
about
this
covering
provision,
the
main
names
they
turn
and
updates.
On
that
the
SoCs
protocol
Vlad
will
be
presenting
remotely
problem
I
interfaces
by
vendor
specific
identifiers
Manoj.
We
are
skipping
that
one
in
fact,
and
it's
our
v6
network
programming
Pablo
is
going
to
present.
A
Does
anybody
have
any
questions
or
comments
on
the
agenda?
Okay,
good?
So
this
status
update
the
discovering
provisioning
domains,
names
and
data
it's
in
iesg
evaluation,
but
in
fact
we're
going
to
have
a
presentation
in
this
meeting
to
discuss
the
topic
in
detail,
so
you
can
ask
Tommy
directly
for
in
updates
for
the
IP
fragmentation
considered
fragile.
It's
an
RFC,
editor
q,
apparently
those
two
sir
reference
you
should,
but
that
should
be
good
to
go
soon
and
the
generic
EVP
encapsulation
it's
in
iesg
about
evaluation
right
now.
B
B
All
right,
so
last
call
was
concluded.
Our
Shepherd
Eric
line
did
a
lot
of
good
review
catching
some
nits
in
there.
So
we
really
appreciate
that.
Thank
you
to
him
for
that.
We've
done
several
refinements
during
that
process,
so
we're
now
on
version
o
8,
so
we
jumped
a
couple
as
we
fixed,
typos
and
stuff,
so
I
think
it's
in
pretty
good
shape.
At
this
point,
first
I
want
to
highlight
a
couple
of
the
minor
changes
that
we
did.
B
First,
we
clarified
that
the
multihoming
that
we
are
offering
with
having
multiple
provisioning
domains
is
only
available
to
the
PVD
where
clients
this
should
have
essentially
no
impact
on
legacy
clients,
and
they
will
not
be
aware
of
this
multihoming
setup.
We
also
clarified
that
the
RA
messages
are
intended
to
go
separately
to
PVD,
aware
hosts
and
non
PVD
aware
hosts
when
that's
the
case,
they
should
be
using
different
llas
so
that
these
are
easily
separable.
B
B
That
was
one
of
I
think
the
more
open
questions
that
we
were
still
trying
to
work
over
when
we
presented
this
in
Montreal,
we
had
three
different
options
for
how
we're
gonna
try
to
align
the
dhcpv6
information
with
the
PVD
information
during
the
process
of
getting
the
review.
We
kind
of
landed
on
something
that's
slightly
different
from
what
we
presented
there.
So
I
did
want
to
explain
it
to
everyone
here.
Make
sure
that
we
all
believe
is
the
right
thing,
since
this
is
kind
of
you
know
during
last
call
post
last
call.
B
The
dhcpv6
elements
are
associated
with
the
implicit
PVD
on
that
interface,
so
we
think
this
is
kind
of
the
most
sane
way
of
arranging
everything
again.
This
is
not
something
that
we
imagine
is
going
to
be
a
huge
use
case
of
transmitting
this
information.
It's
more
to
ensure
that
if
this
information
is
received
by
the
network,
that
the
clients
have
something
sensible
to
do
with
how
they
interpret
and
associate
the
data.
So
if
you
have
any
comments
or
concerns
on
that,
please
do
let
us
know
that's
about
it.
B
C
Easement
so
yes,
I
finished,
my
ID
eval
I
was
telling
Eric
I
just
didn't,
have
a
chance
to
write
it
up
like
it's,
how
I
finished
it
last
week,
oh
there's
like
another
draft
ahead
of
this
in
the
queue
which
I
haven't
written
up,
so
I
wanted
to
get
it
out
before
the
meeting
so
I
say
like
hey,
you
guys
are
like
taking
a
long
time,
but
I
didn't
so
I'll
try
to
get
it
out
as
soon
as
possible.
Okay,.
B
B
Right
and
then
just
the
other
aspect
of
this
is
now
that
this
has
been
a
fairly
mature
document.
We
have
done
previous
hackathon
work
with
this.
We've
done
interrupts
testing
previously,
but
of
course
you
know,
a
couple
of
the
details
have
changed
since
then.
So
anyone
who
is
interested
in
working
on
this
personally
I'm
working
on
this
for
our
Apple
client
side,
but
anyone
who
has
a
deployment
that's
interested
in
adding
this
support
in
and
doing
work
at
a
hackathon
in
the
upcoming
times.
B
A
E
E
This
new
aircraft
is
rather
light,
so
we've
got,
we've
got
a
mechanism
whereby
the
proxy
can
provide
the
DNS
service
to
its
clients
and
we've
also
added
some
an
option
that
can
that
makes
the
proxy
do
happy.
Eyeballs
on
the
client's
behalf.
So
I
said
please,
so
it
was
kind
of
obvious
that
tions
needed
dns
life
features
non
Sox
aware
apps
had
to
do
KN,
quad-a
queries
somehow
and
in
the
case
of
happy
eyeballs.
Those
queries
had
to
be
done
separately
now
during
the
last
ITF.
E
Someone's
benchmarks
just
said
that
Sox
clients
should
also
be
able
to
do
yes
and
I,
and
currently
you
need
to
do
txt
queries
for
that
and
of
course,
there
are
some
other
DNS
use
cases
that
are
cropping
up.
For
example,
service
binding
is
on
the
horizon.
Who
knows
if
it
will
get
centralized
and
come
to
think
of
it?
Who
knows
what
else
we'll
get
standardized
and
what
other
future
use
cases
there
will
be
for
DNS?
E
So
next
slide
up
until
draft
of
seven,
we
used
to
have
individual
options
for
DNS
like
functionality,
so
you
could
do
a
and
quality
queries
and
also
PTR
queries
the
what
was
dangerous
about
this
is
that
we
were
basically
duplicating
the
NS
functionality
and
as
new
use
cases,
and
if
news
kept
these
cases
keep
cropping
up,
then
we're
going
to
have
to
keep
up
with
them
and
yeah
basically
follow
whatever
the
DNS
folks
are
doing
now.
Obviously,
the
alternative
is
to
have
the
client
used.
The
act
actually
use
DNS.
E
However,
of
course
it
can
do
a
DNS
of
Sox,
but
it's
hard
for
the
proxy
to
convey
it
policies.
What
IP
is
it?
What
resolver
ip's
it
has
to
use
whether
to
do
plaintext,
DNS
or
DNS
over
TLS
or
DNS,
over
HTTP
DNS
over
TLS
or
a
over
HTTP
might
be
associated
with
some
credentials
and
first,
you
might
have
to
give
those
credentials
to
the
client
and
in
case
of
DNS
over
TLS,
those
credentials
are
actually
private
keys.
E
F
E
D
F
E
E
E
E
E
E
B
E
E
There
might
be
some
some
cases
in
which
the
in
which
it's
appropriate
for
the
proxy
to
perform
the
happy
eyeballs
mechanism
rather
than
our
client.
So
let's
say
we
have
higher
RTT
between
the
client
and
the
proxies
the
proxy
or
the
client,
and
the
proxies
vantage
point
so
happy
eyeballs
is
gonna.
Work
like
this.
First,
the
client
Rizal
sends
out
two
DNS
requests
and
one
for
a
and
one
for
qua
date,
and
it
gets
back
the
response
one
RTT
later
and
then
it
issues
to
connect
requests
one
for
ipv4
and
one
for
ipv6.
E
Now,
obviously,
we're
kind
of
wasting
on
ITT
here
so
Sox
also
allows
you
to
use
domain
names
in
the
request.
So
if
the
proxy
can
do
happy,
I
have
also
done.
The
client
needs
only
issue
a
connect
request
and
then,
and
then
the
another
proxy
sends
out,
tries
to
establish
multiple
connections
in
parallel,
and
whichever
of
those
succeeds
ends
up,
it
ends
up
hooking.
The
client
with
this
is
obviously
faster.
We
shave
roughly
one
client
to
proxy
RTT,
so
next
slide.
E
E
The
the
option-
semantics
are
the
usual
semantics
used
by
source
options.
So
if
the,
if
the
proxy
has
no
idea
what
to
do
with
the
option,
I
mean
it,
it
doesn't
implement
happy
apples,
it
simply
ignores
the
option
and
doesn't
echo
it
back.
Otherwise,
the
client
knows
that
the
server
the
proxy
attempted
happy
eyeballs
now,
of
course,
there's
a
caveat
to
using
happy
eyeballs
nearly
willing.
So
if
we
use
happy
eyeballs
and
TFO
we're
going
to
have
a
lot
more
replays
than
expected,
so
TFO
TFO
does
stipulate
that
replays
can
occur.
E
G
There
are
questions
Ben,
Schwartz,
so
first
of
all,
I
just
want
to
say
thanks
for
thanks
for
doing
all
the
work
here.
This
this
draft
has
improved
in
every
iteration
I.
Think
it's
I
think
it's
really
getting
very
good.
Thank
you.
The
I
do
I,
do
have
wonder
about
the
the
happy
eyeballs
behavior
here,
I'm
confused,
because
in
socks5
it
seems
like
a
proxy
could
already
do
this.
So
do
you
think
that
a
proxy
do
you
believe
that
in
Sox
5
the
proxy
actually
already
could
be
doing
happy?
Eyeballs,
I.
E
G
G
G
B
Tommy
Pauline
Apple,
so
yes
again,
echoing
Ben,
thank
you
for
doing
updates
on
this,
and
this
is
good
discussion.
I.
Think
going
back
to
those
diagrams,
you
had
talking
about
the
different
approaches
for
how
you
use
happy
eyeballs,
essentially,
is
it
on
the
client
or
it's
on
the
proxy
totally
agree
that
most
of
the
time,
it
makes
sense
for
this
all
to
be
on
the
proxy
and
that's
how
we
see
it
used
generally.
B
Today,
I
mean
there
are
going
to
be
some
cases
in
which
the
client
does
it,
but
those
are
going
to
be
fairly
rare.
I
agree
with
Ben
that
the
explicit
signal
here
is
likely
not
needed.
I.
Think
discussion
in
the
text
referring
to
happy
eyeballs
is
important,
saying
that
the
proxy
should
use
this
mechanism
when
it
is
not
a
TFO
connection.
I
think
would
be
valuable
because
that,
actually,
you
know
allows
it
gives
more
incentive
for
the
clients
to
not
try
to
second-guess
it
on
their
own.
B
B
B
E
I
mean
if
the
client
is
providing
a
domain
name
as
part
of
the
request,
then,
and
let's
say
that
the
proxy
is
biased
towards
using
ipv6.
The
proxy
sends
out
a
TFO
scene
and
let's
say
that
the
return
path
doesn't
work,
and
so
then
the
client,
the
client,
is
left
with
a
with
a
connection
that
isn't
working.
The
proxy
says:
hey
that
stuff
didn't
work.
F
B
G
So,
to
tell
me
that
filling
all
the
way
back
to
the
client
is
is
difficult
here,
because
if
the
client
just
reissues
the
same
connect
to
the
same
domain
name,
it
will
been
a
ton
less.
The
proxy
is
actually
stateful
remembers.
This
you
know,
remembers
to
blacklist
this
unless
the
proxy
remembers
to
blacklist
v6.
For
that
for
that
host,
the
proxy
will
just
do
the
same
thing
again.
If
the
proxy
is
stateless,
that
the
client
and
the
client
reissues
the
same
request.
B
H
Jonathan
X
I
was
gonna,
say,
sort
of
somewhat
fortuitous
delivery.
After
producing
there's
a
lot
of
state
related
to
happy,
eyeballs
and
I
think
we
need
to
at
least
analyze
whether
there
are
privacy
implications
for
this.
We
want
to
make
sure
that
I
think
we
want
to
make
sure
that
this
state
isn't
shared
across
various
users
of
the
proxy.
But,
as
you
know,
each
user
of
the
proxy
has
their
own
state
or
you
could
find
out
what
other
people
using
the
socks
proxy
are
connecting
to,
which
would
be
bad
all.
E
E
C
Yeah
thanks
suresh
krisshnan,
so
just
to
put
Gauri
on
the
spot
again
and
I
kind
of
keep
harping
on
this,
but
that
does
TS.
Vwg
needs
something
specific
from
this
one,
because
I
always
like
feel
uncomfortable
just
doing
this
year.
So
should
we
keep
sending
you
know
it's
every
meeting
or
how
do
you
want
to
do
this.
I
Hi
Cory
Ferris
do
I
want
more
work,
wow.
What
a
question
and
I
think
we
probably
would
appreciate
a
presentation
in
TS
pwg
in
our
wonderfully
packed
agenda.
We
can
make
some
space
if
it
tells
us
about
the
transport
related
topics.
I
think
that
would
actually
be
a
really
good
thing.
This
is
maturing,
so
it
would
be
good
just
to
get
a
presentation
start
and
do
that.
J
Graf
nom:
this
is
public,
americium
and
I'm,
going
to
present
on
the
ethernet,
an
acceleration
that
we
are
pursuing
in
draft
idea
of
a
spring
as
our
v6
and
we're
programming.
So
the
use
case
is
pretty
simple.
In
hobby
six
we
have
a
customer
that
is
sending
a
packet
you
get.
It
arrives
to
the
service
provider
network
and
ingress.
P
is
that's
going
to
encapsulate
this
packet
into
an
ipv6
header
with
an
extensional
header
that
is
going
to
be
the
segment
routing
header
slope.
You
know
this
packet
from
the
customer.
J
C
Suresh
krisshnan,
so
the
reason
I
wanted,
like
the
services
folks
to
compress
in
tears,
there's
like
a
protocol
number
allocation
requests
coming
in
as
an
early
allocation,
so
I
just
wanted
the
internet
area
to
be
aware
of
it.
It's
not
that
we
are
under
severe
scarcity
in
the
protocol
number
space
and
I
really
want
them
to
not
use
59
known
exceda.
To
do
this
so
I'm
inclined
to
grant
it
so
that
that's
kind
of
why
I
just
wanted
everybody
to
be
aware
that
this
is
gonna
happen.
K
J
First,
we
are,
we
do
not
have
the
their
IP
header
in
between
the
segment
writing
Heather
and
a
u.s.
Ethernet
frame,
and
second,
we
are
not
following
the
procedures
from
a
draft
in
essence,
based
on
segment
routing.
We
are
going
to
do
when
we
are
going
to
be
capsulated
either
on
a
frame.
We
are
going
to
do
some
processing
on
different
kind
of
flu
cups
based
on
segment
routing,
so
we
are
not
following
a
dealer
and
is
our
IP
processing.
D
D
We
encapsulate
incoming
frame
into
labels,
start
directly,
there's
no
shame
layer
for
ether
I
over
IP
I
think
we
want
you
to
keep
the
similar
for
a
service-based,
l2
VPN,
where
we
have
an
ipv6
header
and
SH
address,
table
set
and
I'll
to
frame
directly.
We
don't
don't
want
to
have
any
other
shim
layer
in
between
which
is
a
Ethernet,
IP
I
think
you
are
suggesting,
plus
plus
we
we
have
to
be
fully
compliant.
If
we
were
to
do
that,
a
different
Ethernet,
IP
spec.