►
From YouTube: IETF102-SPRING-20180716-1330
Description
SPRING meeting session at IETF102
2018/07/16 1330
https://datatracker.ietf.org/meeting/102/proceedings/
A
A
A
Thank
you
to
our
grabbers
great,
so
the
first
thing
you
want
to
kind
of
to
cover
is
a
quick
update
on
the
the
Charter
we
discussed
it
on
the
list.
We've
discussed
it
at
the
last
meeting
and
the
number
of
meetings
before
that
we
called
rough
consensus
around
the
text
that
we
posted
on
the
list.
With
the
the
updates
that
we've
made,
you
can
see
it
at
the
the
URL
there.
A
It's
currently
an
IAS
to
review,
where
we
deliberately
aim
to
focus
that
on
things
that
were
making
spring
technology
deployable,
I
think
we've
got
a
bunch
of
the
old
documents
around
that
we've
worked
on
for
some
time,
where
there's
some
operational
considerations
that
we
need
to
make
sure
that
we
that
we
cover
and
and
cover
some
of
the
gaps
before
moving
on
to
other
things.
So
there's
been
the
aim
of
the
Charter
to
break
down
into
those
we
have
as
a
working
group,
a
bunch
of
things
that
are
ongoing.
A
We
still
have
documents
that
are
somewhat
dated
that
need
to
get
through
through
the
the
standardization
process.
So,
for
example,
the
SR
MPLS
document
still
has
some
some
knits
that
need
to
be
to
be
dealt
with.
We
have
a
number
of
considerations
around
SR
v6,
there's
still
a
significant
number
of
Kentucky
concerns
be
around
it,
for
example,
and
one
of
the
blocks
that
was
raised
against
the
Charter
was
actually
on
this
subject.
So
I
think
this
is
some
area
that
we
need
to.
A
We
need
to
have
some
focus
on
in
the
group,
and
then
we
have
other
supporting
technologies,
so
some
of
which
we'll
talk
about
today.
There
om
mechanisms
for
for
SR
in
general,
and
then
young
models
supporting
the
kind
of
protocol,
independent
parts
of
the
parts
of
the
configuration
and
telemetry
for
sr3
considerations
that,
like
folks,
that
are
working
on
drafts
to
to
look
at
we.
We
have
an
interesting
balance
in
spring
between
documenting
use
cases
and
in
kind
of
functional
specs,
given
that
we've
got
so
many
kind
of
parallels
with
other
working
groups.
A
A
A
So
we
have
some
other
notes
on
the
agenda.
You
will
have
seen
from
the
the
males
on
list
and
there's
a
number
off
list
that
we
always
end
up
with
a
very
packed
agenda.
I
think
we'd
like
to
start
setting
some
some
expectations
as
to
like
what
gets
onto
the
gently
agenda,
and
so
we
make
the
best
use
of
the
fact
everyone's
saying
in
the
same
place,
we've
we've
had
a
few
drafts
which
you've
had
discussion
on
the
list,
but
we
we
continue
to
get.
A
You
know
kind
of
place
all
the
drafts
or
drafts
that
don't
have
any
any
discussion
on
the
list
then
submit
for
an
agenda
slot.
Please
try
and
make
send
a
mail
to
the
list.
Have
it
more
than
his
des
forwarded
draft
submission
announcement.
It
would
be
good
to
highlight
what
decisions
and
discussion
points
there
need
to
be
a
further
draft
and
I
think
we'll
try
and
bias
towards
things
getting
onto
the
agenda.
A
Agenda
and
slots
for
ITF
103,
so
that's
going
to
mean
that
we
also
continue
to
have
this
problem.
So
the
the
discussion
that
we're
trying
to
air
bias
towards
in
the
agenda
today
and
I
think
going
forward
like
figure
out
some
of
these
discussions
on
the
near
term,
milestones,
make
sure
they're
concluded
and
then
to
start
to
socialize
new
work.
There
has
overlaps
with
with
other
working
groups.
So
it's
been
raised
on
the
list.
A
So
here
is
our
agenda
for
today.
Just
as
a
point
about
you,
the
packed
agenda
means
you'll
often
get
like
a
slot.
That's
almost
too
short
to
deal
to
present
in
so
I.
Think.
If
folks,
who
are
submitting
drafts,
it's
really
useful
not
to
have
had
the
discussion
on
the
list
such
that
we
don't
have
to
use
the
time
slot
to
go
through
to
go
through
existing
existing
material.
A
And
then
there's
a
couple
of
things
that
we
couldn't
find
time
for
on
the
agenda.
There's
these
two
drafts
in
particular,
there's
an
SR
mps,
multicast
framework
draft
and
that's
going
to
be
presented
in
PIM
and
then
is
a
update
for
the
bgp
signal,
desu,
our
policy
for
both
the
being
and
the
young
model
that
are
there
going
to
be
an
idea.
Yes,
Jeff,
okay,
so
that
was
Jeff
concerned
so
that
the
multicast
traffic
is
also
being
presented
in
RTG
gg.
D
So,
in
terms
of
progress
of
document,
we
have
the
architecture
document
which
is
in
RFC,
editor
state
and
most
specifically,
I
was
48,
so
we
have
all
autos
final.
We
waiting
for
the
final
go
from
GED
for
algae
pintura.
It's
currently
now
ESG
evaluation,
and
there
was
one
blocking
comment
is
being
resolved.
So
what
is
a
new
graph
should
be
published
this
week
in
term
of
MSD?
See
it's
also
in
is
G
evaluation.
D
There
are
comments,
a
blocking
comment
regarding
the
interaction
between
network
and
TCP,
who
would
like
the
others
to
to
to
to
react
faster,
but
as
of
today,
I
think
the
ball
is
in
the
is
G
reeling,
the
MPs
working
document.
So
it's
under
working
of
last
column,
where
a
number
of
comments
us
thank
you
for
all
the
people
we
met
commands.
D
F
F
So,
what's
defined
mainly
in
this
model,
we
have
the
second
route
in
global
block
the
sRGB.
So
it's
about
global
configuration,
this
one
I
want
to
stress
this.
One
is
the
base
model
for
segment
routing.
We
do
have
the
protocol
dependent
model,
the
OSPF,
signaling
and
ISS
said
Marilyn
that
defines
the
purple
part
in
those
two
several
models.
So
this
one
defines
other
protocol
independent
parameters,
srgb
and
we
have
the
vertical
srgb
configuration.
Does
that
as
a
feature?
So,
if
you
support
you
have
a
very
specific
just
say,
you
have
iodized
use
a
specific
clock.
F
F
C
F
We
also
have
some
notifications,
that's
supported
in
this
model,
so
one
thing
to
notice
is
we
have
the
transfer
type
defined
in
this
model
from
the
very
beginning
cuz.
We
have
e.
This
model
mainly
defines
the
MPs
it
applying.
So
how
the
ipv6
transport
define
in
this
one
I
say:
identity,
I
know
the
I.
Sorry,
six
model
is
defined
in
a
separate
draft,
so
I
think
we
either
use
this
one
as
the
base
one
it's
the
base
model
so
I
serve
a
six
and
two
icer
v6
model
can
augment
this
model.
F
So
considering
this
model
here,
IC
is
already
completed
and
there
has
been
stable
with
like
two
on.
If
you
have
some
con
lines,
they
see
the
opportunity
to
say
it,
and
then
we
like
to
start
the
yellow
to
reveal
and
after
because
all
the
segments
out
in
imperative
in
Java
in
either
in
last
in
the
final
stage,
all
in
pretty
much
close
to
Alaska.
So
and
then
we
were
last
call
this
data
model.
D
F
D
F
If
you
look
at
a
draft,
it
actually
consists
two
models.
One
is
defined
in
just
the
basic
types,
so
other
modules
can
you
can
impart
and
then
the
other
is
just
the
specific.
They
said
Marat
in
configuration
Parker's,
the
PCE
physical.
Those
particles
also
use
the
base
basic
part.
So
if
you
have
a
name,
if
you
look
at
something
you
have
different
requirements,
I
guess
not
yeah.
H
Justin
so
those
number
of
sorry
young
models
that
don't
reference
this
work-
and
this
is
just
incorrect.
The
initial
idea
was
to
have
the
base
types
here
and
then
reference
them
from
other
drops,
and
you
see
number
of
models
and
crazy
and
there's
no
really
here
in
between.
Please
take
a
look
and
reference
to
have
proper
structure
in
place.
You.
F
Have
if
you're
defining
a
data
model
in
routing
area,
we
have
the
resulting
type
first
now,
why
that's
already
an
RFC
that
defines
a
lot
of
basics
types
like
a
router,
IP
vector
that
you
can
reference,
and
this
one
also
has
a
separate
module.
Four
basic
configure
are
the
groupings,
so
you
can
use
for
second
or
out
in
configuration.
So
if
you
are
defining
anything
or
augmenting
anything
inside
morality,
you
can
reference
this
model.
D
I
Hi
kitten,
drought,
Kate
ontological
from
Cisco,
and
doing
an
update
on
SR
policy
drafts,
we'll
start
with
the
segment
routing
policy
which
was
adopted
by
the
working
group.
So
the
key
update
was
this:
the
adoption
call
was
started
after
the
last
IETF
and
poster
call
version.
5
of
the
document
was
adopted.
There
were
several
comments
and
inputs
received
during
the
IETF
and
also
during
the
working
group,
an
option
call.
The
major
change
was
that
this
document
was
reorganized
and
the
folk
the
focus
was
to
progress.
I
The
core
SR
policy
framework
and
other
topics
were
moved
to
separate
documents
and
we'll
look
at
what
those
things.
Besides
this,
there
are
also
minor
changes
to
clarify
some
detail,
correct
and
improve
the
text
based
on
the
comments
and
feedback.
So
this
is
an
overview
of
how
the
original
document
has
been
reorganized.
So
we
have
the
draft
idea
of
segment
routing
policy.
This
remains
and
covers
the
core
SR
policy
architecture.
I
There
is
this
draft
SR
policy
consideration
which
now
has
text
mainly
from
the
appendix
section
and
plus
a
few
other
texts
from
the
word
from
the
0-5
version.
What
discovers
is
really
the
some
of
the
employee
implementation
and
deployment
aspects
related
to
SR
policy?
We'll
talk
about
it
in
the
next
presentation
and
the
third
part,
which
was
all
the
traffic
counters,
SR
counters
related
content,
which
was
16
a
section
13
in
the
0-5
version.
That's
been
put
in
this
other
draft,
which
would
also
be
covered
later
today,
so
this
draft.
That's
our
policy.
Architecture.
I
There
is
a
list
of
segment
types
that
can
be
used
in
the
policy.
This
is
the
currently
defined
segment
types.
It
also
talks
about
validation
of
candidate
paths
and
selection,
tiebreaking
to
select
the
best
or
the
active
candidate
path,
the
binding
said
concept
and
its
usage,
and
there
are
different
modes
in
which
it
can
be
used.
There
also
discussed
and
covered
in
this
document.
I
The
other
key
piece
is
that
the
steering
mechanisms
into
and
SR
policy
there
are
three
or
four
different
ways
in
which
this
could
be
done,
and
all
of
that
are
covered
in
this.
So
do
there
are
those
sections
remain
in
this
document
there
was
some
text
related
to
protection
and
PIL
FA
that
has
been
improved
and
some
more
concepts
added
there
just
to
cover
the
in
the
architecture.
I
I
J
I'm
Anderson
from
Nokia
the
latest
draft
reference
is
about
using
PC
initiated
to
deploy
a
circuit
policy,
but
I
haven't
seen
any
drafts
or
extensions
for
pieces
up
to
do
this.
So
is
there
any
talking
about
how
we're
gonna
map
an
SRT
policy
with
color
and
multiple
candidates
said
lists
to
the
P
set
messaging?
Yes,
I.
I
Believe
there
is
some
work
going
on
on
that,
but
you're
right,
it's
not
yet
been
posted,
but
it's
expected
to
be
posted
soon.
Right
now
the
coverage
I
think
it's
covered
in
the
BGP
SRT
context,
but
a
piece
of
part
is,
you
know
you
have
to
be
added.
I,
think
yeah,
maybe
through,
has
better
throw
from
Huawei.
So
we
have
a
one
document
which
talks
about.
How
do
we
associate
various
s
our
thoughts
into
anis,
our
policy?
I
G
I
G
G
I
I
K
I
Hi,
so
this
is
the
as
our
policy
considerations,
which
covers
the
texture,
which
was
previously
there
in
the
appendix
section.
So
the
draft
ITF
spring
segment,
routing
0/0
version-
was
posted
identical
to
the
0-5
which
was
adopted
by
the
working
group.
So
this
is
really
the
appendix
section
14
from
that
document.
This
is
an
informational
draft.
I
The
contents
here
and
there
have
been
minor
changes
to
clarify
and
improve
the
text
based
on
the
feedback
and
comments.
So
what's
really
covered
in
this
document
is
there
is
a
SR
policy
head
end
reference
architecture?
This
identifies
really
various
components
and
their
interaction.
So
we
have
this
SR
policy
module,
which
learns
as
our
policy
candidate
paths
from
various
signaling
protocols.
I
We
have
BGP
SRT,
we
have
P
SEP
local
configuration
all
of
these,
and
then
there
is
the
SR
policy
database
that
is
built
up
from
signaling
protocols
like
a
GPU,
BGP
LS,
so
the
the
interworking
or
information
flow
or
how
what
parts
of
functionality
is
implemented
or
may
be
implemented
in
one
area
component
or
the
other
is
what's
really
clarified
or
covered.
In
this
document
it
describes.
There's
our
policy
dynamic
path,
computation.
I
This
is
really
highlighting
some
key
aspects
of
the
computation
so
that
we
leverage
the
segment
routing
concepts
like
you
know,
taking
care
of
ensuring
maximum
ecmp.
You
know
taking
care
of,
said
lists
or
set
constraints
in
the
computation,
and
there
are
various
optimization
objectives
and
constraints
that
are
talked
about.
I
This
is
again
mainly
information
on
things,
then
the
SR
policy
architecture
draft
talks
about
the
candidate
path
and
tiebreaker
rules,
but
this
document
really
has
the
examples
which
you
indicate
how
Hadden
would
choose,
based
on
different
paths,
with
different
attributes
coming
from
different
protocol
sources.
So
those
examples
are
covered
here
so
that
it's
a
better
reference
for
implementation.
I
The
document
also
talks
about
the
distributed
and
centralized
control
plane,
and
you
know
the
use
cases
which
need
centralized
computation,
some
use
cases
which
can
be
done
entirely
in
a
distributed
manner
and
others
where
a
mix
of
both
can
be
used.
There
are
certain
aspects
of
binding
sets
and
use
cases
which
are
also
described
here.
I
I
mean
how
binding
sites
could
be
discovered,
how
bindings
it
from
srl
B
can
be
used
for
SR
policies
where
you
need
some
sort
of
a
persistency
or
like
a
well
known,
binding
set,
and
then
there
are
a
few
other
as
use
cases
that
are
covered
like,
for
example,
that
is
flex
algo.
There
is
some
information
about
how
optical
or
any
general
layer
to
interface
could
be
modeled
as
a
segment.
I
I
So
the
content
is
already
familiar
because
all
of
it
was
part
of
the
original
0
5
version
of
the
draft,
which
was
adopted
by
the
working
group.
It's
fairly
mature.
In
that
sense,
that's
been
stable
for
some
time,
but
based
on
updates
and
comments
feedback,
it's
you
know
being
updated
so
at
this
point
would
like
to
request
for
working
group
adoption
for
this
draft
open
its
since
it's
already
the
contents
have
been
already
through
the
previous
last
call.
It
should
be,
and
yeah
expect
new
comments
updates.
A
please
share
with
us.
A
I
have
some
comments,
I
think
there's
a
few
challenges
we're
getting
this
drafted
adopted
and
particularly
because,
if
you
look
at
a
bunch
of
its
kind
of
local
to
node
implementation
detail,
so
you
know
how
you
should
split
functionality
across
different
software
modules,
not
all
of
which
exist
in
all.
Implementations
is
kind
of
an
interesting
question
as
to
whether
we
we
should
include
that
in
a
draft
in
the
working
group,
the
others
have
considerations
you'll
go
when
we
did
the
policy
draft
adoption.
A
There
was
some
discussion
with
tease
about
what
what
constitutes
traffic
engineering
and
what
constitutes
traffic
steering,
and
so
there
was
a
deliberate
split
there
right
to
be
able
to
try
and
have
the
SRT
work
because
kind
of
exists
as
a
steering
mechanism
and
not
the
path
computation
part.
Given
that
this
document
talks
a
bunch
about
path,
computation,
I
think
it
needs
to
have
some
collaboration
with
T's
and
we
need
to
discuss
exactly
how
that
fits
together.
So
I
think
we
probably
need
to
go
through
those
discussions
before
we
can
kick
off
an
adoption
call
sure.
I
So,
on
the
on
the
on
the
hair
and
architecture,
yeah,
it's
a
reference,
it
does
not
exactly
need
to
be
done.
That
really
improvement,
but
it's
more
of
a
conceptual.
The
example
that
I
gave
is,
for
example,
s
our
policies
received
on
a
node
by
a
BGP,
then
certain
clarity
or
information
about
what
part
constitutes
the
BGP
processing
and,
what's,
let's
say,
the
s,
our
policy
processing
that
clarity.
I
A
Not
saying
that
the
content
is
not
useful,
I
think
it's
just
the
way
it's
written
right
now.
It's
of
the
block
diagrams
you've
got
a
very
specific
to
that.
Where
words
I
think
you
could
call
out
look.
This
is
this
functionality
that
you
have
there's
this
other
set
functionality:
here's
how
they
interact
his,
what
here's,
what
BGP
will
do
for
you
anyway?
Here's
what
what
will
be
done,
I
think
there's
some
there's.
I
A
But
sure
maybe
I
would
say
that
it's
it's
quite
a
gray
area
as
to
whether
what
it
covers
is
even
really
a
cell
specific.
There
are
some
s
are
specific
things
in
there.
In
terms
of
you
know,
this
is
how
you
might
you
might
go
from
the
set
set
paths,
but
if
you
start
talking
about
here's
how
to
compute
a
path
that
has
Lincoln
like
missus
link
affinity,
then
the
overlap
with
well,
we
didn't
ever
write
a
similar
doc
ferrand
for
CSP
f4
for
rsvp-te.
A
M
M
So
so
the
basic
intentions
of
this
draft
were
I
felt.
There
was
a
lot
of
confusion
between
the
work
that
we've
been
doing
in
the
SFC
working
group
for
service
chaining,
and
some
proposals
that
have
been
put
forward
for
segment
routing
to
do.
Service,
chaining
and
I
heard
a
lot
of
talk
about
well
they're
competing
technologies,
but
the
reality
is
they're,
really
not
they're
complementary.
M
So
there's
two
scenarios
described
in
the
draft.
The
first
one
is
where
the
nsh
encapsulation
just
basically
uses
segment
routing
as
a
transport.
So,
if
you're
not
familiar
with
what
we've
done
in
SFC,
the
the
encapsulation
was
built
specifically
so
that
it
could
work
with
any
transport.
So
we
didn't
care
whether
it
was
VX,
LAN
or
GRE
or
MPLS,
or
any
of
the
different
transports
we
wanted.
M
It
to
be
independent
of
that
and
this
scenario
maintains
that
by
allowing
NSH
to
be
carried
underneath
segment,
routing,
whether
it
be
SR,
MPLS
or
SR
v6,
the
second
scenario
shows
how
you
could
actually
integrate
the
two
things
so
segment
routing.
We
build
a
segment
list
with
services
as
part
of
the
segment
list
and
then
nsh
is
simply
used
as
a
mechanism
to
identify
which
segment
stacks
should
be
pushed
back
onto
the
packet
when
it
comes
back
from
the
services.
M
So
this
allows
us
to
remove
all
of
the
VLANs
and
other
types
of
mekinese
that
you
would
need
between
the
forwarder
and
the
service
function
and
just
use
the
NS
H
as
a
as
a
way
to
identify
which
which
context
we're
in
and
therefore
push
on
the
right
segment
stay
there
next
slide,
please.
So
this
is
a
just
a
very
quick
picture.
We
described
this
in
the
draft.
M
M
That
we,
what
we've
tried
to
do
with
each
application
scenario
in
the
draft,
is
show
the
stated
benefits
I'm
not
going
to
read
through
all
of
these.
You
can
read
them
for
yourselves
and
they're
in
the
draft,
but
we've
tried
to
give
some
some
advantages
of
using
this
mechanism
next,
like
least,
this
basically
is
a
picture
that
shows
the
integration,
which
is
the
second
application
scenario.
M
So,
as
you
can
see,
once
again,
the
NS
H
is
carried
under
the
segment
stack,
but
we
use
the
NS
h
path,
identifier
to
push
on
the
necessary
segment
routing
stack
when
we
come
back
from
the
services
next
slide.
Please
again
stated
benefits
are
in
the
draft
I'm
not
going
to
go
through.
All
of
these
I've
listed
them
here
happy
to
take
questions
on
any
of
them
next
slide.
We
also
show
the
encapsulation
date
details
both
SR
MPLS
and
SR.
M
So,
in
conclusion,
basically,
the
nsh
based
service
chain
in
and
segment
route
in
a
complementary
technologies.
That's
the
main
point
that
I
wanted
to
get
across
with
this
with
this
draft,
although
we
can
do
service
chaining
purely
with
segment
routing.
There
are
a
lot
of
issues
doing
it
with
SR
MPLS,
mainly
around
metadata
capabilities
and
so
forth,
but
there
are
also
arguably
issues
around
doing
it
with
SR
v6
as
well,
which
happy
to
have
a
conversation
on
those
I.
M
The
the
NS
H
gives
us
the
transport
independence
and
the
SR
gives
us
a
really
efficient
way
of
steering
the
traffic
through
the
intermediate
nodes
that
without
us
having
to
carry
the
per
flow
state.
So,
by
combining
these
two
technologies,
hopefully
we
can
get
that
transport,
independent
SOC
solution
and
it's
it's
a
solution
that
we
think
takes
advantage
of
the
merits
of
both
technologies.
So
last
slide,
please
so
next
steps.
Obviously
we
want
to
request
feedback
from
both
the
spring
and
the
SFC
working
groups.
I
did
talk
to
Joel
my
co-chair
and
SFC.
M
We
need
to
talk
to
the
spring
working
group
chairs.
We
personally
feel
that
it
it's
appropriate
if
the
working
group
wants
to
do
it
to
adopt
this
work
into
the
spring
working
group.
But
again
that
all
depends
on
an
adoption
call
from
from
the
working
group
and
whether
they
want
to
see
this
so
any
questions
they.
N
N
You
can
embed
the
message
kind
of
information
in
a
segment
building,
but
that
defies
the
purpose
why
we
separated
services
for
transport
and
all
the
stuff
we've
been
doing
over
the
last
three
four
years,
as
as
an
industry
was
to
provide
a
way
to
actually
consume
networks
and
the
more
you
put
service
knowledge
into
the
transport.
The
the
more
barriers
you
create,
so
I
would
strongly
ask
people
not
to
to
think
twice
before
pushing
for
this
kind
of
embedding
of
services
into
user
data
plate.
So
I
agree
that
a
lot
of
conclusions.
G
M
O
So
I'm
going
to
present
an
update
on
the
SR
service
training
while
we
completely
integrate
the
service
but
segments
working
and
the
first
thing
that
we
changed
since
the
last
presentation
that
I
have
101
wines
that
we
renamed
the
draft
into
service
programming
with
segment
rating,
and
the
reason
is
that
my
segment
routine
enables
to
do
more
of
interest.
Sprinting
our
training
services.
You
can
actually
program
them.
You
can
using
a
service
6
for
example,
and
sit
arguments.
O
O
One
of
them
is
for
personal,
treating
our
services
and
we
we're
starting
to
get
some
some
services
with
segment
rating
native
support.
We
added
to
it
in
in
the
draft,
and
also
as
I,
was
mentioning
at
the
beginning
of
the
presentation,
a
few
notes
on
the
advanced
network
programming
capabilities
that
segment
routing
provides.
O
O
D
O
O
C
O
O
D
D
O
O
O
B
So
I
appreciate
your
stating
explicitly.
You
were
ignoring
RFC
76065,
but
the
whole
point
was
to
avoid
a
massive
interoperability
problem.
Where,
let's
say
we
have
a
segment,
we
have
SFC
over
segment,
routing
v6.
We
have
SFC
over
MPLS,
we
have
SFC
over
Ethernet,
we
have
SFC
over
rate
IP.
We
don't
want
an
N
squared
problem.
N
sh
gives
us
an
order.
N
problem.
You
have
to
map
to
a
transport
understood.
We
got
a
map
to
transports,
we're
not
reinventing
those.
B
What
you've
done
is
create
a
not
just
a
transport
but
a
complete
representation
which
maintenance
were
into
a
full
mapping
between
every
representation.
If
we
followed
this
pattern,
segment
routing
for
v6
isn't
so
special
that
we
should
create
a
new
pattern
for
how
we
think
about
interoperability,
just
for
that
seems
like
you're,
leading
us
down
a
path
that
makes
our
tasks
a
lot
harder.
O
O
B
M
M
Had
a
comment
on
the
T
of
ease
and
it's
another
y
coming,
and
that
is
why
do
we
have
to
go
and
redefine
a
whole
bunch
of
tail
V's
that
we've
already
done
it's
almost
like
and
it's
frustrating,
because
it's
almost
like
we're
trying
to
make
segments
routing
into
the
hammer
it
can
fix
everything.
It
can
do
everything
and
damn
it
if
it's
not
with
a
segment
route
in
hammer,
we're
not
doing
and
we
want
it.
We
have
to
reinvent
everything
and
and
that's
what's
frustrating
it's
like.
M
O
O
O
M
Q
So
if
you
go
with
the
approach
that
way,
we
are
afraid
to
touch
anything
new
that
we
will
not
do
ever
anything.
So
here
we
have
case
where
you
have
multiple
layers
of
doing
things
and
each
layer
is
doing
over
and
over
the
same
thing
like
say
with
the
states
in
the
network.
So
what
what
is
being
told
here
is
that
the
SR
v6,
you
can
do
not
only
service
chaining,
but
you
can
do
service
programming
through
this.
It's
it's
it
is.
Q
N
But
yeah,
let's
seriously
it's
craziness,
please
please
don't
make
statements.
You
need
more
state.
You
need
more
state
in
the
network
if
you
need
more
state
in
the
network,
you're
doing
the
wrong
things
in
the
wrong
places
again
network
is
there
to
forward
and
SH
is
there
to
do
services?
If
you
do
it
properly,
then
then,
that's
simply
not
true
what
you
said
and
again
just
because
we
can
do
something
simpler
for
a
particular,
simpler
use
case.
N
Just
because
we
can,
it
does
not
mean
we
should
because
then
we're
gonna
have
a
simpler
case
here,
simpler
case
here,
and
somebody
at
the
end
will
come
to
me
and
say:
please
implement
this.
Please
implement
this.
Please
implement
this
and
from
three
simpler
cases,
I
have
a
shell
to
to
support,
and
and
five
years
later
you
need
a
PhD
to
manage
a
network
or
no
operator
is
willing
to
touch
anything,
because
it's
so
complex
that
that
you
need
a
PhD
to
introduce
any
technology.
N
O
O
Q
O
D
R
Good
afternoon,
this
is
public
America
from
Cisco
today,
I'm
here
to
talk
about
a
draft
industry,
this
hobby,
six
network,
programming
or
vision
5.
So,
as
you
might
already
know,
is
Harvey.
Six
network
programming
is,
in
a
sense,
the
capability
of
create
a
distributed
program
in
the
network
as
a
set
of
individual
functions
through
this
hobby.
Six
domain
of
this
document,
what
is
doing
is
describing
the
concept
itself
and
some
of
the
most
basic
functions
that
are
used
across
a
set
of
shared
use
cases.
R
So
if
we
look
at
the
content
of
the
draft
itself,
what
we
are
defining
is
a
new
set
of
SRB
six
functions,
so
these
are
the
ones
listed
on
the
left-hand
side
and
we're.
In
essence,
you
have
some
from
the
most
basic
function,
which
is
the
end
point
or
the
end
point,
with
layer,
3
corresponding
to
more
functions
like
the
decapsulation,
with
hyper-v
6
for
sonic,
so
that
the
X
6
or
the
explore
and
come
with
the
capsulation
ipv6
right
before
table
lookup
and
so
on.
R
Then
the
draft
is
also
defining
a
set
of
basic
intro
to
main
basic
security
ACLs,
as
the
inter
domain
would
be
part
of
a
separate
raft,
and
we
are
also
defining
a
set
of
basic
counters
for
these
as
hobby'
6
behaviors.
The
drug
is
also
giving
a
set
of
use
cases.
These
cases
are
all
of
them,
leveraging
the
functions
that
I
explained
in
the
previous
slide.
R
These
use
cases
for
our
basic
security
layer,
3,
VPN
layer,
2
VPN,
this
RT
for
under
the
SLA
or
there
are
an
ingress,
be
or
a
midpoint
into
an
SRT
policy,
tlf,
a
or
SRT
for
service
programming
notice
that
the
draft
is
not
describing
fully
how
we
create
each
one
of
these
use
cases.
So,
for
example,
if
I
go
into
TLT,
what
these
draft
is
describing
is
how
to
leverage
the
functions
that
we
create,
that
we
have
defined
in
this
raft
duty
LFA,
but
of
course,
a
TFA
mechanisms
are
described
in
a
separate
wrap
them.
R
So
if
we
look
at
the
ID
history,
we
published
this
drafting
March
2017,
where
we
presented
it
we
presented
well,
we
included
the
main
draft,
some
of
the
most
basic
functions
and
illustrations.
This
was
presented
in
90th
1998
in
Chicago
in
March
last
year,
in
June
2017,
we
publish
our
vision,
one
that
was
just
a
minor
update
with
some
draft
clarifications.
We
also
included
a
formal
definition
of
the
counters
which
before
were
described
in
an
abstract
manner,
and
now
we
are
now
they
are
defined
as
a
counter
one
Condor
203,
so
they
are
concrete.
R
In
October
2017
we
publish
the
revision,
which
is
including
the
evpn
function,
so
n
DX
to
be
DT
und
T
to
M
and
the
related
illustrations.
We
also
added
a
new
function,
so
the
endpoint,
with
the
capsulation
and
ipv4
ipv6
table
lookup,
and
also
we
move
the
service
programming
related
functions
into
the
dropship
lat
tract.
R
We
did
this
with
objective
to
leave
this
table
with
only
the
basic
functions
that
are
required
that
are
required
in
in
the
most
common
use
cases
in
December
2017,
we
publish
the
revision
where
we
added
the
OEM,
so
we
describe
how
the
SRA
chobits
processing
is
done,
the
end
at
OTP
and
function
and
the
related
illustrations
in
March
2019.
We
added
support
for
the
reduce
SRH
following
the
the
six-month
sorry
struct.
So
this
involves
the
functions.
R
T
insert,
read:
T
n
cups
read
TN
cups
to
read
on
the
end
v6,
and
we
also
added
the
Ayana
registry
for
the
SR
v6
endpoint
tabs,
with
the
objective
that
all
the
control
plane
drops
can
divert.
The
IANA
allocated
code
points
to
signal
the
support
for
each
one
of
the
functions
right
before
this
ITF
we
publish
the
region
5.
It's
just
containing
some
text
verifications.
R
If
we
look
at
the
technology
state
for
this
truck,
we,
as
you
might
already
know,
we
have
large
community
support.
We
have
multiple
interoperable
implementations,
both
open
source
and
proprietary
on
sitcom
2017.
There
was
an
interrupt
where
there
were
two
different
vendors
and
several
different
open-source
implementations
on
the
ENT
since
report
this
year
there
was
also
an
one
vendor
that
had
already
shown
intro
and
another
different
vendor.
I
know
this
information.
R
Now
some
of
the
related
work
that
is
based
on
this
ID
is,
for
example,
draft
Duke's
is
bringing
a
surfer
as
the
one
trough.
Itf
DMM
is
our
v6
mobile
user
plain
notice
that
the
DMM
draft
is
defining
newest
our
v6
functions,
which
are
specific
to
mobility,
but
since
they
are
specific
to
mobility,
these
functions
are
defining
in
this
ID.
R
Another
graph
is
the
drafts
of
cloud
which
was
previously
presented,
and
then
we
have
the
service
experience
our
v6
OEM,
which
is
also
defining
new
functions
as
a
v6
Young
released
by
sorry,
six
bt
pls,
a
sorry,
six
Isaiah's
as
our
a
six.
So
what
I
would
like
here
is
together
working
group,
input
and
feedback
on
this
work.
So
please.
E
On
Bonica
Juniper
Networks,
several
of
the
sets
that
you
define
in
this
document
take
information
that
is
currently
encoded
an
MPLS
VPN
labels
and
moves
it
into
a
said.
I'd
like
to
see
you
address
two
things
in
the
document.
First,
why
is
that
necessary?
Why
is
it
not
okay,
where
it
is
today?
Second,
why
is
it
a
good
idea
to
know
good
into
the
IP
destination
address,
along
with
routable
information?
Why
not
move
it
into
some
place
where
it's
separate
from
me
a
destination
address
as
it
is
today
so.
E
E
E
B
So
your
presentation
cost
me
to
go
look
again
at
the
draft
and
then
think
about
something
I
saw
which
made
perfect
sense
in
the
segment
routing
header
draft
and
I'm.
Now
confused,
so
I
hope.
I
can
provide
a
clear
question.
This
is
about
the
transit
sets
which
are
in
a
drafting
or
in
your
table
of
said
programming
SIDS.
The
text
says
you're
at
a
node
n.
C
B
Have
a
destination
address
of
B,
which
is
not
a
local
sit
but
you're
going
to
do
some
sort
of
CID
processing
that
is
somehow
related
to
something
and
I'm,
not
sure
what
from
the
text
being
transit
said.
Well,
the
bass
segment
routing
draft
says
explicitly
and
for
obvious
reasons,
for
consistency
with
8200
and
good
practice.
If
it's
not
one
of
your
SIDS,
you
don't
need
to
do
anything
with
it.
So
I
don't
understand
how
these
transit
seeds
work.
B
R
B
I
Hi,
my
name
is
Uma.
Can
you
go
back
to
one
slide?
Please
yeah.
So
the
second
draft
draft
IETF
DMMs
rj6
Mobile,
is
offensive
great
work.
So
how
only
one
comment
on
the
draft-
because
you
put
it
here
because
it's
connected
to
the
programming
I
am
commenting
here
s.
Our
v6
can
be
used
as
an
underlay
for
the
transport
pack,
our
transport
networks,
great
if
it
works,
but
the
only
problem
there
is
in
the
name
of
removing
gtp
tunnel.
The
TE
ID
is
encoded
into
ipv6
address.
What
happens
with
this
is
complete.
I
All
5g
mobility
ring
scenarios
dependent
on
ipv6
underlay.
There
is
huge
networks,
underlays
built
an
MPLS
today.
This
operation
will
help
actually
so
that
under
lists
can
be
independently
deployed.
Mpls
ipv4
ipv6
a
survey
six
anything
except
that
part.
It
is
good
you
how
to
reconstruct
that.
Actually,
so
the
TE
I
did
he
not
been
coded
into
ipv6
sry.
Six
and.
T
C
T
I
T
U
D
U
Great,
so
this
draft
is
talking
about
how
to
provide
node
protection
for
traffic,
engineered
ASR
paths,
I'm,
going
to
first
start
out
with
a
link
protection
example
and
kind
of
walk
through
this
rather
complicated
topology.
But
this
issue
is
actually
sort
of
a
matter
of
details
and
getting
all
the
details
right
so
I
think
it's
worthwhile
to
actually
go
into
the
detailed
topology
examples.
U
So
the
topology
design
on
the
left
there
I
use
a
notation
where
all
of
the
node
SIDS
all
the
notes
that
indexes
can
be
derived
from
the
node
number,
as
can
the
sRGB
s.
So
you
know
these.
These
nodes
have
numbers
two-digit
numbers,
so
the
two-digit
X
Y
value
will
be
the
node
CID
index,
we're
still
on
the
on
the
first
slide.
There.
U
U
A
U
Okay,
yeah,
probably
it's
intending
to
save
the
other
screen
to
show
my
video,
but
I'm
not
streaming
anything
so
that
probably
won't
be
fixable.
Okay.
So,
with
this
scenario,
the
in
this
example
we're
gonna
have
node
70,
sending
a
packet
out
its
interface
72
node
1,
with
the
label
stack
that
particular
label
stack
shown.
I
won't
read
out
the
whole
label
stack,
but
it
corresponds
to
the
node
cid-42,
a
node
said
480,
another
node
said
483
and
a
node
said
490.
U
So
that's
going
to
steer
the
the
traffic
from
70
to
one
to
two
to
three
to
80,
to
83
to
90
and
I've
kind
of
used.
This
notation,
where
the
the
light
blue
nodes
and
arrows
correspond
to
the
arrows,
are
adjacency
Syd's,
the
blue
ones
or
adjacency
Syd's,
and
the
the
blue
node
numbers
are
actual
node
Syd's,
so
that
you
can
tell
sort
of
where
the
the
anchor
points
are
of
this
teehee
path.
U
So
in
this
particular
example,
just
doing
looking
at
the
failure
of
link
1
to
2
without
node
protection,
this
is
just
the
link
protection
case.
We
have
a
normal
for
D
entry
for
the
incoming
label
of
100,000,
so
1
0,
1,
0,
0,
2,
you're,
going
to
pop
the
label
and
send
it
out
the
interface
from
1
2
to
4
the
link,
protecting
backup
path,
you're
gonna
pop
the
label
and
send
it
out
the
interface
1
to
21.
U
With
this
different
label
stack
and
that
label
stack
describes
the
in
this
case
the
T
il.
If
a
backup
path,
you
know
going
out
to
21,
22
23
and
then
at
3
and
30,
and
it
basically
merges
the
backup
path
at
node
2.
Now
this
is
okay.
When
you
just
have
link
protection,
when
you
don't
want
to
apply
the
condition
that
you
can't
go
through
a
potentially
failed
node,
but
so
in
the
next
example,
we'll
show
to
go
to
the
next
slide.
U
So
the
next
slide
that
that
isn't
the
case.
First,
we
can't
go
through
in
the
backup
path
and
we
also
can't
we
have
to
basically
go
farther
in
the
path
to
the
next.
Basically,
the
next
node,
where
labels
have
significance
so
the
next
segment
in
the
path.
So
again,
in
this
example,
70
is
sending
out
the
same
label
stack
which
results
in
the
same
instantiated
path,
but
for
node
protection,
and
we
still
have
the
same.
U
U
We
are
going
to
have
to
interpret
the
label
after
the
node
cid-42
in
the
context
of
the
following
node
or
the
next
segment
in
the
label
stack.
So
in
this
case
we
end
up
using
the
label
value
of
one
two:
four:
zero.
Eight
zero.
In
that
case,
which
is
basically
the
node,
said
480
at
no
24
I,
would
also
point
out
that
this
notation
of
you
know
using
srgb
values
using
a
different
srgb
value
for
every
node
is
not
necessarily
something
you'd
want
to
do
in
a
real
network.
U
You'd
probably
want
to
use
the
same
srgb
value,
but
if
we're
going
to
have
a
general
solution
for
this
problem,
we
in
general
should
take
into
account
the
possibility
of
different
srgb
s,
so
I've
explicitly
put
in
every
node
having
a
different
srgb
just
to
both
highlight
that
point,
and
so
that
we
don't
sort
of
oversimplify
the
problem
and
come
up
with
a.
We
could
explicitly
decide
that
we
don't
want
to
cover
that
case,
but,
at
least
in
general
I
think
we
should
be
covering
that
case,
so
yeah.
U
The
other
path
possibility
here
is
path
B,
which
goes
out
seventy
one
two
three,
but
then
takes
a
right
turn
to
go
to
34
and
then
gets
released
up
through
83
and
ends
up
on
90.
This
path
is
going
to
have
a
different
second
label
in
an
order
for
the
PLR
node
one
to
be
able
to
produce
the
correct
label
stack
for
this.
It's
going
to
have
to
look
at
the
second
label
as
well
any
questions
here
so.
U
U
What
final
slide
yeah
so
so
we'd
like
the
chairs
to
consider
conducting
a
poll
for
working
group
adoption?
What
one
issue
that
has
been
you
have
been
brought
to
our
attention
that
the
tea
is.
A
draft
also
has
some
text
that
describes
a
solution
to
the
same
problem.
It
uses
the
the
solution.
Description
uses
a
second
look
up
based
on
a
sort
of
a
modified
second
label.
The
description
actually
in
our
in
our
draft
uses
context
labels.
U
D
U
Think
it
would
make
more
sense
for
it
to
be
in
spring,
mainly
because
so
the
the
solution-
D
the
actual
backup
path-
we
described-
happened
to
be
TILs,
a
backup
paths,
but
they
could
be
any
form
of
Beca
pads.
They
don't
necessarily
have
to
follow
the
purse
convergence
path.
They
just
need
to
get
back
to
the
the
srte
path,
so
they
can
start
using
the
rest
of
their
labels
properly.
V
V
U
D
D
G
Yeah
so
effect
is
defined,
as
our
effect
is
defined
as
a
prefix,
prefix
length
and
then
protocol,
but
now,
with
flexible
flex,
algorithms,
no
same
prefix
can
be
I,
wrote
I
using
multiple
prefix
EPS.
So
this
information
alone
is
not
sufficient,
FCAT
287
at
that
time
percent
there.
So
we
need
to
extend
8287
to
add
that
support,
so
I
just
use
a
simple
topology
as
an
example.
So
here
we
have,
the
default.
Algorithm
is
supported
by
all
of
every
node
and
then
the
green
nodes
support
algo
128
and
then
the
red
one
support
elbow
129.
G
So
now,
for
example,
if
you
do,
let
us
say,
MPLS
trace
so
starting
from
node
0
for
destination,
node
9,
so
if
it
goes
to
node
1
and
we
want
to
do
it
for
elbow
128,
so
in
this
case
the
node
will
receive
the
prefix,
the
prefix
length
and
the
protocol.
But
that
means
that
it
will
resolve
the
default
protocol,
but
incoming
packet
has
the
label
corresponding
to
lip
I'll
go
128,
so
it
will
falsely
assume
that
there
is
a
mismatch
and
indicate
an
error.
There
could
be
other
cases.
G
G
So
we
should
actually
extend
8027
to
add
that
support
in
solution
is
really
simple.
We
just
have.
We
have
16
bit
reserved
field,
so
we
can
use
the
8
bits
from
that
to
carry
the
algorithm
ID
by
default
for
all
algorithm
unaware
applications.
They
can
use
algo
0.
So
you
don't
really
need
to
worry
about
the
older
implementations
or
now
and
then,
whenever
you
want
to
paying
for
a
particular
flex
algorithm
for
that
case,
so
you
carry
the
algo
ID
in
the
elbow
field.
G
So
yes,
in
this
case,
if
you
see
down
when
the
node
is
doing
validation,
it's
in
addition
to
prefix
its
length
in
protocol.
We
are
also
carrying
the
elbow
ID,
so
we
can
carry
take
corresponding
the
prefix,
a
it's
next
off
and
so
on,
and
we
can
do
the
proper
validation
and
return
success
of
failure.
So
there
is
the
draft
very
simply.
It
is
a
really
simple
drop
yeah.
So
we're
really
trying
to
address
a
gap
that
we
think
this
chart
will
address.
G
W
So
the
two
purposes,
one
is
to
show
that
how
the
second
routing
be
useful
to
help
them
sqn
traffic
second
part
is
really
about
end-to-end
path:
traversing
through
happy
Network,
because
the
reality
is,
we
won't
be
able
to
have
SR
in
day
one.
The
traffic
have
to
go
through
different
part
of
the
segment
of
not
as
our
v6
enabled
Network.
So,
let's
get
it
started.
So
for
s
q1
right,
there's
a
has
been
in
the
market
for
master
five
years.
W
The
classic
s
t1
is
being
like
two
endpoints,
which
are
interconnected
by
like
provider,
network
and
Kos
SR,
on
leased
line
and
being
supplemented
by
a
third
party
path
which
can
be
public
Internet.
So
that's
the
the
classic
s.
T1
looks
really
simple,
but
actually
in
deployment.
There
are
lots
of
lots
of
issues
many
because
the
mesh
interconnection
among
all
the
endpoints-
that's.
Why
is
t1
even
though
has
been
in
the
market
for
many
years,
and
the
deployment
has
been
limited.
W
W
A
z2
application
flow
has
to
go
through,
for
example,
on
c4.
So
with
that,
if
just
traditional
and
current
network-
and
you
have
to
do
a
lots
of
a
provisioning
configuration
to
make
those
flows
symmetrically,
traverse
through
specific
edge
node,
where
the
ingress
or
egress,
when
segment
routing
it
becomes
very
simple,
we
can
put
a
policy
into
the
ingress
node
and
then
the
traffic
for
guaranteed
to
traverse
your
desired
egress.
So
we
find
this
very
useful
and
just
for
emphasize
on
that
for
the
the
path
between
a
1
e
to
the
encryption.
Ipsec.
W
W
W
It.
So
just
reiterate
those
two
points
so
see
this
just
for
illustration
purpose.
For
example,
if
we
use
the
gie
encapsulation
between
the
sd1
endpoint
to
the
ingress
port,
ingress
node
of
the
PE,
and
we
can
use
gie
key
to
indicate
differentiate,
different
kind
of
flow
requirement
and
then
controller
can
inform
the
ingress
note
on
how
to
do
the
proper
mapping.
Then.
W
There
may
be
an
issue
there
for
ecmp,
but
if
the
last
mile
is
only
a
few
hops
away,
and
not
many
actually
actual
paths
between
the
cst-100
to
the
PE
is
not
a
big
point,
a
big
issue,
but
anyway,
when
you
stimulate,
we
want
more
feedback
on
the
mailing
list,
using
this
UDP
source
port.
To
do
the
differentiation.
W
Another
part
is
how
to
represent
the
security.
The
the
problem
is
once
we
have
a
provider
network.
The
PE
has
the
pore
facing
the
Internet,
then
bring
up
lots
of
security
risks
to
the
provider
network.
For
one
thing
we
all
know
there
could
be
DDoS
attack
to
those
P
once
you
have
a
port
facing
the
Internet,
so
that
part
will
require
some
kind
of
entity.
Balance
function
to
be
enabled
to
put
prevent
those
unwanted
traffic.
W
On
second
part,
is
you
could
have
users
malicious
users
to
spoof
the
CPE
source
address,
to
be
able
to
get
the
traffic
traverse
through
your
own
provider
network
and
that
one
come
down
to
kind
of
trade
off
how
much
as
a
provider
are
willing
to
put
into
the
ash,
to
prevent
us,
unwanted
traffic
versus
letting
some
amount
of
traffic
to
traverse?
And
we
are
proposing
that
using
some
kind
of
a
new
protocol
type
to
maybe
using
part
of
the
gie
key
to
basically
represent
those
are
the
legitimate
traffic.
W
W
I'll
finish
quickly,
so,
since
we
only
have
time,
I
will
not
cover
this
much
a
magical
main
case.
So,
though,
for
the
sd1.
Actually,
there
will
be
more
issues,
there's
a
tunnel
between
two
endpoints,
if
especially
when
they
don't
have
secure
channel
between
them
to
manage
the
the
IPSec
key
negotiation
is
quite
a
lot
of
work
and
there
are
lots
of
gaps
like
using
an
H
R
P
dmvpn.
There
are
some
issues
so
we're
going
to
have
another
session
to
discuss
the
gaps
of
today's
available
protocols.
W
Now
being
RT
g
working
group
on
Thursday
hope
people
can
come
to
join
to
discuss
another
one
is
the
for
the
IPSec
Auto
configurations,
because
today
it
takes
lots
of
menu
configuration
to
do
the
IPSec
configuration
and
if
you
want
to
do
a
large-scale
SD
one
network
is
not
scalable.
So
there's
a
draft
working
group
draft
in
the
iTunes
SF
talking
about
Auto,
configure
of
those
IPSec
parameters
and
I
hope
people
who
are
interested
I
will
come
to
you
to
join
the
discussion.
That's
our
ones
day
afternoon.
Thank
you
very
much.
J
S
I'll,
try
to
make
this
really
fast
all
right
this.
This
draft
draft
Duke
spring
srst
when
actually
used
to
be
called
draft.
Dukes
SR,
frosty,
wind
zero
is
presented,
Ieft,
ITF
100.
It
covered
a
lot
of
the
edge
st
when
edge
testing
when
edge
stuff
that
the
Linda's
talk
covered,
as
well
as
the
selection
of
the,
including
the
selection
of
an
SR
policy
through
the
underlay
Linda's.
Just
just
so
we
can,
you
know,
get
this
out.
The
way
Linda's
draft
has
has
gone
down
the
road
of
looking
more
into
the.
S
Srst
win
really
looks
at
the
service-level
agreement
and
providing
a
service
level
agreement
to
an
over-the-top
VPN
with
scale
and
security
for
the
SDM.
In
particular,
it
allows
selection
of
non
Depot
pass
through
a
provider's
network
for
su
n
edge.
Node
C
denotes
the
SC
one
edge
notes,
use
a
binding
said
to
achieve
this.
Every
six.
It's
an
SR,
v6
binding,
said
for
an
ipv6
data
plane
for
an
ipv4
data
plane.
We
specified
the
use
of
an
MPLS
binding,
said
over
UDP.
S
The
question
that
is,
how
does
a
server
spider
provision
that
binding
SID
and
the
answer
to
that
is
on
demand
on
demand
from
an
SDN
controller,
we
would
request
the
binding
sit
from
a
provider
and
we
started
the
protocol
to
request
that
and
in
subsequent
drafts,
we're
gonna
be
looking
at
how
that
protocol
gets
built
out.
There
are
subsequent
versions
of
this
draft
we're
looking
at
how
that
protocol
gets
built
to
make
that
request
between
the
SDN
controller
and
a
service
writer
controller
that
manages
SR
policies
so
service
spider
controller.
S
Then
provisions
these
SR
policies
to
the
closest
Pete.
You
know
to
the
CEO,
that's
that
they're
requested
for
and
instantiates
of,
binding
sid
of
that
SR
policy,
either
an
MP
SR
or
as
our
v6
bindings
it,
and
this
is
close
to
the
end
here.
Currently
we
have
s,
our
v6
bindings
is
defined
and
we
have
MPLS
bindings.
It's
defined,
utilizing
RFC,
75
10
for
ambulance
UDP
encapsulation.
S
We
defined
directly
connected
ce2
PE
and
not
directly
connected
ce2
PE
cases
we'll
be
adding
the
not
directly
connected
c2p
with
sr
v6
in
next
revisions,
as
well
as
the
SDN
controller
to
the
service
provider,
controller
protocol,
extensions
and
exploring
that
area
and
seeing
what
needs
to
be
needs
to
be
done.
So
this
point
we're
asking
for
collaboration.
I
know
Linda
will
be
collaborating,
so
if
other
folks
want
to
want
to
join
us,
please
drop
us
emails
to
the
list
or
individually
and
we
can
move
this
work
forward.
X
D
Q
Q
Q
It
was
for
classic
pinion
or
standard
ping
and
traceroute
in
a
service
network,
and
then
it
could
evolve
when
we
added
a
service,
expand
traceroute
that
imply
Bri,
2018
or
actual
December
2017,
and
we
also
added
cases
for
segment
by
segment
paying
in
overlay.
Traceroute
I
presented
this
work
at
last
ITF
in
London,
and
since
then
there
was
a
last
call
for
the
six
Penn
SRH
for
the
SRS
trough
till
six
men
out
of
that
lost
all
there
were
comments
that
you
hope
it,
which
were
the
one
that
was
defining
SRH
draft
it.
Q
Q
The
draft
actually
have
sort
of
two
major
sections
with
subsections,
so
one
is
defining
the
building
blocks
that
we
need
to
do
any
our
v6
and
in
the
second
part,
is
about
some
use
cases
illustration
on
how
we
used
it
building
log:
it's
not
comprehensive
all
use
cases
if
you
can
build
something
else
as
well,
but
there's
the
basis
so
only
building
blocks.
What
it
defines
is
two
six
one
series
for
one
behavior,
so
it's
called
endo
poopie.
That's
when
a
man
pointed
point
and
one
is
for
onm
endpoint
wait.
Q
B
Q
On
the
illustration
side
of
things,
there
are
multiple
restoration.
Bonus
is
the
classic
thing
which
is
actually
paying
to
a
new
packet
or
ipv6
address
in
a
servicing
network,
and
then
you
have
classic
trace
route
which
is
tracing
a
route
to
ipv6
ipv6
address
in
the
network.
It
builds
on
ICS
actually
fully
used
to
you.
I
CNT
it
doesn't
add
anything.
Anything
is
to
a
C
and
B
and
it
was
seamlessly
with
ipv6
thrown
inside
the
network
it
for
the
SR
basic
side
of
thing.
Q
C
Q
Are
pinging
no
an
ipv6
address
v4,
which
is
on
the
node
on
that
side,
and
then,
if
thing
is
happening
from
b1,
but
is
the
problem
stripping?
Is
that
you
want
to
do
that
being
via
a
cid
list?
So
the
answer
is
very
simple:
the
node
who
wants
to
do
it
can
create
in
a
storage
with
the
Sibley's
recorded
ship,
just
suck
it
out,
and
then
any
node
who
was
known
as
obviously
capable
who
will
have
no
change
in
terms
of
processing.
Q
This
message
is
a
transect
ipv6
ICMP
packet
and
the
node,
whether
included,
in
truth,
the
egress,
and
in
this
case
equals
happened
to
be
the
classic
mode
and
then
to
a
signal
correspond,
so
no
changes
required
at
the
transit
node
or
the
desperation
hood,
but
the
SL
v6
capable
or
who
was
the
source
node
it
wants
to
do
and
take
the
packet
over
trafficking.
You
in
part
can
include
that
information,
yes,
average.
Next
up,
this
traceroute
works
the
same
way
in
the
interest
of
time.
I'll
I'll
just
keep
that
next
slide.
Q
Q
They
gotta
go
in
and
I
think
what
wouldn't
break
so
sit
is
considered
as
generic
here,
so
it
could
be
any
city
and
the
ping
flavors
are
there
it's
end
to
end
things
when
you
think
from
source
to
the
egress
or
is
sector
by
segmenting,
where
each
node
in
the
segment
respond
to
that
thing
message.
So
this
would
be
like
more
like
a
proof
of
transit.
Okay
and
increase
road
could
be
also
hop-by-hop
where
all
nodes
participate
in
send
the
response
to
the
place
should
request,
or
it
could
be
segment
by
segment
we're
only
nude.
Q
There
are
a
segment
in
the
SRH,
all
the
one
that
respond
to
the
traceroute
trace
route,
so
just
like
overlay,
and
then
there
is
a
graph
that
was
part
of
the
chair,
update
that
talks
about
srn
pls.
So
this
draft
is
like
equally
applicable,
so
it
has
a
statement
there
and
same
is
for
in
in
s21
and
that
it's
a
service
is
equally
applies
to
that
cases.
Q
So
painted
function
is
basically
what
we
see
in
session,
but
the
only
thing
is
that
here
for
ping
to
sit
function,
top-40,
pc,
800,
piece,
it's
added
to
a
storage,
and
that
call
is
packet
to
be
very
pointed
and
response
to
go
back
to
the
english
next
slide.
Please,
in
case
of
overlay,
trace
or
segment
by
segment
thing.
We
can
do
the
use
of
the
orbit
to
fools.
The
packet
can
be
processed
by
the
segment
on
the
SR
SR
part,
and
the
respond
only
comes
from
the
segment
and
the
behavior
there
is
forward.
Q
I
Q
Am
and
his
question
is,
if
I
sorry,
six
traceroute
can
be
used
for
proof
of
transit,
then
what
is
the
purpose
of
in
situ
Empire,
so
I
think
the
first
part
is
the
Rafi
itself
does
not
put
restriction.
That
depends
on
the
hardware
capability,
in
terms
of
where
the
time
mister
me
taking
it
going
to
be
up
with
implementation,
but
it's
typically
as
soon
as
possible
on
the
English
pipeline.
This
is
where
it
should
go
and
regarding
the
ro
NM,
it's
different
to
living.
Q
E
Might
it
be
a
good
idea
to
make
this
functionality
available
to
everybody
by
moving
the
obut
out
of
the
SRA
chatter
and
into
a
destination
option
that
precedes
the
SRA?
Cheddar
would
have
the
exact
same
functionality.
It
would
just
be
available
to
other
segment
routing
other
routing
header
types.
So,
first.
Q
Thing
is
that
when
a
new
hardware
is
processing
the
SRH
hope
it
is
they're
inaccessible
and
you
don't
have
to
look
elsewhere
to
get
another
or
an
embed
and
that's
less
complexity
with
hardware.
The
second
thing
is
that
here,
when
anyone
the
node
to
make
a
decision
based
on
the
seat
type,
whether
that
mood
for
that
particular
seat
type
really
want
to
process
that
obit
or
not,
it
is
a
local
decision,
it's
trip
and
with
putting
it
in
another
distribution.
Header
makes
that
complexity
to
thymine.
E
Q
E
Q
D
Q
D
Q
P
P
The
scope
is
informational
in
nature,
so
it
doesn't
define
new
procedures.
So,
as
mentioned,
this
is
a
gal
gas
header
for
their
Sol
links.
The
next
and
SR
policies
we
built
with
the
pls
label
stack
next,
so
these
are
the
basically
the
delay,
measurement
and
loss
measurement
packet
formats
define
in
62,
C
or
D
port.
So
next
in
the
next.
P
So
out
for
outer
band
one-way
delay
in
lost
measurement,
the
7876
defines
the
UDP
return
path.
So
this
is
what
we
would
use
for.
The
signal
routing
as
well.
The
next
and
there
are
already
RFC-
is
defined
for
OSPF,
eius,
eius
and
bgp
alice
is
also
becoming
RFC
for
advertising.
The
PA
link
metrics
next.
P
P
So
this
draft
is
for
defining
the
UDP
path
for
sending
the
queries
presenting
on
behalf
of
the
authors
and
contributors
and
next
next,
so
the
acquirement
is
to
loss
and
delay
performance
measurement,
that's
agnostic
to
the
data
plane
and
we
don't
need
to
boost
our
PM
s--
essence
to
negotiate
UDP
port.
That's
the
spirit
of
SR
is
stateless
on
egress
node
and
when
we
enter
your
measurements
and
handle
ICMP
scenarios
and
the
scope
is
that
we
will
use
the
60
TCR
d4
probe
message
formats,
as
well
as
the
7876
UDP
reply.
P
So
we
are
basically
getting
the
UDP
ports
for
the
delay
and
loss
measurement
and
next
so
as
define.
There
is
one
port
is
for
the
delay
measurement
and
one
port
is
for
the
last
measurement
and
next
so
response
is
set
back
using
the
UDP
information.
That's
received
in
the
in
the
probe,
query
message
and
next,
so
it
does
define
a
return
path,
segment
list
for
the
two-way
measurement
and
next
so
I
the
SR
policy.
P
There
is
a
CMP
so
by
adding
the
IP
header,
IP
UDP
header,
we
can
take
advantage
of
the
a
CMP
functions,
that's
already
there
in
forwarding
next.
So
we
welcome
your
review
comments
and
suggestions.
The
implementations
for
the
building
blocks,
63
74
I
PA
DP
base
pros
for
IP
SLA,
already
exists,
so
we
are
requesting
for
working
group
adoption
for
this
one
as
well
next,
so
you
have
a
question
and
then
I
think
we
have
oh.