►
From YouTube: IETF110-PIM-20210309-1600
Description
PIM meeting session at IETF110
2021/03/09 1600
https://datatracker.ietf.org/meeting/110/proceedings/
A
A
B
Yeah,
okay,
I
yeah,
I
guess
we
can
get
started
then
so
welcome
everyone
to
another
online
pin
meeting
this
time
in
czech
republic.
B
Ideally
we
should
have
been
there.
So,
let's
see,
I'm
gonna
navigate
the
slides
there.
Okay,
so
please
note
note:
well
it's
the
usual
not
well
also
before.
B
B
Yeah,
this
is
our
current
status.
We
have
a
couple
of
young
models
that
are
still
in
the
rfc
editors
queue.
They
have
been
there
quite
a
while
and
I'm
not
sure
how
long
how
much
longer
it
will
take.
B
A
In
both
of
those
in
both
of
those
drafts,
I
will
do
a
better
job
of
reviewing
them
before
we
send
them
to
alvaro,
because
in
both
cases
it
probably
should
have
been
not
sent
out.
So
that's
my
bad
so
I'll
make
sure
that
they're
thoroughly
vetted
before
we
send
them
to
you.
B
B
B
B
So
we've
been
a
little
slow
with
that
against
the
volunteers.
That
did
a
great
job,
getting
a
story
together
and
we
got
the
results
and
there's
this
draft
that
I
mentioned
before.
That
has
the
results.
So
please
have
a
look
at
that:
we're
going
to
start
the
actual
work
of
revising
these
rfcs.
B
So,
looking
for
volunteers
to
work
on
that,
I
asked
on
the
mailing
list
that
maybe
that's
a
handful
of
people
already
but
yeah.
If
you
are
interested,
please
respond
to
that
email
or
just
get
in
touch
I'll,
set
up
a
meeting
in
a
couple
of
weeks
where
the
volunteers
can
discuss
how
they
want
to
do
their
work.
A
Yeah,
just
as
you
look
at
that
agenda,
we
did
make
a
little
bit
of
adjustment
with.
Typically
we
do
working
group
drafts
first
and
then
individual
dress
after
they're
done.
We
did
make
some
adjustments
for
some
personal
reasons
to
have
some
individual
drafts
go
earlier.
So
just
just
note
that
it's
not
typical.
B
B
C
C
C
C
So
some
of
the
section
arrangement
got
modified
and
there
was
so
with
respect
to
solution.
Major
solution
has
not
changed.
It
remains,
as
is
the
way
it
was
before,
even
got
accepted
in
the
working
group
and
working
with
last
car,
and
there
were
more
detail
added
from
the
algorithm
side
itself
and
there
was
a
request
to
add
two
different
sections
or
another.
C
I
would
say
that
pointing
towards
two
one
of
the
draft
and
one
of
the
rfc
and
the
rfc
is
dr
load
balancing
rfc,
so
that
got
added
that
how
exactly
it
is
going
to
work
with
drlb
rfc.
And
if
there
were.
There
were
a
couple
of
places
where
content,
where
duplicate
they
have
been
removed,
and
we
added
some
more
description
to
make
sure
that
those
specifications
are
clear
enough
and
there
were
couple
of
editorial
changes
for
which
we
had
got
comment.
So
we
can
go
to
the
next
section.
C
So
election
algorithm
just
to
kind
of
recall
that
each
dr
among
the
dr
candidate,
they
will
so
basically
the
election
algorithm
goes
almost
similar
to
the
actual
team
rfc.
But
we
have
some
extra
hello
options
where
you
will,
any
router
will
basically
announce
that
they
do
support
this
specification
and
once
dr
has
been
elected,
the
dr
ip
address
will
also
be
centered
oops.
C
So
we
are
there.
Dr
address
will
also
be
sent
in
the
hello
options
so
that,
even
if
new
router
comes
up
with
higher
priority,
it
is
not
going
to
take
over.
So
it
gives
us
a
option
for
dr
to
be
a
sticky
and
ddr
is
going
to
be
elected
among
the
rest
of
the
candidate
other
than
the
dr,
which
is
we
can
consider
it
as
a
second
best,
dr
in
the
land,
and
that
is
not
sticky
and
dr
and
bdr.
C
Options
which
has
been
received
in
hello
is
stored
locally,
and
that
is
more
of
implementation.
To
make
sure
that
you
can
handle
the
case
when
some
new
router
comes
or
if
your
priority
changes
you're
not
going
to
you're
not
trying
to
take
over
as
idea
and
election
algorithm,
which
has
been
defined
in
team
rfc
0761
has
been
slightly
modified
to
adopt
these
some
of
the
new
steps.
C
And
so
before,
even
going
to
the
election,
there
is
a
modification
in
hello
exchange.
So
with
hello.
Now
we
are
going
to
send
a
dr
address
option
and
pdr
address
option,
and
initially
both
of
them
will
be
set
as
zero.
Sorry,
it
is
dr
address
option
and
both
of
them
will
be
set
as
a
zero
and
after
default
old
timer
expires.
Dr
and
vtr
will
be
elected,
and
one
more
thing
to
note
down
here
that
this
specification
will
work
only
if
all
the
routers
on
the
lan
they
do
support
this
particular
steps.
C
So
working
with
dr
lb,
so
rfc
8775,
which
became
standard
I
think
last
year,
so
with
dr
load
balancing
option
there
are
list
list
of
there
are
list
of
candidate
which
will
be
sent
in
the
hello
option.
So
with
this
specification,
if
those
lists
are
supporting
mdr
improvement,
route
or
mdr
improvement,
then
these
option
has
to
be
added
in
eight
seven,
seven,
five,
and
if
it
doesn't
support,
then
it
will.
C
C
C
C
Okay
yeah,
so
the
previous
draft,
which
we
spoke
about,
though
it
does
like
backup,
dr
and
it
talks
about
stickiness.
So
there
are
two
I
would
say
there
is
a
major
difference
between
both
of
these
draft.
So
this
draft
is
trying
to
simplify
if
we
really
need
an
extension
in
pin
hello
itself
to
elect
the
premiere.
So
we
can
go
to
the
next
slide.
C
So
this
draft
was
presented
the
few
idf
back
so
just
just
to
recall
that
by
default,
what
exactly
is
a
problem
statement?
So
if
you
see
here
very
simple,
topology
so
left
hand
side,
you
consider
that
left
hand
side
the
r8
and
r9.
Both
of
them
are
two
pin
router
on
the
lan
and
r8
had
dr
priority
as
91
and
r9
has
their
priority
as
a
90..
C
C
C
Now
this
step
there
are,
there
is
going
to
be
some
extra
time
taken,
because
the
total
time
will
be
first
thing.
R9
detects
the
failure
and
then
r9
starts
building
the
tree
and
starts
getting
the
traffic,
but
there
are
requirements.
There
are
lots
of
customers
where
multicast,
because
looking
at
the
way
network
is
growing
and
the
way
mindset
is
changing
with
respect
to
convergence,
so
requirement
is
to
achieve
a
faster
convergence
and
to
achieve
faster
convergence.
There
are.
C
C
Thanks
yeah,
so
so
in
this
case,
that
is
where
backup
dr
comes
into
the
picture,
and
the
overall
functionality
of
backup,
dr,
is
to
actually
kind
of
build
the
tree
parallel
to
your
actual
dr,
and
keep
all
the
states
with
respect
to
pin
protocol
ready
at
r9
and
as
soon
as
you
detect
the
failure
you
start
forwarding.
So
in
this
case
the
overall
convergence
hit.
C
C
They
don't
need
to
know
whether
there
is
a
backup
they
are
elected
or
my
company
are
not
elected,
so
that
is,
that
is
what
the
mechanism
of
this
rock
usage
and
that
there
is
no
need
to
have
extra
hello
options
among
the
routers.
So
we
can
go
to
the
next.
C
Slide
so
yes,
as
I
think
it
even
discussed
in
the
previous
draft
lots
of
vendors
and
lots
of
end
customers,
they
do
want
stickiness
in
the
mdr
functionality
and
reason
for
that.
If
there
is
any
new
router
coming
into
the
network
which
has
better
priority
it
will,
it
will
cause
a
churn
in
the
lan
site
and
the
reason
for
churn
is
since
dr
gets
changed
now.
C
New
dr
has
to
build
all
the
multicast
tree,
and
then
it
will
start
forwarding
traffic
to
the
axis,
and
these
chunks
may
not
be
really
needed
and
the
reason
I
can
think
of
couple
of
reasons.
It
could
be
just
maybe
configuration
that
someone
accidentally
configured
higher
their
priority.
It
was
not
the
intention,
but
even
these
kind
of
accidents
may
cause
a
lot
of
traffic
jam,
and
so
customers
are
vendors.
They
really
want
to
have
a
stickiness
feature:
stickiness
functionality,
yeah.
We
can
go
to
the
next.
C
So,
as
I
was
discussing
in
pim
working
group,
one
of
the
things
which
can
be
done
to
achieve
a
stickiness
in
the
pim
is
so
right
now,
if
we
think
the
dr
election
procedure
is
actually
between
two
things:
two
parameters-
one
is
your
dr
priority
and
then
second
is
pimp.
Neighbor
ip
address.
C
So
when
dr
election
happens,
router
4
will
get
elected
as
a
pmdr,
but,
as
I
said,
if
router
5
comes
with
priority
500
that
may
end
up
taking
dr
role
and
it
will.
It
has
to
go
through
all
the
tree
building
procedure
and
then
4
will
start
pruning
its
own
tree
and
five
will
take
over.
So
if
we
want
to
achieve
stickiness,
we
can
utilize
this
characteristic.
Where
dr
priority
is
the
one
who
is
actually
driving
the
whole
dr
election.
C
C
So
for
that,
the
mechanism
which
which
I
was
discussing
even
in
the
working
group
mailing
list
is,
let's
reserve
the
highest
dr
priority
highest
highest,
possibility
or
priority
on
the
land,
and
if
we
reserve
it
is
something
similar
to
you
can
say,
mutex
that
once
four
has
been
elected
as
a
dr.
So
the
original
dr
election
will
happen
depending
on
what
was
the
actual
configured
vr
priority.
C
Once
that
has
been
done,
router
4
will
get
our
router
4
will
get
the
max
dr
priority,
and
it
will
start
advertising
its
priority
as
a
max
value
so,
and
we
consider
the
reason
for
reserving.
That
number
is
to
make
sure
that
no
one
configures
that
manually,
otherwise
it
will
end
up
going
into
the
ip
address.
Selection
and
ip
address
cannot
be
controlled.
C
C
Now,
if
you
see
from
router
1,
2
and
3
point
of
view,
they
started
getting
router
4
dr
priority
as
a
max,
so
no
matter
what
they
are
never
going
to
take
over
as
a
dr.
So
now,
even
if
a
router
comes
with
priority
500
when
out
of
router
5
comes
into
the
network
and
it
starts
advertising
its
own
dr
priority
as
a
500,
since
there
is
a
router
4
who
is
already
advertising
max
value,
it
is
never
going
to
take.
So
we
will
maintain
the
stickiness
feature
now.
C
What
would
happen
if
this
router
goes
down?
Router
4
itself
goes
down
as
soon
as
router
4
goes
down.
We
are
back
to
exact
same
way
where
we
started
so
where
router,
1,
2
and
3
are
in
the
lan.
Now
dr
priority
is
100
200
and
300,
and
since
their
router,
their
priorities
are
already
configured.
There
will
be
dr
election
and
as
soon
as
dr
election
happens,
the
router
3
will
start
advertising
its
dr
priority
as
a
max
and
same
thing
continues.
C
So
if
router
4
doesn't
support
this
specification,
we
cannot
achieve
stickiness,
but
even
in
that
case
it
is
not
going
to
break
any
functionality
in
router,
1,
2
and
3,
because
the
router
four
will
get
connected
as
dr
dr
on
the
land.
So
even
since
it
doesn't
support
this
new
function,
new
specification,
it
will
keep
announcing
itself
as
a
router
400.
Oh
sorry,
dr
priority
400,
so
it
will
be
acting
as
a
dr
till
someone
else
takes
over.
C
C
So
the
reason
why
I
was
in
favor
of
reserving
max
dr
priority,
it
is
it
is
for
the
simple
fact
that
we
don't
want
accidentally
these
numbers
to
be
open
to
be
configured,
because
if
I
am
using,
let's
say
that
max
dr
possible
priority
is
100
and
I
am
using
system
to
assign
a
priority
100
to
whoever
is
the
dr
at
that
point
of
time.
If
user
also
assigns
a
priority
as
100
on
the
land,
what
it
is
going
to
happen
that
it
says
router
who.
C
So
adjusting
asset
matrix.
So
if
you
see
here,
even
though
dr
does
play
a
role
for
sending
traffic
on
the
land,
but
if
assert
comes
into
the
picture,
it
will
be
assert
winner
who
is
going
to
who
is
going
to
start
forwarding
traffic
on
the
land.
So
one
of
the
idea
here
was
to
okay.
C
So
I
think
next
slide
speaks
about
implementation
of
stickiness
behavior
yeah.
So
we
do
have
implementation
for
this
behavior.
What
I
have
described
in
last
couple
of
slides
about
stickiness,
and
if,
when
I
did
google,
maybe
someone
can
confirm,
but
I
think
there
are
other
vendors
who
also
do
have
implementation
almost
in
same
lines,
though
numbers
have
been
not
reserved
yet,
and
it
is
just
that
the
same
same
mechanism.
Implementation
does
exist
and
one
more
thing
to
discuss
here
so
initially,
I
think
I
presented.
B
B
C
So
I
did
yesterday
since
I
get
email,
I
think,
from
juniper
attaching
ipr
for
this
draft.
So
when
I
read
about
that
ipr,
it
talks
about.
Basically
the
way
stickiness
is
achieved
is,
I
think,
just
not
doing
vr
election
anymore
or
some
some
kind
of
timer
related,
but
I
did
when
I
did.
Google,
maybe
human
can
confirm.
I
think-
and
I
I
have
discussed
this
with
woman
and
jeffrey
both
and
I
think
juniper
and
nokia
both
have
almost
similar
implementation
with
respect
to
stickiness.
C
D
D
Can
we
leverage
some
of
I
mean
what
has
been
done?
I
guess
one
thing
I
think
to
be
worth
looking
at.
Is
you
know
in
the
case
of
erp
and
say
rsvp
was
it
you
know
a
protocol
level
stuff
or
were
these
just
vendor
implementations
that
made
that,
and
I
think
those
could
be
good
precedence,
good
good
examples
to
look
at.
D
You
know
how
to
solve
this
problem,
whether
it's
worth
doing
it
in
the
protocol
or
it's
worth
you
know
just
making
it
informational
and
you
know
leaving
it
up
to
vendors,
leaving
up
the
implementations.
But
you
know
this.
This
doesn't
seem
unique
at
all
to
pim.
It's
a
pretty
common
thing
that
happens
in
lots
of
protocols.
E
Hey
I'll
go
to
the
thunderbolt
80.,
so
what
has
me
very
confused
is
the
fact
that
we're
talking
about
two
solutions
that
basically
do
the
same
thing.
E
Mankind
just
made
a
really
good
argument,
in
my
opinion,
as
to
why
the
other
solution
is
not
needed,
because
we
can
do
the
same
thing
without
signaling.
It
looks
like,
but
of
course
this
draft
hasn't
been
approved,
hasn't
been
adopted
and
in
general
you
know
whether
it's
informational
standard
doesn't
matter.
If
the
working
group
is
going
to
work
on
several
solutions
or
several
related
solutions,
even,
for
example,
the
the
load
balancing
draft
for
the
dr's,
it
would
be
really
nice
if
they
were
all
considered.
You
know
how
do
they
interact?
E
What
happens
if
one
is
working
on
the
other
one?
I
said
what
happens
if
one
guy
thinks
it's
doing
this
and
the
other
guy
is
doing
something
else.
You
know
thinks
along
those
lines,
regardless
again
of
the
status.
So
what
confuses
me
is
that
again
we
we
seem
to
be
circling
around.
There
seems
to
be
several
implementations
of
this
or
something
very
similar
to
this
draft.
E
If
I
remember
correctly,
there's
at
least
one
implementation
of
the
dr
improvement
draft
as
well,
so
I
think
we
sort
of
need
to
resolve
that
right.
Do
we
want
to
do
one
solution,
two
solutions,
you
know
etc,
as
long
as
as
we
have
consensus
on
that,
as
long
as
we
understand
how
they
can
either
interact
together
or
or
not
right,
and
that
is
clearly
defined
in
the
specifications
you
know
it
would
make
it
a
lot
clearer.
B
B
But
now
we
have
basically
two
proposals
for
how
to
do
this,
so
we
need
to
see
what
are
their
pros
and
cons
right
and
do
we
need
do
we
actually
need
two
solutions,
or
should
we
pick
the
one
solution
that
we
think
is
is
best
or
are
there
different
use
cases
so
that
you
know
one
one
solution
is
best
in
one
scenario,
while
in
other
scenarios,
maybe
the
other
one.
So
we
need
to
look
carefully.
E
Alvaro
just
to
be
clear,
I
I'm
not
either
advocating
for
one
or
two
right.
I
I
want
the
working
group
to
decide
that
and
if
we're
going
to
go
with
more
than
one,
we
just
need
to
make
sure
that
we
consider
how
they
interact
or
not,
and
that
if
there
are
multiple
use
cases,
maybe
we
define
that
in
drafts.
You
know
for
this
use
case,
it's
better
to
use
solution
one,
and
for
that
other
use
case,
maybe
solution.
E
E
If
the
other
solution
is
not
it's
not
supported,
but
of
course,
there's
a
way
to
know.
If
I
support
this
draft
because
there's
no
signaling,
unless
you
know,
there's
configuration
assumed-
and
you
have
a
bunch
of
other
stuff,
so
there
needs
to
be.
You
know
more
coordination
now
I
said
you
know.
My
personal
opinion
is
that
my
camaraderie
just
made
a
really
good
argument
for
why
we
only
need
this
one,
but
really.
B
So
yeah,
so
if
the
working
group
decides,
you
know
that
we
that
we
only
need
one
solution
that
covers
all
the
use
cases
then
yeah.
We
probably
want
to
publish
only
one
of
the
documents,
at
least
that's
my
feeling,
but
we
need
to
have
that
discussion
and
I
wouldn't
rule
out
at
this
point
that
we
possibly
could
have
two
documents.
It
depends
what
we
decide.
A
Yeah,
because
some
people
may
want
to
have
a
solution
that
does
have
a
new
hello
option,
and
maybe
some
don't
want
to
do
that.
It
seems
to
me
that
having
two
solutions
is
okay.
I
mean
it's
something
that
we
may
want
to
do,
but
we
right
now
only
have
one
working
group
document,
so
we
have
to
make
that
decision
first,
whether
we
want
to
adopt
this
one
or
not
but
albro.
A
It
sounds
like
what
you're
saying
and
what
you
said
on
the
list
is
that
let's
say
that
we
do
adopt
this.
This
draft
that
we're
talking
about
right
now.
A
You
would
prefer
that
both
this
and
the
dr
improvement
progress
together,
like
we
should
hold
off
on
progressing
vr
improvement
until
this
one
is
also
to
a
state
where
it
should
progress.
Is
that
correct?
E
Very
nice
they're
not
dependent
on
each
other
right,
so
I
don't
need
one
for
the
other
one
to
work
right,
so
they
don't
have
to
progress
together.
It
would
be
very
nice
so
that
when
you
tell
me,
for
example,
if
I
don't
support
your
improvement,
then
do
this,
then
you
know
I
can
I
can
look
how
this
works.
E
So
it'd
be
really
nice.
If
they
were
close,
they
don't
have
to
be
together.
E
Okay,
I
mean
right
now
it's
it's
a
really
weird
situation,
because
we're
in
the
dr
improvement
draft,
we
are
normatively
recommending.
The
use
of
a
non-adopted
document,
which
you
know
in
the
grand
scheme
of
things,
is
not
a
bad
thing.
It's
just
that
it
would
be
just
nicer
if
things
have
progressed
a
lot
more.
B
B
B
B
A
B
A
A
F
F
A
So
the
poll
currently
is
six
in
favor
and
two
against
so
and
now
seven
in
favor,
so
we'll
let
this
run
for
a
little
bit
longer.
But
we
do
need
to
take
it
to
the
list
and
we'll
need
to
make
it
as
simple
as
we
can.
When
we
make
the
requests
in
the
list
and
just
focus
specifically
on
this
draft
and
then
you're
right
stink.
We
can
them
both
and
if
we
decide
to
discontinue
on
we'll,
do
it.
B
So
it's
look
good
here,
but
yeah.
Of
course
we
have
to
take
it
to
the
list
and
also
want
to
hear
what
concerns
people
have
why
they
are
wanting
not
to
adopt
and
also
what
makes
people
like
this
and
want
to
adopt
it.
A
A
A
F
Yes,
stick.
Can
you.
F
Yeah
yeah
so
yeah
thanks
to
mike
and
stick
for
taking
this
a
little
bit
early
in
the
agenda,
I
have
some
chronic
back
pain,
so
I
couldn't
wait
a
lot
longer.
F
So
the
proposal
is
to
kind
of
build
on
the
8059
rfc,
to
request
new
joint
prone
attributes
for
a
lisp
multi-site
scenario.
So
I'll
just
briefly,
go
over
the
problem
statement
and
then
kind
of
explain
the
motivation
for
requesting
the
new
tlv
and
then
we
can
of
course
take
questions.
F
So
the
multi-site
scenario
for
lisp
multicast
has
been
covered
in
6831,
where
multicast,
asm,
ssm
and
binder
modes
are
supported
in
the
overlay
with
an
ip
multicast
based
underlay.
So
the
key
point
here
is
that
we're
using
ip
multicast,
both
in
the
overlay
and
in
the
underlay
and
just
for
simplicity
sake.
We
will
just
take
ssm
in
the
overlay
and
ssm
in
the
underlay,
but
without
loss
of
generality.
F
F
M
overlay
might
be
multicast
groups
spread
across
multiple
vrfs
mapped
to
young
underlay
transport
multicast
groups,
where
m
is
much
greater
than
n,
so
the
problem
gets
compounded
for
multi-site
scenarios.
We
will
discuss
that
particular
scenario
using
the
next
slide,
but
this
is
already
being
covered
in
section
eight
one,
two
of
sixty
eight
thirty
one
section,
eight
one,
two
of
sixty
eight
thirty
one
already
notes
that
when
you
have
such
a
scenario
where
you
have
a
m2n
mapping
very
m
much
greater
than
n,
you
could
have
traffic
going
to
undesired
locations.
Now.
F
The
goal
of
our
proposal
is
not
to
you,
know,
optimize
or
rather
reduce
the
traffic
going
to
undesired
locations,
but
also
fix
scenarios
that
were
related
to
traffic
happening.
So
the
proposal
we
have
given
may
not
completely
take
away
the
traffic
being
you
know,
sent
to
under
unrequited
locations
and
then
getting
dropped,
but
definitely
it
should
avoid
traffic
looping
scenarios
that
we
didn't
observe
in
a
particular
implementation
with
such
characteristics.
F
So
the
protocol
exchanges
that
we
suggest
are
predominantly
between
the
border
nodes,
but
then
they
can
be
between
you
know
xtr's
inside
a
lisp
site
also,
but
for
the
purpose
of
this
presentation,
I
will
just
limit
my
explanation
to
the
border
nodes
and
you
know
how
the
multicast
tree
gets
formed
at
the
border
nodes
and
why
we
require
this
new
tlv
next
slide.
Please.
F
F
That,
in
order
to
reach
the
source
in
site,
one
the
blue
site,
I
have
to
get
to
border
the
site
border
because
it's
a
slight
external
prefix.
Therefore,
it
forwards
the
pim
join
in
the
overlay
to
the
border
b3
for
the
you
know,
source
the
multicast
source,
that
is,
the
camera
in
site.
One
also
maps
that
traffic
to
a
underlay
tree
rooted
at
border
three,
because
for
the
xtr
three
one
it
it
appears,
the
traffic
originates
from
v3.
F
The
b3
is
the
ingress
itr
right,
the
b3
gets
both
the
overlay
join
and
the
underly
join
the
underlay
tree
rooted
at
b3,
and
then
the
overlay
tree
that
is
rooted
for
the
cameras,
eid,
prefix
and
the
camera
group,
and
then
figures
out
that
the
camera
eid
prefix
is
actually
reachable
via
b1
and
therefore
forwards.
A
join
in
the
overlay
to
the
b1
encapsulated
using
the
lisp.
This
is
again
specified
in
6831,
nothing
new
and
then
forwards
an
underlay
join
by
mapping
the
overlay
group
to
an
underlay
group
to
the
tree
rooted
at
b1.
F
Now
this
is
fine
for
the
unidirectional
traffic.
Now
I
have
not
shown
here.
You
know
bi-directional
traffic,
but
one
could
easily
imagine
that
if
there
is
a
source
connected
to
str31
and
receiver
connected
to
xtr
one
one,
then
the
same
process.
What
I
just
described
repeats
in
the
opposite
direction.
F
But
what
could
happen
in
this
process
is
that
the
same
tree
that
is
rooted
at
b1
for
the
underlay
for
the
traffic
coming
from
you
know,
xtr
one
one
could
also
be
used
inside
the
lisp
site
blue
site
for
the
traffic
that
xtr11
pulls
from.
You
know
xtr
31
by
b3
and
b1.
So
I
will
just
repeat
my
last
point:
the
central
tree
that
is
rooted
at
b1,
which
b3
is
part
of
for
the
flow
that
is
coming
from
xtr
one
one
to
three.
F
One
could
also
be
used
for
the
traffic
that
is
flowing
from
xtr
31
to
say
the
receiver
in
xtr
one
two.
So
therefore,
the
traffic
happening,
basically,
whatever
traffic
that
was
sent
from
xtr11
to
b1,
to
go
to
b3
a
copy
of
that
packet
goes
to
xjr12
and
therefore
duplicate
packets
get
received.
Or
you
know,
even
traffic
looping
scenarios
happen
in
the
case
of
bi-directional
traffic
between
two
different.
You
know
lisp
sites
exchanging
bi-directional
multicast
traffic.
F
You
know
the
complexity
arrives
is
because
the
border
nodes
perform
a
special
role
in
participating
in
three
pim
domains,
two
in
the
underlay
and
one
in
the
overlay.
Now
the
reason
why
I
say
two
pim
domains
in
the
underlay
is
that
sorry
stick.
You
may
have
to
come
back
to
the
diagram.
The
two
in
the
underlay
essentially
is
one
is
the
side
facing
under
liping
domain
and
then
one
is
the
core
facing
under
lipid
domain,
and
then
you
have
the
over
lipid
domain.
F
So
in
order
to
kind
of
you
know,
break
this
looping
or
you
know
a
duplicate
traffic
being
received.
The
obvious
solution
is
to
use
a
split
horizon
and
that's
what
the
tlv
proposal
is,
but
I
will
pass
at
this
point
of
time
and
take
any
questions
and
then
try
to
clarify,
because
I
think
clarifying
the
problem
statement
here
probably
definitely
requires
additional.
F
Okay,
okay,
okay,
so
so
these,
when
we
thought
about
the
solution,
I
think
one
of
the
key
tenets
that
we
thought
was,
or
rather
one
of
the
key
proposals
that
we
thought
was:
let's
try
to
use
a
split
horizon
approach
where,
instead
of
using
the
same
tree
for
the
you
know
intra
site
traffic
and
the
intersect
traffic.
Let's
try
to
you
know:
partition
the
address
space
and
use
different
ranges,
one
for
the
you
know,
site
local
traffic
and
one
for
the.
You
know
intersect
traffic,
and
that
way
we
could
achieve.
F
You
know
the
split
horizon,
so
the
one
of
the
ways
we
could
achieve
the
split
horizon
is
by
having
the
downstream
border.
In
this
case,
you
know
for
the
traffic
direction
b1
to
b3,
let
b3
request
to
b1.
When
the
overlay
joint
happens.
You
know
let
b3
convey
the
or
signal
the
overlay
to
underlay
mapping
explicitly
and
thereby
you
know
you
can.
F
F
F
Okay,
okay,
so
so
I
was
just
trying
to
explain
that
you
know
the
the
on
the
downstream
router
can
use
a
signaling
mechanism
to
map
the
to
conveys.
You
know
interest
by
conveying
the
mapping
that
it
wants
to
do
use
for
the
overlay
to
underlay
using
a
new
tlv
and
that's
the
new
proposal
that
we
are
making,
where
you
know,
b3
essentially
signals
to
b1
for
the
overlay
group.
You
know
for
the
overlay
group
camera
group
in
this
case
for
the
camera
source.
Please
use
a
given
underlay
group
that
you
know.
B
F
Right
all
right,
so
the
the
last
slide
stick
basically
or
the
next
slide,
not
the
last
one,
the
fourth
one.
F
So
basically,
the
proposal
is
to
have
a
tlv
that
signals
the
overlay
to
underlay
mapping
where
the
join
the
pim
joint
prune
attribute
will
be
enhanced
to
include
a
new
underlay
multicast
group,
very
similar
to
what
has
been
proposed
in
1859
for
the
ingress
replication
case,
where
the
same
tlv
format
is
used.
Instead
of
the
multicast
group.
It
was
a
unicast
group.
F
F
B
G
H
I
I
I
have
to
admit:
I'm
sort
of
took
a
break
from
him
for
a
number
of
years
did
did
what's
the
relation
with
the
lisp
solution
and
the
list
book.
H
H
F
Good
question
is
a
two
two
parts
to
answer
to
your
question
right:
should
this
be
presented
at
list?
Absolutely?
Yes,
probably
at
the
next
ietf.
I
will
present
this
to
lisp
working
group.
Yes,
but
should
it
be
progressed
in
list
per
time?
F
Correct
me
if
I'm
wrong
sticker
mic,
the
8059rfc
where
the
previous
types
have
been
defined
have
been
progressed
in
pim
and
therefore
I
submitted
it
to
pim,
because
the
type
that
I
am
proposing
is
very
similar
to
the
type
that
has
already
been
requested
for
the
unicast
address,
and
that
was
done
in
pim.
A
Yeah
that
makes
sense
to
me.
However,
I'm
looking
at
the
lisp
charter
right
now,
they
do
have
a
section
on
multicast
that
does
say
that
they
do
support
overlay
multicast
by
means
of
replication,
blah
blah
blah,
and
it
may
need
this.
It
may
need
discussion
with
other
working
groups
related
to
multicast,
including
pin
they
call
out
pins.
So
we
definitely
would
need
to
coordinate
with
them
because
it
sounds
like
they
would
almost
want
to
work
on
it
themselves,
but
I'm
not
sure
go
ahead.
Albro.
E
Hey
anything,
yes,
so
I
think
the
difference
between
this
and
say
mvpn,
for
example,
is
at
least
the
details
in
the
draft
about
what
to
do
with
everything
right.
A
vpn
is,
you
know,
a
countless
number
of
pages.
E
So
you
said
mike
what
needs
to
happen
right,
which
is
you're
coordinated
with
lisp
make
sure
that
list
wants
this,
and
if
you
know,
we
need
to
add
a
lot
more
details
according
to
what
ac
said,
which
makes
sense,
then
you
know
we
need
to
just
coordinate
with
list
chairs
on.
E
B
That's
exactly
what
happened
last
time.
The
main
work
was
not
in
pim,
but
it
was
presented
and
discussed
in
the
list
working
group
as
well
to
make
sure
that
they
actually
thought
it
was
a
good.
A
Idea
sandy
has
a
question
of
prasad
about.
Is
this
the
extension
that
you
just
presented
for
the
star
g
or
sg,
or
for
both
of
them.
F
Yeah?
Yes,
thanks
for
bringing
it
up
mike.
F
Is
for
both
sandy
when
the
strategy
so
the
tlv
proposal
that
can
be
added
stick?
Can
you
go
to
slide
number
four?
Please.
F
F
A
Okay,
that
made
sense
to
her,
so
any
other.
A
So
precise,
do
you
want
us
to
reach
out
to
joel
and
the
other
list
chairs,
or
do
you
want
to
do
it?
What
do
you
prefer.
F
A
E
Just
a
quick
note
list
didn't
meet
this
week,
but
they're
going
to
plan
an
interim
soon
after
the
atf.
So
since
you
haven't
presented
this
there,
it
would
be
good
to
present
to
there
right
before
deciding
what
to
do
with
the
draft.
F
Okay,
okay
alvaro:
I
think
it
was
alvaro
yes
alvaro
I'll,
try
to
see
if
we
can
get
it
presented
at
the
interim
thanks
yeah.
Thank
you.
Thank
you
mike
and
stick.
F
G
All
right
perfect,
I
got
so
many
microphones
in
front
of
me.
I
don't
know
which
one
is
which
anymore
I
just
turn
them
all
out,
and
one
of
them
just
picks
me
up
okay.
So
this
is
the
update
for
point
to
multipoint
policy
to
give
you
guys
a
little
bit
of
overview
where
we
are
with
some
of
the
drafts
out
there.
Obviously,
the
replication
segment
was
adopted
by
a
spring
the
point
to
multiply
policy,
obviously
by
pim.
Thank
you.
G
The
mvpn
evpn
extensions
by
bess
was
adopted.
We
are
working
very
hard
on
the
pce
draft
and
trying
to
make
it
adopted
in
the
pce
working
group.
There
is
a
little
bit
of
discussions
back
and
forth
on
how
these
objects
should
be
presented
and
downloaded
from
the
pce
to
the
pcc.
G
G
Okay
sure
thank
you
so
so
one
last
question
that
is
still
remaining:
I'm
not
sure
what
was
the
outcome
of
it
was
the
yang.
I
don't
know
it's
it's
sitting
in
a
spring,
I
I
don't
know
whether
we
wanted
to
bring
it
into
the
pimp
or
not.
I
don't
know.
A
That's
what
I
was
gonna,
that's
what
I
was
gonna
come
up
comment
on
yeah
great,
so
stig
may
remember
this
as
well.
You
may
too,
but
so
last
summer.
I
think
it
was.
We
did
discuss
this
with
the
spring
chairs
and
they
said
that
they
wanted
to
keep
that
in
spring.
Unless
you
broke
this
up
into
two
yang
documents,
one
for
the
ptmp.
I
A
And
one
for
replication
segment,
one
would
be
here
and
one
would
be
there.
So
that
would
be
your
choice.
It
would
be
a
lot
a
lot
of
work,
but
we're
certainly
open
to
consider
adoption
in
this
working
group.
If
it's
just
focused
on
the
policy
part.
G
Okay,
understood
yeah,
so
let
me
have
a
conversation
with
the
with
the
co-authors
and
we'll
take
it
from
there.
Thank
you
next
slide,
please.
G
G
G
G
All
we
did
is
we
introduced
a
brand
new
function,
which
is
the
replication
function,
think
of
it
as
the
mpls
replication
seat,
which
we
are
just
putting
it
in
the
srv6
function,
and
it's
called
the
replication
function
within
the
srv6
again,
nothing
new.
All
the
goodies
that
were
there
previously
are
going
to
be
carried
forward
with
the
srv6.
G
G
So
I
kind
of
touched
base
on
this
slide
too.
I
I
tried
to
simplify
it
as
much
as
I
as
I
could
again.
The
replication
function
that
we
introduced
on
the
replication
nodes.
It
has
the
forwarding
information,
so
we
can
figure
out
the
outgoing
interfaces
and
you
know
pushing
the
new
replication
function
for
downstream
nodes
that
they're
going
to
do
the
same
replication
over
and
over
again.
G
Until
we
get
to
the
leaf
node
at
the
leaf
node
based
on
the
replication
function,
we
can
remove
the
encapsulation
and
actually
look
at
the
payload
and
forward
it
to
the
hosts
that
are
connected
to
that
leaf
node
on
the
bud
node.
Obviously
it
does
both
functions
again.
When
the
replication
segment
is
examined
on
the
bot
node,
there
is
going
to
be
a
local
packet
that
is
going
to
be
extracted
for
the
bud
node,
and
there
could
be
many
other
outgoing
interfaces
based
on
that
replication
function,
that
the
packet
will
be
replicated
and
forwarded
out.
G
So
just
a
quick
example:
here
again
the
node
one
here
is
the
root
note
root.
Node
number
two
is
a
replication
point
and
your
leaf
nodes
are
number
five
six
and
seven.
So
you
know
I
I
made
a
connection
between
node,
five
and
seven,
but
that
connection
could
not
be
there
or
it
could
be
there.
It
doesn't
matter,
but
those
are
the
leaf
nodes.
G
So
number
node
number
two
really
is
working
as
a
replication
point.
As
you
can
see
the
examples
at
note
number
six,
there
is
going
to
be
a
replication
function,
f6
which
will
encapsul
decapsulate
the
srv6
and
grab
the
payload
and
forward
it
to
the
host
same
as
story
with
node
number.
Five.
G
There
is
going
to
be
a
replication
function
or
a
replication
set
of
f5,
which
will
decapsulate
the
srv6
and
forward
the
payload
to
the
to
the
host
that
is
connected
to
the
to
node
number
five
and
going
to
number
seven.
We
can
really
do
a
traffic
engineering
and
you
know,
force
the
packet
through
note,
4
and
then
eventually
note
4
vr
function
will
forward
that
packet
to
note
7,
which
has
a
replication
seat
of
f7,
and
it
will
pop
the
srv6
and
forward
the
packet
to
the
host
so
again,
nothing
new.
G
We
are
just
using
the
existing
srv6
functionality
out
there
for
traffic
engineering,
etc,
etc.
We
are
introducing
a
very
powerful
functionality
here,
which
is
a
replication
function,
and
then
you
can
connect
to
replication
function
via
unicast
domain
or
you
can
chain
them
together
to
create
a
tree.
It
is
very
flexible,
it
can
do
any
type
of
forwarding,
unicast
or
multicast
anywhere
within
the
domain
of
srv6.
A
G
In
in
yeah,
I
I
believe
so
we
need
to
discuss
that
a
little
bit
further,
but
yeah
that
that's
where
it
is
right.
Now,
yes-
and
there
are
some
updates,
I
think,
within
the
body
of
the
draft-
I
can't
remember
exactly
but
the
yeah-
all
the
updates
are
already
within
there.
A
J
J
Next
slightly
please:
firstly,
I
will
give
a
very
quick
review
of
the
problem
and
the
solution
overview
of
this
draft
and
both
in
the
network
side
and
the
hostess
side
in
the
shared
network.
P
merced
may
maybe
happen.
J
Because
the
multicast
server
service
becomes
wide
widely
deployed
and
the
a
large
number
of
multicast
entries
increase
and
and
maybe
a
a
large
number
of
a
certain
message-
may
be
sent
in
a
very
short
period
and
that
made
trig
many
p
mercedes
in
in
the
shared
networks.
So
it
may
maybe
in
make
the
asset
a
certain
packet
not
be
processed
in
time
or
even
is
discussed,
and
it
will
make
the
delay
of
the
traffic
duplication
in
the
network
next
slide.
Please.
J
And
in
this
chapter
we
have
promoted
a
two
solution
at
the
division,
defined
that
the
two
solution,
and-
and
we
use
the
pim
hello
option-
to
distinguish
these
to
both
the
solution.
One
is
the
simple
packing
solution
and
the
other
is
a
aggregating
packing
solution
that
is,
make
the
same
source
or
the
same
rp
address,
and
it
saves
the
package
space
and
there
is
no
change
to
the
pmr
set
state
machine
for
this
solution.
For
this,
both
these
solution
solutions
next
slide.
Please.
J
The
update
of
this
draft
there
are
two
steps
aspects,
one
is
that
the
we
update,
the
p
merced
pack
packing
format
and
the
format
is
updated
to
align
with
the
rfc
8736
and
the
pim9
register
packing
draft
and
the
and
the
the
pin
pin
type
field
update
is
no
factor
with
the
with
this
draft
solution,
because
we
remain
to
use
the
p
merced
type
for
for
the
packing
or
certain
and
the
count
field.
J
We
update
to
align
the
pim
nung
register
packing
solution,
because
they're
not
necessary
to
define
another
format.
J
And
the
second
point
we
add
some
brief
analysis
for
the
p
merced
tamar
and.
J
Sorry,
the
previous
and
the
there
is
no
effect
on
the
existed
as
a
timer
mechanism
for
both
the
star
g
and
the
sg
so
because
the
a
sub
winner
sends
a
third
message
due
to
the
local
period
of
time,
expiration,
depending
on
the
implementation
of
the
time
accuracy
of
maybe
in
the
same
second
or
in
the
same
millisecond,
etc,
that
the
pim
strategy
or
sg
will
expire,
which
are
expelled
at
the
same
time,
will
be
sent
by
the
packing
message
instead
of
the
individual
pen
message.
J
So
there
is
no
other
change
in
this
process.
B
Yeah,
can
I
comment
on
that,
so
I
think
this
this
looks
great
to
me.
The
only
thing
I
would
point
out
is:
if
you
have
a
third
timers
that
expire
at
almost
the
same
time
right,
then
you
could
grip
multiple
together.
The
key
thing
is
that
you
don't
send
a
cert
too
late,
but
it's
okay.
If
you
send
a
search,
maybe
a
few
milliseconds
or
a
second
or
something
earlier
right.
B
So
maybe
it
could
be
a
good
test
guidance
on
yeah
along
those
lines
once
you
let's
say,
if
you
have
many
asserts
going
off
like
this
yeah
right
now
and
some
are
about
to
expire
in
one
second,
then
you
could
send
all
of
them
now
and
after
that
they
would
all
be
in
sync,
so
you
could
keep
sending
all
of
them
at
the
same
time
after.
K
J
J
Stick
and
the
next
step
for
this
draft-
and
I
will
add
some
some
operations
of
asset
packing
for
how
to
perform
this
asset.
Packing.
A
J
Okay,
I
I
I,
I
don't
think
it's
it's
ready
for
last
call
now.
B
Okay,
okay,
yeah
yeah,
at
least
I
would
say
I
I
read
through
it
again
and
I
think
it's
in
good
shape,
but
yeah
I'll
provide
a
few
comments
myself
and
hope.
Other
people
can
read
it
and
comment
as.
B
K
Okay,
can
everybody
hear
me
okay,.
C
K
All
right
so
yeah
we
had
the
sixth
draft
for
pim
null
register
backing
and
we've
uploaded
the
seventh
one
stick.
You
can
go
to
the
second
slide,
so
there
were
a
bunch
of
reviews
and
thank
you,
everybody
for
reviewing
the
draft.
K
We've
fixed
all
the
editorial
comments,
but
there
seemed
to
be
some
discussions
around
how
the
downgrade
scenario
would
work
and
if
the
capability
check
is
enough
for
the
packing
or
null
register
packing
to
work
so
I'll
be
just
discussing
the
capability
check
once
and
I
hope
that
clears
up
any
confusions.
K
Let's
go
to
the
third
slide
stick,
so
this
would
be
the
pim
register.
Stop
it
that's
sent
from
the
rp
to
the
dr
and
it
would
set
the
pivot
if
it's
capable
of
handling
pimp,
packed
null
registers.
K
So
at
the
dr,
the
dr
will
send
an
unpacked
null
register
to
the
rp
after
the
rst
expires
and
the
rp
can
send
back
the
or
the
register
stop
with
this
capability
bit
set
or
unset,
and
at
the
dr,
when
we
receive
the
register
stop,
we
can
just
check
if
it's
capable
of
handling
the
null
packed
null
registers
or
not.
K
K
Okay,
there
were
some
additional
questions
too,
which
is
which
are
not
covered
in
the
slides
because
I
sent
them
before
they
came
back,
but
they
were
to
address
lenny's
comments.
K
So
there
was
a
question
about
whether
pim
null
register
packing
will
treat
any
cast
rp
with
mst
any
different,
and
the
response
is
that
it
will
not
for
both
mechanisms.
Pim
null
register
packing
will
work
only
if
any
cass
rp's
in
the
entire
rp
set
supported.
So
that's
a
comment
that
it's
that
would
be
clear
in
the
in
the
latest
draft
and
also
I
I
accept
the
comments
about
the
usage
of
pim
registers
and
null
registers
being
interchangeably
used
in
the
draft.
K
So
I
fixed
that
as
well
in
the
latest,
one
that
hasn't
been
uploaded
here.
That
would
be
the
eighth
draft,
but
we
will
clear
any
ambiguity
between
the
usage
of
a
null
register
or
the
usage
of
a
data
register,
so
the
packing
is
only
for
pim
null
registers
or
pim
register
stop
messages.
So
we
will
make
that
very
clear
in
the
eighth
draft.
K
So
the
last
slide
is
just
to
know
about
the
next
steps
and
if
we
can
make
a
call
on
this
because
because
that's
all
we've
addressed
all
the
other
comments
based
on
this.
B
Yes,
so
there
were
some.
There
were
some
comments,
especially
about
the
downgrade
scenario
that
people
had.
So
I
don't
know
whether
we
should
try
to
see
if
they
they
are
okay
or
if
they
still
think
they're,
they
have
any
concerns,
or
we
could
wait
for
yeah.
Do
that
during
working
group.
Last
call,
I
don't
know
if
you
have
any
thoughts
on
that
mike.
A
B
Do
another
last
call,
but
at
least
we
had
some
review
already
so
yeah.
A
B
B
K
A
Yes,
okay,
thank
you!
So
when
that's
done,
then
stig
we
should
issue
a
working
group
last
call.
Well
maybe
we
should
just
ping.
Everybody
who's
commented
to
make
sure
that
everybody's
cool
with
what's
happened.
To
that
point,
do
a
working
blast
call
and
then
you
and
I
thoroughly
review
it
again,
one
more
time
before
we
send
it
back
to
avro.
B
I
Page
so,
firstly,
I
would
like
to
thank
you
very
much
for
ac
and
jeffrey
for
their
relevant
comments
during
the
last
adoption
call.
So
in
this
updated
version,
we
address
all
the
comments.
I
I
I
I
In
addition,
initially
pc
pc
as
a
controller,
will
obtain
the
information
about
the
network,
so
this
is
normally
done
through
igp
or
bgp.
So
pc
just
have
a
passive
session
or
peer
relation
to
any
one
of
the
nodes
in
the
domain
and
then
pc.
You
can
get
all
the
information
about
the
network,
such
as
link
bandwidth
and
lingua
color
and
loader
seats
in
including
those
multicast
c,
is
configured
on
on
the
replication,
node.
So
pc,
you
will
get
all
those
information.
I
So
after
piece,
I
have
connection
from
pc
to
possible
english
node
and
the
pc
get
those
network
informations,
so
pce
as
a
controller
can
accept
a
request
either
from
application
or
from
from
users.
So
the
request,
as
soon
as
the
pc
receives
the
request
from
user
or
application,
so
pce
will
compute
the
path
after
pc
get
a
pass.
I
I
So
after
english
note
received
this
secondary
list,
so
english
node
will
set
up
the
path
and
then
send
the
status
of
the
pass
to
pce
so
pce
after
receiving
the
report
from
the
english
node
pce
will
record
the
status
of
this
path
into
its
a
task
database.
So
that's
the
roughly
the
past
computation
and
the
past
setup.
We
got
into
stateless
there's
a
physics,
p20p
path.
Next.
I
Page
so,
as
I
mentioned
that
we
changed
the
name
so
because,
as
a
physics,
piton
p,
as
jeffrey
john
mentioned,
that
is
already
used
by
their
their
solutions,
so
they
have
different
meanings.
So
we
change
p
to
sr
p
term
p
in
our
document
to
stateless
s,
r,
v,
six
p
down
p,
because
in
the
context
of
our
document
the
p2p
path
is
we
don't
have
any
space
per
pass
space
in
the
core
of
a
network.
I
So
also,
we
added
the
descriptions
about
this
split
subtree.
I
think
this
is
a
very
good
suggestion
from
ac
ac,
so
we
added
text
with
regarding
to
so
in
the
case,
we
have
limited
about
a
segment
size
segment
this
size,
so
in
that
case
we
will
split
some
tree
into
multiple
sub
trees,
such
that
for
each
of
the
subtree.
I
So
also
we,
as
a
request
by
jeffrey
john
jefferson,
suggests
that
we
should
have
an
example
of
ip
header
using
one
of
our
configurations
see
the
comparisons,
so
we
give
a
example
encoding
using
gsrv6
compression.
So
this
gives
us
details
how
we
use
compressed
speed
to
encode
a
piton
b3
next
page.
I
B
B
I
Yeah,
basically,
I
send
a
request
to
lease
to
get
comments
regarding
to
this
draft,
but
we're
waiting
for
any
comments
from
the
spring
working
group.
B
A
Non-Multicast
related
discussions
going
on
that
it's
hard
to
break
in
which
is
partly
why
we're
working
on
some
of
that
related
work
here
in
pym.
But
there
was.
B
It
would
be
good
to
hear
yeah
to
what
you
know
whether
people
think
that
it
addressed
those
concerns
the
concerns
they
had
or
not
I
mean
there
were
there
were
people
in
the
in
favor
of
adopting
it,
and
there
were
people
like
again
and
it'd
be
interesting
to
see
you
know
if
if
some
people
have
changed
their
minds,
if
they
think
the
new
person
is
better
or
I
guess
it
could
be
worse,
but
hopefully
better.
A
Yeah,
it's
a
it's
a
good
question,
speaking
as
an
individual
it
just
it
goes
back
to
since
I'm
on
this
draft,
so
it
just
kind
of
goes
back
to
you
know.
We
already
have
a
good
solution.
We've
adopted
within
pim.
You
know:
do
we
need
another
solution
that
tackles
it
a
different
way?
It's
kind
of
the
age-old
question
and
my
views
are
our
and
I've
expressed
these
before.
A
In
other
words,
is
that
it's
we
should
be
open
to
multiple
solutions,
but
if
they're
technically
sound-
and
so
this
working
group
just
has
to
decide
that,
but
regardless
we
do
need
to
get
buy-in
from
spring,
because
we
got
buy-in
from
spring
on
the
existing
draft
that
we
are
working
on
in
pen.
B
A
B
Yeah,
I
think
the
next
steps
probably
should
be
to
both
to
ask
on
the
mailing
list
for
input
and
also
like.
I
can
also
try
to
trigger
help
trigger
that
and
and
also
to
reach
out
to
spring
again.