►
From YouTube: IETF-MPLS-20230713-1400
Description
MPLS meeting session at IETF
2023/07/13 1400
https://datatracker.ietf.org/meeting//proceedings/
A
B
B
C
We
are
waiting
a
bit
more
to
get
to
the
usual
number
of
attendees
that
we
see.
We
are
right
now
at
10
attendees
and
hopefully
that
will
increase
soon
and
we
will
get
started
soon.
C
C
C
C
And
it
seems
we
have
lost
lost
one
one
Warrior
along
the
way.
We
are
at
nine
attendees
right
now.
Quite
a
few
of
your
usual
attendees
are
not
sure
not
shown
up
yet.
D
C
B
C
All
right
so
welcome
to
mpls
network
action
interim
meeting
part
of
the
series
of
open
calls
that
we're
having
every
week.
This
is
a
collaborative
work
between
three
working
groups:
mpls
files
and
debtnet.
C
We
are
presenting
the
note
12,
because
this
is
an
official
interim
meeting
and
please
get
acquainted
with
this
note.
It
covers
the
rules
and
regulations
of
contributions
to
ietf.
C
Do
you
some
useful
pointers
there
in
case
you
needed
them?
You
can
find
them
on
this
slide.
C
So
right
on
to
the
discussion
today,
we
we
have
four
items,
and
the
last
usual
item
is
an
open
item
for
anyone
to
add
to
the
agenda.
D
C
All
right,
so
we
will
go
through
the
agenda
to
the
first
item,
which
is
reviewing
the
action
items
that
we're
tracking.
We
have
to
open
items,
action
items
that
are
still
open.
The
first
one
is
to
continue
the
investigation
on
the
intersection
of
M
A
with
existing
mpls
features.
Last
week
we
had
a
discussion
on
that
net
with
Mna
on
that
net,
with
yeah
with
m
a
and
that
was
given
by
Greg.
So
hopefully,
there
will
be
similar
investigation
with
other
features.
That
mpls
supports
it's
an
open
item
and
you
feel
free.
D
C
C
So
let
me
do
that,
while
I'm
presenting
we
are
taking
notes
today
for
the
minutes
on
this
Wiki.
C
You
should
have
received
a
a
text
node
in
the
chat,
okay,
so
the
second
action
item
that
all
right.
Sorry,
two
in
the
case-
yes,
yes,
yeah,
we
I
see
two
two
people
in
the
queue
and
Lois
at
the
top
go
ahead.
B
C
I
think
this
is
a
good
question.
Yeah
I
I
would
like
to
see
a
similar
presentation,
but
I'm
not
sure
if
we
have
anyone
on
the
call
that
you
know
or
maybe
like.
E
C
Okay,
so
let's
move
on
to
Stuart
and
then
to
Greg
anything
else,
Lua.
E
D
Yes,
actually
I've
done
some
work,
I've
done
work
on
beer
and
if
beer
chairs
would
agree,
I
would
be
glad
to
make
a
presentation
on
dear
in
mpls
how
it's
encoded.
What's
there
and
what's
expected
so
time
wise,
probably
that
would
be
after
ITF,
meaning
if
that's
okay,.
E
So
so
so
mine
was
just
a
a
a
an
FYI
question.
You
said
that
the
slides
are
archived
are
in
the
mpls
wiki
area.
Aren't
they
archived
automatically
as
part
of
the
the
fact
that
this
is
an
interim
meeting?
Don't
they
go
into
a
bundle
associated
with
each
interim
meeting.
C
That's
a
good
question:
Stuart
I
think
the
material
that
we
upload
is
saved
and
that's
my
feeling
I
can
double
check
that,
but
the
slides
Greg
at
that
time
did
not
upload
them,
so
we'll
have
to
see
a
way
to
upload
them.
So
the
slides
were
presented
during
the
session,
we'll
have
to
see
if
we
can
upload
them
after
the
interim
has
passed.
B
D
C
Okay,
all
right
and
the
next
action
item
that
we
have
and
we're
tracking
is
the
updates
that
we
need
to
do
to
m
a
working
group
graph
documents.
C
And
basically,
if
there's
you
know,
there
were
multiple
discussions
about
multiple
isds
in
the
packet
and
so
on,
and
we're
there
were
things
that
that
were
not
clearly
spelled
out
in
the
requirements
to
a
draft.
So
there
was
an
action
item
to
for
the
authors
to
validate
at
least
this
is
covered
so
last
week,
I
did
promise
to
send
a
summary
of
the
discussion
to
the
working
group.
C
Mailing
list
I
have
not
yet
and
I'm
willing
to
do
that
this
week,
or
maybe
towards
the
end
of
this
week.
C
C
E
No,
no
I
just
put
up
put
the
microphone
on
so
that
I
could
tell
you
if
someone
was
trying
to
get
in
the
in
the
queue,
because
it's
hard
for
you
to
see
it
I
think.
C
Okay,
all
right:
these
are
the
action
items
that
I
am
tracking
and
we
possibly
have
a
new
one
today
for
the
beer
presentation,
so
I'll
move
on
to
the
next
item
on
today's
agenda,
so
I
do
have
a
slide
coming
up
on
a
part
of
this
set
of
slides
and
I
need
to
switch
to
a
different
set
of
slides
for
Steward
I'm
okay
to
go
through
this.
Do
you
mind
if
we
continue?
C
Sorry,
yeah
I
I
should
have
noted
the
shuffling
before
the
meeting
okay.
So
this
is
one
slide.
I
composed
I
was
discussing
with
with
Loa,
and
we
have
some
open
questions
on
M,
A
and
I
want
to
make
sure
that
at
least
we
are
all
aware
of
them,
and
not
necessarily
then
answers.
But
the
questions
are
there,
so
usually
the
if
the
flow
of
mpls
packets,
a
single
flow
will
have
the
same.
C
C
So
this
will
this
can
have
impact
on
these
classic
routers
if
they
continue
to
Hash
on
the
full
stack.
The
first
you
know,
I
had
to
open
questions
like
I
mentioned,
which
of
the
following
could
be
true
m.
A
header
mandates
getting
entropy
label
as
a
network
action
and
all
mne
capable
lsrs
must
hash
or
process
on
the
entropy
label,
as
opposed
on
the
full
stack.
So
that
could
be
a
true
or
false
statement.
C
I'm,
not
I'm,
I'm,
open
to
pausing
and
seeking
you
know,
opinions
and
I
can
continue
the
whole
slide,
and
then
you
know
people
can
can
ask
questions
or
sound
opinions
at
the
end.
So
my
feeling
is,
let
me
continue
and
see
what
happens
towards
the
end.
So
the
second
statement
is
m.
A
packet
must
only
Traverse
M
A
capable
lsrs.
C
C
The
other
alternative
is
the
third
statement
is
m:
a
packets
carry
the
the
usual
the
classic
Alie
El,
along
with
m
a
header
that
was
discussed
in
the
past
and
that
can
have
an
implicational
size
of
the
label
stack,
but
it
has
an
advantage
that
non-emini,
capable
other
stars
can
still
hash
on
the
entropy.
C
C
C
And
the
last
statement
is
you
know?
We
know
that,
even
if
we
select
the
primary
path
to
be
all
M
A
capable
during
transient
Network
conditions,
some
M
A
packets
may
be
detoured
or
rerouted.
And
how
do
we
ensure
that,
after
such
transient
conditions,
the
the
packets
continue
to
be
forwarded
by
m
e,
capable
lsrs
foreign.
E
Bullet
three
bullet
one
as
it
were
no
numbers
on
them
right,
so
I,
I
I
think
it's
unreasonable
to
suppose
that
this
only
goes
into
a
pure
new
new
build.
And
thus
you
have
to
have
a
non-entropy
processing
packets
in
the
system,
and
you
probably
have
to
have
none
El
capable
routers
in
the
in
the
system,
which
I
think
means
that
bullet
3
has
to
be
of
the
form
that
all
lsrs
on
the
path
use
El
for
ecmp.
E
C
Yeah
but
okay,
that
that
I
understand
and
and
the
challenge
is
like
you
said
some
lsrs-
don't
support
Eli
today,
right.
A
Hi,
so
my
read
of
this
is
slightly
different
and
so
I'm
going
to
say
five
none
of
the
above
there.
The
situation
is
way
more
complicated
than
you
make
it
out
to
be,
and
there
are
many
variables
which
are
orthogonal,
which
you
have
not
described
very
clearly.
So
let
me
take
a
stab
at
doing
this
in
a
logical
way.
A
First
of
all,
the
question
is
whether
El
is
necessary
whatsoever.
Obviously,
if
ecmp
is
not
used
on
the
path,
El
is
not
required,
and
so
that
becomes
irrelevant,
assuming
El
is
is
required.
Then
the
question
becomes:
is
El
useful
at
every
Hub,
it's
very
very
likely
that
ecmp
is
not
used
at
every
hop.
If
it
is
only
used
at
hops
that
support
M
A,
then
you
can
put
El
in
the
m
a
header
and
you're
just
fine.
C
Can
I
pause?
Do
any
I
know
you're
you're
trying
to
rebuke
all
the
points,
but
can
we
stop
at
one
point
because
I
need
clarity,
please,
okay,
so
you're,
saying
that
we're
fine
if
we
carry
the
entropy
label
in
the
m,
a
action
right
that
that
that's.
D
C
A
C
C
A
A
C
A
C
That's
interesting
proposal
there
we'll
have
to
see
if
that
can
be
respected
by
all
lsrs.
Okay.
A
E
E
E
A
A
D
Thank
you,
so
I
have
a
question
about
number
two,
because
what's
a
what's
the
scenario.
C
Yeah
I
can
try
to
answer
that,
so
there
are
two
cases
indeed,
then
the
action
is
edge
to
edge
and
and
then
the
the
m
e
headers
exposed
at
the
edge.
You
know
the
at
the
egress
and
there
are
hop-by-hop
actions,
and
in
that
case
the
m,
a
header
mean
not
the
at
the
top.
C
Both
cases
and
and
the
discussion
here,
the
hopper
hop
action
is
more
relevant.
D
Well,
because,
as
I
understand,
what
we're
trying
to
convey
is
that,
when
a.
G
D
Is
or
some
system.
G
D
So
it's
should
should
ensure
that
m
a
will
be
accessible
only
to
capable
M,
A
capable
lsrs,
so
I
think
that
would
be
different
from
their
statement
too,
because
statement
2
says
that
any
none,
M,
A
capable
osr
must
not
be
traversed
by
mpls
packet,
with
the
stack
that
contains
m
a
so
right.
If
else,
if
osr
is
not
M
A
capable
but
is
not
really
M,
A
is
not
at
the
top,
then
I
don't
see
why
it.
It
has
to
be
so
restrictive.
D
Well
again,
that
is
depends
on
the
action
because
I
would
say,
for
example,
iam
it's.
If
it's
supported
in
ISD,
then
it's
useful,
but
it's
not
mandatory,
so
we'll
collect
information
from
those
nodes
that
are
capable
of
supporting
m
a
I
am.
But
if.
G
C
Again,
for
then
I
think
what
you're
hinting
to
is.
Mutable
data
should
not
be
in
the
stack
and
in
this,
and
basically
we
don't
have
a
problem
of
the
stack
changing
for
pocket.
How
many
packets
right,
I
think
that's
what
you're
hinting
to
is
we
don't
want
to
change
the
label
stack
on.
D
The
phone
well
I,
I
I,
think
it's
as
Tony
pointed
out.
The
real
picture
would
probably
would
be
much
more
complex.
Is
this
statements?
D
So
it's
it's
again
at
this
time.
At
this
point,
I
cannot
really
answer
the
questions,
yes
or
no.
The
only.
C
D
C
The
point
of
triggering
these
questions
is:
there
is
no
clear
answer,
so
if
this
produces
Clarity,
then
the
objective
is
reached
and
not
after
you
know
immediate
answer
for
true
or
false.
But
if
there's
some
clarity
somewhere,
it
would
be
useful,
so
Joel
you're
at
the
top
of
the
queue
go
ahead.
G
Okay,
I,
you,
you
dealt
a
little
bit
with
one
of
the
important
points.
We
need
to
be
very
clear
when
we
are
talking
about
m
a
hop
by
hop
actions
and
when
we
are
talking
about
selective
or
end
to
end
actions,
because
the
implications
on
intermediate
processing
nodes
are
different
note.
If
the
selective
is
not
just
under
the
top
label,
nobody
else
cares.
It
doesn't
matter
if
they
don't
plot
process
it
with
hop
by
hop
if
in
the
visible
region,
you're
expected
to
look
at
it.
G
G
Sticky
in
ffrr.
Well,
you
know
those
pads
have
those
packets
have
already
taken
a
different
path
from
the
packets
that
didn't
get
rerouted
and
the
fact
that
the
label
stack
may
be
different
because
of
that
is
probably
not
a
fatal
issue,
whereas
packets
that
are
expected
to
be
taken
the
same
path.
You
start
messing
with
the
label
stack
at
least
a
more
nuanced
question
and
in
some
of
the
comments
people
said
well,
you
should
know
whether
the
ecmp
is
being
applied
or
whether
all
the
nodes
are
M,
A
capable.
G
You
can
know
whether
they're
they
can
do
M
A,
but
we're
not
as
I
at
least
don't
assume
that
we're
doing
strict
paths,
because
that
seems
excessive,
and
this
whole
thing
is
an
example
of
why
a
detailed
write-ups
are
much
more
useful
than
one
slide.
I
get
tired
enough
of
Ericsson
trying
to
answer
to
ask
complicated
questions
in
slides.
E
Hear
me
again
so
I'd
like
to
suggest
a
a
a
an
algorithm
that
would
probably
work
and
that's
that
if
there
is
changeable
data
in
the
packet,
then,
if
each
node
on
the
path
is
m,
a
capable
you
can
you
do
not
need
an
Eli.
You
could
have
ecmp
information
inside
the
m
a
portion.
E
Otherwise,
in
other
words,
you
are
not
sure
that
every
hop
that
the
packet
will
go
through
is
m
a
capable.
You
must
include
the
El
stroke
Eli
in
order
to
ensure
the
path
I.
Don't
think
it
depends
on
whether
this
is
end-to-end
or
hot
by
hot
Joel.
I
think
it
depends
on
whether
you
have
changeable
data,
not
because
nodes
that
do
not
understand
M
A
will
be
trying
to
make
their
ecmp
decision
so
yeah.
That's
my
that's!
E
A
Okay,
let's
see,
let's
start
with
talking
about
MMA
capability,
so
I,
where
I
thought
we
left
off.
We
had
several
cases
we
have
to
worry
about.
There
are
Legacy
nodes
who
may
barf
when
they
see
the
m
a
label
at
all,
and
if
you
have
Legacy
nodes
like
that,
then
you
cannot
deploy
M
A
on
that
path.
A
H
Cash
hi
so
and
just
one
small
point
about
using
the
label
stack
for
the
CMP.
H
So
if
we
are
using
Instax
ancillary
data,
we
have
repurposed
TC
and
TTL
Fields.
So
there
are
bits
there,
3
plus
8,
11
bits
that
can
be
muted
without
impacting
the
acmp.
If
there
is
a
need
to
have
something
in
ISD
that
changes
without
affecting
EC
thanks.
C
Okay,
so
so
I
think
there's
a
lot
of
feedback
coming
in,
and
some
of
it
is
clear.
Some
of
it
is
needs
more
discussion.
I
am
just
wondering
if,
if
we
need
to
elaborate
in
the
documents
or
clarify
further
these
points,
some
of
them
we're
saying
that
we
need
to
take
action
on
so
maybe
I
can
track
this
within
yeah
I
would
like
to
hear
more
feedback
on
that
front.
Rakesh
go
ahead.
C
H
That's
the
other
point
that
if
it
has
it
on
the
full
label
stack,
you
could
use
mutable
data
into
repurposed
tctr
Fields
without
affecting
ecmp
I.
H
There
are
labels
like
there
are.
The
32
bits
of
LSC
has
20
bits
of
labels,
and
other
ones
are
tctl,
so
hashing
happens
on
the
20
bits
of
the
labels
right,
so
it
doesn't
use
the
ttltc
fields
for
hashing.
So
if
you
are
changing
bits,
for
example,
next
faster
route
or
alternate
marking
or
what
are
the
other
purpose,
it
will
not
affect
acmp.
This
person.
H
A
A
A
A
C
I
still
would
like
to
see
I
mean
I'm.
What
you're
saying
is.
Maybe
we
should
have
a
discussion
on
the
mailing
list
and
I
I
I
would
like
that
as
well,
and
if
we
can
close
all
the
items,
I'm
happy
no
but
I
see
you're
still
raising
your
hand,
so
go
ahead.
Tony.
A
E
That's
what
I
I
agree
with
Tony
on
that
last
point,
and
what
I
was
going
to
propose
is
that
you
trigger
a
discussion
on
this
on
the
list.
If
that
is
as
simple
as
just
pre-publishing
this
slide
as
text
to
start
off
the
discussion,
then
that's
certainly
one
way
of
doing
it.
I
think
Tony
would
like
to
see
more
text
associated
with
each
point.
But
I,
either
way.
The
right
thing
to
do
I
think,
is
to
move
this
discussion
to
the
list.
C
E
E
Where
it
was
asserted
that
once
a
packet
has
been
fast
rerouted
past
the
failure
and
back
onto
the
normal
path,
the
NFR
flag
was
no
longer
needed
and
could
be
cleared
and
then
and
that
it
was
safe
after
that
for
further
NFR
or
further
Factory
reactions
to
take
place.
E
If
I
misunderstood,
then
please,
please
correct
now
and
I
think
I
remember
at
the
time
arguing
that
the
concept
of
a
second
failure
attempting
a
second
repair
was
contrary
to
the
established
fast
reroute
philosophy
and
that
it's
only
safe
to
repair
against
the
set
of
postulated
failures
that
the
frr
action
was
calculated
for
and
if
any
further
failure
was
observed
anywhere
in
the
network
we
had
to
to
use
the
Expression
we
we
used
in
the
development
of
it.
We
had
to
abandon
all
hope,
ceased
all
fast,
reroute
and
reconversion.
E
The
network
using
the
standard,
best
effort
approach
so
and
I
couldn't
remember
at
the
time
the
exact
an
example
condition
that
for
this
so
go
to
the
next
slide.
E
Right,
so
this
is
a
fragment
of
a
network.
It's
an
old
Network
that
was
fragmented,
but
it
is
just
you
know,
use
the
terminally.
The
FR
term
is
a
network
fragment
so
in
this
fragment
to
make
life
easier,
I'm
going
to
have
H,
which
is
a
multi-home
prefix.
If
people
want
to
rule
multi-home,
prefixes
out
of
scope,
I
will
simply
use
prefix.
A
and
I
will
have
some
routers
that
go
between
the
H
on
the
left
and
the
H
on
the
right
and
I
know.
E
We
almost
certainly
have
more
than
one
routers,
because
we
always
use
more
than
one
router
to
prevent
hidden
exchanges
between
adjacent
routers,
which
can
sometimes
be
used
to
sort
of
bypass
complex
to
work
around
strange
events
right
so
I
have
two
a
a
prefix
on
the
left
and
prefix
same
prefix
on
the
right.
I
have
two
plrs
plr
one
and
plr2.
These
are
normal
routers
when
they're
not
preparing,
but
I
used
one
common
term
for
them
in
in
both
of
them
modes.
E
I'm
going
to
assert
that
the
cost
from
plr
one
to
X
is
equal
to
the
cost
from
plr2
to
Z
and
that
the
paths
have
multiple
nodes
to
prevent
any
sort
of
cheating
and
collusion
and
that
all
cast
all
costs
are
one
except
for
the
cost
between
plr
one
and
x
and
plr2
and
z
Oh
by
the
way
and
all
path
costs
are
symmetric
because
that's
another
way
of
introducing
strangenesses
to
these
systems
all
right.
So
this
is
a
really
simple
Network
equal
cost
between
1
and
x,
equal
cost
between
two
and
Z.
E
Right
so
we're
going
to
fail,
plr
one
to
H
and
we're
going
to
implement
fast
reroute.
If
we're
going
to
implement
fast
reroute,
we
have
to
repair
to
Z.
If
we
were
to
repair
to
X,
the
packet
would
come
back
to
plr
one
so
that
wouldn't
work.
If
we
were
repaired
to
Y
we
would
get
ecmp
so
that
doesn't
work
it
could
go
left
or
right
or
at
y,
so
we're
going
to
send
it
to
Z.
E
The
package
is
now
back
on
the
normal
path
and
according
to
the
the
hypothesis
that
was
discussed
at
the
earlier
meeting,
nfrr
is
cleared
and
in
this
particular
scenario
the
packet
will
successfully
proceed
to
H
via
plr2
we're
operating
as
a
normal
router
and
the
links
and
nodes
between
it.
Okay,
so
that's
easy
next
slide,
please
all
right.
So
this
is
the
exactly
the
same
thing,
but
the
other
way
around
right.
E
The
failure
was
between
plr2
and
H
and
the
packet
not
re-routed
to
X
and
proceeds
on
its
happy
path
back
via
plr
one
to
to
H,
and
that
is
all
fine
next
slide.
Please.
E
The
next
slide
is
obvious,
because
I'm
going
to
take
a
failure
in
plr
one
to
H
and
prr2
to
H
and
quote
the
English
children's
nursery
rhyme.
Here
we
go
around
the
mulberry
bush.
The
package
is
going
to
Loop
until
it
dies
of
old
age,
since
neither
plr
know
about
the
history
of
the
packet
before.
E
E
E
It
does
because
some
packet
is
going
to
enter
this
network
somewhere,
it's
going
to
try
and
get
to
wage
because
it
doesn't
know
H
is
unreachable
yet,
and
so
these
packets
are
going
to
go
bouncing
around
between
the
left
and
the
right
of
the
network
until
they
die,
and
that's
not
a
good
thing.
E
E
Then
well,
we
we
must
have
had
some
method
of
telling
everyone
in
the
node
in
in
the
network
that
that's
the
case
and
that's
known,
as
you
know,
essentially
abandon
all
hope.
Regular
reconvergence.
E
C
Stuart
I
think
what
you're
highlighting
is
the
NFR
nffr
flag
is
relevant
beyond
the
merging
Point
here
Z.
Absolutely
it
is
yes,
so
we'd
like
to
keep
it
sticky
all
the
way.
E
You
either
have
to
keep
it
sticky
or
you
have
to
abandon
all
hope
on
a
second
failure,
regardless
of
where
it
is.
You
see
if
it
kept
it
sticky.
What
would
have
happened
was
plr,
one
would
have
sent
its
packet
to
zed
from
Zed,
it
would
have
got
to
plr2
and
it
would
have
died
then,
and
meanwhile,
some
other
packet
could
have
easily
been
repaired
or
some
other
and
regular
productive
forwarding
could
have
continued
for
re
for
ordinary
packets.
E
Until
such
time
as
we
were
gonna,
we
could
do
a
controlled
reconvergence
of
the
network,
but
you
know,
unless
you
make
it
sticky,
you
have
to
go
to
your
emergency
plan
when
you
get
a
second,
a
second
failure
now
I
think
a
sticky
nfrr
actually
is
an
interesting
concept
within
the
sort
of
concept
of
doing
fast
reread,
and
we
would
have
liked
it
some
years
ago,
but
we
couldn't
see
how
to
do
it
with
the
data
plane
technology
that
people
were
prepared
to
deploy
that
and
it
has
all
kinds
of
useful
properties.
E
But
what
has
to
happen
is
it
has
to
be
sticky
or
you
will
get
this
sort
of
meltdown?
I'm,
showing
in
this
picture,
foreign.
E
B
G
So
we
know
what
is
required
to
do
an
nffr
that
is
sticky
and
craft
should
include
the
explanation
of
why
you
would
want
to
do
so,
and
then
we
can
make
decision
as
to
is
this
a
cost
for
willing
to
pay?
And
this
do
you
store
it?
You
raise
an
interesting
case
here
and
it's
not
your
fault.
It's
not
in
some
other
draft
already.
E
I
was
thinking
actually
Joe
that
this
was
this
actually
transcended
m
a
and
was
interesting
in
its
own
in
its
own
right,
because,
as
you
can
clearly
have
forgotten,
you
know
that
you
see
that
are
introducing
an
NFR
flag
in
some
way
in
some
packets,
which
we've
talked
about
in
other
cases,
doesn't
work
entirely
as
well
as
people
think
it
would
I.
G
I
think
it's
attractive,
so
I
think
as
a
practical
matter
Stuart.
If
we
put
it
in
this
draft
with
the
explanation,
people
can
still
point
to
it.
Just
write
the
explanation
so
that
it's
General
that
way
we
don't
have
to
get
into
trying
to
get
some
other
draft
through
some
non-existent
working
group.
Well,.
E
No,
the
the
working
group
is
rtgwg,
of
course,
that's
where
all
the
NFR
technology,
all
the
frr
technology
is,
is
hosted.
G
But
nobody
finds
things
from
there,
so
I.
What
I'm
saying
is
we
know
we
have
the
problem.
We
know
we
need
to
document
the
problem,
so
we
can
explain
what
we
need
going
and
writing
some
other
draft
in
some
other
working
group,
while
possibly
technically
arguably
correct,
doesn't
give
enough
Advantage.
Let's
just
write
one
here
that
proposes
given
this
problem.
G
F
E
So
so
all
right,
so
where
are
we
with
well
I?
Should
let
someone
else
go
first,
but
where
are
we
with
having
a
draft?
I
can
submit
some
text
to.
C
C
There
is
there
there:
okay,
there
was
one
draft
on
nffr,
but
it
expired
and
we,
the
original
I,
think
there
were
two
in
fact
one
from
as
a
primary
author,
but
that
also
expired
and
then
the
network
action
draft
for
nffr
is
also
expired.
So
we're
trying
to
reach
out
at
least
me
and
Laura,
trying
to
reach
out
to
the
co-authors
of
the
draft
and
to
see
what
the
plans
are
depending
on
the
answers.
C
We
might
need
a
new
draft
on
this,
so
this
is
what
the
information
I
have
and
thought
would
share
it
with
you.
C
C
We
talked
about
two
options:
one
is
adding
a
new
sub
stack
or
the
other
one
was
modifying
the
possibly
modifying
an
existing
sub
stack
that
has
a
hopper
hop,
scoped
action,
I'm,
not
sure
what
was
the
conclusion
which
approach
we
want
to
take
a
new
sub
stack
versus
modifying
the
existing
one,
and
maybe
that
the
draft
will
try
to
tackle.
C
Yeah
I
agree
with:
how
do
we
encode
it?
That's
yeah
we
need,
we
need
it
to
be
sticky,
I
totally
understand.
Just
how
do
we
create
an
m
a.
F
Okay,
so
I
think
Stuart
raised
a
valid
case
in
which
the
proof
that
the
no
for
the
FR
need
to
be
sticky
and
actually
I.
Think
in
there
in
this
case,
maybe
there's
a
can
be
a
third
very
pass,
which
is
a
usable
but
to
steal.
The
traffic
will
be
Loop
between
these
two,
this
nose,
because
that
pass
is
not
preferred.
Comparing
to
the
these
two
bars
right.
F
E
Yeah
I
just
thought
that
there
are
of
course
many
many
other
more
complex
scenarios
that
I
could
draw
with
a
triplet
in
here
and
it
going
round
and
round
the
the
circle
or
you
know,
a
a
quadrant
or
a
hexagon
or
whatever.
This
was
just
the
simplest
one
that
I
could
just
put
on
one
slide
and
everyone
could
get
their
head
around
it,
and
indeed
everyone
should
get
their
head
rounded.
As
soon
as
I
did
the
first
slide,
but
just
the
first
failure.
E
E
Well,
I
I
didn't
understand
that
that
was
a
bit
of
a
sweeping
statement.
I
think
you
need
a
bit
more
context.
Tony.
C
B
You
lower
Tony
I,
actually
have
a
mail
from
curietti
saying
that
he
is
not
interested
in
writing.
That
draft,
so
curietti
stepped
down
and
we
are
on
our
own.
A
I
I
appreciate
that,
but
credius
also
let
it
be
known
that
no
one
else
may
work
on
NFL
frr.
So
you
know.
E
E
Else
in
no
one
else
out
inside
Juniper
may
work
on
it
perhaps,
but
he
doesn't
have
an
embargo
on
the
entire
ietf
working
on
the
concept.
B
C
Okay,
all
right
I
think
yeah,
either
way,
I
think
we
need
the
draft
documenting
this
either
coming
from
kiriti
or
someone
else
and
I
think
it's
an
important
topic
to
cover
anything
else.
Do
it.
H
E
C
Yeah
so
I,
like
I,
mentioned
I,
tried
to
reach
out
not
having
gotten
back
any
feedback.
Personally
Loa
did
try
as
well.
He
has
some
feedback.
If
we
have
further
feedback,
I
mean
we'll
share
it.
Definitely,
let's
do
it,
but
and
maybe
by
next
week
in
the
chairs
meeting,
we
should
have
a
decision
on
either
a
new
draft
or
the
existing
draft
revived.
C
C
For
the
presentation,
thanks,
okay
and
I-
think
that
was
the
last
item.
We
had
I
have
a
couple
of
action
items
that
I
took
down
from
this
meeting
and
we
will
follow
up
on
the
meaning
list.
So
before
we
adjourn,
let
me
ask
if
any
any
other
chair
wants
to
add
in
any
closing
comments
or
had
anything
to
say.
C
No
okay,
I
think
I'm
gonna
give
you
back
the
remaining
time
from
today.
It
was
a
very
good
discussion.
I
hope
there
will
be
more
clarity
there
on
the
points
on
the
mailing
list,
so
keep
an
eye
on
the
mailing
list
then
see
if
we
can
get
clarity
there.
Thank
you.