►
From YouTube: IETF96-INTAREA-20160721-1830
Description
INTAREA meeting session at IETF96
2016/07/21 1830
A
B
D
D
H
D
D
D
D
D
With
the
documents
that
we
have
progressing,
let's
start
with
with
the
tunnels,
we
have
a
received
some
some
slides
from
Joe
that
have
been
uploaded,
unfortunately,
another
job
nor
mark
r
%,
so
they
are
requesting
to
have
the
discussion
on
the
list
as
compared
to
to
having
the
discussion
here
and
just
for
as
a
reminder,
the
document
status
is
currently
informational
and
the
question
is:
should
this
still
be
in
an
informational
document
or
become
a
vc
key?
For
that
we
have
to
take
into
account
the
impact
on
other
rfcs
and
there's
some.
D
D
There
any
question
for
clarification
on
this:
okay,
here,
no
next,
so
more
documents
that
we're
progressing
will
have
the
interior
ossining
practice,
which
was
adopted
in
Prague,
and
the
chairs
will
request
a
location
after
this
meeting.
So
that
is
on
the
go.
We
have
the
interior
ad
hoc
wireless,
for
which
Charlie
hopefully
will
present
an
update.
D
Then
we
have
a
couple
of
calls
for
adoption
on
the
interior
IP
in
UDP
that
generated
quite
a
long
thread
of
discussion
on
the
mailing
list,
but
we
couldn't
see
any
working
group
support
for
adoption.
We
also
looked
at
the
draft
I
EDF
envio
three
GUI
and
which
got
adopted
by
the
working
group
and
Tom
will
soon
%
an
update
to
this
purchase.
D
Other
documents
there
is
a
multicast
over
I
trip
leader
to
wireless
from
Charlie
and
a
towel,
so
the
authors
are
going
to
work
on
a
new
draft
because
there's
an
itrip
leader
to
meeting
next
week
in
San
Diego,
so
we'll
be
working
on
that
and
hopefully
I
knew
on.
Your
revision
will
come
out
and
then
we
have
a
couple
of
announcements.
There's
an
IEP
announcement
in
Carter's
will
do
another
announcement.
Next,
okay,
so
agenda
bashing.
Are
there
any
questions
or
suggestions
from
tejinder?
If
not,
will
we
let
the
Brian
do
his
presentation.
I
While
we're
waiting
for
this
to
come
up,
hi
I'm
Brian,
Trammell
I'm,
the
among
other
things-
I
am
the
IAB
lead
for
the
IV
stack
evolution
program
and
the
reason
I'm
here
is
came
up
in
the
so
there's
a
kickoff
meeting
beginning
of
the
week,
I
bniester
you
got
together
and
it's
like
okay.
Well,
you
know
we
have
these
programs
and
a
lot
of
people
in
the
affected
areas
may
or
may
not
know
what
they
do
so
well.
F
I
I
It's
hard
to
evolve
the
stock,
but
the
stack
of
bolts
anyway,
is
there
any
way
that
the
IEP
can
help
and
are
there
gaps
in
work
in
the
IETF,
where
there
could
be
sort
of
engineering
fixes
to
some
of
these
problems,
so
in
this
date
say
that
the
stack
is
hard
to
evolve,
mean
there's
these
many
layers,
and
you
know
some
people
in
this
room
may
have
heard
of
the
ipv4
to
ipv6
transition.
I'm.
Assuming
everyone
here
is:
okay,
there's,
probably
some
slides.
I
You
can
find
on
that
if
you
haven't-
and
so
some
of
this
was
driven
forward-
and
some
of
this
is
actually
sort
of
like
you
know-
various
actors
who
have
part
responsibility
for
different
parts
of
the
stack
sort
of
moving
in
different
directions.
We
originally
thought
so
this
is
what
the
IEDs
stock
evolution
program
looks
like
is:
can
we
help
since
the
program
was
sort
of
rebooted
in
2014?
We've
done
two
workshops:
two
and
a
half
workshops.
I
Semi
marni,
oh
and
I,
ought
see
so
we're
kind
of
looking,
I
OT
things
and
how
I
OT
things
have
to
do
with
various
layers
of
the
stack,
because
there's
no
program
to
look
at
the
whole
iot
thing
and
then
three
boss,
spud
Accord
Plus
this
morning.
That
was
a
great
deal
of
fun
and
then
there
was
a
barbell
fun
measurement
that
led
to
the
measurement
analysis
for
protocols,
research
group,
which
was
a
proposed
research
group.
But
since
I
made
these
slides,
it's
now
a
real
actual
full-blown
research
group.
I
So
there's
not
a
whole
lot
that
we've
we've
done
that
really
touches
on
int
area.
So
far
there
may
be
as
we
look
at
how
sort
of
things
in
transport
interact
with
things
down
at
layer
2,
because
there's
this
layer
3
and
that
obviously
has
some
interactions.
There
watch
this
space
there's
three
ways
to
participate.
Basically,
we
have
an
open
list:
stock
Evo,
discuss
at
IEP
org.
That's
actually
been
relatively
quiet
recently
because
most
the
people
who
are
paying
attention
to
that
have
been
paying
attention
to
the
boss.
I
So
there's
the
Accord
off
last
time
the
plus
bought
this
time
when
there
are
both
show
up
at
them
and
then
the
IAB
will
announce
on
the
IETF
list.
If
there
are
announcements
for
workshops
and
workshops
announced,
usually
that's
invitation
only
send
a
position
paper.
We
have
sort
of
smaller
room
conversations,
anything
that
we
think
is
a
big
room
conversation.
I
We
try
to
get
the
iesg
to
approve
a
zip-off
so
with
that,
if
you
have
any
questions,
feel
free
to
ask
me
dad
or
by
email
or
send
a
message
just
a
key,
but
it's
gotta
be
at
work.
Thank
you
very
much.
D
J
J
Well,
while
we
hit
get
the
slides,
basically
the
what
has
been
doing
the
internet
directory
so
far,
do
you
mean
you
may
be
aware
of
the
internet?
Are
a
directory
you,
maybe
even
a
member
of
that
and
with
what
we
have
been
doing
so
far
has
been
revealed
documents
upon
request
from
the
80s,
so
that's,
basically
what
the
internet
or
a
directory
has
been
doing
and
the
slide.
J
So
that's
it
for
so
that's
basically,
a
future
thanks
to
the
people
that
is
in
the
directory
has
been
doing
review
so
far.
So
next
one
is
about
what
we
want
to
order.
It
is
want
to
do
on
with
the
directory
in
the
in
the
future.
So
this
basically
summary
what
we
are
going
to.
We
are
going
to
review
all
Internet
area
documents
prior
to
the
ITF
last
call,
so
that's
going
to
be
mandatory
for
all
the
documents
and
the
outcome
of
that
will
be
a
recommendation
from
the
reviewers.
J
We
will
have
at
least
two
reviewers
from
the
directory
whether
the
document
is
ready
for
going
to
let
go
or
not.
So
that's
the
first
thing
that
the
directory
will
be
doing
you.
The
second
thing
that
we
will
be
doing
is
to
review
all
documents
that
are
on
IP
of
Lascaux,
unidentified
those
that
tackles
and
our
impact
or
hassle
relationship
with
the
internet
area,
and
if
that
is
the
case,
to
also
provide
a
review
and
to
provide
a
review
today,
this
basically
suggesting
the
PAL
opposition.
J
So
should
this
go
forward
to
this
discuss
and
also,
of
course,
provide
feedback
to
the
document
sheffer
and
the
outfits.
That
also
applies
to
the
first
case
to
the
internet
area
documents.
I
will
remove
other
things
that
reviewing
documents
upon
request
to
the
from
the
avisas.
We
were
doing
and
helping
other
other
things,
but
they
made
the
topic
starter
review
of
the
internet'll
recommends,
and
we
you
of
all
documents
in
ATF
last
call
that
may
have
an
impact
on
internet
area
next,
one
please.
J
So,
how
is
the
directorate
form
so
well
is.
Basically,
the
members
are
nominated
by
the
selected
by
davis,
so
you
are
interested
in
forming
being
part
of
the
directory
pleased
to
talk
to
the
two
day
this,
and
that
will
be
very,
very
helpful
and
now
one
very
new
thing,
maybe
that's
something
that
will
be
new
form
for
all
the
chairs
of
the
internet
area-
is
that
all
the
internet
area
working
with
chairs
will
be
part
of
the
directory.
So
that's
something
that
intuition
don't
blame
me.
J
So
that's
important,
because
we
have
a
more
a
lot
more
presence
there
and
also
away
the
more
background-
and
I
know
you
wanna
comment
on
this.
Oh
okay,
well,
two
of
the
members
of
the
directory
itÃs
coordinator
for
the
time
being
is
Bernie
balls
and
myself
and
then
just
quick
thing
on
the
memory
responsibilities.
You
are
part
of
the
directory.
You
have
to
respond
upon
request.
Very
fast,
so
I
can
do
the
review.
J
I
cannot
do
the
review
right
now
and
then
provide
the
review
within
two
weeks
by
default
or
between
the
by
the
deadline
that
is
set
on
on
the
request
and
last
light.
All
this
information
together
with
mods,
more
detailed
things,
will
be
up
in
the
Internet
era
directory
web
page.
That
is
been
updated.
So
the
information
that
is
there
right
now
is
that
yet
updated,
but
it
will
be
done
in
the
next
few
days.
K
K
One
thing
we
want
to
figure
out
is
like
we
want
to
have
a
team
of
talented
who
are
like
able
to
go
through
documents
from
other
areas,
trying
to
find
touch
points
and
everything
that
makes
our
life
easier
when
we
had
to
replace
ourselves.
Okay,
so
that's
one
thing,
that's
kind
of
not
stated
here,
but
it's
something
you're,
not
thinking
second
thing
is:
we
want
to
do
systematically
review
all
the
documents
and
that
cannot
be
done
without
a
larger
cool.
K
So
there's
like
a
nice
set
of
people
that
are
in
there,
but
it's
not
sufficient
with
a
number
of
documents
going
to
idea
plus
call.
So
it's
kind
of
we
are
opting
in
all
the
internet
area
motion
group
chairs,
whether
you're
free
to
opt
out.
If
you
don't
want
to
do
it
like
we
won't
like
it.
But
if,
if
you
want
opt
out
or
not,
do
the
reviews
like
I
just
come
and
talk
to
the
ladies
or
the
D,
the
coordinators,
and
we
cannot
be
out
on.
K
It
this
won't
be
like
a
round-robin
list,
that's
how
the
other
directorates
work.
So
this,
like
an
all
the
list
of
reviews
in
there.
So
when
I
Rahman
comes
out
the
first
person
Angeles
does
it
and
it's
probably
like
going
to
be
1
review
a
month
out,
guess
like
if
we
get
the
right
set
of
people
took
it
thanks.
L
D
L
I'll
be
representing
a
loose
young
and
some
Isaiah,
the
co-authors,
just
a
brief
background
on
go.
It
is
a
type
of
encapsulation
within
UDP.
We
are
explicitly
designing
it
to
be
generic
and
extensible,
and
we
have
virtualization
and
non
virtualization
use
cases.
Originally
this
was
in
NV
03.
We
decided
to
move
it
to
int
area
because
very
general
protocol,
so
it
seems
more
appropriate
they're
mixed.
L
L
It
was
kind
of
limiting
extensibility,
so
GU
was
defined
based
on
that
principle
to
go
beyond
GRE
and
allow
extensibility,
but
with
the
same
model
quick
overview
of
the
features
so,
as
I
mentioned,
goos
very
much
like
GRE
with
flag
fields,
we
added
a
header
length,
so
this
does
allow
for
variable
length,
headers
and
also
allows
middleboxes
to
parse
over
headers.
They
don't
understand.
We
have
an
IP
protocol
number.
So
one
significant
difference
with
between
GRE
&
goo
goo
carries
an
IP
protocol
number
sets
the
8-bit
normal
protocol
number.
L
We
use
UDP
encapsulation
similar
to
how
will
join
GRE
over
UDP
to
facilitate
CCMP.
We
a
concept
of
control,
messages
versus
data
messages.
One
important
extension
is
security.
We
have
an
optional
security
field
that
allows
authentication
of
the
header
itself
and
similarly,
we
have
checked
some
fragmentation,
several
basic
extensions
that
all
cover.
In
a
moment
we
targeted
hardware
friendliness
and,
as
I
mentioned,
it
does
support
network
virtualization.
Also,
the
back
fact
that
we
used
IP
protocol
number
is
not
an
aberration.
L
So
this
is
the
current
format
of
goo
version
0.
It's
actually
simplified,
since
the
last
version
that
we
had
done
taking
feedback
from
Adrienne
Farrell.
So
it's
a
UDP
header,
followed
by
four
byte
goo
header,
followed
by
fields
and
a
private
data
section,
so
the
flags
indicate
which
fields
are
present
just
like
GRE.
The
private
data
is
actually
a
section
that
is
somewhat
undefined
in
the
sense
that
it
can
be
used
for
private
data,
so
an
implementation
or
site
could
put
in
their
own
information.
L
They
could
put
in
tlv
s
or
flag
information
or
other,
like
just
good
version.
One
is
actually
what
I
would
consider
kind
of
a
special
case,
and
this
really
came
up
with
the
IP
and
UDP
discussions,
and
we
realize
that,
because
of
the
format
that
we
had
in
gu,
we
could
actually
directly
encode
an
IP
packet
within
the
GU
header
and
call
it
version
1,
and
this
has
the
exact
same
semantics
as
ipv4
and
ipv6
over
UDP.
L
So
the
changes
in
version
4,
which
was
the
most
recent
change
and
they
pointed
out-
we
simplified
it.
So
we
move
the
concept
of
an
extension
fields
bit
magic
number.
The
inner
flow
and
identifier
is
renamed
flow.
Entropy,
that's,
basically
the
UDP
source
port
used
for
ecmp
purposes.
We
did
describe
the
set
of
IP
protocol
numbers
that
are
innocence.
Legal
very
few
were
actually
excluded.
L
Hop-By-Hop
options
in
ipv6,
for
instance,
and
ipv6
extension
headers,
are
discounted
an
ipv4,
but
for
the
most
part
it
doesn't
seem
like
there's
a
reason
to
exclude
any
of
the
normal
IP
protocols.
At
this
point
we
allow
user-defined
control
types.
We
greatly
expand
at
the
ayana
considerations,
so
there
are
several
values
that
we
need
to
to
define:
iono
numbers
for
the
checksum
and
some
other
things
were
deferred
to
the
extensions
draft
which
I'll
talk
about
in
a
moment
and
we
expanded
on
the
Security
section
and
also
there's
a
public
online,
advanced
security
and
extensions
draft.
L
So
that
was
the
main
draft,
and
then
we
have
a
companion
draft,
which
is
myself
Lucy
and
Fred
templin
contributed
greatly
to
the
fragmentation
part
of
it.
So
this
is
consolidating
what
we
kind
of
consider
the
fundamental
set
of
goo
extensions.
So
when
we
develop
you,
we
also
had
the
idea
that
we
would
need
extensions,
so
we
kind
of
derived
a
basic
set.
What
appear
to
be
the
fundamental
core
extensions
that
we'd
want
to
have
an
in
an
encapsulation
protocol
and
they
are
checksum
option
fragmentation,
option
security
and
paler
transforms
and
remote
checksum
offload.
L
Checksum
option
it's
very
similar
to
UDP
light,
except
we
always
cover
the
the
GU
header,
which
is
very
specific
with
a
header
length
and
we
allow
some
portion
of
the
goop
paler
to
be
covered.
The
reason
we
have
a
checksum
in
the
GU
header
is
this
kind
of
resolves
some
tricky
issues
we
got
with
the
ipv6
checksum
in
particular,
and
this
will
include
a
pseudo
header.
L
So
the
idea
is
that
we
can
use
the
GU
checksum
to
include
the
pseudo
header
and
that
allows
us
to
not
use
the
ipv6
checksum,
which
can
be
it
doesn't
have
to
be
used,
accepting
restrictions
on
not
using
it
or
pretty
complex,
as
we've
seen
in
G
reviewed.
If
you
in
mpls
reading
people
nextly
fragmentation,
then
this
basically
it's
an
idea
from
44
59.
The
ideas
put
fragmentation
in
the
encapsulation
layer,
Joe
and
Fred
have
obviously
been
talking
about
fragmentation
on
the
list
a
lot.
L
This
is
part
of
the
discussion,
the
idea
it's
pretty
pretty
straightforward.
It's
much
like
normal
IP
fragmentation.
We
do
get
to
put
a
fairly
large
identifier
in
which
is
obviously
helpful,
and
one
of
the
things
about
fragmentation.
Encapsulation
is
actually
very
efficient.
We
only
have
the
outer
IP
how
to
replicate
it.
There's
no
inner
IP
header,
that's
replicated
so
it's
IP,
header,
goo
header
and
then
basically,
the
fragmented
packet
security
option,
as
I
mentioned,
also
is
very
important.
This
is
a
variable
field
to
accommodate
various
security
protocols.
L
Sorry
now
is
defined
as
a
64-bit
128
bitter
2056
fitch
field.
It's
opaque
in
the
sense
that,
in
order
for
security
work,
obviously
the
endpoints
have
to
agree
on
the
meaning
of
it,
and
we
have
a
couple
of
examples
of
how
this
might
be
used.
Simple
security,
cookies,
secure
hash
could
use
other
algorithms,
to
whatever
extent
we
need
security.
L
Payload
transformation
option
is
kind
of
related.
This
is
the
idea
that
we
will
want
to
encrypt
payloads,
often,
maybe
sometimes
and
compress
it.
So.
The
idea
of
the
payload
transfer
transform
option.
This
tells
what
the
payload
actually
is.
So
our
first
definition
for
this
is
dtls,
so
this
allows
us
to
have
GU
dtls
payload
and
the
dtls
obviously
protects
the
payload
with
fairly
strong
security.
L
It's
like
remote
checksum
offload
is
an
optimization.
This
is
for
Nick's
network
interface
cards
that
compute
the
TCP
or
UDP
checksum
of
packets,
however,
are
not
capable
of
looking
inside
an
encapsulation
to
do
the
computation,
so
we
actually
found
some
tricks.
If
you
turn
on
the
UDP
checksum,
there
are
ways
to
derive
the
inner
checksum.
L
If
we
know
where
it
is
so,
the
idea
of
the
remote
checksum
all
flight
is
to
emulate
sort
of
a
checksum
offload,
but
packet
actually
goes
to
the
receiver
and
the
receiver
can
deduce
what
the
correct
checksum
is
on
the
basis
that
the
outer
UDP
checksum
was
correct.
So
it's
a
really
nice
performance
optimization
and
we
see
pretty
good
results
with
this,
so
we
kind
of
like
it
okay,
so
I
guess
the
request
for
making
on
the
interior
is
to
adopt
goo.
So
apparently
that
has
happened.
L
D
Thanks
so
the
that's
a
reminder,
so
we've
already
accepted
to
inherit
from
many
03
the
GUI
and
you
heard
what
the
differences
are
from:
C
3
to
4
and
there's
the
extensions
document.
So
I
guess
the
next
step
would
be
to
request
the
adoption
of
the
extensions
document
on
the
mailing
list.
But
how
does
anybody
have
any
question
for
Tom
Moore,
quick
pick
on.
M
David
back
at
Tom,
not
such
a
question
for
you
but
I.
Think
a
general
question.
After
Ross
Callens
talk
talk
at
the
plenary.
M
L
L
M
Okay,
actually,
it
is
a
serious
question,
because
it
this
is
not
going
to
be
the
last
one.
We
certainly
have
enough
and
some
kind
of
guidance
and
architecture
document
about
which
ones
you
ought
to
use.
Where
for
what?
What
purpose
would
probably
benefit
people?
Who
don't
follow
the
encapsulation
development
to
work
here
in
detail.
N
K
D
N
So
I'm
quickly
going
to
recap
on
where
we
coming
from
so
we
did
a
couple
of
experiments,
one
here
at
the
ITF
and
Yokohama,
if
you,
if
you
remember,
and
one
on
a
fairly
large
campus
network
and
what
we
did,
we
record
it
all
broadcast
and
multicast
I'm
traffic,
and
it
turns
out
that
there's
a
lot
of
personally
identifiable
information
in
those
protocols
and
a
lot
of
these
protocols
don't
come
from
from
the
IETF,
so
the
privacy
problems
we
saw,
for
example,
was
host
namings
a
lot
of
people
name
their
host
after
themselves,
which,
if
that
is
broadcast.
N
Obviously
everybody
knows
your
name
and
potentially
your
identity,
and
that
is
basically
covered
in
in
this
document
that
you
saw
earlier
at
the
chess
presentation.
So
this
is
basely
done.
There's
a
lot
of
users
are
persistent
identifiers
and
that
has
big
implications
on
a
couple
of
things.
That's
thing
done
in
the
ITF
or
I
Triple
E,
where
you
talk
about
IP,
address,
randomization
or
mac
address
randomization.
If
you
randomize
your
mac
address,
but
you
have
a
persistent
identifiers
that
is
broadcast
to
everybody
on
the
land.
Why
even
bother
write?
It
completely?
N
Destroys
mac
address
randomization,
a
couple
of
protocols.
Do
this.
We
observe
protocol
behavior
and
a
lot
of
protocols
frequently
broadcast
and
frequently
means
like
four
times
a
minute
and
that's
a
lot.
So
you
have
to
be
on
the
network
for
for
a
couple
of
seconds
and
we
have
seen
everybody
on
the
land.
N
I
mean
something
like
if
you're
a
microsoft
windows,
user,
for
example,
you
can
configure
your
wireless
LAN
based
on
SSID,
saying
you're
at
home,
you're
at
work
or
you're
in
a
public
space,
and
then
windows
is
behaving
differently.
So
it's
not
responding
to
ping
anymore
and
things
like
that,
and
we
haven't
seen
that
in
those
apps.
N
So
the
problem
very
often
is
proprietary
protocols
sewn
on
IDF
protocols
and
because
idea
protocols
are
fine.
We
believe
for
three
reasons.
So
there's
people
looking
at
these
protocols
that
have
something
to
say
input
like
the
security,
Directorate,
they're
being
reviewed
people
design
them
carefully.
A
lot
of
people
have
something
to
say
about
them
and
we
have
documents
that
you
will
privacy,
for
example,
this
one
yet
the
NSS
d
privacy.
We
have
RFC,
70
and
19,
which
goes
with
the
HTTP
privacy
and
a
bunch
of
others,
and
that's
operational
support
and
product.
N
So
there's
a
lot
of
wireless
access
points,
for
example,
where
you
can
enable
dhcp
snooping,
which
means
the
access
point,
will
see
that
the
DHCP
packet
and
not
going
to
rebroadcast
that
packet
on
the
wireless
interface.
Because,
then,
you
can
have
a
rogue
DHCP
server
or
something
like
that.
So
there's
products
that
you
deal
with
these
protocols
and
they
can
because
they're
openly
specified
by
the
idea
so
I
TF
locals
and
the
major
culprit
here,
but
its
proprietary
protocols
because
they
receive
none
of
this
no
review,
no
input,
no
operational
support
because
they're
largely
unknown.
N
So
in
in
this
document
we
have
some
protocol
design
guidance
for
these
kind
of
folks
to
avoid
these
privacy
problems
that
we
have
observed
in
in
real
operational
networks
when
we
did
our
experiments,
for
example
by
you,
revealed
the
identity
and
social
graph
of
a
user.
That's
not
what
you
want
and,
as
I
said
before,
we
really
want
to
avoid
that
these
protocols
break
things
that
happen
at
the
ITF
or
other
SDOs
such
as
IP
address
or
mac
address
randomization,
because
it
completely
destroys
all
these
efforts.
N
So
if
you're
an
app
developer-
and
you
have
this
cool
broadcast
feature-
you
can
completely
destroy
IP
address
randomization.
You
should
be
aware
of
this
right.
You
should
go
somewhere
and
look
it
up
and
say:
okay,
I
shouldn't
do
this
because
I'll
destroy
this
right
and
we
want
to
help
build
better
products.
So
I
think
with
this
document,
we're
at
the
point
where
we
either
say
we're
gonna,
adopt
this
and
progress
it
towards
an
RC
or
kill
it,
and
that's
your
decision.
Okay,.
D
Question
so
the
reminder
this
is
our
talking
that
we've
been
looking
at
for
a
while,
since
experiment
there's
been
support
and
there's
more
details
than
having
added
progressively,
but,
yes,
I
think
the
idea
would
be
to
to
eventually
adopt
this
document.
So
we
really
want
to
hear
from
the
group
what
the
what
their
opinion
is:
Grissom
I.
O
O
O
P
Q
Q
Q
Q
Yeah,
the
basic
idea
is
that
it's
a
best
con
practice
draft,
given
that
ACN
was
added
to
IP
in
2001,
but
that
changed
the
lower
interface
and
nothing
was
ever
really
written
about
what
protocols
beneath
IP
should
have
to
do.
This
is
both
the
tunnels
and
lower
layers.
It's
actually
not
straightforward.
Q
Q
The
big
problem
is
incremental
deployment,
as
the
next
slide
shows,
and
this
this
compares
ecn
with
diffserv
or
traffic
class
identifier,
more
generally,
because
it's
sometimes
called
traffic
class
in
weight.
It's
called
a
and
b
6,
in
fact,
and
it
with
that
you're
sending
your
requirements
down
the
stack
to
the
lower
layer
or
to
the
tunnel
outer,
whereas
with
ecn
you're,
sending
the
fact
that
it's
capable
that
the
transport
is
capable
of
understanding,
easy
and
down
the
stack
and
then
you're.
Q
The
lower
layer
is
sending
possible
congestion
experienced
up
the
stack
and
you
get
a
need
to
combine
the
inner
and
the
outer
at
the
egress
of
a
tunnel
or
a
larry
gress,
which
is
what
our
f6
I've
see.
6040
specifies
in
that
table.
Elmet
we're
not
changing
that
in
the
current
work.
We're
just
writing
guidelines
on
how
to
write,
lower
layer
protocols
and
pointing
them
at
those
drafts
and
all
the
rest
of
it.
Q
So
I'm
just
going
to
go
through
not
what
this
draft
says,
but
one
of
the
major
parts
of
it,
which
is
very
small
and
has
just
been
split
out
into
another
little
draft
which
you'll
see
at
the
moment
is
individual,
but
the
TS
PWD
chairs
want
to
fast-track
it
to
PS,
because
it's
essentially
it
was.
It
was
a
section
of
text
in
this
BCP
that
updated
a
number
of
other
proposed
standards,
and
so
we've
taken
that
out
as
a
proposed
standard.
So
it
all
goes
through
the
process
smoothly
and.
Q
The
problem
that
it's
a
very
simple
little
problem,
RFC
6040,
is
about
tunneling
of
ecn
and
its
scope
was
IP
and
IP
tunnels
and
it
was
unclear
to
people
some
people
guess
that
that
meant
also
IP
and
I
pee.
Where
there's
a
shim
in
between,
like
you
know,
Jerry
or
do
that
has
just
been
talked
about,
and
others
guess
that
it
didn't
mean
that
so
we
thought
we'd
better,
make
it
clear.
Q
So
this
is
just
a
minor
update
to
say
we
do
actually
include
that
and
we've
specified
it
as
tightly
coupled
shim,
in
other
words,
where
the
shim
is
added
at
the
same
time
as
the
outer,
so
that
it
is
effectively
something
where
the
machine
that's
doing.
It
can
have
in
memory
what
was
in
the
other
header
and
what
will
be
in
the
new
one.
So
I
can
compare
the
two
and
just
in
case
and
in
fact
I'd
like
feedback
from
anyone
that
reviews
this
about.
Q
This
we've
said
that
RC
6040
should
apply
because
we
figure
we're
talking
about
updating,
tumbling
specs
that
have
been
around
for
many.
You
know
hundreds
of
years,
and
so
it
may
be
infeasible
to
change
implementations,
because
the
way
they've
been
structured,
but
if
you
think
we
could
say
must
we'd
rather
say
must
and
to
give
a
feel
for
the
specs.
This
is
going
that
this
has
in
the
updates
header.
Q
M
M
Q
Q
Q
Right
so
next
steps.
We
would
really
like
someone
to
review
both
these.
If,
if
you
feel
you
may
get
forced
to
review
them,
you
might
want
to
pick
the
short
one,
which
is
two
pages
before
you
get
forced
to
read
the
other
one
which
is
29
pages,
but
the
the
obviously
be
the
one
that
some
standards
track
is
more
important,
but
the
other
one
is
also
much
more
generic.
So
someone
with
a
bit
of
an
architectural
feel
for
all
this
would
be
useful.
Q
So,
yes,
reviews
please,
for
both
and
I've
put
up
there,
the
sort
of
things
we're
looking
at
for
reviewability.
You
know
the
comprehensibility
gaps
for
the
first
one,
but
the
second
one
it's
more
is
the
list.
Complete
is
the
main
thing,
because
it's
such
a
short
one
and
that
point
about
can
we
make
it
a
must
for
following
6040
or
do
we
have?
Should
it
be
assured,
but
like
that
looked
over
so
I,
don't
know
whether
there's
any
volunteers
have
you
think
volunteers
in
this
one
group
well.
D
D
H
H
So,
as
you
might
guess,
enhanced
ping
is
an
enhanced
form
of
being
or
extended
ping,
and
I'm
not
one
of
the
authors.
They
couldn't
make
it
so
I'm
giving
this
presentation
for
them.
So
the
motivation
is
that,
when
operators
deploy
a
router,
there
might
be
useful
to
be
able
to
use
numbered
v4
interfaces
or
private
address
space
for
v4,
or
only
a
link
local
address
on
the
v6
interface.
H
But
when
you
do
that,
you
can't
ping
those
interfaces
from
anywhere
on
the
internet
and
even
in
the
case
of
like
a
numbered
ipv4
interfaces
even
from
within
your
own
domain.
So
eeping
comes
to
the
rescue
here.
It's
an
application.
Much
like
traditional
ping
sends
a
probe
message.
Waits
for
reply.
What's
different
about
extended
ping
is
that
you
have
two
interfaces
that
you're
going
to
specify.
H
H
At
this
point,
some
comments
have
been
received
from
a
mailing
list,
in
particular
adding
the
ability
to
identify
an
interface
by
MAC,
address
various
editorial
comments
and
we'll
be
posting
a
new
version
after
ITF,
and
so
eventually
we'd
like
to
do
this
to
be
considered
for
adoption.
At
some
point,
thanks
thanks
a
lot.
R
Jhene
aiko
I
have
not
read
the
draft
sir,
but
I
have
a
question.
So
when
you
didn't
define
interface,
I
assume,
for
example,
for
ipv6
link-local,
you
should
specify
it
with
zone
index
right.
H
R
H
R
S
H
H
I
agree:
I'll
make
sure
the
author's
receive
that
information.
D
Thanks,
thank
you
very
much
so
again
the
authors
are
not
present,
but
we
encourage
people
to
send
comments
on
the
list.
Thanks
a
lot
Chris.
So
next
topic:
Margaret's
gonna,
talk
to
us
about
bandwidth,
aggregation
for
network
access,
a
new
topic
and
probably
relevant
for
interior
and
very
adult
to
also
being
next
to
the
zoo,
I
guess
so.
T
For
several
I
TS
now
we
had
an
informal
group
meeting
to
discuss
bandwidth,
aggregation
for
network
access
or
what
we
call
banana.
The
bananas
scenario
is
a
very
strict
subset
of
a
site,
multihoming
scenario:
it's
a
scenario
where
you
have
multiple
links
to
a
home
or
small
office,
and
they
are
provided
by
the
same
service
provider,
which
opens
up
a
possibility
for
this
sort
of
picture
where
you've
got
a
host
a
in
a
homer
or
small
office.
T
You've
got
a
host
be
somewhere
on
the
internet,
and
the
cpe
is
used
is
connected
to
two
different
types
of
link
in
this
case.
In
this
particular
example,
an
LTE
link
in
a
DSL
link,
but
it's
not
specific
to
that
and
you
could
have
a
concentrator
in
the
operators
network.
That
also
can
combine
those
two
links,
and
in
this
case
there
are
various
options
for
how
to
do
things
like
a
load
sharing
across
those
two
links
for
bandwidth,
aggregation
and
or
failover.
T
If
one
of
those
links
is
down,
the
traffic
could
use
the
other
link
there.
A
lot
of
people
are
doing
work
in
this
area
throughout
the
Internet.
The
broadband
forum
is
working
on
some
architecture
for
this,
but
there
are
many
operators
who
are
out
there
already
implementing
this
in
several
different
countries.
Hundreds
of
thousands
of
users
of
proprietary
solutions
in
this
area
and
we've
been
getting
a
lot
of
those
people
together.
T
T
There
were
other
proposals
as
well:
there
was
a
mobile
IP
based
proposal.
That
was
quite
interesting
and
there
was
quite
a
bit
of
interest
in
it,
but
the
spec
seemed
to
have
expired
and
I
need
to
get
with
the
authors
and
find
out
if
they're
going
to
be
updated,
and
there
were
always
also
a
list
based
proposal
that
was
experimental
and
the
authors
were
doing
I'm,
mostly
interested
in
doing
a
simulation
and
measurements
and
stuff
on
their
simulation,
and
there
were
some
others.
Some
other
proprietary
choices
out
there
that
haven't
been
documented
in
internet-drafts.
T
But
my
considerations
document
right
now
brings
up
his
shoes
like
her
flow
versus
per
packet.
Multiplexing
right,
you
can
say
well,
poor
clothes,
always
better
suppose
the
answer
you
get
from
everybody
else.
You
got
to
do.
/
flow
load
sharing,
except
that
from
a
home
there
might
at
any
given
time
the
only
one
or
two
or
three
flows
into
a
perf
low
load
sharing
actually
gets
pretty
poor
results,
so
people
are
doing
per
packet
or
like
in
the
case
of
MP
TCP
they're,
not
absolutely
doing
/
flow.
T
They
are
actually
able
to
to
share
the
load
of
one
flow
across
multiple
connections.
I
talked
about
whether
UDP
gets
low,
balanced
or
bypassed
in
the
NPT
CP
case.
It's
easy
to
do.
Tcp
UDP
has
to
go
a
different
route.
Some
people
are
just
using
MP,
tcp
and
bypassing
UDP.
That
might
be
okay
if
the
amount
of
UDP
traffic
stays
low,
but
if
quick
continues
to
run
on
UDP
and
becomes
popular,
maybe
that
won't
be
okay.
I
talk
about
those
things
in
the
draft
and
together.
H
H
T
T
T
There
is
the
next
steps
and
what
common
work
we
could
do
or
what
work
we
could
do
here
in
the
IETF
and
then
decide
whether
we
can
bring
the
work
to
the
interior
working
group,
possibly
or
or
to
another
group,
and
that's
basically
why
I'm
here
today
is
to
talk
to
people
about
the
work
here
that
doesn't
have
an
ietf
home.
The
problem
statement
considerations
the
GRE
total
potential
GRE
tunnel
based
solution,
a
standard
one,
possibly
based
on
current
proprietary
work
and
even
the
MP
TCP
based
solution
does
not
have
a
home.
T
They
talked
about
reach
our
turing
to
do
it,
but
there
would
work
was
quite
a
bit
of
objection
to
that
in
the
npp
CP
group
saying
it
was
really
more
of
an
interior
problem.
So
should
we
be
doing
this
kind
of
work
and,
if
so,
where
and
how,
here
in
it
area
somewhere
else,
they
may
have
any
opinions
about
that.
T
D
D
T
D
U
Well,
this
will
be
very
short
all
those
about
not
very
short,
so
next
slide,
please,
yes,
so
this
is
the
draft
about
more
or
less
below
layer,
three
characteristics
of
wireless
links
and
we've
had
the
draft
out
there.
It
sort
of
gotten
some
comments
it
and
finally,
as
earlier
this
week,
I
responded
to
all
the
comments
that
were
on
the
list
and
put
out
a
new
version
of
the
draft
which
I
pretty
much
don't
reckon
too
many
people
at
a
time
to
read.
U
U
Three
hubs
well
really
we're
talking
about
what
kind
of
affects
their
our
own
links
between
neighboring
devices,
but
really
it's
in
sort
of
in
the
context
of
layer
three
ups,
it
was
a
suggestion
to
reduce
the
sort
of
informal
nature
of
some
of
the
discussion,
so
that
was
done.
The
triggers
were
redrawn,
better
captions
and
then
some
wordsmithing,
so
all
in
all
I
think
that
it
was
a
relatively
incremental,
except
maybe
the
next
slide.
Please
other
words.
U
A
suggestion
for
making
in
this
draft
a
discrete
discussion
about
how
to
determine
the
quality
of
a
link
and
link
quality
indicators
is
a
non-trivial
subject.
It's
no
just
I
guess
you
would
say
it's
related
to
metrics
over
a
link
and
there's
all
kind
of
things
you
can
measure
and
whether
it's
bi-directional
or
useful,
or
what
thresholds
her
are
and
so
on,
and
so
I
think
that
it
does
deserve
discussion.
But
I,
don't
think
it
belongs
in
this
draft
and
it
would
be
a
whole
new
area
for
discussion.
So
I
think
that's
my
last
slide.
U
D
Thank
you
very
much
Charlie,
so
any
quick
feedback
on
this
last
couple
of
slides
to
Charlie.
Otherwise,
probably
we
should
take
this
to
the
list.
Then
I
think
it's
a
good
questions,
but
maybe
better
to
discuss
it
on
the
list
I'm
going
to
bring
serologies
for
the
other
presenters
we're
out
of
time,
but
I
mean
the
slides
are
having
uploaded
feel
free
to
to
to
ask
for
a
feedback
on
the
under
list
and
you
very
much
written.