►
From YouTube: IETF113-INTAREA-20220322-1330
Description
INTAREA meeting session at IETF113
2022/03/22 1330
https://datatracker.ietf.org/meeting/113/proceedings/
A
B
A
A
A
A
So
we
are
going
to
ask
you
to
to
help
us
if
you
want
to
ask
a
question:
do
join
the
queue
online,
even
if
you
are
local
here
or
remote,
so
that
we
can
handle
the
order
of
the
people
and
we
will
give
you
the
voice
for
those
that
have
not
seen
it.
Please
keep
your
mask
on
all
the
time
and
approach
the
mic
only
when
you
are
called
and
your
turn
to
the
queue
is
arriving
for
everyone
else.
A
A
A
This
is
the
agenda
that
we
have
for
this
meeting.
We
have
eight
items.
So
first
is
the
our
welcome
this
presentation
right
here,
giving
you
the
status
and
update,
but
right
now
we
don't
have
any
working
group
documents.
So
it's
a
slight
one.
Then
we're
going
to
have
set
talking
about
ipv4
polishing
at
the
etf
thread,
with
rfp
parcels
luigi
for
internet
address
gaps,
then
we
have
the
ip
regional
internet
blocking
considerations
by
lenny
semantic
ip
addressing
for
satellite
higher
layer
address
aggregation
by
tony
and
service
routing
in
multi-access
edge
computing.
A
A
D
C
C
C
C
C
C
So
there's
been
some
disagreement
about
how
large
or
how
exclusive
this
concern
was,
but
we
perceived
that
a
very,
very
substantial
amount
of
the
objection
or
the
concern
about
our
proposals
in
november
was
based
on
the
fact
that
they're
ipv4
specific
fixes
people
said
a
lot
of
things
that
were
quite
disparaging
toward
ipv4
toward
continued
engineering
work
on
ipv4
toward
the
role
of
such
work
in
the
ietf
and
the
the
strongest
concerns
that
we
noticed
and
the
most
frequently
stated
that
we
noticed
appeared
to
be
versions
of.
Should
the
ietf
still
work
on
fixing
ipv4.
C
C
The
feedback-
sorry
about
that
yeah,
so
a
main
output
of
the
sunset
four
working
group
in
2016
made
this
proposal,
and
this
went
for
went
up
for
review
as
an
ietf
wide
consensus
and
the
community
had
quite
substantial
concerns
about
it
and
it
didn't
reach
a
consensus,
and
so
our
hope
is
to
see
if
the
opposite
consensus
can
be
found.
That
is
people
had
objections
to
the
idea
that
ietf
should
not
do
this
work.
C
C
We've
found
a
lot
of
opposition
to
ipv4
work,
but
no
clear
policy
that
we
can
or
can't
do
it.
So
I
would
ask
somewhat
rhetorically,
but
also
somewhat
concretely
and
somewhat
practically.
Can
we
clarify
what
common
sense
and
what's
serious
mean,
and
I
would
note
that
the
other
proposal
that
we
talked
about
last
time,
the
unicast
240
slash
4-
is
already
the
existing
behavior
of
billions
of
devices
and
it's
plausible,
but
it's
actually
the
behavior
of
the
majority
of
internet
nodes.
C
But
it's
something
where
there
is
far
from
universal
compatibility.
But
it's
quite
a
widespread
behavior
and
it
seems
striking
to
say
that
this
isn't
serious
when
it's
a
behavior,
for
example,
that's
already
implemented
in
perhaps
the
majority
of
nodes
and
billions
of
devices
across
the
internet,
and
I
guess
more
concretely.
C
C
So
I
would
hope
that
we
could
get
and
reach
some
kind
of
clear
statement
of
ietf's
relationship
to
these
maintenance
and
coordination.
Questions
which
we
think
have
arisen
are
arising
and
will
continue
to
arise,
and
we
query
whether
an
alternate
consensus
may
be
found,
given
the
lack
of
consensus
for
the
declaring
ipv4
historic
position.
That
was
noted
when
that
proposal
was
made
and
looks
like
that's
about
it
and
yeah.
We'll
take
questions
or
comments,
and
thank
you
for
your
attention.
A
E
E
C
I
think
that
kind
of
conspicuously
to
me
as
someone
who's
been
interested
in
ipv6
and
the
ipv6
transition
for
a
long
time.
I
don't
think
that
there
was
really
ever
a
transition
strategy
that
had
such
a
thing
as
an
end
date.
People
famously
have
said.
Well,
there
is
no
flag
day
right.
This
transition
appears
to
be
in
practice
an
indefinite
thing.
C
I
don't
mean
to
suggest
that
ietf
should
commit
itself
to
a
position
that
the
ipv6
transition
is
permanent
or
never
complete,
but
I
do
think
that
what
we
observe
is
that
the
ipv6
transition
does
appear
from
the
present
moment
from
the
present
perspective,
to
be
something
that's
very
much
incomplete
and
that
very
much
has
no
projected
end
date
and
that
very
much
is
anticipated
to
last
for
the
immediately
foreseeable
future,
and
so
I
think
it's
worthwhile
to
acknowledge
that.
I
would
be
happy
to
see
proposals
that
try
to
formulate
that
or
try
to
address
that.
C
C
C
Clearly
that
is
a
possible
use
that
could
be
formalized.
That
could
continue.
Unofficially,
in
practice
that
could
be
the
subject
of
an
official
designation,
so
all
of
the
addressing
policy
questions
and
all
of
the
other
policy
questions
our
drafts
have
attempted
to
leave
for
another
day
and
really
focus
on
implementation.
Behavior
and
say
you
may
have
something
in
your
kernel
that
inspects
a
packet
that
inspects
an
address
that
says.
According
to
current
rfcs,
I
am
expected
to
drop
this
packet,
because
this
address
is
invalid.
E
Thank
you
very
much
for
this
very
detailed
question.
I
think
we
share
a
point
that
v6
deployment
should
have
been
done
for
a
long
time.
It's
not
the
case.
Even
if
it's
growing
point
taken
now
as
an
individual
contributor,
I
would
be
very
reluctant
to
use
the
remaining
for
addresses
that
could
be
reserved
for
anything.
We
can
do
just
to
gain
one
year
or
two
year
anyway.
No
no
need
to
reply
on
this.
C
I
mean
I
do.
I
would
like
to
reply
on
that,
because
I
appreciate
the
concern-
and
I
gave
a
presentation
about
this
at
nanog
and
I
had
occasion
to
forward
a
question
about
exhaustion
to
someone
who
actively
works
in
the
secondary
market
for
ipv4,
addresses
and
asked
if
we
were
able
to
use
some
kind
of
auction
or
market-based
allocation
mechanism,
rather
than
the
rir's
non-market-based
historic
allocation
mechanism.
C
In
allocating
a
pool
of
addresses
like
this
for
global
unicast.
How
long
would
they
last
and
his
off-the-cuff
speculation
was
eight
years,
so
I
just
wanted
to
put
that
out
there
in
terms
of
people's
concerns,
because
I
understand
that
the
demand
has
been
quite
voracious
and
that
the
exhaustion
has
happened
quite
rapidly.
Anyway.
I
see
there
are
two
other
questions
and
limited
time,
so
I'd
love
to
get
the
other
questions.
F
Hey
seth,
it's
tom
hill
from
bt.
I
I
think
it's
sort
of
kidding
ourselves
a
little
bit
to
equivocate
between
fixes
that
are
affecting
you
know,
millions
of
people
across
the
world
or
fixes
that
benefit
a
few
people.
We
have
a
lot
of
parallels
of
this
in
the
software
engineering
world.
We
have
a
lot
of
parallels
for
this
in
cars.
We
there
are
huge.
There
are
swathes
of
people
in
the
world
who
are
quite
happy
with
windows.
F
Server
2003,
which
microsoft
has
long
since
abandoned
microsoft,
might
one
day
release
a
fix
for
the
firewall,
for
example,
something
critical,
something
that
genuinely
affects
all
of
those
servers
that
are
still
out
there.
They
might
actually
do
that.
They
could
still
do
that,
but
they're
not
going
to
back
port
usb
3.2
support
into
it,
and
so
you
have
to
think
how
many
people
is
this
going
to
help
in
terms
of
these
fixes
some
things
genuinely.
F
We
should
you
know
we
should
care
if
ipv4
is
broken
properly
broken.
We
should
genuinely
care
about
that.
We
should
not
care
that
some
people
have
elected
to
write
a
usb
3.2
driver
for
their
ipv4
stack.
It's
it's
not
necessarily
going
to
help
as
many
people,
as
you
hope,
and
ultimately
all
of
this
effort
does
detract
from
rolling
out
ipv6,
but
that's
a
couple
of
questions
in
a
statement,
but
in
particular
I
think
we
really
need
to
be
very
honest
with
ourselves
about
the
effort
going
into
this
and
what
it's
for.
C
So
I
appreciate
the
distinction
that
you
draw,
that
there
are
different
kinds
of
fixes
and
that
there's
different
scope
in
the
benefit
of
different
fixes,
and
that
may
go
to
arguing
that
some
of
the
examples
that
we've
given
of
other
ongoing
ipv4
maintenance
may
not
be
viewed
as
exactly
analogous
to
our
proposals
and
without
having
analyzed
all
the
details
under
that
rubric.
I
can
say
that
seems
to
be
a
possible
point
of
argument.
C
G
Now,
so
I
think
it's
what
we
should
be
doing
with
ipv4,
so
I
have
no
objections
to
before
being
in
maintenance
mode,
but
it
doesn't
mean
we're
going
to
develop
new
stuff
and,
secondly,
I'm
a
bit
confused
about
a
few
slides
in
your
presentation.
So
you
propose
if
some
work
did
not
get
enough
consensus
and
not
enough
interest,
do
you
think
that
getting
higher
level
statement
about
doing
more
work
in
ipv4
would
help?
I
was
under
impression
that
you
bring
in
some
work
to
atf.
G
A
A
A
H
H
H
Instead,
they
put
as
many
of
the
small
boxes
as
possible
into
one
or
a
few
larger
boxes
or
parcels
and
then
place
the
parcels
on
a
semi
truck
or
an
airplane.
The
parcels
arrive
at
a
regional
distribution
center
where
they
may
be
further
redistributed
into
smaller
parcels.
They
get
delivered
to
the
consumer,
but
most
often
the
consumer
will
only
find
one
or
a
few
parcels
at
his
doorstep
and
not
50
individual
boxes.
H
So
a
is
formed
when
an
upper
layer
protocol
identified
by
the
five
tuples
source,
ip
destination,
ip
source
port
destination,
port
and
protocol
produces
a
buffer
with
up
to
64
upper
layer
protocol
segments.
All
segments
except
the
final-
must
be
equal
length.
They
can
be
up
to
65
64
k,
octets
minus
headers.
H
H
So
ip
parcels
are
based
on
the
jumbograms
construct.
They
include
a
jumbo
payload
option,
but
they
have
a
non-zero
value
in
the
payload
length
field,
whereas
true
jumbos
use
the
value
0
in
that
payload
length
field,
the
payload
length
gives
the
length
of
the
first
segment.
Only
the
jumbo
payload
length
gives
the
length
of
the
entire
parcel.
H
So
we
have
ip
parcel
support
for
both
v6
and
v4.
So
to
to
do
that,
we've
defined
the
jumbo
payload
option
for
ipv4
the
maximum
ip
parcel
size
is
the
64
segments
times.
The
maximum
64k
per
segment
slightly
under
four
megabytes
is
the
largest
parcel,
and
here
on
the
right,
you
see
a
diagram
showing
the
construct
of
a
parcel
where
we
have
an
ip
header
and
k
segments.
I'm
sorry,
j
segments
all
all
within
the
same
ip
packet.
H
Some
related
work,
a
concept
known
as
generic
segment
and
receive
offload
is
implemented
in
some
os
and
nics.
Linux
implements
it.
For
example,
the
upper
layer
protocol
can
supply
multiple
segments
in
a
single
system
call.
There
was
a
study
with
the
quick
protocol
that
showed
significant
performance
increases
using
gso
and
gro.
H
H
Another
study
known
as
big
tcps,
considered
end
system
internal
implications
of
jumbograms
for
better
performance.
So
what
ipparcels
is
really
proposing
is
a
combination
of
the
results
of
these
studies,
which
is
the
gso
gro
style
segmentation,
plus
ip
fragmentation
with
ip
jumbograms
for
network
transmissions.
H
Then
a
singleton
parcel
is
an
ip
header.
With
jumbo
payload
option
and
a
single
upper
layer
protocol
segment
of
length.
L,
then
a
multi-segment
parcel
is
an
ip
header
with
jumbo
payload
option:
j
minus
one
upper
layer,
protocol,
segments
of
length,
l
and
the
final
upper
upper
layer
protocol
segment
of
length,
k,
which
must
be
less
than
or
equal
to,
l.
H
So
there's
a
first
pass
in
the
adaptation
layer
which
partial
fragmentation
occurs.
These
are
loosely
reassembled
with
opportunistic
merging
and
a
second
pass
in
which
ip
fragmentation
is
applied
to
individual
sub-parcels,
and
here
we
need
strict
reassembly
with
fragment
re-transmission
if
necessary.
H
H
H
Now,
in
terms
of
integrity
link,
layer
checks
like
crc32,
can
miss
errors
in
packets
that
are
larger
than
about
9k
bytes.
But
I
t
parcels
are
often
much
larger,
but
fortunately
ip
parcels
include
a
separate
integrity
check
for
each
upper
layer
protocol
segment.
So
if
there's
many
of
them
there's
many
integrity
checks
in
the
parcel.
H
H
So
the
next
steps
are
that
we
want
to.
We
see
that
I
p
parcels
increase
the
efficiency
and
performance
for
end
systems.
Iparcels
provide
a
path
forward
for
larger
mtus
in
the
internet.
Iparcel
spec
is
in
advanced
stages
of
development.
Here
it
is
the
point
of
the
data
tracker
and
I
want
to
ask
now
if
we
can
adopt
ip
parcels
as
a
working
group
item.
A
A
H
So
we
we
have
two
studies
that
show
that,
by
sending
multiple
segments
in
a
single
system
call,
it
reduces
the
number
of
interrupts
and
it
reduces
the
overhead
of
packaging.
The
the
parcel
and
for
transmission
across
networks
that
have
larger
mtus,
larger
packets,
increase,
fewer
interrupts
and
more
efficiently.
A
H
I
So
luigi,
I
had
a
similar
question
on
the
performance
idea.
I
mean
in
slide
nine.
If
I
remember
correctly,
you
say
we
have
a
bunch
of
links
that
support
ip
parcel.
They
may
go
through
links
that
do
not
support
ip
parcels.
So
basically
you
have
operation
going
on
inside
the
network.
So
at
least
at
the
beginning
of
the
deployment
you
will
have
a
performance
hit
because
you
have
to
man
change
a
little
bit
the
way
you
you
aggregate
or
disaggregate,
fragment
or
reassembly
the
packets
right.
H
If
I
understood
the
question
correctly,
the
ability
to
know
when
to
use
parcels
is
a
not
a
performance
intensive
operation.
When
you
send
these
things
called
parcel
probes,
which
I'll
put
the
thing
back
up
again,
what
you
would
normally
do
is
you
start
sending
regular
ip
packets
and
then
send
a
parcel
path,
qualification
probe?
If
the
probe
succeeds,
then
you
can
begin
sending
ip
parcels.
H
D
I
I
Okay,
okay,
again,
I'm
luigi
I'm
actually
going
to
present
tools
to
just
an
update
on
two
drafts
about
internet
addressing.
We
have
out
there
two
documents,
the
problem
statement
and
the
gap
analysis
a
little
bit
of
telenovelas
in
the
sense
that
what
did
happens
is
one
one.
Two
we
had
a
side
meeting
at
that
point
and
dirk
reported
in
this
very
working
group.
So,
based
on
the
side
meeting,
we
formulated
three
three
questions
that
you
asked
to
the
mailing
list.
So
what
exact
features
do
we
want
from
the
internet
where?
I
I
Actually
ip
parcels,
if
I
remember
correctly,
is
a
spinoff
on
discussion
started
on
the
mtu
issue
on
about
the
the
first
question,
so
for
each
and
every
thread,
what
we
did
is
try
to
summarize
the
discussion
in
an
email
in
order
to
check
if
our
understanding
was
okay
and
we'll
show
you
that
in
the
next
three
slide,
and
actually
even
after
the
summarization
that
we
we
did
when
we
we
thought
the
discussion
was
more
or
less
over.
Actually
discussion
actually
went
on,
which
is
good.
I
We
tried
to
incorporate
everything
this
included
some
private
email
exchange
in
order
to
be
sure
that
we
captured
correctly
what
some
people
said
on
the
email.
Okay,
so
and
actually
we
had
three
new
quarters
on
the
document:
laurent,
abraham,
chen
and
dino
farinacci,
but
actually
there
is
a
contribution
of
a
lot
of
people
there.
Okay,
so
first
question:
what
exact
features
do
we
want
from
the
internet?
The
the
summary
of
the
discussion?
One
was
a
a
list
of
features.
I
I
just
put
the
keywords,
but
actually
this
resulted
in
a
in
a
new
section,
section
3
in
the
problem
statement
and
each
and
every
point
here
has
been
developed
in
a
consistent
way
with
a
good
paragraph,
I
would
say
so
very,
very
good
input
that
we
received.
Second
one
was
where,
and
how
is
the
futures
innovation
happening?
So
the
summary
of
that
discussion
is
that
not
surprisingly,
a
certain
way,
we
have
two
dimensions.
I
One
is
the
horizontal
dimension,
so
it's
age
versus
core
okay,
the
other
is
the
vertical
dimensions
is
about
which
layer
of
the
protocol
stack.
So
and
obviously
this
is
not
just
one
of
all
the
other.
It
happens
in
a
hybrid
way.
I
would
say,
then
there
were
points
about
how
much
unique
and
globally
rootable
an
address
should
be.
This
is
somehow
linked
to
the
discussions
that
we
see
around
about
internet
consolidation
or
centralization
depends
which
terminology
you
like
to
use.
I
I
The
third
question:
what
is
an
address
anyway,
so
this
specific
question
went
beyond
any
expectations
that
we
had
went
beyond
the
the
just
submission
cut-off
date.
Okay,
the
discussion
went
on
for
a
long
time.
Even
recently,
there
were
some
some
follow-up
emails
on
that
went
beyond
the
entire
mailing
list,
mostly
in
the
architectural
discussion.
I
Okay
and
then
you
have
a
certain
kind
of
mappings,
which
is
could
be
one-to-one,
there's
a
classical
unicast
or
something
more
revolved,
and
this
has
also
brought
a
lot
of
changes
in
section
5
on
the
problem
statement
document
and
again
a
little
bit
here,
a
little
bit
there.
Everything
is
on
the
data
tracker,
okay,
so
I
will
go
quickly
through
the
main
changes.
I
apologize
for
the
title
that
I
messed
up
somehow
didn't
know
this.
I
There
are
two
sections
in
the
problem
statement:
2.7
is
about
communication.
Protecting
privacy
is
a
work
in
progress.
To
be
honest,
the
plan
is
because
the
privacy
issues
has
been
raised
several
times.
In
all
the
questions
we
will
try
to
to
fetch
input
from
the
prg
research
group,
so
the
privacy
enhancement
and
assessment
research
group.
I
think
it's
the
right
community
to
ask
for
and
then
there
is
this
desired
network
features
that
is
more
or
less
the
the
list
that
I
showed
you
before
again.
I
We
with
all
the
text
that
comes
along
in
order
to
describe
what
are
those
features
and
other
important
changes
are
in
section
four.
We
have
a
new
part
of
about
hampering
privacy
and
in
the
problem
statement
section
itself,
we
added
some
improved
input
from
the
discussion
that
took
place
actually
in
the
architectural
discussion
mailing
list
about
the
question.
What
is
an
address
anyway,
on
the
gap
analysis
document,
the
main
changes
is
section:
five
is
a
new
one.
I
We
call
it
a
system
view
on
addresses
it's
where
we
discuss
about
this
two-dimensional
space,
where
the
innovation
takes
place.
Okay
and
we
we
try
to
describe
what
are
the
different
implications
and
how
it
happens.
Okay
and
then
there
are
a
bunch
of
other
important
changes
that
we
we
have
in
in
several
sections
about
the
extension
in
the
length
of
the
addresses
or
we
added
new
examples
about
chic
yeah
is
ip
or
what,
if
we
have
addresses
that
are
actually
longer
than
128
bits,
okay
and
a
discussion
about
semantic
extension
and
some
improved
conclusion.
I
Now,
as
for
the
status
of
these
two
documents,
now
I
give
you
an
app.
I
gave
you
just
an
update
on
the
content.
The
content
of
the
documents
is
for
the
problem
statement
to
provide
an
example
and
scenarios
where
the
the
existing
internet
addressing
is,
is
a
potential
entrance.
Okay
and
then
there
is
a
gap
analysis.
I
What
is
this
happening?
What
has
been
done
in
order
to
improve
in
a
certain
way,
they're
addressing
and
in
a
certain
way.
This
represents
the
fact
that
there
are
solutions
trying
to
fill
in
a
gap.
That's
the
content,
but
the
real
purpose
that
we
we
said
since
the
beginning
was
to
bring
the
community
to
discuss.
Addressing
okay,
and
certainly
we
had
a
difficult
start.
I
Okay
covet
19
didn't
help
at
all,
I
would
say,
but
finally
we
we
we
we
made
it
in
the
sense
that
there
was
a
lot
of
discussion
and
we
tried
to
to
to
gather
all
the
different
facets
that
we
we
saw.
We
just
left
out
at
this
stage
any
any
discussion
or
text
that
was
going
too
much
into
solution
space,
because
it's
not
the
scope
of
these
two
documents.
Okay,
which
brings
me
to
the
last
slide.
I
To
be
honest,
so
I
think
these
two
documents
document
a
community
effort,
all
the
co-authors
that
are
on
board.
They
do
agree
that
they're
bringing
value
in
the
sense
that
documents
something
or
concerns
that
that
are
there
okay.
So
all
their
crowd
was
think
that
this
world
thinking
about
working
group
adoption
here
in
the
interior,
okay,
looking
long
term,
but
we
don't
discuss
this
now-
is-
was
thinking
that
what
should
we
do
next-
and
this
goes
again
back
to
community
discussion
on
what
should
we
do
once
we?
I
D
I
A
A
L
But
I
cannot
move
how.
How
can
I
move
this?
Oh
yeah
yeah
use
it.
Okay,
got
it
all
right,
hello,
everyone!
This
is
zelin
and
presentation,
is
about
satellite
network
and
problem
and
solutions
from
airstrip
perspective,
and
this
is
this
works
start
from.
Probably
I
ietf
111,
we
published
the
problem
statements
and
later
on,
we
published
some
draft
draft
about
solution.
L
L
What
we
plan
to
do
is
that
we
want
to
provide
the
basic
ip
connectivity
or
basic
for
satellite
network
and
all
drafts
so
far
are
only
informational
experiment
and
right
now
we
expect
more
feedback
from
different
wg
and,
of
course,
right
now.
People
may
feel
confusing
to
understand
whole
solution
because
there's
no
dedicated
working
group
in
itf,
so
I
can
only
present
different
pieces
of
solution
to
different
working
group.
L
L
And
if
you
want
to
see
more
explanation,
you
can
go
to
this
slide
deck.
We
have
a
kind
of
a
presentation
before
to
our
collaborator
university
story
to
discuss
the
problems
for
the
satellite
and
the
problems
for
3gpp
and
iitf,
and
in
this
slide
I
also
try
to
answer
questions
which
arises
before
ietf
meeting
and
also
in
the
youtube
sets
mayor.
L
Alias
most
of
questions
are
not
very
technical
details
about
my
our
proposal
is
about
why
we
need
to
do
this
and
why
the
current
satellite
networking
company
didn't
raise
any
question
to
ietf
those
kind
of
things.
Also,
we
give
some
introduction
about
the
ng-run
requirement
for
cellular
network
from
there.
You
can
see
that
ip
is
a
kind
of
instructor
for
the
for
the
whole
architecture,
so
we
have
to
provide
ip
connectivity
to
to
them.
L
L
Here
I
just
give
more
discussion
about
the
semantic
address,
because
this
is
probably
the
interest
of
this
working
group
and
the
semantic
address
is
it's
a
we
designed
dedicated
for
satellite
network,
because
li
network
is
very
special.
It's
not
like
the
network
on
ground
satellite
network
is
very
organized.
Even
they
are
moving
very
fast,
but
they
are
moving
on
the
same
speed
if
they're
on
the
same
attitude,
so
we
propose
to
use
the
three
index
to
represent
each
satellite
dynamically,
because
those
index
never
change.
L
Even
satellite
position
is
changing,
so
we
have
a
share
index
which
will
describe
the
which
share
or
which
layer
of
satellite
the
this
will
be
determined
only
by
the
altitude
and
the
inclination
angle.
So
if
every
satellite
has
the
same
altitude
and
incontination
angle,
those
satellites
are
belong
to
the
same
shift.
The
skill
index
will
be
set.
L
Also,
the
orbit
plane
index
is
that
the
from
the
picture
you
can
see
the
the
lines
connect,
different
green
dots,
their
orbits
and
the
object
plane
is
that
the
some
satellites
were
moving
on
the
same
orbit.
The
those
index
will
be
same
and
the
satellite
index
is
that
for
each
satellite
on
the
same
orbit,
which
position
or
a
relative
index
in
that
object.
L
So
from
this
three
index
we
can
uniquely
identify
each
satellite
in
a
satellite
concentration
and
for
the
this
semantic
address
pro
draft
we
for
the
let's
update,
we
add
co-author
and
also
add
one
section
which
is
a
32-bit
semantic
address,
and
why
we
add
this
section
is
because
the
satellite
network
is
related
to
the
closed.
So
if
we
use
ipv6
it's
pretty
much
overhead,
if
we
can
use
a
much
shorter
address,
it
will
be
a
big
7
and
the
satellite
network.
L
L
So
here
is
a
review
of
how
the
topology
looks
like
we
have
50
percent
satellites
moving
to
one
direction
and
another
50
percent
satellite
moving
to
different
directions,
every
satellite
moving
very
fast,
more
than
seven
kilometers
per
second,
and
also
every
device
on
ground.
We
are
moving
with
the
earth's
rotation,
which
is
also
very
fast,
more
than
even
faster
than
sound
speed
and
the
link
metrics
keep
changing
and
the
ground
state
station
to
cell
life
link
also
keep
flipping
instead.
L
In
addition
to
the
link
matrix
change,
so
what
is
the
problem
using
igp?
Of
course
igp
can
be
used
here,
but
the
problem
is
that,
because
the
the
link
states,
this
changes
so
frequently
the
service
time
will
be
dramatically
reduced
because
the
number
of
the
unsteady
link
is
huge.
We
have
some
paper
and
an
analyze
that
says
that
less
than
20
is
a
is
a
kind
of
usability
which
is
not
tolerable
to
the
service
provider
and
then
well.
L
When
we
try
to
find
the
solution
for
the
satellite
routing,
we
have
to
think
about
the
special
characteristics
for
satellite
network.
So,
first
of
all,
the
the
cellular
network
is
not
like
the
regular
network.
It's
it
is
kind
of
a
carrier
network
of
which
means
the
the
the
satellite
network,
of
course,
with
the
intercellular
link,
it
will
only
only
do
the
transport
work
and
satellite
network
is
very
organized.
L
So,
as
I
said,
it's
multi-layer
of
grid
network
even
interleaved,
and
moving
to
different
direction.
Also,
there
are
limited
number
of
into
satellite
link
because
those
links
are
very
expensive,
probably
six
or
a
little
bit
more
than
six
will
be
enough
for
swiss.
A
a
satellite
in
3d
space,
so
we
can
use
a
self-explanatory
semantic
address
to
identify
each
satellite,
as
I
said
for
that
draft
and
importantly
that
satellite
position
is
predictable
when
time
is
changing,
because
every
satellite
orbit
element
parameters
are
known.
L
So
here
is
our
hybrid
solution.
We
think
we
need
to
use
some
hybrid
technology
to
get
the
final
solution,
and
this
is
the
principle
first,
is
that
we
have
to
use
the
computation
power
in
in
this
space
issues
and
we
have
to
do
the
computation
for
dynamic
topology
for
dynamic
mapping.
Metrics
also
predict
which
ground
station
took
satellite
link
could
be
used.
L
L
Also,
we
we
will
utilize
the
spatial
characteristics
like
I
said,
the
semantic
address
can
be
used
and,
lastly,
that
we
come
out
to
this
instructive
routing,
a
draft
for
the
routing
purpose.
So
the
interactive
writing
is
very
simple.
It's
like
the
semantic
writing,
but
we
because
we
use
a
semantic
address.
We
can
correctly
compress
the
header.
We
don't
need
to
put
the.
L
L
M
Hi
gary
fergus,
thanks
for
the
talk,
it's
really
interesting
to
see
the
internals
of
one
of
these
leon
networks
and
my
question
is
probably
which
operators
are
calling
for
this
work
to
be
done.
Here
I
mean
this
is
a
interoperability
question.
Do
we
need
a
standard
within
satellite
systems
to
do
this,
or
is
this
just
an
interior
routing
protocol
which
we
just
need
to
view
at
the
edges
so
which
operators
are
you
talking
to
or
which
manufacturers
are
asking
for
this
work.
L
A
very
good
question:
I
think
I
have
some
answer
in
the
problem
statement
workshop.
Why
itf
need
to
do
this
from
our
point
of
view?
First
of
all,
the
consolidation
is
right
now,
the
the
operation
mode
is
that
such
as
starting
every
company
providing
its
own
solutions
right,
but
the
problem
is
that
the
orbit
resource
and
the
spectrum
resource
is
very
limited.
L
We
think
in
the
future
the
satellite
network
should
be
shared
by
different
service
providers,
for
example
the
leo
orbit.
They
only
can
hold
about
60
000
satellites
right
now,
starlink
consumed
the
40
000
and
the
china
constellation
consumed
more
than
12
000,
so
we
don't
have
too
many
orbits
resource
right
now.
So
in
the
future,
I
I
believe,
the
due
to
the
resource
limitation
on
the
orbit
and
also
spectrum,
and
also
some
countries
and
anti-trust
regulation.
L
The
satellite
network
could
be
infrastructure.
This
is
also
the
point
from
the
3gpp.
That's
the
satellite
network
is
just
a
kind
of
like
backfill
network.
It
should
be
provided
the
service
by
different
service
provider.
So
from
this
point,
where
we
think
that
ipso
the
the
top
of
the
open
solution
to
the
cellular
satellite
network,
also,
probably
in
the
future,
the
difference
owner
of
the
satellite
could
have
some
interpret
interoperability
issue.
There.
M
L
I
think
they
are
they're
only
right
now.
The
starting
doesn't
need
any
l2
and
l3
solution
because
they
are
doing
the
relay
technology,
but
they
are
testing
the
rsl
from
this
year.
However,
I
don't
expect
reveal
to
the
public
solution
because
there's
some
monopoly
yeah,
that's
the
current.
Their
business
model
is
private.
N
O
O
The
the
content
and
ideas
expressed
in
this
are
solely
the
views
of
the
authors,
and
it
does
not
reflect
as
individuals
and
it
doesn't
affect
the
views
or
positions
of
our
of
any
of
our
affiliations
and
for
those
it
kind
of
goes
without
saying,
but
for
those
who
are
less
familiar
with
ietf
processes
who
might
be
watching
as
perhaps
newcomers.
This
is
an
individual
contribution
and
does
not
reflect
or
represent
itf
consensus.
E
And
if
you
just
allow
me
to
emphasize
what
you
just
said
for
the
people
listening
to
this
on
youtube
later,
I
am
the
internet
era
director
and
thank
you
so
much
for
clearly
spelling
out
that's
an
individual
contribution,
and
indeed
that's
not
representative,
sorry
for
repeating
what
you
just
said.
Thank
you.
O
Not
at
all,
thank
you
eric
for
clarifying
all
right
now,
let's
get
to
the
fun,
so
just
a
little
bit
of
background
and
motivation
and
the
purpose
behind
this
draft.
In
light
of
recent
geopolitical
events,
there
have
been
discussions
in
various
circles:
technically
non-technically
political
on
the
concept
of
blocking
internet
connectivity
for
a
country
or
a
region.
O
What
we
wanted
to
do
is
describe
what
that
might
look
like
kind
of
some
well-known
approaches
for
blocking
connectivity,
that
service
providers
use
fairly
frequently
and
commonly
and
then
describe
the
implications
of
either
of
each
of
these
approaches.
The
positive
negative,
the
advantages
disadvantages.
O
The
intended
audience
for
this
document
is
policymakers
and
kind
of
the
general
public
at
large.
Pretty
much
all
the
people
who
aren't
in
this
room,
but
who
are
interested
in
the
topic
and
would
like
to
know
what
would
this
look
like?
We
do
not
take
any
position
about
whether
this
is
a
good
idea
or
a
bad
idea,
but
what
we're
trying
to
provide
is
some
background
information
on
what
this
might
look
like,
so
that
those
who
do
have
opinions
on
the
matter
and
can
can
can
have
informed
opinion.
O
What
this
document
is
not,
we
are
not
again
advocating
for
or
against
any
particular
policy
or
position.
We're
not
saying
that
this
is
a
good
idea
or
a
bad
idea.
We're
just
reporting
the
news
and
and
let
others
decide
on
the
basis
of
some
of
the
information
we're
providing
not
providing
any
political
opinion
or
analysis
on
the
ethics
of
blocking
connectivity
to
the
internet.
O
Also,
we
would
like.
Obviously,
this
document
has
been
inspired
by
recent
events,
but
it's
probably
not
going
to
be
the
last
time
or
the
last
conflict
that
might
inc
inspire
discussions.
So
we'd
like
this
to
be
generic
enough
to
be
applicable
beyond
just
a
single
event
and
be
maybe
valuable
for
the
future,
and-
and
perhaps
you
know
it,
it
could
be
useful
for
you
know
before
events
take
place,
it
could
be
helpful
in
maybe
guiding
actions.
O
It's
also
not
a
guide
for
blocking
against
security
threats.
You
know,
there's
some
and
I'll
talk
about
some
of
related
work
that
covers.
If,
if,
if
a
network
or
a
region
is
attacking,
you
know
blocking
that
region.
That's
that's
a
completely
different
issue.
This
is
not
protection
from
a
region,
but
more
so
about
sanction
kind
of
the
the
or
the
the
internet
connectivity.
Equivalent
of
you
know,
economic
sanctions,
think
of
it
as
connectivity
sanctions.
So
that's
kind
of
the
use
case.
O
We've
envisioned
here
we're
also,
you
know
not
producing
a
how-to
guide
on
weaponizing
or
you
know,
magical
industry
secrets
on
on
killing
access
everything.
We've
limited
all
of
the
approaches
to
well-known
ideas
and
approaches
that
operators
use
frequently
to
to
legitimately
filter
and
block
internet
access.
O
So
we
don't
believe
that
we
are
giving
away
or
planting
seeds
or
adding
any.
You
know
that
there's
nothing
groundbreaking
here
in
terms
of
what
we're
doing
these
are
all
well
well-known,
well-understood
techniques
that
have
been
documented
elsewhere.
We
believe
it's
also.
We
we
didn't
go
into
the
area
of
malicious
attacks,
either
physically,
you
know
bombing
in
infrastructure
or
you
know,
through
cyber
attacks
or
things
like
you
know,
dns
cash
poisoning.
I
think
those
are
interesting
topics
and
probably
worth
another.
O
You
know
document,
but
it's
it's
kind
of
outside.
It
seemed
too
broad
of
an
area
and
it's
kind
of
outside
the
area
of
expertise
to
the
authors.
So
we
kept
that
out
of
scope
for
this
document,
all
right
with
that
out
of
the
way,
the
actual
meat
of
the
document
blocking
techniques.
So
we
kind
of
start
from
the
physical
layer
and
work
our
way
up
so
disconnecting
cables.
You
know
how
effective
would
that
be?
O
O
Next,
we
we
cover
packet
layer
at
the
data
plane
discussing
things
like
goip
access,
control
lists
and
finally,
we
talk
about
dns
things
like
you
know,
undelegating
top
level
domains
or
other
relevant
domains.
Also,
the
idea
of
blocking
resolution
requests
either
coming
from
name
servers
or
end
hosts
in
a
given
region.
O
O
O
O
O
O
O
You
know,
multinational
entities
and
those
routes
and
autonomous
systems
could
be
advertised
from
other
places
in
different
regions.
There's
the
cloud
in
any
event:
it's
it's
it's.
There
are
porous
borders
and
it's
difficult
to
neatly
say
this
region
or
this
country
only
has
the
routes
coming
in.
You
know
from
entities
that
are
based
in
that
region
also
they
can
be
multi-homed
in
different
regions.
O
There
is
registry
information,
but
that
is
notoriously
inaccurate
and,
finally,
the
decentralized
nature
of
the
internet
makes
it
pretty
much
in
you
know
it's
pretty
much
impossible
to
completely
block
a
region.
This
is
kind
of
a
feature,
not
a
bug.
This
is
by
design
the
the
internet
was
kind
of
intended
to
act
like
this.
That
said,
you
can
put
a
pretty
good
dent
in
connectivity
and
throughput
at
certain
there.
O
There
are
certain
chunk
points
where
you
could
pretty
significantly
restrict
access
and
and
do
some
some
harm
if
one
wanted
to
actually
do
that,
there
has
been
some
prior
art
in
this
area.
Rfc
7754
talks
about
blocking
and
filtering,
but
this
document
is
more
focused
at
a
kind
of
higher
level
application
level
transport
host
level
rather
than
network
infrastructure.
O
So
there's
there's
a
good
bit
of
difference
here
that
that
said,
there
are
some
overlapping
themes
on
things
like
efficacy
and
the
importance
of
specificity
when
it
comes
to
filtering
and
blocking
there's
a
draft
in
the
p-e-a-r-g
working
group
on
censorship
and
again
this
is
more
focused
on
censorship
by
regimes
within
their
borders,
rather
than
say
blocking
all
traffic.
Coming
out
of
that
that
that
region
as
say,
you
know,
sanctioned
because
of
the
activities
of
a
regime.
So
it's
more
of
a
directionality
difference,
but
again
there's
there
are.
O
O
O
Are
there
other
blocking
techniques
that
we
didn't
include
that
should
be
included,
and
we
are
requesting
adoption
by
this
working
group?
Another
open
question
is
bcp
versus
informational.
We
kind
of
went
back
and
forth
on
this.
We
don't
have
really
strong
opinions,
we'd
be
happy
to
go
with
consensus
if
this
is
adopted
and
we'd
love,
review
and
comments,
and
with
that
I'd
be
happy
to
take
any
questions.
D
Ted
hardy
speaking,
thank
you
very
much
for
your
time
in
putting
this
together
as
a
presentation,
and
I'm
particularly
appreciative
of
the
fact
that
you
clarified
that
this
was
an
individual
contribution
and
that
you're
now
asking
for
comments
from
the
from
the
group.
I
I'm
about
to
speak
about
the
internet
society
and,
although
I
am
currently
on
the
board
of
trustees
of
the
internet
society,
I
want
to
make
it
clear
that
I'm
not
speaking
for
them.
D
D
There
is
a
generalized
framework
which
they
have
created
to
describe
the
effects
of
internet
blocking
and
the
techniques
of
internet
blocking,
and
they
have
over
time
gone
into
the
specifics
of
the
internet
blocking
on
different
territories
at
different
times.
So,
for
example,
there
was
one
on
the
sudan
that
was
done
in
2019.
D
There
have
been
three
such
impact
reports
on
the
current
geopolitical
situation,
examining
the
current
efforts
to
possibly
remove
russia
from
the
internet.
The
request
by
the
ukraine
government
to
icann
and
the
related
impacts
of
partition
of
the
network
by
these
efforts
so
there's
there's
a
whole
bunch
of
work
that
is
specifically
directed
toward
policymakers.
D
D
O
Thanks
ted
yeah,
I
I
think
that's
that's
great
feedback
and
there's
there's
lots
of
activities
going
on.
I
I
think
I
don't
have
an
answer
other
than
to
say
you
know
what
would
be.
I
would
turn
this
back
to
the
consensus
of
the
working
group
as
well
and
see
if,
if
others
share
that
those
those
opinions
and
thoughts,
so
you
know
if,
if,
if
we
believe
that
this
document
doesn't
really
add
anything
to
what's
already
out
there,
then
you
know
that's,
that's
that's
consensus.
So.
G
Jen
lincoln
just
a
random
network
engineer
I
feel,
like
let's
say
you're
a
doctor
and
you
publish
a
very
well
written,
very
well
thought
article
about
15
best
methods
to
shoot
your
neighbor
in
the
food
with
careful
with
cost-effective
analysis
and
all
this
stuff.
So
it's
basically
how
I
feel
when
I
read
this.
O
P
Thanks
thanks
for
for
the
presentation
and
the
disclaimers,
so
I'm
one
of
the
authors
of
rfc
7754
and
I
thought
I
might
share
a
couple
of
lessons
learned
from
that
process
because
it
was,
it
was
not
easy
and
it
it
shared
some
of
the
same
flavor,
but
obviously
a
very
different
context.
So
we
started
thinking
about
writing.
That
document
also
triggered
by
like
a
specific
event
or
activity
that
was
occurring,
which
was
proposals
of
a
couple
of
dns
filtering
pieces
of
legislation
in
the
u.s
congress,
they're
called
sopa
and
pipa.
P
So
that
was
the
genesis
for
the
document
and
I
think
it
started
out,
maybe
in
a
not
dissimilar
form
from
from
your
document
and
then
over
time
we
really
it
took
a
long
time
to
to
publish
and
so
and
so
completely
missed.
Also,
the
you
know
the
the
event
that
it
was
trying
to
impact,
because
by
the
time
we
got
to
the
publication
that
those
bills
had
already
died
in
congress.
But
the
time
also
gave
us
an
opportunity
to
provide
the
document
with
much
more
structure.
P
And
so
you
pointed
out,
you
know
the
focus
on
particular
aspects
like
the
analytical
framework
that
we
used
looking
at
scope
and
granularity
and
efficacy
and
security
of
each
of
the
different
blocking
techniques.
But
we
started
much
more
towards
what
you
have,
which
is
you
know
not
not
so
much
of
a
framework.
P
But
I
think
that
the
key
difference
between
that
document
and
this
one
is
that,
ultimately,
it
does
have
a
bit
of
a
normative
valence,
because
it's
trying
to
show
which
of
the
techniques
are
consistent
with
the
internet's
architecture
and
which
ones
are
not.
And
I
think
in
the
case
of
this,
like
mass
scale
blocking
that
isn't
really
possible
right,
because,
if
you're
disconnecting
from
the
network,
then
you
are
inherently
not
consistent
with
its
architecture.
And
so
I
think,
other
than
in
these
sort
of
one-off
kind
of
limited,
deep
hearing
cases.
P
You
can't
really
avoid
that
with
with
the
disconnection
or
the
block,
you
know
the
the
outright
blocking
case,
and
that
makes
the
trade-off
between
any
value
that
you
get
from
publishing
this
document
and
the
potential
downsides
of
you
know
implicitly
appearing
to
endorse
any
of
the
techniques.
Much
it's
just
a
much
different
trade-off.
I
think
which
speaks
in
favor
of
of
not
advancing
this,
this
kind
of
document-
and
I
don't
think
you
can
really
avoid
the
you
know
a
political
reading
or
the
political
implications
of
it.
O
N
Q
I
feel
that
whatever
technical,
relevant
and
correct
input
information
follows
in
the
paper.
If
you
begin
this
way,
you
are
inviting
people
to
interpret
this
and
republish
as
either
an
a
threat
of
doing
something
or
the
invitation
to
do
something
like
this
and
well.
Okay,
if
you,
if
you,
if
you,
if
you
really
feed
the
public
discussion
like
this,
that's
something
that
can
hardly
be
repaired.
Q
O
In
terms
of
the
first
question
on,
did
we
consult
diplomatic
resources?
We
did
not.
The
authors
wrote
this
in
their
individual
capacities
as
engineers
with
the
intent
of
providing
information,
the
goal
of
which
would
be
so
that
the
layman,
the
lay
person,
could
find
this
as
helpful
information
in
understanding
this.
O
These
issues
we
intended
it
to
be
sober
without
opinion,
one
way
or
the
other,
and
we
tried
to
take
great
pains
to
make
it
clear
that
we
were
not
endorsing
supporting
or
advocating
any
position
one
way
or
the
other,
but
just
providing
kind
of
a
you
know.
Staying
in
our
swimming
lanes
as
engineers
of
this
is
what
some
of
the
things
that
someone
might
suggest
doing.
O
We
would
welcome
if,
if,
if
we
didn't
do
a
good
enough
job
and
if
there
are
better
ideas
for
making
that
more
clear
in
terms
of
you
know
not
advocating
a
position
like
I
said
that
was
our
goal,
but
if,
if
others
have
better,
you
know,
text
suggestions,
we'd
be
more
than
welcome
to
it.
I
see
your
point
on
bcp.
Like
I
said
it's,
it's
an
open
question,
bcp
versus
informational.
O
O
O
I
I
I
I'm
not
sure
these
these
ideas
would
just
disappear
or
seem
to
be
endorsed.
If
it
was
merely
mentioned
you
know,
so
I
think
it's
up
to
the
you
know
we'd
be
happy
to
hear
the
consensus
of
the
working
group.
Whether
or
not
the
question
is
does
this?
Is
this
an
appropriate
thing
and
is
there
interest
in
discussing
these
issues.
F
I
suspect
it
was
a
necessary
evil
that
there
were
there
was
going
to
be
a
technical
response
to
what
is
effectively
a
political
question
and
I
think,
you've
written
very
well
and
and
and
sean
shown
that
you
know
clearly.
This
is
something
that
you
don't
support,
which
is
good.
I
I
wanted
to
to
draw
your
attention
on
the
basis
that
there
is
a
difference
between
what
you
say
and
how
you
say
it
and
how
you
publish
it.
Have
you
seen
any
of
the
internet
sanctions
project.
F
F
I
fear
potentially
the
raw
information
just
throwing
it
out.
There
may
not
have
been
the
most
considered
approach,
so
in
terms
of
the
questions
posed
in
bcp
versus
information,
all
they
think
is
moot.
I
don't
believe
that
there
should
be
any
further
work
done
to
this
draft
and
I
certainly
wouldn't
support
adoption
by
any
working
group.
R
Hi
ben
schwartz,
I
think
the
I
you
know.
I
appreciate
that
that
you're
looking
for
an
opportunity
to
do
something
constructive
here
and
I
think
that
it
needs
a
little
more
thought
to
figure
out
what
that
is.
You
know
one
one
possibility
that
I
could
imagine
is
is
starting
from
the
other
end
of
the
problem
and
and
also
taking
a
longer
time
horizon.
R
You
know,
I
think
that
just
the
you
know,
since
the
time
that
you
wrote
this
draft,
I
think
the
the
events
that
inspired
it
have
already
evolved
pretty
radically.
I
suspect
that
the
draft
would
look
very
different
if
it
was
written
today
instead
of
two
weeks
ago,
and
so
I
think
that
there's
there's
a
need
to
to
take
a
longer
time
horizon.
L
O
J
Hi
everyone
mallory
noodle,
I'm
the
center
for
democracy
and
technology
yeah.
I
first
want
to
just
say
I
think
the
discussion
has
been
interesting
and
I
I
welcome
that
noting
as
well
that
you
are
all
presenting
tomorrow
at
the
human
rights
protocol
considerations,
research
group
meeting,
which
is
in
the
first
session
tomorrow,
where
I
think
it
might
be
interesting
to
cue
up
more
of
these
sort
of
three
discussions
of
you
know
the
politics.
J
So
I
actually
welcome
that
discussion,
even
if,
like
others,
I
disagree
that
the
draft
should
move
forward
in
its
current
form.
But
I've
also
previously
reached
out
to
you
as
authors,
because
I
think
that
the
the
effort
to
try
to
describe
problems
for
the
internet,
which
is
done
in
the
censorship
draft
that
you've
obviously
read-
and
you
noted
in
your
slides-
is
an
important
one.
J
I
mean
there's
a
lot
of
balance
that
needs
to
be
taken
into
consideration
that
alyssa
and
others
have
pointed
out,
and
you
know
if
that
draft,
which
the
censorship
draft
is
from
november
2014.
So
we're
talking
a
very
long
time
to
be
able
to
get
around
to
describing
these
things
in
just
the
right
way,
with
the
intention
of
helping
network
operators
fix
it
route
around
it
like
harden
the
network
against
censorship,
obviously
not
the
other
way
around,
and
I
think
that
if
there
are
ways
in
which
that
draft
could
do
that
better.
J
J
But
you
know
the
you
know
the
iutf's
in
the
business
of
keeping
things
connected.
I
think
that,
even
if
there
were
sanctions,
even
if
there
were
calls
for
the
intern
internet
connectivity
to
be
included
in
those
sanctions
which
currently
in
this
very
specific
situation,
it
has
not
been
and
has
never
been
in
the
past.
J
If
we're
talking
about
syria,
iran,
iraq,
afghanistan,
like
no
sanctions,
have
included
internet
connectivity
so
far,
even
if
there
were,
we
would
want
the
iatf
to
probably
resist
that
right
in
whatever
ways
it
can
either
by
explaining
that
it's,
you
know
not
proportionate
that.
That's
not
what
they're
we're
in
the
business
of
doing.
If
we
even
take
a
political
stance,
I
think-
and
that's
really
important
so
anyway.
Those
are
my
thoughts
thanks.
So
much
look
forward
to
speaking
with
you
about
it
tomorrow
as
well.
O
Great
thanks,
mallory
and
just
for
the
purpose
of
transparency.
We
we
presented
this
at
ipeg
on
on
sunday
and
we
as
as
marilyn
mentioned,
where
we're
going
to
share
this
with
hrpc
tomorrow,
not
for
the
purpose
of
working
group
shopping.
It's
it's
really.
Interior
was
the
the
only
work
group
we.
We
had
intended
to
request
adoption
but
more
to
share
these
ideas
and
get
more
review
and
feedback
from
a
broader
scope
of
the
community.
A
Okay,
thank
you
very
much.
I
think
you,
you
got
quite
a
bit
of
interesting
feedback
and
I
would
actually
encourage
you
to
look
at
the
references.
If
ever
the
the
audio
was
not
very
clear,
we
got
a
whole
bunch
of
references
bodies
and
documents
that
probably
you
should
consider
so
we'll
make
sure
that
those
are
captured
in
the
minutes.
If
ever
you
missed
them,
but
I
think
the
feedback
was
quite
clear
that
at
this
moment
the
group
doesn't
believe
this
is
a
document
that
should
move
forward.
A
K
K
K
K
We
also
have
a
new
idea
that
basically,
actually
it
was
old,
but
it
could
not
get
written
down
for
how
to
think
about
aggregation.
I
wanted
to
get
this
written
down
before
I
forget
about
it
or
retire,
and
we
did
talk
about
proxy
aggregation
long
ago
that
got
shot
down.
But
what
happens
if
we
did
unilateral
remote
aggregation.
K
K
K
And
the
next
new
idea
is
the
concept
called
abstraction
action
boundary,
and
this
is
100
percent
due
to
noel
chiappa
like
to
thank
him
for
suggesting
this.
Basically,
the
idea
is
that
we
don't
have
to
aggregate
necessarily
at
the
isp
boundary
we
can
aggregate
one
or
two
or
many
steps
past
that
point.
K
What
happens
if
a
remote
as
decides
to
do
remote,
aggregation,
they
decide
they're
on
that
abstraction
action
boundary
and
they
stopped
advertising
and
propagating
more
specifics
and
just
advertised
the
abstract.
The
aggregate,
as
far
as
I
can
tell
this,
is
actually
something
that
works
more
specifics.
We're
going
to
cause
traffic
around
right
around
ispb
but
b
is
still
providing
reachability,
so
he's
not
strictly
in
violation
of
transit
requirements.
K
K
K
K
K
K
If
you
wanted
to
aggregate
a
write
prefix,
for
example,
you
might
take
and
pick
this
line
that
I've
shown
here
in
color
and
that
might
be
your
abstraction
action
boundary,
because
it's
across
a
bunch
of
transnational
links
and
transcontinental
links
where
they're,
presumably
fewer
links.
You
would
capture
the
necessary
parts
for
traffic
engineering
and
wouldn't
lose
any
significant
route.
Optimality.
S
Yeah
so
tony,
when
you're
talking
about
where
the
abstraction
action
boundaries
should
be,
you
know
we've
thought
about
this
for
a
long
time
if
it
should
be
done
on
ingress
versus
egress,
and
the
thing
about
proxy
aggregation,
as
you
as
you
well
know,
is
that
when
you
proxy
aggregate,
I
call
it
kind
of.
Sometimes
you
lie,
because
if
you
advertise,
you
p
to
somebody
you're
making
the
assumption
that
you
can
reach
everything.
S
That's
inside
of
p
everything
that's
more
specific
from
it
and
if
you're
carrying
the
more
specifics
inside
then
you
could
actually
drop
at
that
boundary
versus
aggregating
on
ingress,
which
means
you
believe
you
can
forward
already
all
the
way
to
the
edges
of
the
sp,
and
then
you
give
it
to
your
neighbors,
your
adjacent
neighbors,
and
they
may
not
have
the
more
specifics
and
have
to
drop
it.
So
it
sounds
to
me
logically
and
more
efficiently
that
you'd
want
to
aggregate
on
egress
to
maybe
tail
sites
versus
transits.
T
T
T
T
L
T
E
R
R
F
F
A
Okay,
thank
you
very
much.
We
are
off
time
and
we
won't
have
time
to
to
run
the
questions,
but
we
did
have
three
authors
asking
for
adoption
and
feedback
from
the
group
so
we'll
take
that
to
the
list
regarding
sets
ip
policing
before
policing,
ip
parcel
from
fred
and
the
internet,
addressing
gaps
from
luigi,
so
we'll
take
those
on
the
list.