►
From YouTube: IETF112-V6OPS-20211112-1200
Description
V6OPS meeting session at IETF112
2021/11/12 1200
https://datatracker.ietf.org/meeting/112/proceedings/
A
Three
out
of
four
chairs:
that's
that's
as
good
as
we
could
hope
for.
I
suppose.
A
I
can
certainly
do
that
so
welcome
to
this
v6
six
man
joint
working
group
session
on
the
hop
by
hop
extension,
header,
behavior,.
A
A
We
don't
practice
those
on
online
meetings
or
with
miteko.
We
probably
don't
practice
them
anymore
at
all
the
speakers.
The
presentations
are
uploaded
to
mitico,
so
the
speaker
should
just
go
and
press
the
share.
Preloaded
slides,
find
their
slide
set
and
and
share
that
they
can
run
and
control
the
slides
themselves.
A
A
Then
we'll
have
a
section
on
the
requirements
and
solution
drafts,
basically
more
meat
on
the
problem.
If
you
like
a
set
of
example,
use
cases
just
lightning
talks
on
those
just
to
give
an
idea
of
how
hope
I
hope
is
used
today
and
then
we
hope
to
spend
most
of
the
time
at
the
end
of
the
meeting
discussing
where
we
want
to
take
hope.
I
hope
if
you
want
any
changes
or
improvements
to
the
hope,
I
hope
extension
header
any
comments
on
the
agenda
before
we
move
on
to
the
main
topic.
C
C
C
The
hop
by
hop
extension
header
can
be
used.
Two
ways.
One
way
is
to
influence
how
a
packet
is
routed,
as
are
most
of
the
fields
in
the
base.
Ipv6
header.
Another
way
it
can
be
used
is
to
influence
the
control
plane.
The
router
alert
option
was
used
that
way
so
because
it
was
used
to
influence
the
control
plane.
Many
implementations,
punted
packets,
containing
the
router
alert
option
to
the
control
plane
and
unfortunately,
this
can
caused
the
router
alert
option
to
be
a
dos
vector.
C
Then
many
implementations,
just
punted
all
packets,
containing
the
hbh
to
the
control
plane,
and
this
caused
all
packets
containing
hph
to
become
dos
vectors
that
made
bad
things
happen.
Network
operators
filtered
all
packets
containing
hph
people
didn't
use
the
hbh
because
they
knew
it
would
be
filtered,
and
we
had
this
kind
of
cycle
of
failure
for
the
hbh.
C
Well,
something
changed
in
rfc
8200,
and
it's
this
note
that
you
see
on
the
right
hand,
side
of
the
slide.
Initially
all
nodes
had
to
process
the
hbh
options,
but
now
it
was
expected
that
a
node
would
only
process
hph
if
it
was
explicitly
configured
to
do
so.
C
C
C
C
Do
we
need
to
re
re-examine
currently
to
find
hbh
options?
A
lot
of
them
are
just
hanging
around
for
historical
sake.
Maybe
the
router
alert
option
needs
to
be
deprecated
and,
finally,
what
work?
What
documents
do
we
need
to
progress
in
order
to
make
this
happen?.
C
Would
and
at
this
point
I'll
open
the
floor
for
anybody
who
wants
to
ask
questions
about
what
our
goals
are
in
this
meeting.
C
D
Yeah
hi
this
is
guillermo.
Presenting
for
the
for
that
draft
for
the
hp
adoptions
processing
drops
excellent.
Can
you
share
the
slice
yourself
or
do
you
need
some
help?
You
know
I
haven't
done
it
before.
Maybe
if
you
could
give
me
again.
A
Probably
same
time,
okay,
let's
see
if
we
can
find
the
presentation.
A
I
think
it
is
this
one
is
that
the
correct
slide
set
yeah?
Yes,
excellent,
yeah.
D
That's
it
all
right:
excellent,
okay,
all
right
hi,
my
name
is
dion
mishra
and
I'll,
be
presenting
operational
issues
with
processing
of
humpbai
hop
extension
headers.
So
so
this
draft,
just
in
in
recent,
I
believe,
a
few
a
few
weeks
or
so
ago.
We,
the
draft,
was
recently
adopted
since
adoption,
we've
changed
and
updated
the
name,
and
then
we
have
a
few
additional
updates
to
the
draft.
D
So
in
this,
in
this
deck,
we'll
be
we're
going
over
the
updates
and
then
the
overall
progression
of
the
of
this
draft
and
and
then,
as
as
ron
had
mentioned,
I
guess
you
know
kind
of
segue
into
kind
of
the
issues
and
all
related
to
hop.
I
hop
extension,
headers
and
especially
kind
of
honing
in
on
the
focus
of
this
draft
and
really
the
problem
statement,
and
it's
it's
really
not
now.
D
Now,
as
this
draft
is
a
work,
your
job
document
really
just
this
drop
draft-
is
really
applicable
to
really
any
any
issues
related
and
really
honed
in
on
on
hbh
options
and
what
the
problems
that
occur
that
exist
today
and
then
how
we
can
segue
into
breaking
that
cycle
with
related
issues
and
not
having
to.
D
I
guess
worst
case
scenario,
as
ron
had
nicely
mentioned:
deprecate
hph,
so
we
want
hph
to
be
viable
and
that's
really
the
goal
and
and
that
a
lot
of
that
is
what
we'll
talk
through
in
this
slide
deck.
So
next
slide.
D
So
the
changes
that
were
updated
after
the
adoption
call
so
that
so
one
is
a
title.
This
is
during
the
adoption
call.
Then
we
then
we
renamed
it
after
after
that,
so
the
title
was
changed
as
it
was
misleading.
You
know
towards
the
solution,
so
we
anything
related
to
solution
space.
We
did
a
you
know
quite
heavily
and
I
believe
it
was
in
section
seven
and
eight.
We
we
removed
anything
that
was
solution
space
because
we
wanted
to
make
this
draft.
D
You
know
really
cater
to
the
work
group
that
we
want
the
work
group
to
be
involved
in
helping
develop
and
progress
the
strap.
So
we
want
so.
The
goal
was
really
to
completely
eliminate
anything
solution
related
and
make
it
come
generalized,
so
it
can
apply
to
any
solution
to
help
help
make
hph
survival.
D
So
the
purpose
of
this
draft
clarified
in
both
the
abstract,
introduction
sections
scope,
is
also
clarified
in
section
two
additional
references
added
and
it
directly
quotes
specifications
in
existing
rfcs
where
we're
suitable
and
then
the
requirements
section.
So
there
was
a
lot
of
updates
that
we
had
in
the
requirements
section
and
we
cleaned
up
a
lot
of
that.
D
So
anything
in
there
was
not
pointing
to
solution
space
or
any
kind
of
any
solution
and
just
making
it
more
generalized
and
focused
on
the
problem
statement
and
then
section
eight
significant
changes
instead
of
being
completed
or
deleted,
we
we
migrated
it.
D
We
migrated
over
that
were
important
to
consider.
So
we
just
kind
of
did
some
more
cleanup
in
section
8
as
well,
so
really
section
8
and
sections
7
were
really
the
ones
where
we
did
quite
a
bit
of
cleanup
before
the
before
and
during
the
adoption
call
to
get
this
document
ready
for
to
become
a
work
group
effort
next
slide.
D
So,
as
far
as
future
work,
so
the
requirements
in
section,
seven
st-
they
still
need
some
more
work
and
we'll
be
conducting
that
in
a
later
revision.
So
we
would
like
feedback
from
the
from
the
work
group,
and
we
appreciate
you
know
really
all
the
feedback
that
we
had
gotten
through
the
adoption
call
and
the
continued
feedback
and
that
any
criticism
we
definitely
wanted
we're
open
to
any
any
any
changes
updates
or
whatnot,
as
this
is
a
work
document
to
help
progress.
D
This
document,
the
migration
status
strategy
in
section
8,
is,
is
an
important
consideration
and
which,
which
needs
a
work
group.
You
know
that
we
have
to
work.
We
would
like
to
work
with
the
work
group
together
and
get
recommendations
on
migration
strategies
of
how
to
make
hph
options
viable
and
kind
of
a
really
a
path
forward,
and
that's
really
a
big,
a
work
group
effort
to
help
make
the
viability
of
speech
options
as
well
as
news
news,
sections
on
and
other
network
scenarios.
D
They
haven't
been
added
yet
so
there
may
be
up
that.
That
may
be
some
additional
work
future
work.
So
if
the
work
group,
you
know
as
we
progress
just
really
brainstorm
and
think
of
ideas,
enterprise,
iot
or
other
other
use
cases
and
scenarios
related
to
hph
options.
Next
slide.
D
So
I,
and
on
the
mailing
list,
there
were
some
discussions
related
to
the
draft
and
just
really
clarifications,
and
and
with
this
draft
and
just
comparing
there
were
some
comparisons
done
with
the
goals
of
rc9998
and
just
kind
of
comparisons
to
this
draft.
So
rc
1998.
D
It
was
really
it's
a
generic
and
it's
really
talks
to
all
the
all
the
extension
headers
and
really
the
christmas
tree
effect
of
the
extension
headers
and
and
and
the
limits
on
number
of
options.
You
know
within
each
header,
especially
the
hph
and
destination
option
headers,
but
really
talks
generically
to
all
all
extension
headers.
D
It
doesn't
call
out
specifically
just
the
hph
where
this
draft
is
really
honed
in
just
solely
hold
honed
in
on
the
hbh
options
and
really
trying
to
really
identify
the
problem
statement
clearly
and
then
and
the
problem
and
the
problem,
space
and
kind
of
the
endless
cycle
that
you
know
with
the
misnomer,
with
the
hbh
being
a
dos
vector-
and
you
know
with
with
older
hardware
and
now
when
you,
when
your
hardware
kind
of
getting
around
that
you
know
coming
around
coming
around
the
bend
with
that
now
trying
to
make
get
to
the
point
where
hbh
can
really
be
viable,
so
really
honed
in
and
then
also
and
then
solutions
that,
where
hbh,
especially
with
developers
being
able
to
use
hbh
as
a
viable
option
for
telemetry
and
and
there's
so
there's
so
much
there's
a
lot
of
space
that
can
be
that
can
be
used
for
for
hph.
D
There
are
a
variety
of
use
cases:
new
services,
telemetry.
You
know
ippm
working
group
with
any
io.
D
And
there's
a
variety
and
there's
probably
a
lot
more
to
come.
You
know
once
once,
hbh
really
becomes
viable
and
we
kind
of
break
that
cycle.
You
know
a
lot
more
development
can
common
and
really
the
gain.
Is
the
operators
can
really
gain
from
this
that
this
new
development?
Now
we
now
we
have
this
extra
tool
in
the
operator's
toolbox
to
really
help
pave
the
path
forward.
D
So
our
main
purpose
is
enabling
the
hp
option
to
be
utilized
in
a
safe
and
secure
manner,
without
danger,
endangering
any
operations,
and
then
the
ease
of
deployment
of
network
services
and
in
a
multi-vendor
operational
scenarios.
Next
slide.
D
What
would
what
would
happen
and
really
the
big
thing
is
with
the
dos
vector
and
really
that
you
know
having
traffic,
it
hits
the
forwarding
plane,
but
actually
all
traffic,
both
forwarding,
plane
and
control,
plane,
type
header
options,
being
the
hbh
options
being
punted
to
this,
to
the
to
the
to
the
soft
to
the
slow
path
or
the
control
plane
path,
and
that's
and
that's
really
what,
with
newer
hardware
and
intelligence
built
into
the
forwarding
plane
so
and
being
able
to
mitigate
that
and
now,
with
rate
with
interfaith,
you
know,
being
able
to
control
the
forwarding
plan,
the
rate
limiting
mechanisms
that
can
help
protect
the
control
plan
separation
and
that
and
that's
really
the
big
big
deal.
D
You
know
really
across
the
board
of
the
fear,
the
not
having
that
separation
of
control
and
forwarding
plane
that
everything
anything
that
supporting
plane,
whether
it's
a
a
forwarding
plane
option
or
a
control,
plane
option
that
everything
getting
punted
and
then
not
having
that
complete
separation
that
that
has
always
been
the
fear
and
and
and
so
with
the
rate
limiting
that
that
helps,
but
that
that
does
cause.
D
You
know
inconsistent
pack
and
drops
and
impacting
normal
forwarding
so
being
able
to
process-
and
I
guess
with
newer
hardware,
especially
with
mpus
and
as
development
happens,
being
able
to
process,
for
you
know,
process
of
hbh
options,
headers
really
in
the
forwarding
place
in
path
and
line
rate,
and
that's
that's
really
the
goal
and
as
as
a
development.
D
In
the
industry,
with
modern,
routers
and
being
able
to
handle
hph
options
so
the
misnomer
of
not
being
able
to
process
hbh
options,
I
think
that's
that's
something
that
we
kind
of
want
to
tackle,
and
I
think,
as
as
this
problem
statement
draft,
you
know,
you
know,
gets
adopted
and
becomes
rfc.
We
can
really
help,
at
least
with
the
industry
and
kind
of
change
that
misnomer
that
hbh
options
it
is
really
viable,
and
it's
in
a
break
that
cycle
that
it
really
will.
D
You
know,
not
be
a
dos
factor
not
with
intelligent
mpu's,
being
able
to
do
that
proper
processing
with
development
with,
as
well
with,
let's
say
bob
hindenstraft.
You
know
with
restricting
the
number
of
options
and
and
other
solutions
that
exist.
You
know
any
solutions
that
exist
to
really
make
it
make
it
possible
and
viable
next
slide.
D
So
common
implementation,
so
the
values
in
the
next
header
field
in
the
ipv6
header,
so
so
the-
and
this
is
kind
of
really
the
kind
of
big
issue
that
it
triggers.
So
when
the
in
the
next
header
field
is
set
to
the
to
options
to
zero,
that
directly
is
directly
sent
to
the
slow
path.
So
the
option
type
won't
be
examined
before
the
pack
has
sent
to
this
float
path.
So
and
that's
really
the
standard
kind
of
default
behavior.
D
So
as
traffic
comes
in
and
that's
then
that's
really
the
the
fear
that
I
and
that
operators
have
with
with
hph
and
that's
why
there's
a
field
rate
limiting
filtering
and
and
dropping
with
acls
to
drop
it
so
and
that
and
that's
the
common
implementation.
That's
been
done
with
most
vendors,
as
as
as
the
development
happens,
with
with
modern
routers,
with
npus
and
and
moving
away
from
fixed
function,
86
to
more
special
specialized,
I
guess
architectures
and
even
proprietary
asics,
but
that
basic
development.
D
As
that
happens,
the
the
priorities
being
sent
the
forwarding
plan
and
what
you
know
will
be
we
should
be
able
to
handle.
You
know
hp
adoption,
the
line
break
and,
and
with
you
know,
possible
restrictions
on
the
number
of
options
that,
as
draft
you
know,
hasn't
that
that
idea
and
maybe
other
solutions
that
actually
can
help
kind
of
clean
that
up
so
making
that
forwarding
plane
viable.
So
we
don't.
D
You
know
punt
traffic
directly
to
the
slow
path
so
and
historical
reasons
that
you
know,
and
then
this
also
something
that
what
what
this
draft
really
spells
out
in
detail.
There's
an
architecture
section
that
goes
into
the
control,
plane
and
forwarding
plane,
architecture
and
historical
reasons
of
what
happened
with
with
this,
with
not
having
that
separation
and
everything
being
punched
into
the
slow
path
and
now
newer,
asics
and
architect
and
basics,
and
npus
being
able
to
really
have
the
ability
and
can
handle
hph
options.
So
that
that's
that's!
D
That's
really
the
goal
that
she
kind
of
changed:
that
mindset
for
operators
and
then
implement
implementation
as
well.
Now
you
know
at
least
across
the
board
being
able
to
handle
that
handle
the
processing
next
slide.
D
So
standard
specifications
so
rfc
2460
required
that
all
the
nodes
examine
and
process
hop
by
hop
options.
Header
rc
8200
now
expected
all
those
long
delivery
paths
only
examine
the
process
of
halfway
hop
options
that
are,
if
explicitly
configured
to
do
so.
So
that
was
a
that
was
a
big
change,
a
change
from
a
2460
to
8200.
D
So
now
there's
a
local
configuration
that,
depending
on
the
on
the
on
the
note
itself,
you
know
whether,
if
you
can
process
that
to
process
that
only
if
it's,
if
it's
capable
of
processing,
so
that
that
that
does
help-
and
you
know-
for
operators
as
well
to
not
have
to
you-
have
that
fear
of
that
control,
separation
of
control,
plane
or
forwarding
plane
that
nodes
that
are
maybe
down
rev
that
they
can
avoid
and
they
with
local
configuration
to
avoid
having
to
process
hph
options
that
they're
not
capable
of
doing
so
and
then
as
well.
D
So,
with
our
current
situations
of
various
configurations
and
and
operator
of
networks
unable
to
support
service
deployments
and
just
disturbs
normal
ip40,
so
that
that's
really
kind
of
the
big
big
issue,
especially
on
the
public
internet
as
well
as
you
know,
private
mpls,
you
know
and
internal
networks,
but
any
any
anywhere
where
you
have
hvh
options.
D
I
think
the
fear
of
that
not
having
that
control
plan,
separation,
control,
important
plane,
separation
when
hbh
option
comes
in
you
know
either
you're
dropping
it
right,
limiting
it
or,
where
or
being
punched
into
the
forwarding
path,
and
the
ignore
is
really
the
biggest
thing
that
you're
ignoring
it.
So
now
that
that
that
feature
of
being
able
to
make
use,
hph
absence
reliably
and
having
it
be,
a
feasible
solution
for
for
developers
is
really
not
possible.
Just
the
way.
D
Job
rate
is
a
typical
processing,
so
many
many
operators
deploy
ecls
that
discard
all
packets
containing
hph
options.
So
this
is
got
with
this
draft
of
the
honing
and
on
hbh
and
trying
to
control
just
change
that
mindset
for
operators
to
not
not
do
that.
D
As
with
with
the
development
and
with
modern,
routers
and
development
that
that
hph
options
it
can
be
viable,
and
there
is
with
your
architectures
that
we
have
that's
with
that
separation
control
plan,
forwarding,
plane,
rc
6564
reports
from
fields
indicating
that
some
ip
routers
deployed
with
global
internet
are
configured
either
to
ignore
or
drop
had
packets
having
hpd
rs
7872.
D
So
many
many
network
operators
perceive
hph
options
to
be
a
breach
of
separation
control
control
authority,
plane,
which
I
mentioned.
Several
network
network
operators
configure
their
nodes
to
discard
all
packets
connected
to
the
page
options
so
kind
of
making
it
really
not
viable
and
then
other
nodes.
Other
configure
nodes
are
forwarding
packets,
but
ignore
hph
options
so
the
ignoring
dropping
and
and
then
you
know,
control
plane.
You
know
so
there's
there
are.
D
You
know
overall
just
a
lot
of
the
operators,
typical
processing,
really
kind
of
denied
denied,
dropper
or
or
or
not,
for
the
rate
limit.
You
know,
then,
that's
really
been
the
typical
kind
of
business
as
usual
method
of
dealing
with
hbh
and
you
know
making
it
you
know
not
viable
excuse
me.
D
Yeah,
let
me
let
me
just
thank
you.
Thank
thanks
ron
good
next
slide
I'll
see
if
I
can
breeze
through
all
right
all
right,
so
shall
we
break
the
end
little
swoop.
So
that's
the
biggest
thing
here.
We
want
to
really
make
hph
viable,
really
break.
D
That
kind
of
mindset
for
operators
with
with
development
of
you,
know,
new
implementations
and
updated
implementations
across
the
board,
with
vendors,
making
it
to
make
hph
viable
and
being
able
to
process
hp,
and
you
know,
options
not
having
that
mindset
that
it's
a
dos
vector
and
and
then
not
and
then,
and
getting
getting
out
of
that
mindset
that
we
have
to
drop
them.
Gotta
discard
the
plain
acls
to
drop.
It
drop
up,
hb
adoptions.
D
So
we'd
like
to
so
with
the
community,
you
know,
I,
you
know
internet
community
at
large
we'd
like
to
break
the
loop.
You
know
this
continuous
loop
of
you
know
not
not
not
having
hph
really
be
reliable.
You
know,
because
it
because
of
the
mindset
with
the
operators
and
breaking
that
loop
fix
the
problem,
so
the
problem
exists
and
then
trying
to
make
hbh
viable
with
processing
and
having
feasible
solutions
such
as
I
mentioned.
D
You
know
bob
in
the
trap,
with
the
limit
of
the
number
of
hbh
options
and
other
solutions
that
may
be
out
there.
Fixing
that
problem
and
making
make
hph
options
actually
be
able
to,
you
know,
be
a
viable
solution
that
can
be
utilized
by
operators.
You
know
in
their
operator
toolbox
now
allow
better
leverage
of
the
hph
capability
next
slide.
D
So
we've
collected
requirements.
You
know
on
reasonable
solutions,
so
there
has,
there
has
been.
You
know:
we've
gone
through.
I
taught
mentioned
bobsleigh
and
they'll
be
talking
about
that.
I
think
everything's
up
after
this.
So
that's
that's
really
the
big
one
and
I'll
I'm
gonna
skip
through
this
slide
that
I'll
be
digging
into
that
anything
in
his
presentation.
Next
slide.
D
You
so
questioning
comments.
C
B
Gory
was
also
going
to
present.
Let
me
see
if
I
can
figure
it
out.
B
A
B
Good,
yes,
gory
and
I
got
involved
in
this
when
we
were
working
on
the
path
mtu
option.
Corey
and
his
university
did
a
number
of
data
collection
to
sort
of
figure
out
how
well
hop
I
hop
work
hop
by
hop
options
worked
and
we
quickly
discovered
that
they're
dropped
a
lot,
especially
at
the
edge,
and
so
it
was
so.
We
started
to
think
about
how
could
we
improve
processing
pop-up
options?
Yeah
there's
been
a
lot
of
interesting
discussion
in
the
dabber
room
about
this.
So
why
don't
we
next
slide.
B
Yeah,
so
this
this
is,
as
the
previous
speaker
said,
top
options
are
not
working
well
on
the
internet,
it's
very
common
to
drop
them,
and
so
this
is
a
proposal
to
modify
how
routers
process
hop
high
up
options
next
slide.
B
Yes
and
8200
sort
of
define
what
was
up.
We
believed
to
be
current
practice
that
you
know
when
8200
was
done,
that
you
know
they
weren't
getting
processed
and
already
so
it
was
changed
or
clarified
that
you
would
only
process
them
if
you
were
configured
to
do
so,
and
this
obviously
did
not
improve
the
situation
next
slide.
G
Yeah,
okay,
so
our
take
was:
could
we
find
a
way
to
simplify
the
way
in
which
hot
buy
hop
options
are
used
because
commonly
we
find
paths
that
drop
the
hotmail
hop
option
at
some
point
along
the
path?
Now
this
isn't
dropped
in
the
sending
node
and
it
isn't
dropped
in
the
receiving
node
and
it's
not
even
dropped
in
the
first
half.
G
G
There
are
a
number
of
little
pieces,
but
the
ability
to
push
something
onto
the
slow
path.
We
now
see
as
a
dos
attack,
and
we
have
rfcs
that
support
us
in
this.
So
the
goal
is
to
redefine
the
procedures,
to
make
hot
lap
actions
practical,
and
we
know
it
won't
work
on
all
paths.
So
this
isn't
kind
of
saying:
hey,
we'll
write
an
rfc
and
change
all
these
routers,
but
what
we
think
it
can
do
is
we
can
encourage
a
design
and
deployment
case
where
it
starts.
G
G
Okay,
so
so
the
good
thing
about
rules
is
bob,
and
I
are
not
that
opinionated
about
this
set
of
rules,
but
we're
opinionated
at
the
moment
that
we
should
have
a
set
of
rules.
So
this
is
what
we're
currently
suggesting
and
the
first
one
is:
let's
have
one
hot
backup
option
that
works.
So
let's
get
a
spec
that
says
the
first
hop
by
hop
option
must
be
processed
on
the
fast
path.
G
G
Well,
we
probably
won't
get
there.
So
the
option
here
is
have
one
hot
backup
option
that
must
be
crossed
in
fast
path
and
allow
other
ones
to
be
configured
to
be
processed
as
market
as
implementation
start
to
use
this.
There
are
implications
here,
though,
so,
carry
on
listening.
If
you
can
nodes,
creating
packets
with
buy
options
should
include
a
single
one
may
include
more,
of
course,
based
on
local
configuration
and
we've
said
that
really,
if
there
are
more
than
they
shouldn't,
really
concern
you
at
the
moment,
unless
you're
configured
for
them.
G
You
can
skip
the
rest
of
the
options
without
examining
them
not
processed,
not
even
verified.
This
eliminates
some
of
the
complexity.
It's
maybe
not
quite
as
future
proof
as
we
would
like
it,
but
it's
probably
more
realistic.
It's
a
path
to
go
along,
which
is
why
we're
putting
down
in
this
particular
draft
nodes
unable
to
process
the
hot
pile
in
the
fast
path
must
treat
it
as
an
unrecognized
option.
G
G
If
you
want
to
do
something
different,
then
configure
it
as
an
explicit
configuration
and
then
you'll
be
compatible
with
what
we've
said.
The
route
for
alert
option
we've
got
is
an
exception.
This
isn't
because
we're
in
love
with
the
route
or
a
left
option,
I
don't
think
we
really
are
it's
just.
I
think
the
router
on
that
option
was
always
about
posting
on
the
slow
pack.
G
So
I
don't
think
there
is
ambiguity
here
with
this
particular
option
now
it
might
be
that
we
don't
need
the
option
at
all,
and
I
guess
that
will
be
determined
by
talking
about
it
and
figure
out.
If
anyone
really
needs
this,
but
if
you
wanted
it,
it
could
be
a
credible
exception.
I
think
to
the
must
process
on
fast
path
rule.
G
This
is
really
just
the
massage
with
respect
to
8200.
Some
things
have
to
change
and
we
paraphrased
a
little
bit
of
this
slide.
The
word
so
read
the
draft
for
exactly
the
choice
of
words.
I
had
to
crop
it
down
to
fit
it
on
the
slide
in
a
sensible
size
of
font,
but
basically
we
don't
expect
icmp
messages
to
be
sent
from
norms
on
the
path
when
this
is
not
a
supported
option.
G
Why
don't
we
expect
it?
Well,
we
know
that
many
nodes
on
the
path
already
ignore
this,
so
this
is
kind
of
like
a
futile
attempt
to
persuade
everyone
to
send
icmp
messages
and,
apart
from
the
processing
cost,
it
just
never
will
happen
with
every
node
on
the
path,
because
there
are
already
nodes
that
ignore
this
and
don't
send
you
a
message.
So
how
can
this
really
help
so
follow?
G
G
G
It's
like
through
to
alert,
and
the
current
text
says
this,
and
personally
I
don't
have
a
problem
with
this.
I've
talked
with
my
co-author
and
then
we've
put
it
into
the
id
and
we're
happy,
though,
to
listen
to
other
people
on
this
one.
I
think,
because
it's
just
exactly
the
way
it's
written
here
and
it
could
be
done,
but
do
we
really
want
to
do
this
or
has
the
day
of
roots
or
alert
gone
in
which
case
just
tell
us,
is
that
third
bob?
G
Now
we
get
to
the
kind
of
probably
important
bit,
because
all
that
was
setting
the
scene
and
new
hop
by
hop
options
if
people
are
going
to
start
using
hot,
buy
hop
options
which
we
hope
this
will
allow.
The
new
hot
buy
hop.
Options
have
to
be
designed
for
fast
path.
Processing
people
should
know
this
up
front
and
just
be
clear
about
it.
G
G
So
we've
had
this
around
for
a
while
and
we're
in
fact
we're
going
to
ask
for
wiki
group
adoption
again
in
in
six
man
as
a
update,
so
we're
gonna
ask
as
part
of
this
meeting
today
for
that
and
we've
received
some
issues.
The
most
difficult
to
answer
is
what
is
the
fast
path
or
the
slow
path?
What
is
the
control
plane
and
the
forwarding
plane?
G
This
would
be
something
we
could
easily
agree
with
just
any
one
person
in
either
of
these
two
groups,
but
getting
agreement
between
multiple
people
appears
to
be
harder,
so
we
will
take
advice
on
what
these
terms
mean,
but
I
mean
it's
clear
to
us
that
the
fast
path
is
the
right
place
to,
of
course,
hot,
by
hop
option.
G
G
There
is
implication
here
to
anyone
using
this,
because
if
you
put
two
by
hop
options
in
the
same
ipv6
packet,
the
second
one
doesn't
meet
the
criteria
of
being
the
first,
because
it's
the
second
and
it
might
not
get
through.
Therefore,
you
have
to
think
carefully
about
how
you
want
to
use
hot,
buy
hop
options
over
a
long
paths
or
what
might
happen
to
the
second
option.
G
G
G
G
Our
proposal
constrains
things,
but
it
also
places
some
requirements
on
the
expectations
from
good
equipment,
so
it
isn't
to
change
to
the
ipv6
base.
Spec,
it's
not
a
requirement
to
implement,
but
you
won't
be
able
to
say
you
implement
this
rfc
if
it's
finally
published
unless
you
do
certain
things.
G
Some
uses
of
hot
hop
options
will
no
longer
work.
They
no
longer
work.
Now
is
the
sad
result.
Maybe
you
can't
expect
this
to
fix
the
places
where
it's
broken,
but
in
the
future
the
first
option
would
be
supported
by
equipment
that
meets
the
spec
and
the
second
option.
Well,
that
may
or
may
not
be
processed.
G
These
aren't
specific
options
to
our
specific
issues
to
our
proposal,
any
application
or
service
that
uses
hot
help.
Options
need
to
work.
Even
if
no
packets
are
delivered
with
these
options-
and
there
may
be
some
merit-
it's
not
our
assertion
either
way,
but
there
may
be
some
merit
on
limiting
the
number
of
extension
headers
on
the
size
of
extension,
headers
or
constraining
them
to
be
fixed
sizes
so
that
they
are
easier
to
implement.
G
So
these
are
not
specific
to
this
proposals,
but
they
are
things
that
people
might
have
opinions
from
which
might
influence
the
way.
This
actually
evolves.
Next
slide
next
steps,
we
have
feedback,
we
have
editorial
comments,
they're,
wonderful
and
the
more
comments
we
get
the
clearer
we
understand,
at
least
at
the
moment.
G
Every
set
of
issues
that
are
well
articulated
really
helps
us
understand
what
decisions
to
make
so
is
there
interest
in
this?
The
current
state
we
really
think
is
not
tenable.
We
have
something
specified,
that's
kind
of
fuzzy.
It
can
be
a
problem,
it
might
never
be
used.
So
let's
try
and
pin
it
down
a
little
bit
more
into
something
more
useful.
B
The
only
only
thing
I
want
to
add
to
this
is,
and
there's
been
a
discussion
of
this
in
the
chat,
but
there
clearly
needs
to
be
hop.
I
hop
options
that
have
a
compelling
use
case
that
would
cause
them
to
be
implemented
widely
having
options
which
people
don't
want
to
support
doesn't
help
this.
That's
we
well.
Our
personal
opinion
is
that
the
path
mtu
one
is
maybe
a
good
example
of
something
that
is.
A
And
I
suppose
we
will
do
the
discussion
at
the
end
and
come
back
to
to
this
and
toms
draft
yeah.
I
see
ron
nodding
super,
so
tom
herbert
you
are
next.
A
H
Are
seeing
it
go
ahead,
tom
awesome,
so
my
name
is
tom
herbert
I'm
going
to
talk
about
limits
on
ipv6
or
not
our
ipv36
extension
header.
So
this
is
a
draft
in
I
proposed
in
six
man.
It's
not
a
working
group
draft
at
this
point.
H
So
the
overview,
so
we
already
know
that
support
for
ipv6
extension
headers
is
underwhelming,
so
this
is
a
little
more
general
than
just
hop.
By
help
options,
I
will
cover
ipv6
extension
headers
in
general.
The
major
reason
tlvs
are
hard
to
process
and
variable
length.
Headers
are
hard
to
process
in
hardware,
so
it's
already
been
covered.
H
I
believe
the
problem,
though
one
of
the
things
that
exacerbated
it
was
there
are
a
few
limits
to
the
usage
of
extension
headers
so,
for
instance,
in
rc
8200,
the
only
limit
for
the
number
of
extension
headers
or
even
the
the
size
of
an
extension
had
a
renal
limit
for
the
number
of
options
and
hop
by
help
options
or
size
and
extension
header
is
the
mtu
of
the
packet.
H
So
you
could
actually
put
like
three
or
four
hundred
unknown
hop
by
hop
options
in
a
single
packet
and
obviously,
if
a
router
or
even
an
end
host
tries
to
process
that
it's
going
to
take
a
long
time
and
clearly,
the
only
purpose
of
putting
300
options
in
a
single
packet
is
not
denial
of
service.
So
I
believe
we
need
to
limit
them,
and
you
know
considering
the
last
talk.
H
This
is
a
little
more
general
limits,
so
the
idea
is,
we
want
to
specify
a
set
of
limits
for
both
sending
and
receiving
extension
headers.
H
There
are
various
types
of
limits,
so
one
of
the
limits
is
on
processing
of
extension
headers.
So
basically,
this
would
be
the
number
of
extension
headers.
The
number
of
options
within
hop.
I
hop
or
destination
options
the
length
of
options,
so
all
the
parameters
with
regards
to
variables
of
extension,
headers.
That
would
be
one
set
of
limits,
another
one
which
actually
a
little
more
insidious-
and
there
was
a
little
bit
of
discussion
on
this
in
the
chat.
H
It's
mostly
an
implicit
requirement.
Now
that
routers
have
to
be
able
to
read
transport
header
information,
particularly
transport
layer,
ports
in
order
to
be
able
to
filter
and
even
route
packets,
it's
obviously
nowhere
in
any
of
the
standards.
Do
we
specify
that
routers
have
to
do
that?
In
fact,
the
standard
probably
says
they're
not
supposed
to
they're
supposed
to
be
able
to
route
solely
based
on
the
ipv6
header.
However,
in
reality
we
know
this
is
is
really
not
true.
H
There
are
a
lot
of
devices
out
there
that
have
to
read
the
layer,
four
header,
which
means
basically,
when
they
implement
this
as
a
in
a
device.
Usually
it's
a
parsing
buffer,
so
they
have
a
fixed
amount
of
data
of
packet
headers
that
they
load
in
to
the
fast
path,
processing,
64,
bytes,
128,
bytes,
256
bytes.
H
If
we
put
a
lot
of
headers
in
the
packet
extension
headers
and
potentially
even
other
encapsulations
ipsec,
what
have
you
if
there's
too
many
of
those
it
pushes
the
transport
layer
header
down,
and
if
the
device
can't
reach
that
far
into
the
packet,
some
of
the
some
of
the
devices
will
actually
drop
it.
So
this
is
a
little
more
difficult
of
a
problem
and
the
only
way
to
really
solve
it
is
to
actually
limit
the
number
of
bytes
of
headers.
H
So
that's
the
motivation
for
this
limit
limits
also
apply
both
to
senders
and
receivers,
but
we
won't
do
want
to
adhere
to
the
canonical
robustness
principle,
for
that
so
be
conservative.
From
what
you're
saying
liberal
and
what
you
receive.
H
So
the
way
we
design
the
giraffe
is
default,
sending
limits.
So
by
default
we
mean
a
host,
that's
sending
extension
headers
unless
it
knows
that
it
can
exceed
this
these
limits.
These
are
what
it's
limited:
to
send
and
I'll
get
back
to
a
minute
how
we
might
have
al
our
priority
knowledge
of
what
we
can
send
into
the
internet
and
the
limits
are
specified
in
the
draft
and
we'll
go
over
them
in
detail.
H
We
limit
eh
to
a
certain
size.
We
also
have
to
consider
padding
options.
H
This
is
already
in
some
of
the
rfcs,
but
we
limit
number
of
padding
options
to
some
logical
number,
similarly,
data
length
and
have
a
limit,
and
that
last
one
is
actually
the
limit
on
extension,
header
length
that
I
referred
to
full
chaining
receiving
limits
same
thing,
but
the
difference
is
receiving
limits.
They
are
optional.
H
So
obviously
a
host
can
receive
all
hop
by
hop
options,
all
destination
options
or
a
router
can.
But
if
someone
so
desires,
they
can
put
limits
on
these.
The
default
limits,
for
instance,
your
doc
number
of
destination
options
or
helping
options,
would
be
eight
and
again
there's
default
limits.
On
paddling
and
the
ipv6
extension
header
length,
so
the
question
is
what
happens
when
a
limit
is
exceeded,
and
this
is
kind
of
important
because
it
defines
the
behavior
and
we
really
divide
this
into
two
classes.
H
So
one
is
end
host
that
are
receiving
packets
and
intermediate
devices
general
with
them,
as
intermediate
devices
should
not
drop
just
because
at
a
limit
like
this
was
exceeded,
and
it's
pretty
easy.
Rc
8200,
for
instance,
already
mentions
that
packets
should
not
be
dropped,
they
should
be
extension,
headers
should
be
or
hubba
help
options
can
be
ignored.
H
So
we
do
extend
that
a
little
bit
to
allow
intermediate
nodes
to
ignore
some
subset
of
hop.
I
hop
options
so
basically
an
ironman
could
process
the
first
say:
eight
hop
by
hop
options
and
then
ignore
the
rest.
So
that
is
a
little
bit
different
requirement
than
rc-8200
and
hosts,
though
pretty
much
expect
it
to
process
all
the
options
and
perform
the
correct
behavior.
H
H
H
The
sender,
as
I
mentioned,
its
limits
are
defaults.
If
it
wants
to
exceed
those,
it
has
to
know
that
it's
safe
to
do
so.
The
question
is:
how
do
you
obtain
that
knowledge,
so
this
actually
came
up
in
the
last
ietf.
When
I
presented
the
obvious
one
is
if
we're
sending
within
a
limited
domain
limited
domain,
we
would
know
this
information
so
static
configuration.
H
This
is
probably
going
to
be
the
most
prevalent
use
case
for
hop
by
health
options.
Anyways
that
seems
like
it
should
work
pretty
well
more
advanced.
We
could
do
some
sort
of
probing
similar
to
happy
eyeballs,
so
the
idea
would
be
send
packets
exceeding
the
limits.
If
you
see
responses
come
back,
it's
fine,
if
not
fall
back
and
send
packets
that
don't
exceed
the
limit.
H
We
can
actually
extrapolate.
This
proving
could
be
used
to.
You
know,
for
instance,
create
a
database
that
map
source
to
destination
and
it's
more
than
just
extension
headers.
We
could
actually
apply
this
to
any
sort
of
advanced
features
like
new
protocol
transport
protocols,
but
I
don't
think
the
draft
is
going
to.
We
want
to
go
into
this
on
the
draft.
It's
probably
a
little
battle
scope,
but
we'll
probably
mention
that
in
a
future,
revision
did
want
to
touch
on
the
pragmatics
and
the
implementation.
I
think
there
was
some
discussion
previously
on
this.
H
The
way
to
look
at
this
is
because
of
tlv's
are
inherently
a
serialized
construct,
so
we
have
to
process
them
in
order.
So
if
there's
five
tlvs
and
their
variable
length,
we
have
to
process
the
first
one,
the
second
one
and
the
third
one
if
we
want
to
get
to
the
fourth
one.
H
So
this
is
why
it's
a
pretty
difficult
thing:
it's
really
hard
to
get
out
of
the
serialized
nature
of
that
and
the
variable
length
nature
without
specifying
that
either
tlvs
have
a
fixed
order
or
ver
fixed
length,
but
presuming
that
we
don't
want
to
do
that.
This
is
kind
of
what
the
canonical
loop
that
implements
tlvs
would
look
like,
and
in
this
case
basically,
we
assume
that
this
is
the
standard
two
byte
tlv
header,
so
the
first
byte
is
the
type.
Second
byte
is
the
offs
the
data
length.
H
So
we
look
at
first
byte,
I
included
at
the
end
of
list,
which
obviously
is
not
applicable
to
hot,
by
hop
and
destination
options,
but,
for
instance,
for
tlv
option
or
a
tcp
would
be.
I
believe
so
we
add
that
so
end
of
list
just
means:
stop
prospection
processing
get
out
of
the
loop
pad
one
one
byte
padding,
usually
that's
zero
type.
H
In
that
case
we
just
skip
over
it
and
then,
if
it's
not
one
or
if
it's
not
a
single
byte
type,
it's
everything
else.
So
we
have
to
check.
Do
we
have
at
least
two
bytes
of
length
left
so
by
the
way
that
the
while
loop
is
doing
a
while
loop
over
the
length
of
the
tlv
area,
and
we
have
an
offset
that's
kind
of
a
pointer
into
that
area.
So
once
the
offset
reaches
the
end
of
the
area,
the
tlb
processing
is
done.
H
H
Look
at
the
tlv
length,
which
I,
as
I
mentioned,
is
the
second
pipe
and
with
the
tlv
length
we
now
know
what
the
type
is.
The
tlv
length
is,
if
it's
pad
in
meaning
it's
multi-byte
padding
we'll
handle
that
separately.
But
if
it's
not
pad
in
then
usually
we'll
do
some
sort
of
lookup
or
switch
on
the
type,
and
that
will
return
some
sort
of
handler
call
into
the
handler.
H
And
if
the
handler
is
okay,
we
proceed
so
at
the
end
of
the
loop
we
adjust
the
offset
by
the
tlv
length,
so
all
tlv
loops,
pretty
much
are
going
to
look
like
that
and
if
we
have
the
limits-
and
this
is
where
they
would
be
applied,
so
the
limits
on
the
extension
header
chain,
the
size
of
the
extension
header
number
of
extension
headers.
This
would
be
applied
before
such
a
loop.
But
everything
else.
The
limit
for
number
of
options
that
we're
willing
to
process
would
be
probably
the
head
of
the
while
loop.
H
There
would
be
limits
on
padding,
so
we
have
to
consider
both
pad
1
and
pad
n.
There
will
be
limits
on
option
length
that
would
be
applied
when
we
have
variable
length
option,
and
then
we
also
want
to
consider
limits
on
non-padding
options.
So
if
you
put
this
in
basically
what
it
results
in
is
more
conditionals
in
the
data
path.
H
So
if
you
look
at
this
from
a
very
high
level,
what
we
really
can
do
is
consider
this
a
parameterized
function.
So
the
parameters
to
this
dlv
loop
are
pad
one
value.
The
patent
value,
el
eol
type
values
the
tlv
table
is
that
lookup
table
that
matches
type
to
a
handler,
and
then
the
various
limits
could
also
be
parameterized.
H
Even
a
hardware
function
that
implements
tlvs
to
the
extent
that
we
can't
eliminate
the
serialized
part
of
the
while
loop,
but
we
could,
for
instance,
do
some
parallelism
inside
the
handlers
and
all
the
checks
and
the
accounting
could
be
done
pretty
efficiently
in
a
hardware
block,
and
in
fact
that's
what
my
day
job
is
now
is
working
on
this
problem.
H
So
this
draft
I
proposed
a
while
back
I'm
very
interested
in
feedback
whether
or
not
we
should
proceed
with
working
group
adoption,
but
I
guess
it's
probably
part
of
the
larger
discussion
today,
so
we
can
make
that
part
of
it
and
that's
it.
Thank
you.
A
Excellent,
thank
you
very
much
tom,
so
we'll
get
back
to
both
toms
draft
and
and
bob
and
gory's
and
then,
but
first
now,
we'll
we'll
do
a
set
of
example,
use
cases
for
the
hope.
I
hope
option.
I
believe
bob
and
gory.
You
are
up
first.
C
A
quick
note,
these
use
case
talks
are
strict
limit
of
five
minutes.
Each.
G
I've
got
no
audio
from
both,
so
I
think
that
means
me
yes,
okay,
so
this
is
the
ipv6
movement
path,
ntu
hot,
by
hop
option.
If
you
can
pass
the
title
slide,
then
you
probably
already
figured
out
what
this
is
going
to
do.
But
let's
move
forward
next
slide.
Please.
G
G
G
I
think-
and
basically
this
is
a
method
where
you
send
a
packet
as
a
probe,
usually
a
sacrificial
probe
through
the
path,
and
if
that
probe
happens
to
not
be
delivered,
then
you
don't
know
that
that
size
of
packet
gets
through
if
that
pro
packet,
which
carries
no
useful
data
apart
from
padding
information,
perhaps
or
maybe
a
time
stamp
gets
through
to
the
other
end.
And
you
get
a
reply,
you
know
that
that
particular
size
of
packet
is
deliverable
across
the
path.
G
G
G
If
you
include
this
in
your
packet
and
the
router
helps
you,
it
will
fill
in
the
minimum
path
mtu
in
the
forward
direction.
Transfer
this
all
the
way
to
the
remote
node
at
the
res
look
at
the
destination,
and
that
will
return
the
return
path
mtu
back
to
you.
So
you
discover
what
the
routers
are
telling
you
along
the
path.
G
Obviously
not
all
routers
will
do
this,
and
many
ethernet
switches
will
simply
ignore
this,
because
that's
what
ethernet
switches
do
and
all
of
these
can
be
configured
with
a
path
to
you.
So
it
doesn't
actually
tell
you
concrete
information,
but
it
really
does
give
you
some
information
which
would
help
you
very
quickly
determine
what
your
path
supports
and
to
discover
when
that
configuration
change
needs
to
happen,
because
somebody
brought
up
a
link.
That's
got
a
different
mtu
next
slide,
please.
G
The
operation
we've
already
mentioned
is
as
a
way
of
figuring
out
how
routers,
along
the
path
are
configured
or
what
mtu
they
might
use,
and
you
could
then
simply
probe
props
to
check
that
that
works,
or
you
might
simply
believe
it
and
see
if
your
traffic
gets
black
told
either
way
you
could
discover
very
rapidly
if
some
of
the
routers
are
configured
with
different
mtu's
along
your
path
and
therefore
choose
a
suitably
big
one.
Next
slide,
the
status
says
that
this
we
think,
is
a
finished
document.
G
So
we've
asked
for
working
group
last
call
in
six
that's
been
processed.
It's
now
gone
to
the
iesg
as
an
experimental
spec,
which
we
believe
is
harmless
to
add
to
your
router
configuration
and
can
actually
offer
useful
benefit
if
routers
start
to
update
this
information
and
hosts
can
start
sending
it.
So
we
think
this
is
a
good
example
of
how
you
can
use
a
hot,
buy
hub
options,
header
and
it
doesn't
have
to
be
sprouted
by
every
router
on
the
path
to
gain
utility.
A
A
E
Yeah,
can
you
that's
better?
E
E
There
you
have
the
slides,
I
believe,
okay,
yeah,
please
go
ahead.
Oh
thank
you.
Everyone
yeah
I've
been
looking
at
discussions.
I
find
many
people
think
that
ioam
will
be
an
important
use
case
for
the
ipv6,
so
there'll
be
some
proposals
ready
to
actually
support
iom
using
the
hbh
extension
header
option,
but
there
there
were
some
issues
for
this
kind
of
proposal.
E
Iom
is
a
tree
option
does
need
to
perform
processing.
So
that's
why
the
natural
place
to
host
it
is
in
the
ipv6
extension
header,
but
by
the
rfc
ipv6
hope
I
hope.
Extension
header
must
also
be
the
first
extension
header
in
the,
and
there
are
two
issues
about
iom
trees.
E
One
is
that
the
overhead
can
be
very
large
because
it
included
those
instruction
header
and
the
trace
data
collected
at
each
hub
and
also
due
to
this.
The
data
collection,
the
the
header
side,
might
change
at
each
hop
makes
a
header
arrival
lens.
E
Also,
since
the
overhead
is
very
large,
it
can
make
it
very
difficult
to
access
the
subsequent
extension
headers,
because
many
many
routers
has
this
hardware
limitation
on
the
header
buffer
size.
E
E
So
there
are
some
possible
solutions
to
this.
The
first
one
is
iom.
We
can
basically
separate
the
instruction
part
and
the
data
part
and
since
the
header
part,
is
a
fixed
size,
so
we
can
put
it
in
the
still
put
it
in
the
hbh2
header
and
we
postpose
the
data
part
in
the
some
later
extend
header
after
the
routing
header.
E
So
but
the
issue
of
this
solution
is
that
we
need
to
determine
where
to
actually
put
the
data.
Do
we
really
need
to
design
new
extension
header
for
that
or
put
it
in
some
material
ways
on
some
other
existing
extension
headers?
E
So
the
second
solution
is,
we
can
use
some
concept
of
called
segment
iom
export.
There
are
two
basically
pro
approaches
in
the
context
of
srv6.
We
can
enforce
that.
We
will
export
the
collected,
the
iom
data
so
far
only
and
the
answer
each
srv6
node,
which
means
at
that
place.
We
will
first
clear
all
the
data
collected
so
far
up
now
and
then
keeps
a
hph
header,
less
short.
E
So
therefore
we
can
easily
access
srh,
but
this
is
only
applicable
to
the
srv6
and
in
general
case
ipv6
network
case
we
can
deploy.
Basically,
we
can
limit
the
size
of
iom,
header
or
head,
which
means
the
number
of
hubs
we
can
collect
the
data
once
we
reach
that
limit.
We
will
export
data
and
clear
the
data
path
and
start
over
again
to
then,
then
we
can
use
this.
We
can
keep
the
header
size
fixed,
the
third.
We
can
use
a
iom
direct
export
option,
which
means
there's
is
a
postcard
based.
E
We
don't
collect
data
in
the
in
the
in
the
header.
Only
only
we
directly
export
state
out
of
the
falling
plane,
so
the
packet
header
side
will
be
fixed.
So
in
the
unit
next
slice,
please.
E
Yeah,
you
know
in
the
draft
to
be
these
several
options
with
the
pros
and
cons
for
each
and
the
next
next
slides
please.
E
So
we
would
like
the
working
group
to
reach
consensus
on
the
proposed
recommendation,
and
that's
so
you
can
develop
the
complete
solution
if
any
change
and
update
to
existing
standard
draft
is
needed.
Thank
you
very
much.
A
Thank
you
and
chi
dong.
I
believe
you're
up
next.
Why
don't?
I
just
share
the
slides
so
we'll
move
on
a
little
quicker.
I
I
I
A
So
and
then
you
can
see
if
you
can
figure
it
out
and
come
back
to
us
so
guiseppi.
Do
you
wanna.
I
can.
D
A
A
F
Okay
yeah:
this
is
just
few
words
about
another
hobby
op
use
cases
that
is
the
alternate
marking
application
for
fpv6.
So
next
slide.
F
Yeah
just
few
words
about
what
is
the
alternate
marking
is
annoying
passive
performance
measurement
technique
that
allowed
the
measurement
packet
loss
by
switching
the
value
of
a
bit
called
plus
flag,
and
there
is
also
another
bit
called
delay
flag
to
create
a
new
set
of
packets
that
can
be
used
for
delay.
F
There
is
also
another
extension
of
this
alternate
marking
methodology
that
is
called
multi-point
methodology.
F
So
how
we,
how
do
we
apply
this
methodology
in
1986,
we
defined
in
general
new
options
that
can
be
encoded
as
of
by
op
or
as
a
destination
option.
Now
we
are
talking
about
top
by
op,
so
focus
on
the
home
bioptics
case,
and
you
see
that
the
options
is
the
same.
F
There
are
two
flags,
the
loss
and
delay
flag
that
I
have
explained
in
the
previous
slide,
and
then
we
have
the
flow
monitor
identification
field
that
is
required
for
several
reasons,
for
identification
to
allow
easy
collection
of
data
and
to
also
in
combination
with
source
and
destination,
address,
to
select
the
the
the
flow
to
be
monitored,
how
it
works.
The
source.
F
Node
is
the
only
one
that
writes
the
option
adder
to
mark
the
flow
for
bottle
by
open
destination
option
in
case
of
bob
by
up
the
option
adder,
it
can
only
be
read
by
the
intermediate
nodes
if
they
are
configured
to
do
so,
and
the
measurement
is
of
bio
in
case
of
definition
option.
Of
course
the
measurement
is
then
one
in
the
entrance
next
slide.
F
F
Okay,
thank
you
yeah
and
the
the
draft
address
the
hobby
op
use
case
consideration
and
in
particular
the
opeyop
option,
allow,
as
I
said,
measurement
on
every
router
if
the
feature
is
enabled
in
particular,
because
in
many
cases
end-to-end
measurement
is
not
enough,
so
we
want
to
monitor
hobbyop
nodes,
of
course,
examine
and
process.
The
objective
are
configured
to
do
so.
This
is
based
on
rfc8200
and
the
nodes
that
don't
support
or
biops
should
should
ignore
them.
F
So
in
this
case
the
measurement
does
not
account
for
all
lincoln's
nodes
and
along
the
path,
but
this
is
not.
This
is
not
a
big
problem
because,
as
I
said,
the
intermediate
nodes
don't
have
to
handle
to
modify
this
option
on
the
fly,
so
they
only
need
to
read
so
if
they
support
or
not,
this
will
not
affect
the
performance
measurement.
So,
of
course
we
in
the
draft.
F
We
also
highlighted
that
this
opt-by-op
option
is
designed
to
minimize
impacts
bottom
nodes
that
do
not
recognize
this
option
and
on
nodes
that
support
this
option,
because
the
three
high
order
bits
are
all
zero,
and
this
means
in
theory
that
you
have
to
skip.
If
you
don't
recognize
and
data
do
not
change
your
group.
F
In
addition,
one
of
the
preconditions
for
the
application
of
this
methodology
is
the
controller
domain
limitation,
and
this
should
also
avoid
the
risk
of
arbitrary
nodes,
dropping
packets
without
buyout
option
anyway.
In
practice,
we
know
that
the
things
may
be
different,
the
implementation,
and
it
can
happen
that
packets
without
biops
are
forced
onto
the
low
part
next
slide.
That
is
also
the
final
slide,
so
in
summary
of
it
is
desirable
to
modify
the
job
bioprocessing
to
make
hobbyop
options
more
practical,
also
to
allow
further
users,
including
ultimate
market
talent.
A
Thank
you
guys,
excellent,
so
gee,
let's
see
if
we
can
get
you
back
on
again,
okay
hear
me:
we
can
hear
you.
It
sounds
better
now.
I
Okay
good,
so
this
is
another
use
case
of
the
ipv6
hubba
hub
extension
header
to
use
it
to
carry
the
waiting
identifier.
Okay,
next
slide,
please
so.
Here's
the
background,
a
vtn
is
a
virtual
underlay
network
consisting
of
a
set
of
dedicated
or
shared
network
resources,
and
it
is
associated
with
a
customized,
logical
topology.
I
I
Please
read
the
draft
and
this
draft,
and
also
the
in-hand
vpn
draft
in
case
working
group
and
the
identifier
of
the
vtn
needs
to
be
carried
in
the
data
packet
and
passed
by
each
hub
along
the
forwarding
path
so
that
it
can
be
used
to
steer
the
package
to
use
the
set
of
resources
allocated
to
the
vtm
for
the
processing,
so
that
we
think
the
harbor
hub
extension
header
is
the
suitable
approach
for
this
case,
and
this
document
proposed
a
new
up
harbour
hub
option
to
carry
this
waiting
information
next
slide.
Please.
I
So
here
is
the
proposal.
We
propose
to
define
a
new
option
type
for
the
written
resource,
identifier
in
the
hubble
hub
header.
I
The
first
two
bits
are
set
to
zero
so
that
it
can
be
escaped
when
and
recognized,
and
the
third
bit
is
set
to
zero
to
so
that
it
will
not
change
in
the
route
and
then
there's
a
four
octet
within
resource
id,
which
is
used
to
uniquely
identify
the
set
of
resources
allocated
to
the
vtn
and
the
follow
the
procedures
in
the
network.
Basically,
the
ingress
node
should
encapsulate
an
outer
ipv6
header
and
the
hubble
hub
header.
I
I
We
know
that,
according
to
the
rfc8200
network,
nodes
may
be
configured
to
ignore
the
hover
hub
header
and
there
can
be
implementations
to
draw
packets
due
to
the
harbor
hub
header
and
luckily
the
other
half
processing
draft
is
working
on
the
pro
solutions
to
solve
this
problem
and
would
like
to
see
that
throughout
making
progress
at
the
same
time,
operators
before
we
have
this
mechanism
ready
operators
need
to
make
sure
that
when
they
use
the
vt
mechanism,
all
the
natural
nodes
involved
in
can
either
process
the
hobby
hub
header
in
fastpass
or
ignore
the
hub
header.
I
So
that's
all
I
want
to
introduce
at
the
use
case
to
this
world
working
group
and
by
the
way
we
have
a
request
for
the
adoption
call
in
the
second
working
group.
Thank
you.
C
Okay,
we
have
two
sets
of
questions
of
this
set
and
this
set
so,
let's,
let's
open
the
queue
for
anyone
who
wants
to
address
any
of
these
questions.
K
Okay,
fine
for
all
solutions
which
I
have
heard
not
just
today,
but
in
the
mail
alias
too,
I
could
classify
as
a
three
type
of
solutions.
From
my
point
of
view,
the
type
of
solution
number
one
is:
let's
we
enforce
people
to
use
at
least
one
here,
or
at
least
one
option-
it's
at
least
something
yeah.
It's
an
enforcement.
I
don't
believe
it's
possible
to
enforce
from
atf
it's
possible
to
enforce
people.
K
If
people
does
not
have
business
case,
they
will
still
continue
to
filter
out
all
this
doesn't
matter
that
particularly
rfc
will
tell
okay,
you
must
and
then
atf
would
would
have
not
a
good
look,
because
itf
has
asked
should
master
whatever,
but
people
will
still
ignore.
It's,
not
not
a
pleasant
situation
for
atf.
K
Therefore,
enforcement
from
my
point
of
view
is
not
a
good
idea.
The
second
type
of
solution
solutions
which
I
have
seen
a
lot.
It's
restrict
something
by
numbers.
For
example,
I'll
tell
people,
okay,
you
will
not
have
more
than
three
headers
off
and
then
three
options,
whatever
restrictions
but
sorry
how
it
could
help.
If
currently,
people
does
not
have
even
business
case
even
for
one
option.
K
For
example,
they
don't
support
even
one,
and
you
tell
them
okay,
you
will
not
have
in
the
future
more
than
three
will
it
help,
of
course
not
because
they
don't
want
even
one.
But
it's
it's
a
bad
thing
for
the
future,
because
if,
in
the
future
we
will
need
to
some
protocol
expansion
and
this
restriction
could
could
limit
us
on
the
future.
Therefore,
I
am
against
any
restriction,
doesn't
matter
which,
one
as
soon
as
you
will
put
okay,
let's
restrict
by
number
of
headers
by
size
of
option
itself
by
whatever
any
restrictions.
It's
not.
K
It
looks
like
good
because
because
we
could
not
even
start
first
option
and
the
third
type
of
solution
which
I
have
seen
today,
not
just
today
that
change
somehow
architecture
principally
tell
something.
Okay,
for
example,
let's
classify
some
options
as
a
soft
soft
options
which
will
go
to
control,
plane
and
other
options
as
a
hardware.
Options
which
will
go
should
be
in
the
data
plane.
Okay,
this
is
not
numbered.
This
is
something
some
principle
change
for
such
things,
I'm
supportive,
I
believe
it's
probably
may
try
probably
make
sense
to
try.
K
Probably
it
will
not
help
anyway.
From
my
point
of
view,
because
I
have
a
discussion
in
the
chat
in
the
chat
that
there
is
no
business
case
as
soon
as
business
case
will
will
be
visible
immediately.
Everything
will
be
fixed,
no
problem,
but
we
could
try
this
because,
for
example,
this
particular
solution,
soft
and
hard,
a
separation
and
some
something
principle
principle
change
how
how
mechanics
operate
some
architecture
change
this
one.
I
support.
H
Back
to
something
that
was
in
the,
I
believe
it's
bob's
draft,
so
you
mentioned
that
rfc
8200.
When
we
made
that
change
it
didn't
have
an
impact.
Do
we
have
data
or
some
information
that
that's
true.
B
B
C
C
The
default
behavior
for
most
routers
is
to
punch
to
the
control
plane.
It
can
be
configured.
A
router
can
be
configured
to
drop
a
packet
that
contains
hph
and
recently
I
know
of
at
least
one
vendor
that
has
a
new
switch.
That
says,
ignore
the
hph
pass,
the
packet,
don't
punt,
it
don't
drop
it.
H
That's
the
preferred
behavior
is
would
be
to
ignore,
as
opposed
to
punt.
So
I
I
don't
know
if
we
need
to
maybe
have
another
document
on
that
best
practices
or
something
that,
but
I
think
that
would
be
a
big
thing
that
that's
a
lot
of
the
problem.
If
we
could
just
have
router
vendors
ignore
instead
of
drop
that
would
get
us
halfway.
I
think
to
the
solving
the
problem.
L
Thank
you.
I
wanted
to
say
that
the
hub
by
hub
is
already
used
very
successfully
in
the
iut
in
the
context
of
report
networks
and
the
hobbyhop
header
has
to
be
looked
at
by
every
node.
L
It
contains
topology
information
which
is
very
similar
to
the
vtn,
and
it
also
contains
loop
avoidance
information
because
ripple
is
reactive
in
fixing
the
routing
just
to
save
energy,
so
that
that's
one
thing
so
very
successful,
very
useful
and
the
other
one
is
is
we
have
yet
another
use
case
for
hub
by
hub
in
the
context
of
that
net.
In
this
case,
we
are
not
signaling
a
topology.
L
M
Oh
good,
okay,
so,
first
of
all
thank
you
and
thanks
to
chairs
for
arranging
this
dedicated
session
for
this
harbor
hub.
So
we
could
discuss
and
seek
the
the
proper
solutions,
and
there
are
some
use
cases
as
just
presented
by
the
several
colleagues
here-
and
this
is
the
hobby
hub
is
the
is
a
real
problem
and
we
could
say
it's
a.
It
is
a
headache
for
the
operators
you
could
see
from
the
hour
basics
of
the
the
the
draft.
M
There
are
three
operators
that
was
actually
asked
by
the
operators
they
want
to
solve
it.
They
want
to
actually
use
the
hub
options
headers
and
currently
they
just
they
have
to
block
it,
and
currently
we
are
seeking
the
solutions,
as
progressed
in
bob's
draft,
which
is
good
but
and
also
you
hear
there
are
some
questions
you
listed
here.
M
M
So
once
we
have
the
solution,
we
still
will
have
to
consider
how
to
actually
use
it
so
to
do
like
a
make
it
really
usable
in
the
real
network
and
how
to
make
the
hubba
hub
coexist
with
I
mean
the
new
new
device
which
could
support
the
hub
hub,
they
could
coexist
with
the
existing
devices.
N
Okay,
can
you
hear
me
right?
So
I'm
really
happy
to
see
this
discussion
happening,
but
at
the
same
time
I'm
a
bit
surprised
right.
There
are
definitely
people
who
want
to
make
this
work,
so
I
see
no
reason
to
even
start
talking
about
duplication
or
not
rehabilitating
it
unless
there
are
proof
that
it's
dangerous
right,
so
I
think
yeah.
We
should
keep
exploring
options
on
how
we
can
make
those
things
useful
about,
and
I
believe
nobody
gonna
enable
proper
processing
across
the
internet
until
we
find
a
compelling
use
case
right.
O
So
I
strongly
support
to
move
the
world
forward
to
find
some
like
a
good
solution
of
hobbyhop.
O
I
I
support
the
work
of
hgbh
and
I
think
it
should
proceed,
and
that
means
that
we
should
rehabilitate
hebe's
work.
It
behaves
open
headers
because
it
can
support
lam,
mtid
and
the
pmto
options.
Another
function,
frank,
speak.
I
don't
think
the
service.
Is
there
some
functions
of
network,
so
I
don't
think
they
are
services,
and
another
issue
is
that
about
the
current
status
of
backup
options.
I
Frankly
speaking,
the
hope
option
has
not
been
widely
used
by
operator,
but
this
does
not
mean
that
the
operators
oppose
a
backup
option
because
they
don't
know
how
to
use
backup
options,
because
this
is
a
new
thing
right.
So
so
I
give
the
support
to
this
work
and
also
about
the
documents.
I
think
we
should
make
a
draft
about
the
requirements
of
each
beach.
This
should
be
comprehensive.
P
Thank
you.
So
I
mean
it's
originally
going
to
save
this
for
the
end,
but
figuring
out
exactly
when
the
end
of
the
session
slash
q
is
tricky.
I
just
want
you
to
note
that
when
we'd
originally
discussed
having
this
sort
of
joint
session
and
focusing
on
h
by
sorry
processing,
we
were-
or
at
least
I
was
a
little
concerned-
how
the
session
would
go.
P
You
know,
would
everybody
actually
try
and
get
together
and
and
solve
the
problem,
or
do
we
instead
devolve
into
shouting
at
each
other,
and
I
just
want
to
know
how
really
impressed
and
happy
I
am
with
the
attitude
that
everybody's
had
and
how
well
people
have
been
sort
of
trying
to
get
together
and
recognize
the
issue
and
also
discuss
how
we
can
move
out
of
this.
So
sorry
for
the
sort
of
touchy
feely,
but
but
I'm
really
happy
with
how
this
has
been
going
so
far,.
C
I
I
think,
as
I
mentioned,
I
really
supported
the
work
on
this
hobbyhop
option.
Header,
as
we
can
see,
we
already
have
several
use
cases
or
applications
in
the
limited
domain
and
before
we
can
deploy
the
for
the
larger
domain
or
even
the
internet.
For
some
other
cases,
we
need
to
get
the
technology
ready.
We
need
to
have
this
documentation
documented
documented
in
the
itf
standards
to
guide
the
implementation
of
the
winders.
So
I
think
this
is
really
important
to
to
make
use
of
this
extensible
feature
in
the
future.
C
Okay,
I
see
the
queue
is
empty,
so
I'll
open
the
open
it
up
for
some
further
questions.
C
First,
is
oh
gee,
you're,
oh,
no,
that
you
were
just
there:
okay,
I'll
open
it
up
for
some
further
questions.
I
know
that
I've
heard
some
support
for
continuing
the
work.
I
know
we
don't
make
decisions
at
meetings.
We
make
them
on
mailing
lists,
so
chairs
will
get
together
and
figure
out
how
to
do
well.
It's
not
quite
a
call
for
adoption,
it's
a
how
to
put
out
a
decision
or
how
to
get
more
more
feedback
on
putting
out
a
decision
assuming
that
we
do
go
forward
with
the
work.
C
C
G
Yeah,
surely
we
can
look
again
at
the
list
of
hot,
buy
hop
options
and
other
options
and
find
some
dead
wood
in
there
and
bob-
and
I
started
this,
but
before
we
we
wrote
anything
because
we
wanted
to
understand
what
really
existed
and
some
of
the
stuff
doesn't
really
exist
that
we
have
in
the
rsc
series.
G
C
How
do
people
feel
about
that?
You
know
deprecating
that
one
and
shuping
you're
next
online.
C
M
Already
defined
and
but
whether
to
deprecate
I'm
a
bit,
I
just
I'm
not
sure
whether
we
we
might
make
some
trouble
on
this
and
how
to
guarantee
we
we
want
to
to
do
it
wrong.
I
mean
when
somebody
still
using
it
and
because
you
never
know-
and
that
is
my
thoughts
on
this
beta
conservative
and
regarding
the
documents
and
work.
Definitely
the
requirements
was
just
imagined
a
comment
and
in
in
our
draft
we
have
a
dedicated
section
on
these
requirements
and
we.
J
M
J
K
Is
everywhere
for
all
working
groups
that
if
you
will
try
to
understand
some
particular
problem,
for
example
in
this
case
hope
I
hope
or
whatever
you
need
to
read
basic
rfc
of
course,
and
then
you
try
to
search
and
find
all
other
rfc
which
is
related,
and
it's
really
research.
You
need
to
do
a
big
research
which
is
more
or
less
possible
to
do
for
vendor.
But,
okay,
it's
a
challenge,
but
it's
completely
not
possible
to
do
for
carrier.
K
Therefore,
for
carrying
to
understand
all
this
nuances,
so
all
these
problems
around
hope,
I
hope
it's.
It's
really
mission
is
impossible,
because
probably
he
need
to
read
a
few
a
few
dozens.
J
K
Rfc
and
it's
it's
not
what
is
his
it's,
not
his
job
on
opposite
side.
Let
me
give
you
an
example
of
what
was
going
on
in
wi-fi
alliance.
For
example,
you
know
we
finally
answered
they
develop
they're,
trying
to
incorporate
in
one
primary
document
which
they
trace
from
the
history
currently
and
as
a
result,
they
have
something
consistent,
it's
always
possible
to
take
just
one
file,
just
one
latest
document
and
read
everything.
Unfortunately,
it's
opposite
extreme,
because
in
the
case
the
last
document
is
already
more
than
5
000
pages.
K
K
It's
up
to
particular
working
group,
particular
chairs,
particular
id
that
some
particular
working
group
could
start
to
formalize
everything
properly
because,
okay,
if
you
have
some
particular
problem,
it
should
not
be
scattered
over
thous
or
the
dozens
of
rfc.
It
should
be
some
some
number
of
limited
rfc.
You
should
not
read
everything.
You
should
not
become
an
expert
to
understand.
It's
it's
a
really
big
problem
from
my
point
of
view,
it's
everywhere
and
hope
I
hope,
is
a
good
example.
Sorry,.
Q
Yeah,
let
me
first
thank
you
again
to
the
chair,
sir,
for
organizing
this
and
running
it
correctly.
Q
Q
Now
I
would
suggest
maybe
we
can
go
like
a
best
current
practice
to
not
enable
them
rather
than
deprecating
them.
That
may
be
a
little
bit
more
operational
issue
towards
a
standardization
issue
there
and,
as
the
people
say
throughout
the
alert
for
mid,
is
required
because
mld
are
sent
to
the
multicast
group
right.
So
if
you
want
to
scoop
them,
you
need
to
get
the
router
let's
to
go
to
in
the
slow
path.
So
that's
that
and
yes,
let's
continue
the
work
on
the
documents
for
sure.
C
Let
me
ask
a
question,
since
I
see
the
two
erics
in
the
line
about
what
deprecate
actually
means,
I
think
it
means
that
if
an
option
is
deprecated,
it
can
still
be
used
by
the
protocols
that
use
it.
For
instance,
router
alert
is
used
by
mldv2.
It
can
still
be
used
by
him
or
by
that
protocol,
but
new
protocols
cannot
use
it.
Does
it
mean
more
than
that.
Q
B
Jump
in
on
that
a
little
bit
yeah,
it
usually
means
what
ron
says
and
that's
like
when
we've
deprecated
other
things
we,
the
deprecation
document,
usually
defines
it
specifically
for
what
it's
deprecating,
but
usually
it
means
you.
You
know
we're
not
the
protocol
police,
it
doesn't
turn
anything
off,
but
just
don't
use
it
in
the
future
and
in
practice
it
can
never.
J
Be
reallocated
really,
I
think
I
just
want
to
say
with
respect
to
working
group
documents
and
progress
as
a
responsibility
for
six
man,
we
should
be
having
an
adoption
call
for
one
or
more
of
the
documents-
six-man
documents
you
saw
today
in
the
week
or
in
the
coming
week,
or
so
I
would
expect
up
to
the
chairs,
but
I
would
expect
to
see
one
soon,
so
I
would
encourage
everyone
to
take
the
time
to
go,
read
those
documents
and
to
make
your
comments
known
now
or
during
the
adoption
call.
P
Yeah
others,
especially
bob
largely
said
what
I'm
gonna
say:
deprecates
is
kind
of
like
updates.
Nobody
quite
knows
exactly
what
it
means,
but
when
you
deprecate
something
generally,
you
explain
what
you're
meaning
by
it
when
you
put
it
in
the
document
and
yes,
this
is
a
problem
and
everybody
knows
it's
a
problem,
but
we
haven't
solved
it
yet.
So,
oh
well,.
N
C
Does
anyone
have
any
final
comments
chairs
anyone
any
any
expected
activity
and
then,
oh,
I
see
eric
has
joined
the
eric.
J
I
wanted
to
echo
some
of
the
things
that
eric
and
warren
had
said
to
thank
all
of
you
chairs
for
putting
this
together
all
of
the
authors
and
presenters
for
taking
the
time
and
for
everyone
who
came
to
this
session
to
to
try
to
see
what
what
path
forward,
if
any,
might
might
be
made.
So
I
appreciate
everyone's
everyone's
efforts
to
try
to
figure
out
in
what
direction
we
should
all
be
pulling.
C
Yeah,
thank
you
and
chairs
any
any
comments
on
what
we
think.
Next
next
steps
are.
H
C
R
Finally,
figured
out
how
to
unmute
myself,
I
asked
tom
to
write
a
draft
for
chix
man
on
a
bcp
for
ignoring
hbh
document
options,
so.
C
C
I'm
thinking
we
probably
need
something
like
the
three
documents
we
saw
presented
at
the
beginning
of
this
session,
a
requirements,
a
solution
and
limitations,
not
quite
sure
if
limitations
and
solutions
should
be
merged
into
one
or
not,
but
I'll.
Leave
that
for
the
the
authors
to
discuss.
C
Does
anybody
think
we
need
a
document
to
look
at
house
cleaning?
You
know
deprecating,
you
know
dead
wood
and
possibly
the
router
alert.
C
R
Okay,
I
thought
I
had
unmuted
myself-
I
guess
not
anyhow,
but
but
I
would
agree
with
you
that
a
an
omnibus
draft
deprecating,
a
few
of
the
options
or
router
alerts
is
an
obvious
one.
B
C
B
And
I
also
just
got
the
mic
on
so
I
think
this
has
been
a
useful
session
to
talk
about
these
issues
all
together,
so
okay,
glory.
G
So
we
might
want
to
to
think
about
what
deprecate
really
means
for
richer
alert.
Maybe
it
means
don't
use
it
on
internet
paths,
maybe
only
use
it
for
specific
protocols
or
something
so
there's
probably
something
to
write
down
here.
I
think
that
might
be
useful.
C
C
Well,
if
that's
that,
I
thank
you
all
for
your
contributions
and
we'll
continue
to
discuss
this
on
both
mailing
lists
till
then.
I
think
it's
time
for
us
all
to
go.
Get
coffee.