►
From YouTube: IETF113-SPRING-20220325-1130
Description
SPRING meeting session at IETF113
2022/03/25 1130
https://datatracker.ietf.org/meeting/113/proceedings/
A
B
B
C
H
H
H
H
H
As
you
see,
all
shares
are
remote
and
thank
you,
tom
hill,
for
helping
with
the
room
management.
H
As
a
remember,
minutes
are
collaborative,
so
you
can
click
on
the
url
on.
Please
check
your
name
and
your
statement
in
terms
of
queue
management.
It's
a
bit
different
this
this
week.
H
So
if
you
are
remote,
you
enter
the
queue
by
pressing
the
res
and
icon,
and
if
you
are
in
vienna,
you
have
to
use
the
mythical
light
client
I
believe
now,
when
speaking,
if
you're
remote,
you
need
to
separately,
send
your
audio
and
if
you're
in
in
the
room,
you
can
use
the
room
microphone
and
finally,
as
a
reminder,
sessions
are
recorded
both
audio
on
video.
H
And
next
please,
so
you
probably
know
by
now
so
now
out
has
finished
and
you
we
have
a
new
isg
as
far
as
rooting
area
is
concerned.
Andrew
is
a
is
the
new
ad
and
martin
is
leaving,
and
this
has
an
impact
for
springer,
because
spring
spring
working
group
has
been
assigned
to
andrew,
so
we'd
like
to
welcome
android
world.
H
We
will
have
a
five-minute
slot
presented,
so
I
won't
say
anything
and
martin
is
leaving
I'd
like
to
thank
martin
very
much
for
the
four
years
of
services.
H
H
In
term
of
document
we
made
some
progress
on
the
compressed
server
six
segment
list
encoding
in
srh,
so
we
were
waiting
for
a
draft
dealing
with
the
relationship
between
cc'd
on
rc
4291.
It
is
now
published,
it
is
from
suresh.
It
has
been
presented
in
six
months
this
week,
so
you
can
refer
to
the
presentation.
H
There
is
an
issue
tracker
initiated,
so
you're
welcome
to
directly
modify
it,
but
if
you
do
please
copy
the
the
spring
mailing
list
for
any
modifications
that
you
that
you
do
as
a
reminder.
The
document
is
now
a
working
document.
It
is
owned
by
the
working
group,
so
orders
please
work
with
working
group
to
to
progress
on
the
points
raised
during
adoption,
and
I
think
we
have
a
zero
one
addressing
some
comments.
So
thank
you
to
francois.
H
Adoption
call
we
did
the
call
on
srt
pass
midpoint
restoration.
H
There
is
a
support
for
the
requirement
to
protect
traffic
sentinel
policies.
H
H
H
I
Firstly,
thanks
very
much
for
the
welcome
and
you
know
coming
into
this
working
group
and
having
observed
this
working
group
for
a
long
time.
I
A
I
H
E
How
ampellat
and
palestine
parting
is
currently
being
covered
in
ipv6,
so
no
segment
routing
can
be
leveraged
in
an
ipv6
data
plane
in
mpls.
The
envelope
top
label
stack
section
is
encoded
in
the
iphix
entity
7,
while
the
subsequent
label
stack
is
decomposed
separately
in
ipfix
entity
71
to
79.
E
So
in
each
ipfix
entity
we
have
the
label
the
experimental
bits
and
also
the
bottom
of
the
stack
bit
while
in
iphix
entity
47.
We
see
that
mpls
top
label
ipv4
address
and
in
iphix
entity
46
the
ample
stop
label
type,
which
is
describing
from
which
routing
protocol
or
path
computing
element,
the
label
and
the
the
prefix
has
been
coming
from,
and
since
this
was
the
only
change
between
mpls
and
impala
segment,
routing
in
rfc
91
60,
we
updated
the
emperor's
top
label
type
registry
at
ayana.
E
So,
in
order
to
gain
also
the
same
data
plane,
visibility
as
we
have
in
mpellet
and
then
plus
segment
routing
and
also
in
srv6,
we
need
to
do
the
same
in
ipfix.
E
Currently,
I'm
aware
of
srv6
already
being
deployed
in
a
network
operators
network,
some
of
them
already
started
to
do
migrations
from
mpls
to
srv6
and
speaking
for
a
network
operator.
I
know
that,
especially
during
migration
phases,
data
plane,
visibility
is
a
very
crucial
so
that
we
can
actually
see
to
which
segment
routing
id
where
traffic
is
being
forwarded
or
being
dropped.
E
So
the
in
srv
fix
the
equipment.
Routing
header
is
defined
in
rfc
8754
section
two
next
slide.
Please.
E
And
we
were,
we
are
decomposing
that
in
several
ipv6
entities,
so
in
the
ipv6
srh
segments
left,
we
see
basically
where
we
are
in
the
segment
list.
In
the
ipv6
sf,
h,
tech
and
sre
flex,
we
are
composing
the
attack
and
the
flex
field
from
the
srh
and
in
the
ipv6
srh
segment.
Time
see
same
as
in
mpls
we
are
describing
from
which
routing
protocol
the
the
segment
has
been
coming
from.
E
Then,
in
the
ipfix
entity,
sf
section,
we
are
decomposing
the
entire
srh
as
a
series
of
n
octet,
while
in
srh
segment
list
section,
we
are
decomposing
the
segment
list
of
the
series
of
n
octets,
the
ipv6
sf
segment
and
the
segment
basic
list
there.
We
are
encoding
the
the
the
segment
list
as
an
order
basic
list
according
to
rfc
6313.
E
So
we
have
two
ways
of
exposing
the
the
seat
list
so
either
as
a
basic
list
so
or
as
a
entire
section
as
an
octet
array,
and
also
here,
I'm
asking
especially
the
network
vendors.
E
E
Next
step
is
some
operational
consideration
regarding
the
srh
compression
as
you're
aware
of
the
basically
the
the
with
sfh
compression.
We
have
a
so-called
compressed
seat
container,
which
is
basically
still
a
128
bit
long.
It's
a
180
128
bit
long
cc
list
and
therefore,
basically,
the
ipv6
srh
segment
list
does
not
change.
It's
still
a
list
of
ipv6
seats,
but
it
can
either
contain
ipv6
systems
or
a
list
of
seasid
container
or
both.
So
they
are
not
mutually
exclusive.
E
It
probably
makes
sense
to
add
in
the
rough
document
a
section
how,
basically,
the
iphix
data
collection
can
distinct
between
a
bb6
list
and
the
list
of
seasid
containers
and
from
what
the
autos
understood
them
probably
doesn't
make
sense
to
decompose
the
the
cc
contained
into
compressed
seats
in
open
export
there.
I'm
asking
for
feedback
from
the
working
group
next
slide,
please
so
so
far
we
have
been
collecting
feedback
from
stream,
ops,
awg
and
ipfix
doctor.
E
So
from
the
feedback
we
have
included
the
the
new
ipfix
entities
for
the
srh
section
and
the
segment
list
section,
but
also
added
the
segments
left
to
expose
where
in
the
segment
list,
the
forwarding
happens
and
that
might
be
useful
to
detect
forwarding
loops.
E
E
E
Next
slide,
please
so
data
plane
visibility
is
missing.
Do
you
recognize
the
we
problem
statements
to
believe
the
document
should
progress
quickly
through
itf
to
write
that
private
enterprise
code
points
are
being
used
at
srv6
deployments
and
therefore
we
requested
the
adoption
at
awg
and
I'm
looking
forward
to
hear
your
comments
and
feedback
questions.
K
Thomas
thanks
for
your
work
on
this,
and
also
previously
on
the
sr
mpls
part,
I
should
say
a
quick
feedback,
not
a
question
on
flight
number.
Seven,
I
think
your
about
the
ccd
container.
I
think
I
agree
with
your
assessment
that
it
doesn't
add
much
value,
at
least
in
my
opinion,
to
decompose
it
thanks.
I
L
Yeah,
just
just
to
build
on
what
katana
had
said,
there's,
I
think,
there's
any
value
in
decomposing.
L
In
fact
it's
I
think
it's
better
not
to
make
any
kind
of
guess
as
to
what
a
behavior
is
of
any
of
these
sids,
just
transport
them
and
let
the
let
the
receiver
determine
what
the
behaviors
are.
L
J
Joel
can
you
load
the
next
presentation.
G
The
deck
name
is
the
srv6
and
mpls
interworking.
Only
that's
what
I
sent.
B
B
G
So
this
draft
presents
the
interworking
scenario
into
generalize,
generalizes
interworking
scenario
into
so
that
into
a
simpler
topology
as
I'm
showing
in
this
slide.
So
if
you
see
green,
issuing
a
srv6
domains,
orange
is
showing
mpls
domain
and
the
dashed
overlays
showing
a
box
where
the
interworking
functions
are
done.
This
is
a
border
router
between
such
domains,
which
provides
the
interworking
function
and
supports
both
srv6
and
mpls.
G
So
in
this
slide
we
are
trying
to
generalize
the
problem
into
a
transport
interworking
and
the
service
interworking.
What
transport
interworking
means
is
we
have
a
layer,
2
layer,
3
and
layer,
2
services
which
are
either
srv6vpn
or
mpls
vpn,
and
the
service
interworking
that
we
are
trying
to
show,
but
in
the
bottom,
is
a
case
where
we
have
a
srv6
vpn
working
with
an
mpls
vpn
to
provide
service
connectivity.
Even
though
the
service
signaling
is
discontinuous,
it's
not
of
the
same
type
and
can
you
go
to
the
next
slide.
G
So
this
draft
introduces
new
behaviors
to
provide
that
interworking
functions
that
I
showed
in
the
previous
slide
on
the
border.
Routers,
so
first
function
that
we
introduced
is
a
first
behave
as
a
dtm
behavior
and
what
it
does
is
when
we
receive
a
srv6
packet
where
the
destination
matches
the
dtm
behavior,
we
decapsulate
the
ipv6
header
and
below
that
we
are
carrying
an
mpls
payload.
So
we
do
a
lookup
of
the
mpls
payload
and
we
we
send
the
traffic
further
based
on
the
mpls
labels
below
the
ipv6
header.
G
This
is
a
new
behavior,
another
new
behavior
again.
This
is
executed
on
the
the
into
as
an
interlocking
function
on
those
border
routers,
and
in
this
case,
what
we
are
doing
is
we
receive
an
I
I
when
we
receive
an
ipv6
packet
which
matches
the
dpm
behavior,
so
it
decapsulate
the
packet
and
whatever
is
the
associated
mpl
stack
with
this
behavior,
that's
pushed
onto
the
packet
and
so
and
based
on
and
further
forwarded,
based
on
the
new
stack
of
labels
being
pushed
next
slide.
Please.
G
So
this
is
a
new
h,
dot,
encaps,
dot
m
behavior,
which
takes
the
mpl
stack
as
in
input
and
adds
the
ipv6
header
and
the
srh
above
it
together,
mpls
label
stack
and
its
payload
becomes
the
payload
of
the
new
ipv6
packet
and
the
next
header
field
is
set
to
137,
because
it's
carrying
an
mpls
payload,
also
there's
a
reduced
version
of
it
next
slide.
Please.
G
G
So
once
we
do
that,
we
can
use
these
b
cits
in
the
segment
list
of
an
sr
policy,
which
is
an
sr
policy,
would
be
a
consistent
because
we
are
using
the
the
binding
set
of
a
different
type
and
it
represents
the
intermediate
domain
of
a
different
data
plane.
So
what
I
can
do
is
in
an
mpls
if
the
header
is
mpls
I
can
take.
G
I
can
create
an
mpls
binding
set
for
an
ipv6
sr
policy
and
represent
and
use
that
binding
set
to
represent
the
intermediate
data
plane
in
my
policy,
and
that
way
we
can
provide
a.
We
can
present
the
policy
to
the
hidden
next
slide.
Please
so
now
I
will
go
into
the.
How
do
we
create
these
states
on
the
interworking
boxes
or
the
for
these
functions?
So
we
use
the
in
the
transport
interworking,
as
I
mentioned
earlier,
we
are
trying
to
we
are
trying
to
reach
the
the
transport
endpoint
or
the
service
endpoint.
G
So
what
we
do
is
in
this
case
we
use
the
well-known
procedures
of
srpc,
where
we
provide
a
path
using
the
sr
policy
which
satisfied
a
certain
intent
across
the
multiple
domains.
Srpc
detects
the
data
plane,
discontinuity
because
it
is
getting
a
btp,
ls
feed
and
it
can
identify.
There
is
a
network
which
is
not
of
the
data
plane
type
of
the
hidden
where
the
sr
policy
is
to
be
programmed.
G
Also,
we
use
the
bgp
inter
domain
routing
3107
procedures
which,
to
advertise
the
the
egress
endpoints
pe
locators
or
the
we
can
say,
service
endpoints,
which
are
pe
locators
in
the
srv6
vpn,
as
well
as
ipv4
pe
loopbacks
for
the
mpls
lsp
in
the
multi-domain
network
and
advantage
of
bgp
inter
domain
routing
is
when
you
do
next
top
self
on
these
border
routers
between
these
domain.
It
provides
the
termination
of
the
next
stop
as
well
as
of
the
end
cap.
G
Next
slide,
please.
So
these
are
the
few
legends
that
I
have
using
in
the
slides.
One
is
a
green
means,
srv6
capable
node
orange
means,
mpls,
capable
node,
and
the
green
and
orange
in
the
circle
means
it
supports
both
mpls
as
well
as
srv
is
capable
of
next
slide.
Please
so
here
I'm
showing
how
we
can
make
an
srpc
based
solution
for
the
interworking.
So
what
happens
is
node.
G
10
is
a
pe,
which
is
advertising
the
vpn
service,
prefixes
vpn
prefix,
with
the
srv6
service
set,
which
I
am
showing
as
a
b10
as
a
locator
of
10,
followed
by
a
dt4
function,
which
is
a
perv
of
lookup,
and
then
it's
advertised
is
a
certain
color
red
which
tells
the
intent
it
is.
This
is
received
by
the
node
one
through
the
service
rrs,
but
node
one
is
sitting
multiple
domain
away,
which
is
not
a
common
igp.
So
what
node
one
is?
Does
it
doesn't
know
how
to
reach
the
note
10?
G
It
will
go
to
the
sr
pc
with
the
we're
asking
for
a
certain
intent.
That
means
it
could
be
a
low
tendency
to
reach
the
note.
10.
srpc
will
compute
the
low
latency
path
from
node
1
to
node
10
and
in
this
case
I'm
assuming
it's
node
2
in
the
domain,
1
node
5
in
the
middle
domain,
which
is
mpls
not
the
srv6
and
the
node
8,
which
is
again
back
to
srv6.
G
So
what
it
does
is
the
srpc
sees
there's
an
inconsistent
data
plane
in
middle
and
it
triggers
the
interworking
procedures
on
the
border
box,
in
which
case
in
this
case,
which
is
four
and
seven.
G
So
it
programs
an
sr
mpls
policy
on
node
four,
as
you
can
see
by
the
sequence
number
three
from
srpc,
and
it
is
allocating,
even
though
it's
an
srm
pls
policy
along
the
sla
path
for
node
five
to
node
seven.
But
it
is
bounding
it
to
an
srv6
policy
of
a
bm
behavior
and
that
policy
is
programmed
and
that
binding
set
is
programmed
on
the
hidden
node
1
by
the
srpc.
G
That
is
shown
by
the
sequence
number
four,
and
if
you
see
the
policy
on
the
node
one,
it
has
node
two
as
a
first
segment,
then
there's
a
binding
sid
of
the
vm
behavior
of
on
the
node.
Four.
Then
the
node
eight
by
a
node,
8
endpoint
and
then
the
node
10
endpoint.
So
what
happens
is
now
when
the
traffic?
Of
course
it
will
visit
the
node
2
and
function
and
update
the
ipv6
destination
at
the
segment
left
on
the
node
4,
it
will
execute
the
bm
behavior,
where
it
will
put
the
mpls.
G
It
will
update
the
the
destination
address
to
the
next
ips
address,
which
is
the
node
8,
but
it
will
also
push
the
mpls
stack
there
so
once
it
pushes
it
takes
through
the
sla
path
in
the
mpls
middle
domain
and
then
at
the
node
seven.
Of
course
it
will
because
of
the
php
or
note
5
it
will
it
will.
G
H
So
this
is
sorry
to
interrupt.
You
still
have
five
sides.
G
To
go
on
less
than
two
minutes
so
sure
time
quickly
finished.
I
think
the
idea
has
come
across.
It
should
be
fine
thanks.
So
this
is
exactly
same
idea,
but
here
the
we
are
seeing
the
english
domain
is
mpls
and
a
middle
srv6
domain.
Sr
policy
is
allocated
in
mpls
bindingsid
and
that's
what
we
put
in
the
segments
on
the
the
head
and
on
the
node
one
and
that's
the
way
we
provide
the
interworking
next
slide.
Please.
G
Yeah,
so
this
one
is
a
case
of
a
bgp
procedures
and
we
know
in
bgp
we
can
always
do
the
next
top
self
on
the
border
node
in
which
we
are
showing
node,
seven
and
four
and
which
can
terminate
the
certain
end
cap
and
then
advertise
the
new
one.
So,
in
the
case
of
in
this
case,
what
we
are
trying
to
show
is
this
is
srv6
vpn
end
to
end,
so
we
need
a
reachability
to
an
ok
locator
of
node
10.
If
the
traffic
is
just
in
from
the
node
1
to
node
10..
G
So
what
happens?
Is
we
can
advertise
the
ipv6
locators
in
the
right
node
through
an
mpls
domain
in
the
middle,
which
is
a
six
pe
solution?
I
can
always
advertise
the
ipv6
addresses
with
the
ipv
for
next
stop
and
with
the
explicit
null,
and
that
way
it
provides
the
reachability
of
the
locators
to
the
left
node
through
an
mpls
network.
It's
an
existing
xxp
solution.
Next
slide,
please,
and
similarly
to
provide
the
over
the
mpls
over
srv6
network.
G
What
we
do
is,
in
this
case
it's
the
one
and
ten
are
the
legacy
ps,
which
is
a
mpls
vpn.
So
we
use
the
existing
mpls
3107
path
here.
So
we
have
a
3107
labels
on
border
nodes,
four
and
seven,
which
goes
to
node
one.
It's
an
existing
bgplu
setup
just
that
from
four
to
seven.
We,
we
we
tunnel
into
an
ipv6
sr
ipv6
tunnel,
which
is
of
the
srv6
and
we
the
destination,
is
to
be
of
dtm
behavior.
So
that
way
we
provide
the
tunneling
next
slide.
Please.
G
I
think
I
can
skip
this
one.
We
can
go
to
the
next
slide,
yeah
summaries,
this
this
document
has
been
in
the
idf
from
october
2018..
The
draft
describes
both
the
data
plane
and
associated
control,
pin
procedures
for
data
plane.
We
have
defined
the
new
behaviors
dtm
and
dpm
behaviors,
and
we
also
introduced
the
concept
of
internet
connecting
binding
sets
to
traverse
the
heterogeneous
data
plane
for
control
plane.
We
provide
both
srpc
and
bgp
based
solutions.
Next
slide,
please
yeah,
so
I
I'm
looking
for
the
working
group
adoption
for
this
document.
J
M
I
am
sally
from
juniper
network,
so
one
question
basically,
regarding
this
srv6
end
behavior
end.dpm,
we
have
already
have
an
exact,
similar
seed,
vendor
dm
defined
as
part
of
draft
bonica
spring
srv6
and
dtm,
which
has
been
presented
a
few
times
in
the
spring
working
group
as
well.
So
I
see
the
definition
is
exactly
the
same.
G
So
so
sorry,
this
has
been
even.
G
N
Drove
hi
trove
here,
swadesh
one
question:
maybe
with
my
pc,
chair
hat
on
in
your
analysis,
for
the
sr
srpc
solution.
Is
there
any
gaps
that
you
had
found
while
describing
the
solution.
G
N
Yes,
I
think
in
a
single
pc
case,
it
is
pretty
clear
that
it's
easy
to
do.
What
I'm
worried
about
is
multi-pc
case,
where
you
have
different
pcs,
maybe
one
pcs
for
srv6
domain
and
another
for
sr
mpls,
doing
that
there
would
be
little
tricky
so
that
and
might
require
some
piece
of
extensions
as
well.
There
is
a
working
group
draft
in
pc
which
talks
about
how
to
do
stateful,
interdomain
parts,
so
there
might
be
some
changes
required
there
as
well.
So
I
think
maybe
we
need
to
discuss
this
offline,
how
to
progress.
J
Okay
last
last
question:
robin:
please
go
ahead.
C
Okay,
robin
hobby.
My
comments
for
this
draft
is
that,
in
fact,
this
the
interworking
between
the
srv6
domain
and
the
mcs
domain,
there's
the
complex
the
data
plane,
because
we
know
the
sr
advantage
of
srv6
used
to
transverse
the
domain
based
on
the
ipv6
reachability.
C
O
P
You
I
you,
okay,
hello,
everyone.
My
name
is
jacob
babaraj
monika,
I'm
going
to
present
the
mpls
extension
header
encoding
that
are
defined
in
our
draft
on
behalf
of
all
our
co-authors.
By
the
way
this
draft
has
been
presented
in
yesterday's
pals
working
group.
I
can
please
do
that.
P
Yeah,
so
just
let's
talk
about
all
the
abbreviations
which
are
used
in
the
presentation
and
the
draft
as
well.
I
will
leave
it
to
the
user
to
look
at
it.
Okay,
so
this
is
the
agenda.
We're
going
to
talk
about
in
the
presentation.
P
Next
slide,
please,
okay,
so
there
are.
There
are
many.
A
new
applications
are
coming
up
with
the
new
requirements
to
carry
an
additional
information
in
the
mpls
packet
to
influence
the
mkls
forwarding
or
for
the
oem
purposes.
So
this
requires
an
mpls
packet
to
carry
more
spls
or
espn
for
application,
and
this
will
increase
the
mpls
stack
that
drastically
to
solve
this
problem.
We
need
a
generic
framework
to
build
the
embedded
header
format
that
would
carry
multiple
loading
stations
in
the
mpl
stack
or
after
the
bottom
of
the
label
stack.
P
The
main
objective
of
this
trap
are
the
mpls
packet
should
be
able
to
carry
two
types
of
instax
forwarding
instruction,
one:
the
flag
based
instruction
forwarding
instruction.
That
does
not
need
any
spray
data.
Next
forwarding
instruction.
That
needs
an
accelerator,
the
mpls
packet
to
carry
additional
data
after
the
bottom
of
the
impeller
stack
and
the
third
one
is
any
combination
of
the
scene.
Stack
and
mpls
bottom
of
the
stack
powering
instruction
could
coexist
in
the
same
temperatures
packet
and
the
fourth
one
is.
P
Before
diving
into
the
solution,
I
want
to
let
you
know
that
we
have
done
the
extensive
hardware
analysis
to
come
up
with
the
implemented
asset
friendly
and
futuristic
solution.
So
the
mpls
extension
header
mainly
consists
of
two
parts:
mps
extension
header
indicator,
so
this
indicates
the
presence
of
the
mpls
extension
hunter
in
the
packet
and
the
second
one
is
mpls
extension
header
format.
The
format
in
which
the
empire
section
should
could
be
carried
in
the
mpls
packet
next
slide.
Please.
P
Let
us
see
the
different
options
of
mpls
extension
header
indicator
option.
One
is
to
extend
the
existing
eli
yield
by
repurposing,
the
els,
tc
and
ptl
fields
to
indicate
the
presence
of
the
mpls
extension
header
option.
Two
is
to
assign
a
new
special
purpose
label
to
indicate
the
presence
of
the
empire.
Section
behavior
option
three
is
to
use
a
user
configure
label
to
indicate
the
presence
of
the
repair
section
header.
Each
options
has
its
own
advantage
and
disadvantage.
P
We
could
choose
the
options
based
on
our
discussion
on
the
ietf
working
group,
so
here
the
fields
can
you
see
the
fields
here?
The
first
field
is
the
stack
by
data
link.
This
is
a
three
bit
field
which
is
used
to
indicate
the
total
length
of
the
instax
extension
header
in
the
order
of
four
bytes.
Some
of
the
parsers
would
require
the
length
of
the
total
length
of
the
in-stack
mpls
extension
for
the
easy
parsing
purposes.
P
The
next
next
is
the
bit
field.
That's
the
ipi
field,
so
this
is
actually
in
stack.
Mps
extension,
header
presence
indicator.
This
is
a
bit
field,
indicate
the
presence
of
the
instax
extension
header
and
the
next
one
is
the
bpi
field.
So
this
is
the
bottom
of
the
stack
empire's
extension
header
presence
indicator
a
field.
A
bit
field
indicates
the
presence
of
the
bottom
of
the
stack
extension
header.
P
So
last
field
is
the
hpi.
This
is
a
hub
by
hub
bottom
of
stack,
mpls
extension,
hydro,
indicating
a
bit
field
indicates
the
presence
of
a
bottom
of
stack,
empire's
extension
indicator
that
needs
to
be
processed
by
half
on
the
next
layer.
Please
this
is
the
instax
extension
header
and
it's
a
data
encoding
format.
So,
as
I
told
you
before,
this
has
two
parts:
one
is
the
instax.
P
Mpls
section
should
indicator
so
here
actually,
the
two
bit
the
ipa
bit
is
used
to
indicate
the
presence
of
in
stack
impedance,
section
header,
and
the
ion
that
is
the
in
stack
length
is
going
to
indicate
the
total
length
of
the
in
stack
mpls
extension
header
length
in
the
order
of
four
bytes
so
also
like.
We
could
carry
a
multiple
such
instruction
in
the
same
indicator.
P
So
next
one
is
the
instructors
extension
format
which
contains
opcode
with
the
instax
forwarding
instructional
code.
This
is
of
eight
bit
that
defines
the
folding
instruction
that
needs
to
be
executed
when
you
receive
the
packet,
and
next
this
is
the
instant
data.
This
is
an
ancillary
data
which
requires
to
be
executed,
which,
which
requires
to
execute
the
forwarding
instruction
and
they.
What
we
defined
here
is
that
data
stacking
bit
in
the
case
of
instead
forwarding
instruction
requires
more
than
20
bits
of
ancillary
data.
P
Then
this
bit
is
used
to
extend
and
carry
more
bits
of
answering
data.
If,
if
the
script
is
set,
then
this
this
will
be
the
end
of
the
android
data.
For
that
specific
forwarding
instruction,
the
the
the
last
one
is
the
ebit.
So
this
is
the
end
to
end
bit.
P
Let's
go
to
the
in
stack,
forwarding
instruction
and
opcode
assignments.
The
value
here.
Actually,
we
have
up
codes
will
be
assigned
using
the
inr
registry,
so
the
value
one
we
have
reserved
it,
for
you
know
to
carry
the
flag
based
forwarding
instruction.
In
some
cases
the
application
does
not
need
any
forwarding
instruction.
That
does
not
need
any
actual
data.
P
So
this
this
this
field,
this
sub
code
will
be
used
to
carry
the
flag
based
upwards
and
the
value
2
is
optionally
used
to
identify
the
byte
offset
of
boss
data
locate,
location
and
value
3
to
254
must
be
assigned
by
anna
and
the
last
value
25
is
used
to
extend
the
upcode
range
beyond
255.
P
the
next
like
please.
So
this
is
the
bottom
of
the
stack
header,
encoding
format,
so
as
an
indicator,
so
we
have
two
bits
to
indicate.
One
bit
is
to
indicate
the
presence
of
boss,
mpls
extension
header,
so
this
is
going
to
indicate
the
presence
of
boss,
impedance
extension,
header
and
another
bit
is
the
hub
by
hop
boss,
extension
header.
This
field
is
used
to
indicate
the
presence
of
boss
extension
header
that
requires
help
by
your
processing.
The
second
part
is
the
data
format.
P
The
first
level
is
0
0,
1
0,
so
this
is
to
avoid
aliasing
with
ipv4
v6
and
v6
packets
and
next
label
is
reserved,
and
the
next
update
is
the
opcode
instruction.
This
value
will
be
assigned
by
anna
the
next.
The
next
octet
indicates
the
length
of
the
boss.
Thanks
for
the
data
in
order
for
bytes,
the
next
update
is
used
to
indicate
the
boss
extension
hydraulic.
Currently,
you
have
two
two
flags
assigned.
One
is
the
next
header
presence.
P
This
indicates
the
another
boss,
mpl
section
header,
followed
following
and
the
hover
help.
That
indicates
the
requirement
of
processing
the
the
specific
header
by
hop
next
slide.
Please
I'm
not
going
to
distract
the
next
slide.
This
is
the
example.
Actually,
this
is
an
example
of
how
we
can
carry
the
data.
P
These
are
the
examples
next
type
please.
So
this
is
the
example.
This
is
another
option,
one
and
option
two
comparison
which
we
want
to
talk
about
for
the
ietf
users
to
discuss
and
extract
things
yeah.
Thank
you
welcome
for
welcome,
review
comments
and
feedbacks,
especially
on
the
mai
label
options.
I
end
up
be
requesting
mpls
working
grouping
currently.
Thank
you.
J
Okay
thanks,
I
actually
have
a
a
question.
Has
this
been
discussed
in
the
mpls
design
team?
I
thought
a.
J
Going
on
there
also.
Q
R
J
Actually
sent,
I
actually
sent
an
email
to
the
to
the
authors
of
this
document
several
weeks
ago
and
didn't
get
a
response.
J
There
are
several
documents
that
already
cover
this,
albeit
with
different
format,
and
I'm
wondering
if
those
have
been
looked
at
in
terms
of
you
know
making
sure
we
don't
have
multiple
documents
trying
to
solve
the
same
problem.
Thanks.
P
S
S
P
Actually,
suddenly,
like
today,
you
know
like
when
you
see
the
supplications
right.
A
lot
of
applications
are
coming
up
that
different
requirements,
which
needs
an
additional
spl
or
espn.
So
that's
going
to
increase
the
label
stack.
That's
where
you
know,
like
the
design
team
has
been
designed
to
tackle
this
problem
in
our
one
shot.
So
that's
why
we
are
trying
to
do
that.
S
T
So
I
two
comments
cheng
a
good
comment:
yeah.
We
hope
to
see
the
service
six
deployed
everywhere
very
soon
as
well,
but
meantime
mpls
network,
we
do
have
a
iom
draft
for
mpls
in
empire's
working
group
and
iom
is
one
application,
that's
very
appealing
to
the
operators
for
mpls,
and
the
second
comment
I
have
is
that
jim
we
have
received
your
email.
T
U
Thank
you,
jim
for
reference
to
mpls,
open
design
team,
it's
a
joint
effort
of
mpls
pals
and
that
networking
group
I
and
I
think
that
spring
because
of
sarah
mpls
everybody.
All
experts
are
invited
effectively
to
the
open,
weekly
design
team
discussions.
U
We
discuss
other
proposals
and
use
cases
are
documented
in
the
draft
as
well
separately,
so
the
motivation
being
discussed,
as
well
as
the
requirements
for
the
solution.
U
So
there
is
a
work,
that's
been
discussed
and
reported
on
yesterday
in
the
meeting,
and
so
I
appreciate
their
presentation,
but
I
think
that
there
are
a
lot
of
more
discussions
that
needs
to
be
done
before
consideration
of
working
group
adoption.
Thank
you.
J
Thanks
greg,
lastly,
jeff:
please
go
ahead.
You're
you're,
the
first
one
in
the
room.
D
Justin
sure
so,
keeping
aside
whether
it's
metadata
should
be
in
data
control,
plane
ipv6
over
srn
pls
is
deployed
at
huge
scale.
It
is
supported
by
most
vendors
and
ignoring
it
just
strong.
It's
a
good
technology.
It's
working,
it's
deployed,
so
please
just
keep
in
mind
that
world
is
not
about
srv6
necessarily
ipv6
servers
are
in
pls
its
current
working
technology.
So
just
keep
it
in
mind.
V
V
V
When
you
use
spfd
to
monitor
as
a
six
policy,
the
control
package
is
forwarded
to
a
reflector
according
to
its
associated
signal
list,
and
the
response
package
is
usually
forwarded
to
the
initiator
through
epi
routing,
so
forward
and
reverse
passes
of
the
package
are
likely
inconsistent
action
in
a
figure.
The
freely
unpassed
dea
will
cause
a
false
positive
issue.
A
consistency,
overwatch
and
reverse
pass
should
be
guaranteed
in
order
to
meet
this
requirement
and
spell
d
could
be
widely
deployed
in
srv6
network.
V
V
Okay
and
the
method
is
based
on
the
past
segment.
Sr6
path
segment
is
defined
to
identify
a
six
path,
such
as
completed
path
or
segment
list.
Ss6
part
segments
can
be
used
to
correlate
to
all
the
uni-directional
is
sex
passes.
At
both
end
note,
another
draft
of
itfs
policy
per
segment
proposes
an
attention
to
bgpsr
policy
to
distribute
as
a
policies
with
carrying
pass
segment
and
bi-directional
pass
information
through
this
extension.
When
distributing
sys
policy
to
the
head
end,
you
must
pass
information
and
per
segment
of
segment
leads
could
be
carried
together
in
this
way.
V
V
V
V
For
reflector
node
d,
the
spft
model
need
to
detect
flag
osih.
If
a
p
flag
is
a
site
extract.
The
path
segment
of
forward
pass
from
sh
then
get
a
second
list
of
all
response.
Control
package
by
the
forward
pass
segment
and
the
resulting
second
list
will
be
used
to
encapsulate
response
control
package.
V
T
C
Okay,
they
say
you
can
be.
I
will
present
the
sr
for
the
ietf
and
to
end
the
network
under
to
end
the
itf
network
slicing
on
behalf
of
the
coursers.
Okay,
here
are
some
this
background
introduction.
C
First,
we
are
familiar
with
the
network
slicing,
as
the
network
sizing
can
be
used
to
meet
the
connectivity
and
performance
requirement
of
a
different
service
or
customer
in
a
shared
network,
and
this
is
the
draft
ietl
for
this
ietl
network
slicing
describes
the
concept
and
the
general
framework
of
ietf
or
network
slides
that
is
itr
network
slides
can
be
realized
by
mapping
one
or
a
group
of
connectivity
constructed
to
an
rp.
Rpm
means
network
resource
partition.
C
In
fact,
before
that,
one
there's
the
one
draft
about
the
framework
of
the
enhanced
vpn.
So
in
here
there's
a
there.
The
return
concept
is
proposed
to
mean
the
underly
network
network
slice
construct,
but
it
is
not
only
confined
to
the
network
slice,
so
nrp
is
an
instantiation
of
retune
in
the
scenario
of
network
slicing,
okay
and
third,
one
this
end
to
end
network
slides
based
by
multiple
network
domain.
C
C
So
here
we
can
see
there
the
general
concept
and
the
framework
and
also
the
vpn
plus
framework
and
the
end
to
end
5g,
e2e
network,
slides
and
this.
After
this
the
framework.
In
the
past
years,
we
defined
the
sr
based
network
slice,
realization
the
most
important
to
use
the
resource.
We
are
segmented
for
the
network
of
slicing
and
indicate
the
resource
partition
and
the
then
they
are
later
the
scalability
user
challenge.
So
the
scalable
ietf
network
slice,
realization
solution,
has
been
proposed.
C
According
to
this
method,
the
duty
coupling
in
the
network
topology
and
the
resource
to
improve
the
scalability
that
is
one
month
ago,
also
that's
the
ipv6
encapsulation
for
the
networker
resource
partition
id
in
the
data
plane.
That
dropped
has
been
adopted
by
the
working
group
a
year,
6
map.
So
now
that's
we
talked
about
this
end
to
end
itm
network
slice,
realization.
C
So
this
means
how
to
implement
the
inter
domain
atm
network
slicing.
So
this
is
the
draft
okay,
next
page,
okay,
so
here
the
concept
is
simple:
that's
the
to
use
this
binding
segment
back
here.
This
introduce
a
special
fighting
segment
called
the
rp
by
the
binding
segment.
C
This
segment
is
a
special
bl
bs
id
used
by
the
domain
nodes
to
steer
traffic
into
a
local
network
resource
partition
so
and
this
the
network
resource
partition
psid
can
be
instantiated
with
srv6
or
srnpr's
data
plane.
So
here
there's
a
simple,
the
euler
solution,
so
we
can
see
there's
the
ingress
of
this.
The
internal
mean
sr
path.
C
C
Okay,
in
fact,
before
this
version,
so
that's
the
way
proposed,
there's
a
four
four
types
as
nrp
binding
segments.
But
later
this
version
of
the
draft,
we
divided
the
nrp
binding
segment
into
two
types.
That
means
the
rpt
binding
site
rpb
by
the
inside.
The
rpb
by
the
inside
is
the
tools
there
are.
The
traffic
to
our
sr
policy
associated
with
the
local
rp.
C
C
So
that's
you
use
one
this
binding
side
to
subversify
the
mapping
of
the
traffic
to
a
sr
policy
which
consists
of
a
list
of
resource
aware
segments
associated
with
the
local
nrp.
Okay.
That
means
the
binding
side
to
to
indicate
sr
policy
which
is
composed
of
the
resource
aware
segments.
C
C
Okay
and
also
for
the
nrp
sorry
rp,
be
by
the
inside.
There's.
Also
there's
the
two
variant,
the
first
variant.
That's
this
binding
side
is
directly
to
indicate
a
rp
local
nrp
at
the
edge
node.
So
that's
there's
one
binding
slide.
There's
one
local
nrp,
then
there's
an
rpb
binding
inside.
So
that's
the
first
variant,
but
we
also
have
the
second
variant.
So
that
means
only
there
is
a
binding
site
to
indicate
the
indicator.
C
There's
the
local
nrp
to
be
bound
as
the
edge
node
of
the
domain,
but
the,
but
the
nrp
will
be
specified
in
the
ingress
of
the
sr
path.
That
means
the
sr
the
the
rp
is
the
encapsulation
of
the
ingress
of
the
sr
path:
sr
policy.
C
Okay.
So
here
this
is
the
srv6
for
the
nrp
binding
side.
So
here
there
we
have
this,
the
srv6,
the
rpt
by
the
inside.
So
that's
the
rc
89
86,
the
under
b6
in
caps.
This
this
behavior
can
be
reused
under
this
document,
defined
the
under
dot
b6
nrp
dot
in
caps
this
another
behavior
for
the
second
variant
and
for
the
be
right
inside.
We
also
have
the
two
variant
and
also
the
tool
and
the
behavior
to
be
defined.
C
Okay,
next
page,
okay.
So
this,
similarly,
so
this
is
for
srpis
there's
also
this
the
different
instantiation
for
this,
the
rp
binding
side.
Okay,
last
page-
and
this
is
the
summary
of
the
updates-
so
the
first
align
the
terminology
with
itr
network
slice
and
the
vpn
plus
dropped.
That
means
that
we
adopted
the
rp
as
a
terminology
to
replace
the
vtn
a
second
we
defined
the
two
types,
rp
binding
segment
for
the
srt
and
the
b,
and
and
also
this
editorial
change.
Okay,
that's
the
page.
C
J
Thanks
robin
linda.
W
Thank
you
robin
for
the
comprehensive
illustration
of
all
the
drafts
you
have
for
the
vpn
plus.
I
just
have
a
one
question
like
for
5g.
We
really
need
something
to
have
different
paths
based
on
the
source
address.
So
is
any
of
those
drafts.
I
didn't
get
chance
to
read
all
of
them.
Any
of
the
draft
describe
that.
C
In
fact,
this
is
the
this
job
is,
regarding
user
related
to
the
ietf
network
slicing.
That
means
the
transport
network,
but
this
is
not
for
the
5g
and
to
end
the
network
slice
realization.
This
is
even.
W
For
transport,
for
example,
the
traffic
come
to
upf
right
so
based
on
the
ue,
for
example,
in
the
compute
aware,
not
working
buff,
when
different
ue,
like
maybe
hand
over
to
different
cell
tower,
anchored
to
a
different
upf.
He
would
like
to
use
a
different
slice
than
the
other
ues
which
were
there
before,
so
it
would
be
nice
to
be
able
to
like,
based
on
the
source,
address
and
then
allocate
to
different
slicing.
I
just
wondering
if
there's
any
draft
describing
that.
C
Okay,
in
fact,
this
drop
is
another
for
for
this
purpose,
in
fact,
there's
the
two
drops
about
the
5g
and
to
end
the
network
slicing.
I
think
this
is
the.
In
fact.
The
5d
traffic
will
not
directly
enter
into
the
ietful
underlying
network
slice
because
of
the
the
the
tracking
from
the
upf
will
first
interworking
with
the
vpn
of
the
transport
networking.
C
So
here
the
they
can
use
on
this,
the
vla
for
the
interworking.
So
that's
a
to
access
to
the
vpn,
so
that's
the
vpn
can
go
on
mapping
to
the
underlay,
an
rp.
So
that's!
This
is
the
case
and
also
that's
one
dropped
in
the
teeth
working
group.
We
have
the
one
draft
that's
used.
We
can.
C
R
This
is
just
answering
lindo's
question
you
mentioned
about
the
how
this
one
relates
to
5g.
There
are
a
group
of
rfc
the
drafts
or
the
draft
at
the
t's.
That
encourage
you
to
take
a
look.
I
can
send
you
a
handful
of
those
drafts,
but
in
summary,
the
whole
idea
of
the
creation
of
ietf
network
slice
is
different
from
the
usage
of
that
during
the
signaling,
because
when
you
refer
to
ue,
that
is
the
signaling
part.
That
is
the
the
orthogonal
action
which
happens.
R
You
are
creating
itf
network
slides,
which
means
that
you
are
connecting
logically
subset
of
your
network
to
the
5g
ram
and
5g
core
mobile,
and
after
that
you
are
going
to
use
it.
So
just
for
clarity,
ue
and
anything
related
to
signaling
is
orthogonal
to
the
right
turn
address,
but
I
will
send
you
the
some
of
the
draft
and
if
you
want,
we
can
talk
offline.
Thank
you.
J
Okay,
thanks
army.
Please
go
ahead.
A
X
So
this
is
the
agenda
for
for
the
for
the
presentation
of
today
next
prize
next
slide.
Please.
X
X
X
Here
are
some
of
the
terminologies
that
we
that
we
will
use
during
the
presentation,
so
especially
what
we
call
the
midpoint
compressed
data,
and
this
is
basically
the
information
that
every
transit
router
along
the
bucket
bus,
add
into
the
packet,
and
it
is
actually
just
three
bytes
of
information,
which
is
a
key
comparison
to
a
support,
fast
racing
headline
rate,
in
addition
to
some
of
the
headers
that
we
use
in
in
the
package.
X
X
X
X
X
Then
we
have
a
segment
routing
header
with
a
segment
routing
pass
tracing
tlp
the
source
node
after
it
creates
this
packet.
It
decides
in
which
interface
the
packet
is
going
to
be
sent
using
the
normal
forwarding
and
it
records
its
information
in
the
packet
just
because,
just
before
the
bucket
leaves
the
router
next
slide.
Please.
X
The
second
row
here
is
the
midpoint.
This
midpoint
receives
the
pro
package
that
was
generated
by
the
source,
perform
an
ipv6
forwarding
or
an
sr
endpoint
behavior,
and
before
also
forwarding
the
packet
out
from
the
node.
It
records
its
mcd
data
in
the
hope
by
hop
pass
tracing
option
next
slide.
Please.
X
X
The
sync
node
will
record
its
pass
tracing
information
in
the
segment
routing
header
tlb
and
will
forward
this
packet
to
original
collector
next
slide.
Please,
the
role
of
this
collector
is
basically
to
receive
the
pro
packet
extract,
the
pass
rating
information
and
save
them
into
a
time
series
database.
X
The
pass
rating
to
information
in
the
time
series
database
will
be
used
by
operators
basically
to
perform
all
of
the
different
analytics
next
slide,
so
in
pass
tracing.
Actually,
we
define
two
new
headers.
The
first
one
is
a
hope.
I
hope
pass
tracing
option
the
format
of
this
option,
as
shown
here,
so
we
have
an
mcd
stack
that
will
be
a
pre-allocated
space
for
the
midpoint
to
record
their
data.
X
X
X
Regarding
the
security
of
model
for
consideration
for
pass
tracing
so
in
pass
tracing,
we
leverage
the
security
consideration
defined
for
the
segment
routing
domain,
as
defined
in
rfc
8754.
X
X
X
So
we
welcome
the
review
and
the
comments
from
the
working
group.
In
particular,
we
would
like
to
ask
other
vendors
to
review
the
data
plane
model
for
pass
tracing
and
give
your
feedback
if
we
need
any
more
optimization
or
the
data
plane
is
good
to
be
supported
at
land
rate
by
other
operators
by
other
vendors.
Thank
you.
U
Everything
that
you
are
achieving
can
be
already
achieved
using
iam
and
even
more
because
iem
has
advantage
of
collecting
telemetry
information
out
of
band
without
impacting
the
data
flow
by
incorporating
telemetry
information
in
the
trigger
packet,
so
that
can
be
achieved
using
direct
expert
option
of
trace
or
hybrid
two-step
option,
and
I'm
happy
to
discuss
it
on
the
mainland
list
more,
but
this
proposal
is
redundant.
S
So
I'd
like
to
know
the
relationship
between
this
pokemon
go
and
rom
and
by
the
way
I
yeah
I'm
really
curious
about
the
temp
stamp
format.
I
think
it
would
not
be
so
accurate
yeah,
so
so,
oh
okay,
so
so
a
two
years
ago
we
have
a
similar
solution,
called
light
item
like
iom.
So
I
can
prepare
the
link
for
the
reference
yep.
X
Okay,
so
again
again
for
fast
racing
versus
iom,
I
believe
again
that
that
this
solves
two
different
problems,
especially
fast
racing
has
been,
has
been
optimized
for
line
rate
hardware
implementation,
but
we
can.
We
can
discuss
more
on
on
the
mailing
list
on
that.
Thank
you.
F
Yes,
I
just
want
it
says.
I
share
the
same
opinion
as
a
great
and
we
do
need
to
make
a
better
comparison
with
iom,
and
if
iom
can
achieve
the
same
goal,
it
seems
unnecessary
to
have
another
solution.
Thank
you.
J
Okay,
last
pablo:
please
go
ahead.
Y
I
believe
that
the
issue
that
we
are
facing
with
iam
is
that
the
data
plane
descent
when
we
do
not
want
to
do
direct
export,
it's
it
becomes
quite
complex
to
support
in
any
device,
particularly
not
only
because
the
data
fields
are
large,
but
also
because
the
the
amount
of
editing
commands
that
you
require
to
implement
it
in
the
actual
hardware.
Y
And
so
basically,
if
you
want
to
do
ecmp,
monitoring
and
troubleshooting
collecting
the
data
from
the
data
path
itself,
I
believe
there
is
no
way
to
solve
that
with
iom,
but
anyway
we
are
happy
to
discuss
more
on
demanding
this.
Thank
you.
M
We
hear
you
okay
thanks,
so
I
am
charlie
from
juniper
networks.
I
am
representing
the
traffic
srv6
in
the
domain.
Mapping
suits
on
behalf
of
my
co-authors.
Can
you
go
to
next
slide?
Please.
M
Yeah,
so
we
had
presented
the
initial
version
on
the
ietf112,
and
these
are
the
updates
from
the
last
version.
We
have
two
new
callers.
We
thanks
their
contribution
and
we
have
enhanced
some
seed
behaviors
to
cater
to
cases
like
oem,
and
we
also
added
a
section
on
interworking
procedures
by
taking
examples
for
the
use
cases
we
defined
in
the
draft
yeah.
So
basically,
this
traffic
had
mentioned
three
new
srv6
nbc
endpoint
behaviors,
named
n
dot,
replace
and
dot
replace
b6
and
android
db6.
M
So
these
behaviors
actually
helps
to
build
paths
across
different
srv6
domain.
One
operator
has
the
document
mentioned
two
use
cases,
one
where
the
option
c
multipliers
is
connecting
where
the
borders
are
connected
by
ebgp,
and
then
there
is
a
second
use
case
where
we
have
option
b
style
interworking,
so
the
android
replace
and
android
replace
b6
are
for
the
first
use
case
for
the
option.
C
style
connect
connectivity.
M
So
what
the
changes
from
the
last
revision
is,
we
have
added
a
section.
Normally,
this
n
dot
replace,
cannot
be
the
last
segment
in
the
sr
policy.
So
we
extended
this
when
the
segment
list
left
equal
to
zero.
We
have
updated
similar
to
the
other
seats
mentioned
in
the
network
programming
rfc
8986,
so
the
remaining
definitions
remains
the
same.
M
Yeah,
so
here
also
the
this
n
dot
replace
b6.
It
also
cannot
be
the
last
segment
in
the
srh
so
similar
to
the
previous
seed.
We
have
enhanced
segment
left
equal
to
when
the
segment
left
equal
to
zero.
M
M
Can
you
go
to
the
next
slide?
Please
yeah.
So
this
is
for
the
this
n
dot.
Db6
is
used
for
the
second
use
case
for
the
service
interworking.
So,
as
per
the
definition,
it
must
be
the
last
segment
in
the
search
so
for
different
from
the
other
two.
We
have
changed
when
the
clarity.
M
Processing,
so
when
the
upper
header,
we
clearly
defined
ipv4,
ipv6
and
ethernet,
and
then,
if
it
is
not
belongs
to
that
how
to
process
similar
to
the
other
episode
behaviors.
So
here
also,
clarity
has
been
provided
on
a
few
fields
on
the
new
ncaa
header.
M
M
So
here
this
is
all
the
first
use
case
options
in
the
working
example.
So
there
are
three
different
srv6
domains
connected
by
iebgp
and
within
the
domain
there
is
ipgp
connectivity
and
there
could
be.
In
this
example,
we
have
taken
three
srt
different
paths.
The
ets
has
a
different
srt
path
for
the
transport,
so
these
two
seats,
this
replace,
b6
and
replace
it.
So
then
the
common
logic
is
for
a
route.
If
the
next
stop
is
one
hop
away,
then,
while
advertising
we
use
and
dot
replace
it
for
a
route.
M
If
the
next
stop
is
multi-hop
away,
then,
while
advertising
we
use
and
dot
replace
v6
and
for
a
single
hop
network
scenario,
we
there
is
no
encap
required,
as
it
is
just
a
replace
or
a
swap
yeah.
So
the
more
details
on
control
plane
and
data
plane.
That
is
explained
more
in
the
draft
yeah.
This
is
the
next
use
case
so
where
there
is
option
b
connectivity,
the
four
is
acting
as
the
abr,
where
the
service
center
working,
the
stitching
db6,
is
advertised
from
the
node
four.
M
So
all
for
all
prefixes
having
the
same
services
same
db60
will
be
reused,
but
if
a
different
services,
different
db6
will
be
used.
So
this
ensures
that
if
the
egress
arrow
gets
perceived,
the
translation
at
the
node
4
also
ensures
percy
behavior
yeah,
so
the
db60
is,
it
is
high
locator
at
the
node,
for
so
this
is
for
the
option
b
here.
Also
we,
the
trap,
takes
how
each
control
plane
and
data
plane
messages
flows
through
the
network
and
next
slide,
please
yeah,
so
so
yeah.
We
request
working
group
review
and
comments.
J
Okay,
thanks
ketan.
K
Thanks
sally
for
the
presentation,
I
had
a
clarification
question
on
slide
number
six.
You
could
go
there
I
wanted
to.
We
could
go
back
to
the
slide
joel
if
it's
possible.
I
had
a
the
question
was:
why
do
we
need
a
replace
in
that
scenario,
one
more
the
options
here.
Thank
you
on
this
slide.
Why
do
we
need
the
replace
behavior
in
the
first
place?
K
I
I
think
you
mentioned
something
about.
You
know
sr
policies,
but
I
didn't
quite
get
that
I
mean
in
option
c.
Why
couldn't
one
just
directly
reach
16.
M
Yeah,
so
what
why
we
are
taking
two
different
seats
right
so
that,
as
we
mentioned,
if
it
is
the,
if
the
ais
has
only
best
effort
or
plexilgo
that
optimization
we
can
do,
we
don't
need
an
additional
end
cap.
But
if,
if
it
has
an
srt
policy,
then
we
need,
because
we
need
to
first
reach
from
one
border
to
other
other
border,
so
we
have
to
replace
first
so
that
the
other
border
understand
what
to
be
a
process
next.
M
So
that's
why
the
first
change
in
destination
we
have
to
do,
but
then
there
is
an
additional
end
cap
required
for
that.
The
the
upcoming
domain
right,
because
that
srt
path
that
has
to
be
on
a
new
end
cap.
K
Okay,
so
if
I
understood
you
correctly,
there
is
a
underlay
bgp
that
you
have
and
and
the
replace
is
used
or
needed
by
that
under
labor
gp,
correct-
and
this
is
probably
in
the
car
or
city
correct.
F
Hello:
everyone
I'm
going
to
talk
about
this-
is
how
you
song
from
futurely
I'd
like
to
talk
about
this
srv6
in
c2
active
measurement
on
behalf
of
other
closers
next
slides,
please
yeah.
First,
the
the
update
from
the
initial
version.
Now
we
reposition
this
as
a
generic
framework
for
sr6
active
measurement
and
we
can
support
other
active
oem
protocols
in
addition
to
iom.
Under
the
same
framework
also,
we
have
a
new
processor
giant
mission
next
slice.
F
The
motivation
for
this
work
is
that
we
believe
actually
the
srv6
need,
need
active
measurement
method
and
also
active
method.
Active
measurement
method
is
also
very
suitable
for
srv6,
because
srv6
has
this
traffic
steering
property,
so
it
can
support
arbitrary
parts,
specify
srh
and
also
we
can
start
the
probe
from
any
any
sr
node
and
the
terminator
and
another
another
or
even
the
same
sr
node
so,
which
means
it's
very
flexible
to
apply
active
measurement
and
also
the
forwarding
is
totally
determined
by
the
srh.
F
That's
why
using
this,
we
can
also
facefully
reflect
the
data
plane
user
traffic
experience.
It
can
has
many
possible
potential
solution,
applications
first
lines
to
achieve
the
next
network,
wide
visibility.
F
We
can
use
smart
algorithms
to
actually
build
the
the
different
sr
parts
to
cover
the
entire
network
to
for
the
for
the
network,
wide
health
monitoring
and
troubleshooting,
and
also
we
can
easily
achieve
the
alternative
path,
probing
for
protection,
traffic
engineering
or
multi-parts
load
balancing
and
with
using
this,
we
can
also
easily
to
achieve
the
symmetric
or
asymmetric
round-shift
measurement.
F
So
just
so,
we
just
define
the
parts
and
the
mixed
package
return
back
to
the
south,
so
we
can
get
the
measurement
so
this
framework,
the
general
to
just
to
use
a
udp
payload
to
encapsulate
the
oem
protocol
header
and
the
data.
We
can
use
a
different
udp
destination
output
number
to
differentiate
different
protocols.
F
Sorry-
and
also
we
proposed
to
use
a
t
flag
in
srh
flat
field
to
indicate
this
as
an
active
pro
package.
This
is
important
because
without
such
a
flag,
the
package
may
may
be
mistakenly
considered
as
a
normal
usage
user
package,
better
better
sr
nodes
and
be
ignored.
F
So
in
this
draft
we
mainly
focus
on
ioam
as
a
chief
use
case
and
also
there's
another
dropped
already
being
adopted
by
the
working
group.
It's
talking
about
how
to
support
as
stem
as
a
use
case,
but
here
we
also
suggest
to
arguments
that
draft.
Is
this
t
flag
to
indicate
the
active
environment
package
and
there
are
also
other
possible
use
cases,
for
example,
to
support
iom,
direct
export
and
or
alternate
marking
schemes,
or
can
be
supported
under
the
same
framework.
F
So
this
slide
shows
how
the
format
of
the
srv6
active
environment
with
iom
I
can
after
the
srh
header
follow,
is
followed
by
a
udp
header.
We
can
use
a
destination
port
to
indicate
the
payload
of
following
it
is
a
iom.
F
Then
we
can
apply
the
standard
iom
header
after
as
a
udb
payload,
and
there
are
some
benefits
for
this
scheme
is
because
I
here
everything
is
already
in
standard.
There's
no
need
to
have
a
new
standard
proposal
and
also
iom
can
support
flexible
and
extensible
data
extension,
and
since
we
encapsulate
the
entire
ram
in
the
udp
payload,
there's
no
basic,
essentially
there's
no
limit
on
segment
hubs.
We
can
support
very
long
paths
to
collect
all
the
data
next
slice.
F
Oh,
I
can't
read
it
oh,
why
is
it
looks
like
this?
Okay,
it's
applications.
I
already
talked
about
this,
that's
it.
I
will
just
emphasize
that
it's
a
it's
a
it's
an
easy
way
to
support.
You
know
it
can
be
considered
another
easy
way
to
support
iom
for
srv6
without
drawbacks
of
encapsulation
or
the
overhead
concerns,
and
also
we
just
use
this
as
an
active
method
to
measure
the
alternative
parts,
long
trip
or
the
cover
the
entire
network.
F
F
Okay,
so
next
step,
we
would
like
to
request
for
working
group
adoption
and,
of
course
we
will
come
all
the
comments
and
the
reviews
and
in
the
next
revision
we
also
consider
to
include
other
issues.
Thank
you.
J
Thanks
how
you
greg
please
go
ahead.
U
Presentation
clarification
question
so
how
this
proposal
related
to
ippm
working
group
document
that
defines
iem
encapsulation
in
ipv6.
F
Okay,
I
think
this
one
is
a
focus
on
the
active
environment,
but
that
wise,
I
think
it's
a
for
the
original
use
of
iom-
is
a
is
considered
as
a
hybrid
method
and
mean
to
encapsulate
iom
in
user
traffic.
But
here
we
just
use
it
as
a
dedicated
probe
only
for.
U
Active
my
my
understanding
that
I
am
can
be
applied
to
active
ip
oem
packets
so
to
achieve
everything
that
you're
proposing.
U
So
I
don't
understand
why
you're
really
emphasizing
active4am
ip
active
ipom
in
service
6
uses
regular
ipo
m
like
icmp
or
ip
encapsulated
stamp
or
bfd.
So,
yes,
explicit
routing
allows
us
to
engineer
the
path
that
test
packets
takes.
So
it's
equally
applicable
to
all
known.
U
Oem
in
ip
so
applying
iom
to
that
is
not
a
rocket
science.
F
Yes,
a
unique
feature
of
the
iom.
You
also
understand
is
that
to
we
can
actually
collect
all
the
data
along
the
path
and,
while
most
other
om
techniques
is
only
work
in
the
edge
to
edge
or
end-to-end
fashion.
So
I
think
iom
can
bring
the
unique
you
know
benefits
to
this
active
environment
area.
F
Yeah,
as
I
said,
the
that
solution
is
proposed
to
encapsulate
the
iom
in
maybe
in
other
extension
headers,
and
it's
intended
to
be
used
for
user
traffic
and
also,
in
my
opinion,
it's
a
you
know.
It's
a
it's,
bring
some
issues
about
encapsulation,
encapsulating
iom
in
the
effects
header
because
of
its
huge
overhead
and
also
there's
some
consideration
about
how
to
actually
use
a
as
our
ipv6
extension
header.
So
I
think
here
we
just
avoid
all
those
issues
and
we
can.
It
can
be
deployed
immediately.
U
I
would
propose,
if
you
not
happy
with
the
iptm
working
group
draft,
why
not
to
work
with
ippm
working
europe
rather
than
proposing
alternative
solutions,
so
driving
itf
to
standardize
two
ways
to
inc
encapsulate
iem
in
ipv6.
So.
H
U
And
special
services
that
seems
yeah
not.
F
U
U
No,
my
understanding
that
stem
draft
in
spring
working
group
is
informational
because
it
doesn't
define
anything
so,
but
let's
take
it
to
the
middle
of
this.
Thank
you.
Z
Yeah,
so
thank
you
chuck.
Could
you
hear
me?
Yes,
we
can
okay.
This
is
which
I'm
from
channel
mobile,
and
so
this
is
a
new
draft.
It
gives
some
good
practice
to
use
the
sr
basics
policy.
Let's
see
the
requirements
and
the
proposal
here,
let's
see
the
application
scenarios
and
first
you
know
some
enterprise.
Customers
have
different
kinds
of
services
with
different
cues.
Z
It
can
be
identified
by
color
and
the
endpoint
on
the
highland.
It's
the
same
with
isa
policy.
Z
So
how
to
use
asap
policy
group,
I
think
firstly,
we
should
study
the
traffic
into
as
a
policy
group.
We
can
have
two
kind
of
ways.
First,
is
a
per
fluid
story.
Z
If
you
want
to
do
that,
you
can
take
two
steps.
First
step,
you
should
steering
the
flow
to
the
sr
policy
group
and
the
step.
2
select
the
constituent
as
a
policy
of
the
group
similar
for
the
policy-based
story
and
the
as
our
policy
group
can
be
configured
manually
all
distributed
by
the
controller
or
you
can
create
through
odin
automatically
next
page.
Z
Vip
customer
and
the
policy
b
is
the
normal
traffic
for
the
vip
customer,
and
the
policy
c
is
the
normal
traffic
for
the
non-vip
customers
and
we
use
the
dsap
to
map
to
the
color.
Z
Z
Z
And
the
voice
traffic
of
the
vip
customers
will
will
be
forwarded
to
the
low
latency
constitute,
I
suppose,
a
and
the
other
traffic
of
the
vip
customers
will
be
forwarded
to
the
policy
b
and
the
non-vip
customers.
Traffic
will
be
carried
by
the
policy
c
in
the
so
it
will
provide
a
very
good
solution.
Z
Z
So,
let's
see
when
the
traffic
running
there
are
two
kind
of
conditions
happen
we
can
use
for
back
pass
the
first
one.
If
there's
a
new
constituted
isr
policy
to
match
for
the
traffic,
then
the
flu
can
be
folded
through
the
fallback
pass.
The
second,
so
there's
no
available
constitute
as
a
policy
except
for
back
pass.
Then
the
traffic
can
be
through
the
forbade
path,
so
it
will
provide
some
solution
in
some
application
scenario.
N
If
you
can
confirm,
we
have,
like
you,
know,
sr
policy
with
composite
candidate
path.
Are
you
calling
the?
What
is
the
main
difference
between
that
and
what
you
call
as
sr
policy
group?
Is
it
the
way
that
you
are
steering
inside
the
sr
policy?
Is
that
the
main
difference.
Z
Oh
so
ciao
could
you
page
to
the
second
slide?
I
I
think
I
I
understand
your
meaning
so
joy.
Could
you
page
the
page
two
of
the
slides.
Z
Yeah
so
in
fact,
I
think
it
as
a
policy
group,
in
fact
the
reprisance
composite
candidate
in
the
past,
which
defined
in
segmented
routing
policy
draft.
I
I
think
I
agree
with
you,
but
in
the
draft
it
didn't
give
any
use
case
or
how
we
can
use
that.
So
here,
when
we
deployed
sr
policy
in
our
network,
we
found
that
the
solution
is
good
but
how
to
use
it.
We
should
give
some
detailed
solution.
So
that's
why
we
write
this
draft.
We
call
that
a
use
case
dropped
and
hope.
N
But
in
this
case
I
think
the
biggest
issue
is
that
the
you
are
deviating
from
what
is
defined
in
the
architecture,
sr
policy
architecture
graph,
where
it
says
that,
in
case
of
composite
sr
policies,
you
will
be
doing
load
balancing
based
on
the
weights.
But
here
what
you
are
proposing
is
that
you
wanna
do
like
you
know,
send
via
vip
traffic
on
one
and
non-vip
traffic
on
another.
I
think
that's
not
part
of
the
draft
anyway,
since
we
are
out
of
time
I'll.
Take
my
question
to
the
list
and
I'll.
A
Yeah
I
just
wanted
to
point
out
that,
like
the
unit
of
signaling
is
the
candidate
path.
So
when
you
say
it's
a
it's
a
special
sr
policy,
it's
really
like
a
special
sr
candidate
path
within
a
policy
and
second,
I
think,
yeah.
We
should
put
something
in
the
sr
policy
architecture
draft
about
the
about
the
possibility,
at
least
to
sig,
to
send
traffic
using
the
dscp
or
whatever
else,
instead
of
or
or
in
addition
to
the
weight.
Z
Yeah,
I
understand
in
a
in
fact
for
the
sr
policy
group.
I
think
that
may
be
some
hierarchical
solution.
I
think
that
is.
Z
We
maybe
need
to
define
some
more
thing
to
make
it
work
wire.
A
It's
basically
just
you
know
the
unit
of
signaling
is
the
candidate
path.
Like
you
don't
need
to
signal,
you
know
you
can
have
a
policy
with
just
one
candidate
path.
Right
or
you
know
you
can
have
multiple
candidate
paths,
so
you
can
put
a
restriction
that,
like
a
policy,
can
have
you
know
one
candidate
path.
If
it's
composite
or
something
like
that,.
J
A
J
To
be
fair
to
them,
guyan
and
boris
you're
in
the
queue.
If,
if
you
can
be
quick,
please
go
ahead
guy
in
first.
Q
Just
a
quick
question:
is
this
some
draft?
I
guess
that
you
mentioned
like
composites
or
are
you
are
you
I
guess
seems
like
you're
doing
some
type
of
mapping,
but
is
this
introducing
something
new?
I
guess
to
the
sr
policy
and
it
sounds
like
it
is,
and
if
it
is,
I
mean
I
guess,
the
concept
of
actually
adding.
I
guess
addition
to
weights,
I
guess,
with
mapping
of
dscp
with
something
like
this
as
the
the
sr
policy
draft
has
not
been
is,
is
still
being
developed
and
it's
not
an
rfc.
Could
some
of
this?
Q
Q
J
Yeah,
let's
take
let's
take
this
to
the
list
and
boris
unless,
if
you
can
be
very,
very
quick,
yes,
thank
you.
AA
J
Okay,
joel
you,
you
just
pointed
out
to
me
my
my
laptop
is
showing
me
924,
but
I
just
looked
at
my
phone
and
it's
9
31.,
so
I
guess
we're
actually
out
of
time.