►
From YouTube: IETF100-SPRING-20171115-1520
Description
SPRING meeting session at IETF100
2017/11/15 1520
https://datatracker.ietf.org/meeting/100/proceedings/
A
A
A
This
is
the
agenda.
I
won't
go
through
it.
You've
seen
it
on
posted
a
couple
of
weeks
ago.
Anyone
having
concern
or
having
any
comments
on
the
agenda.
No,
we
will
proceed.
Then
a
quick
update
on
different
documents,
so
the
working
of
spend
a
lot
of
time
trying
to
push
to
iesg
a
batch
of
two
batches
of
four
documents.
They
made
their
way
and
this
is
the
stages.
A
So
the
three
use
cases
only
is
treated
a
chat
of
mid-december
and
they
are
waiting
for
ID
go
ahead
and
but
just
like
routing
architecture
and
second
housing,
Sinhala
EPE
they,
the
previous
three,
should
soon
be
in
IETF
last
call.
So
these
two
are
in
IETF
last
call
and
iesg
tina,
shot,
mid-december,.
A
Few
words
on
each
of
these
documents,
specifically
on
the
spring
housing
MPs
you
you
might
have
seen
if
you
follow
the
list
which
I
hope
you
do,
allow
made
substantial
and
complete
reviews
of
the
values
documents
which
are
being
addressed
or
have
been
addressed,
but
for
one
of
them,
namely
routing
MPLS,
the
I've
always
decided
to
return
the
document
to
the
working
oak.
So
we
still
have
work
to
do
on
that.
One.
A
Conflict
resolution,
so
there
was
the
last
call
working
up
last
call
some
time
ago
responsible
for
that
there
were
a
good
number
of
comments
and
a
lot
of
discussion,
which
was
good.
There
is
one,
however,
significant
point
which
was
raised
and
which
is
still
not
addressed,
which
is
the
possible
conflict
when,
in
the
case
of
multiple
by
GPS
or
routing
instances,
so
it
needs
to
be
resolved
and-
and
we
are
investigating
ways
on
how
that
could
be
done.
A
Just
to
update
you,
the
documents
that
are
in
iesg
have
went
through
significant
changes.
We
didn't
change
the
fundamentals
of
the
document,
of
course,
but
we
encourage
you
to
go
and
read
the
document
if
you
the
changes,
because
some
of
them
are
important-
I'm
not
going
through
the
whole
list
here,
it's
fairly
cold
and
for
you
to
know,
but
please
remember,
go
and
read
the
latest
versions
of
these
architecture
documents.
They
have
changed.
So
that's
who
for
architecture
and
that's
all
for
segment
MPLS,
but
segment
MPLS.
B
B
B
We've
defined
three
different
roles
in
the
network,
not
that
don't
support
segment,
routing
so
IP
for
order
s
are
capable
routers
that
are
not
in
the
label
stack,
so
they're,
not
directly
addressed
by
a
seat
and
SRK
/
outer
that
are
processing
a
source.
As
you
could
see
in
the
picture
when
ingress
to
the
tunnel
encapsulated
traffic
in
MPLS
and
then
UDP,
it
sets
next
hop
to
the
next
label
in
receive
the
results
internally.
B
B
All
kinds
of
seeds
that
supported
today
and
GPI
supported
there.
There
are
no
really
changes
to
control
plate,
so
very
useful
canal.
Very
useful
comments
with
regards
to
entropy
have
been
received,
and
indeed
there
are
two
types
of
entropy
processing
in
case
when
s
are
capable
not
that
the
single
stack
is
processing
entropy.
It
is
looking
into
in
triple
ables
when
we
are
in
AP
processing
case,
we'll
look
into
UDP
source
ports
that
see
us
to
enrich
entropy.
So
it
has
to
be
coherent
and
consistent.
The
words
your
dream.
B
B
B
B
D
E
F
F
Minor
changes,
since
the
reverse
reversion
is
the
cause.
Remember,
had
been
reduced
to
meet
the
requirement
Kosar
number
limit.
Another
change
is
to
add
some
tends
to
clarify
how
to
word
you're
performing
Hajj
on
the
whole
label
when
we
encapsulate
them
MPs
as
our
package
within
a
you,
IP
UDP
packet,
you
can
see
from
this
figure
no
matter
the
underlay,
the
ipv4
ipv6,
our
MPs
are
the
source,
routing
or
traffic
engineering.
F
F
D
F
Incremental
deployment
of
MPs
as
our
values.
First,
it's
leverage
existing
hardware
capability,
such
as
amperes
forwarding
capability
and
the
MPs,
has
over
UDP
tunneling
capability.
Secondly,
is
facilitated
the
incremental
deployment
of
MPs
SR.
Third,
it
SOCOM
the
load
balancing
issue
associated
with
MPs
SR.
F
Due
to
the
hour,
readable
label,
stack
dips
issue
and
the
maximum
s
ID
dips,
hardware
limitations
force
it
can
seamlessly
integrate
them
with
existing
MPs
routine
technology.
Lastly,
it
works
for
both
ipv4
and
ipv6.
On
the
lace
currently
June
nokia
has
implemented
this
technology.
Juniper
and
Huawei
has
been
to
implement
it.
Cisco
had
developed
a
demo
for
this
technology.
C
H
G
Adrian
Farrell,
so
hot
breaking
news
piece
may
have
broken
out
a
group
of
us
met
lunchtime
today
and
planned
a
strategy
for
merging
this
work.
That
strategy
has
not
yet
been
circulated
amongst
all
the
people
involved.
So
it's
not
a
confirmed
strategy,
but
if
it
works
out,
then
we'll
be
able
to
pull
text
from
both
documents
together
and
have
a
joint
author
team
and
a.
I
Basundi
Cisco
Systems
I
just
have
a
comment
that
I
mentioned
in
the
MPLS
working
group
I
believe
an
ANA
co-author
on
house
Gras.
A
draft
I
believe
that
this
draft
belongs
here
rather
than
MPLS,
because
there
is
really
nothing
created
to
MPLS
here,
except
just
taking
the
entropy
from
the
source
port
and
putting
it
somewhere
else
and
back.
And
if
this
is
the
case,
it
should
not.
I
J
H
Romantics
Nokia
I
only
want
to
echo
the
fact
I
this
should
be
merged
and
as
soon
as
possible
and
having
mom
draw,
because
it's
actually
the
same
thing
which
solves,
but
at
the
end
of
the
day,
we
should
involve
all
the
people
involved.
If
we
have
such
a
discussion,
we
should
involve
all
the
people,
authors
and
quarters
in
it
at
the
fact
that
one
of
them
is
not
invited.
G
Yeah,
the
authors
are
going
to
go
I'm
working
on
this,
while
everybody
else
discusses
where
it
should
be
and
I'm
not
Precious
about
where
it
should
be.
It
clearly
needs
to
be
talked
about
on
both
mailing
lists
and
which
working
group
it's
in
really
I,
don't
care,
because
once
it's
an
RFC,
nobody
will
remember
where
it
came
from.
B
K
Being
from
Hawaii,
so
that's
the
I
I
think
that
the
Union
fact
that
it's
a
proposed
effect
says
that
a
user
several
years
ago
this
this
work
has
been
present
here
that
you
know
bream
working
group.
But
this
is
not
to
be
accepted
by
the
sabrine
working
group.
They
need
to
move
to
I'm
sure
so
working
group
so
now
I
think
that
the
software,
the
SRM
cars
you
should
always
some
work-
could
be
overlapped
in
both
the
working
group.
So
now
I
think
it
is
the
first
step.
K
B
L
Low
Anderson,
so
today's
discussion
on
where
it
goes
currently
it
is,
is
a
candidate
for
working
group.
Adoption
in
MPLS
will
be
quite
a
process
to
get
back
from
there.
We
had
a
kind
of
rough
discussion
between
the
shares
and
the
ideas,
and
the
outcome
was
rather
grudgingly,
but
that
gives
to
mpls
I
have
7510
in
MPLS.
L
So
that's
a
very
related
document
and
I
want
to
keep
that
all
the
agreements
that
we
had
in
the
background
and
that
document
was
formed
to
the
forefront
and
these
documents
go
through
and
I'm
a
little
bit
concerned
about
the,
and
it
hasn't
been
discussed
really
in
the
two
documents
discussed
here.
But
there
is
a
service
chaining
documented.
It's
also
a
companion
document
to
this
that
could
touch
the
special
purple.
Labels
and
I
definitely
want
that
in
in
the
MPLS
workgroup.
I
I've
met
by
Shonda,
Cisco
Systems
related
in
regard
to
7510.
This
was
not
did
not
even
mention
the
term
source
routing.
It
was
not
addressing
that
source
routing
is
addressing
MPLS
over
UDP
tunnel.
This
draft
is
something
else.
It
says:
source
routing
over
IP
underlay,
so
that
is
quite
different
from
7510.
This
really,
in
my
bill,
in
my
opinion,
belongs
here
not
in
MPLS
working
group.
G
Adrian
found
to
Bruno's
question
about
other
tunnels.
It's
clear
that
you
could
tunnel
MPLS
SR
over
anything
the
intent.
Well,
certainly,
the
the
intent
of
the
authors
of
one
document
and
I
think
the
intent
of
the
authors
of
both
documents
is
to
focus
at
this
stage
on
the
encapsulation
that
there
is
an
immediate
need
for,
and
our
suggestion
is
that,
if
other
encapsulations
are
wanted
for
other
tunnel
types
should
cause
different
documents.
H
B
E
Hi
this
is
Emma
from
Hawaii.
The
two
points
first
point
is
that
tunnel
end
cap
depends
on
the
neighboring
router,
which
advertises
what
tunnel
capable
it
has
that
has
been
defined
in
AGP
documents,
so
it
depends
on
actually
which
digress
address
router,
which
what
it
can
handle
depends
on
that
it
may
be.
It
might
be
that
you
know
some
of
the
tunnel
types
need
a
separate
document,
because
you
have
to
transit
the
entropy
from
the
listening.
That
is
one
point
and
second
point
is
in
the
MPLS
working
group.
E
There
was
a
discussion
on,
but
that
these
these,
what
you
call
in
the
picture,
the
two
IGP
domains,
are
one
IP
domain.
I
think
this
draft
is
about
one
IP
domain
because
of
the
essa
sRGB
complications.
If
you
move
it
to
two
IGP
domains
and
tunnel
it
this
be
extended,
work
I,
think
it
is
better.
If
you
keep
it
it
to
one.
I
JP
don't
mind.
F
F
L
So
Louie
Anderson
again,
oh
that's
odd.
We
had
requests
from
both
group
of
authors
on
the
both
document
to
actually
adopt
the
documents
in
the
MPLS
working
group
and
that's
actually
what
triggered
the
discussion
where
it
did
go
and
actually
where
the
outcome
was
MPLS.
So
if
you
send
you
can't,
you
can
only
have
it
actually
accept
adopted
in
one
and
one
group.
It
doesn't
work
the
other
way.
Yes,.
A
M
Yeah
I
like
to
come
into
lower
comment
when,
when
individual
draft
comes
and
presented
to,
multiple
working
group
is
not
intention
for
the
authors
to
be
asking
for
an
optician
from
one
or
the
other
is
asking
for
adaptation
period.
So
I,
don't
you
can
imply
that
because
it
was
presented
in
MPLS,
it
was
like
that.
G
So
my
actions
are
today
to
write
up
the
the
notes
on
the
meeting
we
had
circulated
to
the
people
who
were
at
the
meeting
and
get
them
to
agree,
circulate
it
to
all
of
the
co-authors,
get
them
to
group
to
agree
and
then
start
the
process
of
doing
it.
We
wrote
down
a
classically,
optimistic
software
industry
plan
for
doing
it
that
sees
us
completing
our
merger
and
posting
the
draft
in
four
weeks.
G
E
Himanshu
Shah
from
Siena
since
everybody's
making
the
comments
I
might
as
well,
so
my
preference
would
be
to
progress
it
here,
because
if
you
look
at
the
draft
and
what
the
work
is
he's
actually
segment
routing
just
because
it
is
going
over
the
MPLS
and
IP
network
or
one
encapsulation
type,
doesn't
necessarily
mean
that
it
should
be
processed
in
the
MPLS
working
group.
So
my
strong
preference
would
be
to
do
it
here.
J
Lot
of
Thunder
roaring,
Edie
still
again
we're
merging
this
draft.
We
are
making
decisions
on
something
that
we
don't
know
what
it
is
yet,
even
though
I
think
we
have
a
pretty
good
idea,
I
think
we
should
wait
and
see
the
draft,
and
then
we
can
decide
I
agree
with
law
as
well.
On
the
other
previous
discussion
that
was
had.
J
If
this
draft
the
merge
TRAF
tends
to
be
in
the
same
direction,
which
I
assume
it
will
be,
it's
the
ones
that
we
have
here
and
then
probably
the
same
decision
that
the
chairs
in
MPLS
and
spring
had
gone
to
should
probably
stand
again.
My
opinion:
let's
wait
for
the
marsh
draft
and
then
we
can
make
decisions
and
actually
talk
about
something
we
can
actually
see.
G
So
why
did?
Why
did
we
even
bother
writing
this
document?
There's
some
work
in
BES,
which
is
about
a
BGP,
a
couple
of
BGP
extensions
to
enable
connection
across
about
a
backbone,
and
although
the
document
talks
names
itself,
data
center
gateway,
that's
an
old
file
name
and
we're
really
talking
about
connecting
segment
routing,
enabled
domains
that
documents
just
got
a
couple
of
tiny
little
BGP
tweaks,
it's
a
it's
a
very
small
document
and.
G
G
G
It's
not
dissimilar
to
a
VPN
problem.
Our
solution
to
that
is
that
you
make
or
gateways
visible
on
gateways
to
a
site
visible
across
the
whole
network.
Then
there's?
How
do
you
actually
select
which
path
over
the
backbone
to
use?
You
don't
actually
need
the
full
path.
Obviously
you
just
need
the
entry
and
exit
to
a
domain
and
the
path
a
tunnel
across
the
domain
could
be
segment
routing
or
it
could
be
a
an
MPLS
tunnel
or
whatever,
but
you
do
need
to
see
reach
ability.
G
You
do
need
to
understand
where
you
can
get
to
and
as
I
implied
the
backbone
may
or
may
not
be
segment
routing
enabled
we
want
to
be
able
to
support
both
classic
problem.
How
do
you
identify
the
tunnels
in
the
backbone
and
how
do
you
provide
enough
visibility
of
all
the
options
and
the
topology
to
a
controller
without
splatting
the
controller,
with
absolutely
every
link
in
the
networks?
G
So
here
it
suddenly
goes
into
a
nice
small
font
because
there
are
a
lot
of
building
blocks
available
and,
in
fact,
an
easy
way
to
to
check.
This
is
to
go
to
the
references
section
in
the
draft
and
just
see
whether
your
favorite
sr
technology
document
is
referenced
and
chances
are.
It
is
what
I've
done
here
is
pull
out
some
of
the
key
ones.
So
don't
get
offended
if
your
your
favorite
is
not
on
this
side
go
check
the
the
draft
itself,
so
we
need
to
learn
about
the
topology.
G
That's
available,
learn
about
the
network
and
BGP
LS
gives
us
that
capabilities
about
seventy
seven,
fifty
two
and
the
the
work
in
IDR,
four
segment,
routing
extensions
to
BGP,
LS
and
then
as
a
kind
of
side
bar
to
that
seventy
nine.
Twenty
six
has
lots
of
discussion
about
how
you
abstract
a
network
and
report
the
connectivity
potential
across
that
network,
using
blue
GP
LS
up
to
a
controller.
G
We
need
to
be
able
to
bind
labels
to
prefixes
and
we
have
plenty
of
work
on
that
and
we
need
to
obviously
assign
policies
for
placing
traffic
onto
paths
and
advertise.
Those
policies
and
I
think
I've
got
the
right
version
of
the
documents
they're.
All
there
has
been
some
name
changing
and
adoption
going
on
and
that's
such
an
interesting
point.
The
draft.
The
draft
is
actually
slightly
out
of
date
on
on
name
changes
and
needs
refreshing.
G
We
need
to
talk
about
which
tunnel
type
to
use
to
reach
a
prefix.
There
may
be
options
to
to
go
in
to
LSPs
or
to
do
segment
routine
or
whatever
other
tunnel
and
the
tunnel
end
caps
document
is
quite
handy
for
that,
and
then
we
need
to
be
able
to
discover
all
the
gateways
to
a
site.
Each
gate.
Each
gateway
needs
to
know
the
other
gateways
to
the
site
and
we
need
to
get
end-to-end
advertisement
of
the
available
gateways
and
that's
what
the
best
document
covers.
G
So
I've
got
a
worked.
Example
in
just
a
couple
of
slides
and
a
couple
of
steps,
and
so
the
first.
The
first
step
is
the
exporting
of
topology
and
the
abstraction
and
the
building
tunnels
and
assigning
SIDS
and
the
little
picture
there.
Is
that
reference
architecture
and
really
that
reference
architecture,
maps
down
to
the
bigger
picture
here,
where
the
cloud
networks
are
replaced
by
the
available
tunnels
or
paths
and
those
tunnels
or
paths,
are
assigned
SIDS
so
that
you
can
refer
to
them
in
an
end-to-end
path.
G
So
the
example
here
is
as
a
path
that's
going
out
of
gateway,
1a
and
back
into
the
destination
domain
through
gateway
3b,
and
you
can
map
that
through
to
the
individual
SIDS
that
identify
that
path.
So
that
would
be
the
fully
explicit
label
stack,
but
there
may
be
reductions
on
that.
For
example,
maybe
the
egress
domain
chooses
not
to
share
its
topology
because
it
regards
it
just
as
a
reach
ability
issue
once
that
packet
is
into
that
domain,
it's
its
own
responsibility,
so
you
would
shorten
that
stack
by
taking
out
the
402
and
main.
G
G
Some
people
say
listen.
This
is
just
a
white
paper.
It's
telling
you
how
to
use
the
various
bits
and
pieces
very
interesting,
publish
it
as
a
white
paper
move
on
and
actually
that's
where
we
started,
but
other
people
are
saying
it's
really
helpful
to
understand
how
all
the
other
IETF
work
fits
together
and
and
therefore
would
be
a
useful
archival
thing.
The
authors
have
found
that
second
point
to
be
true
in
best,
but
maybe
once
it's
written,
it's
done
and
it
served
its
purpose.
G
What
we
plan
to
do
is
keep
it
alive
for
a
bit
as
a
framework
for
discussion,
and
it's
our
view,
although
some
of
that
other
work
is
happening
in
IDR
and
in
the
IGP
working
groups
and
even
a
PC
working
group.
This
this
place
looks
like
a
good
point
to
anchor
the
discussion
of
all
the
building
blocks.
B
So
it
is
helpful,
haven't
had
the
routing
working
group,
chair,
I,
think
our
job
here
is
not
only
to
work
on
new
technology,
but
making
this
technology
understandable
and
available
for
people
to
use
so
spending
time
and
effort
on
explaining
technology
pushing
different
pieces
together
is
very
valuable,
especially
for
newcomers.
People
who
don't
know
the
history
and
cannot
follow
everything.
With
regards
to
countenance
document,
we've
been
working
on
packet,
optical
gateway
using
second
routing
semantics,
so
it's
quite
convenient
to
abstract
semantics
of
ln
path
behind
bindings
it.
G
I
think
it's
a
really
good
point
in
this
picture
that
that
top
tunnel
that's
marked
l2o
to
you.
You
clearly
wouldn't
want
well
clearly,
in
my
view,
you
wouldn't
want
the
source
controlling
every
hop
that
that
tunnel
is
taking,
but
even
in
that
case
this
example
has
got
eight
labels
going
on,
and
that
is
probably
going
to
be
too
many,
and
so
you
would
scale
down,
as
shown
here,
delegating
some
of
the
the
choices
another.
B
Important
point
and
think
about
aggregation,
a
GPS
is
the
blast
radius.
If
failure
in
one
domain
is
propagated
to
another
domain,
you
are
dealing
with
its
consistency
and
but
routing
in
general
balance.
It
provides
stable
anchor
point
and
if
another
domain
has
a
faller
most
probably
it
would
be
able
to
recover
and
still
provide
the
reach
ability
of
another
path.
So
he
keeping
this
hidden
and
reducing
blast
radius
would
probably
result
in
better
network
and
more
stable
network
yeah.
E
This
is
a
reminder
we
would
like
you
to
read
on
these
documents.
They
are
very
well
written.
There
is
a
good
documentation
about
how
this
whole
architecture
is
coming
along.
Please
read
the
network
programming.
E
What
is
being
done
with
the
SRS
header
and
then
the
BG
pls
s,
a
v6
extension,
which
is
the
base
draft
for
which
the
service
chaining
ID
are
draft,
is
extended
problem.
What
we
are
trying
to
solve.
What
we
want
to
do
is
we
want
to
provide
an
alternate
solution
to
do
service
training
based
on
segment
routing
over
the
MPLS,
our
s,
our
v6
data
plane.
E
We
want
to
provide
an
ability
to
be
able
to
discover
these
services
and
associated
service
sits
for
those
services.
We
also
want
to
enable
a
solution
which
is
in
line
with
how
the
today's
srte
solution
works
and
add
these
services
as
just
the
elements
or
SIDS
in
that
list.
So
the
solution
will
be
flexible.
It
is
it's
a
fully
scalable
and
that
way
we
can
enable
the
service
sharing
solution
with
it,
with
the
current
SRD
architecture
which
we
have
solution.
So
what
are
service
functions?
The
way
we
try
to
define
the
service
functions?
E
We
try
to
define
it
as
the
s
are
aware,
which
means
it
can.
It
is,
has
an
ability
to
process
the
traffic
which
is
which
is
coming
in
with
the
service
set?
S
are
unaware?
Is
we
realize
that
not
all
the
services
will
be?
S
are
aware
from
the
first
from
the
get-go,
so
those
services,
we
created
a
concept
of
our
proxy,
so
the
underlying
routing
system
act
as
the
proxy
on
behalf
of
those
service
functions
and
it
you
know
we
also
have
the
ability
of
these
services
to
be
discovered
using
using
a
mechanism.
E
So
what
is
an
SR
proxy?
There
are
different
behaviors,
which
we
have
documented
in
France
versus
Doc
ument,
for
the
service
training
based
on
segment
routing
architecture
document.
We
have
defined
it
as
the
static
proxy,
which
is
really
me
too.
It's
today's
solution,
dynamic
proxy,
shared
memory,
proxy
and
masquerading.
We
I'll
not
be
covering
all
of
them,
I'll
just
be
covering
the
first
two.
The
these
are
described
in
very
well
details
in
that
document.
So
please
review
it.
If
there
is
any
question
we
can
talk
over
the
mail
list
or
just
come
talk
to
me.
E
Static
proxy
static
proxy
is
similar
to
you
know
what
we
have
today.
The
service
training
solution
where
static
information
is
being
configured.
So
in
this
particular
case
you
have
a
VPP
node,
which
is
hosting
our
service,
which
is
attached
to
it.
We
have
a
static
configuration
for
an
active
set
like
e
1,
:
:,
a
the
underlays
ipv6
in
this
particular
example,
and
so
the
packet
comes
in
with
the
SRH
header,
with
even
:
:
a
and
the
VPP
realized.
Oh,
this
is
something
which
I
have
instantiated
locally.
E
It
D
caps,
the
outer
header,
which
is
the
ipv6
header
and
the
SRH
it
sends
the
packet,
which
is
an
IP
views.
Ipv4
inner
packet
to
the
service
function.
Service
function
does
its
thing:
the
packet
comes
back.
You
had
an
inbound
policy
on
the
input
interface
and
that
that
is
configured
to
match
the
packet,
which
is
coming
in
put
the
packet
back
and
copy
over
the
next
segment
from
the
SRS
header,
which
is
c2,
:,
:
1
to
the
destination
address
and
send
it
over
the
wire.
E
So,
as
you
can
see
in
this
particular
solution,
it's
it's
today's
concept,
which
we
have
with
the
service
chaining
the
inner
packet
can
be
ipv4,
ipv6
or
Ethernet.
We
just
have
to
maintain
a
change,
static
configuration
and
it
the
one
of
the
most
important
point,
even
though,
is
similar
to
the
current
solutions.
You
also
still
have
an
ability
to
be
able
to
do
the
basic
architecture
of
segment
routing
provides
like
you
can
do.
Sla,
based
steering
and
stuff
like
that.
E
Dynamic
proxy
is
more
advanced
than
static
proxy.
So
in
this
particular
case
the
VPP
is
running
the
new
code.
The
packet
comes
in,
you
have
a
local
set,
which
is
instantiated
as
even
:
:
B,
and
it's
instantiated
with
a
function
which
we
have
defined
in
the
service
training
architecture
document
as
n
dot
ad
packet
comes
in,
we
D
cap,
the
outer
header
caches
that
information.
So
that's
the
important
point
here
sense:
the
inner
bare
minimum
packet
to
this
service
function.
So
this
function
applies
the
the
what
it
needs
to
do.
E
The
packet
comes
back
on
in
ingress
interface,
and
then
it
restores
the
IP
header,
which
was
cached
locally,
constitutes
the
same
SRH,
an
ipv6
header
decrements.
The
segment
list
left,
which
is
a
normal
procedure
copies
over
the
next
segment,
which
is
C,
2,
:,
Kol
1
into
the
destination
address
and
sends
the
packet
out
again.
The
inner
packet
can
be
ipv4
ipv6
or
could
be
Ethernet.
So
it's
completely
stateless
from
that
point
of
view
now
now.
E
The
important
point
here
is
that
once
these
services,
which
are
being
defined,
needs
to
be
needs
to
be
discovered
to
the
controller,
so
we
are
proposing
the
bgp
extensions.
The
base
draft
is
this
segment
ordering
v6
bgp
LS
extension
document.
So
what
we
are
proposing
is
some
new
C
sub
T
alvey's.
So
what
needs
to
be
sent?
We
need
to
send
what
the
service
type
is.
We
need
to
send
the
set
associated
with
it,
which
is
in
the
base
TL
v.
E
We
need
to
send
the
traffic
type
this
service
is
capable
of
which
is
basically
an
ipv4
ipv6
or
Ethernet
inner
packet.
We
encode
that
information
into
the
ste
LV
signals
at
through
bgp
LS
arm.
If
it's,
if
the
service
is
in
a
particular
VPN,
we
signaled
in
Safa
72
else
inside
itself
is
71.
We
send
this
information
over
to
the
controller.
E
Also,
services
can
have
the
data
which
you
know
we
don't
want
to
standardize
on
like,
for
example,
vendor
specific
information
brand
version,
so
you
can
have
a
firewall
from
one
vendor
a
with
a
version,
a
dot
B.
You
have
another
vendor
Y
with
X
dot
Y.
As
a
version
number.
We
encode
that
information
in
this
opaque
metadata,
TLV
and
signal
it
to
the
to
the
controller.
The
benefit
here
is
that
only
the
consumer
and
the
publisher-
and
you
really
needs
to
know
what
the
opaque
type
is
and
what
the
data
is
encoded.
E
From
the
implementation
point
of
view,
the
functions
which
we
we
described
earlier,
the
proxy
functions
for
the
s
are
aware,
are
already
implemented
in
the
open
source
software.
You
can
download
it
from
the
segment
routing
dotnet
and
it's
implemented
on
Linux
kernel
and
it's
implemented
fti
o
vb
p.
We
also
have
an
implementation
of
the
static
proxy,
which
is
today's
solution
of
how
the
service
chaining
works.
A
static
proxy
is
configured
as
n
dot.
A
s
function
again
described
in
the
segment
routing
architecture
document.
E
We
have
done
it
on
cisco
hardware,
so
let
me
know
if
you
are
interested
and
we
have.
We
are
already
working
with
academia
and
few
other
partners
to
aware
the
service
chaining
on
the
functions
as
as
the
native
service
service
chaining
functions,
so
those
applications
will
be
able
to
process
the
SR
as
a
header.
It
process
the
SR
header
and
also
can
understand
the
CID
in
that
particular
case.
What
happens
is
if
you
know
what
the
SRT
solution
is.
This
function
itself
becomes
a
part
of
the
network.
E
So
from
that
point
on,
this
is
a
completely
stateless
solution
and-
and
you
know,
the
nodes
can
can
be
auto
discovered
using
the
BGP
LS
and
then
it's
just
another
said
in
the
SRS
header,
with
that
what
we
like
to
do
is
to
seek
the
input.
This
is
again
an
alternate
solution
of
service
training
which
we
are
providing
with
segment
routing.
Where
you
can
unable
you
know
so
shining,
you
can
still
do
segment
routing
SLA
based
earring,
so
we
would
like
to
seek
your
input
and
feedback
and
any
suggestions
welcome.
N
Well,
you
compare.
You
have
a
section
that
comparatives
or
discusses
the
relationship
with
the
SFC
architecture.
76
65
I
think
that
actually,
that
probably
not
very
productive,
because
comparing
approach
that
is
similar
to
one
that
have
control
plane
in
distributed
routing
protein
versus
the
source
rolling.
It's
like
you
compare
our
oranges
and
apples.
Yes,
you
have
controlled
with
the
source
routing
but
distributed.
N
Routing
has
its
own
advantages.
One
thing
that
I
wonder
is
that
why
not
to
use
the
terminology
that
established
in
76
65,
because
then
it
makes
discussion
much
more
easier
when
you
use
the
same
dictionary,
because
you
talk
of
the
same
entities
and
the
same
functionality
using
your
own
terminology,
there
is
a
terminology.
N
E
E
N
N
I
Bash
on
the
Cisco
system.
Just
to
reply
to
this,
there
may
not
be
a
one-to-one
mapping,
so
maybe
now
maybe
later
it
will
not
so
so
saying
that
whatever
Barrabas
is
proposing
must
have
an
equivalent
in
SFC.
It's
not
the
right
way.
We
want
to
go,
we
want
you
segment
routing,
and
maybe
there
will
be
one
to
one
mapping,
maybe
not
I
mean.
E
E
O
How
to
properly
do
service
function,
changing
everything
that's
necessary
for
it
and
then
we're
saying
we're
gonna.
Do
this
different
other
way
that
isn't
quite
the
same?
It
may
not
be
the
same.
Are
we
going
to
make
mistakes?
Are
we
going
to
repeat
mistakes
if
we
reuse
the
architecture,
but
do
the
implementation
in
the
fore
differently,
then,
at
the
very
least
we
you
know,
there's
just
some
consistency
there
and
I
guess
in
C
is
valuable
and
the.
E
P
So
this
draft
talks
about
a
mechanism
where
you
can
label
a
provide
path,
level
label
in
segment,
routing
so
problem
statement
so
for
using
segment,
rodding
MPLS
the
segment
path
is
represented
as
a
stack
of
labels,
but
when
these
packet
shreds
made
it
along
the
path
when
the
intermediate
point
started
to
pop
up
the
labels,
when
you
reach
the
egress
point
you
you
basically
lose
all
these
Pat's
information
and
you
can't
identify
where
the
packet
is
actually
original
from
which
ingress
point.
So
we
do
have
this
requirement.
For
example,
in
service
provider
point
of
view.
P
P
P
When
you
do
as
such,
you
can
basically
find
out
where
which
which
path
these
packet
belongs
to
and
the
second
up.
The
second
proposal
is
basically
to
add
not
only
a
path
label,
but
also
a
source
label
which
identify
the
ingress
point.
So
the
path
label
is
also
assigned
by
the
egress
point
where
the
source
label
is
asserting
the
source.
Sorry,
the
source
label
is
basically
signed
by
the
egress
point
where
the
path
label
can
be
locally
decided
by
the
source
ingress
point,
so
these
two
label
addition
to
label
give
you
better.
P
Give
you
more
label
more
label
a
bit
so
and
with
this
two
layer
of
Haraki
label,
you
can
basically
have
more
flexibility
of
labeling,
your
path,
it
more
extendable,
so
in
terms
of
use
cases
or
application.
For
example,
in
this
diagram
we
will
basically
demonstrate
the
first
option
where
you,
you
only
have
the
path
label
and
the
upper
red
one
red
path
is
labeled
by
2001
and
the
bottom
one
is
fun
too.
So
it's
on
at
the
bottom
layer
of
the
labels.
P
P
We
have
noticed
that
not
only
us
are
looking
at
this
this
this
problem
and
there's
another
proposal
which
will
be
also
demonstrated
here
to
myself.
So
it
will
be
worth
for
the
working
group
and
for
everyone
to
have
more
discussion
which
options
are
going
to
be.
You
know
fit
for
what
kind
of
use
cases
and
yes
and,
and
we
would
love
to
hear
about
your
comments
and
and
and
and
and
advices.
Thank
you
very
much.
Okay,.
I
N
N
N
P
So
well,
there's
three
use
case,
I
think
the
most
sounding
one.
For
example.
If
you
want
to
do
your
one
plus
one
protection,
then
you
have
to
know
which
path
is
which
one,
but
in
your
even
in
your
egress
point
or
any
of
those
intermediate
node,
you
won't
know
where
to
come,
because
all
the
labels
have
popped
up
by
the
previous
ones.
So
that's
why
you
will
need
that
path
level,
identification
to
make
you
you
know
which,
which
which
packets,
from
which
powers
who
we
have
both
paths-
accidentes
yeah,.
N
R
Imagine
so
you
think,
is
the
only
use
of
special
episode
label.
You
can
you
cannot
current
identify
whether
this
package,
from
which
pass
you
cannot
there's
for
all
paths
you
can
for
all
the
past.
You
can
put
indicator
in
the
inner
packet,
but
you
cannot
differentiate
this
package
from
which
pass.
You
cannot.
R
N
S
Hi
Dave
Allen
Erickson
first
I'd
like
to
state
that
I
like
sort
of
the
general
direction
this
is
going
in
and
the
problem
space
that
it's
looking
to
address
I
think
there's
a
couple
of
interesting
aspects
to
this.
You
know:
I've
got
some
opinions
in
terms
of
I
think
what
the
better
choices
are.
Of
course,
I'll
have
to
hear
the
other
draft,
but
certainly
I'm,
very
interested
in
participating
in
and
pursuing
this
whirring
we
can
discuss
okay.
Thank
you.
I.
E
Can't
allow
liquor,
Cisco
Systems,
so
I
yeah,
hi,
Kate,
ontological,
Cisco,
Systems,
so
I
think
the
performance
measurement
is
right.
There
are
existing
mechanisms
and
it
may
be
useful
to
check
if
we
can
extend
them
on
one
plus
one
path.
Protection
I
agree
that
this
can
be
done
without
this
solution.
There
are
existing
ways
to
detect
and
trigger
on
the
last
one
as
well.
This
is
yeah.
There
are
again
existing
mechanisms,
but
we
can
look
at
that
regard.
Yeah.
Thank
you.
E
B
E
A
quick
comment
here
regarding
the
first
point:
you're
trying
to
do
the
profiles
management
based
on
the
segments
list,
which
you
haven't
maintained.
You
can
do
that
by
steering
the
traffic
into
a
binding,
said
and
just
doing
the
performance
measurement.
That
way,
what
is
other
use
keys
here
so
I
didn't
hear
very.
E
Very
useful
work,
but
this
draft
doesn't
indicate
how
do
you
how
they,
how
they
each
know,
transit
node,
has
to
look
into
this
last
path
light.
So
this
needs
to
be
described
whether
what
is
the
rld-
and
you
know
where
to
put
this
and
also
need
to
indicate
that
each
transit
know
Dwight-
has
to
look
it
to
the
last,
not
last
label.
These
needs.
P
D
T
Good
afternoon
everyone
I'm
going
to
talk
about
the
MPLS
SR
path,
identifier,
so,
let's
jump
into
the
problem
space.
So
it's
an
MPLS,
SR,
Network
and
certain
link
is
running
hot
and
we
want
to
figure
out
which
of
the
MPLS.
Sr
paths
is
contributing
to
the
traffic
on
that
particular
link.
So
we
should
be
able
to
count
the
traffic
per
MPLS
SR
path.
So
the
problem
here
is
measuring
the
traffic
on
the
English
would
not
be
sufficient
to
figure
out
which
MPLS
SR
path
as
causing
carrying
how
much
traffic
on
that
link.
T
Because
SR
is
a
ecmp
aware
mechanism.
So
on
every
node
there
will
be
a
CMP
hashing
and-
and
you
really
don't
know-
on
a
particular
link
for
a
particular
SR
path,
how
much
traffic
is
really
flowing
and
you
won't
be
able
to
distinguish
based
on
the
label
stack
because
at
that
particular
point,
the
labels,
which
are
inserted
from
the
source.
Some
of
the
labels,
might
have
been
popped
off
and
you
only
have
the
late
remaining
labels,
which
will
not
be
able
to
distinguish
the
paths
based
on
the
label
stack.
T
So
the
high-level
solution
is
to
come
up
with
the
identifier,
a
globally
unique
identifier
and
then
put
it
in
a
packet
header.
So
it
should
be
possible
to
find
this
identifier
in
the
packet
header.
So
you
really
need
a
distinguisher
to
identify
that
there
is
a
path
identifier
below
this
distinguishing
label
and
it
has
to
be
transparent
to
legacy
implementations
so
forwarding,
plane
legacy.
Mpls
forwarding
plane
should
be
able
to
work
fine
with
this
solution.
T
So
there
are
we've
come
up
with
two
options:
one
option
where
there
are
three
label
additional
labels
getting
pushed
on
the
stack
and
there
is
another
option
where
two
labels
are
pushed
on
the
stack.
So
there
is
an
SR
path
indicator
label.
This
is
a
special
purpose
label
from
the
MPLS
reserve
label
space,
so
this
implies
that
there
are
special
labels
below
which
are
used
for
accounting
and
not
forwarding
the
traffic.
T
So
the
next
label
is
a
path
identifier.
It's
a
19
bit
unique
label,
so
this
could
be
globally
unique
or
scoped
for
up
on
a
node
basis.
So
when
it
is
scoped
per
node,
then
you
have
this
node
identifier
below
this
path.
Identifier
and
the
SI
bit
in
the
path
I
did
in
the
second
label,
identifies
whether
there
is
a
node
identifier,
present
or
not
so,
together
with
the
path
identifier
and
the
node
identifier
is
used
as
a
key
to
count
the
traffic
and
then
to
export
this
information
to
external
entities.
T
So
to
save
the
label
stack,
there's
also
another
option
where
you
just
have
the
path
identifier.
So
in
this
case
the
path
identifier
is
a
globally
unique
number.
So
so
all
the
SR
paths
in
your
network
must
use
a
globally
unique
number
and
then
insert
this
path
identifier
into
the
packet,
so
you
get
19
bits
of
a
path
identifier
space.
T
So
if
that's
not
sufficient
and
that
gives
around
a
half
a
million
s
are
passed
through
your
network
and
if
that's
not
sufficient,
then
the
second,
the
first
option
model
a
can
be
used
to
get
a
higher
scale
so
other
than
that
other
the
forwarding
plane
procedures
are
pretty
similar.
Only
thing
is
you
look
at
the
C
bit
and
then,
if
C
bit
is
1,
that
means
that
you
just
have
to
use
the
path
identifier
as
a
key
to
count
the
traffic.
T
So
where
does
this
special
labels
put
up
in
the
stack
label
stack?
So,
ideally
as
you,
if
we
assume
every
node
is
capable
of
reading
the
label
stack
whatever
the
ingress
prepares
and
every
node
in
the
network
is
capable
of
reading.
This
label
stack
and
it's
ideally
would
go
at
the
bottom
of
the
stack.
But
that
is
not
the
real
deployment
scenario
that
could
be
nodes
which
cannot
Lee,
which
cannot
read
the
label
stack
up
to
the
final
hop
in.
T
In
such
cases,
these
County
accounting
labels
have
to
appear
multiple
times
and
they
have
to
be
placed
in
the
label
stack
in
such
a
way
that
every
node
in
the
network
can
can
be
able
to
access
it
and
then
account
the
traffic,
and
so
we
we
are
whenever
it
appears
at
the
top
of
the
stack.
It
needs
to
be
popped
off.
T
So
these
labels
have
to
be
placed
in
such
a
way
that
nodes
which
understand
the
special
label,
the
these
labels
appear
at
the
top
of
the
stack
only
when
a
node
on
get
exposed
at
a
node
where
which
can
understand
these
labels.
So
we
need
to
have
an
eye
advert
I
mean
extension
to
a
GPS
to
advertise.
The
capability
of
this
mechanism.
T
T
T
So
this
is
a
difference
between
what
is
a
path
identifier
and
what
is
the
binding
said
so
so
there's
our
architecture
already
defines
a
binding
set,
so
the
scope
is
like
bindings,
it
could
be
global
scope
and
or
it
could
be
local
scope.
Similarly
s
our
path,
identifier
also
could
be
global
or
no
local
scope
and
the
purpose
of
binding
said
is
traffic
steering
into
a
star
paths,
whereas
this
purpose
of
this
SR
path,
identifier,
is
traffic
accounting.
T
So
generally
the
action
for
binding
seed
would
be
pop
off
and
replace
with
the
label
stack,
whereas
a
South
path,
identifier
should
pop,
it
should
be
popped
off
and
it
appears
on
the
top
of
the
label.
Stack
and
binding
seeds
are
20
bit
and
it's
our
path.
Identifier
is
19,
so
that's
in
spite
of
all
these
differences,
it's
very
much
possible
that
if
an
operator
wants
to
use
a
locate
and
SR
path,
identifier
and
use
it
also
as
a
binding
seed
for
the
policy,
this
should
be
very
much
possible
to
do.
A
A
Not
taking
any
question
sorry
for
that
in
to
respect
the
last
presentation,
so
each
other
it
was
presented
in
MPLS
already,
so
you
have
had
time
to
already
opportunity
to
present
it
offer
to
discuss
it
and
also,
as
Laura
mentioned,
that
discusses
special
purpose.
Labels
and
lower
might
want
to
have
the
discussion
in
MPLS
as
well.
So
please
wait
now,
don't
even
try
the
far
you
can
sit
down
and
honestly
I'm
and
I'm
burning
time
on
the
last
presentation.
Please
Thank
You
Sanne.
U
Hello:
everyone,
my
name
is
Aaron
Duke,
Cisco
Systems
talking
today
about
segment,
routing
and
Sdn.
That's
what
we're
looking
at
is
what
we've
looked
at
is
SD
when
are
over-the-top
VPNs
and
their
use
of
a
default
path
through
the
network
to
reach
their
endpoint.
And
how
can
we
provide
them?
Access
to
some
SLA
x'
SLA
pads
in
the
network
to
improve
their
improve
their.
U
Latency,
or
or
or
select,
specific
bandwidth
to
reach
an
endpoint
garyun,
look
at
the
forwarding
and
control
plane
take
a
look
at
security
items.
This
is
a
bit
of
a
run
through
the
draft,
since
this
is
a
revs,
zero
and
comments,
and
questions
are
welcome
at
the
end.
If
we
have
time,
okay,
the
basic
layout
here
that
we
have
is,
we
have
a
SD
one
overlay
or
over
top
VPN
overlay,
and
we
have
some
sort
of
SP
underlay.
We
defined
a
service
provider
controller,
which
is
that
we've
labeled
an
SR
controller.
U
U
Okay,
so
typically,
typically
SD
win
solution
at
our
edge
nodes
or
ingress
edge
nodes,
we're
gonna,
classify
some
traffic,
determine
an
egress
edge
edge,
node
encrypt
it
send
it
off
and
it'll
get
best
paths
or
shortest
path,
forwarding
over
the
underlay
to
the
egress
edge
node.
In
this
case,
from
c1
to
c2.
We
take
the
shortest
path
and
then
at
the
edge
of
the
egress
node,
we
typically
do
capsulate,
decrypt
and
forward
on
to
our
endpoint.
In
this
case,
we
got
a
pointer,
no
I
don't
have
a
pointer
anyway.
U
In
this
case
it
would
be
Z
as
a
n,
don't
what
we've?
What
we've
added
to
this
is
the
ability
for
these
SD
one
edge
nodes,
push
and
binding
cid
and
when
they
push
that
binding
cid
they'd
be
sending
their
daily
traffic
over
a
secure
connection,
their
secure
transport
to
their
egress
notes,
as
well
as
their
monitoring
and
active
monitoring
traffic
as
well.
They
can
measure
latency
or
traffic
loss
over
these
over
these
transports.
U
U
So
the
binding
said
at
c1
then
gets
associated
with
some
SL,
a
2
2,
a
2
C
2,
which
is
the
node
closest
to
the
egress
node
from
the
from
the
SD
one
edge,
node,
ok
and
C
2.
Does
it?
Does
the
normal
SR
forwarding
where
it
would
remove
a
necessary
dress
or
every
six
forwarding
in
the
draft
where
moves
in
sr
h
before
forwards
to
e
2?
U
Response
sort
of
thing,
but
suffice
to
say
the
stuff
on
the
left
is
SD,
win
or
or
solution
private
stuff,
the
stuff
on
the
right
we
can
define
with
pset,
be
GPL
ste
stuff
in
the
middle,
where
we
have
that
service
request
from
the
provider.
That's
new
snoo
new
control
plane
work
that
we're
going
to
be
expanding
on
in
future
versions
of
this
draft
and
from
the
security
side.
U
The
spring
s.
Our
v6
network
programming
guide,
defines
couple
of
security
statements.
Sec
1
insect
to
that
limit.
The
ability
for
edge,
node,
C
nodes
to
be
able
to
utilize,
binding
SIDS
or
send
traffic
to
any
other
SID
within
the
source.
Spider
network
we'd
extend
that
to
include
a
whole
so
that
specific
edge
nodes
that
have
been
allocated
or
allowed
to
use
a
binding
set
are
able
to
access
that
binding
SID.
U
U
So,
in
this
draft
we've
we've
we've
started
out
with
a
fairly
simple
view
of
how
SR
v6
can
be
used
to
provide
SLA
paths
for
over-the-top
VPNs
and
SDM,
with
directly
connected
sieepiess.
We're
gonna,
look
at
the
remotely
connected
Pease,
multiple
providers
using
MPLS
cores
and
using
an
MPLS
PE
to
seee
link
in
subsequent
versions
and
we're
welcoming
any
collaboration,
discussion,
questions
on
the
list
or
here
at
Mike,
ok,.
U
U
So
that
would
be
better
be
up
to
the
the
edge
node,
the
seee
note,
in
order
to
determine
how
they,
how
it
would,
how
would
implement
that
detection?
It's
not
the
service
writer
that
that
does
that,
so
that
the
edge
nodes
can
can
run
their
own
measurements
across
the
SLA
path
and
the
service
writer
itself
separately
can
inject
traffic
across
that
across
the
same
policy
and
do
its
own
measurements
for
that
same
path.
Ok,.