►
From YouTube: IETF109-SPRING-20201120-0730
Description
SPRING meeting session at IETF109
2020/11/20 0730
https://datatracker.ietf.org/meeting/109/proceedings/
B
B
So
I'm
not
going
to
spend
too
much
time
here
as
an
introduction,
but
whether
you're
a
contributor
or
a
participant
as
usual.
Please
make
sure
that
you
read
the
note
world
carefully
and
understand
it
next
slide,
please
bruno
so
we
have
a
very
short
or
a
very
small
agenda.
I
should
say
not
not
short,
but
we're
going
to
have
an
update
and
the
future
plans
of
the
design
team,
followed
by
a
discussion
of
the
draft
that
they've
they've
just
released.
B
I
think
I
believe
it's
version
two
now
and
then
we'll
open
up
the
the
floor
for
discussion,
which
I
hope
is
going
to
be
most
of
this
session.
Next
slide,
please
bruno
so,
just
for
every
to
level
set
everybody
we,
the
the
chairs
of
the
the
spring
working
group.
B
We
created
a
design
team
on
the
seventh
of
july
specifically
to
go
and
look
at
the
subject
of
compression
or
srv6
over,
not
not
srv6
sr
over
ipv6
and
compression,
and
we
tasked
the
design
team
with
two
rather
broad
topics.
B
The
first
was
to
come
up
with
the
requirements
for
solutions
for
compressing
segment,
routing
information
for
use
over
ipv6,
and
the
second
was
to
do
a
comparison
of
the
proposed
approaches
that
we've
already
got
in
terms
of
individual
contributions
into
the
working
group
and
present
that
information
as
input
to
the
working
group
to
be
able
to
make
some
decisions
on
how
we
move
forward
with
this
work.
B
We
specifically
asked
the
design
team
to
work
independently
of
the
spring
chairs
and
of
the
spring
working
group,
and
we
did
that
deliberately,
because
we
wanted
to
make
sure
that
they
had
the
autonomy
to
go
away
and
look
at
this
subject
with
with
a
fresh
mind
and
to
come
back
and
give
us
input
into
the
working
group,
so
they
self-organized
within
their
own
charter
and
the
the
results
of
which
was
the
draft
that
you
see
on
the
screen.
B
Although
I
believe
it's
version
two
now
we
we
obviously
want
to
thank
the
design
team
for
the
hard
work.
We
know
that
they've
been
meeting
more
than
once
a
week
for
the
past
few
months.
A
lot
of
work
has
gone
into
this
and
we're
very
thankful
for
for
taking
up
that
work.
B
B
C
You,
okay,
so
I
think
this
is
withheld
chung
from
channel
mobile,
I'm
glad
to
report
the
status
of
the
design
team
to
working
group
on
behavior
of
the
team
members.
So
next
page.
C
C
C
C
C
Page
as
just
now,
charles
mentioned,
in
fact,
we
have
very
clear
scope
for
the
design
team.
The
design
team
is
to
produce
some,
maybe
rough
concerns
output
to
the
working
group
related
to
two
topics.
C
I
think
working
group
chair
also
hope
we
can
answer
following
two
questions.
One
is
why
there
are
several
proposals
already
standardized.
C
The
other
is
whether
is
their
value
in
picking
one
also,
this
may
be
included
in
the
requirements
readout,
but
I
don't
think
we
have
a
done
something
related
to
some
questions
in
the
design.
Team.
C
Of
course,
chairs
also
agree
that
if
the
design
team
can't
agree
or
doesn't
think
it's
helpful
to
report
those
aspects,
that's
also
accepted
for
the
working
group.
I
think
that
is
good
for
design
team
next
page.
C
So
for
the
time
plan,
I
think
currently
design
team
have
a
two-stage
plan.
The
first
stage
is
during
itf
108
to
ietf
109
and
we
hope
to
out
to
put
a
requirement
draft.
I
think
you
we
have
achieved
that.
C
So
the
progress
of
the
design
team
is
so
far
so
good.
We
kicked
off
since
the
end
of
july
and
we
have
had
more
than
20
meetings
till
now.
C
The
link
is
shown
in
the
page.
You
can
review
the
requirement
draft.
We
call
for
comments
on
that
and
I've
seen
quite
a
few
comments
in
the
mail
list.
I
think
we
will
resolve
the
comments
as
soon
as
possible.
C
C
C
I
think
it
may
maybe
in
january
of
2021
and
we
hope
to
submit
analysis
draft,
maybe
the
initial
draft
to
working
group
before
atf
wanton,
that
is
the
basic
status
and
our
rough
plan
for
the
design
team.
B
Yeah,
just
one
thing,
though
joel
we
still
have
another
presentation,
I
believe
so.
Please
keep
these
comments
to
what
you've
just
seen,
rather
than
specifically
to
the
outputs.
F
One
thing
I'd
like
to
add
to
what
wei
chang
said.
I
don't
think
he
meant
to
say
this,
but
the
drafts
that
you're
seeing
today
do
not
include
all
of
the
requirements
that
are
under
considerate
consideration.
There
are
still
a
good
many
in
the
parking
lot
that
are
yet
to
be
worked
on.
Would
you
agree
with
that?
Wei
chang.
G
G
You
then
contradicted
yourself
and
said
sometime
in
december
now
I've
gone
through
that
document
in
quite
some
detail
and
I'm
concerned,
to
say
the
least,
that
six
months
after
we've
started
this.
What
I
have
in
front
of
me
is
a
document
that
steps
outside
of
the
charter
in
a
couple
of
areas,
I'm
not
going
to
go
my
comments
on
the
loop
about
that
and
the
rest
of
it
does
nothing
more
than
state
the
obvious.
G
So
my
question
to
the
chair
is:
do
you
really
believe
that
this
design
team
is
going
to
come
up
with
a
proper
design
document
in
a
reasonable
time
frame?
Considering
that
you
were
already
over
the
time
frame
which
was
promised
to
this
working
group,
and
do
you
believe
that
there
will
ever
be
consensus
within
that
design
team?
Considering
that
you
have
had
a
chair
already
quit
the
design
team
and
state
publicly
that
it
is
because
the
vendors
are
ignoring
the
operator
requirements?
B
C
Yeah,
so
I
I
agree
with
chair,
so
I
think
design
team
here
is
trying
to
give
some
output
and
I
think
it
we
hope
to
help
a
working
group
to
get
a
correct
direction
for
the
technology
and,
as
you
just
mentioned,
in
fact,
I
don't
know
when
we
can
get
agreement
of
in
the
working
group.
We
make
those
plans
just
to
guide
the
design
team
to
work
higher
efficiency
because
we
have
to
set
some
target,
but
all
those
drafts
we
submitted
to
a
working
group.
C
That
is
that's
the
individual
draft.
That
means
we
still
need
the
strict
procedure.
I
mean
the
review
and
the
comments
and
the
modification
and
to
achieve
rough
concerns
in
working
group.
So
I
think
we
don't
I'm
not
intended
to
say
we
have
guided
agreement
or
we
have
that
conscience
in
our
design
team.
Then
the
working
group
should
accept
this
draft.
C
G
E
Comments,
I
would
hope
I
I
I
can't
tell
none
of
the
chairs
are
going
to
tell
the
design
team
how
to
deal
with
the
comments.
We
hope
you
will
be
taking
into
account
all
the
comments
received
on
the
list
and
engaging
with
people
on
the
list
and
then
going
and
continuing
the
design
team
process.
As
you
said,
you
expect
to
finish
to
do
another
revision
and
we
hope
that
will
reflect
discussion
so
there's
a
better
chance
that
the
working
group
will
adopt
the
result.
E
F
H
Okay
yeah,
it
seems
I
mean,
in
my
opinion,
it
seems
like
the
the
best
way
to
go,
for
this
is
to
lay
out
the
requirements
and
have
the
working
group
decide
because,
as
it
was
mentioned,
it
seems
has
been
a
long
while
to,
and
there
is
no
consensus
within
the
design
team
to
to
agree
on
what
the
requirements
are.
The
second
point
that
I'm
trying
to
make
is
about
appendix
a
which
is
having
existing
standards
included.
H
H
I
would
think
that
the
existing
standards
should
be
included
as
part
of
the
metrics
when
we
choose
one
of
or
more
of
the
designs.
Thank
you
very.
C
I
I
apologize,
I
sent
my
comments
just
recently,
so
I'm
looking
forward
for
discussion,
but
one
general
question
and
concern
that
I
have
so
and
that
was
highlighted
both
in
chairs
introduction
and
and
wei
chang
presentation
that
the
design
team
was
chartered
to.
B
Well,
I
can
comment
from
a
chair's
perspective
and
and
bruno
and
joel,
please
pipe
up
as
well.
If
you
have
anything,
but
from
our
perspective
greg,
we
wanted
to
make
sure
that
the
design
team
had
the
autonomy
to
go
away
and
make
their
own
decisions,
and
we
gave
them,
as
you
know,
a
task
to
look
at
segment
routing
compression
over
ipv6.
B
Now,
if
that
design
team
comes
back
and
they
have
a
consensus
that
the
base
of
the
requirements
that
they
want
to
put
out
is
srv6,
then
they
need
to
justify
what
why
that's
the
case?
B
On
the
other
hand,
I
think
I
saw
in
the
document
that
there
was
also
discussion
about
other
solutions,
and
I
think
the
design
team
can
make
some
comments
on
that,
because,
at
least
from
our
perspective,
we
hope
that
they've
looked
at
all
possible
solutions
to
make
those
requirements.
I
Well
again,
I
would
appreciate
if
the
design
team
did
follow
the
charter,
and,
yes,
I
agree
with
you
if
they
decide
that
some
aspects
of
the
charter
must
be
outside
the
scope
of
the
document.
There
needs
to
be
a
very
technical
discussion
about
it
and
very
strong
arguments,
because
what
I
sense
is
that
their
disconnect
within
the
design
team
might
be
related
to
this
change
of
the
scope.
J
Yeah,
I
think
we
should.
I
think
we
should
let
we
think
continue
with
the
presentation
for
a
lot
of
content
to
go
through.
We
haven't.
We
haven't
seen
that
yet
and
if
I
can,
if
I
can
speak
the
greg's
comment,
I
think
a
lot
of
which
he
said
is
answered
in
that
in
that
next
presentation,
or
at
least
we'll
give
the
the
rest
of
the
audience
the
context
it
needs.
E
H
A
Okay
cool,
so
regarding
the
requirements,
I
think
we
are
really
hard
working
right.
Basically,
we
have
more
than
twice
meeting
in
some
weeks
right.
A
So
if
someone
is
disappointed
of
the
progress
I
really
like,
they
can
make
some
contribution
to
the
design
team
if
they
want,
but
I'm
not
really
sure
that
it
will
help
or
not,
but
it
doesn't
matter
and
regarding
the
name
we
did
make
some
discussions
of
the
name
of
the
draft,
so
it
is
consensus
of
among
the
design
team
and
actually
we
can
discuss
it
again.
If
you
want,
we
can
make
it
in
the
mailing
list.
Yes,.
E
K
Since
srv6
is
has
been
defined
in
a
series
of
rfc
and
working
group
documents
and
also
has
been
deploying
some
operators,
for
example,
intelli
telecom
in
several
scenarios,
so
from
standpoint
of
network
migration,
I
think
that
a
new
future
compressed
solution
should
be
as
a
basis
based.
I
think
that
this
should
be
concerned
as
a
basic
requirement.
E
L
Can
you
hear
me?
Yes
all
right,
so
I
have
three
general
comments.
My
first
comments.
I
want
to
thank
the
design
team.
We're
really
grateful
for
you
taking
the
time
and
doing
this,
so
anything
you
hear
at
niner
or
negative
is
really
trying
to
get
things
right
so
appreciate.
It
second
comment
is
the
requirements
I've
seen
general
requirements,
I
looked
at
it.
L
L
I
don't
know
if
I
mean,
maybe
I
didn't
read
it
so
so
I'm
guilty
here,
but
I
when
I
scan
through
it,
I
noticed
that
the
requirements
are,
you
know,
lumped
into
one
bucket.
You
know
in
different
areas,
but
it's
all
under
one
umbrella,
and
I
don't
know
if
per
use
case
might
be
more
beneficial.
I
mean
that's
something
the
design
team
can
look
at.
The
third
thing
is
I
mean
you
have
to
be.
We
have
to
be
ready
for
the
outcome.
You
know.
There's
consensus
is
great.
L
If
there's
no
consensus,
what
do
we
do?
So
that's
something
we
need
to
think
about.
We
don't
want
to
wait
for
the
last
minute
and
start
you
know
shoveling
and
you
know
doing
other
stuff.
So,
let's
be
ready,
you
know,
there's
consensus,
we're
all
you
know.
So
it's
a
win-win.
If
it's
not,
we
need
to
go
forward
and
figure
out
what
to
do
and
that's
something
we
need
to
think
about
upfront,
I'm
good.
That
was
my
comments.
Thanks.
E
Before
we
continue,
we
need
to
cut
this
cue.
We
should
have
said
something
sooner,
because
it's
clearly
too
long
when
we
need
to
get
on
to
the
next
presentation
so
andrew,
I'm
sure
you
have
more
to
say.
Can
we
ask
you
to
please
wait
until
after
the
next
one,
but
we'll
let
vim
who's
on
the
okay
vince
pulled
himself
off
k.o?
You
get
the
last
word
for
now,
we'll
do
the
next
presentation
and
then
we'll
open
it
up
to
the
floor.
M
We
can
I'm
going
to
keep
it
very
short.
I
have
three
comments
or
three
points
to
make.
One
is
thank
you,
design,
team,
but
hoping
to
really
see
some
consensus
b.
The
draft
needs
work.
Clearly
everybody
has
said
I
don't
need
to
enumerate
on
that.
Please
get
the
draft
in
shape
and
three
I
look
at
the
appendix
I
look
at
some
of
the
requirements
and
to
lewis
point.
M
If,
if
there
is
no
consensus,
I
want
the
working
group
at
least
to
know
we
at
arcus
have
running
code
on
on
a
solution
that
is
based
on
srv6
and
minimally.
We
like
to
see
that
move
forward
happy
to
see
if
there
are
other
solutions,
but
that
is
the
solution
we
are
working
forwards
know
that
design
team
you
guys
are
working
on
it,
which
we
always
appreciate,
but
we
have
a
working
code
and
we
like
to
see
a
consensus
soon.
Thank
you
so
much.
E
Okay,
waiting
bruno
will
now
bring
up
the
other
presentation
and
you
can
then
go
through
that
and
we
will
take
questions
on
this
presentation
at
the
end
of
the
presentation.
So
you
can
put
yourself
on
the
queue
whenever
you
like,
but
we're
not
going
to
start
taking
questions
until
he's
had
a
chance
to
go
through
it.
E
B
And
wei
chang,
if
you
could
try
to
be
as
quick
as
you
can,
but
just
bearing
in
mind
we've
we've
got
about
30
minutes
now,
so
we
want
to
make
sure
we
have
some
time
for
discussion.
C
Yeah,
okay,
I
will
okay
so
next
page,
I
I
think
it
yeah.
This
document
focus
on
the
requirement
like
next
page.
C
Yeah
and
just
now
someone
asked
if
there
are
use
case
or
something
like
that.
I
think
it.
This
figure
here
choose
the
packet
to
hide
with
sih
it's
obviously,
if
a
strict
pass
te
is
deployed,
the
seed
list
will
be
too
long.
Example,
eight
hops
will
take
about
128
bytes
to
list
more.
There
are
several
proposed
methods
to
reduce
the
resulting
isabe
6
encapsulation
size
by
comprising
the
seed
list
in
the
working
group.
Now,
so
I
think
some
use
cases
have
been
provided
in
a
working
group
already
next
page.
C
So
here
is
the
overview
of
the
requirement
draft.
Now
there
are
three
aspects
of
the
requirements:
srb6
seed
list,
comprision
requirements,
the
srv6
specific
requirements
and
the
protocol
design
requirements
as
well
as
we
had
the
appendix,
which
included
some
requirement
items
without
unanimous
concerns
within
design
team.
C
The
figure
the
items
with
right
flag
is
loser
which
we
have
been
agreed.
The
one
with
the
green
flag
are
those
without
unanimous
concerns
within
design
team.
Next
page.
C
So,
let's
go
yeah
next
page,
firstly,
is
about
the
encapsulation
hider.
I
think.
Obviously
this
is
a
basic
requirement.
It
requires
a
solution
to
reduce
the
size
of
i76.
Encapsulation
hide
the
next
page.
C
So
forwarding
efficiency
and
we
would
like
a
record
as
a
number
of
the
hider's
password
during
the
processing
of
the
second
list
and
the
number
of
the
flip
lookups
during
the
processing
of
a
segment
list
for
different
proposals.
Next
page.
C
So
the
stator
efficiency,
we
hope
the
compression
solution
should
minimize
minimize
the
amount
of
the
additional
forwarding
seat,
stored
and
note
next
next
page
for
the
seedless
lens.
The
compression
mechanism
must
be
able
to
represent
sr
pass
data
contain
up
to
16
segments.
I
think
this
requirement.
We
had
a
lot
of
discussion
and
there
are
some
input
from
different
operators.
Then
we
think
a
16
segment
is
enough.
C
So
we,
the
design
team,
think
this
is
a
necessary
requirement
next
page,
so
for
the
lossless
compression,
of
course,
the
comprise
the
seed
list
must
be
equivalent
to
the
original
state
list.
C
C
C
For
the
service
scale,
similar
to
the
other
two,
the
compression
mechanism
must
be
able
for
representing
one
million
service
per
node
next
page.
C
This
is
for
the
srv6
base
co
existence,
so
we
hope
the
compression
solution
can
support
deployment
in
existing
assad
6
network.
So
this
figure
shows
the
applicant
scenario.
The
path
maybe
only
support
the
original
i76
or
comprise
the
srv6.
C
Next,
several
pages
is
some
requirements,
items
with
rough,
but
not
unanimous
concerns
and
we
hope
to
get
more
comments
from
working
group
wide
and
any
feedback
are
appreciated.
Next
page.
C
I
think
it.
Firstly,
we
would
like
to
point
out
the
design
team
is
always
open
for
any
proposal
when
we
prepare
the
requirement
draft
here,
we
list
the
two
target.
C
C
C
C
C
So
for
the
hyper
juniors
sydney,
it
is,
we
hope
the
compression
solution
can
support
a
combination
of
a
compressed
and
the
original
segment
in
a
single
pass.
So
this
is
a
little
bit
different
from
the
requirement
item
we
just
mentioned
for
the
co-existence
item.
This
allowed
one
pass
can
go
through
both
comprised
and
non-comprised
segments.
C
C
I
would
like
it
to
sorry
chair.
I.
I
would
like
to
see
that,
because
the
design
team
we
have
eight
different
members,
this
output-
I
mean
my
meaning-
is
that
this
draft
have
a
agreed
by
the
design
team.
So
I
think
some
questions
may
be
answered
by
the
design
team
members.
I
Yes,
thank
you,
okay.
I
I
don't
want
to
repeat
my
comments.
Actually
I
in
adversely
I
misunderstood,
I
commented
only
on
what
is
marked
as
a
full
consensus,
but
I'll
go
with
add
my
comments
to
other
part
of
the
draft.
What
I
want
to
point
out
that
I
get
an
impression
that
the
requirements
are
centered
for
the
brownfield
deployment
scenario
of
the
compressed
sid
solution.
E
N
N
O
Thank
you,
I'm
thank
you
for
the
make
this
work.
All
requirements
are
good,
but
especially,
I
impressed
that
the
requirement
on
the
atlantic
side,
because
the
the
whatever
the
operators
who
already
deployed
srp6
in
the
wild
and
it's
a
basic
base,
a
service
functionality
and
heterogeneous
citris.
O
It's
really
really
important
for
us,
so
please
make
sure
that
the
other
appendix
requirement
to
be
the
normative
part
of
the
requirement.
Thank
you.
That's
all.
P
Bob,
yes,
thank
you,
so
I
wish
I
had
slide
numbers,
so
I
could
tell
you
which
one
I'm
going
to
ask
about,
but
the
slide
that
was
titled
srb6
base
coexistence,
I
having
trouble-
and
I
I
read
the
draft
too,
but
there's
a
section
about
this,
but
I
don't
really
understand
what
this
means.
It
says
the
compression
solution
must
support
deployment
in
existing
srv6
networks.
Well,
can
you
elaborate
on
what
that
means.
B
F
Well,
thank
you
and
thank
you
in
this
picture.
You're
seeing
two
sr
paths.
One
of
them
is
depicted
by
solid
lines.
It
has
only
one
routing
mechanism
in
it,
the
ps4h,
with
classic
srv6
sids.
You
see
another
sr
path
affected
by
a
dotted
line.
It
has
the
compression
mechanism
in
it
whatever
it
is.
F
J
Hey,
hopefully,
folks
can
hear
me,
but
we'd
also
call
this
shift
in
the
night
deployment
at
one
point,
but
that
was
maybe
two
not
interpreted
the
same
by
everyone,
so
hopefully
that
clarifies
it
a
couple
things
for
the
the
rest
of
the
comment
just
on
on
the
time
it's
taken
to
produce
this.
I
just
want
to
remind
people
that
we
are
going
through
a
pandemic
and
things
are
very
tough
for
people.
J
A
lot
of
people
took
most
of
the
summer
off
during
the
last
several
months,
so
the
design
team
started
really
in
earnest
in
september
and
there's
I
just
wanna
highlight:
there's
been
like
many
many
many
hours
of
work
put
into
what
we've
got
here
and-
and
I
think
that
I
think
we've
got
a
good
start
and
some
good
great
requirements
in
here
that
that
reflect
the
design
team
is,
is
coming
from
and
and
the
operators
and
and
people
that
we
have
contact
with
within
the
team.
J
The
second
point
on
questions
around
association
with
srv6.
I
just
want
to
call
it
that
when
we're,
when
we
look
at
what
we
are
compressing,
we
are
compressing
sr
information.
It's
been,
it's
been
defined
in
the
in
the
ask
from
the
from
the
chairs
and
that
information
we're
compressing,
has
been
called
in
one
of
the
first
slides,
as
the
s36
said,
lift.
So
if
we,
if
we
didn't,
have
that
current
solution
to
compress,
then
we
wouldn't
actually
be
compressing
anything.
J
I
also
want
to
point
out
that
the
draft
specifically,
if
we
read
past
the
first
page
of
the
draft,
defines
explicitly
that
we
that
we
are
considering
solutions
with
the
current
existing
srv6
data
plane
and
building
requirements
for
that
and
considering
solutions
with
new
control,
plane
and
data
planes
and
building
requirements
for
those
as
well.
So
I
just
wanted
to
call
that
out
before
there's
more
comments
on
on
that
topic.
F
Okay,
I
think
greg
mursky
hit
the
nail
on
the
head
in
his
very
first
comment
when
he
came
to
the
mic
at
the
beginning
of
the
meeting.
The
question
is
really
for
charter
of
the
working
group.
Are
we
here
to
compress
segment
information
for
an
sr
over
ipv6
solution,
or
are
we
here
to
press
account
the
sid
list
as
it
lives
in
the
srh,
and
that
cannot
be
restated?
Are
we
here
to
optimize
behavior
for
deployments
that
already
use
the
srh
heavily
or
are
we
here
to
equally
keep
in
mind?
B
Ron
one
comment
here
from
jim
is
you
know
it
seems
to
me
that
we're
we're
here
to
to
work
on
requirements
for
what
needs
to
be
compressed
and
if
the
design
team
make
a
com
decision
that
well,
it's
really
the
srh.
That
needs
to
be
compressed.
There's
no
other
thing
out
there,
whether
deployed
or
not.
That
needs
to
be
compressed,
then
clearly,
that's
where
you
would
focus.
B
So
I
think
I
I
would
word
it
that
you
know
look
at
what
needs
to
be
compressed
in
you
know
these
existing
headers
and
work
from
there.
Q
Yeah,
you
hear
me
yes
yeah,
so
I
wanted
to
go
out
two
things.
Basically,
first
of
all,
I
think
right
now,
if
I
at
least
I've
been
part
of
the
design
team
and
the
way
you
should
read
the
requirements
is
that
we
are
actually
going
for
both
of
green
and
br
and
brownfield,
because
there
is
a
set
of
requirements
specifically
that
built
upon
srv6,
but,
and
there
is
a
set
of
operators
who
want
to
actually
see
that
happening
and
that's
why
they
are
in
the
requirements
document.
Q
But
I
also
want
to
point
out
that
we
haven't
I've
done
the
analysis
yet
so
what
we
are
doing
at
this
stage
is
building
upon
is
a
requirements
document
that
is
generic
enough
to
cover
both
greenfield
as
well
as
brownfield
and
then
based
on
the
analysis.
We
will
see
how
certain
solutions
comply
to
this,
because
there
is
a
different
set
of
people
wanting
different
things
and,
as
a
result,
at
this
stage
we
want
to
be
open
to
actually
cover
all
those
different
scenarios
right.
Q
The
analysis
which
we
haven't
discussed
yet
is
that
for
some
of
these
requirements,
what
we
are
going
to
do
is
build
a
set
of
use
cases
that,
on
which
we
are
going
to
analyse
analysis,
the
the
different
set
of
solutions
that
are
out
there
in
order
to
then
I
look
at
those
things
and
to
comment
on
on
john's
comment
on
performance
and
and
look
up
things
even
that
we
had
a
consensus
on
on
how
to
do
that,
because
we
believe
that
certain
fields,
although
the
header
might
be
complex,
it's
the
lookups,
will
determine
the
performance
and
the
efficiency
of
how
that
implementation
will
scale,
and
that's
why
we
have
kept
that
requirement
in
it,
because
we
believe
it's
valuable
thanks.
A
Hello
go
ahead
so,
first
of
all,
I
think
we,
I
fully
agree
with
wim
that
we
do
include
greenfield
and
brownfield
as
well
in
the
document
that
that's
the
very
important
thing
right.
The
second
point
is
that
we
do
believe
that
the
traps
is
not
finished
yet
we
still
have
a
lot
of
work
to
do
and
in
this
meeting
and
after
this
meeting
yeah.
So
this
answer
to
andrew
and
the
third
one
is
that
I
think
the
requirements
of
compression
comes
from
the
overhead
of
srv6c
right.
A
So
I
think
the
name
of
the
job
is
appropriate
because
we
are
going
to
say
that
we
are
going
to
solve
the
problem
that
came
from
the
srv
succeed,
so
we
have
compressed
srv6c
right,
but
we
do
not
limit
the
mechanism
to
be
like
sih,
based
only.
We
do
not
do
that
right.
We
are
allowed
to
discuss
auto
solutions
based
on
fi
or
not,
and
right
now
we
are
focusing
on
a
very
general
requirement
which
can
be
like,
which
can
be
supported
by
multiple
solutions.
R
Hi
there,
tom
hill,
I
have
a.
I
think
I
have
a
concern
around
the
inclusion
of
what
I
believe
is
an
inclusion
of
a
requirement
to
mix
compressed
sids
with
uncompressed
sids
or
compressed
sids
of
different
lengths
in
the
same
header.
I
think
that
was
one
of
the
requirements
that
went
in
here
and
my
I.
I
realized
that
that's
noted,
as
not
being
unanimous
at
the
moment.
My
concern
is
that
this
doesn't
seem
particularly
efficient
from
a
forwarding
plane
perspective
and
I've.
R
I
wanted
to
to
point
out
that,
when
the
design
team
are
looking
at
these
requirements,
I
was
hoping
that
they
weren't
looking
at
them
in
isolation,
and
they
were
looking
at
the
broader
solution
and
all
the
requirements
there
making
sure
that
there
wasn't
any
contradictory
elements
to
that.
This
does
seem
particularly
inefficient
as
a
suggestion.
G
Firstly,
I
just
want
to
agree
with
what
some
said.
I
really
do
think
that
that
is
really
inefficient,
but
I
I
want
to
ask
the
chairs
this,
firstly,
my
reading
of
this
document
and
maybe
I'm
wrong,
but
the
references
to
srv6
that
are
all
over
this
and
yes,
I've
heard
the
comments
before
this
seem
to
me
to
tie
this
very
much
to
srv6,
as
in
traditional
srv6
that
we've
seen
up
till
now.
G
If
the
design
team
cannot
come
to
a
consensus
about
that
tie
to
srv6
or
not
that
type
that
srv6,
when
are
we
likely
to
get
that,
and
is
the
design
team
then
prepared
to
say
that
anything
outside
of
traditional
srv6
is
out
of
scope
and
can
be
pursued
outside
of
this
entire
process,
because
I
I
am
deeply
concerned,
as
I
said
in
my
previous
comments,
that
four
months
in
and
yeah,
I
know
the
pandemic,
blah
blah
blah.
The
reality
is
is
that
there
are
other
solutions
that
have
already
shipped.
G
They
are
in
running
code
and
I
am
extremely
concerned
that
this
process
is
resulting
in
a
situation
where
things
are
being
developed
outside
of
the
auspices
of
of
the
ietf
because
of
the
delays
being
created
and
as
a
result
that
damages
the
technical
ecosystem,
because
people
are
not
going
to
stop
developing
certain
of
those
solutions
are
going
to
go
ahead.
G
They
are
shipping
in
code
today
running
code
in
major
vendors
routers,
so
the
delays
here
I
need
to
know
how
long
is
this
likely
to
take
before
we
get
a
statement
from
this
design
team,
because
right
now
we
do
not
have
a
design
document.
This
is
not
a
full
design
document.
It
is
not
even
a
requirements
document,
it
has
disputed
sections
all
over
it
and
this
is
ietf109
where
it
was
told
it
would
be
presented.
E
Okay,
I
want
to
allow
the
y
ching
to
respond,
but
I'm
going
to
ask
the
other
design
team
members
not
to
respond
to
that
and
unless
you
it's
really
urgent
to
get
off
the
line,
because
we
have
four
minutes
left
and
I'd
like
to.
Let
folks
who
haven't
spoken,
speak
so
greg.
You
may
consider
taking
your
comments
to
the
list
as
well,
but
wait
ching.
You
should
respond
to
andrew.
C
Yeah,
so
I
think
andrew
writes
a
very
good
question
and
I
think
all
the
draft
we
are
preparing
is
the
first
goal
is
to
get
a
correct
direction
for
the
for,
for
the
design
team
for
the
working
group,
and
there
are
a
lot
of
different
solutions
can
be
deployed,
but
in
itf
we
have
to
give
a
clear
suggestion
to
the
industry,
which
one
should
be
adopted
by
the
working
group
and
so,
from
my
point
of
view,
design
team
will
do
what
we
can
as
fast
as
we
can.
C
E
B
A
S
Okay,
thank
you.
Firstly,
I'm
using
liu
from
channel
mobile,
an
operator
from
my
point
of
view.
I
think,
for
the
compression
solution.
Is
it
necessary
to
be
complete
compatible
with
the
classic
as
well?
6
standard
means
that
in
the
requirement,
the
the
the
compression
solution
should
be
srv6
based,
and
secondly,
I
also
hope
the
a
solution
can
be
moved
forward
fast
and
so
because
in
the
chain
mobile
net
network,
which
we
need,
we
really
need
to
deploy
s6
compression
soon.
S
T
T
This
is
a
huge
effort
to
manage
some
kind
of
new
number
resource.
D
B
Yeah-
and
we
can
take
that
one
to
the
list
way
more
because
it's
a
long,
I've
heard
the
explanation.
It's
a
long
explanation.
We
don't
have
time
for
it
now.
E
U
Thanks
for
the
design
team-
and
I
believe
that
we
are
in
the
requirements,
phase
approach
is
coming
later
analysis
of
the
approaches.
What
I
would
like
to
say
is
that
you
know,
while
tackling
the
combustion
problem,
which
is
really
what's
the
focus
on
the
requirement,
should
reflect.
You
know
fair
and
a
full-fledged
analysis
and
not
really
lower
the
bar
for
what
you
know
is
already
deployed
and
being
evaluated
for
deployment
with
srv6.
U
So
I'm
hoping
that
we
have,
you
know
a
broad
spectrum
analysis
of
the
requirements,
even
if
you
know
some
operators
may
like
to
you
know,
probably
focus
on
only
one
or
two
of
them,
because
in
itf
we
have
a
thing
of
you
know.
Building
on
what
is
existing,
you
know
we
keep
define,
introduce
something.
U
Then
we
improve
it
add
figure
I
can
understand,
and
it
is,
I
think,
natural
for
many
participants
to
have
that
same
feeling
and
same
logic
with
you
know,
on
srv6,
and
I
hope
you
know
everybody
can
appreciate
that.
That's
all
thank
you.
E
Thank
you
katan.
Thank
you,
everyone
we
will.
We
need
to
continue
these
discussions
on
the
list
because
we
we
as
chairs,
need
to
see
what
you
guys
think
are
important
and
we
encourage
the
design
team
to
keep
working
towards
the
goals
they've
laid
out
and
the
timeline
they've
laid
out.
Thank
you
all
very
much
daniel
did
you
want
a
last
word.
V
Keep
crapping
out
so
thanks
for
the
design
team
by
the
way,
there's
quite
a
lot
of
hours
put
behind.
I
just
wanted
to
stress
one
last
point
about
the
standardization
that
is
key
for
scalability,
as
I
already
stated
in
the
mailing
list,
so
just
make
sure
that
it
is
still
considered
a
compression
solution.