►
From YouTube: IETF109-6MAN-20201120-0900
Description
6MAN meeting session at IETF109
2020/11/20 0900
https://datatracker.ietf.org/meeting/109/proceedings/
B
B
B
I
think
you've
seen
this.
I
think
you've
seen
that-
and
this
was
the
agenda
from
the
first
session
we
didn't
get
to
linda
dunbar's
talk,
so
that's
going
to
be
the
first
talk
now
next
slide,
and
then
we
have
a
report
on
the
sr
compression
design
team.
There
was
just
many
of
you
may
have
been
in
the
spring
working
group
that
just
preceded
this,
and
there
was
a
pretty
big
long,
just
discussion
about
this
we're
gonna.
B
A
C
C
C
C
C
C
Today
the
train
is
using
anycast
instead
of
having
multiple
local
dns
resolvers
in
each
ldm.
There
are
many
many
benefits
of
using
anycast,
not
only
it
can
balance
the
traffic
across
different
servers
using
the
utilizing.
The
network
condition
is
actually
basically
being
able
to
utilize
the
routing
layer,
information
to
achieve
better
load,
balancer
load
balancing
and
to
remove
the
single
pointer
failure
at
the
dns
resolver.
All
the
application
load
balancers
also
that
the
many
client
or
user
device
may
use
their
cached
ip
addresses
for
extended
period
of
time.
C
One
application
server
in
ldn1
maybe
is
very
close
to
the
one
in
ldm2,
so
the
network
distance
difference
is
not
significant
enough
to
balance
out
other
factors
like,
for
example,
higher
capacity
or
maybe
some
side,
maybe
more
preferred
than
others.
So
there
are
other
issues
brought
up
by
this
next
slide,
please.
C
The
service
is
better
to
be
served
by
the
original
server,
so
they
call
it
sticky.
So
in
a
way
that,
if
you
look
at
the
local
data
network
too,
there
will
be
many
many
traffic
from
different
uee,
different
users
or
different
applications,
and
even
from
the
same
user,
it
may
have
multiple
applications.
C
All
those
users
they
actually
may
resolve
to.
For
example,
ip3
may
may
be
anchored
into
the
edge
application
server
too
versus
the
newly
migrant
ue1
need
to
go
to
ldl1.
So
in
the
3gpp
sa2
edge
computing
project,
there
are
many
proposed
solutions
and
we
find
that
actually
ipv6
provide
a
very
elegant
solution.
That's
why
we
want
to
present
here
to
get
people's
feedback
next
slide.
Please
next
slide.
C
C
So
when
the
s1
server
coming
back
with
the
response
back
to
the
source,
the
r1
basically
insert
use
the
acl
to
filter
out
the
service
and
insert
the
sticky
service
sticky
destinations
of
tov
inside
the
destination
extension
header.
So
then
the
traffic
comes
back
to
back
to
the
ue
and
in
the
ue
it
has
the
expected
behavior
to
copy
the
destination
extension
header
from
the
received
packet
to
the
subsequent
packets,
for
the
services
and
for
the
flows
that
need
to
be
sticky.
C
So
with
that,
when
the
ue
moved
to
anchor
to
the
psa2
on
the
traffic
comes
to
the
router
b
and
the
router
b
will
be
able
to
be
informed
by
the
sticky
service
management
system
to
filter
all
those
packets
and
be
able
to
filter
out
the
original
egress
router,
which
is
r1,
and
with
that
information,
our
router
b
can
either
use
a
tunnel
or
use
a
segment
rounding
to
forward
the
packet
to
explicitly
to
the
router
one
to
achieve
this
service
to
be
sticky
to
the
original
server
next
page.
Please.
C
C
We
assume
that
within
some
environment
the
local
data
network
is
managed
by
one
provider.
They
can
use
a
shorter
identifier
to
represent
the
egress
router.
There
could
be,
if
that's
not
the
case,
say
in
the
heterogeneous
environment.
You
have
to
use
the
actual
address,
then
the
sticky
type
can
set
to
two.
Then,
with
that
you
will
use
the
tunnel
endpoint
subtle,
which
is
defined
by
the
tunneling
cap
draft
to
represent
the
egress
router,
and
we
put
this
sticky
surface
sticky
destination
subtle
in
the
destination
extension
header
next
page.
Please.
C
Another
option
say
this
is
hope
to
get
some
feedback
from
the
experts
here.
There's
also
the
ipv6
routing
extension
header
so
based
on
the
definition
of
the
routing
extension
header
is
to
say,
is
to
list
the
number
of
intermediate
nodes
to
be
visited
on
the
way
to
the
destination
packet
destination.
C
C
F
Okay,
I
was
going
to
agree
with
ron.
I
think,
if
you
give
it,
if
you
put
in
the
destination
header,
then
you
open
the
possibility
that
it
could
be
still
be
delivered
to
the
end
point
at
was
it
l2
or
whatever,
but
that
l2
could
open
a
proxy
session
for
certain
applications
and
maybe
proxy
it
back
to
l1.
C
Thank
you,
okay,
next
page,
so
this
is
for
when
the
user
device,
like
older
older
version,
doesn't
do
what
3gpp
spec
is
doing
so
it
doesn't
do
anything
with
the
incoming
package
doesn't
copy
the
destination
option
header
into
the
next
subsequent
package.
This
is
one
option
to
achieve
the
sticky
service.
C
C
So
with
that
5g
management
system
can
notify
the
local
data
network
management
system
that
this
particular
user
is
to
be
re-anchored,
and
then,
with
that
this
router
ingress
router
will
be
able
to
find
out
through
his
routing
protocol,
find
out
where
this
psa2
is
attached
and
be
able
to
send
this
sticky
service
sub
theory
information
to
the
new
ingress
router.
So
that's
the
service
without
dependence
on
the
ui
behavior
next
case
next
page
here
is
the
another
case
where
there's
no
assistance
from
5g
system
at
all.
C
Okay.
So,
as
I
said
earlier,
the
purpose
is
to
get
feedback
from
the
experts
here
to
validate
this
approach
actually
workable,
and
we
are
looking
for
feedback
if
it's
workable,
we
can
propose
this
to
3gbp
to
show
for
ipv6.
Actually,
the
solution
is
very
elegant.
Instead
of
many
other
proposed
solutions
out
there,
in
addition
to,
I
should
say.
B
C
G
G
G
G
G
G
G
G
G
G
B
G
G
The
first
aspect
aspect
is
srb6,
the
seedless
compression
requirement.
The
second
activist
is
srb6
specific
requirement
and
the
last
one
is
protocol
design
requirements
as
well
as
we
have
a
appendix
in
this
draft,
which
contains
some
requirements
without
unanimity.
The
unanimous
concerns
within
the
design
team
in
the
figure,
the
item
with
the
right
flag,
is
those
which
have
been
agreed
within
the
design
team.
G
G
G
G
B
E
First,
thanks
to
wai
ching
during
hiring
a
lot
of
work.
Second,
people
might
get
excited
that
the
document
looks
incomplete.
There
are
requirements
that
are
still
in
the
open
state
that
aren't
in
the
document.
So
if
it
looks
incomplete,
don't
get
too
nervous
about
it.
Yet
second
is
a
question
probably
for
eric
klein
and
you
bob
and
olay
we've
had
an
open
call
for
adoption
on
the
crh
draft.
Since
late
may,
it's
waiting
on
this
design
team,
it
looks
like
the
design
team
won't
be
back
until
ietf
110..
E
Now
I
have
customers
who
are
interested
in
the
crh,
but
could
care
less
about
the
srv6
control
plane,
they're
provisioning,
their
boxes
from
a
controller
that
does
everything,
so
they
don't
want
the
srv6
control,
plane
or
anyone
else.
Sooner
or
later
you
know.
When
do
we
make
the
decision
to
adopt
crh
for
no
reason
other
than
for
the
people
who
are
using
it
and
not
using
any
iepf
routing
protocol.
F
I
think
I
think
it's
important
to
note
that
the
the
sr
design
team-
well,
it
may
be
going
slow,
it
does
seem
to
be.
It
does
seem
to
be
working.
It's
just
maybe
not
working
fast,
but
we
had
talked
about
there
being
some
other
options
like
whether
or
not
six
man
needs
to
adopt
fcrh
or
whatnot
you
need.
You
just
need
a
a
rooting
header,
some
type.
F
B
F
G
H
Just
on
the
context
of
what
whether
the
design
team
thinks
that
there's
a
new
voting
header
subtype
needed,
the
design
team
is
just
focused
on
building
the
requirements
and
then
allowing
not
analyzing
the
proposals
eric.
So
I
don't
think
you're
gonna
get
anything
on
on.
You
know
there
won't
be
a
design
of
a
solution
by
the
design
team.
It's
just
the
requirements
and
analysis
of
the
proposals
that
it's
going
to
produce.
B
B
I
So
what
I
kind
of
want
to
say
is
looking
at
the
whole
crh
thing
right
now
we're
in
a
situation
where
this
has
been
around
for
a
number
of
ieps
and
we've
moved
from
requirements,
documents
to
a
design
team
to
etc,
etc.
The
fact
is
is
that
this
code
is
shipping
today,
it's
in
production
code,
and
there
are
people
like
myself
who
need
it
and
we
need
it
in
order
to
deal
with
geopolitical
issues.
For
one
thing:
it's
critical
for
dealing
with
geopolitical
issues
and
avoiding
the
suppression
of
internet
freedoms.
I
That's
what
we're
using
it
for
I'll
bobby
blunt,
and
by
delaying
this
any
further.
All
that
we
are
doing
is
driving
protocol
development
further
outside
of
the
ietf,
because
the
development
is
not
going
to
stop.
This
is
simply
too
critical,
and
I
would
argue
that
that
is
not
in
the
interests
of
the
technical
community.
I
It
is
not
in
the
interests
of
the
vendors
who
their
very
customers
are
the
operators,
and
we
have
a
massive
demand
for
this
on
the
continent,
where
we
have
to
have
a
working
solution,
which
is
what
crh
gives
us
to
deal
with
authoritarian
states
who
wish
to
play
with
traffic.
This
is
how
we
deal
with
it,
and
I
am
pleading
with
this
working
group
to
let
let's
stop
the
delays,
because
crh,
as
we've
said,
is
a
building
block.
It
is
not
tied
to
srh.
B
A
We
can't
hear
you
do
you
want
to
see
if
you
can
fix
your
audio
issues
and
then
we
go
to
so
far
and
then
come
back
to
is
that
okay
and
when
you're
at
the
head
of
the
queue?
Please
unmute
yourself
a
couple
of
seconds
ahead
of
time,
because
it's
it
takes
a
little
while
to
get
going.
Okay,
safar
disappeared.
B
J
The
second
point
I
mean
that
you
have
the
adoption
of
this:
the
crh
and
the
relationship
of
the
adoption
and
the
retirement
has
been
discussed
between
the
routine
area
and
the
intel
area.
I
think
that
if
the
work
is
being
done
for
the
adoption,
I
think
this
not
only
the
entire
area,
but
it
also
should
be
coordinated
with
looking
area
and
the
spring
working
group,
the
third
one
I
want
to
know
that
I
wanted
to
clarify,
I
think,
in
the
adoption.
The
first
adoption.
K
J
B
B
A
L
L
L
L
This
is
the
shape
of
the
hot
by
hop
option.
If
you
haven't
seen
this
before
the
bb
and
c
lines,
just
underneath
the
package
are
the
most
important.
In
other
words,
if
you
are
a
ipv6
router
and
you
get
this
hot
buy
hop
option,
you
can
skip
it
and
continue
processing.
We
prefer
you
to
fill
this
in
because
it
will
tell
us
things,
but
we're
aware
that
some
routers
won't
do
this
and
that's
quite
okay
and
we'd
prefer
you
to
update
it.
L
L
What
have
we
done
when
we
revised
zero,
three
and
zero
four?
We
did
two
revisions
in
the
last
period
and
our
two
revisions
did
a
fairly
big
rewrite
of
the
words.
Our
original
words
were
good,
of
course,
because
we
try
to
write
good
words,
but
they're
now
actually
good
and
readable
by
others,
which
is
a
real
advantage.
L
We
think
so,
if
you
prove
us
wrong,
please
read
it
because
my
final
slide
is
going
to
say
read
this
draft,
because
it's
now
structured
in
a
way
which
is
which
presents
the
different
parts
to
different
people
who
are
interested.
We
talk
about
what
the
router
has
to
do.
We
talk
about
what
the
source
has
to
do.
L
One
of
the
things
that
was
exposed
by
looking
at
the
api
was
there's
probably
two
ways
to
use
the
information.
That's
in
the
option.
The
first
way
is
basically
in
the
way
path.
Mtu
discovery
has
traditionally
used
it.
You
get
a
packet
back
with
some
information,
you
use
it
at
the
ipv6
layer
or
you
directly
change
the
the
cache
or
entries
you
have
for
path
mtu
for
the
flows
that
you've
received
these
messages.
L
The
upper
layer
then
reads
the
options:
data
it
can
validate
the
options
data
because
it
knows
more
about
the
contents
of
the
packet
which
it
receives
as
a
probe
and
then
highlighted
in
green.
There
is
a
way
for
this
upper
layer
protocol
to
then
throw
away
the
option
data.
If
the
packet
isn't
validated,
it
seems
subtle.
You
probably
have
to
read
the
draft
to
to
understand
it
properly.
L
But
what
this
means
is,
if
the
upper
layer
processes
the
hop
option
data,
then
you
can
have
a
better
security
method,
because
the
hop
option
data
can't
be
easily
injected
off
path.
If
this
happens,
that
that
simple
check
of,
can
you
deliver
it
to
the
upper
layer?
Is
the
upper
layer
expecting
this
packet
with
the
option
attached
to?
It
provides
a
lot
of
extra
security
and
by
thinking
this
through
particularly
the
two
different
ways
you
could
use
the
hot
buy
hop
option.
L
L
L
L
K
B
L
Right
so,
first
set
of
results:
mtu,
okay.
So
what
did
we
find
out?
We
did
a
lot
of
experiments
for
mtu
to
figure
out
what
mtu
we
saw
running
from
these
probes
to
sites
select
the
alexa
top
1
million.
We
looked
at
half
a
million
targets
for
ipv4,
only
300
000
targets
for
ipv6,
but
the
picture
emerges
quite
clearly.
L
So
the
first
bit
of
good
news
is
that
these
from
these
target
locations,
which
are
arguably
not
isp
edge
locations,
we
know
that,
but
for
these
locations
most
of
the
past
got
pathed
to
use
greater
than
1500
bytes,
and
that
applies
for
ipv6.
Also
96,
that's
great.
So
what
happens
to
the
remaining
four
percent
that
it's
slightly
sadder
answer
for
the
remaining
four
percent
path?
Mtu
discovery
works
well
with
ipv6
for
0.05
percent
of
cases.
L
L
L
L
L
But
plp
mtud
relies
on
sending
successive
probes,
so
you
can't
discover
this
in
one
shot.
You
have
to
use
multiple
probes
to
get
there,
and
the
idea
between
the
behind
the
hot
by
hop
option
is
that
you
can
send
discovery
packet
and
avoid
all
that
number
of
probes,
particularly
if
you
want
to
get
a
big
mtu.
That
saves
you
many
many
rtts,
so
good
news
and
bad
news.
Bad
news.
If
you
talk
about
pmtud
for
ipv6
lots
of
people
implemented
it,
but
few
routers
actually
give
you
the
information.
You
need
plp.
B
L
L
Next
slide,
then,
if
we
oh
we're
good,
we
got
it
larger
internet
mtu.
So
my
ambition
in
life,
partly
is
that
we
get
to
use
these
really
big
frames
that
ethernet
actually
provides,
even
though
the
ieee
haven't
standardized
them,
because
we
know
many
line
cards
actually
support
large
mtus
and
we
know
many
servers
have
them,
and
many
client
operating
systems
support
these.
L
L
Well,
one
place
to
look
is
perhaps
in
the
peering
database.
What
do
internet
exchanges
actually
advertise
as
an
mtu?
I
mean
you've
got
to
get
your
packets
via
an
internet
exchange
in
most
cases,
and
the
answer
is
38
in
peering
db
use
a
default,
mtu
51
use
a
1500,
byte
mtu,
probably
the
same
advertisement.
Actually,
so
only
seven
percent
used
a
nine
kilobyte
mtu.
L
L
It
might
not
help
you
in
general,
we
don't
have
isp
data
and
I
suspect,
if
we
had
isp
data,
we'd,
find
that
many
isps
at
the
edge
give
you
1500
or
slightly
less.
We
know
that
from
previous
work,
so
this
isn't
really
a
complete
data
set.
It
just
shows
where
one
of
the
bottlenecks
is,
if
you're
into
content
edge
services,
and
you
have
data
for
the
mtu,
get
to
the
content
edge
to
akamai,
to
cloudflare,
etc.
We'd
love
to
talk
to
you.
That
would
be
fun.
L
L
L
Again,
it's
not
a
bad
piece
of
news.
It's
probably
an
expected
piece
of
use.
We
probably
want
more
data
to
other
types
of
servers
and
we
presented
that
data
last
ietf.
So
for
next
ietf
we'll
have
a
better
set
of
data.
We
could
dig
into
two
of
our
probes
and
tell
you
what
happened
for
two
one
was
in
the
uk,
which
appears
to
be
quite
a
good
place,
because
the
extension
headers
were
fine,
the
service
provider
forward
them.
We
could
probe
the
internet
from
a
home
residential
router.
One
of
them
was
in
bob's
house.
L
We
talked
about
last
iatf.
The
operator
was
comcast,
I'm
I'm
really
hopeful
that
we
have
a
conversation
with
comcast
to
find
out
exactly
what
was
happening,
and
the
news
was
summarized
in
this
quote
here.
So
I'll
read
it
so
that
I
don't
misrepresent
what
they
said:
the
routers
punt
extension
headers
to
the
control
plane,
the
control
plane
bandwidth
is
limited
and
can
be
impacted
if
excess
transit
extension
headers
traffic
is
forwarded
in
current
implementation.
L
That
means
it's
a
good
to
filter,
transit
packets
that
contain
extension
headers
to
protect
the
control
plane
capacity
if
you're
in
v6
hops.
You
probably
saw
this
same
thing
being
discussed
there
in
the
draft
I
put
at
the
bottom
of
the
slide,
and
it
talks
about
more
detail
why
that
might
be
the
case.
L
L
So
we
plan
to
look
more
at
the
edge
see
where
extension
headers
work
at
the
moment.
If
you
want
to
use
the
extension
we
advocating
in
this
draft
across
the
general
internet,
it
may-
or
it
may
not
work-
that
in
itself
is
not
a
disaster
when
it
works.
It
provides
extra
information
when
it
doesn't
work,
just
be
careful
not
to
use
it
on
a
packet
that
you
really
care
for
use
a
probe
packet
to
carry
the
extension
header
or
you
could
use
it
in
the
general
internet.
L
Oh
next
steps-
yeah,
that's
where
we
got
to
so
we
have
a
working
piece
of
code
in
vpp
that
adds
the
field
modifies
it
updates
it
sends
it
up.
So
we
have
one
router
that
could
do
a
proof
that
we
can
actually
do
something
here.
We'd
love
more
people
to
implement
this
really
really
love
to
talk
to
you
and
see.
If
we
could
do
something.
The
target
place
where
this
is
most
useful
is
likely
within
the
data
center
within
a
data
center,
big
mtu
is
often
supported.
The
switches
often
have
the
support.
L
The
routers
might
well
have
that
support,
and
this
would
actually
be
a
big
win
to
letting
you
immediately
verify
that
the
configuration
of
the
device
is
on
path
matches.
What
you
expect
so
looking
for
people
to
implement
the
router
side,
we're
also
looking
for
people
who
are
interested
in
the
host
code,
you
can
use
it
in
a
very
simple
way
and
get
the
information
out
about
your
path.
L
Would
people
be
interested
in
talking
to
us
about
that?
We'll
do
that
experiment
as
well.
Please
talk
to
us
new
data
for
march.
Please
read
this
version.
If
I've
said
nothing
else,
that's
useful,
the
version
now
is
really
readable
and
we
don't
know
how
to
improve
it.
So
please
tell
us,
is
that
my
last
slide.
A
A
While
the
experiments
go
on
or
do
you
do
you
see
any
issue
with
you
know?
From
my
perspective,
this
looks
like
we're
almost
done
right,
that
we
could
push
this
document
forward
and
publish
it,
but
yeah
what
do
you?
What
do
you
prefer?
What
you
see
as
the
most
successful
path
here
for
getting
both
deployment
and
and
publication.
L
I'll
talk
first
and
then
I
think
bob
should
talk,
because
I
don't
know
why
we
agree
yet
on
this.
But
if
people
want
to
implement
this
right
now,
I
would
love
to
talk
to
them,
because
the
more
experience
we
get
sooner,
the
better
everything's
going
to
be
so
no.
I
would
happily
delay
publication
if
there
was
active
work
to
get
this
implemented
and
get
experiments
going
with
this,
then
maybe
it
didn't
happen
be
experimental.
Perhaps
I
could
push
you
to
do
a
ps
because
we
actually
knew
about
it.
L
L
B
B
A
L
K
A
A
K
Hello,
everybody:
this
is
an
update
about
our
draft
on
application
of
alternate
markings,
so
next
live
yeah.
Just
a
quick
recap
regarding
the
methodology
from
whom
is
not
very
familiar
with
this
kind
of
methodology.
So
alternate
markings
allow
a
passive
performance
measurement
technique
to
make
measure
packet,
loss,
delay
and
deliveration.
K
K
K
In
this
case,
the
ultimate
marking
is
extended
for
multi-point
flows.
In
this
case,
you
can
also
monitor
the
full
network,
or
otherwise
you
can
select
select
the
subnetwork
to
monitor
at
different
levels.
This
allows
flexible
performance
management
approach,
so
you
can
go
to
monitor
a
sub
network
up
to
a
single
flow
or
a
single
link.
K
K
K
K
We
are
requesting
an
option
adder
that
can
be
a
non-biop
or
destination
based
on
the
type
of
performance
measurement
you
want
to
enable
in
general,
the
source.
Node
is
the
only
one
that
writes
this
option,
either
to
mark
the
flows,
but
the
intermediate
or
destination
nodes
passively
receive
and
read
these
bits
to
perform
the
measurement,
but
they
did
not
modify.
K
K
K
Slide
the
reason
for
the
introduction
of
this
pro
monitoring
identification
field
is
requirement
for
implementation
reason,
because
to
allow
a
flexible
measurement,
you
have
to
reduce
the
per
node
configuration
in
order
also
to
increase
the
number
of
flows
that
you
want
to
monitor
and
the
use
of
acl
is
limited.
So
that's
why
it's
better
to
have
an
identification
field
in
the
in
our
cld.
K
M
K
K
Some
discussion
about
the
uniqueness
of
the
this
field
because
it
can
be
set
by
a
centralized
controller
and
the
controller
can
have
the
construct
the
nodes
in
order
to
guarantee
uniqueness
of
these
into
malignant
pi.
Otherwise
it
can
be
randomly
generated
by
the
source
node,
but
in
this
case
there
are
some
possibility
to
have
the
collision
a
chance
of
collision.
For
example,
if
we
are
going
for
20-bit
flow
monitor
identification,
there
is
a
50
chance
of
collision
for
1,
1,
1,
200
flows.
K
You
can
prefer
general
in
many
cases
when
measurement
is
not
enough,
so
it
could
be
required
job
by
of
measurement,
but
even
if
for
rob
biops,
I
know
that
there
is
some
discussion
about
the
applicability
and
in
any
case
there
is
no
problem,
because
even
if
a
non-part
node
does
not
is
not
configured
to
read
this
option,
the
up
by
op
is
made
only
for
the
nodes
that
are
configured
to
to
read
these
option.
So
this
not.
This
does
not
affect
the
measure.
K
Yeah
regarding
the
security
consideration,
so
there
are,
of
course,
some
security
concerns,
but
are
limited
because
the
ultimate
market
implies
modification
on
the
fly
to
an
option
other.
So
but
in
any
case,
the
information
is
very
limited
and
this
must
be
performed
in
a
way
that
does
not
alter
the
qrs
experience
regarding
the
head
to
the
measurement.
K
Yeah
the
change
from
the
last
version.
We
addressed
the
comment
from
ron
about
the
time
the
timing
aspect
of
this
methodology,
because,
yes,
I'm
concerned
about
the
resiliency
of
reordering,
but
there
is
a
mathematical
formulation
in
both
rfc
321
and
lx3889
about
that,
and
we
also
include
a
small
paragraph
that
describes
how
the
alternate
marking
means
resilient
to
this
kind
of
reality.
K
K
A
B
K
K
A
It's
just
to
wait
until
prague,
then
hopefully
we
will
try
to
make
some
progress
between
now
and
then.
If
things
come
up,
I
guess
the
barrier
to
do.
Interim
meetings
is
lower
now
than
than
normal
as
well.
So
we
that's
certainly
something
we
could
do
if,
if
it's
required,
but
otherwise,
we
will
virtually
see
you
in
prague.
L
A
B
B
A
I
B
B
K
A
K
K
B
So
I
think
it
does
work
better
to
just
call
the
question
you
know
after
the
before
or
after
the
talk
than
to
do
it
during
the
talk
or
else
maybe
it
bill
works
better
at
the
end
of
the
session,
when
people
are
tired,
when
I
go
home
but
okay
well
good,
I
will
end
this
look
good,
so
I
think
we
will.
Thank
you
all.
I
think
it's
been
a
good
meeting
two
sessions,
it's
2
20
in
the
evening
in
the
morning.
For
me,
some
of
you
are
in
better
time
zones.