►
From YouTube: IETF108 SPRING 20200727 1100
Description
SPRING session at IETF108
2020/07/27 1100
A
C
C
A
A
A
Not
remember
the
name
but
the
collaborative
note-taking
tool
which
is
available
either
in
in
mythical
or
in
a
different
tab
or
our
browser.
If
you
want
shopping,
is
going
to
take
notes
but
you're
welcome
to
to
contribute
to
correct
your
statements
or
your
name
in
term
of
jabber.
Every
everyone
can
can
use
a
jabber,
but
it's
difficult
for
the
chairs
to
see
both
cues
on
on
jabber.
So
if
someone
wants
to
relay
the
jabber
questions,
it's
it,
it
would
be
welcome.
A
A
D
A
A
A
A
A
The
first
one
is
a
draft
for
a
spring
sl
replication
segment,
which
has
been
adopted
as
a
working
document,
so
pending
being
refreshed,
so
it
is
describing
a
local
replication
on
a
load
on
the
node
and
there
is
a
corresponding
craft,
which
is
to
be
working.
The
teamwork
group,
which
is
going
to
to
work
on
creating
a
replication
tree
or
states
in
the
in
the
network,
but
it's
for
for
pinworking
group,
so
the
name
of
the
graft
is
just
for
for
reference.
A
Next
one.
There
is
a
code
for
option
for
draft
long
spring
sf
for
enhanced
vpn,
which
is
underway
on
ending
wednesday
this
week,
and
also
we
have
a
draft
called
for
adoption
for
draft
rather
spring,
as
a
policy
young
again
ending
today
on
draft
a
code
for
the
adoption
for
draft
rather
spring
76
younger,
so
colorful
adoption
underway
ending
ending
today.
A
A
A
A
A
However,
we
would
like
to
to
have
at
least
the
first
feedback
by
september
15th
for
the
working
group
to
to
see
a
first
output
of
the
design
team
and
then
we'll
see
for
them
for
the
next.
The
next
milestones
as
a
reminder
for
everyone,
a
working
group
on
design
team.
The
output
of
the
design
team
is
to
be
used
as
an
input
to
the
working
group.
So
it's
just
an
even
individual
draft,
just
like
any
other
individual
draft.
A
A
A
F
F
A
B
B
So
that's
our
architecture
just
to
give
an
overview.
The
sr
policy
architecture
draft
covers
the
framework
and
information
model
of
the
sr
policy,
which
is
really
one
of
the
key
fundamental
blocks
of
the
sr
architecture
for
creating
the
seedlist
or
the
source
route
information
that
is
actually
set
up
in
the
packets.
B
B
So
the
draft
was
presented,
you
know
along
at
iit
of
98,
so
very
early
on.
It
was
one
of
the.
It
is
one
of
the
key
milestone
of
the
working
group.
It
was
adopted
at
itf
101,
and
we
last
presented
this
document
at
itf
102
almost
two
years
ago.
So
since
then
there
have
been
many
discussions
on
the
list.
There
have
been
reviews
comments
and
some
of
them
happen
offline
as
well.
So
over
this
period
of
time
the
document
has
undergone.
B
On
the
candidate
on
the
candidate
path
selection,
there
was
some
doubt
so
there
was
some
confusion
on
the
protocol,
origin
values
and
we
had
to
put
in
a
clarification.
These
are
actually
more
like
priority
values
to
determine
which
one
gets
precedence
over
the
other.
For
example,
locally
configured
gets
preference
over
what
is
signaled
via
pcp
or
bgp.
B
Again
for
the
clarification
on
the
tie.
Breaking
rules
on
you
know:
preference
the
we
had
two
names
in
the
draft.
One
is
the
sr
policy
name
and
the
sr
polity
policy,
candidate
names-
and
you
know
there
was
a
in
some
cases,
a
confusion
between
these
and
you
know
what
are?
How
are
they
signaled
in
various
protocols?
So
those
clarifications
were
updated
in
the
document.
B
Then
we
a
couple
of
updates
ago,
we
introduced
mechanism.
There
was
a
requirement
for
you
know,
ability
to
simply
kind
of
pop
the
bc
label
and
do
a
lookup
and
forwarding
based
on
the
underlying
ip
or
label,
and
this
was
more
like
a
fallback
kind
of
a
mechanism,
and
so
we
added
you
know
explanation
of
how
that
could
be
done
using
the
existing.
B
And
then
there
were
update
of
terminologies.
The
srv6
network
programming
is
past
working
group
last
call,
so
we
have
updated
some
of
the
terminologies
related
to
srv6,
basically
behavior
function,
and
you
know
some
segment
types.
They
were
updated
in
the
latest
document
and
there
is
also
the
ayana
registry
setup
for
the
sr
policy
segment
types
and
in
the
last
version,
which
was
updated
a
couple
of
weeks
ago.
B
We
have
also
updated
security
considerations,
so
this
is
a
high
level
update
not
going
into
you
know
each
and
every
changes
move
to
the
next
slide.
Please,
and
this
would
be
the
last
so,
as
I
mentioned
at
the
start,
we
wanted
to
give
an
update
on
the
status
and
where
and
how
we
want
to
go
ahead
and
accomplish
this
critical
milestone
for
the
working
group.
B
So
as
a
next
step,
there
are
a
couple
of
things
that
have
come
to
author's
mind:
one
was
there
was
there
is
a
feedback
for
including
some
examples
for
candidate
path
selection.
You
know
the
adapt
includes
the
tie,
breaker
algorithm
and
how
they
are
picked
up.
Some
of
these
examples
were
there
in
a
different
draft
and
there
is
a
proposal
to
move
this
into
the
appendix
section,
so
they
are
not
normative.
B
Simply
examples
of
the
of
this
draft,
and
then
authors
are
also
aware
and
there's
ongoing
discussion
about
a
use
case
of
more.
Let's
call
it
composite
constraints,
basically
not
just
a
single
one
constraint,
but
what
if
sr
policy
had
you
know
multiple
constraints?
How
do
we?
How
do
we
solve
or
address
that?
So
that's
still
in
work,
and
these
are
the
two
things
that
you
know
are
pending
or
we
are
going
to
work
on.
B
G
B
A
H
H
H
I
think
just
now,
chairs
have
given
a
very
detailed
description
of
the
scope
of
the
design
team
and,
according
to
the
email
from
chels,
the
design
team
will
produce
rough
recommendations.
That
is
just
an
individual
draft
to
a
working
group
on
two
related
topics.
The
first
one
is
what
are
the
requirements
and
the
second
one
is
the
analysis
document
which
maybe
covers
the
comparison
and
some
other
magics
and
the
design
team
have
been
introduced
by
a
chairs,
the
coachelle
from.
H
H
H
We
will
ask
for
all
the
midi
minutes
and
the
documents
and
make
them
acceptable,
accept
accessible
by
anyone,
and
we
will
have
meetings
the
e-meeting.
We
will
book
a
bi-weekly
meeting
and
we
will
start
after
this
week's
meeting.
We
will
use
the
zoom
as
the
tools.
Maybe
some
others
from
the
design
team
can
also
join
us
and
we
hope
in
the
future.
We
can
have
a
face-to-face
meeting
during
itf
meeting
next
page.
H
H
We
will
have
a
output
draft
that
will
cover
the
both
data
plan
and
the
control
plan,
and,
as
adjuster
charles
mentioned,
we
may
need
to
prepare
a
rough
draft
before
september
15th.
I
think
that
is
a
little
bit
challenging
for
us
and
the
second
stage
will
be
between
itf
109
to
itf
110,
the
main
task.
H
We
are
putting
the
drafts,
which
direct
describer
the
different
solutions
for
srv6
compression.
That
is
the
existing
draft
and
which
we
will
use
as
the
input
for
the
analysis,
draft
and
the
output.
We
will
output
analysis
document
that
will
include
evaluation
information
based
on
the
requirements
document,
so
that
is
the
basic
work
plan
for
the
design
team.
H
H
H
A
I
know
it's
difficult,
but
it
would
be
good
to
have
a
first
feedback
to
be
presented
to
the
working
group
by
by
september
15
and
and
then
maybe
every
every
every
two
months
or
something
like
that.
But
so
the
current
time
frame
in
in
nine
months
seems
a
bit
a
bit
too
long,
but
we
will
work
with
you
on.
A
A
A
I
Yeah,
it's
it's
andrew
here.
I
also
just
wanted
to
comment
on
that
time.
Frame.
Nine
months
seems
like
a
long
time,
particularly
considering
that
there
are
operators
like
ourselves
that
actually
have
a
fairly
dire
need
for
this
stuff,
and
I
realized
that
things
take
a
long
time
in
the
ietf
but
nine
months,
considering
the
fairly
long
time
frames
that
have
been
involved
in
the
discussion
of
these
things
already
before
the
design
team
just
seems
yeah.
It's
it's
problematic
and
I'd.
H
Okay,
so
thank
you
and
this
current
the
time
frame
have
been
agreed
by
the
design
team.
I
think
it.
You
know
it's
really
challenged
for
us
to
get
agreement
on
the
requirement
and
the
analysis,
but,
as
you
mentioned,
we
will
try
to
do
that.
Currently,
the
time
frame
is
just
a
plan.
I
think
if
we
can
work
more
efficiency
and
I
think
that
that
will
speed
up
the
progress,
maybe
we
can
shorter
the
duration
to
get
agreement.
A
D
D
D
The
behavior
was
described
at
high
level,
but
now,
in
that
new
version
we
have
a
proper
pseudocode
as
well
and
then
some
some
other
fixes
and
changes
in
the
ins
section
and
also
coming
from
feedback
that
we
received
over
the
past
year
on
the
mailing
list.
Thank
you
for
all
who
commented
on
the
graph
next
slide.
Please.
D
We
have
the
heat
processing,
the
upper
layer
have
a
processing,
so
these
two
blocks
are
inherited
from
erotic,
8754
and
the
network
programming
graph,
and
we
also
have
a
third
block,
that
is,
for
the
return
traffic
and
that
is
specific
to
the
proxy
behavior,
but
same
formation
for
all
three
of
them
next
slide.
Please.
D
D
D
Now
we
have
new
code
points
for
all
the
flavors
of
the
masquerading
property,
because
this
is
frankly
the
only
one
that
has
flavors
and
again.
This
is
to
align
to
better
align
the
graph
with
the
network
programming
graph,
which
also
defines
different
code
points
for
each
flavor
of
the
of
the
behaviors.
D
A
J
J
So
the
available
mpls
segment
routing
is
using
the
amplis
data
plane.
So,
on
the
right
hand,
side
you
see
a
packet
capture
coming
on
a
ampulla
segment,
routed
forwarded
packet
exposed
by
ipfix
and,
as
you
can
see,
there
are
no
to
no
much
surprise.
The
amperless
labels
are
still
the
same.
Top
label
address
is
the
same
top
label.
Prefix
length
is
the
same,
but
what
should
have
been
changed
is
actually
the
top
label
type
in
this
render
implementation.
It's
still
referencing
ldp,
even
though
it
was
forwarded
with
empire
segment.
Routing
next
slide,
please
yeah.
J
J
But
that's
not
all
of
it.
As
you
know,
segment
routing
has
six
or
different
seats
type
d6
type,
basically
describing
an
instruction,
a
segment,
a
service
on
the
network
and
by
having
that
information
that
dimension
also
present
in
ipfix.
That
would
allow
us
to
get
deeper
inside
why
a
packet
was
forwarded
in
a
particular
way.
So,
for
instance,
if
you
take
the
ti
lfa
application
there,
it's
about
json,
c6
next
slide.
J
J
So
I
was
already
collecting
feedback
from
the
spring
and
the
ops
awg
working
group.
Thank
you
very
much.
I
submitted
this
to
ayanna
and
I
received
the
first
review
from
the
iphix
entity
doctor,
I'm
looking
at
from
further
feedback
from
spring
and
ops,
awg
and
planning
to
adopt
at
ops,
ops.
They
are
a
ops.
A
A
C
C
C
C
C
C
C
So
second
use
case
is
a
large
scale
van
networks.
So
when
the
van
networks
consist
of
several
thousand
nodes,
then
it
is
useful
to
have
smaller
igp
domains,
so
the
smaller
igp
domains
reduce
the
blaster
radius
of
the
network
events.
So
the
domains
are,
you
know
the
the
fault
domains
become
smaller,
so
so
having
a
smaller
domain
also
helps
in
reducing
overall
state
on
the
device.
C
C
So
even
if
we
use
even
if
some
deployments
use
the
controller
based
solutions
which
can
look
into
each
of
these
domains
and
get
the
database
and
built
an
end-to-end
path
for
end-to-end
t
constraint,
the
network
still
needs
to
have
for
use
cases.
I
mean
for
scenarios
when,
when
the
controller
connectivity
goes
down,
the
network
still
needs
to
have
the
n20
paths
built
in
so
that
it
can
use
in
case
in
case
there
is
a
failure.
C
Please
so
the
third
use
case
is
a
data
center
interconnect,
so
this
network
diagram
shows
data
centers
connected
via
a
core,
so
many
many
applications
that
run
in
the
data
center
may
require
end-to-end
path,
diversity,
for
example.
Here
we
can
see
that
there's
a
red
path
and
a
blue
path
end
to
end
and
that
there
could
there
is.
C
Please
so
so
seamless
sr
is
an
extension
to
existing
seamless,
mpls
architecture
so
to
be
able
to
satisfy
these
end-to-end
te
constraints.
A
bgplu
has
some
shortcomings,
for
example
in
this
network.
If
we
see
for
the
pe5
loopback
bgplu
on
pe
one
bgplu
gives
just
a
single
path
to
the
remote
loopback
and
and
that
single
path
is
mostly
chosen
based
on
bgp
best
path
selection.
So
here
we
need
a
way
to
advertise
multiple
paths
to
the
same
loopback,
so
this
seamless
sr
architecture
proposes
an
extension
to
bgp
protocol.
C
C
Transport
ribs
are
a
collection
of
tunnels
that
that
belongs
to
that
belong
to
a
single
transport.
Class.
Bgpct
is
a
protocol
extension
as
it's
a
new
family
and
it
has
a
route
distinguisher
in
the
nlri,
so
route.
Distinguished
the
purpose
of
route
distinguisher
is
to
is
to
uniquely
identify
the
prefix
and
route
distinguished
pair
to
a
particular
loopback,
and
there
is
a
route
target.
C
This
is
the
the
route
target
extended
community
that
gets
carried
in
bgp
ct
advertisement
and
route
target
corresponds
to
the
transport
class
that
the
bgp
advertisement
belongs
to
and
then
there's
a
mapping
community.
So
this
mapping
community
is
is
a
is
a
bgp
extended
community
in
bgp
protocol
and
then
it
is
used
to
define
the
service
mapping
requirements
for
that
particular
bgp
ct
advertisement.
C
The
forwarding
state
looks
very
the
the
forwarding
on
the
packet
looks
very
similar
to
bgplu.
There
is
no
really
any
difference
so
the
way
the
bgplu
label
gets
swapped
on
the
border
nodes.
The
same
same
mechanism
will
be
applicable
for
bgpct
as
well,
so
in
in
this
example,
we
have
this
loopback
pe5,
the
the
top
part
shows
the
the
bgpct
advertisements
and
the
bottom.
The
bottom
boxes
show
the
the
label
the
packet
forwarding
with
respective
label
operations.
C
So
if
you
can
see
the
left,
most
pe5
advertises
a
prefix
pe5
with
a
route
distinguisher
and
then
the
route
target,
which
is
red
color
for
the
red
for
the
end,
to
end
red
path,
and
then
it
associates
a
label
and
then
sets
next
stops
to
self
and
then
sends
it
to
asbr
seven
and
asbr.
Seven
changes
the
next
stop
to
self
and
then
advertises
another
label
for
the
same
prefix
and
that
continues
till
the
advertisement
reaches
pe
one.
C
Has
a
vpn
prefix
v1
and
then
there
is
a
route
distinguisher
and
route
target.
So
this
is
vpn
route,
distinguisher
and
route
target,
and
this
is
not
in
any
way
related
to
the
bgp,
ct's,
rd
and
rt.
So
in
vpn
advertisement
the
rt
specifies
the
vpn
membership
in
bgp
ct
advertisement.
The
rt
specifies
the
transport
class
membership
and
to
simplify
the
service
mapping
and
then
to
be
to
allow
auto
steering
this
extended.
Color
community
is
used.
C
So
if
you
see
the
vpn
prefix
carries
the
extended
color
community
red
and
the
the
route
target
in
bgp
ct
advertisement
carries
the
same:
extended
color
community,
which
maps
directly
maps
to
the
extended
color
community
red
so
on
the
ingress.
The
resolution
of
vpn
on
this
red
path
will
be
automatically
automatically
done,
based
on
the
extended
color
community
in
the
vpn
advertisement.
C
So
we
have
an
example
use
case
and
and
how
how
this
can
be
achieved
with
seamless
sr.
So
this
is
a
use
case
where
there
are
multiple
asses
s,
one
two
and
three,
and
it
roughly
represents
each
continent,
and
so
there
is
a
data
sovereignty
requirement,
which
is
requires
to
avoid
no
node,
a
and
c
in
as3,
as
node.
A
and
c
belong
to
a
particular
country.
C
C
C
So
once
the
red
lsp
is
created
in
as3,
the
red
transport
class
is
created
on
all
the
border
nodes,
and
then
there
is
a
resolution
with
policy
which
is
advertised
by
the
mapping
community,
which
says
in
as3.
The
resolution
is
to
be
strict
resolution
to
use
only
red
paths,
whereas
the
mapping
community
on
as2
and
as1
will
say
if
red
path
exists,
resolve
on
that
and
if
that
doesn't
exist,
use
best
effort
path.
C
So
if
we
see
in
as1
and
as2
the
red
tunnels,
intradomain
tunnels,
red
tunnels
are
not
created
in
as1
and
es2,
because
it's
not
the
constraint
is
not
applicable.
So
the
traffic
is
just
going
to
follow
best
effort
path,
whereas
on
the
border
nodes
there
is
a
state
created
for
the
reddit
transport
class
and
labeled
with
separate
label
advertised
for
the
right
transport
class.
C
So
on
pe
one,
the
service
when
the
service
prefix,
which
needs
to
honor
this
data
sovereignty
requirement,
will
use
the
red
color
community
and
then
use
red
bgpct
labels
to
forward
the
traffic.
And
if,
as
you
see
in
this
diagram,
you
can
see
the
traffic
going
from
pe1
to
sbr1
and
2
asbr
2
and
then
asbr
3
4
and
then
use
the
red
lsp
in
as3
and
then
reach
pe2
next
slide.
Please.
C
A
G
I
have
two
questions
about
this
presentation.
The
first
is
as
you're
showing
in
this
slide
and
also
in
the
document
I
see.
Segment
routing
is
just
used
as
one
type
of
the
tunnel
and
rsvp
and
ltp
can
also
be
used
under
this
architecture.
Right,
yes,
could
you
please
clarify
what
is
called
the
seamless
signal,
routing
and.
C
C
C
A
Next,
I
believe,
is
easy
mean
by
the
way
anyone
can
go
to
the
mic
queue
anytime,
just
like
during
a
physical
meeting
and
also
it's
it's
best
practice
to
to
say
your
name
on
affiliation.
When
you
speak,
even
though
we
we
see
your
name
on
the
chat,
I'm
not
sure
it
will
be
how
it
will
be
seen
on
youtube.
So
it's
better
to
teach
your
name.
A
A
A
A
A
K
K
K
So
the
requirement
and
scope
of
this
draft
is
performance
monitoring,
delay,
monitoring
as
well
as
liveness
monitoring
for
end-to-end
sr
parts,
it's
applicable
to
srm
pls
and
srv6
data
planes,
basically
to
run
a
single
protocol
in
sr
networks.
That's
where
the
motivation
is
to
simplify
the
implementations
and
reduce
operational
cost
also
for
the
operators,
simplify
the
deployment
and
operational
complexity
so
to
avoid
the
end
point:
dependency,
stateless
on
the
end
point
to
allow
higher
scale
and
faster
detection
interval.
K
K
K
So
in
enhanced
performance
monitoring
mode,
the
pro
packets
on
the
reflected
node
there
is
a
network
programming
function,
enabled
and
it
allows
to
optimize
the
operations
point
and
add
timestamp
and
re-inject
the
probes
and
avoid
that
that
that
that
function
and
process
in
the
fast
path.
So
this
will,
you
know,
make
the
faster
liveness
failure
and
performance
monitoring
possible.
K
Please
so
failure
is
notified.
If
you
know
some
m
number
user
configure,
probe
messages
have
delay
values,
exceed
the
user,
configure
thresholds
and
counts
same
way.
Loudness
failure
is
notified.
It's
a
loss
of
heartbeats
when
consecutive
n
number
of
probe
messages
are
not
received
back
at
the
sender.
K
So
if
using
a
tvamp
messages
or
simple
diva
messages,
there
is
a
transmit
timestamp,
that's
added
by
the
sender,
and
there
is
a
received
timestamp,
that's
added
by
reflected
node
using
the
network
programming
function.
It's
added
that
the
byte
it's
locally
programmed,
and
in
this
case
the
offset
would
be
a
16
in
the
payload
of
the
t1
per
stamp
approved
message
and
next
slide.
K
K
K
K
K
K
K
K
L
K
K
K
K
Yeah,
so
by
sending
the
basically
in
any
lightness
protocol,
you
are
sending
probe
messages
along
the
path
that
you
are
monitoring
and
if
there
is
a
loss
of
connectivity,
the
probe
messages
are
not
received,
and
this
is
how
we
know
there
is
alignness
failure
and
packet
format
can
be
anything
in
this
draft.
We
are
proposing
t1
for
a
simple
t1
to
leverage
the
existing
implementation
and
deployments,
but
packet
format
can
be
anything.
The
idea
is.
L
So
there
is
no
that's
why
I
wonder
how
the
far
end
will
determine
what's
the
expected
rate
of
these
probe
messages
and
how
then
calculate
because,
for
example,
if
we
look
at
bfd
there
is
a
whole
machinery
of
negotiating
the
interval
between
the
two
end
points,
and
then
there
is
a
detect
multiplier,
which
is
essential
to
calculate
their
detect
time
in
cfm.
It's
a
little
bit
different,
but
still
they
hardcoded
that
three
messages
in
a
row
missed
the
constitute
their
defect.
K
Yeah,
so
I
think
the
the
whole
theme
of
the
solution
is
that
the
reflector
is
unaware
of
the
there
is
no
punt.
There
is
no
re-inject,
there
is
no
raid.
There
is
no,
you
know
lpts,
it's.
It's
really
fast
part
forwarded
just
like
data
traffic,
so
there
is
the
whole
concept
of
this
rate.
Limiting
exchanging
the
rate
information.
All
of
that
is
being
is
not
is
not
needed
in
this
enhanced
performance
monitoring.
That's
why
we
call
it
enhanced,
because
it's
a
significantly
a
step
forward
compared
to
existing
technology.
L
L
L
K
But
it's
it's
not
used,
there
is
no
pointing
done
and
no
injection
of
the
probe
on
the
reflector
is
sent
and
come
back
to
you.
It's
forwarded
by
the
reflected
node,
just
like
any
other
data
packet.
So
this
is
why
the
reflector
is
unaware
that
there
is
a
protocol
being
run
or
there's
late
limit.
There
is
no
state
there
it.
So
you
can
run
at
very,
very
high
speed.
K
L
K
L
Well:
okay,
if
you
saying
that
you
want
to
define
any
packet
format,
then
you
don't
need
to
refer
to
these
protocols
because
they're
protocols
for
the
reason,
because
they
are
based
on
some
specification,
which
defines
the
protocol.
If
you're
inventing
some
new
protocol,
then
you're
inventing
new
protocol.
K
A
I
I
But
I
do
see
advantages
in
using
this
for
actual
timing
across
a
path
and
then
my
other
comment
on
this
you've
said
that
in
the
draft
it
doesn't
really
kind
of
limit
you
to
specific.
You
know
tiwa
or
stamp,
but
I
point
to
the
to
the
fact
that
section
5.2
actually
does
specify
rfc,
5357
and
h762
etc.
K
Yeah,
that's
a
good
feedback
andrew
we,
we
will
definitely
address
the
comment
and
the
first
comment
that
you
had
about
so
liveness.
It's
kind
of
there
is
no
extra
protocol
machinery
required
for
lioness
you.
If
you
will
it
you're
kind
of
getting
it
for
free
right.
There
is
no
state.
There
is
no
extra
a
lot
extra
functionality
except
you
know
that
your
probe
messages
and
continuity
checks
are
failing.
A
A
K
K
K
So
we
look
at
the
requirement
and
scope
the
history
of
the
drought,
the
updates
we
made
since
it
was
presented
in
singapore,
the
summary
of
the
changes
and
the
next
steps
there
is
in
the
backup
of
this
presentation.
We
do
have
slides
that
was
presented
in
singapore
for
the
lynx,
pls
policy,
a
srv6
policy,
the
provisioning
model
and
ecmp.
K
So
we
will
not
go
over
the
what
was
presented,
but
we
will
just
present
the
updates
next
slide.
Please
so
just
to
refresh
the
requirements
and
scope
of
the
drop
is
the
delay
and
loss
performance
measurement
for
links
and
sr
parts
for
p2p
and
p2mp
links
can
be
a
physical
virtual
lag
or
lag.
Members
idea
is
to
also
measure
the
ecmp
for
sr
paths
and
also
support
the
standalone
direct
mode
loss
measurement,
and
this
is
the
using
simple
t1.
K
K
K
K
K
K
K
So
we
have
defined
a
tlv
for
the
destination
address,
so
if,
if
there
is
an
the
we're
using
127.8
destination
address,
if
you
want
to
make
sure
that
packet
is
indeed
processed
by
the
expected
or
intended
destination,
reflector
node
there
is
a
destination
address
added
in
the
message
next
slide.
Please.
K
So
in
the
return
address
tlv
there
was
there.
We
now
also
added
a
written
address.
So
if
you
want
to
get
reply
back
on
a
different
note
other
than
the
sender,
for
example,
there
is
a
sub
tlp
for
it
and
we
already
had
the
subtleties
for
the
srm,
pls
or
srv6
labels
to
receive
the
reply
on
a
specific
sr
path.
K
K
So
we
welcome
your
comments
and
suggestions.
There
is
an
implementation
that
exists
for
this.
We
are
requesting
spring
working
group
adoption
as
the
base
work
is
happening
in
stem.
We
are
we.
We
have
been
keeping
the
ipp.
Sorry
in
ippm,
we
have
been
keeping
yppm
working
group
in
the
loop
about
the
milestones
and
we
are
also
presenting
this
draft
in
ippm
on
friday.