►
From YouTube: IETF99-RTGWG-20170721-0930
Description
RTGWG meeting session at IETF99
2017/07/21 0930
https://datatracker.ietf.org/meeting/99/proceedings/
A
C
Thanks
Chris
hi
good
morning,
okay,
a
little
thinner,
I'm,
throwing
a
D,
so
we've
been
discussing
here
in
this
working
group
for
the
last,
maybe
a
couple
of
idea
of
cycles,
some
proposals
and
other
things
around
routing
in
the
data
center,
and
we
had
some
presentations
on
Monday
right
and
so
there's
been
a
little
confusion
of
what
we're
gonna.
Do
we're
gonna
go
forward?
How
we're
gonna
do
this?
Are
we
gonna
do
this?
It's
one
of
the
big
questions,
of
course.
C
So
what
I
think
a
plan
is
going
to
be
going
forward,
and
this
is
will
send
an
email,
probably
next
week
to
the
working
group
so
that
everyone
actually
knows
I
think
we
all
realize
that
there
are
specific,
maybe
special,
different,
how
we
call
them
requirements
or
circumstances
inside
of
their
Center.
So
what
I
have
to
do
with
the
regular
geology?
C
So
what
I
have
to
do
with
the
way
that
we
want
the
potential
routing
protocol
surrounding
solutions
to
behave
inside
the
data
center,
each
of
the
ployment
other
things
along
the
lines,
so
that
could
lead
us
or
has
led
us
already
to
define
solutions
for
the
data
center.
That
are
not
just
the
regular
routing
protocols
that
we
have
today,
so
this
also
means,
at
least
in
my
mind,
that
we
may
have
more
than
one
solution,
because
not
all
the
topologies
are
the
same.
C
C
Ok,
so
Jeff
says
it's
happening
but
resolve
which
to
me
it
means
it
didn't
happen
for
this
idea.
So
what
we
want
to
make
happen
for
next
IETF
is
what
I
want
to
do,
and
you
know
welcome
to
suggestions
and
questions
and
flames,
and
everything
else
you
want
to
do
is
hold
a
nonworking
group.
Forming
Boff
in
Singapore.
C
Do
two
things:
one
discuss
some
of
these
special
circumstances
and
and
characteristics
that
we
think
we
need
and
to
go
over
the
solutions
for
some
of
the
potential
solutions.
Theythey
is
not.
This
is
important
not
to
have
a
beauty
contest
or
a
winner,
necessarily
because
I
just
said
that
I
believe-
and
maybe
you
guys
do
too-
that
we
may
have
more
than
one
potential
solution.
So
the
idea
is
not
to
say:
oh
yes,
solution,
one
is
better
than
two
because
it
may
be
better
in
some
circumstances,
but
not
in
others.
C
If
we
do
that,
and
if
we
identify
interesting
solutions
that
for
which
we
can
also
identify
interest
in
the
ITF
to
work
on
them,
then
we
can
figure
out
what
the
next
steps
are.
Meaning
we're
going
to
work
on
something
specific
that
we
charter
a
working
group
to
each
other
to
do
we
bulk
everything
into
one.
C
C
Jeff
is
going
to
help
coordinate
so
the
proponents
around,
so
that
we
can
have
some
discussion
at
the
beginning
of
that
Boff.
If
you
are
interested
in
presenting
something
in
the
next
few
weeks,
hopefully
Ella
and
the
FRA
chairs
and
we'll
go
forward
from
there.
Obviously,
all
of
this
is
subject
to
discussion
and
other
process
parts
in
the
AEG
and
with
the
ideas
well
Rick,
Rick
Taylor
and
it
sort
of
kind
of
clarifying
question
from
my
understanding.
The
purpose
of
the
IETF
is
really
around
interoperability,
particularly
with
routing
protocols.
C
Just
just
this
protocol
work
on
my
box
and
yours
within
the
data
center.
Surely
you
own
everything
in
that
data
center
it's
owned
by
whoever
is
running
it
is.
Is
there
interoperability?
There
I
mean
it's,
not
my
field
of
expertise.
So
it's
my
question
is
if
there's
interoperability,
sure
that
is
valuable
work.
C
If,
if
it's
silos
of
technology
owned
by
single
users
operations,
is
this
valuable
IETF
work
at
that
point,
or
are
we
just
showing
off
up
Frankie
protocols,
so
I'm
going
to
say
yes,
there
is
interpretability
is
important,
you're
right
yeah,
it's
my
data
center,
it's
my
stuff
they're!
My
boxes,
probably
I,
bother
saying
all
the
buses
from
the
same
person,
however,
that
same
when
they're
obviously
probably
sold
the
same
solution
to
different
people.
C
D
That's
Joe
Brian,
so
I
accept
the
need
for
doing
specialist
routing
protocols
in
the
data
center.
Absolutely
but
I
noticed
it's
part
of
a
trend
for
domain
specific
routing
protocols
and
I.
Wonder
whether
we
might
we
want
to
go
up
a
level
and
create
a
toolkit
so
that
you
can
build
domain
specific
routing
protocols
and
then
the
data
center
one
might
be
a
profile.
C
Sure
there
may
be
something
that
we
do.
One
of
the
things
that
I
want
to
do
is
you
know
great
I
made
a
list
of
course,
so
that
we
can
specifically
discuss
that
and
take
that
off
the
plate
bit
of
this
working
group.
So
we
can
have
your
clarity
and
focus
on
that.
So
hopefully
I'll
get
that
done
in
the
next
couple
weeks
and
we
can
start
having
this
questions
like
that,
because,
yes,
that's
another
potential
option
right
that
we
can
go
forward
with
that.
Les
les.
E
C
Just
said
nothing
so
so
I
think
that
that
you
know
there's
a
class
of
solutions
that
of
course
are
around
enhancements,
occur
and
routing
protocols.
There
is
already
work
that
has
been
done
and
published.
Srf
sees
that
I
personally
believe
could
be
used
to
enhance
running
protocols
the
data
center,
for
example,
so
I
don't
want
it's,
not
my
intent
to
slow
anything
else
down.
As
I
said
the
beginning.
C
One
of
the
important
things
here
is
to
gauge
interest
and
enthusiasm,
and
if
there
is
work,
extending
specific
protocols
and
the
extensions
happen
to
be
around
you
know,
there's
a
sense
of
stuff
and
there's
interest
in
the
working
group
and
the
process
is
followed
and
all
this
stuff.
You
know
I'm
fine
with
that.
A
More
comments,
so
there's
some
new
features
coming
up
coming
silicon
that
would
enable
us
to
build
non
class
topologies
and
we
need
to
start
looking
into
protocols
that
could
address
non.
Classical
data
sent
apologist.
This
number
one
number
two
we
see
data
center
getting
out
of
data
center
so
leaves
being
the
edge
which
requires
quite
different
set
of
features
in
the
routing
protocol
so
long
term.
We
need
to
address
all
of
this,
not
just
BGP
and
DC,
which
works
perfectly
fine
and
hundreds
of
people
have
deployed,
so
it's
natural
evolution
of
routing
and
long
term.
F
D
D
So
we
wanted
to
build
a
layered
solution,
so
the
way
we
approach
this
was
really
assume.
We've
got
a
substrate
or
underlay
that
will
provide
the
the
resources
that
we
need
and
what
we're
going
to
do
is
to
overlay
a
number
of
VPNs
on
this,
such
that
each
VPN
can
draw
specific
resources
from
the
underlay
to
provide
the
the
the
services
that
that
it
needs
to
serve
it
that
provide
in
particular,
and
it
can
have
dedicated
resources
if
it
needs
them.
We
call
this
a
VPN.
D
This
is
an
enhanced,
VPN
or
VPN
plus
it
is
the
importance
of
the
dedication
of
the
resources
that
allows
us
to
have
the
performance
guarantees
that
we're
looking
for
and
to
do
that,
we
think
we
need
much
tighter
coupling
between
the
under
the
overlay
and
the
underlay
than
we
normally
have
in
networks.
So,
for
example,
if
you
do
a
providing
hard
isolation,
you
may
have
a
dedicated
tunnel
as
opposed
to
a
shared
tunnel
in
parts
of
the
parts
of
the
network.
D
So
we're
going
to
splain
explain
this
step-by-step
say
you
will
have
met
all
the
steps
before,
but
I
was
surprised
at
how
easily
they
went
together
so
we're
looking
for
fine-grained
off.
We
were
assuming
we're
going
to
use
a
segment
routing
construct
and
the
reason
we
wanted
to
use.
That
is
because
it
provides
a
good
way
of
providing
a
fine-grained
steering
of
the
packets
through
the
network
and
through
compute
resources
in
the
network.
So
segment
routing
is
normally
described
as
providing
paths
and
nodes
and
links.
D
But
of
course,
as
you
will
seen
from
stuff
we've
explained
in
MPLS,
we
can
get
it
to
steer
through
service
functions
and
I
think
we
can
get
it
to
steer
through
many
other
utilities
in
the
network.
So
we
can
use
that
to
provide
the
isolation
between
the
VPNs
and
the
guaranteed
latency
by
setting
up
the
resource
chains
right
and
the
advantage
of
this,
as
is
well
known,
is
that
there's
less
core
state
needed
to
be
maintained
to
support
this.
D
D
D
We
normally
think
of
this
as
ways
of
constructing
traffic
engineering,
but,
of
course
we
can
use
it
to
construct
an
explicit
VPN
as
well,
which
is
not
something
that's
been
vocalized
very
much
here
and
the
important
thing
there
is
that
we
create
the
VPN
simply
by
handing
the
cid
lists
to
the
to
the
entry.
So
the
entry
points
of
the
network.
So
the
only
thing
that
that
communication
needs
to
happen
is
between
the
controller
that
creates
the
VPN
and
the
ingress
objects.
And,
of
course,
that's
fulfills.
D
So
again
what
I
showed
before
we
have
an
existing
VPN,
which
we
are
going
to
call
a
de
I
want
to
create
a
new
VPN,
cdb
and
I.
Do
this
simply
by
going
to
each
of
those
nodes,
C,
D
and
B,
and
providing
it
with
the
CID
list
needed
to
construct
each
of
the
each
of
the
paths?
Now,
one
of
the
things
that
came
out
of
the
of
the
N
word
discussion
was
the
need
for
these.
So.
B
D
For
creating
and
modifying
paths
in
the
network-
and
this
is
about
the
fastest
way-
you
can
do
it-
you
just
hand
to
an
ingress,
node
a
new
path,
and
but
it
also
has
the
characteristic
that
you
may
wish
to
manage
the
internal
structure
of
that
network
in
the
network
itself.
So
you
hand
the
hand
the
path
list
and
it
discovers
what
each
component
discovers.
What
is
there
so,
for
example,
running
an
IGP
over
the
top?
D
D
We
see
all
of
the
different
potential
colors
of
the
resources
and
we
color
them
late,
so
that
initially
everything
is
it's
neutral
and
only
given
a
color
when
it
when
it's
needed
to
construct
a
network
of
a
particular
color,
and
then
we
use
it.
We
partition
things
to
create,
in
this
case
the
three
different
VPNs
and
we
specify
the
path
through
the
three
VPNs
by
Sid
lists.
D
This
is
using
strict,
strict
source
routing
paths,
which
is
where
I
think
we
will
end
up
when
we
are
dealing
with
true
isolation
or
loose
or
even
paths,
because
not
not
all
services
require
strict
isolation.
So
there's
a
mixture
of
sort
of
hard
and
soft
resource
preservation,
that's
needed,
depending
on
the
the
application
and
maybe
depending
on
how
much
bandwidth
you've
got
in
hand,
and
so
you
can
be
a
little
a
little
less
careful
right.
D
Service
functionality
so
is
chaining
for
both
for
virtual
functions
and
for
actually
potentially
the
operation
of
the
network
itself
inside
the
the
network.
So,
for
example,
if
you
are
going
to
run
OSPF
on
one
of
these
VPNs
inside
the
VPN,
then
you
would
have
to
have
access
to
compute
resources
that
were
dedicated
to
that
to
that
network
virtual
network.
So
it's
quite
simple,
really
you
just
especially
you
have
to
have
some
function
f
that
resides
on
node
3
identified
my
sig
103,
then
by
including
103
at
node
3
in
the
instruction
list.
D
We
add
this
to
the
the
service
function
to
the
path.
There's
a
bunch
of
work
going
on
and
they'll
be
a
more
comprehensive
draft
written
for
the
next
IETF
that
a
group
of
us
are
working
on.
So
what
we've
done
is
we've
integrated
service
function,
chaining
and
segment
routing
in
a
seamless
way,
in
order
to
provide
the
dedicated
resources
and
now
service
functions,
but
we
need
to
go
a
bit
further.
D
So
the
where
you
want
isolation,
you
need
to
be
stricter
in
terms
of
what
you
steer
the
packets
through,
and
it's
obvious
that
we
can
extend
these
mechanisms
to
steer
a
packet
through
any
identifiable
resource
in
the
VPN.
So,
for
example,
physical
and
virtual
interfaces,
Q's
NP,
specific
mbu's,
CPU
cores
lookup
engines.
Anything
really.
So
the
important
thing
is
that,
by
increasing
the
instruction
set
and
by
providing
the
right
concatenation
of
instructions,
we
can
steer
the
packets
around
the
network
to
the
right
resources
which
may
be
reserved
specifically
for
them.
D
We
can
also
use
this
approach
to
tune
the
behavior
of
a
resource.
So,
for
example,
a
an
instruction
might
be
something
that
influence
the
behavior
at
the
specific
behavior
as
a
clue
get
a
Q.
For
example.
Maybe
you
want
to
flush,
it
I
think.
The
the
important
thing
is
that
once
we
step
into
this
world,
then
it's
up
to
us
to
decide
what
instructions
we
might
want
to
add
and
prepend
to
the
front
of
the
packet.
D
But
we
get
you
in
moving
away
from
a
simple
network
to
more
a
set
of
network
programmability,
we're
building
more
sort
of
an
operating
system
in
the
network,
so
we're
steering
a
packet
through
a
a
resource
in
VPN
a
we
might
specifically
go
to
Q
103
for
some
packets
and
cubano
forth
rather
packets,
and
we
might
identify
a
resource
as
being
a
resource.
That's
a
stuff,
that's
a
component
of
a
well-known
object
which
are
102
or
it
might
be
a
resource
in
its
own
right.
D
So
for
those
who
haven't
seen
it,
the
the
IP
encapsulation
we
would
impose
for
this
unification
is
IP
the
to
have
the
MPLS
label
stack
that
we
would
have
otherwise
created,
put
that
in
UDP
and
put
that
in
either
an
ipv4
or
ipv6
header.
Note
that
we're
supporting
ipv4
and
ipv6,
which
allows
us
to
add
some
of
this
into
a
legacy
environment.
D
This
is
a
very
similar
diagram
and
it's
deliberately
a
very
similar
diagram,
because
the
problem
of
hopping
over
and
bridging
across
IP
gaps
in
an
MPLS
network
turns
out
to
be
almost
exactly
the
same
problem
as
building
you're
using
this
technology
in
an
IP
network
in
order
to
introduce
segment
routing.
So
there's
an
elegance
in
that
that
we
should.
We
should
consider
and
note
that,
although
I'm
only
showing
connectivity
here
at
any
particular
point
in
the
stack,
I
could
show
calling
up
a
service
function
or
routing
through
a
specific
queue
or
invoking
any
other
feature.
D
So
what
when
I
got
here
is
a
single
compact
data
plane
format
that
can
support
interconnection
between
MPLS
segment
routing
islands
can
support
service
routing
service
service
function
chaining
and
can
support
segment
routing
over
either
IP
year
version
pretty
well.
All
of
the
data
plane
requirements
already
exists
because
RFC
7510
MPLS
over
UDP
is
the
fundamental
component
in
the
IP
case
and,
of
course,
segment.
Routing
MPLS
already
exists.
D
It's
important,
of
course,
to
focus
on
the
fact
that
these
labels
are
merely
20
bit
instructions
and
not
the
the
packaging
and
the
packaging
in
our
sse
3032
format
is
media
convenience.
It's
also
important
to
remember
that
we
don't
need
any
of
the
MPLS
control.
Planes
turned
on
to
do
any
of
this,
so
this
is.
This
is
unique.
This
is
a
unified
approach.
That's
got
a
lot
of
benefits.
D
Initial
focus
on
the
control
plane
will
be
so
initial
focus
has
been
on
the
data
plane
and
will
be
going
to
the
control
plane.
Next,
we're
clearly
going
to
have
to
get
it
working
under
the
classic
iGPS
we
can
lea
going
to
have
to
support
bgp,
LS
and
PCE
controller,
and
the
overlay
can
use
a
dedicated
control
plane
or
a
share
control
plane,
depending
on
what
degree
of
sharing
is
permitted
between
the
different
VPNs
and
that's
a
function
of
the
isolation,
both
in
terms
of
control
stability
as
well
as
data.
D
You
know,
data
interference.
So
all
we
kind
of
done
really
is
to
try
and
unify
deterministic
networking
with
service
function,
chaining
with
segment
routing
to
build
the
new
class
of
VPNs.
That
some
industries
are
asking
us
to
put
forward
so
we
we
can
potentially
have
a
virtual
network
with
hard
isolation
which
is
better
than
we
get
with
classic
VPN,
where
packets
can
bump
into
each
other.
We
get
the
benefit
of
both
hard
isolation
with
statistical
multiplexing.
D
We
get
tighter
integration
between
the
underlay
and
the
overlay
so
that
we
can
draw
on
specific
resources
in
the
underlay.
We
can
perform
resource
reservation
on
a
per
VPN
basis.
We're
doing
this
with,
we
think
less
state
in
the
core
compared
to
other
techniques,
and
we've
got
an
integration
of
VPN
service
functions
and
guarantee
performance.
I
think
that's
the
end,
so
questions.
B
Ok,
actually
I
want
to
jump
in
here
for
a
moment.
So
since
the
topic
of
network
slicing
was
was
discussed,
and
so
you
know
this,
this
has
some
relevance
to
network
slicing.
There
was
a
on
Monday
and
I
want
to
make
it
clear
that
you
know
the
process
of
the
Boff
is
taking
place,
took
place,
Monday
we're
not
going
to
have
arguments
about
relevance
and
so
on
to
this
technology
or
relevance
of
this
to
network
slicing,
et
cetera,
that's
being
done
elsewhere.
This
is
just
informative
and
relevance.
B
G
This
is
omaha,
I,
hope
to
comments
and
one
question:
actually
the
system
closes
to
work
for
naturalizing
and
ever
so
actually,
I
worked
in
neck
slicing
solutions
to
companies,
and
this
is
the
closest
work
in
the
transport
network.
Don't
mind
thanks
for
this
work
and
the
question
is
in
the
stateful
virtual
networks
slide.
You
said
that
to
create
a
VPN,
a
set
of
said
list
is
created
and
provided
each
ingress
at
the
VPN.
Together
with
the
package
selection
criteria,
I
looked
at
the
document,
I
couldn't
find
the.
D
We
wrote
the
the
document
sort
of
in
haste,
I
suppose
we
will
be
significantly
expanding
it.
How
you
select
the
how
you
actually
select
the
packets
is
kind
of
your
part
of
the
the
dialogue
between
the
owner
of
this
network
and
the
tenant,
and
we
can
use
any
of
the
ACL
type
techniques
or
we
can
use
an
open
flow
selector
or
whatever,
or
we
can
just
take
everything
from
a
port
I.
G
G
D
I
Adrian
Farrell
two
points.
The
first
was
I
was
one
of
the
co-chairs
of
the
the
net
slicing,
buff
and
I.
Don't
want
to
prejudge
what
the
iesg
will
do,
but
I
think
a
strong
theme
that
came
out
of
that
was:
don't
wait
on
an
overarching
architecture
to
do
work
that
is
useful
for
operating
building
networks.
You
know
if
there's
work
out
there
that
needs
to
be
done
whatever
the
purpose
of
that
work.
If
it
has
value,
then
then
don't
sit
so
yeah.
This
is
good.
A
A
F
I
I
Resources,
that's
great,
so
it
turns
out.
You
want
to
pick
it
your
representation
of
VP,
M
plus
as
well.
So
what
came
over
in
your
slides
was
that
the
the
user,
the
person
who
had
to
begin
was
being
given
a
tight
coupling
with
the
way
the
network
was
operated
and
built
and
I
think
that
tight
coupling
is
between
the
controller
and
the
network,
not
the
customer
in
the
network.
Yes,
of
course
it's
actually
so
we
got
four.
I
I
think
we
might
have
radical
agreement,
then
that
this
is
really
what
you're
talking
about
is
a
controller
based
system
where
the
controller
has
knowledge
of
what
what's
needed
and
is
operating
the
network
using
the
variety
of
tools
that
we
already
have
to
achieve.
That
and
I'm
not
opposed
to
overarching
cookbook
framework
documents,
I've
written
to
many
of
them
myself,
but
I.
Don't
think
you're
doing
more
than
telling
us
that
there
are
a
lot
of
tools
out
there
and
we
can
put
them
together
absolutely.
D
J
To
get
through
in
three
knowledge,
blueburger,
two
things:
your
statement
of
you
were
surprised
how
everything
fits
together,
I'm,
not
I,
think
a
bunch
of
us
are
happy
to
hear
that
and
sort
of
makes
sense
to
us,
because
you're
leveraging
a
whole
lot
of
things.
While
we
assume
you're
leveraging
a
whole
lot
of
pieces
that
we're
already
working
here
in
David,
it's
not,
but
it's
not
clear
from
your
presentation
or
from
your
documents,
which
you
are
and
the
one
document
that
goes
into
some
of
the
details
misses
a
whole
lot
of
work.
J
You
know
we're
doing.
We
have
a
way
of
doing
etiology,
abstraction
and
control.
We
have
ways
to
do
it.
We
have
models
and
frameworks
for
Sdn
control
of
transport
or
TV
networks.
It
just
please
bring
them
in
and
then
when
we
have
that
cookbook
it'll
it'll
show
how
the
whole
pieces
fit
together.
So
that
would
be
really
nice
indeed,
and.
D
J
Agree
but
I
wasn't
gonna
bring
that
up.
My
second
point
was
actually
I.
Do
think.
You've
highlighted
a
definition
that
we
should
be
more
focused
on
in
in
the
area
I'm,
not
saying
in
which
group,
which
is,
we
don't
have
a
good
definition
of
srte,
and
we
should
right
so
I
think
that
that
is
an
implication
of
what
you're
talking
about.
J
K
Agreed
it's
a
good
document
to
actually
put
the
pieces
together,
which
we
all
have
right,
but
I
believe
that
in
spring,
when
we
started
there
was
a
bunch
of
use
case
documents
written
which,
at
the
end
of
the
day,
didn't
go
forward
because
we
thought
this
was
not
really
relevant
for
ITF.
I
do
agree
that
segment
routing
over
IP
is
something
which
is
not
fully
fleshed
out
and
each
for
the
work
which
is
ongoing.
Anything.
But
the
other
question
which
I
have
is:
what
is
the
the
scope
of
this
document?
K
Is
it
just
a
framework
which
you
put
together
because
it's
actually
putting
together
the
pieces
which
we
actually
have
available
in
many
working
groups
and
it's
actually
putting
it
together?
But
there's
I
don't
see?
What's
new
to
be
done
or
what's
new,
let's
say,
specifications
which
need
to
be
done
or
protocol
work
which
need
to
be
done
in
from
here
in
order
to
address
these
use
cases,
whether.
B
B
L
So
I'm
here
to
talk
about
drafted,
safe
and
I
work
wrote
about
low
latency
applications,
and
so
the
background
for
this
is
that
you
know
we
saw
a
lot
of
references
to
work
on
latency,
sensitive
applications,
critical
communications,
low
latency
and
we
sort
of
what
we're
wondering.
What
is
this
and
what
does
it
actually
imply?
And
you
know
people
were
claiming
that
it's
a
major
major
change.
Is
it
so
we're
trying
to
understand
what's
going
on
and
how
it
impacts?
L
Internet
and
you
know,
is
there
new
work
for
the
IETF,
the
Arctic's
rebels?
It's
kind
of
a
big
picture
view
into
this,
and
this
is
working
progress
on
here
for
a
couple
different
reasons,
including
the
you
know,
request
for
you
guys
to
contribute.
So
we've
seen
many
requirements
for
latency
sensitive
communications
appear.
Tactile
Internet
requires
one
millisecond
reaction
times.
They
tend
from
somebody
self-driving
cars
and
other
heart
requirement.
5G
has
a
ton
of
discussion
about
low
latency
or
support
for
low
latency
applications
and
specific
requirements.
Again.
L
The
one
millisecond
number
appears
there
somewhere
in
their
requirements
and
ten
milliseconds
for
for
more
general
latency
figure.
So
these
are
kind
of
the
the
you
know.
You
can
you
sort
of
think
about
this
and
they
make
sense
in
at
least
in
some
some
aspects
that
you
for
some
some
of
these
applications.
You
actually
do
need
fast
communications,
there's
also
plenty
of
wild
claims
in
this
space.
L
L
You
know
different
speed
of
light
or
something,
and
in
this
you
know
where,
as
kinds
of
business
change
is
sort
of
ongoing,
one
of
them
is
actually
that
you
know
as
you
sort
of
move
or
if
you
have
low,
latency
applications
or
demand
for
them,
then
you
might
need
you
know.
Some
of
the
resources
need
to
be
closer,
so
that
might
change
the
landscape
a
little
bit
in
the
cloud
space
as
an
example.
L
So
we
you
know
I
I
would
not
expect.
At
least
you
know
major
changes
in
how
the
dynamics
and
economics
of
the
Internet
operate,
but
but
it
is
true
that
the
world
does
care
about
low
latencies,
some
examples
about
things
that
are
going
on
at
the
IETF
and
elsewhere
or
in
the
deployment
data
centers
being
distributed
around
the
globe,
including
cooperation
with
operators,
advanced
optimization
techniques
to
get
to
those
data
centers
with
some
DNS
tricks
industries
working
on
you
know,
HTTP
to
quick,
TLS
1.3
with
you
know:
zero
round-trip
time.
L
The
design
l4s
that
net
802
1
TS
n
5g
radios,
you
know
tons
of
work.
We
also
have
a
Sdn
SFC
techniques
to
you
know,
make
it
possible
to
tailor
better
various
kinds
of
routing
paths
through
the
network,
make
sure
that
that
you're
sort
of
optimized
for
for
a
given
situation
in
your
network
and
at
the
application
level,
we
have
tons
of
tools
also
to
to
help
some
of
these
latency
issues,
and
so
just
to
sort
of
recap
where
we
are.
L
It
seems
that,
like
we're
working
on
the
link
layer,
so
the
links
are
being
improved,
our
route,
the
mechanisms
are
being
improved,
transport
protocols
are
being
improved,
the
security
tools
are
being
improved
in
terms
of
latency,
lynsey's
applications
is
being
looked
at,
network
deployments
are
changed
into
taking
to
account
latency,
and
this.
This
is
really
just
you
know:
regular
business
at
IETF
and
elsewhere.
So
one
statement
that
could
be
made
here,
of
course,
is
that
I,
it's
all
done,
and
you
know,
there's
nothing
more
to
be
done,
I
that
you
know
to
some
extent.
L
That's
true,
there's
plenty
of
work
and,
and
it's
not
a
revolution
in
the
in
the
same
sense
as
some
some
some
people
might
be
expecting,
but
there
is
some
some
first
of
all
ongoing
work
and
then
there
might
be
some
issues
that
that
we
need
to
address,
but
it
also
might
imply
that
there's
you
know
some
pressure
for
changing
infinite
in
in
in
big
arrays
and
might
cause
some
strain
for
their
architecture
in
several
places.
So
so
our
draft
tries
to
look
at
that
like
what?
L
What
possible
things
we
might
be
thinking
in
terms
of
a
bigger
change
to
two
slides
about
that
here.
So
the
first
point
to
make
is
really
that
that
you
know
I
see
a
lot
of
people
working
on
particular
details
of
networking
and
really
focused
on
let's
optimize
latency
on
this
link
or
this
part
of
the
the
routing
fabric.
L
But
you
know
if
you
try
to
think
about
the
possible
applications
of
this.
You
have
a
factory
with
robots,
communicating
with
each
other
or
some
some
kind
of
traffic
control
system,
where
you
really
need
to
communicate
quickly
and
make
sure
that
your
your
communications
get
through.
You
need
to
think
about
the
system
that
the
whole
you
know.
Where
are
the
participants
that
need
to
communicate?
How
do
we
get
to
them?
And
often
it's
not
just
one
link
away,
it
could
be
further
away
and
and
then
the
other
aspects,
and
then
communication
also
included.
L
So
that's
really
really
important
to
be
seem
to
be
forgetting
at
times
there's.
Obviously,
a
trend
of
service
placement
in
the
internet
work
is
no
longer
in,
like
you
know,
if
you
have
a
web-based
service
somewhere,
it's
no
longer
in
one-one
server
and
you're
in
your
data
center,
but
it's
actually
typical
distributed
around
the
globe
in
some
some
fashion.
So
we're
we're
seeing
that
that
distribution
happened
might
be
going
even
more
reads.
You
know
than
then
than
it
is
today.
L
L
So
obviously,
if
you,
if
you
have
a
very
low
latency
application
and
as
part
of
the
routing
you
you'll
tunnel,
your
packets
thousand
kilometers
away
that
that's
three
milliseconds,
at
least
so
so
that
might
not
work
in
all
situations
and
and
then
there's
multiple
ways
of
fixing
that
you
know
one
is
to
move
away
from
some
of
this
tunneling
approaches.
The
other
one
is
to
think
about
where
you
actually
place
the
end
points.
L
Fortunately,
some
of
that
is
actually
relatively
easy
or
becoming
easier
today,
because
we,
because
of
the
cloud
and
virtualization
techniques,
allow
you
to
place
functionality
in
in
different
places
in
the
network
in
much
easier
fashion.
Tandems
true
before
also
there's
gonna,
be
demands
for
cross
layer.
Optimization,
look!
If
we
put
all
these
layers
together,
then
we
can
cut.
You
know,
half
a
round-trip
from
this
exchange
and
then
everything
will
be
faster,
great
well,
that
might
be
true,
but
there
might
be
also
costs
like
your.
Your
design
will
be
more
fixed.
L
L
L
To
think
about,
I
mean
we
have
lots
of
experience
of
not
being
able
to
deploy
qsr
because
it's
a
difficult,
both
technical
but
also
business-wise,
Casey
class
via
and
Dave
Claude
had
a
very
nice
paper
pointed
to
by
our
graphed.
You
should
go
and
read
if
you
contemplate
in
in
designing
any
of
these
things,
so
that's
the
sort
intro
to
what
we're
doing
in
the
draft.
L
H
Yeah
names
on
from
Holly
yeah
III
trade
like
this
idea
of
real
this
low-latency
issuing
architecture
view
so
because
they
think
that
low-latency
Wow
is
a
hot
topic,
but
it's
quite
difficult
to
achieve
to
satisfy
by
using
the
single
technology,
doing
ITF
or
Internet
technologies
difficult
to
achieve
different
use
case
requirements.
So
I
think
that
maybe
you
may
build
an
architecture
view
that
maybe
a
cookbook
to
combine
and
have
the
gap
analysis
of
existing
technology
to
see
if
this,
using
this
reusing,
existing
low,
latency
tools
in
IGF
to
meet
the
requirements
in
the
maximum
sense.
H
I
think
this
is
a
good
idea
and
maybe
some
potential
gap
also
could
be
should
be
analyzes
before
between
the
different
industrial
requirements,
for
example,
to
add,
I.
Think
a
proper
forum
also
launch
the
project
is
called
prepared,
a
short
IP
service.
They
have
some
requirement
for
the
user
arm
service,
so
yeah
I
think
this
is
a
go-to
way
to
go
and
we
have
a
similar
idea.
So
maybe
you
can
talk
about
this
so.
B
L
It's
just
a
quick
response
that
you
know.
Thank
you,
and
you
know
this
discussion
is
also
partially
similar
to
what
we
just
discussed
about
net
slicing,
that
we
sort
of
trying
to
have
this
overall
view
the
big-picture
view,
but
that
shouldn't
stop.
You
know
people
identifying
necessary
things
and
going
and
do.
J
And
then
how
do
we
provide
information
back
up
through
the
transport
protocol
and
we
see
there's
an
opportunity
for
transfer
protocols
to
be
QoS,
we're
both
down
and
up,
and
but
we
don't
see
anyone
looking
at
that
and
that
certainly
beyond
the
scope
of
the
current
work,
so
looking
at
it
from
the
architecture
side,
maybe
and
attack
that
and
help
us
give
us
solutions
in
that
area.
That's
really
nice!
You
thank
you.
M
So
if
you
actually
we're
in
the
past
aware
Network
meeting
convinced
that
you
can
go
back
to
your
emails
for
those
who
went
to
ideas
before
got
some
other
conflicts
I'm
here,
to
give
you
a
short
summary
and
explain
what's
going
on,
and
why
go
it's
going
on?
It's
not
my
slide,
so
I
hope,
I,
Callisto
or
a
craniums
on
it.
So
pass
aware
what
is
this
so
traditionally
we
used
to
have
a
host
which
had
one
interface
to
the
network.
M
One
IP
maybe
see
address
one
interface
and
there
were
routers
which
had
a
lot
of
interfaces,
and
it
was
probably
one
of
the
main
difference
right
there.
Outers
a
multihomed
can
forward
packet
between
interfaces
and
August.
Oh
host
has
to
do
is
to
send
packet
to
those
routers
to
be
delivered.
Now
everything
has
changed
now.
We
can
actually
sometimes
tell
a
difference
between
hosts
and
routers
or
I've.
Seen
discussion
on
the
other
mailing
lists,
like
is
my
phone
actually
host
or
router?
M
It
depends
right
if
I
enable
in
tester
ink
on
my
phone,
it
suddenly
became
a
kind
of
router
so
host
now
multihomed
as
well.
They
might
be
multihomed
in
terms
of
still
having
one
interface
which
connects
the
multi
homes
network
or
just
have
more
than
one
physical
interface.
So,
when
host
connect
to
a
network,
what
does
it
know
about
the
network?
M
Traditionally,
nothing.
It's
a
kind
of
black
box
right,
I'm,
sending
packets
and
magically
appears
on
the
other
side
or
not
so
someday.
I
will
be
just
actually
heard
that
that
will
be
really
nice
right
if
host
might
get
some
information
about
the
network
and
not
treat
this
as
a
black
box.
However,
there
are
two
approaches:
routers
are
smart
right.
All
host
needs
to
do
is
to
give
routers
they
put
all
those
packets
and
routers.
Whistles
is
beautiful.
M
Routing
protocols
this
group
is
talking
about,
could
deliver
their
packets
in
the
best
possible
way,
because
routers
run
all
those
named
a
protocols.
No
information
about
pass
and
so
on,
but
people
who
sitting
in
other
rooms
and
mostly
Berkeley
MS
host,
might
have
different
opinions.
Hosts
might
know
better
how
to
send
the
packets
and
how
to
deal
with
retransmissions
packet
lost
and
host.
My
have
some
preferences
on
how
packets
should
be
sent
and
all
the
routers
need
to
do
is
to
take
this
shut
up.
Take
my
packets
and
deliver
it.
M
So,
let's
back
to
the
topic,
because
I
do
not
have
a
much
time.
So
what
is
the
best
awareness?
We
can
look
at
it
as
two
problems.
First
of
all,
it's
a
control
plane.
It
would
be
really
nice
to
know.
We
have
different
paths
in
the
network
right
because
again,
if
my
laptop
is
connected
to
my
enterprise
network,
it's
actually
multi
home,
because
it
has
different
addresses
from
two
different
ISPs
and
there
are
more
than
one
internet
path
available
for
that
host,
but
host
might
even
might
not
even
understand
it.
Then
Welman.
M
There
are
more
than
one
path.
What
kind
of
path
co-host
could
use
as
they
will
equal
all
some
path
might
be
more
equal
than
others.
There
might
be
some
characteristic
of
the
network
path
which
host
or
transport
layer
and
application
layer
and
host
might
need
be
aware
of,
and
then,
when
we
got
all
this
information
on
from
the
control
plane
host
needs
to
be
able
to
use
all
that
information
and
send
packet
as
host
would
like
so
particular
path.
M
Why
do
we
need
a
research
group
because
it
looks
like
there
are
a
lot
of
people
like
ITF
in
different
groups
which
working
on
that
problem
from
different
aspects
right?
It
might
be
much
I
apologized
if
you
do
not
see
your
favorite
work
or
favorite
working
group
here,
because
otherwise
people
will
become
playing
in
Ken's
IETF
million
cleans.
That
font
is
true
small
when
they
could
not
read
the
slide
so
transport
protocol
in
PTC
peak
week,
aggregation
approach
like
I'm,
pretty
sure
some
of
you
been
to
banana.
M
Both
the
control
plane
indeed
like
like
spring,
and
my
favorite
topic
is
multi-home
costs
me
fog,
Orca,
which
now
you
might
have
heard
this
week
about
pvd's
and
so
on
right.
So
it
would
be
really
nice
to
get
all
of
you
in
the
room
and
start
looking
at
this
as
a
long-term
research
topic.
So
we
could
come
back
to
ETF
and
talk
about
what
I
needs
to
be
done.
So
it's
not
the
first
time
right.
We
trying
to
solve
this
problem.
M
Long
time
ago
it
was
ipv4
source
routing
when
host
actually
I
was
able
to
tell
network
houses,
packet
should
be
routed,
and
then
everyone
agreed
it's
a
bad
idea,
security,
scalability
and
so
on.
Yes-
and
it
was
some
work
on
integrated
services
and
I'm
gonna
skip
this
bi
differentiated
services,
kind
of
works
on
MPLS
networks.
Indeed
at
least,
and
then
we
decided
to
a
look
at
ipv6
as
128
beats
ipv4
in
their
advance
source
routing
for
ipv6
and
again
people
agree.
M
That's
a
bad
idea,
well,
more
or
less
the
same
reason
as
it
was
a
bad
idea
for
before.
However,
v6
gives
us
more
opportunities
right
because
I've
been
here
here
ago
in
Berlin,
presenting
Enterprise,
multi-home
and
cane
ipv6
from
Rahil
and
actually
pass
awareness
perspective,
because
multihomed
Enterprise
hosts
need
to
get
some
information
about
available
a
network
path.
So
multihomed
host
I'm
going
to
spend
some
time
on
it
because
I
love
the
topic
so
host
might
be
connected
via
one
or
more
physical,
in
yourself,
every
physical
interface
and
to
the
network.
M
People
try
to
solve
this
problem
for
a
while
right.
Shame,
I
think
there
is
an
RFC
on
shame,
but
I
do
not
think
anyone's
in
a
deployed
from
mobile
on
multi-home,
toast
and
steal.
It
was
more
for
my
village
here,
I
mean
host
could
move
between
different
networks,
but
it
could
not
control
which
network
to
use.
Oh,
yes,
there
is
a
violation
called
Lisp
which
kind
of
trying
to
solve
the
same
problem
but
again
more
from
mobility.
M
Perspective
host
do
not
have
much
control
in
this
case
here,
multiple
TCP,
it's
actually
closer
right
because
host
might
influence
our,
whereas
the
traffic
is
going.
Oh
said:
Ventura,
okay,
I'm
and
the
routed
working
group,
so
a
host
actually,
which
sometimes
can
talk
about
talent
points
as
a
host
as
well
right-
could
send
a
packet
through
predefined
route
by
using
these
are
ipv6
or
MPLS
actually
segment
on
junk
as
well,
and
when
we
start
talking
about
all
these
paths,
awareness
and
given
host
some
informations.
M
The
question
is:
how
host
could
get
that
information,
preferably
as
dynamically
as
possible,
so
ipv6
segment,
routing,
for
example?
How
host
could
know
what
kind
of
headers
to
put
into
a
packet?
One
of
the
ideas
are
proposed
is
to
use
genus
because
Jana's
school,
almost
as
cool
as
BGP,
we
can
use
genus
for
distributing
almost
any
information,
so
yeah
host
could
ask
how
can
I
in
the
genus
please
give
me
pass
to
the
destination
and
get
not
just
name
but
some
kind
of
pass
information
as
well.
M
M
Ok,
I'm
here
here
is
my
network
information,
and
there
is
an
architecture
FC
published
while
ago
and
again
question
how
host
could
discover
it
and
in
our
shiny
new
world
of
ipv6
we
already
have
an
information
of
configuring
host,
provide
increase
with
any
related
network
information
which
called
router
advertisement.
You
could
host
might
not
just
get
a
prefix
and
default
router
and
DNS
information,
but
also
some
other
hints
about
what
is
available
and
I
think
this
draft
been
adopted
in
interior,
but
I'm
not
sure
because
they
miss
the
session
sure
it's
all
good.
M
However,
there
are
some
politicals
or
you
might
even
sometimes
a
security
problems,
because
a
curator
might
believes
it
Iranians.
The
network
hosts
should
not
tell
me
what
to
do
my
network.
My
rules,
however,
and
the
users
might
say
no
I
am
paying
for
the
service.
I
want
to
influence
the
past
and
my
they
might
actually
have
totally
conflicted
interests
right
as
an
operator
of
enterprise
network
I
might
want
to
use
the
cheapest
uplink
possible,
while
my
host
might
might
prefer
using
the
fastest,
doubling
and
so
right.
M
So
it's
also
problem
which
need
to
be
solved
amongst
others,
and
we
believe
that
the
road
to
the
destination
might
not
be
really
easy,
but
it
might
be
interesting
and
beautiful,
because
there
are
so
many
interesting
problems
to
solve.
So
it's
a
proposed
research
group.
We
are
going
to
meet
on
Singapore,
so
please
come
to
the
room
because
it's
I'm
so
sorry
it
was
a
scheduling,
conflict
with
ideas
and
some
other
our
sessions.
Unfortunately,
we
really
missed
routing
people
in
the
Roman
Wednesday.
Please
come
to
Singapore.
M
B
So
if
there
are
no
comments
on
that,
we're
gonna
close
the
session
before
people
get
up.
However,
let's
make
this
a
very
quick
transition,
because
we've
eaten
three
minutes
into
mpls
is
time
already
so,
if
you're
staying
in
for
mpls,
please
stay
if
you're
leaving,
please
leave
any
side
conversations
have
them
outside
and
let's
do
a
quick
transition
to
MPLS.