►
From YouTube: IETF99-PANRG-20170719-1330
Description
PANRG meeting session at IETF99
2017/07/19 1330
https://datatracker.ietf.org/meeting/99/proceedings/
A
C
B
B
Where's
Tommy,
oh
hey,
here's
Tommy
yeah!
So
can
you
do
the
minutes
for
this
and
I
asked
for
a
jabber
scribe?
Frank,
sorry,
I'm
just
messing
with
you:
okay!
B
B
Why
did
that
change
the
now
we
have.
E
A
B
Should
are
oh,
there's
a
well
run
it
off
your
laptop
out
of
the
email,
so
we
just
got
the
the
first
group
of
slides
there.
Apparently
our
CDN
problems,
so
they
may
not
be
appearing
in
the
thing
let's
go
on.
Let's
do
this.
As
I
said,
this
is
the
path
or
networking
proposed
research
group
I'm,
Brian
Trammell.
This
is
Jen
link
OVA,
we
are
your
chairs.
B
B
Please
note
well,
so
our
agenda
today
is
going
to
introduce
what
all
of
this
is
all
about.
We're
gonna
have
three
presentations
sort
of
at
different
points
in
the
space
of
katha
we're
networking.
The
idea
is
really
to
look
at.
These
is
all
sort
of
a
common
theme
in
networking,
all
of
which
is
relatively
close
to
the
IETF,
and
the
idea
is
to
see
if
we
have
a
scope.
That
would
be
interesting
for
founding
a
working
group
or
founding
a
research
group
around
this.
B
There
should
be
a
jar
here
and
I
put
a
dollar
in
it.
Every
time
I
say
working
group.
So
there's
a
lot
of
room
for
discussion
at
the
end.
I
expect
there
will
be
quite
a
few
questions.
Why
are
we
here?
So
we
identified
a
common
theme
of
path,
awareness
and
a
whole
bunch
of
research,
that's
on
the
edge
of
standardization
or
being
standardized
for
them,
the
IETF,
so
the
most,
the
most
obvious,
is
Multi
multi
path,
transport
protocols,
so
NP
TCP
is
the
obvious
one.
This
is
going
for.
B
Standardization,
quick,
has
an
item
on
its
charter
to
look
at
multipath,
though
not
yet
I
believe,
but
it's
definitely
in
scope.
There's
also
a
lot
of
work
on
hybrid
access
approaches.
So
this
is
where
you
take
to
access
network
links
and
you
bond
them
together,
and
you
do
things
with
flows
over
those
you're
actually
doing
sort
of
like
traffic
engineering,
the
access
network.
There
is
the
banana
Boff
on
Monday.
B
That's
an
efforts
been
going
on
for
a
while.
There's
also
work
on
doings
for
proxying,
stuff
and
MP
TCP,
for
this
slightly
more
exotic
are
sort
of
path,
control,
approaches.
Sfc
is
looking
at
this
and
also
segment
routing
work
in
spring,
so
ipv6
segment
routing.
So
the
ability
to
actually
be
able
to
say,
okay,
you
have
to
visit
this
router
and
this
router
and
this
router
on
the
way
that's
pretty
explicit
path,
control
right
now
that
tends
to
work
in
a
single
administrative
domain.
B
There's
work
on
dynamic
interface
and
dynamic
transport
selection,
which
is
another
way
that
you
can
get
your
traffic
to
go
down
different
paths
or
pass
with
different
properties.
So
there's
the
multiple
interfaces
work
in
the
the
myth,
WG.
If
it
was
at
work,
a
rookie
group
or
was
that
I
forget
which
I
should
go
where
that
can
be.
That
was
from
if
and
then
also
some
work
on,
socket
interfaces
and
on
dynamic
transport
selection.
In
the
taps.
Working
group
there
has
been
interest
in
past.
B
Signaling
came
out
of
the
IAB
stack
Evo
program
a
year
ago
next
week,
the
+
Boff
and
then
also
there's
the
alto
working
group,
there's
signaling
about
properties
in
the
path.
In
that
case
it's
sort
of
something
it's
out
of,
and
so
all
these
things
kind
of
fit
together.
There
are
strewn
across
different
areas
in
the
IETF:
they
all
have
kind
of
a
research
angle
to
them,
so
it
it
seemed
to
us
that
exploring
this
theme
does
seem
like
a
job
for
a
new
research
group.
We're
actually
aware
of
other
of
these.
B
You
know,
please
don't
feel
bad
if
we
miss
your
favorite
path
or
where
working
group
we
can
come
and
talk
about
the
scope
of
that
is
like
hey.
Are
you
aware
of
this
or
you
or
this,
because
I
think
some
of
the
information
about
stuff
that's
going
on
in
other
working
groups,
and
these
could
inform
sort
of
a
scope
of
a
research
group.
But
the
point
here
is
basically
show:
there's
there's
a
bunch
of
stuff
going
on
in
this
space
path.
B
Awareness
very
quickly
illustrated
you
have
a
network,
you
have
some
endpoints,
you
have
a
control
plane.
Protocol,
B
control,
plane
protocol
tells
the
network
how
the
traffic
flow
should
go.
This
is
you
know,
routing
101,
usually
here
in
the
inter
domain
space,
that's
BGP
and
there's
a
bunch
of
intradomain
routing
protocols
as
well.
That
interact
with
that.
The
important
point
here
is
that
the
endpoints
have
really
actually
nothing
to
say
about
the
path
rate.
It's
like
here's.
My
address
here
at
the
address
I'm
trying
to
get
to
put
the
packets
on
the
wire.
B
The
control
plane
tells
the
fording
plane.
Let's
do
and
they
end
up
on
the
other
side,
no
selection
of
path
properties.
You
know
in
multipath
TCP,
you
actually
still
don't
have
any
sort
of
awareness
of
the
path
beyond
you
might
point
that
has
two
interfaces
so
that
they
can
get
to
different
paths
or
to
different
networks
and
three
interfaces
so
on
and
so
forth.
B
What
we're
looking
at
is,
is
you
know
so
that
the
the
the
the
far
side
of
this
is
where
you
have
essentially
a
path
aware
stack,
which
can
interact
with
the
routers
with
the
forwarding
plane
and
actually
get
different
times
from
different
points
to
different
paths
for
the
network
from
the
same
end,
points
maybe
with
the
same
addresses,
maybe
with
the
different
addresses
you
know.
This
actually
is
not
something
that
you
can
just
do
in
the
network.
This
actually
does
require
things
tap
on
the
endpoints
as
well.
B
I
mean
you:
can
you
can
say:
okay,
there's
this
guy
up
here
who
never
shown
up
in
a
routing
area,
working
group
and
it's
talking
about
path,
awareness-
and
this
is
not
really
interesting
because
in
the
control
plane
all
routing
his
path
aware,
you
know
everywhere.
Adding
decision
made.
Everything
that
goes
down
to
the
14
plane
is
okay,
I
have
I,
have
a
packet
is
going
on
this
next
hop
in
the
path
so
on
and
so
forth.
B
What
we're
really
interested
in
in
this
research
group
is
how
this
extends
to
the
edge,
so
we're
talking
about
endpoint
discovery
of
paths
in
point
explicit,
Association
of
properties
to
pass
endpoint
selection
of
paths
and
when
we
see
in
especially
in
work
like
in
PVC
and
other
multipath
transport
protocols.
This
is
happening
anyway
right.
So,
if
you
look
at
how
I'm
graphing
engineering
is
happening
with
with
segment
routing,
this
is
happening
anyway.
These
are
things
where
it's
not
just
sort
of
a
static
forwarding
situation,
as
determined
by
the
routing
protocol.
B
We
should
be
explicit
about
this.
I
should
also
say
that
you
know
when
they
talk
about
endpoints
and
edges.
Tunnels
have
end
points
and
edges
too,
and
probably
one
way
that
this
one
that
being
implemented
is
you
essentially
have
overlay
networks.
This
is
how
we've
always
done.
You
know
more
exotic
routing
over
less
exotic
routing.
B
There
are
a
bunch
of
underlying
hard
problems
here.
So
any
point
in
time
that
you
essentially
have
a
bunch
of
hosts
connected
to
a
bunch
of
networks.
The
host
idea
of
the
best
path
and
the
network's
idea
of
the
best
path
might
conflict
all
right.
So
we're
not
saying
we're
going
to
build
these
overlays
and
suddenly
you
know
bgp
goes
away.
That's
not
I
think
realistic
when
we're
talking
about
what's
going
to
happen
tomorrow,
but
already
right
now
within
PTC
P,
when
you
have.
B
Multiple
interfaces
that
you
can
choose,
you're,
actually
choosing
to
put
traffic
on
one
one
path
or
another,
and
that
might
actually
there's
a
control
loop,
that's
happening
at
the
endpoints
that
might
conflict
for
the
control
loop,
that's
happening
in
the
network
if
you've
every
month,
scheduling
at
the
transport
layer.
Obviously
you
have
more
degrees
of
freedom
when
you
have
path
awareness
right,
so
normally
in
scheduling
it's
like
okay,
well,
I'm,
gonna
use.
My
various
windows
and
I
know
what
congestion
control
is
doing.
B
It's
like
do,
I,
send
it
back
or
not,
and
now
there's
a
whole
different
degree
of
freedom.
It's
do
I,
send
the
packet
or
not
and
which
interface
to
a
user
which
path
do
I
use.
There
are
temporal
aspects,
so
all
of
the
various
bits
of
passed,
selection,
property
discovery,
any
control
input.
All
of
these
are
happening
on
different
timescales
and
I'm
thinking
it
very
bad
if
those
timescales
happen
to
sync
up
in
a
bad
way.
There's
also
work
to
be
done
in
the
semantics
of
properties.
B
So
once
you
have
multiple
paths,
you'd
like
to
be
able
to
say
things
about
them
like
some.
Maybe
this
is
a
this:
is
a
a
high
bandwidth,
high
delay
path
or
a
low
bandwidth,
low
delay
path
right
now.
A
lot
of
this
is
done
with
measurement
in
a
path
where
network
you
might
actually
get
this
information
explicitly
from
the
network
and
dissemination
algorithms.
How
do
you
get
information
about
the
path
properties
to
the
endpoints
where
they
can
use
it?
This
has
impacts
on
privacy.
B
B
So
we
have
some
text
for
a
proposed
research
group
shorter.
This
is
up
under
the
Charter
and
groups
on
the
data
tracker
I'm
not
going
to
go
through
this
right
now,
but
I
encourage
you
to
have
a
look
at
this
or
have
a
look
at
this
and
the
slides
in
the
meeting
materials
as
we're
going
through
things,
because
we're
going
to
come
back
to
these
points
when
we
talk
about
whether
we
have
this
cooperate
or
not.
This
is
not
a
ball,
but
we
would
very
much
like
your
input
on
you
know
is.
B
Is
this
something
that's
interesting?
Is
it
something
that
there's
critical
mass
the
two
big
questions
that
I'd
have
are:
do
we
have
the
scope
right,
you
know:
is
there
stuff?
That's
missing
other
things
that
we're
putting
in
here
that
don't
really
belong
in
here
and
then
also
is
there
interest
or
energy
to
contribute
to
a
new
research
group
in
this
space?
And
if
so,
what
should
we
look
forward
to
when
we're
planning
an
agenda
for
Singapore?
B
So
with
that
you
have
this
lights
for
Olivia,
oh
they're,
up
limit.
Okay
with
that
I
will
ask
our
first
speaker
to
come
up.
F
Okay,
so
I
met
Brian
one
months
ago.
He
told
me
that
I
should
try
to
explain
a
decade
of
past
awareness
and
I
was
fully
enough
to
say
yes,
so
then
let
me
try
to
show
you
my
view.
So
this
is
a
biased
view
based
on
stuff
that
we
have
done
during
the
last
15
years
or
maybe
more
on
what
is
past
awareness?
What
are
the
issues?
What
are
things
that
we
tried
didn't
work?
F
It
will
not
be
a
complete
survey
of
everything
that
could
be
done
with
passive
rely,
so
it's
very
biased,
and
maybe
it
will
make
up
your
mind
so
that
you
can
have
your
own
viewpoint
of
past
awareness.
So
to
look
at
past
awareness
I.
Think
it's
important
to
look
to
remember
what
are
the
starting
point
for
the
Internet
and
our
starting
point
are
very
simple.
F
What's
the
difference
between
a
rotor
and
and
a
nose,
the
answer
is
always
an
endo
says:
one
IP
is
one
at
one
interface
and
this
one
address
and
the
rotor
has
multiple
interface
and
multiple
addresses
and
in
the
mind
of
many
people
this
is
always
DC,
still
the
difference
between
and
O's
and
between
and
waters.
What
do
we
have
today,
but
today
the
arrows
are
slightly
different,
all
the
nos
that
we
have
in
the
room.
They
have
multiple
interfaces,
there
were
so
much
more
capabilities
and
what
we
had
in
the
1970s.
F
F
If
you
look
at
the
CPU
of
G
and
oast,
it's
very
likely
that
the
CPU
of
dinner
and
those
that
you
have
is
much
powerful
than
the
CPU
of
the
control
plane
of
the
rotors
that
resides
in
your
network,
because
we
don't
put
the
same
CPU
in
the
rotors
as
the
one
that
we
put
in
the
Endo's,
so
the
environment
says
exchange
and
both
the
routers
and
the
Endo's.
They
have
several
network
interface
and
we
have
to
keep
that
in
mind.
F
So,
what's
the
interface
between
the
and
host
and
the
network
that
we
have
today?
Well,
what
does
the
Endo's
know
about
the
network?
If
you
ask
someone
who
is
developing
stack
on
an
and
host
and
you
ask
the
developers,
what
do
you
know
about
the
availability
of
the
network
and
what's
happening
in
the
network?
Basically,
they
know
this.
So
from
an
analyst
viewpoint,
you
have
very
few
visibility
on
what's
happening
in
the
network
and
what
are
the
characters
characteristics
of
the
network
that
you
use
for
you,
the
network
is
a
black
box.
F
You
just
send
packets
and
you
expect
the
packets
to
come
back
from
the
network,
but
you
don't
really
care
all
the
packets
will
flow
to
the
network
and
all
the
packets
will
come
back
from
the
network
is
the
same
view
as
the
view
of
an
application
developer
with
a
file
system.
You
don't
really
care
about
the
existence
of
inodes
and
stuff
like
that,
but
you
want
to
save
your
fives
I.
F
Think
it's
better
to
have
questions
after
yeah.
It's
probably
that
many
people
would
disagree
with
some
of
the
stuff
that
I
will
say,
but
if
we
stop
I
will
not
be
able
to
cover
everything.
So
what
do
we
have?
So?
Basically,
there
is
a
tester
between
what
we
put
on
the
host
and
what
we
put
on
the
underwriters.
F
There
is
what
your
point
is
that
from
a
past
viewpoint
the
host
is
dump
and
the
network
is
intelligent,
so
the
router
has
to
manage
the
network
pass,
and
so
the
router
needs
to
know
what
are
the
available
pass
and
it
has
to
at
least
we
have
ways
to
be
able
to
select
the
path
to
be
used
to
reach
a
specific
destination.
So
it
has
more
information,
the
adults.
F
They
only
need
to
have
connectivity,
so
they
don't
care
about
the
past
so
from
a
rotting
hoop
on
Geonosis,
a
completely
dumb
device
where
the
rotors
are
very
intelligent.
If
we
look
at
reliability
of
the
data
transfer,
we
have
the
opposite.
We
have
the
intelligent
oast
and
we
have
placed
all
the
complex
functions
for
the
reliability
in
the
transport
protocols
and
even
the
congestion
control
on
the
Endo's
and
all
the
complexity
is
based
on
the
and
O's
2f
devices
in
the
network
that
are
as
simple
as
possible
and
the
only
forward
packets.
F
So
do
we
have
a
duality
between
reliability
and
network
information
and
the
routers,
the
only
Q
and
may
drop
may
be
mark
packets
if
Ethan
is
deployed.
So
what
is
pass
awareness,
and
how
can
we
define
that?
So
there
are
two
viewpoints
for
pastoralists.
There
is
a
control
page
view
point
where:
how
can
a
host
learn
the
existence,
the
availability,
the
characteristics
or
whatever
of
different
network
paths
that
exist
inside
a
network
related
can
use,
and
there
is
the
data
page
view
point
which
is
o
as
a
handles.
F
Can
I
tell
the
network
which
path
I
would
like
to
use
to
reach
a
given
destination,
and
there
might
be
another
question
which
would
be
to
say
whether
the
end
OS
is
to
be
aware
of
the
paths
that
are
used.
If
you
want
to
exploit
multiple
paths,
I
will
argue
later
on.
That
is
better
from
the
an
oath
to
have
some
visibility
on
the
path
that
it
uses,
and
at
least
you
have
to
know
whether
you
are
using
passed
a
or
pass
B.
Otherwise,
you
will
have
issues
with
congestion,
control
and
Meghan
is
like
that.
F
So
let's
get
past
awareness
and
some
evolution
of
past
awareness
in
on
the
Internet.
So
if
you
look
at
the
first
generation
routing
protocol,
let's
say
rip
for
it.
What
was
important
was
to
have
connectivity,
and
as
long
as
you
have
one
pass,
which
a
destination,
everybody
is
happy
and
you
don't
want
to
do
mod
and
debt
with
those
kind
of
solution,
and
if
you
have
multiple
paths
in
the
network,
what
you
do
use
you
use
them
for
failover
or
for
recovery
when
there
is
a
failure
in
the
network
and
then
routers
have
evolved.
F
If
you
look
at
OSPF,
you
have
the
ability
to
compute,
multiple
equal
cost
paths,
to
reach
the
same
destination
and
to
do
load,
balancing
based
on
a
hash
function,
and
you
can
introduce
MPLS
as
well
to
have
more
control
inside
the
network.
If
you
look
at
MPLS
well,
we
all
know
that
the
initial
motivation
for
MPLS
almost
25
years
ago
was
to
simplify
forwarding
by
having
adware
based
forwarding,
and
then
there
was
an
evolution
in
the
control
plane
so
in
the
control
plane
of
MPLS.
F
The
first
part,
the
first
solution
in
the
control
plane
with
CDP
and
later
LDP
was
to
be
able
to
have
the
same
path
with
MPLS
is
the
one
that
we
would
get
with
a
standard
idea.
What
in
protocol?
Even
if
you
did
not
use
IP
forwarding
inside
the
routers
and
you
had
shortest
path
with
a
DP
and
then
a
DP
evolved
to
be
able
to
provide
equal
cost
multi
path
and
with
various
issues
to
do
the
hashing
correctly
on
top
of
MPLS.
F
And
then
there
were
requirements
for
traffic
engineering
and
with
the
requirements
for
traffic
engineering.
We
brought
up
rsvp-te
with
the
link
to
OSP
FTE
or
is
aste
so
that
you
have
a
routing
protocol
that
distributes
information
about
the
link
characteristics
and
you
have
a
signaling
protocol
that
allows
to
create
paths
between
routers
along
the
specified
link
and
chosen,
and
the
last
evolution
is
segment
routing
and
basically,
we
segment
watching.
What
we
have
is
that
we
have
eventually
across
the
coupling
between
MPLS
and
the
routing
protocol.
F
This
is
something
that
was
considered
to
be
too
complex
20
years
ago
and
20
years
ago.
We
didn't
want
to
specify
that
intradomain
routing
should
be
done
with
a
link
state
routing
protocol,
and
there
should
be
a
coupling
between
the
link
state
routing
protocol
and
the
solution.
So
we
wanted
to
decouple
the
establishment
of
the
path
from
the
routing
protocol,
and
so
we
had
LDP
and
lgbtq.
F
Now
everybody
agrees
that
link-state
routing
is
a
stable
solution
and
we
can
leverage
link
state
routing
in
segment
raatein
to
be
able
to
compute
path
without
requiring
NDP
and
arrow
GPT.
So,
basically,
segment
watiam
is
a
way
to
get
rid
of
ADP
and
error
cpt
and
to
simplify
the
network.
If
you
have
a
network
which
is
running
MPLS
with
whatever
violent
of
MPLS
was
the
viewpoint
the
D
and
O's,
as
on
the
MPS
MPLS
network,
nothing
some
researchers
who
play
with
trace
route
so
the
so
that
they
can
detect
the
MPLS
Turner's.
F
But
besides
those
crazy
guys,
nobody
is
aware
of
the
fact
that
MPLS
is
used
in
the
network,
so
the
network
is
completely
black
for
the
for
the
Endo's.
So
what
have
we
tried
on
the
Endo's
12
a
way
to
do
path?
Awareness
on
the
Endo's?
Maybe
the
first
solution
was
ipv4,
sauce
writing
and
at
that
time
you
had
token
ring
that
was
doing
sauce
voting
and
with
a
way
to
do
all
paths
explore
and
to
discover
the
path
that
were
available
in
the
bridge
network
in
ipv4.
F
If
you
look
at
integrated
services
from
the
researchers
viewpoint,
what
the
researchers
dreamed
about
integrated
services
was
a
solution
where
the
Endo's
signals
the
pass
requirement
using
a
signaling
protocol,
whatever
the
signaling
protocol,
and
then
you
have
a
quality
of
service
routing
protocol
which
is
used
in
the
network
which,
based
on
the
requirement
that
are
expressed
by
the
and
O's,
will
select
the
path
and
will
allow
the
packets
to
follow
the
specific
paths.
What
did
the
IDF
do
with
this
researchers
dream?
F
Well,
basically,
the
IDF
designed
arrow
GP
protocol
for
the
Endo's,
which
which
allows
them
to
signal
the
pass
requirements,
but
then
doing
quality
of
service
routing
at
that
time
was
considered
to
be
too
complex
and
it
was
too
risky
to
a
low
pass
to
be
forwarded
along
non
shortest
path.
So,
in
the
end,
we
decided
to
put
our
VP
along
the
shortest
path,
which
means
that
our
GP
is
not
a
protocol
that
allows
to
select
the
path.
F
We
are
differentiated
services
and
type
of
service
routing.
So
again
we
such
as
viewpoint
thanks
to
the
mark.
We
could
do
something
with
a
close
cooperation
between
the
routing
and
between
the
Endo's.
This
did
not
really
happen
because
there
is
no
interaction
between
D
and
O's
and
the
raw
truce
and
the
network
ipv6
ausrotten
have
we
done
something
better
than
ipv4,
basically,
the
same
solution
and,
unfortunately
same
program
from
a
security
viewpoint,
pass
awareness
and
multihoming.
F
So
during
the
last
decade
we
have
seen
more
and
more
devices
with
multiple
interfaces,
and
when
you
have
multiple
interface,
you
can
influence
the
selection
of
the
path
without
I
think
to
mark
anything
in
the
packets
or
use
a
signaling
protocol,
because
the
basic
operation
of
sending
the
packet
on
your
left
interface
or
on
your
right
interface
is
the
way
for
you
to
control
the
utilization
of
the
paths
in
the
network.
So
when,
once
you
are
multi
owned,
you
have
more
capabilities
in
the
network.
So
what
are
the
solutions
that
we
have
done?
F
Maybe
my
first
interaction
with
multihoming
was
on
a
spark
station
one.
So
it's
pretty
long
time
ago
it
had
multiple
Ethernet
interfaces
and
at
that
time
the
interaction
between
the
network
and
the
multihomed
and
O's
was
to
run
rip
on
the
Endo's
to
listen
to
the
RIP
messages
and
thanks
to
the
RIP
messages,
you
had
a
view
on
what
which
paths
were
available
in
the
network.
I
guess
to
the
nobody
is
using
rowdy
on
East
and
O's,
even
if
it's
milky
oh.
F
But
this
is
something
that
we
are
missing
from
the
interaction
with
the
with
the
network
and
then
we
have
multiple
protocols.
So
the
identifiers
locate,
locate,
locator
separation
came
with
shim
6
&
8.
The
basic
idea
is
very
simple,
so
you
have
an
identifier
which
is
stable
and
which
is
associated
to
the
host
and
D.
F
There
are
locators
that
are
attached
to
the
interfaces
and
from
a
transport
viewpoint
you
will
interact
thanks
to
the
identifiers
and
from
a
network
viewpoint
you
will
send
those
packets
inside
packets
with
the
locators,
and
this
allows
you
to
move
packets
from
one
locator
to
another.
So
when
you
move
over,
you
are
multi
ohm.
This
is
a
solution
that
works
well,
but
this
is
completely
up
act
to
the
transport
layer
and
the
transport
layer
doesn't
see
which
locators
or
which
path
has
been
used
by
the
underlying
networking
set.
F
So
this
is
nice
because
you
don't
have
to
change
a
transport
layer,
but
the
drawback
of
this
solution
is
that
the
transport
layer
cannot
exploit
the
capabilities
on
the
underlying
network
step
and
there
is
no
communication
channel
between
the
Endo's
and
the
network.
Lisp
is
another
solution
that
was
designed
within
the
ITF,
the
ID.
Again
we
have
a
solution
where
the
and
those
will
have
identifiers
and
those
identifiers
are
IP
addresses
and
in
the
network
we
will
use
locators
on
the
border
routers
and
the
border
routers
will
make.
F
F
This
deployment
is
on
smartphone,
for
example,
where
you
have
two
different
interface
and
you
can
use
multi
pass
tcp
on
the
smartphone
to
use
the
two
interfaces
together
and
what
are
the
solutions
that
we
that
we
have
designed
within
the
ITF
to
deal
with
that
we
had
to
do
congestion
control
correctly.
We
had
to
keep
to
do
with
transmissions
three
injections
and
to
be
able
to
switch
from
one
to
another.
Maybe
the
lesson
which
can
be
learned
from
this:
the
design
of
multipath
CCP
and
the
design
of
a
CTP
CMT.
F
Is
that
the
fact
that
the
transport
layer,
as
a
visibility
on
the
path
that
I
used
by
the
underlying
network
network
layer
is
very
important
because
it
allows
the
transport
layer
to
understand
what
are
the
characteristic
of
the
characteristics
of
a
pass?
So
if
you
compare
a
multipass
tcp
with
TCP
/,
shim
6,
for
example,
they
are
both
capable
of
using
different
paths
in
the
network,
but
multi
pass
TCP
for
multi
pass
TCP.
F
F
What
does
ipv6
segment
watering
bring?
My
hope
is
that,
with
ipv6
and
marathi
we
will
have
a
standardized
way
for
the
ad
host
to
be
able
to
encode
network
paths,
and
at
least
this
will
be
within
an
enterprise
domain,
because
we
know
that
there
will
be
issues
in
using
ipv6
segment
rotting
in
multiple
domains.
What
we
sing
it
will
be
a
communication
channel
between
the
and
host
and
the
network
to
enable
it
to
learn
the
available
network
path,
because
the
fact
that
you
can
use
the
pass
doesn't
mean
that
you
know
which
paths
are
available.
F
So
how
can
we
give
this
interaction?
Ok,
we
organize
this
interaction,
something
that
we
are
exploring
with
dávila
bra
for
for
a
species
for
hpog
CDs
in
my
in
my
group
is
that
most
of
the
communication
that
you
do
from
ana
and
most
are
triggered
by
dns
operation
and
the
dns
is
an
interaction
that
the
end
hosts
as
with
the
network,
and
so
what
we
can
do
if
we
want
to
create
a
communication
channel
between
the
Endo's
and
the
network
is
that
we
can
put
intelligence
in
the
dns
resolver
and
every
time
a
host.
F
Does
a
dns
query:
the
dns
resolver
can
provide
to
the
host
the
path
that
it
should
use
as
segments
were
together
or
the
list
of
positive
should
use,
and
the
client
can
also
put
additional
information
in
the
DNS
request.
If
you
want
to
do
a
kind
of
signaling,
say,
I
would
like
a
path
with
five
megabits
per
second.
You
could
say
that
in
the
DNS
message
and
get
the
answer
with
a
path
that
meets
your
requirements
and
then
you
can
create
the
path.
F
So
last
point
before
concluding:
if
you
try
to
work
on
pass
awareness,
you
have
to
be
aware
that
there
is
a
political
layer
in
this.
In
this
forum
space,
you
have
the
network
operator
viewpoint
and
for
the
network
operator.
Basically,
the
network
is
like
the
post
office,
so
the
operator
is
managing
the
network.
He
invests
time,
money
and
whatever
in
managing
the
network,
and
he
considers
that
the
paths
that
are
followed
by
the
packets
are
is
sole
responsibility.
And
then,
if
you
look
at
the
end
user,
the
viewpoint
of
the
end
user
is
completely
different.
F
The
end
user
thinks
that
he
pays
for
the
network
and
since
he
pays
for
the
network,
you
should
be
able
to
influence
the
selections
of
the
paths
in
the
network.
So
from
an
end-user
viewpoint,
it's
like
driving
a
car.
So
when
you
drive
a
car,
you
still,
you
select
the
path
that
you
want
to
use
in
the
network
and
you
don't
want
to
use
the
path
which
has
been
selected
by
the
train
manager
and
that's
a
very
difficult
problem.
B
B
B
G
You
go
all
right
good
afternoon.
My
name
is
Sam
representing
here
for
Google
infrastructure,
so
today
I'm
going
to
talk
about
the
way
we
do
the
Sdn
for
the
public,
internet
and
I
know
this
topic
is
pretty
big,
but
in
ten
minutes
I'll
try
to
condense
as
much
as
possible,
but
you
have
the
slides.
You
can
go
back
and
refer
specifically
about
the
questions.
G
So,
as
you
all
know,
we
have
the
biggest
and
baddest
Network
and
we
do
that
very
efficiently.
Let
me
qualify
that
we
do
this
in
a
very,
very
structured
fashion,
so
which
means
we
need
to
control
the
network
all
the
way
up,
all
the
way
up
and
down
to
the
layer
and
always
east-west,
and
we
should
be
able
to
manage
very
efficiently
all
the
way
from
the
transports.
If
you
really
see
the
the
transport
network,
we
do
have
very
large
network
in
terms
of
the
transport
as
well
and
with
respect
to
the
data
centers.
G
We
do
have
a
very,
very
large
footprint
and-
and
we
did
just
didn't
end
there-
we
are
actually
building
multiple
regions
where
we
have
more
data
center
presents
the
the
reason
why
we
do
this.
You
could
think
that
okay,
it
is
very
deterministic
way
how
we
actually
scale
things,
but
given
the
clout
requirements,
we
are
actually
scaling
much
more
faster
rate
than
that
what
we
anticipated.
G
So
if
you
really
look
at
the
capacity
of
the
data
centers,
we
are
actually
going
almost
10
times,
and
that
brings
a
very,
very
interesting
problem
within
the
campus
of
the
data
centers
as
well,
so
which
is
also
going
ten
times
more
right
and
if
that
is
the
case,
the
actual
northbound
traffic
or
north
to
south,
which
is
growing
tremendously,
so
we
are
actually
which
is
pretty
expensive
proposition,
especially
the
Internet
traffic,
so
how
we
actually
do
this
without
disrupting
the
network.
That
means
we
need
to
able
to
do
this
without
bringing
down
the
capacity.
G
That
means
we
always
should
be
able
to
scale
up
and
at
some
point
we
need
to
scale
down
to
roll
out
ten
new
architectures
as
well.
So
that
means
predictability.
Reliability
are
very,
very
important
aspects
and
I
will
cover
those
as
well.
So,
if
you
have
seen
in
the
recent
past,
we
have
proposed
different
the
way
we
actually
manage
the
network
different
ways.
G
So
we
started
off
with
how
we
actually
traffic
engineering
traffic
engineer
our
van
traffic,
which
is
amongst
the
data
centers,
which
you
also
call
as
B
phone
network,
which
is
the
reason
why
we
do.
That
is.
We
need
to
run
efficiently
the
van
links
so
that
we
could
optimize
our
utilization
and
we
have
pretty
much
very
deterministic
way
how
the
actual
applications
are
utilize
and
based
on
the
class
of
traffic
to
how
much
of
redundancy
we
need
to
build
into
for
the
services.
So
it
is
very,
very
efficiently
run.
G
So
that
was
the
very
first
when
we
came
out
with
Sdn
proposal
to
the
public
and
the
second
topic
which
we
covered,
which
also
Sdn
managed,
was
the
virtual
network.
So
you
may
think
what
exactly
the
virtual
network
we
have.
We
do
have
the
infrastructure
to
have
the
services
run
as
pretty
much
like
a
cloud
customer.
G
So
you
take
any
of
the
internal
service,
whether
you
take
YouTube
or
any
of
the
charts
they're
running
as
a
customer
from
the
infrastructure
perspective,
so
the
same
option
you
have
when
you
actually
talk
about
Google
Cloud
as
well,
which
is
also
called
as
TCP.
So
the
infrastructure
is
managed
by
the
the
thing
which
we
call
as
Andromeda,
which
is
the
infrastructure
name
and
the
third
aspect
which
we
talked
about.
That
shall
how
we
manage
the
data
centers
itself.
That
is
the
fabric,
so
we
know
every
end
point
and
how
the
traffic
is
actually
flowing.
G
So
we
actually
optimize
in
a
such
a
way
that
how
we
actually
load
balance
across
the
entire
fabric
and
so
to
go
a
little
bit
of
the
details.
The
before
you
know,
which
is
actually
inter
connecting
various
data
centers,
which
actually
runs
at
very,
very
high
capacity,
followed
by
the
virtual
network,
which
is
the
Andromeda
which
is
the
foundation
for
the
Google
Cloud
and
the
next
one.
Is
the
fabrics-
and
it
is
not
like
one
day
we
thought?
Okay,
we
will
do
the
Sdn
way.
It
is
approbation
of
how
we
are
actually
evolving
the
network.
G
So,
as
you
can
see
2013,
which
was
the
first
time
we
disclosed
that
we
use
the
fifth-generation
fabric,
which
is
a
Jupiter,
but
with
the
egress
capacity
of
about
1.3
petabytes
per
second.
So
since
then,
we
have
evolved
much
and
we
scaled
much
higher.
I.
Don't
have
the
numbers
to
show
you,
but
as
you
can
see,
that
the
scale
is
really
really
scaling.
So
that
means
we
need
to
really
scale
the
the
Internet
capacity,
how
we
actually
appear
with
the
external
routers,
and
how
do
we
eat
Gress
the
traffic,
which
means?
G
How
do
you
actually
load
balance
both
incoming
traffic
as
well
as
the
outgoing
traffic?
So
in
order
to
do
that,
so
what
we
have
done
is
we
have
came
up
with
certain
requirements,
which
is
how
to
reduce
the
cost.
The
reason
the
cost
actually
could
span
into
multiple
areas,
that
is
operational,
cost
the
actual
equipment
cost
or
the
topics
the
capex
or
it
is
how
we
actually
evolve
our
architecture
in
such
a
way
that
we
could
expand
to
that
requirement.
G
The
scale
requirements
which
is
as
I
as
I
have
said,
which
is
scaling
at
the
rate
of
10x.
So
how
do
we
do
that?
So
you
want
to
actually
make
sure
that
these
things
are
going
to
be
managed
in
efficient
way,
and
the
answer
for
us
is
this
T
and
because
we
have
mastered
how
to
actually
do
this.
So
that's
where
this
Sdn
for
the
public
internet
action
coming
came
into
picture.
So
traditionally
the
way
we
do
is
when
we
pier
okay
for
identity
purposes.
Let's
take,
we
have
read
enhanced
devices
which
could
peer.
G
So,
even
if
one
fails,
you
have
the
failover
device,
the
the
main
problem
with
that
is
that
going
back
if,
in
order
to
scale
now,
we
are
dependent
on
the
the
peer
facing
device,
which
is
let
us
take
peering
router
and
it
is
pretty
expensive
because
you
are
now
running
most
intelligent
routing
applications
and
it
has
to
scale
as
well
and
it
it's
port
port
is
pretty
expensive.
So
how
do
we
scale
right?
G
So
what
we
wanted
to
do
is
we
wanted
to
take
a
look
at
the
problem
and
scale
it
down
in
such
a
way
that
we
wanted
to
move
the
functionality
away
from
the
device
so
that
we
dumb
down
the
device.
So
when
you
dumb
down
the
device,
what
will
happen
is
that
the
logic
will
be
moved
away
from
the
device
and
the
device
will
just
appear
with
the
peering
routers,
and
so
you
know
so
to
put
it
in
the
perspective.
G
So
we
have
the
big
data
centers
and
which
will
actually
support
lot
of
data
and
which
are
interconnected
with
the
B
for
network,
which
is
the
van
Network
or
internal
van,
and
though,
is
this
fabric.
These
fabrics
also
connect
to
the
external
world
through
the
B
2
network,
which
is
the
internet
one
for
us,
and
so
from
the
perspective.
If
you
look
at
users
traffic
or
in
this
case
it
could
be
a
single
user,
it
could
be
cloud
user.
G
The
traffic
will
come
into
the
network
and
we
have
to
ensure
we
need
to
support
that
if
it
is
a
search,
request
or
YouTube
request
or
so
on
and
so
forth.
So
we
need
to
actually
optimize
the
incoming
traffic
to
redirect
to
the
right
data
center
or
right
service
to
front-end
that
request
and
we
need
to
provide
back
the
service
or
the
data.
So
if
you
put
that
into
context,
we
have
to
simplify
that
the
incoming
thing.
So
that
means
the
device.
When
we
are
trying
to
manage
across
the
network.
G
G
So
it's
not
scalable
for
us
and
most
of
the
routing
in
this
case
for
the
peering
network
is
that
it's
all
about
the
connectivity
and
the
shortest
paths,
but
for
us
we
need
when
we
optimize,
it
is
all
about
the
service
or
the
application.
So
actually
they
do
so
and
the
fall
trickery
is,
of
course,
the
most
important
aspect
of
all.
G
So
if
you
really
look
at
the
architecture,
here
is
how
it
is
so
you
have
the
external
peer
which
will
actually
be
connected
to
our
network,
so
you
know,
in
other
words,
instead
of
having
a
peering
router.
We
move
this
functionality
back
into
something
called
peering
fabric,
and
this
peering
fabric
will
have
BGP
speakers,
and
this
will
actually
exchange
the
BGP
routes
with
external
devices
and
so
from
there.
What
we
do
is
this
information
is
actually
be
available
for
the
controller
to
actually
program
the
flows.
G
How
we
do
that
so
here
is
the
simple
architecture
from
pretty-pretty
like
50,000
point-of-view,
fake
point-of-view.
So
if
you
really
look
at
it
because
we
optimized
from
the
global
perspective,
the
end
hosts
should
be
able
to
route
it
to
the
right.
The
peering
interface,
so
that
means
all
the
way
from
the
fabric
cord
from
the
GFE.
We
need
to
be
able
to
do
that.
G
Okay,
if
I
receive
a
request
from
here,
the
host
can
actually
program
or
already
have
the
program
flow
to
egress
the
traffic.
We
are
this
particular
peering
interface,
so
this
is
the
very
very
simple.
So
what
we
do
is
instead
of
managing
or
manage
by
the
router
facing
the
P,
the
peering
sites.
Rather,
what
we
do
is
we
build
this
logic
so
that
we
we
are
now
aware
of
how
the
traffic
is
originating
from
which
peering
site
and
how
the
the
traffic
is
actually
egressing
out
of
the
fabric.
G
So
we
could
actually
control
this,
we
are
flows
and-
and
we
don't
do
any
rocket
science
there-
we
pretty
much
simplified
the
whole
thing
in
such
a
way
that
we
could
actually
scale
it.
So
if
the
capacity
goes
up,
we
should
be
able
to
scale
the
peering
fabric,
much
higher
rate,
and
we
can
have
many
bgp
speakers
who
can
actually
do
that
and
we
shot
the
tasks
across
this
BGP
speaker
so
that
the
routing
table
could
be
constrained
to
whatever
size.
G
We
would
like
to
having
said
that
the
whole
of
the
thing
the
availability
is
very,
very
important
right,
so
you
can
actually
look
up
the
slides.
Why
we
emphasize
on
that,
and
the
challenges
are
that
when
we,
the
reason
why
we
do
this
is
because
we
wanted
to
scale
both
network
compute
and
the
storage.
So
storage
is
pretty
much.
G
We
most
of
us
do
already
Network
we
are
trying
to
do,
and
the
compute
is
the
one
which
we
actually
scale
it
as
well,
so,
depending
on
how
we
actually
do
that,
how
the
traffic
we
are
dealing
with,
we
can
actually
scale
up
and
down
the
computer.
So
three
together
will
actually
provide
us
a
better
utilization
of
our
resources
serving
the
Internet
and
I.
Thank.
H
All
right
good
afternoon
going
to
present
Sian.
This
is
our
secure
internet
architecture
which
provides
path,
awareness
and
meaningful
multipath.
It's
actually
secure
inter
domain
architecture,
but
I'm
not
going
to
talk
too
much
about
the
security
of
Sion
I'm,
mainly
going
to
talk
about
the
path,
awareness
and
the
multipath
aspects
and
the
routing
itself.
H
So
our
main
architectural
design
goals
were
first
of
all
high
availability,
so
our
goal
was
to
be
able
to
communicate
as
long
as
the
network
path
exists
without
an
adversary.
So,
ideally,
you
know
if
we
have
a
network
with
malicious
routers,
perhaps
malicious,
a
asus
we'd
like
to
be
able
to
communicate
as
long
as
we
do
have
an
end-to-end
path
without
an
anniversary,
that's
a
big,
difficult
challenge
to
achieve.
Next.
H
Finally,
we
also
our
goal
is
also
to
achieve
scalability
efficiency
and
flexibility,
so
I'm
first
going
to
talk
about
isolation,
domains.
This
is
a
basic
principles
behind
Scion,
which
is
that
we,
in
order
to
achieve
scalability,
we
split
up
autonomous
systems
into
these
isolation
domains.
So
an
isolation
omein
encompasses
thus
the
set
of
autonomous
systems,
and
so
we
see,
for
instance,
an
autonomous
system
here,
and
then
we
have
an
isolation
of
main
core.
H
H
So
then
we
run
actually
two
sets
of
routing
protocols.
We
were
on
one
across
isolation,
domains
and
one
within
each
isolation
ameen.
So
next
I'm
going
to
briefly
describe
her
outing
works
inside
an
isolation
win.
So
we
call
this
process
beaconing
and
in
essence,
we
have
core
es,
is
KL
and
M
that
all
issue
routing
be
consent.
They
similar
to
today's
routing
updates
in
today's
internet.
They
traverse
the
network.
However,
what's
different
is
that
they're
only
issued
by
the
Corey
asses?
H
H
So
now
we
disseminate
a
number
of
path
properties,
so
these
be
messages,
their
record
path,
properties
as
they're
being
forwarded
and
their
record
information
such
as
MTU,
available
bandwidth
path
policy.
Various
services
are
being
supported,
cryptographic,
algorithms,
that
are
being
supported
and
so
on
and
so
forth.
H
So
we
then
differentiate
between
up
and
dump
have
segments,
but
in
essence,
is
any
segments
can
be
used
in
both
ways
and
just
the
way
we
draw
it
is
we
draw
the
core
at
the
top
and
so
house
or
domains
are
at
the
bottom?
So
we
call
it
a
not
path.
If
the
path
is
to
be
being
used
towards
the
core
and
the
down
path,
four
paths
are
being
used
from
the
core
to
a
non
Correa's.
H
Then
we
also
have
a
paths
or
infrastructure
to
disseminate
this.
These
paths,
and
essentially
each
AAS,
has
a
one
of
these
path
servers.
They
offer
lookups
for
an
isolation
of
main
ananias
number
and
they
return
down
path,
segments
to
the
destination,
core
path,
segments
across
ice
teas
and
up
half
segments
to
the
is
décor.
H
So
then
the
way
it
is
this
all
is
initiated
is
an
AAS.
Learns
multiple
paths
to
the
core,
so
the
a
s
would
look
at
their
paths
and
inspect
and
see
which
paths
they
want
to
re-instill
their
local
clients.
In
this
case,
all
the
paths
are
being
used
and
then
these
paths
are
being
registered
at
the
local
passers
and
they
will
be
used
as
up
halves
in
this
case
towards
the
core.
Similarly,
a
s
then
also
selects
down
paths
to
themselves.
So
this
is
our
receiver
controls
how
others
reach
reached
at
a
s.
So
again.
H
The
path
exploration
also
works
across
size.
These
this
is
actually
quite
similar
to
how
BGP
operates.
But
here
you
see
how
a
updates
and
beacon
is
being
sent
through
the
network
and
again
similar
to
the
intra
is
see
weakening.
The
paths
are
being
traced
and
then
multiple
paths
are
being
made
available
in
this
way.
H
So
now,
when
a
path,
lookup
happens:
a
host
contacts,
a
rain
server.
So
this
is
the
the
protocol
brine
and
it's
the
essentially
name,
lookup
protocol
that
we
were
using
in
Sion
and
the
host
requests
a
given
domain
to
look
up.
The
rain
server
then
responds
with
an
ISDN,
an
isolation,
omein
number
metonymy
system
number
and
the
local
address
different
than
in
today's
internet.
The
local
address
is
quite
unimportant,
so
only
the
isolation
of
main
and
the
a
s
number
are
important.
H
So
in
the
host
context,
the
path
server
infrastructure
that
then
returns
up,
half
a
core
path
and
these
down
path
segments,
not
a
hosts,
is
then
free
to
combine
these
segments
in
any
way
it
wishes,
as
long
as
it
takes
exactly
one
up,
half
one
core
path
and
the
down
pipe
segment
to
form
the
enter
and
half
so
this
is
when
I
said
in
the
beginning
that
the
path
selection
is
somewhat
constrained,
and
so
it's
not
fully
source
routing
in
this
case.
So
here
is
an
example
of
this.
H
When
a
host
in
our
wants
to
communicate
with
a
destination
in
s
our
looks
up,
these
up
have
segments
and
the
down
path,
segments
and
now
some
of
the
down
paths
are
not
being
directly
connected
to
an
up
half
a
s,
and
so
it
also
obtains
these
core
segments,
and
now
it
can
combine
them
in
various
ways.
So,
for
instance,
there
are
also
shortcuts
that
are
possible.
H
So
one
of
the
blue
paths
is
one
of
the
green
paths
can
follow
this
combined
intersects
at
O,
and
then
the
packet
actually
just
simply
goes
from
R
to
o2s.
So
packets
don't
always
have
to
go
through
the
core.
So
multiple
options
are
possible,
including
these
dash
lines
which
indicate
peering
appearing
links,
and
so,
even
though
the
path
doesn't
directly
is
not
directly
sent
across
this
fearing
link
or
the
beacon
I
should
say
this
peering
link
can
be
discovered
and
can
be
used
similar
to
today's
internet
that
at
most
one
peering
link
can
be
traversed.
H
So,
as
you
see,
multiple
paths
are
possible
in
this
in
this
simple
example.
Here
also,
this
obviously
works
for
the
inter
domain
case.
So
here
we
have
a
host
in
s,
communicating
with
a
destination
in
a
prime
and
again
the
host
fetches
up
halves,
cor
paths
and
down
paths
and
again
multiple
path.
Combinations
are
possible,
although
they
Traverse
some
of
the
same
a
s
s
at
the
interface
between
autonomous
systems.
Different
links
can
be
used
and
they're
being
differentiated,
to
create
multiple
paths.
H
So
here
is
now
some
examples
for
these
path
combinations.
So
we
have
just
looking
at
the
time
I'm
going
to
wait
to
fast.
It
seems
like
right
because
I'm
almost
done
I
used
to
give
this
talk,
and
so
you
always
take
too
long.
I
figured
I'll
hurry
up
this
time
so
non
events.
So
here
we
have
an
example
for
an
OP,
half-court
path
and
down
path.
That
is
simply
combined
in
in
this
way
and
then
the
packets
follow
the
blue
path.
H
Now
here
we
see
another
combination
through
without
the
core
path
and
actually,
in
this
example
here
were
also
crossing
the
peering
link,
so
that
packet
actually
does
not
go
through.
The
is
décor
and
what's
important
is
that
the
paths
are
cryptographically
protected
in
a
way
that
different
combinations
are
being
prevented.
So
an
adversary
has
to
combine
the
paths
the
way
we
envision
them
to
be
combined
and
they
cannot
be
arbitrarily
changed
afterwards.
H
Here's
another
example
were
the
peering
link
from
P
to
X
is
being
used,
and
what's
important
in
sign
is
that
the
sender
has
transparency
of
the
path.
So
the
sender
sees
that
it's
packet
will
leave
the
blue
isolation
omein
and
enter
the
green
isolation
domain
at
this
level.
So
you
get
some
amount
of
path.
Transparency
for
the
sender.
H
Here's
another
example
of
a
shortcut
path,
similar
to
the
one
I
already
showed
earlier.
So
in
summary,
the
architecture
is
essentially
a
complete
redesign
and
resolves
a
number
of
fundamental
problems
of
today's
infrastructure.
So
we
have
path
control
by
senders
and
receivers.
We
have
also
acquired
a
rich
property
discovery
through
this
beaconing
mechanism,
or
even
a
mechanisms
like
the
cryptographic
techniques
support
it
can
be
communicated
or
services
being
supported
can
be
communicated
in
the
path
that
then
the
sender
can
use
to
select
the
end-to-end
path.
H
We
also
have
a
rich
environment
of
security
mechanisms,
such
as
trust
routes
that
can
be
selected
by
each
isolation,
omein
and
a
lot
of
transparency.
How
different
authentication
mechanisms
work?
There
is
meaningful
a
multi
path
where
the
endpoint
can
actually
control
the
different,
multiple
paths
and
also
the
receiver
can
control
which
paths
Sanders
can
use
to
reach
it,
including
the
ability
not
to
announce
some
of
the
paths
and
get
a
default
off
behavior.
So
because
it's
a
cryptographic,
architecture,
the
all
the
forwarding
informations
cryptographically
protected.
H
So
if
you
do
not
announce
this
publicly,
you
can
be
connected
to
the
network,
so
meaning
you
can
communicate
with
anyone
on
the
internet.
However,
other
entities
cannot
send
you
directly
traffic,
so
a
lot
of
opportunities
to
use
this
architecture.
So
in
essence,
ioan
is
an
isolation
architecture
for
the
control
plane,
but
it's
really
a
transparency
architecture
for
the
data
plane.
B
Thank
you
very
much
Adrian
if
you
could
stay
up
and
Sam
and
the
Lybia,
if
you
could
come
up
to
just
in
case
people
have
sort
of
like
wider
questions,
so
I
want
to
thank
all
three
of
the
speakers.
I
think
we
got
a
really
nice
sort
of,
like
you
know,
look
at
the
spectrum
of
of
this
space
like
so
okay.
So
how
did
we
get
here
and
and
what
are
the
goals?
B
B
I
Yeah
Dave
plug
Akamai
I,
really
liked
I,
said
Olivia
Oliver,
the
first
present
presenter,
your
your
overview
of
things,
the
one
thing
I
took
towards
the
end.
You
said
the
difference.
There's
this
gap
between
what
operators
want
to
do
and
what
the
users
want.
The
car
that
the
analogy
used
was
driving
cars
versus
I.
Remember
what
the
other
analogy
was,
but
anyway,
the
what
it
seems
to
me
was
missing
that
maybe
I
can
offer
an
idea
or
a
word
that
we
should
be
using
is
expectation.
The
gap
between
that
is
usually
managed
by
I.
F
There's
a
difficult
point:
C,
which
is
or
to
formalize
in
some
way
the
user
expectations
and
how
to
make
sure
that
the
the
network
information
which
is
useful
for
the
users
and
we
we
tried
that
with
integrated
services
with
right
stuff,
we
never
really
succeeded
and
but
I
don't
have
a
clue.
I
don't
have
a
solution
to
solve
that.
H
J
Andrew
McGregor
Sam.
Is
it
fair
to
say
that
a
no
post
espresso
will
Google
from
the
outside
looks
like
a
relatively
small
number
of
extremely
path?
Aware
hosts
some
number
that's
less
than
a
few
thousand
I'm
sorry,
it
may
even
be
one
sorry
couldn't
repeat
the
question:
is
it
fair
to
say
that
from
the
outside
Google
looks
like
a
relatively
small
number
of
extremely
path,
aware
hosts
I
mean
I
I,
think
that
would
be
true
but
I'm
interested
in
what
you
think
yeah.
G
It
could
be
it's
pretty
transparent
right,
so
you're
really
going
see
how
exactly
we
you
do
from
the
back
end,
because
if
you
really
look
at
how
we
host
the
services
and
how
they
are
serviced,
it's
pretty
transparent,
how
they
actually
get
originated
and
how
they
get,
how
the
front
end
is
actually
doing
its
job.
At
the
back
end,.
K
B
K
That's
actually
probably
a
little
lower
than
I
was
hoping
for.
I
I
think
it's
especially
important
to
pay
attention
to
the
point
from
the
first
presentation
about
the
political
aspects
of
what
you're
doing
I
was
that
that
was
at
the
nanoq
meeting,
when
Jeff
Houston
and
Dave
Meyer
presented
him
6
to
the
operator
community.
K
It
was
awesome
and
not
in
a
good
way,
but
now
that
we
have
learned
from
that
experience
also
I
think
that
you
know
there's
there's
a
research
aspect
of
this
and
a
explaining
research
aspect
to
this,
but
I
think
you're
both
going
to
be
better
a
lot
for
this
work
for
this
research
group.
Speaking
as
the
transport
area
director
I
am
thrilled
to
see
this
work
going
forward,
I
could
have
raised
my
hand
twice
I'm
thrilled,
to
see
this
work
going
forward
and
I
throw
to
see
it
going
forward
in
the
IRT
F.
L
E
L
No,
it's
because
I
wasn't
sure
in
this
group
from
from
the
presentations
we've
had,
whether
we're
talking
about
awareness
of
what
the
path
was
of
what
it
is
and
all
the
presentations
have
been
about
routing,
which
is
something
static
and
everything
I've
worked
on.
This
is
awareness
about
what
the
the
path
is
and
how
I
change
it
when
I
use
it
and
things
like
that
rate,
which
is
and
PM
tud
and
all
those
sort
of
things
which
maybe
is,
is
more
what
it
was.
L
B
F
One
when
you
have
multiple
paths,
if
you
look
at
the
temporary
aspects,
when
you
have
a
single
path,
the
temporal
aspects
is:
when
do
you
decide
to
send
the
next
packet
and
what
kind
of
congestion
control
retransmission
you
use
to
send
the
next
packet?
If
you
have
multiple
paths
in
the
network,
you
have
another
dimension
to
take
into
account,
which
is
the
fact
that
when
you
see
that
your
temporal
characteristics
are
not
the
one
that
you
would
expect,
so
you
see
lossy.
F
So
you
see
delay
you
can
decide
to
use
another
path
and
that's
an
additional
dimension
to
the
form
that
needs
to
be
taken
into
account
at,
for
which
we
don't
have
a
real
solution.
We
don't
know
exactly
when
we
should
use
a
different
path.
So,
if
I'm,
if
I'm
living
here,
let's
say
I
have
a
multi
pass,
TCP
connection
but
I'm
using
a
single
pass
and
then
I
find
that
this
pass
is
working
badly
because
I
have
many
retransmission.
F
Should
I
try
to
continue
to
retransmit
on
this
path
or
should
I
just
reestablish
another
pass
and
hope
that
Wis,
for
example,
equal
cost
when
Tobias
I
will
end
end
up
in
a
different
part
of
the
network
and
I
would
have
different
characteristics?
And
when
you
have
passed
awareness,
this
becomes
possible.
F
M
Lives
are
gonna,
have
a
quick
and
a
longer
point.
A
quick
point
is
so
Spencer
I.
Think
actually,
is
this
distract
at
the
discussion
because
it's
specifically
not
a
working
group
forming
anything,
but
so
so,
therefore,
I
think
this
is
totally
ok,
you
know,
and
so
the
worry
isn't
is
just
ready
to
to
charter
right
or
anything
like
that.
It's
a
research
group
proposal
and
it
has
a
runway.
M
The
slightly
longer
thing
is
going
in
the
same
direction
as
pops
right,
I
was
and
I
got
up
when
Olivier
first
started
speaking,
because
your
talk
surprised
me
because
I
keep
forgetting
you
actually
also
a
routing
person,
because
it
was
all
about
routing
and
you've
done,
multipath
TCP.
M
So
when
you
show
me
a
thing
like
where
the
end
point
doesn't
know
anything
about
the
network,
that's
actually
not
true,
because
the
network,
the
endpoint,
is
using
the
path
or
the
path,
and
it
knows
quite
a
bit
while
it's
using
the
network
right
when
it's
them
putting
up
and
it
hasn't
send
a
packet.
Yet
it
knows
nothing,
but
in
general
it
actually
does
know
quite
a
bit
so
but
I
know
you
know
this.
We
don't
have
to
go
into
it
with
it
that
they
give
up.
M
The
whole
set
of
presentations
was
very
routing
oriented
and
it
the
difficult
part
comes
within
the
interaction
with
transport
starts
right,
for
example
right,
if
you,
if
you
don't
want
them
that,
if
you
want
the
node
to
know
something
about
paths
that
it
isn't
currently
using,
you
could
say
well,
the
network
you
know
might
provide
that.
Occasionally
right,
we
alto
has
been
developed
in
sort
of
that
direction.
And
then
you
know
the
question
is:
what's
the
timeliness
of
that
information
right,
you
can.
You
can
convey
things
like
here's,
the
hard
upper
capacity
of
that
path?
M
That's
probably
okay,
right,
so
don't
slow
start
overshoot
gets
trickier.
If
you
want
to
convey
load
information,
that
is,
you
know,
easily
stale,
it's
even
harder
when
you
want
to
convey
other
pieces
of
information,
because
then
you
you,
as
a
network,
have
an
assumption
what
the
end
point
might
do
and
since
we're
now
building
quick,
which
will
quickly
change
that.
M
But
if
you
can't,
you
can't
believe
that
everything
is
going
to
look
like
TCP
anymore,
so
that
that's
really
where
the
hard
part
is
I,
think
I
agree
with
book
right.
I
think
that's
something
I
think
it's
worthwhile
to
talk
a
bit
more
about,
because
when
we
tried
to
do
this
in
the
ITF
we
never
had
the
time
it
was
always.
You
know
we
need
to
standardize
this
thing
and
everybody
said
no.
It's
not
ready
in
the
tide.
Right,
I
think.
F
The
issue
is
that
we
are
working
at
the
index
intersection
between
the
rotting
people
and
the
transport
people,
and
we
have
to
make
sure
that
the
routing
people
can
change
a
bit
to
be
in
the
mindset
of
the
transport
people
and
the
trust
what
people
need
to
change
a
bit
to
win.
The
mindset
of
the
writing
people
and-
and
this
won't
be
easy
because
they
are
not
that
many
people
who
live
at
this
interaction.
For
the
moment,
yeah.
B
Thank
you
very
much
Olivier.
We
hope
to
see
you
as
well
in
Singapore.
I
will
note
that
there
is
an
unfortunate
it's
been
noted
several
times
in
my
general
direction,
and
I
will
note
to
the
rest
of
the
room
that
there
is
an
unfortunate
conflict
with
the
ideas
both.
So
a
lot
of
the
routing
people
are
over
there
talking
about
any
enabled
networks.
B
J
And
your
burger
again,
I
just
wanted
to
note
that,
from
the
point
of
view
of
routing
and
from
the
point
of
view
of
any
in
system
and
the
communication
and
all
the
AIS
is
in
between
everything
is
a
bit
on
the
future.
Based
on
the
information
you
have
about
the
past,
and
one
of
the
things
that
can
be
communicated
between
entities
in
the
community
in
this
kind
of
space
is
their
best
estimate
of
the
uncertainty
in
what
they
think.
They
know
about
the
network
and
perhaps
even
a
sketch
of
how
they
expect
it
to
evolve.
F
So
I
agree
that
everything
you
do
is
based
on
what
you
have
observed
in
the
past
and
the
bet
that
you
do
for
the
future.
But
if
you
look
at
what's
happening
today,
there
are
it's
sometimes
difficult
to
do
to
guess
on
what
has
been
happening
in
the
past.
So
let
me
give
you
an
example.
So
we
have
done
some
experiments
on
a
large
cloud
provider
and
this
large
large
provider.
F
They
have
multiple
data
centers
all
around
the
world
and
when
you
open
a
TCP
connection
from
one
of
one
OS
in
one
of
these
data
centers
to
another,
then
the
TCP
connection
will
be
load
balanced
by
using
equal
cost.
Multi
pass
over
multiple
and
pls
tunnels,
and
there
are
different
MPLS
Turner's,
some
go
over
the
Pacific
or
there
go
over
the
plenty,
and
so,
depending
on
the
TCP
connection
that
you
open,
which
is
supposed
to
be
from
a
path
viewpoint.
You
go
from
one
owes
to
another.
F
J
I
agree
that
was
that
was
kind
of
my
point.
If
the
writings,
if
the
writing
system,
that
is
doing
that,
a
CMP
could
say
hey,
these
paths
exist,
and
there
are
T
days-
are
roughly
this
and
you're
going
to
get
one
of
them
on
any
given
TCP
connection,
and
only
one
then
that's
useful
information
for
the
in
system.
Yes,
but.
C
So
there
might
be
interactions
that
should
be
considered
I'm,
not
sure
if
we
really
need
like
close
coordination,
but
that's
a
question
to
ask
and
what
I
actually
wanted
to
say
was.
First
of
all,
thank
you
very
much.
I
really
enjoyed
all
the
presentation
and
I
think
they
framed
this
really
nicely
I'm
very
interested
in
this
topic
and
I
just
quickly
jumped
to
the
last
question
there
may
be.
The
first
starting
point
is
actually
collect.
C
N
High
competence,
so
in
terms
of
this
scope
and
the
presentations
I
mean
we,
you
know
we
had
a
bunch
of
presentations
and
the
routing
aspects,
there's.
Obviously
the
transport
aspects.
People
have
mentioned
I
ain't.
This,
perhaps
also
we
tie
into
the
measurement
and
probing
aspects
more
than
has
been
discussed.
N
B
I
think
that
there's
well
there's
two
ways
to
look
at
that
one.
We
have
sort
of
a
transitional
system
right
I
mean
you
look
at
it's
something
like
Zion,
it's
further
out
in
the
future
right,
but
it
addresses
most
of
these
things
right,
there's
a
transition
to
that
and
in
the
transit,
and
what
we
have
right
now
in
transport
is
all
measurement
based
right.
B
So
one
of
the
things
to
think
about
I
think
is
how
you,
how
you
take
these
control
loops
that
run
off
with
measurement
that
you're
doing
at
the
endpoints,
with
no
assistance
from
the
path
and
then
how
you
get
to
something
where
you
have
some
assistance
from
the
path
and
then
how
you
get
to
something
where
you
have
assurances
from
the
path
and
then,
even
when
you
have
assurances
from
the
path
there's
a
there's,
a
an
implicit
trust,
then
between
the
endpoint
in
the
path-
and
maybe
you
might
be
in
a
situation
where
you're
not
going
to
trust
that
right.
B
The
path
has
signed
it
and
says
this
is
authentic,
but
you
might
run
into
you
know
hard
problem
number
one.
Maybe
you
don't
have
the
same
interests
so
I
think
that
yeah
I
completely
agree
with
you.
We
should
pull
a
lot
of
the
measurement
stuff
in
and
I
think
that
there's
a
lot
of
stuff
that
we
have
learned
from
that
that
can
yeah.
P
High
ten
and
I
think
this
is
all
really
interesting
and
I
would
certainly
support
a
research
group
being
formed.
I.
Think
in
terms
the
things
we
want
to
do,
which
shouldn't
someone
mention
happy
apples
and
at
the
moment
that
RFC
is
undergoing
an
update.
So
it's
an
active
thing
in
a
working
group
today,
so
I
guess.
The
question
is
to
what
extent
there's
overlap
there
in
terms
of
what
you
might
be
discussing
here
and
what's
actually
happening
in
something
that
will
ship
in
products
next
month
or
whenever
it
happens,
to
be
I.
P
P
O
P
B
I
would
like
to
ask
everyone
here
who
is
interested
in
this,
so
this
is
everyone,
who's
gone
to
the
mic
line
and
everyone
who
raised
their
hands
and
everyone
who
laughed
the
jokes.
So
to
the
the
point?
I'm.
Sorry,
if
we
missed
your
favorite
path,
aware
thing:
please
send
you
a
favorite
path
or
thing
to
the
mailing
list:
energy
at
IOT
org,
because
I
think
they'd
certainly
like
to
collect
that
on
the
list.
That
might
be
input
to
an
eventual
document
about
these
things
as
Maria
suggested.
B
But
we
really
want
to
know
what
we
don't
know
right
and
we
want
to
so
this
in
the
very
initial
stages.
I
think
that
this
research
group
can
can
have
a
knowledge,
transfer
and
pooling
sort
of
aspect
that
could
be
very
useful
and
then,
as
we
figure
out
we're
going
to
do
with
that.
But
yeah,
please
do
say:
hey
you've
got
this
wrong.
You
didn't
mention
my
favorite
broken
thing.
O
Rajma,
sorry-
and
this
is
interesting,
but
might
be
more
useful
to
at
least
prescribe
a
problem
with
a
little
bit
more
context
right.
You
got
the
Yui
they
use
equipment
like
there
was
shown
the
devices
that
consume
the
content
and
the
other
side.
You
have
the
servers
that
provide
the
content
serve
the
content.
O
Because
these
are
the
entities
that
are
pumping
the
content
into
the
network
to
words
they
use
equipments
the
devices
that
consume
the
content,
so
it's
very
important
to
select
the
egress
path
in
accordance
with
what
the
criteria
might
be
to
serve
that
content
correctly
to
that
UE
at
that
point
of
time,
as
we
know,
ninety
more
than
90%
of
content
online
and
it
flows
from
server
to
the
UE
they
use
equipment.
So
this
really
worth
solving
a
problem
from
the
uese
point
of
view
in
a
way
yeah
because
they're.
O
If
they
have
multiple
interfaces,
then
they
got
to
select
the
right
interface,
which
would
dictate
the
right
IP
address,
which
then
in
turn
would
dictate
what
the
server
needs
to
set
up
the
path,
but
again
I'm
scratching
my
hand,
thinking
that
we
need
to
describe
the
problem
with
a
little
bit
more
context
or
what
what
what's
really
worth
for
us
to
tackle?
Is
it
really
the?
U
east
side
mm-hmm?
B
I
think
there
are
a
lot
of
different
sort
of
provision
architectures
for
various
services.
I
think
that
one
thing
that's
missing
from
that
vision
of
the
world
is
any
interactive
video
which
is
hard
and
one
of
the
places
where
I'd
expect
path.
Awareness
gives
you
the
biggest
win.
I.
Think
that
there's
a
there's,
a
an
insight
in
your
comment
about
maybe
for
the
content
delivery
stuffs.
A
lot
of
this
is
already
solved,
I
mean
by
by
just
engineering
within
the
network.
B
You
don't
need
to
know
a
whole
lot
than
where
the
UE
might
be,
but
if
the
UE
can
assist
in
doing
that
selection
in
a
path
aware
and
a
path
aware
way
that
you
get
from
your,
you
know
your
85%
good
to
your
95%
good.
That
might
be
worth
looking
at
I
think
that
that
CD
ins
are
like
content.
Delivery
in
general
is
somewhat
less
challenging,
also
because
we
put
a
lot
of
brainpower
in
it
over
the
past
20
years.
Right
so
I
think
there
are
emerging
applications
that
will
benefit
from
this
more.
A
Sure
I
actually
think
the
end
point
is
also
very
important,
because
the
problems
there
is
sometimes
more
trickier
when
you're
talking
about
servers
you're,
mostly
thinking
about
how
can
I
put
more
bandwidth
for
endpoints.
It's
like
wired,
Wireless,
3G
multi-home
course
with
different
addresses.
Some
of
them
might
not
be
usable
at
all
and
if
endpoint
couldn't
reach
a
content,
delivery
system
doesn't
matter
how
much
effort
we
put
in
to
pass
awareness
on
servers,
yeah.
O
Certainly,
that's
true,
but
if
the
client
happens
to
have
only
one
interface
you'd
get
to
the
network,
all
bets
are
off,
but
if
the
client
has
more
than
one
then
I
agree,
then
there
is
a
need
for
again
on
the
server
side
to
figure
out
what
part.
What
interface,
what
network
to
which
the
interface
is
connected
to,
might
be
better
to
serve
that
piece
of
content
with
water.
Ssl
is
required
for
the
own
that
not.
F
B
K
Dawkins
again,
I'd
like
to
speak
in
support
of
Mirrors
suggestion
I
do.
The
survey
is
like
he's
like
one
of
the
first
step.
So
if
the
research
group
takes
on
I
think
that
there's
been
a
real
aspect
of
this
stuff
that
basically
it's
like
ooh
I,
touched
that
it's
hot
and
I'll
never
touch
anything
that
looks
like
that
again.
So
the
ability
of
the
ability
of
the
people
who
have
worked
on
stuff
to
pass
on
what
they've
learned
has
been
really
limited.
K
If
you
didn't
do
anything
else
with
them,
I
think
just
for
a
better
understanding
of
what
we're
looking
at
I
am
really
excited
about
what
y'all
are
doing
here
and
if
this
looked
to
me
like
one
of
the
research
groups
that
could
easily
be
passing
stuff
over
to
the
IETF
as
this
time
goes
on,
because
I
think
we're
you
we're
talking
about
stuff
that
people
are
doing
today,
but
trying
to
find
ways
that
they
can
do
it
much
much
better.
So
it's
really
research,
not
engineering.
Q
So
gory
first
I've
often
complained
about
people
doing
the
same
as
IETF
working
groups,
but
I
think
this
is
exactly
what
we
need
to
do.
I
think
we
need
to
have
research
here
that
attracts
all
the
things
that
aren't
being
done
in
other
working
groups,
so
we
have
somewhere
to
put
it,
and
the
reason
is
because
I
think
the
Internet
has
changed
that
big
black
box
is
no
longer
the
shape
it
used
to
be.
Lots
of
things
have
changed
even
just
ecmp,
so
as
a
transport
guy
I
have
little
clue
know
about.
Q
R
S
S
A
lot
of
these
problems
through
the
the
David
Clarke
tussle
mindset
right
we're
trying
to
create
a
playing
field
that
I
to
use
my
words
that
gives
the
user
more
choice
about
the
experience
that
their
packets
have
as
they're,
going
through
the
network
and
and
so
I
think
it
would
be
helpful
to
maybe
put
some
words
in
the
Charter
that
talked
about.
How
are
we
trying
to
improve
the
experience
of
the
internet
user
right?
What
is
this
going
to?
Do?
That's
going
to
be
good
for
the
Internet,
as
opposed
to.
S
Let's
come
up
with
some
mechanism
that
allows
you
know
box
a
to
tell
box
B
what
to
do
so,
less
of
a
focus
on
control
and
more
of
a
focus
on
choice,
but
but
the
high-order
bit
is
I
think
this
is
great
work.
I,
hope
that
it
be
lots
of
people
participate
and
I'd
love
to
see
it
happen
in
the
IRT
F.
Thank.
J
R
Markus
keen
I,
just
like
the
second,
the
comments
made
earlier
on
about
provisioning
domains.
So
a
lot
of
you
know
the
initial
sort
of
thoughts
around
that
where
it
to
solve
or
selection
for
devices
with
a
single
interface,
but
there's
also
a
cure
of
ability
to
you
know
to
specify
sort
of
characteristics
of
each
domain.
I'm,
allowing
the
again
talking
my
choice,
allowing
the
host
to
choose
between
which
which
path
that
potentially
would
like
to
take.
So
that's
kind
of
lines
calling
nicely
with
this
cool.
D
Is
one
comment
from
the
jabber
room?
Actually,
the
I
don't
know
who
the
person
is,
but
they
said
that
that
something
about
making
sure
people
understood
the
IRT
f
versus
IETF,
but
also
I'm
curious
about
whether
the
routing
people
would
name
a
subset
of
our
failed
opportunities
or
what
different
failed
opportunities
like.
Would
you
focus
on
good
stuff
or
lots
of
different
ones?
I
guess
I,
don't
know
just
pass
that
question
along
mrs.
B
D
First
time
we've
done
what
I've
done.
They
proposed
research
group
and
you,
as
as
people,
know
the
the
or
don't
know
RFC
is
74
18
kind
of
has
our
informal
approach,
which
is
that
we
can
have
a
year
of
proposed
research
group
once
you've
gotten
to
this
point
without
actually
chartering
it
formally
so
I,
don't
know
whether
Loras
took
hums
or
anything
like
that.
My
own,
you
were
going
to
have
some
review
by
some
of
the
I
star
just
to
give
us
some
perspective.
I
heard
a
lot
of
positives
here.
D
N
D
We
don't
have,
we
have
all
lot
of
transport
people,
but
not
routing
people
in
the
room,
but
we
can
fix
that.
One
thing,
I'd
like
to
know
is:
do
people
feel
we're
going
to
have
to
also
will
have
to
be
very
careful
to
avoid
ipv6
related
conflicts.
It
sounds
like
as
well.
This
may
turn
out
to
be.
One
of
those
groups
is
extremely
hard
to
schedule,
but.