►
From YouTube: IETF106-6MAN-20191121-1740
Description
6MAN meeting session at IETF106
2019/11/21 1740
https://datatracker.ietf.org/meeting/106/proceedings/
A
C
E
D
F
C
C
B
C
G
C
H
C
I
C
Okay,
so
welcome
to
the
second
six-man
session.
We
now
got
the
press
enter
for
the
first
presentation,
on
extension,
headers
Terrance,
doing
the
the
other
one,
and
then
the
plan
was
to
hold
questions
until
the
the
end
of
the
two
sessions
we
can
have
clarifying
sessions
after
after
marks
talk
and
errands.
But
then
we
can
have
a
general
discussion
on
the
topic
topic
afterwards.
Super
marking,
if
you
can't.
J
Again
later
tonight,
so
okay
in
flight
ipv6,
header
extension,
inserting
considered
harmful
boom
RFC
is
1893
and
twenty
four
sixty.
So
this
about
some
processing
of
extension,
headers
with
one
exception
extension
headers,
are
not
examined
a
process
by
any
node
along
a
packets
delivery
path
until
the
packet
reaches
a
node
identified
in
the
destination
address
field
of
the
ipv6
header.
J
The
exception
is
the
hop-by-hop
options,
header,
which
carries
information
which
me
examined
and
process
by
every
node
along
a
package.
Delivery
path,
the
hop-by-hop
options.
Header,
must
immediately
follow
the
ipv6
header,
its
presence,
indicated
by
the
value
zero
in
the
next
set
of
field.
Rfc
8200
updated
this
and
made
a
bit
more
explicit
extension.
Headers
are
not
processed
inserted
or
deleted
by
any
node
along
a
package
delivery
path
until
the
packet
reaches
the
destination
dress
and
the
hop-by-hop
options
text
was
modified
in
a
similar
way.
J
J
So
the
purpose
of
this
internet
draft
was
really
to
capture
the
and
record
the
reasons
and
motivations
for
the
1883,
24,
60
and
80
200
text,
and
also
to
describe
an
ipv6
architecture,
Allah
compliant
solution
to
define
in
in
flight
eh
insertion.
We've
got
a
packet
going
from
the
left
to
the
right
or
from
A
to
C.
It's
transiting,
Network
B
and
network
beyond
ingress
is
inserting
an
extension
header
and
then
at
egress
of
B.
Hopefully
the
extension
header
is
removed
so
that
the
original
packet
arrives
at
C.
J
Some
observations,
the
original
source
and
destination
address
of
the
packet
are
not
modified
during
insertion
and
removal
and
they
couldn't
be.
The
packets
are
being
modified
without
attribution.
So
it's
an
anonymous
modification.
The
packet
size
got
larger
and
an
immutable
next
header
field
got
modified
as
well.
J
My
speculation
is
that
because
there's
128-bit
segment,
routing
IDs
the
same
size
as
ipv6
addresses
it's
going
to
route,
it
quite
a
lot
of
overhead,
and
so
perhaps
the
idea
is
to
try
and
save
overhead
somewhere
else.
Instead
of
having
smaller
seeds,
one
quote,
which
has
been
removed,
I
think
Darren
posted
version.
Eight
of
this,
but
and
and
and
this
is
an
example
of
text
we
might
want
to
look
for
rather
than
being
specifically
one.
That's
continued.
There's
some
theory
in
the
draft.
J
J
Unfortunately,
that's
a
theoretical
statement,
rather
than
a
practical
one.
I've
experienced
all
three
of
these
things
in
my
career
implementation,
bugs
partial
device,
failures
and
device,
miss
configurations
so
that
sort
of
mass
desertion
in
a
internet
draft
or
enough
C
is
really
an
aspiration.
It's
not
assurance
it.
J
It
may
not
be
removed.
The
other
thing
to
to
observe
or
be
aware
of
is
that
these
sorts
of
boundary
devices,
and
while
the
firewall
is
not
quite
the
same,
it's
quite
common
to
have
only
a
single
instance
of
them.
I
have
actually
heard
of
somebody
having
two
NAT
devices
in
a
row.
Surprisingly,
it
was
at
their
home
and
there
was
some
information
security
person
from
Y
or
something
but
most
the
time.
In
my
experience,
there's
only
been
a
single
edge
device
performing
these
sorts
of
function
so
that
that's
really
only.
J
J
This
is
a
scenario,
and
this
is
sort
of
where,
where
my
objection
comes
from,
we
have
a
scenario
where
a
packets
traveling
across
the
internet
from
a
source
is
on
the
left.
Through
the
destination,
is
on
the
right,
the
sorceress
might
be
say,
a
video
content
provider
the
destination
is
on.
The
other
end
is
a
residential
ice.
P
and
I've
spent
quite
a
lot
of
time
at
those
as
our
packet
goes
across
the
internet,
it
traverses
a
number
of
a
SS
and
is
one
has
chosen
to
do
anonymous.
J
Eh
insertion
for
some
reason.
Rather
they
failed
to
remove
there
instead
of
the
H,
because
the
destination
address
of
the
packet
hasn't
changed,
the
packet
will
just
keep
going
to
the
destination
da
s
and
the
brokenness
would
occur
at
the
destination.
Is
the
question
then,
as
me,
is
an
operator
sitting
there
looking
at
these
packets
that
may
be
taking
five
or
ten
thousand
of
my
customers,
video
content
offline
is
who
inserted
the
H
there's
nothing
in
the
packet.
That
tells
me
that,
and
therefore
I
will
have
to
manually
or
going
brute-force
contact.
J
Every
single
is
asked
that
is.
Are
you
inserting?
A
h's
ask
them:
are
you
removing
them
and
they'll
say
no,
my
vendor
writes
perfect
code
and
I'll
say:
can
you
have
a
look
place?
It
may
even
involve
you
know,
disconnecting
hundred
gig
links
to
try
and
insert
some
sort
of
device
to
to.
You
know
capture
the
packets
to
determine
that
the
device
is
really
performing
as
it's
supposed
to
be.
The
problem
is
that
this
fault
is
only
really
seen
as
after
the
packets
left
the
network,
so
most
operators
and
I've
certainly
been
one
of
them.
J
J
The
the
classic
case
would
be
icmpv6.
So
if
the
eh
triggers
an
ICMP
mechanism
of
some
sort,
it
will,
though,
the
the
device
that
sends
the
icmpv6
message
can
only
ever
send
it
back
to
the
source
address
of
the
packet.
Well,
that's
not
the
device
that
inserted
eh.
So
it's
not
going
to
make
it
to
a
device
that
can
consult
the
issue.
J
Another
possibility
in
my
diagram
I
only
had
one
transit
network
inserting
h's,
but
imagine
if
one
of
those
other
ones
was
as
well.
If
the
first
AAS
didn't
remove
the
EH
and
it
kept
floating
along
to
a
later
transit
network
and
that
later
transit
network
was
also
using
eh
insertion,
then
the
EH
might
get
inside
that
Network
any
impact
operation.
J
Incorrect
destination
host
processing,
so
one
of
the
issues
is
that
this,
this
eh
that
was
inserted,
was
not
intended
to
be
received
by
the
device
with
the
destination
address
and
how
an
unknown
here
unknown,
eh
is
handled
is
indicated
by
the
top
two
bits
in
the
type
of
the
EH.
This
could
result
in
a
packet
that
gets
discarded,
even
though
it
would
actually
be
possible
to
skip
over
the
unknown
option
and
process
the
remainder
of
the
packet.
J
The
opposite
could
occur
as
well,
so
a
packet
could
get
I've
actually
lost,
which
order
I
did
it,
but
anyway
the
packet
could
get
processed
when
it
should
really
be
discarded
based
on
the
context
of
the
video.
So
you
know
the
application
that
it's
in
the
payload
a
packet
implementation
complexity,
if
you
think
about
it,
the
edge
device,
the
on
egress
has
to
scan
the
eh
chain,
assume
it's
possibly
not
the
first
one
to
determine
whether
there's
an
eh
there
to
remove
or
not.
J
J
Finally,
the
I
think
it's
even
as
fundamental
as
hostels,
law
or
robustness
principle,
which
says
be
conservative.
What
you
send
be
liberal
on
what
you
accept
inserted
eh
Azhar,
not
expected
by
RFC
8200
compliant
receivers
as
RFC
8200,
P
Hibbert,
some
so
purposely
sending
them
is
not
being
conservative,
I
think
the
solutions
encapsulation
it's
the
classic
way
to
add
new
information
to
an
existing
PDE.
Obviously
we
should
all
understand
and
remember:
TCP
and
caps
application,
IP
and
caps
TCP
link
layer,
caps,
IP
the
to
me.
J
The
solution
is
to
encapsulate
in
an
ipv6
tunnel
an
RFC
24
73.
The
generic
packet
tunnelling
over
ipv6
spec
actually
shows
an
example
of
adding
new
EHS
to
an
existing
packet.
After
the
new
outer
ipv6
header
and
therefore
RFC
24
73
provides
a
tradition
attribution
via
the
outer
ipv6
source,
addressed
as
an
example
of
the
benefit.
That
means
that
PMT
OD
works
because
the
the
the
tunnel
endpoint
that
increased
the
packet
size
is
identified
by
the
source
address
in
the
outer
header.
J
J
One
of
the
issues
which,
which
seems
to
be
possible
motivation,
is
to
try
and
reduce
telling
overhead
one
of
the
struggles
I
remember
dealing
with,
because
I've
done
quite
a
lot
of
work
in
the
past
with
IPSec
tunnels.
Is
this
idea
that
there's
an
IP
packet
inside
of
another
IP
packet
and
it's
sometimes
a
bit
of
a
struggle
to
sort
of
forget
that
the
payload
of
the
outer
packet
is
a?
Is
a
I
P
v6
packet
in
itself?
J
So
in
that
context,
if
we
forget
about
we
just
look
at
the
model
in
a
common
ipv6
packet,
there's
a
link
layer,
header
on
the
front,
Ethernet,
PDP,
etc
in
an
ipv6
and
ipv6
tunnel.
It's
the
same
thing.
It
just
happens
to
be
another
ipv6
header,
and
it's
coincidence
that
the
the
fields
and
the
semantics
have
the
same
meaning.
So
if
we
consider
and
remember
that
an
IP
tunnel
is
a
link
layer
link,
then
we
can
use
link
layer
compression
to
compress
the
inner
packet.
An
example
would
be
robust,
header
compression.
J
So
you
would
apply
this
on
the
inner
packets,
ipv6
header
and
possible,
either
possibly
other
headers
on
the
inner
packet
to
compress
the
effective
size
of
the
total,
something
else
that
I
worked
on
a
few
years
back,
just
as
an
idea
sort
of
triggered
by
this
was
what
I've
called
skinny
ipv6
and
ipv6
tunneling.
So
this
actually
leverages
the
fact
that
the
inner
packet
and
the
outer
packet
have
the
same
header
and
how
same
header,
semantics,
and
so
what
it
does
is
for
nearly
all
of
the
fields.
J
It
basically
makes
the
outer
header
carry
many
of
the
inner
fields,
values
and
then
disposes
of
nearly
all
of
the
inner
packet
header
effectively
and
then
reconstructs
at
the
other
end.
Another
thing
it
does
is
use
a
slash
64's
to
identify
tunnel
endpoints
rather
than
such
128
and
the
unused
IRD
parts
of
the
outer
ipv6
header
address
fields
copy
and
carry
the
inner
packets
IRD
fields.
J
K
K
K
K
K
Okay,
now
I
don't
have
to
slouch
okay,
so
this
presentation
is,
of
course,
about
segment
routing
header
insertion
within
an
SR
domain.
Okay,
there's
been
several
versions
of
this
draft
I'll
just
quickly
mention
that
the
one
that,
where
we'll
be
talking
about
a
couple
t
I,
just
updated
the
draft
yesterday
and
sent
out
the
mail
today.
K
So
you
know
we'll
of
course
talk
about
revision
7,
which
is
a
very
important
revision,
but
we've
made
some
changes
in
the
most
recent
one
and
we'll
we'll
go
over
those
too,
but
I
think
it
still
leaves
all
of
this
discussion
entirely
relevant.
So
we
can
discuss
all
the
versions
of
the
draft
in
revision.
7
we
made
the
draft
standards
tract.
We
added
a
lot
of
normative
text
to
describe
how
segment
routing
header
insertion
in
particular
is
done
within
an
SR
domain.
K
We
describe
the
insertion
process,
we
describe
the
removal
process,
we
described
icmpv6,
processing
path,
MTU
discovery
and
went
into
I.
Think
a
lot
of
good
detail
on
how
implementations
can
do
segment,
routing
header
insertion
within
an
SR
domain,
and
do
it
do
it
safely
within
that
domain.
In
order
to
provide
you
know,
different
types
of
services
within
the
domain
in
revision,
8
we've
gone
a
bit
different
way
and
in
revision,
7
and
prior
to
revision.
7.
K
There
was
a
lot
of
discussion
like
the
first
part
of
mark
slide,
where
it
was
kind
of
a
shall
not
do
segment
routing
header
insertion,
because
25
years
ago
we
wrote
some
texts,
it
said
extension
headers
aren't
inserted,
modified
or
deleted,
except
at
a
source
or
destination,
and
well
that
was
very
applicable
to
the
larger
internet.
We
are
looking
at
segment
routing
header
insertion
within
an
SR
domain
and
that's
more
limited
scope,
so
we've
done
renovation,
eight
is
we've
we've
described
now
how
deployments
and
implementations
are
doing
segment?
Routing
header
insertion?
K
Why
they're
doing
it
and
documenting
the
fact
that
it
is
done
so
that
this
community
can
understand
that
this
is
something
that's
real.
It's
happening
within
limited
domains
within
SR
domains
and
get
some
of
the
motivation
for
why
that's
happening
okay,
but
we
can
still
talk
about
both
revisions
today.
I
think
it'll
be
more
fun
that
way:
okay,
who's
deploying
this-
we
saw
some
of
this
this
morning,
so
I'll
skip
over
it
quickly.
K
Softbank
China,
Telecom,
elia,
22,
kohm,
stern
net
and
tender
ganda
are
all
deploying
sr
v6
and
it
with
SR
insertion
within
their
domains,
who's
supporting
SRH
insertion
and
removal
in
their
implementations.
You
guys
have
seen
this
in
previous
presentations
in
six-man.
I'll
highlight
custom
Asics
from
Cisco
huawei
merchants.
Silicon
Brad
gum,
Marvel
Intel,
are
spreading
the
insertion
and
removal
capability
and
some
open
source
content.
D
K
The
dots
and
the
numbers
and
style
game
so
in
this
diagram
this
this
is
out
of
this-
is
out
of
the
draft.
So
who's
read
the
draft
in
any
of
the
versions.
All
right
lots
of
people
awesome.
Ok!
So-
and
this
is
similar
to
the
SR
header
draft
as
well.
It
uses
the
same
thing
so
node
1
is
connected
to
node
3
3,
to
5
5,
to
6
6,
to
4
and
4
to
2,
ok,
nodes,
3,
5,
7,
8,
6
and
4
are
all
within
the
SR
domain.
K
Node
3
and
fours
are
essentially
pease
of
the
SR
domain.
Ingress,
egress,
p/es,
4
packets
heading
from
left
to
right,
sound,
good,
7,
&,
8
or
other
nodes
within
the
SR
domain.
All
right
they're.
Also
a
7
is
attached
to
5
7
s
attached
to
a
th,
the
6,
ok
I'm,
giving
it
as
an
example
that
there's
a
some
network
that
has
some
edge
notes
and
notes
outside
of
it,
connect
to
those
edge
nodes
and
traffic
that
traverses
the
SR
domain
gets
encapsulated
and.
K
Right
yeah,
so
let
me
let
me
clarify
that
as
well
for
a
packet
from
node
1
to
node,
2
node
3
receives
that
packet.
Note
3
encapsulates
in
an
ipv6
header
between
node
three
and
four
okay,
the
source
of
the
packet.
The
outer
IP
header
is
node.
Three.
The
destination
of
that
outer
IP
header
is
a
CID
at
node
4
and
that
packet
traverses,
node,
five,
six,
seven,
eight
etcetera
well
depending
on
its
path,
will
play
not.
Although.
K
So,
for
example,
an
operator
with
a
GU,
a
lock
of
slash,
28,
P,
P,
P,
P
P,
something
slash
28,
would
use
their
block
to
sub
allocate
a
block
of
SIDS,
so
P
P
P,
colon
B,
where
B
is
the
B,
is
the
block
of
SIDS
with
a
let's
say,
a
slash,
40,
okay
and
within
that
block
of
SIDS,
so
that
that
slash
40
identifies
all
the
sins
within
that
SR
domain.
Within
that
block
of
40,
there's,
let's
say
a
slub
slash,
64.
L
I
M
K
I
K
Thanks,
okay,
so
again
we
allocate
a
/
64
CID
locator
to
each
of
the
nodes
in
the
domain,
where
that
prefix
is,
for
example,
pb4,
for
example,
at
node
4,
so
it
node
4
receives
it,
for
example,
a
/
64
from
which
it
can
allocate
segment
IDs
for
use
at
that
node.
So
anyone
familiar
with
our
s,
our
header
document
should
remember
that
those
SIDS
are
then
used
for
different
things.
Who's
familiar
with
s,
sir
v6
network
programming,
who's
read
that
looked
at
it,
okay,
good
all
right.
K
K
The
next
part
is
in
an
how
we
protect
the
SR
domain
and,
if
you'll
remember,
the
SR
header
and
the
SR
header
draft
defines
how
we
filter
external
traffic
entering
the
domain
and
at
the
ingress
edge.
We
apply
an
ingress
ACL
that
drops
any
packets
destined
to
that
sid
block
within
the
SR
domain
and
then
on
internal
nodes.
K
Essentially
so,
there's
a
ingress
PE
at
node,
3
and
egress
P
at
node
4
and
the
ingress
PE
performs
that
ipv6
encapsulation
with
the
SID
that
will
D
capsulate.
That
outer
ipv6
header,
when
the
packet
reaches
note
4
now
that
Sid
might
be
an
N
dot,
DX
r,
n
dot,
DT
Sid.
For
those
who
don't
know
those
simply
say
forward
the
inner
packet
on
a
adjacency
or
forward
the
inner
packet
and
based
on
a
lookup
in
a
particular
v4
v6
table.
K
K
K
N
K
So
that's
more
of
a
feature
thing
I,
guess
so
in
the
products
that
I'm
aware
of
for
any
traffic
destined
via
a
node
or
a
link
that
fails.
The
repair
path
is
pre
computed
for
that
traffic
and
that
point
of
local
repair
inserts
an
SR
header
to
get
around
that
link
or
node
failure
to
the
destination
so
where
I
say
a
50,
millisecond
or
sub
50
millisecond
packet
loss,
that's
the
that's
the
the
inflammation
at
implementation
at
that
point
of
local
repair.
That's
pre
computed
this
repair
path
that
inserts
the
SR
header.
K
N
K
So
I
think
at
this
point,
in
the
middle
of
the
of
the
SR
domain,
I
don't
care
if
this
traffic
is
tunneled
I,
don't
care
that
it
is
tunnel
traffic.
All
I
care
about
is
that
this
traffic
is
destined
to
a
node,
that
I
have
protection
for
I,
protect
traffic
destined
to
any
node
in
the
network,
with
a
pre
computed
path.
That
is
going
to
get
me
any
link
or
node
failure,
for
which
I
am
the
point
of
local
repair.
K
N
K
N
K
Okay,
so
let's
go
over:
where
does
s
our
header
insertion
occur?
It
occurs
at
any
node
within
the
SR
domain.
Okay
and
that's
any
node.
That's
that
point
of
local
repair.
So
in
this
case,
where
we're
doing
TI
LFA
I
know
that
is
a
point
of
local
repair
running
supporting
TI
LFA
is
going
to
insert
that
SR
header.
Okay.
That
assertion
occurs
on
the
outer
ipv6
header,
which
is
the
one
that
that
essentially
tunnel
header
between
the
node
3
and
node
4
within
the
domain.
K
The
SR
header
removal
occurs
at
the
destination
address
in
the
in
the
outer
header,
so
that
s
our
header,
gets
inserted
and
it's
removed
at
a
node
that
the
inserting
node
decided
on
when
it
inserted
the
SR
header
so
that
destination
node
in
the
packet
receives
it
in
the
terms
of
network
programming.
He
he
pops
these
as
a
pelt,
mat
segment
pop
and
removes
the
SR
header
that
was
previously
inserted
and
the
packet
continues
on
its
journey
to
the
destination
node
within
the
domain.
C
K
C
K
I'm
asking
no,
you
don't
know
the
answer.
Is
you
don't
because
if
I
simply
encapsulate
an
odor,
I
P,
where
the
destination
address
that
IP
at
the
outer
IP
is
an
SR
v6
CID
and
that
s
our
v6
SIDS
behavior
is
2d
capsulate?
The
packet
then
will
wheelie
caps
and
I
think
that
is
actually
described
in
the
SR
header
draft
as
well.
O
K
In
in
it
depends
so,
if
that,
if
the
node
that
receives
this
packet
with
the
inserted
SR
header
is
node
4
and
the
CID
is
the
D
capsulate
said,
then
of
course,
that
entire
IP
header
is
removed.
If
the
node
that
receives
that
packet
is
another
note
prior
to
node
4
in
the
example,
then
the
removal
would
happen
at
a
node
before
node
4.
Ok,
it's
up
to
the
node
that
inserted
the
header
to
also
specify
what
the
sit
is.
B
L
So
you
say
that
on
the
on
the
back
up
and
on
the
protection
it
inserts
a
header
now
in
an
Assad
domain
that
potentially
spends
ten
thousand
kilometers
fifteen
countries,
thousands
of
links
I
want
to
clarify
what
happens.
If
I
get
a
break
here,
then
I
get
a
break
there.
I'm
gonna
get
a
break
there
and
I
get
a
break
there
and
I'm
not
running
six
breaks
deep.
Okay,
am
I
ending
up
with
six
header,
insertions
and
very,
very
large
stacks
as
a
result
or
not
I
know
they.
K
J
K
J
Yeah,
that's
not
no
so
see
where
I
would.
The
approach
I
would
take
is
that
I
would
make
three
and
five
tunnel
endpoints
and
in
five
and
six
tunnel
endpoints
and
then
six
and
for
tile
endpoints
and
those
are
then
the
opportunities
where
you
can
add
or
insert
or
remove
your
SRH
okay,
and
then
that
gives
you
the
attribution
the
source
address,
update
and
so
on.
So.
P
P
K
So
yeah
the
there's
some
there's
some
math
and
some
research-
that's
in
also
in
the
TA.
Oh,
if
they
drop
saying
what
with
the
typical
or
maximum
size
this
would
be
for
those
inserted,
sits,
yeah.
Yes,
so
I
think
this
is
a
good
idea.
Thank
you.
Okay.
The
draft
does
talk
about
MTU
planning,
seven
and
eight.
Both
talk
about
it
empty
use
at
the
ingress
nodes
are,
of
course
less
than
to
you
in
the
in
the
domain
itself.
This
is
pretty
standard
operational
procedure.
K
K
Right
so
we've
seen
from
the
beginning,
it's
deployed
its
functional,
there's
vendors,
doing
it.
The
purpose
of
revision
eight
is
to
state
that
fact
and
let
the
community
understand
what's
going
on
and
what's
happening
and
understand
that
this
is
a
fact
and
it's
it
is
what's
being
done
with
NSR
domains.
We
do
expect
this
to
happen
a
lot
more
over
the
next
few
months
and,
of
course,
over
the
coming
years.
So
this
this
situation
of
SR
header
insertion
within
an
SR
domain
isn't
going
to
stop.
Regardless
of
the
outcome
of
this
discussion,
good.
Q
Job
okay,
I
mean.
Let
me
just
comment
on
your
last
point,
saying
we're
going
to
violate
the
RFC
no
matter
what
you
do
is
a
bad
reason
to
ask
us
to
change
the
RFC.
Please
don't
now,
let's
back
up
the
thing
I
didn't
hear
in
this
whole
thing
was
any
explanation
for
why
other
than
saving
a
few
bytes,
you
need
to
do
insertion
instead
of
encapsulation,
for
this
ti
LFA
problem.
We
know
how
to
another
argument:
one
shouldn't
do
TI
LFA,
I
have
read
the
TI
LFA
train
you're.
K
D
R
As
ad
Joel
to
respond
to
one
point
right,
like
from
version
7
to
version
8,
the
draft
has
been
changed
to
informational,
so
they're
not
seeking
to
change
the
standard.
Okay,
no
I'm,
just
saying
right!
So
now
it's
like
really
like
documentation
of
some
like
implementation
and
deployment,
rather
than
trying
to
change
it.
So
for
me
that
changes
something
in
my
brain.
Okay,
it's
a
different
thing.
So
I
do
understand
your
point,
but
that's
not
what
that
is
proposing.
Okay,.
D
A
K
D
S
B
K
S
Erica
Lane
I'm,
not
a
router,
implementer
and
I,
did
not
follow
the
SRH
development.
So
this
is
just
a
hypothetical
question.
The
if
the
SRH
header
was
say
large
enough
and
had
padding
at
the
end.
Is
it
computationally
the
same
or
more
expensive
to
sa
rewrite
the
SRH
to
sort
of
insert
your
stuff
and
stop
rather
than
insert.
K
K
B
T
Can't
okay,
but
in
terms
of
protection,
what
you
described
and
I
checked!
These
are
a
draft
as
well.
It
talks
about
protecting
people
from
me,
injecting
things
for
this
prefix
right.
Yeah
I,
assume
that
people
configure
it
to
that
prefix
doesn't
leak
as
a
DA
as
well
out
any
part
of
the
domain,
but
that's
not
written
up
in
the
draft
yeah.
K
K
K
M
Gokhale
I
think
that
they
say
the
interest
in
the
base.
For
my
upon
the
wheel.
They
say
the
casa
showed
the
config
confliction
of
the
usual
of
the
network,
boundary
yeah
because
of
your
I
saying
I
mentioned
some
Mayo
I.
Think
that's
the
summer.
We're
thinking
about
this,
the
ipv6
the
base
on
the
internet
summary
is
a
based
on
the
limit
he
that
domain,
so
I
think
this
is
because
of
this
is
that
different,
a
requirement?
We
have
that
different
concern.
M
M
Point
of
view,
I
think
that
the
eyesight
relation
work
I
think
these
are
you
the
in
the
in
the
current
in
chrome
and
deployment?
You're,
always
a
you,
the
from
my
upon
with
the
mobile
transport
or
the
IP
core
transport
like
this
one.
So
I
think
that
this
is
a
concern
either
at
least
from
the
Internet
I
think
it's
can
be
controlled.
There's
the
first
one
say.
B
M
I
second,
a
while
I
sing,
in
fact
that
we
also
compare
in
the
per
possible.
This
is
a
choice.
I
think.
Maybe
we
also
use
some
that
tunnel
Messer
like
this
one
I
sing
the
day,
so
we
were
introduced
of
the
more
complexity
and
the
overhead,
so
I
is
also
a
career
idea,
so
this
is
the
design.
This
is
the
simplicity.
That
is
also
the
concern
on
this
one.
So.
J
I
think
some
of
this
comes
down
to
climbing
to
follow
ipv6,
RC
8200
and
then
not
actually
following
it.
But
it
might
sound
like
a
academic
argument
but
you're
rather
following
it
or
not,
and
if,
if
as
I,
come
up
with
IP
V
10,
that's
a
copy
of
the
ipv6
spec.
But
it
allows
this
and
then
says
we
use
IP
V.
K
J
K
J
K
You
go
so
he's
describing
a
case
where
you
know
not
not
there.
There
do
exist
and
he's
recognized
in
the
fact
that
do
exist,
domains
where
things
other
than
what
are
you
know?
What
are
stated
for
protocols
across
the
internet
are
applicable
and
I
think
this
is
one
of
those
cases
with
the
SR
header
insertion
within
an
SR
domain.
So.
K
B
U
I
remember
when
we
had
the
same
discussion
when
8200
was
written.
I
can't
remember
someone
said
we
can
say
we
should
not
modify
headers,
but
if
you
find
the
use
case
and
a
way
to
do
it
safely,
we
can
reveal
this
right
so
I'm
a
bit
confused
with
your
presentation
and
your
draft
mark,
because
I
think
it's
actually
trying
to
say
not
what
is
exactly
in
the
title,
because
it
the
title
says:
insertion
is
harmful,
but
what
I
see
on
the
slide?
U
J
U
J
U
J
J
U
U
B
U
K
J
U
M
Game
so
I
asked
the
I/o
to
comments.
The
first
one
I
think
we
should
I
respect
the
RC,
but
I
think
this
is
neither
to
be
driven
by
the
requirement.
Yeah
I
think
this
is
the
icing
of
the
artists
a
who
they
are.
They
are
all
proper,
the
many
times
in
the
meaning
list,
but
I
think
the
I.
Sorry,
six,
that
you
the
helpful
to
ipv6
I,
saying
that
the
you
know
also
and
also
proper,
these
to
the
requirement
of
the
faster
reroute,
and
this
is
the
Biden
seat.
M
M
Second,
a
while
I
want
to
emphasize
this
I
think
this
we
be
living
in
the
grunion
code,
I
think.
Oh,
we
already
say
that
the
in
TAC,
the
Europa,
this
advance
Annette,
will
attest
her.
Send
her
already
attest
that
the
faster
as
our
visas
that
he,
our
every
that's
a
between
the
different
of
endures,
so
I
think
that
this
already
I
think
that
the
society.
J
K
K
K
D
D
D
You
can't
do
insertion
or
modification
whatever
was
on
that
slide
and
in
the
draft,
but
if
someone
can
write
a
document
which
describes
how
you
would
do
it
and
and
deal
with
the
issues
and
that
could
be
considered-
and
so
the
first
thing
I
know
is
that
we
have
discussed
this
an
email
quite
a
lot,
so
I
think
it's
quite
good.
That
mark
has
started
the
process
of
writing
a
document
that
actually
writes
down
the
issues
I.
D
You
know
I
I,
don't
this
is,
and
you
know
the
first
version
of
this
draft
and
I
think
it's
good.
It
needs
a
lot
of
work,
but
I
think
it's
good
that
we're
getting
these
issues
written
down
because
you
because
it
gives
you
know
it,
lays
them
out,
and
so
so,
if
this
proposal,
like
we've
just
heard
about
for
us
or
it's
RH
insertion,
they
can
say
how
they
address
the
issues.
And
then
we
can
consider
it
rationally
as
opposed
to
just
endless
email.
So
I
think
this
is
quite
good.
D
I,
don't
think
we're
quite
done
to
consider
either
of
these
but
I.
You
know
I
think
this
is
a
constructive
way
of
dealing
with
it
better
than
just
the
you
know,
gigabytes
of
email
that
we
did
before
so
yeah.
Well,
that's
good!
Yeah!
That's
why
we
write
documents
here
is
to
write
these
issues
down
and
get
agreement
on
them
and
and
I
think
both
of
these
things
could
exist
at
the
same
time
because
they
can
address
each
other,
and
you
know
and
the
things
some
of
the
things
I
heard
about.
D
You
know
it's
just
off
the
top
of
my
head.
It
seems
like
doing
insertion
in
it.
Paquette
seems
less
problematic
than
just
doing
the
general
case
of
insertion,
which
is
what
RFC
8200
is
really
talking
about.
So
I
think
there's
some
ground
here
too
to
work
in
that
is
reasonable.
So
let
me
go
to
ash
yeah.
R
Let's
go
change,
8,200,
I'm,
gonna
say
hell,
no
right,
but
but
I
don't
think
that's
the
ask
and
the
ask
has
changed
in
the
draft:
okay
from
version
7
to
version
8,
so
that's
kind
of
like
you
know.
We
are
not
past
the
emotional
stage
like
to
look
at
that.
So
I
think
the
ass
is
completely
different
than
before
and
I'm.
B
R
R
So
that
is
one
of
the
like
points
of
feedback.
I
gave
Darren
right.
I
said
like
okay,
like
you're,
trying
to
push
this
on
everybody
like
instead,
like
talk
about
like
what
you
have
done,
rather
than
like,
say
like
hey.
This
should
apply
on
the
internet,
so
that's
kind
of
the
direction
I'm,
okay
with
it.
T
Yeah
I
mean
my
comment:
is
that
before
I
read,
the
draft
I
didn't
realize
that
there
was
this
encapsulation
going
on
followed
by
the
insertion
right,
because
that
actually
changes
it
and
as
far
as
I
can
tell
it's
the
way
it's
constructed.
It's
not
gonna
leak
any
of
these
headers
because
of
the
encapsulation,
so
the
DD
action
boundary
of
the
domain
is
well
defined.
I
mean
it
might,
but
actually
leak
the
whole
encapsulated
packet,
but
any
have
other
problems
right,
but
it's
not
going
to
leak.
The
fact
that
it
just
inserted
a
packet.