►
From YouTube: IETF112-SPRING-20211108-1200
Description
SPRING meeting session at IETF112
2021/11/08 1200
https://datatracker.ietf.org/meeting/112/proceedings/
A
A
Reminder
to
go
with
the
notewell
our
ads,
I
believe
all
of
the
ads
have
asked
all
the
chairs
to
make
to
issue
this
reminder
of
bcp
54.
That
folks
need
to
be
respectful
and
courteous.
We
discussed
the
technical,
material
and
solutions
for
the
global
internet
across
a
range
of
requirements
and
that
everybody's
here
to
participate.
A
A
Here
is
the
agenda.
It
is
not
an
especially
crowded
agenda.
We
have
two
hours
we're
scheduled
for
85
minutes.
I
wouldn't
be
surprised
if
some
conversations
take
longer
but
we're
going
to
go
through
it.
So,
for
example,
the
t-wamp
draft
will
be
up
after
I
finish,
going
through
the
chairs
presentation
and
then
we'll
go
through
the
rest
of
these.
A
A
A
A
As
the
queue
management
enter
the
queue
using
the
tool,
mute
yourself
when
you
are
not
speaking
when
you're
on
the
q
I
or
whoever,
whichever
chair
is
running,
things
will
tell
you
when
it's
your
turn.
Unmute
yourself
speak
go
ahead.
If
you
are
speaking,
you're
welcome
to
present
vid
share
video
of
yourself
as
well.
A
A
A
A
A
The
document
when
it
is
posted
will
include
a
specified
open
issue,
section
separately.
I
am
in
the
process
of
establishing
an
issue
tracker
because
I
do
not
expect
the
editors
to
be
updating
the
draft
for
every
individual
issue
and
every
individual
change
to
every
individual
issue.
The
open
issue
section
is
for
major
issues.
As
the
text
I
provided
says,
we
will
use
get
a
github
based
issue
tracker,
because
that's
what
the
tools
people
tell
me
is
the
thing
we
are
supposed
to
use
for
issue
tracking.
A
Now
we
will
not
be
putting
the
draft
into
github
unless,
for
some
reason
the
editors
decide
they
want
to.
I
won't
prohibit
it,
I'm
just
not
expecting
it,
and
all
discussion
of
issues
will
be
on
the
mailing
list.
The
issue
tracker
is
just
so
we
don't
lose
track
of
any.
There
was
enough
discussion
and
heck.
A
A
My
expectation
is
that
draft
will
be
the
one
that
the
six-man
leadership
is
in
the
process
of
appointing
authors
for,
and
there
is
a
presentation
from
those
from
them
in
the
six-man
session
about
that
draft.
If
they
don't
post
something
that
addresses
this,
then
we'll
deal
with
it.
Another
way,
we'll
figure
that
out
when
we
come
to
it,
I'm
not
trying
to
write
a
adoption,
call
conclusion
that
deals
with
every
imaginable
contingency.
That's
why
we
cope.
A
A
A
A
There
are
final
editorial
nits
in
progress
and
the
shepard
write-up
is
in
progress.
The
shepherd
jim
just
sent
an
email
saying
guys
have
all
the
open-ish
comments
that
were
made
been
addressed
because
that's
the
requirement
everything
has
to
get
addressed,
not
necessarily
agreed
to
but
addressed.
We
don't
ignore
comments.
A
We
have
submitted
to
the
isg
spring
segment
routing
policy.
Rad
martin
is
handling
that.
A
To
answer
srihari's
point:
no,
the
question
at
this
stage:
there
are
different
issues.
There
are
multiple
different
issues
at
this
stage.
The
question
for
spring
is
not
whether
six
man
has
blessed
the
relationship,
but
rather
whether
they
have
a
document
that
addresses
the
relationship.
A
What
will
happen
later
is
up
to
six
man,
but
there
is
a
coupling,
as
noted
in
the
open
issues
in
the
adoption
call
when
we
get
to
last
call.
We
have
to
know
what
the
relationship
is
and
what
happens
exactly
depends
on
exactly
what
six
man
says
about
the
relationship,
but
I'm
not
going
to
prejudge
that.
As
eric
pointed
out
in
the
chat,
six
man
has
picked
a
lead
author.
A
A
B
Hi,
joel
hi
everyone
good
morning
good
afternoon.
Thank
you.
A
B
Thanks
joel
hi
everyone,
my
name
is
rakes
gandhi
and
I'm
presenting
the
enhanced
srpm
draft
on
behalf
of
my
co-authors
listed
here.
B
So
the
agenda
is
we'll
look
at
the
requirements
and
the
scope
of
the
draft
history
and
summary
and
the
next
steps,
so
the
basic
requirement
is
to
for
the
performance
measurement
in
sr
networks
for
end-to-end
sr
paths,
it's
applicable
to
both
sr
and
pls
and
srv6
data
planes.
B
B
B
So
the
history
of
the
draft
is
this:
draft
was
initially
published
a
year
and
a
half
ago.
It
has
gone
through
multiple
revisions
and
they
were
presented
in
mpls
and
spring
working
group
sessions.
So
they
were
very
good
feedbacks
received
from
the
working
group
and
the
latest
draft
we
believe,
addresses
them.
B
So
in
the
spring
srpm
stamp
draft,
there
is
look
back
more
defined
for
sr
policy
where
the
packets
are
transmitted
for
each
segment
list
of
the
sr
policy
and
what's
new
here
is
the
the
session
reflector
forwards
them
just
like
data
traffic
without
punting
them
to
control,
plane
and
processing
them.
So
it's
kind
of
it's
agnostic
to
the
protocol
machinery,
and
this
is
what
allows
to
achieve
the
higher
skill
and
faster
intervals
for
any
violations.
B
So
in
in
the
in
the
existing
working
group
document,
we
can
measure
the
round
trip
delay
only
so
in
the
enhanced
mode.
That's
using
the
network
programming
function,
it
optimizes
the
the
operations,
but
at
the
same
time
timestamp
is
added
in
the
packet,
so
at
a
particular
location,
using
network
phone
network
programming
function
for
srm,
pls
and
srv6,
it
adds
the
received
timestamps
and
forwards
the
packet
just
like
data
packet.
So
this
allows
us
to
measure
one-way
delay
for
the
end-to-end
part.
B
B
That
will
come
with
its
offset
in
the
stamp,
which
is
a
16
and
32
bit
in
the
different
modes
of
the
packet
format,
and
that's
basically
it.
I.
A
D
Yes,
thank
you
rakesh,
so
you're
saying
that
this
method
enables
a
one-way
measurement.
That's
right.
At
the
same
time,
you
are
saying
that
the
reflector
doesn't
have
a
state
and
the
packet
does
not
leave
the
data
plane.
B
D
So
how
you
can
do
that
if
the
format
of
the
reflected
packet
is
different
from
the
format
of
their
received
packet
from
the
sender,
so
they're
very
different,
and
you
cannot
really
just
take
a
packet
and
swap
their
destination
and
source
address
more.
So,
if
you
are,
don't
have
a
state
in
the
reflector
what
you
are
measuring.
You
are
not
measuring
one
way
you
are
measuring
round.
E
D
And
because
you
are
traversing
one
way
or
downstream
their
segment
tunnel
and
the
upstream
I
don't
know,
I
can
assume
it's
a
p
network,
so
they're
divided
by
two,
the
round
trip
time
might
be
not
characteristic,
not
accurate.
So
I
think
that
there
is
some
serious
problem
with
this.
B
B
So
if
you,
if
you
can
have
a
look
at
this
working
group
document,
please-
and
let
us
know
if
you
have
additional
comments,
but
this
that
so
that
is
for
the
round
trip
delay
and
the
this
is
an
optimization
where
the
session
reflector,
using
the
network
programming
function
as
the
receiver
timestamp
and
forwards
the
packet.
So
the
packet
processing
is
also
explained
in
the
enhanced
loopback
mode
draft
on
how
it
works.
So
if
you
could
have
a
look
at
that-
and
let
us
know
your
comments,
would
you
appreciate
it.
D
Yeah
I
had,
and
I
I
sent
the
comment
before
the
meeting
so
again.
I
I
see
that
there
is
a
contradiction
between
the
statements,
because
their
segment
routing
programming
has
nothing
to
do
or
does
not
introduce
any
special
mode
in
the
stamp
so
to
do.
Processing
of
stem
packets
in
a
real
one-way
measurement,
reflector
has
to
be
stateful.
D
So
encapsulation
of
their
underlay
of
the
network
is
really
not
relevant.
D
It-
and
that
is
okay-
I
I
apologize.
I
just
will
leave
with
this
okay,
so
we
can
continue
on
the
mainland
list.
Thank
you.
B
Yeah
thanks
sir,
I
I
haven't
seen
your
latest
email
if
you
just
sent
it,
but
I
will
reply
to
it
so
stamp
test
packets
are
shown
here,
and
the
idea
is
that
the
sender
sends
the
transmit
timestamp
t1
in
the
session
sender
packet
and
the
reflector
adds
the
received
timestamp
d2
at
offset
16
in
an
authenticated
mode
and
offset
32
in
the
authenticator
mode.
So
these
are
a
well
defined
locations
in
the
stamp
packets.
This
is
motivation
for
using
stamp
as
well.
B
And,
and
that
is
for
sr
mpls
timestamp
mpls
label
is
defined.
This
is
network
programming
function,
which
will
cause
the
reflected
node
to
do
the
adding
of
the
timestamp
and
forward
the
packet.
B
It
will
cause
the
reflector
to
add
timestamp
label,
2,
sorry,
timestamp,
2
and
forward
the
packet
back
to
the
sender
in
case
of
srv6.
There
are
two
new
and
functions
defined
for
the
two
different
offsets
idea
is
very
similar,
where
timestamp
two
will
be
added
by
the
reflector
and
the
reverse
part
can
be
ip
or
srv6
and
similar
way
entire.
B
The
seedless
is
carried.
If
reverse
path
is
srv6
in
sanity,
the
the
notifications
are,
the
thresholds
are
provisioned,
so
what
we
are
measuring
one-way
delay.
So
our
threshold
is
configured
and
notification
is
generally
generated
when
the
threshold
is
caused
same
way
for
the
synthetic
packet
loss
session
state
is.
This
is
mentioned
in
the
existing
working
of
document
where
the
state
up
or
down
is
declared
based
on
if
packet
is
being
received
or
not.
B
So
welcome
your
comments
and
suggestions.
Many
thanks
for
the
great
discussions
on
the
srpm
drop
during
the
working
group,
adoption
and
looking
forward
to
your
comments
on
this
draft
as
well,
and
we
are
requesting
a
spring
working
group
adoption
for
this
draft
as
well,
and
many
thanks.
A
F
Sorry,
I'm
curious
as
to
how
you
avoid
the
ecmp
issue
with
this.
That
ecmp
will
give
you
a
different
answer
when
you,
when
you
run
this,
is
this
ecmp
safe?
Is
it
for
mpls.
B
Yes,
so
I
mean
for
ecmp:
there
are
standard
techniques
of,
for
example,
using
the
entropy
label
so.
F
B
Yes,
yeah,
we
can
add
that
test
to
you.
No.
F
It
has
to
be,
it
has
to
be.
You
know,
high
level
required,
because
people
will
get
the
wrong
answer
and
we
can't
publish
a
document
where
people
get
the
wrong
answer.
E
Oh
thanks
just
a
quick
question:
I
noticed
that
in
the
case
of
the
ip
side
you
are
setting
the
session
sender
sets
the
destination
equal
address
equal
to
the
session
sender,
address,
etc
effectively,
that
they're
going
out
reversed
lying
on
the
labels.
If
I'm
reading
this
correctly
to
get
to
the
other
post
now,
my
question
on
this
would
be:
what
is
what
is
the
impact
on
stuff
like
ecp38,
on
a
network
that
is
running
multiple
asms
et
cetera?
That
is
actually
protecting
against?
E
B
Yeah
thanks
andrew
for
the
question
so
yeah,
if
that
is
not
suitable
for
the
network,
so
the
second
method,
which
is
a
reverse
path,
can
be
srm
pls,
so
the
node
seed
or
the
entire
label
stack
can
be
used
to
bring
the
packet
back
to
the
center,
so
both
methods
are
defined
and
depending
on
the
the
deployment
or
what
is
the,
what
is
being
used
in
the
network?
One
of
them
can
be
selected
again.
B
This
is
this
has
been
around
many
rfcs
use,
swapping
of
the
source
addresses
already,
and
it's
also
no
different
here.
A
A
G
G
G
G
G
G
G
G
We
have
we
have.
We
have
talked
about
this
on
the
on
the
last
slide.
G
There
are
some.
There
are
some.
There
are
some
a
few
suit
code
for
the
for
the
for,
for
these
and
for
these
functions.
G
H
H
Okay,
yeah,
if
there
is
difficulty
in
going
to
slide
3
I'll,
just
go
ahead
and
state
my
question,
so
we
do
have
a
working
group
adopted
framework
document
and
piece
like
a
pointer
drought
for
what
we
call
ietf
network
slices.
So,
though,
the
original
interest
from
the
working
group
participants
was
largely
with
respect
to
how
the
idf
network
slice
can
cater
to
what
the
industry
refers
to.
H
As
transport
pricing,
there
hasn't
really
been
any
conscious
attempt,
either
by
the
authors
or
the
working
group,
to
limit
the
scope
of
that
construct.
So
I
don't
quite
get
the
idea
of
it
of
having
a
separate,
end-to-end
slicing
framework
document.
So
if,
if
all
that
this
document
is
talking
about
is
about
how
you
can
go
ahead
and
stitch
multiple
vtns
together,
I
would
limit
the
scope
of
this
document
to
that
and
talk
in
terms
of
stitching
vtns
together.
Instead
of
putting
this
under
the
edges
of
something
like
a
end-to-end
slicing.
I
I
I
just
want
to
help
to
reply
to
parents
comments
on
the
entrance
live
framework
craft,
actually
that
one
will
be
presented
tomorrow
in
the
t
session,
and
this
document
is
made
about
the
segment
routine
based
extension,
to
solve
this
multi-domain
mapping
and
the
concatenation
issue.
We
want
to
solve.
Okay,
we
can
discuss
further
about
the
engine
slicing
framework
in
the
this
meeting.
J
Okay,
adrian,
thank
you
joel.
I
is
speaking
as
the
editor
of
the
tease
network
slicing
framework,
which
is
intended
to
be
sort
of
all
embracing
for
ietf
network
slices.
J
I
want
to
caution
the
authors
here
to
be
very
careful
about
the
term
end
to
end,
because
the
the
concept
of
an
end-to-end
network
slice
has
already
been
used
by
3gpp
to
mean
something
much
broader,
of
which
an
ietf
technology
network
slice
would
form
only
part,
so
I
think,
take
a
little
bit
of
care,
especially
as
well
that
that
the
concept
of
end
has
has
a
a
strange
meaning
in
in
ietf.
J
So
maybe
step
back
from
that
headline
title
of
end-to-end
ietf
network
slice
and
talk
more
about
what
it
is
you're
you're
achieving,
rather
than
getting
hooked
on
that
terminology.
A
I
believe
you're
next
and
I'm
sorry
if
I'm
mispronouncing
names
yeah
there,
so
you
should
try
to.
You,
should
click
the
share
button
and
then
I
will
give
you
permission
to
do
so.
K
Hello,
everyone-
I
am
salih
from
juniper
networks.
Today
I
am
presenting
srv6
interdomain
mapping
suits
on
behalf
of
my
co-authors,.
K
So
this
draft
introduces
three
new
srv6
ncb
endpoint
behaviors,
namely
n
dot,
replace
android,
replace
b6
and
n.d
b6.
These
seeds
helps
in
building
srv
six
paths
spanning
multiple
srv6
domain,
so
we
will
get
a
services
continue
service
continuity
over
multiple
services,
transport
domains.
Each
domain
can
have
its
own
t
mechanisms,
so
this
among
the
three
slides,
the
n
dot,
replace
and
android
replace
b6
seats
helps
in
transporting
their
working.
So
these
seats
also
helps
when
there
are
multiple
intent
based
paths
present
in
the
network.
K
So
in
such
scenarios,
also,
this
mechanism
can
help
in
getting
easy
stitching.
That
means
it
can
work
with
the
procedures
mentioned
under
bgp
class
for
transport
or
similar
mechanisms
for
getting
multiple,
end-to-end
intent,
based
paths
across
the
network,
so
the
last
db6
it
helps
in
service
in
the
working.
K
So
now
we
will
look
at
the
two
use
cases.
The
first
use
case
is
for
the
transport
in
the
working,
so
this
this
use
case
is
from
the
seamless
sr
draft.
So
basically
the
figure
shows
three
different
asses.
S1,
as2
and
s3.
The
spr1
to
spr8
are
border
nodes
between
the
ss.
A
given
asp
runs.
K
The
bgp
session,
with
the
asps
in
the
descent
asses
the
asp,
also
runs
ibgp
sessions
with
other
aspires
in
the
same
as
rs,
can
also
be
used
to
achieve
the
full
measure
5bgp
requirement,
so
instead
of
ibgp
or
ebgp.
This
can
also
be
replaced
with
the
intent
based
bgpct
or
similar
mechanisms,
so
these
seats
actually
helps
in
replacing
the
destination
address
in
the
up
incoming
packet.
One
thing
to
notice:
there
is
no
segment
list
change
with
respect
to
these
two
seats.
K
The
next
slide
yeah,
so
the
processing
of
android
replace.
So
this
actually
replaces
the
destination
address
with
the
new
seat
and
forward
the
packet
on
an
outgoing
interface.
So
this
idea
is
similar
to
the
swap
operation
on
an
mpls
data
plane.
There
is
no
segment
list,
change
segment,
left
change
and
it
cannot
be
the
last
seed
for
the
in
the
srh.
K
The
procedure
is
mentioned
in
the
draft
when
srh
is
processed.
After
doing
the
initial
checks,
decrement
ipv6
op
limit
by
one
update,
ipv6
destination,
address
with
the
new
destination
address,
mapped
with
the
n
dot,
replace
it
to
submit
the
packet
to
the
ipv6
module
for
transmission
to
the
new
destination
via
the
member
of
j,
where
it
belongs
to
one
of
the
one
or
more
of
the
adjacencies
of
pgp.
K
So
one
thumb
rule
is
for
a
route
if
the
bgp
next
stop
is
one
hope
away,
then,
while
advertising
we
we
use
and
dot,
replace
it
the
a
detailed
procedure.
Probably
we
will
update
in
the
next
version
of
the
draft
with
an
example
so
endor
as
an
exit
is
n
dot,
replace
b6.
K
So
this
is
where
the
apart
from
replacing
the
destination
address
with
the
new
state,
it
will
also
add
an
additional
srv6
header,
so
this
is
similar
to
swap
and
push
on
the
mpls
data
plane
here
also,
there
is
no
segment
left
change
and
it
cannot
be
the
last
in
the
srh
for
a
route.
If
the
next
stop
is
multihope
aware,
then,
while
advertising,
we
pick
n
dot,
replace
b6
seed.
K
As
mentioned
the
in
the
draft
when
an
src
is
processed
after
the
initial
checks,
decrement
ipv6
hop
limit
by
one
update,
ibv6
destination
address
with
the
new
destination
address,
mapped
with
10
dot,
replace
b6
push
an
ipv6
header
with
the
sr
set
outer
ipv6
source
address
equal
to
the
source
address
the
address
of
the
border.
Node
set
the
outer
payload
length
traffic
class,
hop
limit
and
power
label
fields
set.
The
outer
next
up
header
value,
submit
the
packet
to
ipv6
module
for
transmission
to
the
faucet.
K
Yeah,
so
the
second
use
case
is
for
the
service
interworking.
So
here
there
are
two
srv6
domain,
as1
and
as2.
The
services
are
running
between
pe
one
and
pe
two
in
option
b
state.
So
the
abs
can
also
be
rs,
so
there
are
no
vr
configs
at
the
abr
or
errors.
The
self
next
stop
is
configured
at
the
rrs.
K
The
requirement
here
is
to
avoid
service
route
lookup
on
abr1
and
abr2,
to
provide
an
option
b
style,
end-to-end
connectivity,
the
at
rr.
We
we
decapilate
the
received
srv6
header
and
encapsulate
the
new
srv6
header
with
source
address
same
as
the
rr.
K
So,
like
mentioned,
like
this
sid
recapsulate,
the
receiver
received
a
srv6
header
and
encapsulate
a
new
srv6
header
when
an
sr
the
procedure
is
mentioned
in
the
draft
like
when
an
srg
is
received
after
the
checks
remove
the
outer
ipv6
header,
with
all
its
extension
headers
push
the
new
ipv6
header,
with
the
srv6
seats
associated
with
the
android
db60
in
nsrg,
set
out
our
ipv6sa
equal
to
the
tv
and
our
ipv6
destination,
address
to
the
first
set
in
the
segment
list
set
of
outer
payload
line
traffic
class
hop
limit,
employable
fields
set.
K
L
Okay,
this
is
from
huawei,
so
my
understanding,
the
under
replace,
is
as
similar
as
the
mapping
the
swap
function
of
mpis,
but
I'm
a
because
I'm
not
sure
my
understanding
is
right
or
not
because
in
the
srv6
I
don't
think
we
need
not
the
swept,
because
this
is
the
segment
at
least
when
we
calculate
this,
the
ingress
node.
So
that's,
there's
not
necessary.
It
was.
The
web
has
a
segment
in
the
midpoint,
so
why
we
introduce
this
the
under
replace
function
for
the
sale.
K
Yeah,
okay,
so
basically
there
are
different
mechanisms
for
multiple
domain.
When
there
are
multiple
domains
involved
like
the
ingress
itself
is
computing,
the
full
path
or
the
pc
is
involved.
So
this
mechanism
is
where
the
bgp
is
involved
for
stitching
the
end-to-end
path.
These
domains
are
heterogeneous
and
there
is
actually
on
the
borders
there
itself.
The
the
protocol
reachability
is
not
leaked
or
not
land
by
the
ingress
pe
one,
it
is
actually
switched
automatically
by
vgp.
So
this
is
for
option
c
connectivity
across
multiple
domains.
M
Katan,
my
question
was
on
the
n
dot
db6,
sorry
on
the
pseudo
code-
for
that,
so
this
is
was
a
service
kind
of
a
mapping
right
so
binding.
M
K
Yeah,
so
this
is
per
prefix
kitten,
pepper
fix
at
least
yeah,
so
the
mechanism
is
mainly
the
service
prefix
advertisement.
This
is
option
b,
so
the
rr
scan
also
will
have
service
for
every
prefix.
This
will
be
looked
up.
M
O
O
Like
you
said,
it's
used
for
adjusting
achieving
the
option
c
and
I'd
like
to
see
the
text
is
explicitly
in
the
draft,
and
the
second
question
is
that
when
the
seed
list
contains
only
one
single
seed
in
like
abiding
seed
n,
dot
b6
as
defined
it
in
the
I've
seen
18
9
86,
what's
the
difference
between
the
like
end
b6
and
the
end
rep
play
six,
I
can
see
the
action
is
the
same.
K
Yeah
yeah,
so
the
first
one
the
option
see
how
the
procedure
works
with
an
example.
Probably
we
will
update
in
the
subsequent
version
of
the
draft,
the
second
one,
as
I
mentioned
it,
is
based
on
when
you
start
advertising.
We
look
at
the
bgp
next
up
from
where
this
bgp
protocol
next
stop.
Reachability
is
land.
So
if
it
is
only
one
hope
away,
we
advertise
the
replace
if
it
is,
if
it
is
not.
If
there
are
multiple
seats
to
reach
the
other
domain,
then
yeah
we
will.
K
We
will
do
an
additional
encapsulation
b6
but
yeah,
depending
on
the
network
and
where
the,
where,
where
this
is
getting
stitched
to
one
of
them,
will
be
picked
like
based
on
the
situation
or
that
characteristics
of
that
particular
board
or
not
yeah.
Probably
we
will
update
with
an
example,
so
that
will
be
more
clear
in
the
trap.
O
L
Okay,
okay,
okay,
thanks
joy,
come
here
again,
sorry,
I
I
quick.
I
am
still
using
fields
about
this.
The
purpose
of
this,
this
type
of
oversight
seed,
because
you
know
the
srv6.
L
The
major
advantage
of
srv6
can
still
use
the
ipv6
forwarding
to
transverse
the
different
domains,
but
for
mprs
it
has
to
keep
the
huge
number
of
these.
The
forwarding
entries
for
the
mapping
between
the
between
the
labels,
so
that's
the
for
the
ip
for
the
srv6,
so
we
can
use
the
ipv6
and
ipv6
can
also
use
aggregate
to
reduce
the
forwarding
entries.
So
I
mean
this
is
the
advantage
of
srv6,
but
if
we
introduce
this
map
and
see
the
in
the
srv6
select
the
srprs,
I
think
this
is
just
reduce
the
advantage
of
srv6.
K
Yeah,
let
me
answer
it
yeah.
So,
as
I
mentioned
like,
there
are
different
scenarios
like
like,
as
you
mentioned,
if
everybody
even
network
is
properly
numbered
and
everybody
has
a
similar
mechanism
and
everything
kind
of
a
fresh
deployment,
then
you
have
you
can
even
leak
srv6
locators
across
domains
and
you
can
get
the
protocol
next
up
reachability.
But
this
is
a
scenario
where
there
are
multiple
heterogeneous
srv6
domains
and
they
have
planned
to
work
together.
So
there
is
already
option
c.
K
The
seamless
sr
trap
talk
about
that
particular
use
case
so
and
also
there
could
be
multiple
srv6
intent.
Paths
like
the
bgbct
or
bgp
car,
so
there
also
automatic
stitching
has
to
happen
at
the
border,
so
it
is
for
a
different
use
case,
but
I
think
it's
all.
All
these
different
mechanisms
are
really
required
for
different
kind
of
deployment.
P
Yeah
yeah
first
thanks
for
work
to
publish
this,
and
I
know
it's
a
revision
zero.
So
I
don't
expect
you
to
answer
this
now,
but
maybe
in
a
future
revision
of
the
draft,
it
would
be
interesting
to
see
how
an
sr
source
selects
one
of
these
behavior
when
it
builds
its
path
versus
versus
another
behavior.
P
Just
to
see
the
cases
where
these
sids
behaviors
are
used
or
not
used,
or
one
of
them
is
used
instead
of
another.
That
would
be
an
interesting
illustration
to
see.
N
K
Q
A
K
A
A
A
R
Ahead:
okay,
okay,
yeah,
hello,
everybody:
this
is
an
update
about
the
srh
encapsulation
for
afternoon
marketing
method;
okay,
just
a
quick
recap
about
what
is
the
alternate
marking
methodology?
I
guess
most
of
you
are
familiar
with
this
methodology.
R
R
R
R
K
K
R
Just
the
the
format,
the
of
the
search,
the
sh
tlv,
is
the
same
as
we
already
defined
for
fpv6.
So
there
is
no
difference
between
this
tlv
and
the
tlb
that
we
encoded
in
as
our
biop
or
destination
option.
So
there
are
two
bits
that
are
the
marking
beats.
There
is
the
flow
monitor
identification
that
is
required
to
reduce
the
per
node
configuration
to
simplify
the
counter
sampling
and
also
to
facilitate
the
correlation,
the
data,
export
and
so
on.
R
R
Regarding
the
usage
of
these
tlv
is
all
also
in
this
case
the
application
is
the
same
as
we
have
for
fpv6,
so
the
ingress
node
as
a
part
of
the
srh
encapsulate
the
acceleration
calculation
may
add
dtlv.
If
it
supports
the
alternate
marking
functionality
regarding
the
intermediate
sr,
node
or
egress
node.
R
R
Otherwise,
if
the
intermediate
or
egress
node
are
not
capable
of
processing
this
lv,
this
is
not
a
big
big
problem,
because,
if
nodes
are
not
capable
of
processing
utlev,
of
course,
the
measurement
can
be
done
only
for
the
supporting
nodes.
So
this
is
one
of
the
let's
say
the
advantages
of
the
alternate
marking,
because
you
don't
have
so
the
intermediate
node
and
ending
node
do
not
have
to
write
the
option:
the
tlb
yeah.
In
this
slide,
we
are
going
to
explain
better
the
motivation
why
we
need
to
define
the
search?
R
R
R
Indeed,
in
case
of
srh
alternate
marking
could
be
applied
through
the
this
tlb,
the
srh3,
but
for
all
the
other
cases
with
the
pv6
data
plane
usable
by
open
destination.
Upward
distribution
option
is,
of
course,
the
only
choice
to
carry
alternate
marking
information
and
in
the
end
there
is
no
other
difference
so
because
the
tlb
is
always
exactly
the
same.
R
Another
point
that
we
can
consider
that,
considering
that
we
have
a
compression
desire
design
as
an
ssh
compression
design
team
that
is
working
on
the
optimization
solution
for
srv6
sc
seed
compression
and
srh
implementation.
This
also
could
also
benefit
use
of
srhlv,
but
it's
just
an
hypothesis,
so
maybe
the
last.
The
the
last
slide
is
about
the
next
step.
S
S
R
B
R
R
Because
it's
just
to
leverage
the
this
capability
of
srh
to
to
be
extended
to
tlv
and
understand
your
point,
but
the
solution
for
for
all
the
rooting
header
is
already
in
the
six-man
draft
right,
because
here
you.
R
We
are
defining
the
the
destination
option-
header
that,
of
course,
can
be
applicable
to
all
the
routing
gather,
so
this
is
only
for
the
srh
since
with
srh,
we
have
this
the
possibility
to
use
this
kind
of
tlv,
this
kind
of
extension.
S
A
A
A
A
Why
don't
you
stop
and
restart?
And
let's
see
what
happens?
K
T
Okay,
okay,
thank
you
yeah,
so
I
guess
I
can.
Oh,
I
can
move
the
slides
this
way.
I
was
wondering
how
they
move
the
slides
okay
yeah
good
morning,
everyone,
my
name,
is
sami
wutrus
and
I
I'm
gonna
be
presenting
on
behalf
of
the
officers
here
of
the
draft.
T
You
know
they
use
how.
How
can
we
use
segment,
routing
concepts
applied
to
the
service
control
plane,
and
this
draft
is
focusing
initially
on
elan
service.
That's
ethernet,
an
ethernet
service
in
alan
involved.
T
So
so
so
what
does
it
mean
to
apply
the
segment
routing
concept
to
services?
Here
you
know
it's
not
new,
that
segment
routing
define
an
srgb
for
service
as
well.
This
could
have
global
significance
across
the
networks
who
are
saying
the
srgb
concept
for
services
can
be
used
here,
which
means
that
every
service
globally
in
a
given
domain
will
have
a
unique
index
right
in
that
domain.
T
So
it
will
point
a
unique
label
within
this
srgb.
So,
for
example,
if
in
a
given
domain,
we
are
numbering
the
services
for
elan
here,
then
a
service
number
65
could
have
a
service
index
65
on
all
provider,
routers
or
provider
edge
routers,
providing
that
service.
T
So
so
I
think
the
key
here
is
that
we
are
talking
about.
You
know,
segment
routing
came
with,
of
course,
a
few
concepts
here
and
the
goal
was
simplicity,
meaning
you
know
they
brought
in
the
concept
of
simplifying
the
network.
You
know
this
is
what
sigma
routing
is
about
so
and,
and
they
did
a
great
job
in
the
underlay
by
eliminating
protocols
like
ldp,
for
example,
in
the
underlay,
the
srgb
concept,
globalizing
the
label
space
across
the
network.
T
So
all
those
concepts
have
been
applied
to
the
underlay
and
simplifies
the
underlay
control
plane
greatly
and
the
question
here:
can
we
use
that
as
well
to
simplify
the
control
plane
for
the
service?
And
we
are
talking
about
elan,
for
example,
here
so
going
to
the
next
slide?
T
So
so
here
we
are
just
comparing
or
going
back
to
history
here
and
looking
at
sudowar.
That
was
a
building
block
for
elan
services
when
applied
to
you
know
to
a
service
provider
network.
T
T
Those
two
pieces
are
important,
especially
if
you
are
going
to
be
doing
data
clean
learning
over
a
sudoa.
So
you
know
the
node
that
hosts
the
sudoa
here
need
to
know
from
where
the
packets
are
coming.
So
the
endpoint
is
important
and
as
well
need
to
know
what
service
is
in
question
here,
to
be
able
to
use
a
proper
data,
plane
mclean,
but
this
combining
those
two
piece
of
information
in
one
context
led
to
a
skill
issue.
T
So,
for
example,
if
you
have
ten
thousand
services
I
configured
on
a
hundred
node,
then
each
node
would
need
to
maintain
one
million
sudwar
context
or
one
million
service
id
for
those
for
all
the
end
points
in
all
10
000
servers
as
well.
Sudowar
really
didn't
support
like
legacy
layer,
two
network,
any
active,
active
redundancy.
T
So
what
we
are
proposing
here,
you
know
as
a
way
to
improve
the
scale
for
that
old
technology
or
or
previous
technology,
is
to
split
the
two
pieces
of
information
into
two
contexts:
one
presenting
the
service-
and
here
we
are
talking
more
about
data
plane,
one
presenting
the
service
and
one
presenting
the
endpoint.
T
So
so,
if
you
imagine
and
we'll
go
more
in
details
in
the
next
slides
that
we
split
those
two
pieces
of
information
into
two
sets
in
a
set
list
where
one
will
present
from
where
the
packet
is
coming,
presents
the
end
point
and
one
presents
service,
then
your
skill
will
look
quite
different
right.
You
would
have
you
know
only
10
000
sets
to
present
services
and
the
end
point
givens,
that's
encoded!
T
Underneath
the
service
in
a
header,
then
you
know
you
won't,
have
a
sk,
the
same
skill
problems
that
you
have
with
sudoa
as
well.
If
we
leverage
more
of
the
segment
routing,
you
know
concepts
here,
especially
as
any
cast
said
we
can
introduce
the
active
active
redundancy
to
that
layer
to
world
or
that
service
itself.
T
So
this
is
an
illustration
on
how
we
can
achieve
that
as
well
in
control
plane.
So
so
we
are
talking
about
you
know.
How
are
we
gonna
be
in
a
given
domain
inside
service
provider
network?
You
know,
learn
dynamically
about
what
services
are
configured
where
right.
So
what
we
are
proposing
here
is
that
if
each
node
would
advertise
to
all
other
nodes,
the
services
configured
wiz
as
a
bit
mask
of
all
the
said,
offsets.
Let's
say
that
it
is
configured
with.
T
Then
we
can
really
decrease
significantly
the
amount
of
signaling
in
the
network
compared
to
any
previous
technology,
because
if
you
imagine
the
10
000
service,
we
talked
about
in
the
example-
and
we
are
trying
to
advertise
your
service
across
the
network
and
each
service
is
presented
by
a
bit
in
a
signaling
message.
You
could
have
only
one
message:
one
control,
plane
message
by
which
one
node
can
teach
all
nodes
in
the
network
about
what
services
it's
configured
with.
T
So
you
know,
that's,
of
course,
a
significant
decrease
in
terms
of
number
of
control,
pane
messages
that
can
be
exchanged
so
are
talking
about.
You
know,
instead
of
a
millions
who
are
signaling
done
by
a
given
node.
T
It's
only
one
message,
that's
being
sent
so
so
one
message
compared
to
a
million
right
so
of
course
upon
receiving
that
message
that
being
sent
by
onenote
to
all
other
nodes
like,
as
shown
here
note
5,
for
example,
is
sending
what
service
is
configured
waste
to
all
other
nodes,
then
all
other
nodes
can
as
well
figure
out.
T
You
know
a
membership
of
nodes
in
a
given
service,
so
so,
typically
in
layer,
2
network,
you
need
to
know
what
are
the
members
that
you
know
that
correspond
to
the
service
for
function
like
flooding,
for
example,
because
layer
2
is
all
especially
with
data
plane.
Mclearning
is
all
about
flood
and
learn.
So
so,
when
you
flood,
you
need
to
know
who
are
the
members
of
a
given
layer,
2
service,
to
be
able
to
flood
unknown
unicast
or
broadcast
layer
2
packet
to
it.
T
So
so
now
you
can
learn
the
membership
by
simply
listening
figuring
out
from
the
message
cent
on
all
the
services.
With
one
control
plane
message:
you
can
figure
out
for
all
the
services.
What
are
the
membership?
You
know
when
you
receive
that
message
from
other
nodes,
for
example,.
T
So
the
broadcast
note
said
is:
is
you
know,
present
a
node
as
well
and
can
tell
the
node
that
the
received
packet
is
a
broadcast
pack,
meaning
it's
a
flooded
packet
rather
than
a
unicast
package.
The
mood
itself,
so
the
broadcast
note
set,
can
be
sought
as
as
well
a
note
said,
but
of
certain
nature
right:
okay,
you
know
that
will
tell
the
node
whether
it's
receiving
broadcast
back
it
or
not
right.
So
here
we
are
talking
initially.
T
T
T
You
know
the
context
of
what
we
call
the
sudwar
in
the
past,
presented
by
two
two
sets.
So
as
you
see
here,
we
have
a
service
set
and
then
underneath
that
we
can
have
what
we
call
a
source
set.
T
So
the
source
said
here
could
be
zenut
said
if
this
is
a
single
home,
for
example,
you
know
single
home
host
connected
to
the
provider
edge
or
could
be
in
any
case
said
if
this
is
a
multi-home
device
connected
to
the
provider
edge
for
which
you
are
providing,
of
course,
the
layer
two
serves.
T
So
if,
as
any
guest
said
here
is
used,
then
all
data
plane,
mac
learning
by
all
nodes
is
going
to
be
against
the
anycast
set.
So
any
return
traffic
toward
that
node.
T
The
provider
edges
from
which
we
learned
the
source
max,
for
example,
for
the
multi-home
service,
can
can
be
ecmp
or
multi-passed
here
to
the
devices
most
devices
shown
here
in
the
picture.
For
example,
five
and
six,
who
are
connected
to
the
multiple
servers
right,
so
so,
multi,
passing
and
and
even
aliasing
can
can
be
applied.
This
way
and
and
and
the
idea
here
is
any
cast-
is
already
available
in
segment
routing.
T
So
so
we
are
simply
using
what
what's
available
in
the
underlay
to
provide
the
redundancy
and
provides
the
ecmp
and
the
multi-passing
right
leah
as
well.
Is
you
know?
Is
it's
important
to
do
what
we
call
stuff
like
split
horizon?
So
if
a
packet
is
flooded,
for
example,
to
the
network
from
a
multi-home
device,
we
don't
want
to
create
a
loop.
T
So
so
we
need
to
make
sure
that
when
it
arrived
to
another
device
connected
to
the
same
multi-home
site
is
that
that
packet
will
not
be
looping
back
and
and
that
easily
as
well
can
be
done
because
a
note,
6,
co-share
or
co-own
any
cassettes.
So
it's
receiving
the
packet
source
from
anycast
said
it
will
know
how
to
do
the
proper
split
horizon
here.
You
know
this
is
going
more
into
some
more
details
about
data
plane,
mac
learning,
and
how
can
we
do
that?
T
How
can
we
learn
against
the
source
set?
For
you
know
the
mac
addresses
source
mac
received
in
data
traffic
from
single
home,
as
shown
here
from
note
3,
for
example,
or
even
from
multi-home
as
we're
showing
in
the
previous
slide.
T
So
so
that's
as
well
is
available
in
the
set
list
and
we
can
learn
easily
for
the
given
service
against
the
source
said
the
mac
addresses
you
know
for
a
given
service
so
going
to
the
next
slide.
T
I
mean
this
is
more
going
more
into
details
of
how
can
we
do
some
arp
suppression
and
in
here
we
are
talking
about
flooding
arc
replies
as
well,
so
all
nodes
can
learn,
as
I
p
mcbinding
yeah,
actually
maybe
a
little
history
about
arc
suppression
arc
suppression
is
calling
for.
You
know
decreasing
the
flooding
of
our
packet
across
the
network
and
the
way
to
do
that
is
by
doing
the
arc
suppression,
which
means
that
a
node
can
respond
to
an
arp
request.
T
You
know
on
behalf
of
the
destination,
so
so
here
the
pe
router
can
respond
to
an
arc
request
on
behalf
of
the
ultimate
destination
and
the
way
it
does
that
by
cleaning
our
requests
and
replies
to
know
about
the
ip
mag
binding
and
here,
of
course,
arp
requests
are
always
flooded,
but
our
replies
aren't
and-
and
in
here
we
are
saying-
if
you
floods
are
replies,
then
the
cleaning
of
ip
mining
can
happen
and
nodes
can
learn,
of
course,
about
that.
Here
again,
this
is
as
well.
T
A
very
important
point
that
that
we
will
mention
here
quickly
is
is
the
idea
of
convergence,
and
you
know
if,
for
example,
here
we
have
note
5
and
note
6
connected
to
the
multi-home
device
and
if
one
of
the
nodes
lose
connectivity
to
that
multi-home
device,
what
we
can
do
so,
as
as
you
mentioned,
we
are
using
an
anycast
said,
and
maybe
I
should
stress
on
that
point
as
well.
T
More
pair
ethernet
segment
or
paired
multi
homies,
and
that's
it
so
if
one
node
attached
to
the
multi-homies
on
that
segment,
lose
connectivity
to
that
multi-home
eastern
that
segment,
then
it
can
withdraw.
T
Okay,
as
any
cast
said
associated
with
that
segment,
and
doing
that
withdrawal
in
the
underlay
network
will
simply
give
us
the
conversions
right.
So
we
we
really
don't
need
to
do
much
more
right.
I
think
what's
presented
here,
is
in
the
entrance
before
withdrawing.
If
note,
5
would
detect
that
the
length
you
know
or
the
interface
connected,
the
multi-home
segment
is
or
multi-home
device.
Of
course
right
is
down.
T
Then
it
can,
in
the
interim,
redirect
packet
to
other
nodes
connected
to
that
multi-home
device
until
the
network
converge
and
and
and
and
things
going
back
again
right.
R
S
T
I'm
concluding
I'm
concluding
so.
Finally,
the
two
takeaways
that
you
want
to
take
from
this
is
the
easter
two
service
we
are
talking
about
presenting
it
by
global,
said
in
each
domain
and
that
will
decrease
massively.
T
You
know
the
number
of
state
we
can
keep
in
data
plane
and
will
decrease
drastically,
as
well
as
a
control,
plane,
signaling
needed
and
the
other
takeaway,
which
is
extremely,
is
as
important
is.
There
is
no
need
really
for
doing
any
service
convergence
right.
You
know,
like
typically
as
overlay
layer.
We
always
talk
about
conversions,
overlay,
converging
overlay
and
defining
mechanism
for
convergence
overlay
by
the
use
of
any
gas
said
is
a
problem
become
an
underlay
convergence
and
there
is
no
need
to
do
any
overlay
conversions
right.
T
So
that's
a
key
takeaway.
Finally,
the
last
slide
is
talking
about
a
benefit
in
general.
You
can
go
over
it
as
the
slides
are
uploaded
and
the
draft
is
available
too,
and
with
that
I
can
conclude.
V
T
Yeah,
of
course,
of
course,
good
question
eric
yeah.
Definitely
you
know
the
use
of
network
function
and
srv6
is
is,
and
I
think
we,
the
purpose
eric
again,
is
just
to
introduce
the
concept
but,
of
course,
the
mechanics
and
the
the
more
details.
Even
the
signaling
aspect
will
come
later.
W
Yeah
hi
thanks,
thank
you
so
sami.
I
just
got
a
quick
question
about
the
relationship
of
this
draft
to
one
you've
had
in
bess
about
a
year
ago.
It
was
very
similar
and
so
yeah
sure
yeah
go
ahead.
Please
could
you
just
clarify
what
your
intention
is
with
the
best
draft,
because
I
would
have
thought
that
this
given
this
relates
to
bgp
signal
services
should
really
live
in,
invest.
T
Yeah
yeah,
definitely,
I
think
the
idea
here
matthew
is,
you
know
we
thought
that
the
concept
is
more
a
segment
routing
concept,
so
so
this
is
why
we
saw
that
the
concept
would
present
here
in
spring,
but
the
signaling
aspect
and
the
more
details
about
that
will
be
presented,
invest
for
sure
right.
So
so
so
we
will
update
the
best
draft
more
address
the
signaling
aspect
and
how
we
can
achieve
that.
And
here
we
discuss
most
architecture
in
the
concept.
W
T
A
T
T
T
X
Sorry,
hey
sami,
I
hope
you're
doing
well.
T
I
know
that
you're
doing
you're
right
you're
right
padres,
as
I
mentioned,
to
matthew.
You
know
there
is
no
difference
between
the
two
drafts,
but
but
the
plan
is
to
change
the
other
draft
to
more
address
the
signaling
aspect.
A
L
L
L
L
Okay,
this
is
jimmy
from
huawei
and
trend-based,
routine.
Okay,
here's
the
introduction,
in
fact
the
simplest,
I'm
sure
segment
routine,
described
the
requirement
for
end-to-end
intent-based
past
surveilling,
multiple
domain
networks.
L
In
order
to
implement
the
seamless
segment
routine.
The
sr
pass
needed
to
set
up
according
to
the
pair
a
color
and
the
point,
it
means
more
sr.
Paths
need
to
be
introduced
in
the
multiple
domain
in
the
multiple
domain,
so
this
means
that
not
only
to
set
up
sr
paths
for
the
poor
endpoint,
but
also
set
up
the
sr
paths
per
pair,
color
and
end
point.
L
L
Through
the
mechanism
the
intended
information
can
be
carried
in
the
data
plane
and
the
network
node
can
steer
the
package
into
the
sr
policy
to
satisfy
the
service
requirement,
so
this
means
need
in
order
to
set
up
the
under
to
underpass
sr
pass
prepare,
so
that's
not
only
to
the
severe
in
the
package
into
the
sr
policy.
L
According
to
the
intent-based
routine,
the
mechanism
can
also
be
used
to
steering
the
traffic
into
the
underlying
network
slicing
to
meet
the
specific
intent
and
also
enforce
the
policy
for
other
intent,
such
as
the
network
environment
and
their
security,
etc.
Okay,
next
slice,
okay,
so
here
this
is
the
first
page
of
the
introduction
about
intent-based
routine.
So
first,
this
is
the
true
concept:
that's
the
color!
So
there's
a
color
is
defined
in
the
segment
routine
policy.
So
that's
the
the
32-bit
numeric
value
that
associates
the
sr
policy
with
the
entrance.
L
L
So
there
can
be
the
mapping
between
the
entrance
and
the
color
in
the
in
the
node.
That
means
the
intent
x
can
be
mapped
to
the
color
y,
so
that
means
if
they
had
a
similar,
similar
entrant
information.
So
that
can
be.
This
is
the
mapping
besides,
this
is
the
mapping,
because
this,
the
intent
can
also
be
used
for
other
purposes,
such
as
the
network,
environment
and
the
secularity
etc,
because
the
color
is
always
associated
with
the
sr
policy
for
the
purpose
of
severing
traffic.
L
Okay,
so
here
are
these
examples,
so
that's
the
in
order
to
simplify
the
inter-domain
routine.
So
that's
in
one
local
domain,
so
there's
a
can
be
a
set
of
sr
policy
group
which
is
shown
in
the
figure
so
that
the
sr
policy
group
group
includes
the
mapping
between
colors
and
sr
policies
for
specific
and
the
point.
L
So
here
we
can
see
that
this
is
the
mapping
between
the
color
one
and
the
sr
policy
one
and
the
color
tool
for
the
sr
policy.
Two
for
the
specific
and
the
point,
because
this
is
the
sr
policy
group
can
be
set
up
and
there's
also
the
mapping
between
the
intense
intent
and
the
color.
So
when
the
packet
arrived
at
the
edge
of
the
network
domain,
so
that's
the
network
node
according
can
search
the
field.
L
I
can
search
this
the
sr
policy
using
the
destination
address
in
the
packet
so
then
find
the
sr
policy
group
go
on
to
use
the
intended
information
in
the
packet
to
map
to
the
corresponding
color,
then
corresponding
the
sr
policy
so
means
that
your
destination
and
the
intended
information
in
the
package
can
search
the
corresponding
sr
policy.
For
the
bracket
and
the
point
so
then
steering
the
traffic
to
the
sr
policy.
L
Okay,
so
the
color
mechanism
can
also
use
to
set
up
the
mapping
between
the
color
and
the
underlying
network
slice.
So
that's
a
we
used
as
the
color
can
use
to
further
unify
the
unified
mapping
process
of
traffic.
Steering
that
means
the
color
can
be
used
for
for
the
for
identified.
Sr
policy
can
also
use
to
identify
the
specific
underlay
network
slides.
L
So
when
the
packet
arrives
at
the
network
edge
node,
the
network
add
node
can
abstract
the
can
derive
the
intended
information
from
the
packet
and
according
to
the
mapping
between
the
yen
trend
and
the
color,
to
find
that
there
is
a
chorus
bound
in
the
color,
then
corresponding
the
underlying
network
slice.
C
L
We
have
this
the
advantage
of
availability,
because
this
mapping
between
the
entrance
and
the
sr
policy
can
be
done
locally
without
the
need
of
advantage,
the
label
binding
for
the
pair
color
and
the
point
to
stitch
the
sr
paths
spanning
multiple
domains
and
also
there's
the
flexibility,
because
the
same
intent
can
be
satisfied
by
the
sr
policy
or
the
underlying
network
slides.
L
So
the
local
network
domain
can
choose
different
solutions
to
satisfy
the
same
entrant.
That
means
in
one
for
the
same
intent
in
one
network
domain
can
use
the
sr
policy.
Another
network
domain
can
use
the
underlying
network
slides,
so
that's
used
for
the
under
to
end
traverse
the
package,
so
that's
the
kind
of
flexibility
to
choose
the
different
solutions
in
the
different
domain,
so
that
is
combined
together
to
satisfy
the
intent.
L
So
there
you
can
improve
the
flexibility
of
the
entrance
inter-domain
routine,
but
I
think
this
is
an
advantage,
because
now,
according
to
the
similes
sr,
it
can
always
use
either
in
order
to
satisfy
the
intent.
You'd
always
use
the
sr
pass.
It's
a
a
little
difficult
to
combine
the
sr
policy
and
the
underlying
network
slides,
okay
and
last
one.
L
That's
the
advantage
or
intensibility,
because
that's
besides
during
the
package
into
the
sr
policy
or
the
annual
network
slides
for
the
sre
guarantee,
the
network
node
can
also
enforce
the
policy
for
other
possible
intents,
such
as
the
network
amendment
and
the
security
and
other
possible
intent.
Okay,
last
slides.
L
Hello-
okay-
oh
sorry,
not
the
last
so
here
this
is
just
a
simple
euro
solution,
so
we
can
see
that's
the
vpnc
that
can
be
of
the
world
height
from
the
p1
to
the
csd1
and
also
the
sr
policy
group
can
be
set
up
in
the
as1
and
also
the
sr
policy
group
can
be
set
up
in
the
es2.
L
So
that's
the
packet
under
to
the
intel
domain
routine
can
be
illustrated.
So
that's
the
when
the
preload
to
arrive
so
that
the
entrance
can
be
carried
and
also
there's
the
vpnc
that
can
be
encapsulated
and
also
according
to
the
intention
information
can
map
to
the
corresponding
the
sr
policy
in
the
sr
policy
group.
So
that's
the
segment
list
for
the
sr
policies.
Credited
path
can
be
encapsulated
for
the
traffic
theory.
L
So
when
arrived
and
the
asbr
one
so
there's
a
user
package,
so
the
second
release
can
be
removed
can
use
the
vpn
seed
to
search
the
favor
and
transverse
the
package
from
the
asbr
one
to
the
asbr3.
L
L
Presentations.
Okay,
so
that's
done
so!
That's
you'll
find
the
sr
policy
in
the
as2
and
the
segment
list
be
encapsulated
who's
there
in
the
traffic
arrive
on
the
p1,
so
they
say
just
your
restoration,
okay,
next
slice,
okay,
so
the
this
is
the
next
step.
So
this
is
the
first
version
so
that
we
would
like
to
listen
to
the
comments
and
refine
the
draft
and
welcome
the
cooperation.
L
A
Y
Okay,
I
just
have
a
clarification
question,
so
is
that
intent
perform
the
similar
function
as
like
policy,
almost
like
a
qos
kind
of
function,
similar
to
qs,
in
a
way
that
you
can
steer
the
traffic,
give
another
layer
of
policy
matching
criteria?
Y
L
To
some
extent
you're
similar,
but
to
be
more
exactly
exact,
you
select
the
color.
That
means
the
entrance
such
as
this
low
latency
or
the
hypernoise.
L
Yeah
yeah,
you
suggested
some.
This
is
abstract
in
intent.
That's
not
a
detailed
service
requirement.
A
A
Z
Z
Z
Z
Z
In
this
case,
I'm
vpn
routing
and
the
corresponding
information
could
be
encapsulated
in
the
source
segment
carried
in
the
ipv6
source
address,
and
this
source
segment
for
mvpn
is
distributed
by
the
root
node
and
the
function
is
excluded
by
the
leaf
nodes
similar
as
the
group
of
n
dot
dt
functions
are
defined
in
rc
8986.
Z
Z
First,
the
thought
segment
is
unchanged
along
the
p2mp
path
compared
to
the
destination
address,
and
it
could
enhance
the
networking
capability
by
allowing
more
functions
in
the
source
space
and
also
the
cement
trick
of
source
address,
could
reuse
the
ipv6
address,
allocation
and
management
method,
or
it
can
have
a
similar
one
next
page,
please
what
is
the
next?
Z
Actually,
we
think
it
is
a
proper
time
to
raise
this
topic
in
spring,
because
this
question
of
seed
appeared
in
source
addressed
field
has
already
been
mentioned
during
the
discussion
of
services
compression,
and
we
believe
this
document
could
give
a
clear
concept
and
ends
a
valid
use
case
for
source
segment,
but
honestly
for
further
work.
We
believe
more
clarifications
will
be
helpful,
just
as
mentioned
in
the
request
of
the
ads
email.
Maybe
there
will
be
a
new
document
for
this,
especially
from
the
view
of
ipv6.
S
Yes,
what
happens
when
a
packet
has
a
sid
is
its
source
address
and
for
some
reason
it
can't
be
forwarded
and
the
node
that
cannot
forward.
It
sends
an
icmp
message
to
that
source
address.
Z
Z
A
U
A
comment:
this
concept
was
first
brought
up
in
the
beer
working
group
when
we
did
when
they
wanted
to
do
the
ipp.
Srv6
style
beer
for
mvpn.
U
There
were
a
lot
of
discussions
on
them
on
the
mailing
list,
mainly
from
me
on
on
the
issues
with
with
this
proposal,
I
think
we
should
re
revive
the
discussion
there.
Z
Actually,
I
think
this
this
is
not
for
beer
or
some
specific
mechanism.
This
can
be
used
for
any
ipv6
based
multicast
to
carry
mvpn,
and
we
also
discussed
this
in
the
section
6
of
the
document.
Maybe
you
can
review
it
and
thank
you
for
the
comments.
AA
Yeah
there
we
go
sure
very
okay.
Oh
this
idea
here
was
introduced
in
itf
111,
originally
targeted
for
industrial
networks,
and
so
this
came
out
of
the
question.
What
can
we
do
better
with
variable
length
addresses,
and
it
only
mentions
in
inside
how
it
would
be
beneficial
in
in
our
opinion,
for
current
service
provider
network?
AA
So
I
wanted
to
lay
this
out
as
something
which
I
think
at
the
core
could
really
help
spring
in
the
long
term,
because
I
think
we're
going
to
see
a
lot
more
customers
coming
into
you
know
our
service
provider
type
network
use
cases
without
20
years
of
v6
and
mpls
preferences
and
when
they're
looking
at
what
they
can
be
doing
with
spring.
I
think
one
of
the
most
obvious
feedbacks
would
be
so
why
is
itf
only
continuing
to
enhance
two
parallel
forwarding
planes
both
have
downsides?
AA
It
avoids
duplication
of
expertise,
development
software,
hardware,
deployment
and
the
limitations,
and
I
think
that's
really
you
know
one
of
the
core
questions
spring
should
ask
itself,
for
you
know
the
the
long
term
we
have
unified
as
our
architecture
as
much
as
possible,
but
we
do
not
have
a
forward
forwarding,
plane,
unification
right
and
obviously
the
current
working
group
structure
for
execution
isn't
suited
to
achieve
something
like
that,
because
we
only
have
working
groups
that
are
there
to
maintain
the
legacy,
and
you
know
just
imagine
how
quick
would
have
turned
out
it
would
have
been
put
into
the
tcpm
working
group
right
so
and
that
legacies
are
quite
different
from
the
operator
requirements
which
we
do
understand
thin
ways:
low
operational,
churn
complexity,
limitation,
yada
right.
AA
So
that's
basically
the
motivation
now,
obviously,
any
of
that
motivation
doesn't
help
if
we
don't
have
ideas
on
how
to
do
better
and
how
we
could
unify.
So
let
me
quickly
explain
how
I
think
all
the
things
we
are
doing
you
know
differently
in
mpls
and
srv6
could
be.
You
know
done
more
comprehensively
in
a
single,
flexible,
addressing
approach,
and
the
main
point
is
that
the
addresses
of
each
node
can
be
variable
length
and
no
address
can
be
a
prefix
of
another
so
that
you
do
own
all
the
suffixes.
AA
So,
for
example,
routers
one
and
two
here
on
the
picture
are
the
ones
most
often
used
as
edge
routers,
so
they
have
shorter
addresses
and
then
the
the
address
is
constructed.
As
a
sequence
of
you
know,
one
such
note,
prefix,
followed
by
a
sequence
of
commands,
zero
or
more
each
with
its.
You
know
optional
parameters
and
that
could
be
a
superset
of
the
existing
sr
commands.
AA
Let's
say
the
most
simple,
one,
obviously
being
something
like
receive,
which
could
be
the
value
four
four
four
bit
command
receive
into
a
vpn
which
might
be
of
a
parameter,
oem,
pund
and
so
on.
AA
So
how
then,
would
we
do
the
most
important
thing,
which
is
the
source?
Steering,
and
here
is
the
example
with
the
loose
steering
where
we
simply
have
a
sequence
of
the
node
prefixes.
Some
local
commands
here
for
the
first
node
command,
one
with
a
parameter
then
command.
Two
being
the
steer
parameter
and
with
respect
to
how
node
one
interprets
the
address.
Well,
it's
basically,
the
rest
of
the
address
is
just
the
parameter
to
the
steer
command.
AA
So
it
basically
takes
the
parameter,
looks
at
the
first
part
of
it,
which
is
the
next
hop
node,
and
then
it
passes
on
the
address
in
a
way
that
that
note
2
and
any
intermediate
hops
toward
it
would
start
interpreting
the
address
at
that
stage,
and
so
it
goes
on
and
as
you
can
see,
we
don't
mandate
additional
local
commands
on
the
notes
like
we
are
wasting
the
space
in
ssrh
and
but
we
can
very
easily
have
them
so
the
address
encoding.
AA
You
know
if
we
simply
strip
the
prefix
of
the
address
on
each
of
these
steering
hops.
We'll
basically
have
an
mpls
style
address,
handling
right,
we're
popping
things
from
the
beginning
of
the
address.
We
can
equally
do
the
srh.
K
AA
That
that's
a
decision
to
make
when
we
ever
get
to
an
encoding
of
this
by
simply
having
a
prefix
that
we
chain,
sorry
an
an
offset.
You
know,
address
interpretation
offset
that
we
progress
in
the
same
way
as
we
do
that
in
srh.
AA
Now
the
variable
length
introduces
some
new
challenges
to
whether
we
have
you
know
inconsistency
in
routing,
in
the
configuration
of
the
nodes
which
will
impact
the
decoding
which
so
far
in
srh
and
mpls
is
because
it's
fixed
size
not
happening,
and
we
can
also
easily
overcome
that
by
introducing
you
know
a
prefix
links,
argument
that
make
sure
that
whoever
is
you
know
generating
an
address.
AA
AA
The
very
same
elimination
of
new
challenges
with
variable
length
for
the
variable
length
addresses
can
can
also
be
done.
We
have
different
ways
on
how
we
can
you
know
manage
address
space
for
commands
so
far.
We've
typically
done
it
by
fixing
them
through
the
standard
which
gives
the
strongest
consistency.
AA
They
could
be
pre-configured
across
the
network,
which
is
fairly
strong
consistency
or
they
could
be
managed
by
the
igp
so
to
make
sure
that
we're
not
having
inconsistencies
across
them.
We
should
definitely
standardize
the
address
space
so
that
it
is
always
clear
on
what
address
what
length
and
whether
it
is
fixed
by
standard
pre-configured
or
dynamically
assigned.
AA
So
I
think
this
is
just
high
level
to
see
how
we
can
eliminate
the
new
consistency,
challenges
through
variable
length,
addresses,
and
that
basically
gets
us
to
you
know
how
could
we
start
looking
at
a
common
header
and
this?
This
is
basically
a
simple
idea
on
how
to
start
with
an
ipv6
header
strip
it
down
to
take
out
all
the
things
that
we
may
not
want.
If
the
semantic
we're
preferring
is
more
towards
mpls,
the
source
address
could
be
completely
optional.
AA
The
destination
address
is
really
that
instruction
that
we
had,
and
you
know
I
I
can
give
a
long
rant
about
that.
We
should
get
rid
of
a
lot
of
the
legacy
qs
that
we
have
and
make
it
into
an
an
options
header,
but
so
we
basically
would
arrive
at
a
very
compact
header
that
was
very
flexible.
AA
So
obviously
there
is
a
lot
of
functionality
beyond
addressing,
so
this
would
just
be
the
start
to
to
show
that
we
can
have
a
unified
addressing
structure
which
makes
the
spring
architecture
more
flexible
and
easily
extensible,
with
the
best
of
both
worlds
of
mpls
and
v6.
Right,
obviously,
you
know
we
need
to
discuss
what
we
think
about
you
know.
AA
Other
differences
in
the
forwarding,
like
you
know,
is
mtu,
discover
better
done
out
of
band
or
in-band
and
then,
of
course,
also
backward
compatibility
right,
and
I
think
the
question
is
really
how
much
backward
compatibility
do
we
need
not
that
we
need
it
and
in
the
most
easy
case,
one
can
see
that
with
this
new
encoding,
you
can
simply
map
all
the
existing
mpls
and
srv6
into
it.
But
is
that
really
what
we
want?
AA
Oh
and
that's?
Basically,
it
right.
So
this
this
is
kind
of,
hopefully
a
somewhat
inspiring
thought
about
how
we
can
you
know,
do
a
lot
more
when
we
come
up
with
a
very
simple,
flexible,
addressing
mechanisms-
and
hopefully
you
know
long-term
evolving,
something
where
spring
has
a
single
unified
forwarding
plane.
You
know
cute
small
dogs,
yeah.
That's
it.
Thank
you
very
much
for
your
time
and
please
take
it
to
the
list
contact
me
directly
if
you're
interested
in
this.
AA
Obviously
this
is
not
something
that
can
be
done
overnight,
but
I'd
really
appreciate
any
feedback.