►
From YouTube: IETF110-RTGWG-20210312-1600
Description
RTGWG meeting session at IETF110
2021/03/12 1600
https://datatracker.ietf.org/meeting/110/proceedings/
A
Well,
shall
we
get
started?
Yes?
A
Okay,
I
think
you
were
gonna,
handle
the
update,
slides
right,
jeff,
yep,
okay,
take
it
away.
B
B
We
are
announcing
id
change,
actually,
we
are
not
announcing.
We
are
just
telling
you
that
it's
going
to
happen.
I
would
like
to
thank
martin
for
all
the
great
work
he
has
done
while
being
our
ad,
and
we
welcome
alvaro
back.
B
B
Documents
that
in
our
past
working
group
plus
call
the
policy
model
has
been
subbing
to
lg
for
quite
some
time
we
are
waiting
on
isg
bgp
draft
has
been
in
last
call
for
two
and
a
half
months
receipt
number
of
comments.
We've
seen
author
replying
that
they're
going
to
address
them.
We
are
still
waiting
for
authors
to
start
addressing
the
comments
next
slide,
please,
we
didn't
publish
any
rfc
since
last.
Atf.
B
The
drafts
that
expected
to
go
into
working
plus
call
our
qs
model
reebok
standard.
We
are
looking
for
shepherds
for
both
drafts.
B
B
C
A
Yeah
yeah
I'm
planning
to
project
your
slides
if
I
can
get
it
to
switch
over,
I'm
gonna
go
to
full
screen
in
a
moment.
So,
let's
see
video,
I.
D
D
C
I
think
we're
good
great,
thank
you.
Okay,
so
integrated
oem.
Well,
we
do
have
different
components
of
oem,
usually
oem
understood
as
taking
two
parts,
two
letters
in
fcaps
acronym.
So
it's
a.
C
Fault
management
and
performance
monitoring
fault
management
is
concerned
with
their
detection
of
network
failure,
localization
and
characterization
and
performance
monitoring.
It's
obviously
a
measurement
of
different
performance
metrics.
Usually
it's
a
packet
delay
packet
loss,
but
based
on
that,
there
are
different.
Other
metrics
can
be
calculated
next
slide.
C
C
So
far,
we've
worked
on
different
protocols
for
fault
management
and
performance
monitoring,
and
we
have
learned
quite
a
lot.
One
of
the
most
broadly
used
and
very
successful
is
bi-directional.
Forwarding
detection
and
there
are
a
lot
of
hardware
based.
C
Support
for
this
and
it
scales
well,
but
what
we
learned
is
that
security
is
important
but
doing
security
or
authentication
at
3.3,
milliseconds
of
for
each
packet
is
very
expensive.
C
Extensibility
is
very
important
and
useful,
and
we
want
to
minimize
the
number
of
oem
protocols
that
require
to
operate
network.
So
that's
one
of
their
main
motivations
for
looking
at
integrating
fault,
management
and
performance
monitoring
under
one
protocol
umbrella,
active
performance
measurement,
oem
and
active.
This
is,
in
definition
from
rfc
7799
that
defines
the
active
as
using
specifically
constructed
test
packets
at
the
same
time
so
itf
and
elsewhere.
C
We
there
are
a
lot
of
consideration
and
work
being
done
for
onpath,
oem
or
telemetry
information
collection
that
uses
data
packets
mark
specifically
or
arranged
specifically
to
generate
information
about
performance
and
experienced
by
the
packets.
C
It
needs
to
be
flexible
enough
to
do
packet,
loss
and
delay
measurement
separately
or
in
combination.
The
security
is
critical
and
again,
as
for
their
fault
management,
extensibility.
C
Combining
this
two
fault
management
performance
measurement
is
that
integrated
oem.
C
C
So
what
we're
proposing
this
reflects
displays
their
format
of
the
base
control
message
list
their
fields.
C
Some
of
them
are
very
familiar
and
the
tlb,
so
the
basic
tlv
extension
includes
type
field
reserved
field
length
and
then
variable
length,
value
field.
C
C
C
Currently,
what
they
proposed
is
are
loss,
measurement,
delay,
measurement
path,
mtu
and
authentication.
C
C
The
timer
negotiation
mechanism
is
a
well-known
mechanism
used
in
bfd
when
each
of
participants
of
their
test
session
advertises
their
interval
that
it
wants
to
send
message
and
expect
message
to
be
received,
so
that
allows
a
balance
between
parties
peers
in
the
test
and
protects
it
from
being
overrun
or
attacked
next
slide.
C
Please
authentication
capability,
authentication
capability
expects
to
be
extensible.
C
And
each
of
their
parties
advertises
what
it
capable
of
supporting
that
can
be
identified
based
on.
C
Bit
filled
and
then
each
of
them
selects
the
strongest
authentication
method
supported
by
all
parties
and
then
can
be.
C
So
this
diagram
reflects
how
negotiation
for
the
lightweight
authentication
is
expected
to
work.
C
Authentication
uses
the
tlv
extension
and
includes
our
variable
length,
hmac
field,
so.
C
And
the
length
of
the
hmac
is
something
that
parties
can
negotiate
during
their
capability
negotiation
phase.
C
Next
slide
performance
monitoring
in
the
integrated
oem,
it's
using
the
constructs
defined
in
rfc,
6374,
mpls
packet
loss
and
delay
measurement,
and
that
supports
synthetic
one-way
and
synthetic
two-way,
as
well
as
direct
loss
measurement
packet,
delay,
measurement,
one-way
and
two
way,
and
we
are
adding
a
packet
mtu
discovery
using
padding.
C
So
their
path
mtu
discovery
monitoring
operation.
It
needs
to
be
more
detail
specific.
Where
welcome
your
comments,
suggestion
and
question.
B
E
Yeah
hi
greg,
so
there
is
a
similar
draft
in
the
bfd
working
group.
It's
a
draft
mean
bfd
extended.
How
does
this
relate
to
that
work
in
the
bfd
working
group?
This?
This
draft
replaced
it
okay,
yeah
it's
not
clear
by
combining
the
rfc,
6374
and
vfd
taking
pieces
from
two,
not
sure
what
requirements
are
being
addressed,
because
this
was
discussed
in
the
bfd
working
group
and
the
extensions
of
control
protocol
for
6374
using
bfd.
C
C
C
Again,
if
you
look
at
their
document,
so
it
goes
into
explanation
of
motivation
in
more
details.
C
I
don't
want
to
just
read
the
document
here
again
out
loud,
but
there
is
some
interest
because
in
other
applications
like
rift,
we
talked
about
with
the
community
and
it
already
provides
infrastructure
that
supports
path.
Continuity,
and
it
might
be
nice
feature
to
complement
it
with
the
performance
monitoring
when
system
discovers
their
topology.
E
B
Rakesh,
you
are
not.
Your
voice
disappears.
E
So
so
we
could
probably
present
this
work
in
other
working
group
and
get
the
compared
with
other
work
happening
in
other
working
groups.
C
Yes,
I
understand
that
you
refer
to
srpm
work.
I
just
want
to
point
that
srpm,
as
I
understand
it,
it's
built
around
stamp
protocol
stem
protocol
is
a
performance
monitoring
mechanism
and
it's
quite
heavy.
So
it's
definitely
too
heavy
for
being
considered
as
a
lightweight
path
continuity.
C
So
I
really
doubt
that
it
was
not
okay.
It
was
not
designed
to
be
a
path,
continuity
and
deform
at
high
rate,
like
3.3
milliseconds,.
C
And
as
such,
I
think
it's
not
the
best
choice
as
a
base
for
integrated
oem
solution.
That's
why
what
we
are
proposing.
We
are
proposing
a
different
approach
to
this
problem.
C
I
think
that-
and
I
I'm
really
appreciate
that
you're
interested
in
this
work,
because
what
we
are
doing,
though,
we're
trying
to
solve
it
differently.
It's
to
me
it's
an
indication
that
there
is
an
interest
and
there
is
a
real
need
to
do
the
to
have
an
integrated,
oem
solution,
but
definitely,
let's
discuss
which
approach
is
more
practical
and
realistic.
F
Greg,
but
do
you
really
do
you
plan
to
extend
the
pfd
for
the
whole
thing
like
protection.
G
C
C
It's
not
really
an
extension
of
bfd,
so
what
we
are
proposing
here
would
not
be
on
top
of
existing
bfd
for
now.
Looking
more
like
a
new
protocol
that
inherits
best
features
of
bfd
and
mechanisms
like,
for
example,
negotiation
using
a
poll
sequence.
C
And
some
of
the
structure,
but
I
would
not
really
refer
that,
as
this
is
an
extended
dfd
and
that's
why,
when
we
started
this
work
and
to
remove
some
confusion,
we
mark
this
document
as
replacing
this
document
that
we
had
earlier
and
named
it
extended.
C
So
their
resulting
protocol,
in
our
opinion,
will
have
a
lot
of
functional
similarities
with
bfd,
but
would
not
be
an
extension
of
the
d
per
se.
F
C
Well
again,
so
this
is
early
and
we
appreciate
their
comments
and
recommendation
suggestions,
so
we're
open
to
discussion.
Let's
do
it
on
the
list
and
it
will
be
great
again.
C
We
are
looking
comparing
with
their
mechanisms
that
been
used
in
so
far
in
protocols,
and
they
there
are
other
all
based
on
configuration.
C
So
we
think
that
being
able
to
con
negotiate
because
different
nodes
parts
of
the
network
can
be
upgraded
at
different
level,
is
a
more
flexible
approach,
but
definitely
your
suggestion
of
having
some
mandatory
security
that
that's.
If,
if
I
understand
you
correctly,
I
I
think
that
that's
probably
the
right
way.
We
need
just
agree.
What
is
the
mandatory
security
authentication
level
that
has
to
be
supported
by
all
nodes
that
support
this
specification.
B
I
Hi
jeff
is
speaking
as
one
of
the
bfd
chairs.
It's
worth,
noting
that
we
had
long
conversations
with
greg
about.
Could
we
put
this
inside
a
bfd
and
greg
in
the
slides
makes
a
good
point
that
you
know
what
we're
doing
is
we're
leveraging
vfd-like
mechanisms.
You
know
the
the
properties
that
are
sort
of
liked
by
greg
for
bfd
is
being
able
to
carry
out
carry
information
from
one
system
to
another
in
a
periodic
fashion.
I
So
we
did
suggest
that
greg
actually
leverage
the
mechanisms
from
the
fd,
for
you
know
his
new
mechanism
so
to
some
extent,
to
answer
fans
question
in
the
eq
we
did
discuss
putting
this
in
the
vfd.
It's
not
a
great
fit,
at
least
in
terms
of
the
core
protocol,
but
we're
quite
happy
to
see
the
mechanism
mechanisms
that
bfd
is
popularized
carried
into
the
rest
ietf
for
other
purposes.
J
Yeah.
Okay,
I
I'm
sorry
sorry
chair.
I
don't
know
if
I'm
permitted
to
ask
questions.
Oh
yes,
please
go
ahead.
Okay,
so
I
I
get
a
clarification
from
from
the
from
previous
comments.
So
I
also
have
another
question
that
I
I
see
you
mentioned
the
past
mtu
discovery
and
the
monitoring
here.
So
I
don't
know
if
why,
if
there
is
any
use
case
that
to
use
a
protocol
like
oem
protocol
to
do
this
kind
of
to
do
this
past
mtu
discovery
and
monitoring
work.
C
Well,
normally,
this
task
is
part
of
oem
functionality,
whether
it's
done
using
on-demand
to
like
icmp
or
whether
it's
done
differently.
For
example,
there
is
a
proposal
in
beer
path,
mtu
discovery
in
beer
that
uses
lsp
ping
extension,
so
here
it
could
be
done
either
on
demand
and
I'm
kind
of
like.
C
Thinking
right
now
on
my
feet,
using
a
pole,
sequence
or
it
could
be
done
periodically
and
in
bfd
we
do
have
a
document
that
quite
advanced,
because
there
is
a
need
from
their
operators
to
monitor
the
path
mtu,
because
path
mtu
on
a
tunnel
can
change
in
course
of
the
operation.
C
J
Okay
sure,
since
you
mentioned
beer,
I
I
also
want
to
have
a
follow-up
question
that,
if,
if
all
these
functions
are
are,
if,
if
the
functions
of
this
in
in
oam,
will
I
mean
what
what
what
kind
of
what
database,
what
data
plane
and
do
you
plan
to
use
this
into
oem
protocol
there?
Because
you
mentioned
beer,
is
that
only
in
the
beer
or
what?
What
other
data
plane
do?
You
have
the.
C
Excellent
question.
Thank
you.
I
really
appreciate
you
ask
the
question
for
now,
so
this
our
goal
is
first
to
define
the
core
protocol
and
then
make
it
applicable
to
all
data
planes.
C
Again
I
can
point
to
the
experience
with
the
bfd
that
bfd
successfully
being
applied
to
mpos
ip.
There
is
a
explanation
of
using
bfd
in
beer,
and
this
is
more
of
a
point
to
multipoint
flavor
of
bfd
so
or
it's.
There
are
two
rfcs
bfd
for
multi-point
networks,
so.
D
A
Interrupt
here
a
little
bit,
we
need
to
sort
of
close
the
discussion
after
rakesh,
so
I
would
say,
let's.
A
You
could
respond
to
yeah.
You
know,
provide
those
pointers
on
the
list,
we'll
let
rakesh
ask
his
final
question
and
then
we'll
move
on
to
the
next
presentation
after
you've
had
a
corresponds
to
that.
Thanks.
E
Yeah
well,
greg.
One
comment
is
that
with
automation
and
controller
and
the
sdn
fairly
advanced
these
days
there,
we,
you
know,
bring
less
and
less
control,
plane,
signaling
and
extensions
to
simplify
the
control
plane.
E
So
I
think
the
simple
t-ramp
is
a
perfect
example
of
how
controller
can
be
used
for
such
use
cases.
So
here
you
know
this
signaling
extensions
with
going
in
a
different
direction.
C
No,
I
don't
believe
so,
because
the
control
plane
is
basically
the
advantage
of
stamp
comparing
to
the
t-wamp
is
stamp.
Configuration
can
be
done
for
the
controller
using
yank-based
data
models.
C
I
don't
see
that
there
is
anything
precluding
to
have
yang
data
model
for
integrated
oem
protocol
and
then
use
a
centralized
controller
to
instantiate
test
sessions,
whether
proactive
or
on
demand
as
operator
desire.
So
I
don't
see
any
contradiction
between
the
model.
Stem
can
be
used
in
network
automation
versus
how
integrated
oem
proposal
protocol
can
be
used
so
but
yeah,
let's
take
it
to
the
list
and
continue
the
discussion
on
the
list.
I
I
think
that
will
be
better
for
everybody.
A
A
Hi
there
I'm
working
on
getting
getting
your
slides
up
in
full
screen
mode.
Just
give
me
a
moment.
L
Thanks,
you
look
good,
thank
you.
So
this
is
a.
This
is
a
problem.
That's
looking
for
a
solution
which
may
or
may
not
already
exist
the
drafts
that
are
great
out.
There
are
drafts
that
we've
been
working
on
for
a
couple
years
now
under
the
irtf
within
the
coin,
research
group
and
we've,
and
we
we
is
eve,
schooler.
L
Xavier
de
foy
and
myself
who've
been
working
on
a
series
of
drafts
to
describe
this
problem
of
locating
and
capturing
data
in
a
standardized
way,
and
so,
if
you
go
to
the
next
slide,
talk
a
little
bit
more
about
the
history
of
this.
But
so
we've
had
these.
L
L
L
You
can
have
orchestrated
container
solutions
that
allow
you
to
locate
data,
but
we're
looking
for
this
to
be
more
of
a
dynamic,
non-pre
provisioned
way
to
locate
data
and
that
data
may
be
cached
and
stored
throughout.
You
know
multiple
locations
and
it
needs
to
be
marshaled
to
be
able
to
feed
a
particular
function,
and
so
to
that
point
is
why
we've
been
working
on
this
within
the
the
coin.
Rg
the
computing
in
the
network
rg
to
just
kind
of
kind
of
further
develop
this
idea.
L
L
So
data,
if
this
is
you
know,
obviously
a
very
broad
concept
but
we're
focusing
on
it.
You
know
data
can
be
a
program,
a
service,
a
resource,
and
we
have
a
variety
of
use
cases
that
kind
of
helps
describe
using
that
and
it
can
involve
statistics,
measurements,
temperature,
location,
metadata
health
records.
L
Okay,
so
one
of
the
use
cases
that
we
developed
and
I'll
try
to
quickly
go
through
these
is
being
able
to.
When
you
have
a
sfc
enabled
domain,
you
have
a
variety
of
service
functions
and,
along
with
a
potential
service
path,
excuse
me
and
the
data
capabilities
of
those
devices
those
service
functions.
It
would
be
helpful
to
have
them
discoverable
in
order
to
steer
applications
based
upon
app
requirements.
L
They,
you
know,
we've
we've
heard
from
this
week
about
using
apn,
and
so
it's
kind
of
along
the
same
concepts
and
it
and
it's
not
only
apm,
there's
some
solutions
outside
of
the
ietf,
like
w3c,
that
are
finding
doing
some
research
on
application
hints
to
the
network
about
things
that
they
want
to
declare
the
the
network
to
do
and,
and
part
of
that
may
be,
to
find
certain
data,
and
so
the
data
to
be
discovered
in
this
particular
instance
is
resources
that
can
help
a
local
application,
perform
a
particular
task,
and
then
data
which
needs
to
be
searched
and
discovered
to
be
able
to
provide
a
result
to
be
active
upon
by
the
application.
G
Yeah
yeah,
because
the
the
description
you've
given
confuses
me,
on
the
one
hand,
there's
already
a
proposal
for
how
to
do:
sfc
service
function,
discovery
or
service
function,
knowledge
for
it
if
you're
using
a
distributed
system,
but
it's
aimed
at
making
sure
that
the
classifiers
know
where
the
sfs
are
not
about
external
discovery,
because
fundamentally,
sfc
is
designed
for
cases
where
the
application,
the
thing
external
to
the
classifier
function
is
not
choosing
the
service
functions.
G
There
also
everybody's
already
using
lots
of
mechanisms
whereby
controllers
can
just
which
generally
stand
up
the
server
functions
anyway,
can
discover
the
service
functions.
So
this
problem
feels
like
it's
already
well
attacked
and
I
have
trouble
with
it
as
an
example.
Understanding
what
problem
you're
really
trying
to
follow.
L
Yeah
so
it
may
be,
and
we've
talked
about
you
know
punting
to
a
controller
to
this
you
know
let
the
controller
take
care
of
you
know,
providing
whatever
service
function,
that
you
need
to
to
provide
it,
and
if
there's
already
a
solution
to
providing
data
capabilities
of
devices,
two
applications,
then
that's
great.
Then
we
need
to
to
make
a
note
of
that.
Maybe
we
can
leverage
that,
for
other
of
our
use
cases
is
that
what
you're
saying
that
that
particular
application
has
already
been
solved.
G
This
to
the
degree
that
I
understand
the
discovery
problem
in
service
function.
Chaining,
I
won't
say
it's
solved
completely
and
there's
always
room
for
improvements,
but
it
doesn't
need
a
whole
new
tack
on
the
problem.
It
seems
to
be
fall
well
within
several
different
domains
that
we
know
work
for
this.
M
Yeah,
I
just
wanted
to
respond
joel
just
quickly.
Obviously,
I'm
aware
of
the
the
service
function,
discovery,
documents
and
staffers
that
you
mentioned,
but
I
think
what
mike's
trying
to
do
here
is
just
give
an
example
of
you
know
what
type
of
data
are
we
talking
about
and
sfc
is
obviously
one
of
those,
but
there
are
many
others,
and
you
know
maybe
this
was
a
better,
not
a
bad,
but
maybe
it
wasn't
the
right
example
to
use,
but
but
but
it
kind
of
gives
a
picture
that
look.
M
G
Okay,
let
me
be
clear:
I
I
get
that
there's
a
general.
I
need
to
discover
functions
and
information
about
them
and
whether
that
falls
into
the
ietf's
purview
or
not
when
they're
really
applications
is
a
whole
different
debate,
and
I
wasn't
trying
to
go
there
but
sfc,
because
the
information
is
who
has
to
discover
it
and
who
has
to
know
it
is
so
specialized
seems
like
a
bad
example,
and
so
I
was
really
struck
by
the
example.
K
L
L
All
right,
so
it
could
also
be
that
applications
need
to
discover
server
memory
and
compute
resources
that
are
available
in
order
to
steer
packets
towards
them.
L
One
of
the
site
meetings
that
happened
this
week
was
dyncast,
which
I
thought
was
pretty
interesting,
which
is
trying
to
discover
ways
that
you
can
dynamically
steer
traffic
to
the
best
resource
in
order
to
find
what
that
best
resource
is,
it
would
be
helpful
to
build
to
have
data
provided
that
gives
information
about.
You
know
the
the
clock
speeds,
and
you
know
the
amount
of
cpu
cores
that
are
available
in
order
to,
in
their
use
case,
bill
to
have
rendering
tests
diverted
to
those
resources,
including
traffic
and
compute
offloading.
L
L
Okay,
this
also
can
be
included
in
a
you
know,
executing
a
process
so
in
a
supply
chain,
type
of
an
environment.
Let's
say
it's
either
trucks
or
on
a
conveyor
belt
in
a
factory.
L
L
It
needs
real-time
measurement
data
such
as,
in
this
case
temperature
to
execute
a
particular
process.
So
if
that
data
is
searchable
and
discoverable
quickly,
you
can
steer
that
in
this
case,
vaccine
to
a
new
path
to
get
to
a
hospital
or
somewhere
where
it
can
be
used
very
quickly
and
not
go
to
waste,
and
so
and
this
can
be
used
in
a
variety
of
types
of
process
execution.
L
L
Slide
the
itf
loves
to
hate
blockchain,
and
it
should
be
the
ledgers,
but
there
is
an
effort
that
is
going
on
and
there's
a
list
blockchain.interop
at
itf.org.
L
That
thomas
is
leading
and
he's
on
this
draft
that
I'm
discussing
right
now
as
well,
and
he
wrote
up
this
use
case.
The
effort
that
is
happening
right
now
is
being
able
to
find
interoperability
between
different
distributed
ledgers,
which
right
now
doesn't
exist,
and
so
there's
a
new
protocol.
That's
called
odop
odap
that
is
being
proposed
to
be
able
to
have
gateway
to
gateway
interoperability.
L
But
aside
from
that,
we're
thinking
that
it's
potentially
a
use
case
where
you
could
need
to
be
able
to
find
data
back
in
some
one
of
these
distributed
ledgers,
whether
it's
an
asset
or
you
know
an
actual
bitcoin
or
whatever,
and
be
able
to
have
that
discoverable,
and
so
that's
also.
We
think
a
potential
use
case
of
trying
to
find
that
data
and
make
and
be
able
to
have
the
network,
assist
and
being
able
to
find
where
that
data
is
next
next
slide.
L
So
elevator
data
is,
you
know,
being
collected
on
these
different
elevators
and
different
floors
with
regards
to
vibration,
temperature
speed
brakes
or
whatever,
and
it
would
be
good
if
that
data
is
discoverable
in
order
for
the
network
and
in
conjunction
with
the
app
to
take
an
action,
whether
it
is
with
regards
to
predictive
maintenance
or
maybe
in
an
emergency
situation,
where
you're
able
to
quickly
identify
a
particular
problem
with
a
speed
and
be
able
to
make
a
quick
action
on
that
and
being
able
to
have
that
data
discovered,
because
that
data
of
these
elevators
could
be
distorted
again
in
a
variety
of
places
on
the
edge,
and
we
just
may
not
know
where
to
find
it
in
ot
worlds.
L
They
have
their
own
contained
solutions,
proprietary
solutions
that
allow
them
to
build
to
provide
that
information.
But
when
you
open
it
up
to
ip,
then
there's
some
new
opportunities
there
next
slide.
So
this
is
the
last
slide.
So
we,
as
I
mentioned,
have
some
problems
that
we've
described.
L
This
draft
is
trying
to
describe
use
cases
as
clear
as
we
can
and
it
there's
there's
still
work
improvement.
That
needs
to
be
done,
but
the
next
step-
and
this
is
why
we're
here
is-
would
to
be
to
work
on
data
discovery
solutions
either
using
existing
technologies
and
protocols.
L
L
Everybody
else
is
extending
them,
so
maybe
there's
there's
an
opportunity
there
and
then
to
see
if
there
needs
to
be
some
protocol
extensions
or
a
new
protocol
needed,
or
maybe,
as
joel
kind
of
pointed
out,
maybe
in
some
use
cases
it's
there's
already
work
being
done
and
we
just
need
to
maybe
expand
that
a
bit.
B
Yeah
supporting
group
chair,
I
read
all
the
drafts
and
they
seem
to
be
bit
ocean
boiling.
I
mean
all
the
data
needs
to
be
discovered
by
everybody,
which
is
you
know,
not
very
meaningful.
So
the
question
to
you:
you're
in
routing
area
and
routing
working
group:
do
you
plan
to
narrow
down
your
use
cases
that
they
really
want
to
routing
specifically
and
at
least
identify?
L
Yeah
yeah,
so
that
yeah,
it's
being
that
the
next
step
would
be
to
start
thinking
about
a
particular
one
of
these
many
use
cases
and
a
particular
set
of
problems,
or
just
a
particular
problem.
Being
that
we're
starting
to
consider
the
solution
part
of
this.
This
is
why
we're
here,
and
so
maybe
there
are
some
routing
aspects
to
this-
that
need
to
be
need
to
be
developed
or
maybe
not,
and
so
that
next
step,
you
know
at
the
end
of
this
idf
we're
going
to
start.
L
You
know
evaluating
now,
like
you
know
what
would
be
some
solutions
that
would
be
able
to
satisfy
a
particular
problem
that
we've
identified
and
so
we're
looking
for
some
feedback
from
this
working
group.
B
So
before
I
pass
it
to
jeff,
what
I
was
trying
to
say
is
not
solutions
actually
narrow
down
your
problem
statement,
because
it's
too
generic
and
I
mean
we
are
happy
in
routing
working
group
to
provide
a
place
to
talk
about
new
problems,
new
solutions,
but
it
needs
to
be
narrowed
down
to
particular
cells.
That
is
routing.
L
Yeah
and
that's
understood
and
that's
kind
of
what
I
was
trying
to
say,
and
it
probably
it
just
depends
upon
which
way
you
want
to
go.
It's
being
that
we're
going
to
start
thinking
about
you
know
what
solution
may
help
solve
one
of
these
problems.
I
think
that
will
help
us
narrow
down
the
scope
as
we
as
we
start
thinking
about
what
some
of
the
available
solutions
that
exist
are.
I
As
juniper,
so
I
I
tend
to
agree
with
prior
comments
that
this
is
trying
to
boil.
You
know
very
large
sets
of
oceans,
but
the
two
general
oceans
that
I
think
are
the
interesting
ones,
are
you're.
Looking
at
a
general
directory,
slash
discovery
service
to
figure
out
what
are
the
interesting
things
I
want
to
get
and
over
your
use
cases
you're
getting
the
once.
I've
decided
I'm
interested
in
something.
How
do
I
actually
get
it
in
an
efficient
fashion
that
makes
sense
for
them
the
data
you
know.
I
Is
it
something
that
needs
to
be
sequenced
reliable?
Is
it
something
that
I'm
willing
to
get
a
periodic,
unreliable,
telemetry
stream
for,
and
certainly
the
second
piece
of
things
is
where
ietf
has
no
good
technologies?
I
So
I
think
that
directory
stuff
may
or
may
not
itself
be
within
the
context
of
ietf
the
other
items
you
have
to
decide
what
the
properties
are.
You
want
and
decide
if
you
actually
have
good
distribution
mechanisms
that
are
fits
for
technologies.
We
already
have.
L
J
Okay,
thank
you,
and
this
is
fanyang
from
huawei
and
in
this
draft
I
yes
in
this
draft,
we
introduce
an
associated
channel
over
ipv6
and
for
short,
we
name
this
associate
channel
as
ach,
and
we
limit
the
scope
to
ipv6
networks.
Next,
please.
J
The
higher
level
motivation
here
that
we
see
from
ibb
sport
to
mprs
and
from
npr's
to
fpv6
the
ipv6,
provide
the
connectivities
in
many
cases,
many
new
use
cases,
including
the
lexi
networks
and
also
there's
new
emerging
use
cases,
and
for
in
all
these
scenarios
that
we
recognize
that
ip
services
requires
higher
quality
of
rsa
guarantee
and
we
see
segment
routing
over
ipv6
provide
the
optimized
route
for
service
forwarding
wire,
the
routine
programming
capability
on
srh,
and
so
this
ach
is
proposed
to
provide
the
control
and
management
programming
capabilities
for
for
the
service
forwarding
and
later
we
will
have
some
examples
at
at
the
end
of
this
slide
and
to
show
the
applica
applicability
of
the
capab
applicability
yeah.
J
J
Data
is
transmitted
along
this
ip
pass
in
the
yellow
arrow,
and
you
see
the
blue
arrows
are
the
associated
channel
created
to
the
ip
pass
and
sorry
and
we
see
in
the
in
the
right
bottom
graph,
and
it
shows
where
this
ach
is
where
this
sh
is
in
one
network
node
and
the
control,
plane,
control
and
management
plane
generated,
generates
the
control
and
management
messages
and
it
is
incumbent,
sorry,
and
it
is
carried
in
the
associate
channel
and
transmitted
in
the
data
plan.
J
J
The
channel
type
specifies
the
type
of
the
control
or
management
quad
code
to
identify
the
path
to
identify
the
ip
path
and
also
associate
the
ip
path
to
the
ach
associate
channel
id
is
specified
and
in
the
and
the
messages
of
the
control
or
management
particles
are
carried
in
the
fixed
message
field
and
since
it
is
a
tlv
format,
so
this
sh
tlv
can
be
kept
encapsulated
in
ipv6
extension
headers
and
it
can
also
be
encapsulated
in
as
a
payload
in
a
synthetic
packet
and
later
I
will
give
two
two
examples
to
explain
the
applications
to
the
to
explain
the
end
to
end
and
how
bad
help
applications.
J
Okay,
the
first
use
case
is
we
we
call
it
unified
oem,
and
here
we
give
three
or
we
list
three
particles
of
used
for
the
oem
functions
and
we
also
identify
their
pro.
There
are
several
problems
there,
because
different
protocols
are
fulfilled,
different
oem
functions,
but
they
also
have
functions
overlapped
and
all
of
this
they
use
the
independent
session
identifiers
and
they
are
deeply.
J
They
are
deeply
encapsulated
in
ipip
packet.
If
there
is,
if
there
is,
there
is
any
intermediate
node
on
the
pass.
They
are
not
sensed,
they
are
not
aware
by
the
end-to-end
sessions
oem
sessions.
J
So
here
we
try
to
come
up
with
a
simple
solution
to
carry
the
different
oem
oem
messages
in
ach
in
the
epi
layer
and
also
in
the
in
a
uniform
way,
and
the
advantage
is
to
use
reduce
the
amount.
The
number
of
the
oem
particles
and
reduce
the
the
number
of
these
sessions
and
also
unify
the
session
identifier.
J
The
figure
below
shows
there
it
is.
There
is
a
end-to-end
end-to-end,
oem,
end-to-end
sh
how
how
how
and
ach
tlv
is
used
for
the
end-to-end
session.
Here
there
is
a
delay
management
delay,
measurement
type
of
ac
htlv
htrv
scout
is
encapsulated
in
the
ipv6
doh
header,
and
this
e2e
should
be
replaced
with
doh
and
with
with
the
sh,
with
the
sh
associate
chat
id
and
when,
when
r4
receive
this
packet,
and
the
sh
will
be.
L
J
And
the
second
use
case
actually
used
two
associate
channels
here
as
channels
here
when
and
the
first,
the
first
so
ach
channel
is
used
between
from
r1
to
r4,
so
r1
generate
fault
management.
A
type
is
htrv
and
encapsulated
in
the
ipv6
hub
by
hub
extension
header.
J
So
in
this
way
that
it,
the
the
every
node
on
this
ip
pass
will
be,
will
process
this
ach
trv
and,
for
example,
if
there
is
arrow
detected
on
our
r3
node
and
when
r3
node
process
this
htrv,
it
will
be
up.
It
will
update
the
the
shtre
to
set
the
flag
of
this
arrow
to
indicate
this
arrow
and
send
to
r4
and
on
our
offer
it
will
use
another
sh
tlv
to
to
indicate
this
indicate
this
fault
or
this
arrow
back
to
r1.
J
To
ask
for
this
switch
over
of
this
of
this
of
this,
I
of
this
user
data
forwarding
and
the
second
the
second
ach
is
actually
should
be.
It
is
used
for
the
end-to-end
use
for
the
end-to-end
session,
because
this
this
this
yeah
yes.
A
C
Sorry
to
interrupt
well
that
what
in
the
previous
slide
being
presented,
it
looks
as
a
combination
of
two
processes.
First
is
tailored
detection,
end-to-end
and
second,
is
protection.
Switchover,
coordination.
C
Using
rdi
functionality,
remote
defect
indicator
so-
and
this
is
not
a
new
problem
and
that's
been
solved
specifically
using
combination,
bfd
and
protection
switch
over
coordination
protocol
already.
So
that's
one
note,
but
my
general
question
is
other
one
that
udp
is
becoming
a
predominant
transport.
C
J
Yeah,
I
will
first
answer
the
first
question.
You
you
mentioned
that
there
yeah,
I
understand
what
you
have
described,
but
there
is
one
case
that
the
the
bfd
and
the
its
rdi
education
is
not
it's
not
exactly
in
soft
is.
If
this
error
is
not
a
failure
of
this
link
is
if
this
error
is
just
a
signal
degradation,
so
there
will
be
there's
not
there's.
No.
If
there
is
only
the
signal
degradation,
so
the
bfd
cannot
100
to
detect
this
dysfunction.
Detect
this
arrow.
K
C
The
currency,
okay,
it's
great
that
you
mentioned
this
scenario
so
basically,
what's
in
constant
betrayed.
C
Media
called
errored
seconds
or
severely
errored
seconds.
I
hope
I
will
have
a
presentation
time
in
ippm
working
group,
which
is
in
parallel
to
rtg
vg.
I
don't
invite
everybody
to
switch
there,
but
it's
been
scheduled
and
you
can
look
at
individual
draft
and
idp
and
working
group
on
error
performance
measurement
and
that
addresses,
I
believe,
your
scenario.
So
basically
in
combination
of
how
network
failure,
packet,
loss
and
delay
can
be
combined
together
and
expressed
as
a
single
metric.
J
Okay,
thank
you
for
the
pointer.
I
think
I
will
look
into
it
and
maybe
we
we
we
can
better
discuss
it
in
the
mailing
list
later.
J
Yeah
after
we
send
this
draft,
we
update
this
draft
and
we
receive
some
comments
and
I
want
to
give
the
feedback
to
the
comments
and
that
first
we
we
first
borrowed
this.
Yes,
we
borrowed
this
idea
from
the
mps,
gah
and
also
the
second.
Is
we
defined
this
this
ach
ingress
node
that
the
egress
node,
and
so
this
achtl
we
will
be
encapsulated
in
at
the
ingress
node.
That
is.
That
means
the
first
node
of
the
fp
forwarding
ipass.
J
So
there
will
be
no
no
confliction
to
the
rfc
82
820,
yes,
and
currently
the
scope
is
defined
to
for
epi
basics.
Maybe
there
are
some
suggestions
that
we
we
could
start
to,
focusing
on
the
on
the
ac.
How
ach
can
be
used
for
on
srv6?
J
J
J
Please
yeah.
The
next
step
will
refine
this
draft
based
on
the
comments
and
suggestions
and
maybe
yeah
and
start
the
application
start
to
specify
the
how
the
applications
used
by
used
in
by
ac
by
sah
yes
used
in
with
sh,
yes
yeah.
That's
it.
A
Okay,
thank
you.
If
there
are
we'll
give
a
moment
for
anyone
to
come
to
the
mic
for
questions,
but,
okay
thanks
shall
we
move
on
to
changly
presenting.
B
F
A
F
Oh
yeah
yeah.
Sorry,
I
get
it
right
now.
So,
okay,
thanks
the
motivation
yeah.
The
motivation
of
why
we
propose
ipv6
base
cln.
Is
that,
as
you
know,
with
the
development
of
cloud
computing
right,
the
connections
between
the
the
enterprise
network
sites
and
the
clouds,
especially
like
the
third
party
public
cloud,
are
added.
F
So
it
will
introduce
some
new
requirements
and
act
and
challenges
for
to
the
existing
networks
and,
as
you
can
see,
that
the
draft
net
to
cloud
problem
statement
have
has
described
some
problems
and
challenges
that
the
existing
network
facing
today
of
how
to
handle
the
interconnection
between
the
ddd
enterprise
branch
offices
and
the
third-party
clouds,
with
the
dynamic
workloads
in
their
vpn
right
and
also
in
this
document.
F
We
we
also
describe
some
extra
challenges,
such
as,
as
we
know
that
if
you
are
using
the
option
a
in
the
intel
as
right,
it
is
really
hard
like
to
configure
the
vpn
right.
So
the
second
one
is
that
if
we
are
using
the
vxlan
to
connect
the
different
branches-
and
as
you
know,
we
cannot
specify
the
underlay
forwarding
pause,
because
the
vxlan
is
only
like
overlay
protocol
right.
So
the
straight
te
requirements
like
the
deterministic
delay
and
like
specific,
pass
forwarding
something
like
this.
They
cannot
be
guaranteed
right.
F
So,
in
order
to
address
this
kind
of
issues,
we
propose
ipv6
based
cloud
oriented
networking.
So
in
this
document
we
describe
the
challenge
of
of
the
networks
facing
today
and
we
also
list
the
requirements
that
ipv6
based
seo
should
specify
satisfied
and
we
also
list
some
like
candidate
solutions.
Yeah
next,
please
so,
audible,
ipv6
based
con
is
a
networking
architecture
that,
first
of
all,
it
is
a
ipv6
based
networking
right
and,
secondly,
it
is
designed
for
the
cloud
yeah.
F
F
The
first
one
is
the
underlay
and,
as
you
can
see
from
the
figure
one,
we
drop
a
typical
taco
cloud
topology
right
here
we
have
dc,
we
have
remote
region
dc
and
we
have
core
dc
something
like
this
and
how
to
deploy
the
quick
connection
from
end
to
end
even
travel,
multiple,
like
data
center,
it's
a
really
house,
a
critical
issue
for
us
right
now
and
sometimes
we
need
to
deploy
like
service
function,
chaining
within
the
like
htc
or
the
gi
ln.
Something
like
this.
F
So
you
know
it's
really
hard
to
support
sfc
in
the
appears
networking
right
now
and
regarding
the
overlay
part,
we
we
describe
a
typical
scenario,
which
is
sd1
right
in
sd1
scenarios.
Sometimes
we
will
use
the
vxlan
to
connect
different
like
signs
and
between
the
pop
gateway.
Something
like
this,
but
in
this
case
the
streety,
like
this
kind
of
requirements,
cannot
be
satisfied
right.
So
next.
F
F
F
And
I
will
go
really
quick
to
go
through
the
whole
requirements
and
solutions
to
to
make
a
quick
picture
for
us
for
all
of
us
right.
So
for
quick
connection.
As
you
know,
the
clouds
were
located
in
any
location
around
the
world
so
and
and
the
people
we
try
to
connect
the
cloud
in
anywhere
anytime.
F
So
this
is
about
a
hyper
net
network
connection,
as
you
know
that
the
connection
between
the
clouds
and
the
enterprise
sites
may
travel
multiple
types
of
networks
such
as
ipv4
and
amperes
and
and
srv6
ipv6,
something
like
this.
So
we
have
to
support
end
to
end
like
ipv6
folding,
at
least
and
if
possible,
if
we
can
support
engine
srv6
forwarding
that
would
be
fast
right
and
in
order
to
in
inter
working
and
with
between
those
kind
of
different
type
of
networks.
F
F
Yeah
past
programming,
we
don't
need
to
say
too
much
like
we
need
the
traffic
to
get
to
to
be
forwarded
following
the
specified
post
yeah,
so
candidate
solution
could
be
like
srv6
or
some
peers,
but
in
this
draft
we
say
that
we
win
srv6
because
it
is
ipv6
based
network.
Next.
F
Yet
maybe
we
can
add
more
solutions
into
this
draft
so
and
then
this
draft
is
really
a
beginning
of
the
draft,
so
we
need
more
comments
and
we
need
more
contributions
and
welcome
yep
next.
F
F
F
Next
yeah,
so
performance
measurements
is
the
basic
requirements
of
any
network.
So
there's
nothing
special
here
and
we
suggest
to
use
the
in-band
pm
or
own
pass
p
and
anything
you
can
call
it
and
and
for
example,
like
ipv6
alternative
attack
alternate
marking
or
I
fade
iom.
Something
like
this
yeah
next.
F
So
this
part
is
about
the
reliability
release,
some
solutions,
such
as
bfd
for
end-to-end
protection
and
fr
for
local
protection
like
midpoint
protection,
egress
protection-
something
like
this,
and
we
also,
as
you
can
see,
that
we
have
some
work
of
redundancy
protection.
So
we
also
include
this
kind
of
protection
mechanism
in
this
draft
yep.
Next
lena,
I
will
go
through
the
whole
slice,
very
quick
and
you
can
ask
later
yeah.
F
Thank
you-
and
this
part
is
about
security-
nothing
new
here
and
I
think
we
should
not
introduce
any
new
kind
of
security
issues,
threats
into
the
crn.
Yet
next.
F
Yeah,
this
part
is
about
the
folding
efficiency
it.
It
is
really
important
because
you
know
in
the
multi-tenants
scenarios
the
tenants
will
run
like,
for
example,
a
lens
light
right.
F
In
this
case,
the
folding
efficiency
for
the
tenants
will
be
very
like
important,
critical
right.
So
we
provide
two
dimensions
of
solutions
to
address
the
forwarding
efficiency
issues.
F
The
first
one
is,
we
have
to
discuss,
discover
the
plus
mtu
along
the
pulse,
so
we
can
set
the
appropriate
mtu
for
the
packet
right,
and
the
second
part
is
that,
if
we're
using
the
srv6
for
forwarding,
the
compression
mechanism
should
be
applied,
such
as
tier
76
and
by
the
way
we
have
over
10
vendors
has
have
support,
gs,
invest
tier
basics
right
now,
and
you
can
see
more
news
in
the
near
future.
Yep
next.
F
So
the
last
one
is
application,
aware
networking.
Yet
in
ipv6
pace
cln
we
will
have
many
types
of
application
traffic
right,
so
they
will
have
various
queues
requirements.
So
we
should
provide
five
granted
hosting
fire
granted
traffic
steering
mechanism
for
this
kind,
yeah
yeah
yeah
for
the
traffic.
So
we
we,
we
add
apn
6
as
a
candidate
solution
here
and
if
you
have
more
like
kind
of
solutions,
we're
going
to
discuss
with
us
yeah
next.
F
Yep
last
next
step
welcome
welcome
to
commons
linda,
and
we
we
are.
We
are
looking
for
more
collaboration
on
this
draft
it
because
it
it
is
really
a
beginning
of
this
draft
and
if
you
have
more
mechanism,
solutions
welcome
to
contribute
to
the
to
the
draft
yep.
Thank
you.
K
Okay,
thank
you
very
much
for
the
presentation,
so
I
have
a
couple
of
comments.
It
seems
to
be.
This
draft
covers
a
lot
of
things
and
it
seems
all
the
network
technology
developed
by
ietf
is
under
this
scope.
Okay,
but
I
feel
this
too
big,
maybe
it's
better
to
break
the
draft
into
some
smaller
ones.
K
For
example,
when
we
talk
about
cloud
oriented
networking
right,
so
if
we
talk
about
public
cloud,
then
you
want
to
have
longer
distance,
because
public
cloud
data
centers
are
far
apart
from
the
enterprise
and
that
technology
needed
for
that
is
quite
different
from
like
say,
edge
computing
like,
for
example,
in
the
5g
edge
computing
environment,
where
the
mini
data
centers.
Well,
they
also
called
cloud
are
very
close
to
each
other.
So
it's
a
local
data
network.
It's
a
smaller
domain
like
for
mission,
critical
applications.
N
K
Different
domains,
you
may
need
apply
different
things
in
there
to
make
it
the
draft
more
concrete.
Okay,
this
is
this
particular
domain
for
this
domain.
We
need
technology,
one
two,
three,
four
for
the
other
one.
We
need
three,
four
five
six,
something
like
that,
I
think,
will
be
better
easier
to
focus.
N
Hi
ron,
I'm
trying
to
figure
out
what
the
what
the
ultimate
goal
of
this
draft
is.
Are
you
building
a
network
architecture
for
network
operators
and
cloud
providers
to
implement,
or
are
you
suggesting
the
development
of
some
new
routing
mechanism,
then,
if
the
former
is,
is
this
the
right
forum
in
the
routing
area
working
group?
Yes,
if
the
former
is
this
the
right
venue
or
maybe,
is
it
something
that
should
be
in
the
ops
area.
F
Okay,
so
ron
as
you
can
see,
this
is
the
architecture
draft
of
con
right
now
we
were
trying
to
find
the
gap
of
the
con
and
existing
networks,
and
we
have
least
some
existing
results
right
here
right
and
we
need
more
input
to
find
where's
the
difference
between
the
ceo
and
existing
network,
and
maybe
we
can
find
more
like
gap
right
there
and
we
get
more
new
mechanism
to
address
this
kind
of
issues
and
we
will
need
more
mechanisms.
A
A
O
A
O
Okay,
let's
go,
this
is
the
last
presentation
and
I
won't
make
it
too
tough.
This
is
josue
from
huawei
and
I
will
introduce
our
work
about
srv6
middle
point.
Protection
I
noticed
wrongly,
is
raising
his
hand.
Do
you
have
any
question
for
this
presentation.
O
O
O
So
why
we
need
srv6
midpoint
protection
in
a
srv6
network
when
an
endpoint
indicated
in
the
srv6
policies
failed.
Other
existing
fr
mechanisms,
for
example,
tlfa
also
defined
in
rtgwg,
can't
protect
the
failed
node,
because
the
current
ipv6
destination
address
is
pointing
to
the
failed
node
srv6
end
to
end
protection
with
efd
could
work
in
this
scenario,
but
local
mechanisms,
which
is
faster
and
easier
to
deploy,
is
also
requested.
O
O
O
Please
so
what
is
the
mechanisms
in
detail
when
we
we
define
this
in
two
cases
when
the
repair
node
is
adjacent
to
the
failed
end
point?
The
repair
node
excludes
the
behavior
defined
in
the
pseudoware
shown
in
the
picture
here.
O
If
the
active
segment
is
not
the
last
segment
in
srh,
first
decrease
the
segments
left
by
one
update
ipv6
destination
with
the
next
segment
or
some
segment
after
the
active
segment
in
the
second
list
and
fib
lookup
on
the
updated
destination
address
and
forward
packet
according
to
the
matched
entry,
you
can
notice
that
this
is
almost
the
same
as
the
end
function
defined
in
rc8986.
O
O
This
case
will
happen
when
igp
convergence
has
already
have
happened,
and
the
repair
node
excludes
the
similar
behavior
as
as
the
just
introduced
above
so
next
page.
Please.
O
It's
okay,
okay,
and
in
this
document
we
introduced
section
five
and
section
six
of
which
section
5
is
about
determining
whether
the
endpoint
could
be
bypassed
or
not.
The
section
6
is
security
considerations.
Both
sections
could
be
used
for
a
security
guarantee
in
section
6.
The
document
requests
required
node
and
the
failed
node
must
belong
to
the
same
trusted
domain,
which
making
the
srh
could
be
changed
safely
by
the
repair
node.
O
In
section
five,
the
document
request
to
ensure
the
security
related
segments
can't
be
bypassed
by
the
proxy
forwarding,
even
when
the
corresponding
node
or
link
is
failed.
So,
but
the
the
mechanisms
request
by
this
scenario
is
defined
in
another
document
and
the
the
draft
id
is
listed
here
next
slide.
O
Please
here
we
list
the
questions
that
have
been
received
since
last
itf.
All
these
questions
have
already
been
answered
in
the
mailing
list
before
just
to
discuss
these
questions
in
the
working
group.
Again,
we
think
this
is
necessary
and
meaningful.
The
first
question
is
how
to
differentiate
whether
the
failed
node
is
the
fail.
Failure
is
note
down
or
linked
down,
generally
link
failure
and
no
failure
are
both
treated
as
node
failure
in
this
document,
just
as
our
fr
mechanisms.
O
The
second
question
is
about
what
function
of
the
failed
node
could
be
excluded
in
the
repair
node,
because
the
proxy
behavior
is
for
pass
repair
which
only
guarantees
the
reachability,
so
other
functions
can't
be
replaced
or
proxied
only
the
end
function
is
excluded.
O
The
third
question
is:
could
te
pass
be
changed
when
doing
protection?
Actually,
this
is
a
very
general
question.
We
believe
the
middle
point
protection
is
a
temporary
status,
so
it's
just
for
a
temporary
reachability
repair.
When
failure
happens,
unity
pass
if
sla
of
the
t
pass
is
supposed
to
be
guaranteed
during
the
process.
End-To-End
protection
could
be
considered.
So
it's
another
story,
maybe
after
the
local
repair
happens
next
slide.
O
P
Bruno
is
speaking
as
a
sprinkle
chair,
so
the
the
scope
on
the
goal
is
a
very
spring
specific
because
it
it
exists
only
because
you
have
a
list
of
segments,
then
the
mechanism
is,
is
a
bit
heavy
on
a
76
online
on.
G
O
O
O
Actually,
this
is
a
topic
we
have
discussed
before
with
other
orders.
We
are
little
confused
now
about
where
to
discuss
this
document
actually,
because
this
document
has
been
discussed
in
rtgwg
several
times.
So
in
this
stage,
maybe
we
prefer
to
put
it
here,
although
we
also
believe
spring
is
another
good
home
for
this
document,
but
we
are
also
willing
to
to
present
the
mechanisms
to
spring
if
necessary,
but
considering,
for
example,
tifa
is
also
defined
in
rtgwg,
and
this
document
is
informational.
O
It's
just
about
the
the
the
forwarding
behavior,
considering
the
local
repair,
so
also
we,
we
would
like
to
hear
the
the
chairs
otherwise
bruno
your
advice
is
really
helpful
and
maybe
some
discussions
about
the
the
documents
home
is
deserves
more
discussion.
B
Yeah
I
mean
I
may
interrupt
here.
I
believe
we
had
intentions
to
meet
and
discuss.
There
are
about
six
or
seven
different
drafts
on
midpoint,
endpoint
protection
that
are
being
discussed
between
spring
and
rtgwg
bruno.
Should
we
take
an
action
point
to
actually
meet
between
the
38th
and
next
atf
and
discuss
all
those
drafts.
P
P
A
So
I
would
say
up
until
this
point,
your
your
work
has
not
been
in
vain.
You
know
it's,
it's
mostly
the
same
people
attending
this
meeting
as
attending
spring
as
well,
and
so
any
discussion
that
you've
had
it's
not
like
you'll
have
to
like
start
over.
You
know
it.
It's
already
been
a.
You
know
useful
work
right,
but
if,
if
I
mean
it's
a
positive
thing
to
have
the
spring
working
group
chair
say
that
he,
you
know
he
thinks
it
should
be
over
in
spring,
because
at
least
that
means
he
thinks
it's
important
work.