►
From YouTube: IETF114 PIM 20220726 1400
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
A
Did-
and
I
think
I
finally
figured
out
all
this
good
to
see
you
by
the
way
yeah
it's.
C
A
A
So
I'm-
and
I
hope
I
have
enough
battery
because
I
forgot
my
power
cord,
but
I'm
sharing
slides
from
here
yeah
and.
A
C
C
C
A
We
may
want
to
do
his
his
was
already
towards
the
end,
but
it
may
be
best
to
have
at
the
very
end
just
because
brian
hi
haberman
wanted
to
be
a
part
of
it
and
he's
got
a
conflict
so
anyway,.
C
C
A
I
can't
get
onto
the
internet.
Let's
continue.
A
C
A
D
C
C
Welcome
everyone
to
to
pim
at
itf
114.
This
is
the
second
physical
meeting,
it's
my
first
or
our
our
first
in
a
while.
C
So
it's
exciting
to
have
a
physical
meeting
here,
but
yeah,
I
think
maybe
most
of
the
participants
are
remote
though,
and
thanks
thanks
for
joining
us
a
couple
of
things
to
remind
people,
you
should
scan
the
qr
code
over
there
or
there's
also
one
by
the
entrance,
that's
for
the
blue
sheets
or
if
you
don't
want
to
scan
that,
just
go
to
meet
echo
and
and
basically
registers
sign
in
so
that
you're
in
the
queue
because
then
you
will
be
part
of
the
blue
sheets.
C
We've
also
been
asked
to
remind
everyone
to
wear
masks,
but
it
looks
like
everyone
is
doing
great
here.
So
thanks
for
that
yeah,
I
think
there
was
some
possible
exception
for
chairs.
But
as
long
as
you
can
hear
us,
okay,
I
guess
we're
happy
to
wear
our
masks
so
yeah,
let's
start
with
with
a
status
update.
C
Okay,
okay,
okay,
all
right!
So
here's
the
note
well,
so
you
should
know
this
by
now:
it's
more
or
less
how
the
itf
works
and
and
yeah
it's
something
everyone
should
know
next
slide.
This
is
the
agenda.
Any
concerns
about
the
agenda.
C
C
Okay,
so
we
yeah,
we
may
arrange,
rearrange
a
little
bit
like
brian
is,
is
not
here
yet,
so
he
will
be
a
little
late,
so
he
might
push
that
to
later,
but
yeah
we'll
we'll
see
how
that
goes.
C
Okay,
yeah!
I
should
have
that
here
all
right.
So
this
is
the
the
working
group
status.
So
we
have
a
pym
young
model
that
is
still
in
rfc
editors
queue
I
think
last
night
jf.
I
was
kind
of
optimistic
thinking.
It
would
be
published
soon,
but
I
think
it's
still
waiting
for
references
for
other
documents.
G
D
G
Forgive
me
if
I
get
the
number
wrong
9127
biz,
which
is
fixing
the
the
the
bfd
configuration
parameters,
so
you
can
either
specify
the
parameters
within
the
protocol
when
you
do
it
or
you
can
specify
them
externally,
because
bit
different
vendors
do
different
ways:
okay,
hopefully
it
didn't
take
too
much
time.
C
Okay,
yeah,
okay,
great
thanks
yeah,
so
at
least
yeah
it's
taking
a
while,
but
it's
it
it
it's
in
the
queue
it
will
be
published.
Yeah
I
mean
not
too
long
time
and
it
sounds
like
yeah.
Okay,
great
thanks.
We
also
got
the
igmp
mld
extension
draft,
that
is
in
the
ufc
editors
queue.
It
actually
is
in
like
auth
48
now
so
it
should
be
published
in
in
a
few
days.
I
think
then
they
got
the
dr
drafts,
the
improvement
and
backup
dr.
We
need
to
do
work.
H
C
Okay
thanks,
but
yeah
just
some
background.
So
basically,
both
these
drafts
talk
about
dr
behavior
and
one
common
thing
is
like
backup,
dr
and
as
a
working
group.
We
need
to
find
out.
Do
we
need
both
these
solutions
or
do
we
want
to
pick
a
solution?
I
think
that's
like
the
main,
the
main
concern
we
have
so.
A
C
We
yeah
we
need.
We
need
the
offers
to
to
push
this
a
bit
more,
and
we
also
want
all
of
you
to.
Please
read
the
drafts
and
share
your
thoughts
and
yeah.
We
we
need
your
help
to
figure
out.
What
is
the
best
thing
to
do
here.
Will
it
be
more
to
two
solutions
or
not
which
one
is
best
or
yeah?
C
It's
a
very
simple
concept.
In
a
way,
I'm
sure
everyone
here
knows
what
the
dr
is
and
it's
kind
of
important
to
to
solve
this,
and
we
don't
have
a
document
which
is
almost
I
mean
it's
almost
strange.
They
don't
have
a
good
solution
for
this
after
so
many
years
with
pim,
so
yeah,
it's
something
we
should
solve
and
it's
a
kind
of
fun
or
interesting
problem,
all
right.
Okay,
we
also
got
the
igmp
mlb
proxy
young
model,
but
this
in
yeah
we
requested
publication
and
you
actually
got
a
couple
more
two.
C
We
got
like
the
normal
register
packing
and
a
surf
packing,
but
we
also
requested
publication
for
us,
so
we
yeah,
we
yeah.
We
have
several
drafts
coming
up
or
yeah,
hopefully
published
sometime.
C
I
know
we'll
see
at
least
you're
in
the
queue
sorry
next,
yes,
okay,
then
we
have
sr
point
to
point
multi
point
to
multipoint
policy
that
we're
not
discussing
this
time.
We'll
have
some
update
later
on
the
igp
v3
mldb2
biz,
basically
revised
signals
because
overseas.
E
C
E
C
C
Let's
do
it
now,
yeah,
okay,
so
for
the
point
to
multi-point
policy,
how
many
people
have
read
the
draft
yeah?
I
guess
it's.
Okay,
we
got
remote
attendees
as
well.
I
guess
the
main
question
is
really.
Do
you
think
it's
ready
for
working
group
last
call
or
do
you
think
there
are
any
issues?
C
Okay,
yeah
and,
of
course,
I'm
not
prepared,
we
can,
we
can
pull
the
room
first.
Maybe
I
know
it's
not
fair
to
do
that.
First,.
C
Yeah:
okay-
let's:
let's
do
that,
maybe
after
the
the
first
presentation
then
I'll
be
signed
in
and
ready
to
do
the
poll
yeah,
okay,
so
I'll
do
a
little
poll
and
ask
you
guys
about
this
10-15
minutes
or
something
all
right.
Then
you
have
the
lisp
extensions.
C
E
Yeah
last
time
we
went
to
the
mpls
group
asking
for
some
comments.
I
haven't
got
back
any
feedback
yet
so
I
need
to
follow
up
on
that,
but
I
think
the
only
thing
that
is
left
there
is
getting
a
sub
tlv
assignment
from
ina.
Okay.
E
C
Yeah,
okay,
great
thanks
and
the
last
draft
they
have
is
the
mri
ferrari
I
like
to
call
it
tilfa,
but
anyway,
that
just
got
adopted.
So
that's
great.
We
did
the
adoption
call
just
a
few
weeks
back
and
it
was
good
support
so
but
yeah
it's
not
been.
No.
Actually
we
do
have
a
presentation
for
that
yeah
shortly:
yeah,
okay,
yeah!
So
that's
that's
the
status.
C
I
guess
we
can
move
to
the
move
to
the
first
agenda
item.
Do
you.
D
C
By
the
way,
hc,
yes,
you
are
in
the
queue
here,
but
you
probably
just
stay
there
from
before:
right:
yeah,
okay,
yeah,
all
right:
okay,
yeah,
your
song.
We
are
ready
for
for
your
presentation
here.
I
Okay,
hello,
everyone,
I'm
isung
liu
from
channel
mobile,
and
today
I
will
present
the
mlfr
based
on
tfa.
It
was
just
adopted
last
week
and
I'll
give
some
brave
introduction
and
update
information
next
time.
Please.
I
Okay,
this
is
a
briefing
introduction
and,
as
we
all
know,
for
the
rfc
7431,
we
have
the
pmmfr
mechanism
to
protect
the
the
pin
and
for
this
job
we
provide
a
new
mechanism
by
using
the
trfa
for
the
pmmr
with
no
additional
extension
of
pim
protocol,
and
we
will
just
update
the
detail
of
the
restrictions
of
the
pmfr
based
on
the
rfa
and
the
remote
rfa
and
the
next
slide.
Please.
I
And
for
the
rfa
to
the
mlfr,
the
team
can
establish
the
backup
tree
according
to
the
normal
protocol
procedure
of
the
rfc
7761,
and
it
can
send
the
drone
home
by
hope
to
establish
the
tree
and
next
slide.
Please.
I
After
the
I'm
of
arrow,
based
on
the
remote
of
a
and
the
pim
joint,
can
carries
the
rpf
vector
of
the
type
0
joint
attribute
to
take
the
pq
node
and
the
picon,
the
pico
node.
Like
the
picture
in
the
r3,
we
can
establish
the
first
part
of
the
backup
tree
till
the
r3
and
the
second
part
of
the
backup
tree
from
the
r3
to
the
original
multicast
source.
I
I
For
the
example
in
the
picture
the,
if
there
are
six,
then
the
pim
joint
to
be
to
establish
the
backup
tree,
it
will
send
the
package
directly
to
the
r5
and
our
file
will
will
forward
it
back
to
the
r6
and
it
cannot
to
establish
the
tree
and
we,
if
you,
if
we
use
the
remote
fa-based
mlfr
and
the
p-space
and
the
q-space
do
not
overlap.
I
I
So
for
the
unit
cost
we
can
use
the
trfa
to
get
stereotypically
a
100
percent,
cardboard
and
network
of
protection.
I
So
for
the
pmfr
pmmr
I
we
can
also
use
the
trfa
parts
to
build
the
backup
tree
and
we
can
use
the
node
seed
as
the
rpf
vector
of
type
zero
joint
attribute
like
the
in
the
picture
r4,
and
we
can
also
use
the
adjacency
seed
as
the
explicit
rp
f
vector
of
the
type
4
joint
attribute,
and
it
can.
I
Firstly,
it
can
establish
a
tree
from
the
r6
to
the
r4
and,
secondly,
it
will
directly
send
the
drone
to
the
upstream
neighbor
and
r3,
and
then
it
will
join
hub
by
hub
for,
according
to
the
normal
procedure
of
the
pin
protocol,
so
the
backup
tree
can
be
established.
I
For
the
next
step,
we
will
add
more
details
for,
for
both
in
the
sr
and
pls
and
the
sr
v6
networks
we
can
run
team
imovie
are
in
both
network
and
we
hope
to
get
more
feedback
from
the
working
group.
Okay,
that's
all
thank
you.
C
Yeah
all
right,
thank
you.
Any
questions
in
the
room
or
or
or
online
as
well.
C
C
C
C
Yeah,
all
right
so
for
the
star
point
to
point
point
to
multi-point
policy:
let's
see
if
it's
ready
for
last
call
I'm
going
to
start
as
a
polar
meet
echo.
So
I'm
not
quite
sure
whether
when
you
do
this
pulse
these
days,
if
everyone's
supposed
to
use
meet
the
echo
or
if
you
do
a
combination
of
the
room
and
meet
echo,
but
I
think
if
you're
in
a
room,
it's
it's
yeah.
It
should
be
sufficient
if
you
show
your
hands.
C
But
yes,
let's
say
if
you're
in
the
room
and
we
you
can
check
okay
alvaro
what
the
hell.
J
Should
we
do
hi,
I'm
gonna
turn
around
just
something
really
quick.
Everyone
should
scan
the
qr
code
at
the
entrance
because
that's
the
call
of
the
blue
cheats.
So
if
you
do
that
you're
logged
in
to
meet
echo
on
your
phone
and
then
you
can
just
do
the
poll
on
the
phone
channel,
okay,.
C
Okay,
let's
do
the
poll
for
everyone
so
yeah
are
you
all
logged
in
and
ready
for
the
poll?
Otherwise
we
can
wait
a
little
bit
but
okay,
let's
do
the.
C
Yeah
yeah,
if
you
scan
that
it's
like
meat,
echo
light
or
something
for
your
phone
yeah.
Okay,
let's
do
that
poll
so
yeah,
so
you
should
all
be
signing
to
meet
echo,
hopefully
and
and
and
see
that
the
poll
so
basically
gonna
start
this
poll
to
check.
If
the
point-to-point
point
to
multi-point
policy
draft
is
ready
for
working
replace
call.
C
A
C
K
C
D
J
C
I
agree:
that's
a
big
rate
yeah,
just
to
know
how
many
are
not
responding
at
all
or
yeah
yeah,
okay,
so
yeah.
I
think
I
think
it
hasn't
changed
for
a
while
as
we'll
stop
here
so
yeah
we
got
14
people
in
favor
or
saying
it's
ready
for
last
call,
but
you
also
have
two
people
saying
it's
not
ready.
C
So
look
yeah!
If
those
are
you
that
think
it's
not
ready.
If
you
have
any
comments,
I
mean
I
would
be
hap
or
we
would
be
happy
to
hear
if
you
have
any.
You
know
thoughts
on
what
what
is
missing
in
the
documents.
H
A
So
human,
can
you
remind
me
again
I'm
taking
notes,
so
I'm
just
catching
up
here,
so
this
draft
was
waiting
on
the
status
of
the
replication
segment
draft
in
spring
and
what's
the
status
of
that
draft
in
spring
right
now,
did
you
say.
E
So
I
think
we
are
it's
in
good
state
too.
We
are
trying
to
do
a
last
call
on
that
one
too,
on
the
replication
segment.
So
should.
E
You
think
I
don't
think
so.
I
I
think
it's
more
appropriate
to
do
a
last
call
on
this
one
first
and
then
go
to
the
replication
segment.
The
reason
for
that
just
refresh
everybody's
mind
is
that
this
draft
in
the
pim
it
actually
talks
about
the
tree
and
the
point
to
multiply
policy
that
you
set
up
on
the
route
and
the
replication
segment
draft
in
a
spring
talks
about
really
the
forwarding
plane
how
the
multicast
instructions
are
built
right.
E
A
Okay,
so
probably
what
we
should
do,
like
we've
been
doing,
is
just
maybe
touch
base
with
these
spring
chairs
and
just
let
them
know
what
we're
doing
and
make
sure
that
they're
cool
with
it
right
then
we'll
proceed.
C
Yeah,
so
you
know
we
did
the
the
poll
here.
A
C
C
E
Comments
any
thoughts
that
comes
in
mind,
please
let
us
know
and
we'll
differently.
E
C
We
often
have
an
issue
with
getting
enough
review
or
documents
so
yeah.
That
would
be
great
if
you
can
have
a
look
and
and
yeah
they'll
check
with
the
spring
chairs
and
we'll
probably
send
an
email
or
two
and
say
you
know,
there's
a
last
call
in
pym.
D
C
Yeah,
please
have
a
look
all
right.
Okay,
then,
I
guess.
E
All
right,
thank
you,
yeah,
it's
good
to
be
here,
seeing
everybody
smiling
behind
the
mask,
but
the.
E
That's
fine
yeah,
so
pim
light
just
to
give
everybody
overview
of
what's
going
on
here
is
eventually
in
this
meeting.
We
want
to
see
whether
we
can
adopt
this
draft
as
a
itf
draft
and
move
forward
or
not
so
this
presentation
eventually
the
end
goal.
Is
that
exit
slide?
E
Please
so
I
mean
we've
done
the
background
a
couple
of
times,
but
just
to
refresh
everybody's
memory,
there
could
be
two
pin
domains
that
are
disjoint
and
you
might
want
to
signal
multicast
states
between
these
the
two
pim
domains
and
to
do
so,
you
don't
want
to
bring
the
pim
adjacency
up
or
the
neighborship
up.
E
So
it's
hard
to
breathe
and
talk
with
this
thing.
It's
you
don't
want
to
bring
the
pym
neighborship
up
between
the
the
two
pin
disjoint
routers.
So
basically
you
just
want
to
use
the
join
and
the
prunes
messages
between
these
two
pin
routers
to
communicate
the
multicast
state,
one
of
the
best
examples
for
it
is
pim
signaling
over
the
beer
network,
so
obviously
in
rfc
7761
it
was
described
that
for
pim
joins
and
prunes.
E
Well,
the
assert
message
should
not
be
there
because
in
the
next
slide
you
will
see
that
was
a
mistake
by
me
for
pim,
join
and
prunes.
You
need
to
make
sure
that
there
is
a
pim,
hello
message
and
adjacency
up
before
you
process
those
joints
and
prunes
and
a
pim
light
interface
is
basically
an
interface
that
allows
you
to
process
those
joints
and
prunes
without
bringing
up
a
team
neighborship
between
the
two
routers
exercise.
E
On
the
version
two
of
the
draft,
a
couple
of
decisions
were
made,
so
we
are
keeping
the
name
as
ping
light.
There
were
some
back
and
forth
whether
it's
light
light
whatever
it
is.
I
think
we
are
keeping
the
name,
as
is
you
know
again
the
the
goal
of
the
draft
already
explained.
So,
for
the
sake
of
time,
I'm
going
to
skip
that
in
the
new
version
of
the
draft
based
on
discussion
with
some
of
the
experts,
we
removed
the
assert
messages.
E
Basically,
we
feel
that
when
the
two
pim
domains
are
connected
via
a
pim
light
interface,
there
is
no
need
for
assert
messages
and
the
pin
boundary
routers.
They
need
to
ensure
that
they
are
not
duplicating
the
multicast
traffic
from
one
domain
to
the
other
domain,
over
the
pin
light
and
last
but
not
least,
is
when
it
comes
to
the
pim
light
interface.
E
In
the
second
case,
like
beer,
you
could
have
a
pli
configured
automatically
on
the
beer
facing
interfaces
and
again,
in
that
case,
for
security
reason,
we
don't
want
to
start
processing
all
these
join
and
prune
messages
on
all
the
interfaces
throughout
the
router.
So
it
is
suggested
that
for
these
automatically
cases
that
pli
is
going
to
be
configured
underneath
the
hood
there
should
be
a
mechanism
to
understand
that
these
plis
are
facing
the
pin,
sorry,
the
beer
domain
and
explicitly
on
those
interfaces.
E
We
accept
the
join
and
the
prunes
coming
because
it
would
be
from
down
a
stream
coming
from
downstream
again.
These
are
security
concerns,
and
I
guess
this
last
point
is
something
that
we
can
discuss
a
little
bit
further
to
understand
whether
this
whole
configuration
and
security
mechanism
is
necessary
in
this
draft,
or
we
should
omit
it
from
the
draft.
E
But
anyway,
that's
one
point
of
discussion
next
slide,
please
yeah!
So
those
are
the
changes,
and
you
know
I
guess
what
the
authors
they
feel
like.
Is
it's
ready
for
adoption
and
take
it
to
the
nexus.
A
Standing
sandy
is
oh
yeah,
yeah.
L
Okay,
okay
and
associated
I'll
do
the
proper
adoption
of
this
draft,
and
I
think
that
it's
great,
if
more,
details
can
be
added
in
the
draft,
such
as
some
comments
from
the
last
meeting,
and
I
also
think
that
if
we
received
hello
from
the
pli,
what
will
we
do
we
do
if
we
should
think
that
it's
a
valid
package
or
we
will
do
something?
I
think
the
details
such
as
forget,
for
example,
for
the
hollow
package
process
need
to
be
added
in
the
draft
too.
A
M
M
Yes,
the
bootstrap
forwarding
requires
pim
neighbors
on
an
interface
when
a
string
router
has
to
forward
bsm's
only
on
interfaces
that
neighbors.
So
if
you
don't
have
them
neighbors,
then
we
need
to
consider
how
bsn
will
be
forwarded.
C
Yeah
yeah
speaking
as
an
offer,
I
guess
yeah,
I
agree
we
we
need
to
mention
that
and
can
probably
just
be
a
statement
saying
you
know
that
they
are
not
supported
and
you
need
to
configure
our
piece
in
some
other
way.
Probably,
but
but.
C
Should
probably
look
at
all
the
message
types
and
make
sure
that
they
are
all
covered
in
some
way?
Like
mentioned,
you
know,
okay,
okay,
I
know
you're
kind
of
saying
only
support
joint
print.
It
might
be
good
to
sort
of
mention.
You
know
why
those
other
messages
are
not
needed
or
you
know.
C
C
I'm
not
sure
if
she
understands
it
I
mean,
should
we
do
a
poll
or
yeah.
D
A
M
A
L
A
Yeah
we
just
need
to
have
you
ask
the
working
group
you're
chairing
this,
your
draft,
so
that's
what
we're
asking
but
we're
going
to
go
ahead
and
initiate
a
poll,
but
on
the
list
we're
going
to
need
to
have
you
send
an
email
out
to
the
list
asking
for
opinions
on
adoption,
but
we'll
we'll
talk
to
you
after
this
meeting.
C
I
would
say
that
you
know
this
is
motivated
by
beer,
but
there's
other
implementation
during
doing
this
kind
of
behavior
in
various
contexts
as
well,
but
we
never
had
any
document
describing
how
to
do
this
or
it's
more
like
implementation,
specific
thing
so
far
but
yeah.
Let's
start
the
poll
and
sandy
we'll
check
on
the
mailing
list,
so
the
poll
here
is
just
to
get
some
some
idea.
D
C
C
N
N
All
right
so
a
little
bit
about
the
onenet
networks,
because
it
might
be
a
little
different
than
the
networks
here.
We're
used
to
looking
at
these
are
mostly
self-contained.
They
don't
have
typically
internet
connections
if
they
do,
there
might
be
like
a
satellite.
N
Nmea
has
three
different
standards.
O183
is
something
that
you
probably
have
in
all
of
your
cell
phones,
because
that's
what
a
lot
of
the
gps
chips
use,
enemy
2000
is
a
can-based
network
and
then
we're
working
right
now
on
onenet,
we've
published
it
and
are
currently
it's
in
early
stages
of
adoption.
N
N
Boats
with
one
display
a
couple
of
sensors
to
larger
tankers
or
container
ships
like
this
so
and
again,
typically
these
these
are
not
connected
to
the
internet.
So
what
we're
looking
at
is
a
lot
of
sensor,
traffic
being
transmitted
to
displays
for
the
pilot
to
kind
of
digest
and
use
for
navigation
and
safety
and
life
critical
type
stuff
like
that.
N
N
So
this
is
kind
of
illustrated
by
this.
We've
got
on
the
right,
a
one
gigabit
sensor,
in
this
case
a
radar
going
sending
traffic
off
to
100
to
a
one
gigabit
display,
but
then
you
might
have
a
lower
cost
sensor
that
only
has
a
100
megabit
or
even
maybe
a
10
megabit
connection
to
the
switch,
and
so
just
in
a
standard
switch
where
the
traffic
goes
everywhere.
Multicast
traffic
goes
everywhere,
that's
going
to
go
out
on
that
100
megabit
link,
and
even
if
the
sensor
itself
filters
out
that
traffic
is
often
times
the
this.
N
Chip
has
the
ability
to
censor
that,
so
it
doesn't
go
to
the
cpu,
but
even
if
it
does
filter
that
out,
it
will
still
overload
that
link
and
so
important
traffic
will
get
dropped
by
the
switch
next
slide.
N
N
So
what
multicast
snooping
helps
us
with
is
you
have
a
managed
switch
there
and
the
switch
will
receive
igmp
or
mld
join
messages
and
send
those
up
to
the
cpu?
The
cpu
will
use
that
to
kind
of
program
the
the
switch
part
to
only
forward
the
multicast
traffic
to
the
to
a
given
port.
That
has
a
device,
that's
interested
in
it.
N
This
kind
of
expands
here,
if
you
have
several
switches,
all
chained
together,
those
those
multicast
joint
messages
will
kind
of
percolate
through
the
network
and
each
switch
will
be
configured
according
to
if
there's
any
device
attached
to
that
port.
That's
interested
in
that
traffic.
So,
in
this
case,
the
100
megabit
sensor
does
not
request
the
traffic
from
the
radar,
and
so
the
switch
does
not
for
the
traffic
there
and
the
link
is
available
for
other
important
traffic
to
get
through
next
slide.
N
N
So
unicast
address
has
a.
This
is
a
link
local
address,
so
the
first
part
of
that
is
going
to
be
fe,
80
and
then
the
last
64
bits
are
the
interface
id
the
next
slide.
N
When
we
start
looking
at
multicast
addresses
according
to
rsc
4291,
the
lower
112
bits
of
the
multicast
address
is
the
group
id.
Then,
when
you
look
at
3306
there's
a
kind
of
the
next
iteration
of
this,
which
is
a
unicast
prefix
based
ipv6
multicast
address
where
it
calls
out
that
kind
of
divides
up
that
112
bits
into
the
some
reserved
the
prefix
length
network,
prefix
itself,
64
bits,
and
then
the
group
id
is
shortened
to
32
bits.
N
Then
you
get
into
a
link,
scoped
ipv6
multicast
address,
and
this
is
a
really
interesting
idea.
It
basically
allows
each
device
on
the
network
to
have
a
group
of
multicast
addresses
that
are
automatically
assigned
to
it
as
kind
of
the
benefit
of
getting
a
link.
Local
ipv6
multicast
address,
and
what
happens
here
is
that
network
prefix
is
the
interface
face
id
taken
from
the
link
local
address
and
then
the
the
group
id
is
allocated
as
per
3307.
N
So
some
guidelines
from
3307
on
how
the
group
id
is
allocated,
there's
different
ranges.
Basically,
the
there's,
a
permanent
ipv66
multicast
addresses
and
those
are
allocated
by
iana,
there's
a
link
to
the
registry
there
and
then
there's
a
permanent
group
ids
again
allocated
by
iana
and
then
there's
dynamic,
multicast
addresses.
So
basically,
if
the
most
significant
bit
is
set,
then
it's
a
dynamic
one.
N
Rc
2464
specifies
that
the
destination
multicast
mac
address
is
the
first
two
octets
or
33,
and
then
the
last
four
octets
are
the
last
four
octets
of
the
ipv6
multicast
address.
So
if
you
look
at
a
link,
scope,
ipv6
multicast
address
those
last
four
octets
are
the
group
id
and
the
group
id
is
not
differentiated
between
different
interface
ids
there.
So
different
nodes
can
generate
different,
like
local
addresses,
with
the
same
mac
address
next
slide.
N
So
we
looked
at
a
number
of
solutions
to
this,
and
one
that
I
left
out
of
the
slide
and
I'll
start
with
is
having
the
switch
itself
look
at
the
ipv6
address,
but
rfc.
I
think
it's
4541
talks
about
kind
of
gives,
an
overview
of
multicast
snooping
and
there's
a
survey
survey
that
they
did
of
the
various
vendors
and
most
vendors
are
not
looking
at
the
ipv6
address
when
they're
making
switching
decisions
they're
just
looking
at
the
mac
address,
so
other
solutions
are
source.
N
Specific
multicast
and
that's
not
universally
supported
by
switch
hardware
seems
to
be
more
for
multicast,
going
between
different
networks,
there's
madcap,
which
is
discussed
in
rfc
2730,
and
this
uses
a
central
server
to
allocate
addresses,
which
and
allocate
dynamic
addresses,
which
would
be
a
great
solution
in
many
types
of
networks,
but
for
the
networks
that
we
deal
with,
we
try
to
avoid
single
points
of
failure
because
the
environment
we
can
operate
in
can
be
pretty
harsh
sometimes
so
we
could
basically
take
this
and
find
a
way
to
shoehorn
it
into
the
protocol.
D
N
Be
probably
fairly
tailored
to
our
solution
and
not
really
usable
by
anybody
else
at
least
not
not
easily,
and
it
wouldn't
be
an
easy
way
to
do
it.
Anyway,
there
is
a
another
protocol.
That's
in
a
draft
called
zmapp,
which
is,
I
think,
zero
configure.
Zeroconf
multicast
address
allocation
protocol,
never.
N
The
draft
expired
in
2003
and
there's
a
a
lot
of
things
that
are
missing
from
it.
Specifically,
the
addresses
and
ports
are
listed
as
tbd
next
slide.
Yeah.
F
Lenny
giovano
juniper
how?
How
are
the
receivers
expressing
they're
trying
to
join?
Are
they
just
sending
standard,
igmp
or
mld
reports,
or
is
there
some
other
protocol.
F
And
you
say,
search
specific
multicast
is
it's
not
uni
ssm,
isn't
universally
supported
by
switch
hardware?
What's
specific,
is
it
like?
Mlbv2
is
not
supported
on
hardware.
What
what
parts
of
ssm
is
it.
N
Well,
it's
mainly
the
the
tables
that
they
they
use
to
make
decisions
as.
H
N
As
which
addresses
are
forwarded
to
which
ports
don't
have
any
sort
of
entry
database
entry
there
for
the
source
address,
it's
all
focused
on
the
destination
address.
So
if
you
look
at
the
the
vector
and
the
address
translation
unit,
there's
basically
one
vector
which
is
a
bit
field
that
says
these
are
the
ports
that
this
address
is
on
and
then
there's
another
buffer
for
what
the
multicast
the
destination
address
is,
and
that's
that's.
F
N
F
The
snooping
mechanism
used
by
the
switches
to
determine
if
a
port
has
an
interested
receiver
and
block
it.
Otherwise,
is
that
just
standard
mld
snooping
or
is
it
something
else.
N
Yeah
it's
basically
standard.
What
we
find
is
that
the
switch
part
itself
provides
a
functionality
where
it
recognizes
an
mld
or
igmp
message
and
it'll
forward
that
up
to
a
cpu
and
then
the
cpu
reads
that
and
says:
okay
well,
based
on
this,
I've
got
somebody
interested
in
this
data
on
this
this
port.
So
now
I've
got
to
modify
that
entry
in
the
address
table
to
forward
traffic
onto
that
port.
F
So
so
just
it's
basically
doing
mld
snooping,
but
it
doesn't
it
can't
look
at
the
source
it
can.
Only
look
at
the
group
address
is
that
the
the
issue?
That's.
C
O
You
basically
are
saying
that
you
know
everybody
that
is
interested
in
the
group
receives
it
from
all
the
sources.
If
that's
not
what
you
want,
you
need
to
use
ssm,
but
it's.
D
N
O
O
Right,
but
I
what
what
are
you
trying
to
do
the
the
use
case
that
you
explained
said
that
only
the
the
folks
interested
in
something
join
a
group?
So
that's
asm!
Is
that
what's
sufficient
right,
so
if
you're
joining
the
group
you're
only
getting
the
traffic
for
that
group,
is
that
sufficient
for
you.
N
That
that
would
be
sufficient.
Yes,
okay,.
N
N
The
earlier
diagrams,
where
we
have
a
the
earlier
diagrams,
where
we
have
a
high
speed
sensor
and
a
low
speed
sensor
connected
to
the
same
network,
we
want
to
have
different
speeds
of
traffic,
only
be
directed
to
the
ports
for
sensors
or
devices
that
can
handle.
That.
O
But
give
me
another
example
where
you're
doing
anything
similar
and
you're,
not
relying
on
pre-allocated
static.
Addressing
I
mean,
that's
that's,
basically
what
most
everybody
uses
and
somehow
we've
survived
three
decades
with
that
and
we're
all
happy
that
this
stuff
in
the
90s
didn't
get
adopted
because
everybody
figured
out
some
easy
scheme
to
use.
You
know
static,
address
allocation
or
other
workarounds
on
these
protocols,
and
people
have
wasted
300
pages
of
wonderful
documents
about
this
right
right.
O
So
no
I'm
just
I'm
just
saying
in
terms
of
if
we
want
to
bring
any
of
this
stuff
back
for
the
dynamic
allocation,
I'm
trying
to
explain
the
history
that
we
had
30
years,
people
of
giving
up
on
the
idea
and
coming
up
with
simple
pragmatic,
you
know
static,
address
allocation
management
seems,
and
we
have
published
a
lot
of
rfcs
about
that
as
well
right.
So
I'm
trying
to
answer
to
him.
D
N
N
A
good
question
I
mean,
I
think,
that's
probably
a
fair
thing
to
require
somebody.
That's
installing
a
network
on
a
big
tanker
ship,
but
a
lot
of
the
users
that
we
have
are
we
can
fishermen,
they
don't
understand
anything
about
networks,
and
so
we
try
to
take
care
of
as
much
of
that
as
as
possible
for
them.
O
These
are
all
standalone
networks,
so
every
stuff
that's
being
deployed
is
going
to
be
running
in
a
separate
instance
of
itself,
which
is
why
you
can
very
easily
you
know
come
up
with
deployment
profiles
that
say:
okay,
this
the
equipment
by
default,
unless
you
configure
it
differently,
will
use
the
following.
You
know
addresses.
O
Is
is
hard
coding,
multicast
addresses
into
their
applications,
and
everybody
gets
problems
with
doing
that.
Once
you
get
into
larger
networks,
you
don't
have
larger
networks.
You
have
something
very
well
predictable
in
terms
of
you
know
how
much
equipment
that
needs
how
many
different
speeds.
So
you
come
up
with
an
address
plan.
We
can
consult
on
that
perfectly
well
and
that
gets
hard-coded
into
the
devices.
That's
what
everybody's
been
doing
and
and
that
guy
has
probably
been
answering.
C
O
O
That's
that's
the
point
that
one
needs
to
get
to
to
have
justification,
not
to
just
do
the
in
my
opinion,
obvious,
which,
as
I
think
most
everybody
has
done
right.
If
somebody
really
comes
to
the
point
of
figure
out,
I
need
a
dynamic
allocation.
Then
it's
most
likely
these
days
going
to
be
some
some
more.
You
know
application
side
with
a
controller
stuff
than
trying
to
rely
on
network
protocols.
N
N
C
D
E
Just
to
give
you
an
example
like
we
have
the
same
type
of
issues
with
iptv,
we
got
480
streams,
1080
streams,
etc,
etc.
So
maybe
this
is
useful
to
you.
Folks
too,
we
use
zero
touch
provisioning
to
download
the
configuration
to
the
to
the
router.
E
As
it
was
mentioned,
we
use
a
static
multicast
addressing
via
the
zero
touch.
So
when
you
download
the
configuration
the
static
multicast
is
within
the
configuration
saying
that
anything
coming
from
this
interface
needs
to
go
to
a
source
that
is
480.
Anything
coming
from
that
interface
needs
to
go
to
a
source
that
is
1080..
N
Is
it
that
you
have
like?
Do
you
work
with
another
like
a
server
to
kind
of
upload
your
configuration,
and
then
it
configures
it
for
you
and
you
download
that.
E
Yeah,
so
zero
touch
provisioning.
What
what
it
is
is
unicast
comes
up
and
you
do
a
dhcp
discovery
to
get
your
router
ip
address
and
then
based
on
a
bunch
of
dhcp
options.
E
You
go
get
your
configuration
like
in
a
dhcp
option.
61.
You
say
that
hey.
I
am
this
router
with
my
mac
address
and
you
get
the
configuration
specifically
for
that
router
and
then
the
provider.
Since
it
knows
this,
router
is
sitting
in
los
angeles
as
an
example.
It
knows
that
interface,
one
two
three,
those
are
four
idea:
streams,
interface,
567,
those
are
like
1080
or
4k
streams,
and
it
can
assign
the
the
the
source
addresses
accordingly,
as
a
static
multicast
address
to
to
those
interfaces.
E
E
N
What
we
would
try
to
avoid
about
that
is
having
a
dhcp
server,
because
again
that
that
represents
a
single
point
of
failure.
Now
that
the
I
mean
that's
certainly
an
interesting
idea
in
that
you,
you
have
some
some
point
in
time
where
you
configure
everything
and
everybody
chooses
that
address
and
stays
stays
with
that
address,
and
that's
certainly
yeah
that
that
makes
sense.
N
Even
can
even
negotiating
what
those
addresses
are.
Are
a
protocol.
F
A
30
how
about
rfc
3306,
I'm
not
sure
if
you
mentioned
that
I
think
you
said
30
307,
but
isn't
that
exactly
what
would
work
here?
It's
just
it's
that
you
know
you
can
derive
a
multicast
address
from
a
unicast
address
in
basics,
right.
N
So
the
problem
with
that
is
is
once
you
do
have
that
that
unique
ipv6
multicast
address
when
you
go
to
transmit
that
on
ethernet,
the
group
id
part
is
not
unique
on
the
network.
The
interface
id
is
unique
on
the
network
and
that's
64
bits,
but
the
group
id
the
lower
32
bits.
K
So
your
presentation
was
really
good
by
the
way
and
you
were
really
well
prepared
and
did
a
lot
of
research
on
all
the
puzzle
mechanisms.
So
thanks
for
that,
but
I
want
to
wait
to
the
you
finish.
Are
you
are
you
done
with
your
presentation
or
you
still
have
more.
K
O
Just
just
yeah
I
took
care
of
a
few
more
people.
Okay,
I
just
wanted
to
say
I
didn't
want
to
sound
dismissive
right,
so
I'm
happy
to
help
as
well
with
this.
It's
just
that
you
know
when
people
think
about
the
solution.
They
come
up
with
these
things.
Oh
no,
I
don't
know
the
address.
I
need
to
learn
the
address
and
the
question
is
okay.
How
do
you
learn
the
address?
Well,
I
have
a
name.
O
Okay,
how
do
you
learn
the
name
when
you
know
the
name
you
can
equally,
you
know
have
an
address
right.
So
that's
why
a
lot
of
these
pragmatic
solutions
come
up
once
you
go
through
the
different
steps
of
the
design
process
right
and
and
that's
what
I
was
trying
to
shortcut
but
yeah,
it's
a
little
bit
longer
explanation.
Typically,
okay,.
C
Okay,
so
yeah,
I
I
mean
I'm
yeah,
I'm
in
line
also,
but
okay
as
a
participant,
so
it
sounds
to
me
like,
like
discovery,
is
like
important
to
you
right.
You
need
some
kind
of
discovery
mechanism,
so
ssm
would
probably
not
work
right
because
you,
how
would
you
know
the
source
address
or
would
can
you
see
some
way
so.
N
Yeah,
the
so
the
protocol
that
we're
working
with
uses
mdns
as
a
discovery
mechanism
for
a
lot
of
the
services
and
then
oftentimes
that
will
lead
into
some
sort
of
rest
api
that
publishes
these
or
might
publish
it
as
part
of
a
text
record.
But
for
the
purposes
of
this,
we
kind
of
consider
that
kind
of
out
of
scope
of
dynamic
assignment,
although
we
certainly
wouldn't
be
against,
including
that,
in
whatever
solution
we
eventually
arrive
at.
C
Right
so
yeah
you
could
potentially
use
maybe
ssm
for
the
actual
data
traffic,
but
you
need
some
way
of
discovering
what
the
user
is.
N
Well,
even
then,
I
I
don't
think
the
problem
is
that
we
couldn't
discover
the
different
sources.
I
think
the
problem
is
that
the
hardware
doesn't
support.
C
C
N
D
B
Oh,
thank
you.
Thank
you,
nate.
I
think
this
is
an
interesting
topic.
My
question
is
not
about
the
whether
we
need
a
solution
about
dynamic
multicast
address
allocation,
I'm
more
interested
in
the
scenario
itself.
Do
you
know
the
exact
how
many
sensors
and
displays
will
be
there
in
this
multicast
domain?
N
Sure
yeah
good
question,
so
we're
we're
looking
to
support
things
that
can
be
very,
very
small,
just
one
display
and
and
one
sensor
to
potentially
hundreds
of
sensors.
N
You
know
you
can
imagine
a
container
ship
might
want
to
have
different
sensors
throughout
the
the
boat
temperature
sensors
depth,
sensors,
all
that
type
type
of
stuff.
So
basically
a
lot
of
flexibility
and
where
the.
B
Okay,
so
actually
I'm
more
interested
how
many
numbers
about
these,
these
players,
it
will
will
there
be
a
lot
of
displays
or
just
several,
because
we
ask
the
the
question
about
the
scenario,
because
we
have
met
similar
use
cases
in
enterprise.
So
I
think
the
scale
coyote
also
matters
how
to
solve
the
problem.
A
N
We
let
nate
do
that
now.
Okay,
next
slide
so
right
through.
N
I
read
through
the
the
z
map
draft
and
it's
it's
a
really
good
starting
point.
It
has
some
things
in
there
like
querying
for
addresses
to
see
if
they're
being
used
and
in
that
regard,
it's
similar
to
what
you
would
see
with
the
the
link
local
stateless
address,
auto
configuration
stuff.
So
there's
at
basically
queries.
This
is
actress
and
use,
and
then
you
have
address
and
use
messages
basically
saying.
N
It
wasn't
quite
clear
whether
it
allowed
for
multiple
maas
that
stands
for
multicast
address
assignment
server.
I
think
whether
it
allow
for
multiple
on
on
a
host,
I
kind
of
got
the
impression
that
it,
it
only
had
a
single
one,
and
I
didn't
see
a
reason
why
you
couldn't
have
multiple
but
the
the
environment
that
we're
operating
in.
We
we
want
to
allow
for
different
applications
running
on
the
same
host,
to
also
coordinate
with
each
other
and.
N
Of
the
network,
you
might
find
that
on
something
like
a
pc
installation
where
they
might
have
a
charting
application
and
a
radar
application
manufactured
or
designed
by
two
different
manufacturers
installed
on
the
same
terminal
and
those,
so
those
pieces
of
software
need
to
to
communicate
with
each
other
without
relying
on
some
sort
of
underlying
assumption
about
what
software's
on
the
the
the
platform.
N
The
big
one,
of
course,
is
required
required
offending
addresses
with
the
same
destination.
Mac
address
right
now,
it's
it's
tailored
just
to
the
ipv
ip
address,
both
ipv4
and
ipv6,
and
then
allocate
group
ids
for
zero
comp
dynamic
addresses.
N
So
if
we,
if
you
look
back
a
couple
sides
ago,
we
talked
about
assigned,
addresses
both
group
ids
and
actual
addresses,
and
then
there
was
a
range
for
dynamic
like
I
would
propose
that
we
carve
out
a
range
of
that
dynamic
address
specifically
for
zero
conf
stuff,
and
that
would
be
to
avoid
conflict
conflicts
with
a
matcap
server
if
they
happen
to
be
installed
on
the
same
network.
C
N
C
N
Right
yeah
now
it
doesn't
mean
that
we
wouldn't
be
interested
in
supporting
other
right
other
scopes.
Yeah.
C
K
Hi,
this
is
dina
again
great
job
on
the
presentation,
so
I
there
is
really
a
simple
solution
to
do.
Group
allocation.
You
could
just
do
hashing
on
the
sources
and
receivers
I'll
explain
in
a
detail
in
a
minute,
but
I
have
a
couple
questions
about
your
deployment
just
to
make
sure
it's
clear
all
the
devices,
the
sources
and
the
receivers
are
all
on
the
ship
and
that's
a
single
scope
of
multicast.
That's
going
to
run
through
a
switch.
There's
no
routers
involved.
Is
that
true
or
false
that.
N
K
In
there,
okay,
so
the
solution
doesn't
matter
if
it's
multi-route
or
hop
or
just
single
it.
And
since
you
answered
stig's
question
about
using
multicast
dns,
it
makes
the
solution
even
simpler,
since
you're,
using
multicast,
dns
you're,
looking
up
a
dns
name,
so
you're
actually
naming
each
of
the
group
communication
that
you
want
to
do.
So
all
you
have
to
do
on
the
sources
in
the
receiver
is
run
a
sha
256
hash
on
that
name.
K
That
will
create
a
unique
address
that
both
the
sources
and
the
receivers
will
sync
to
you,
mld
on
the
receiver
side
to
that
address,
and
then
you
send
from
the
source
on
the
exact
same
address.
You
can
ahead
of
time,
look
at
those
names
and
if
they
hash
to
the
same
lower
to
32
bits
which
will
collide
at
ethernet.
You
pick
a
different
name
so
that
part's
static,
but
the
sources
and
receivers
can
be
dynamic
and
if
they
hash
they'll
hash,
the
same
addresses
and
the
problem
solved.
K
No
third
party,
it's
completely
decentralized,
doing
the
hashing
to
figure
out
what
the
group
address
is
is
trivial.
I
could
write
you
a
a
ten
line.
Python
program
in
a
second
to
do
that
and
the
problem
of
address
l
group
allocation
is
solved
comments,
reactions.
N
Yeah,
so
that's
that's
a
really
interesting
idea.
I
think
the
the
the
thing
about
that-
maybe
I
didn't
mention
before
is
we
also
want
to
be
as
as
standard
compliant
as
possible,
so
that
you
know
oftentimes
people
aren't
designing
ip
cameras,
for
example,
specifically
for
the
marine
environment
that
will
run
this
protocol.
So
we
want
to
be
able
to
take
an
off-the-shelf
solution
and
and
put
it
on
the
boat,
and
we
want
those.
K
Yeah,
you
run
the
group.
The
hash
goes
into
the
ff01
local
scope,
so
nobody
else
can
touch
what
you
want
and
if
you
want
to
play
with
the
high
order
bits
to
make
it
unique
from
other
applications,
you
can
do
that
as
well.
But
what
we're?
What
we
want
the
hash
to
do
is
it's
going
to
be
a
256
bit
hash
but
you're
going
to
truncate
it
to
the
lower
32
bits
or
anywhere
in
the
middle.
K
But
the
whole
point
is:
is
you
don't
want
your
multiple
groups
to
have
address
collision,
but
that's
easily
avoided
up
up
ahead
of
time
by
picking
the
right
sort
of
names,
no
random
number
generators,
both
the
receivers
and
and
the
source
hash
exactly
on
the
same
value,
because
you
want
them
to
get
the
same
group
address,
makes
sense.
Well.
K
N
If
we
were
to
say
that's
how
the
onenet
protocol
should
do
it,
how
do
we?
How
do
we
know
that
when
we
go
to
to
integrate
other
types
of
devices
on
there,
because
a
lot
of
networks,
marine
networks
are
not
necessarily
going
to
be
marine,
only
devices
we're
going
to
have
other?
You
know
tvs
and
cameras,
and
you
know
satellite
systems
and
stuff
like
that.
How
do
we
know
that
we're
not
going
to
get
collisions
from
those
other
devices?
The.
K
A
K
Yeah
right,
oh
so,
you're
worried
about
mac
juris
collision,
yeah,
that's
a
concern.
You'll
have
to
make
sure
that
it
doesn't
happen.
I
mean
if,
if
you
want
to
check
the
switch
to
see
what
groups
are
joined
to
see
if
there's
collision,
then
you
have
to
do
collision
avoidance
or
avoidance.
I
want
to
do
collision
well
there
you
have
it
sorry.
I
said
the
wrong
word:
you're
doing
collision
detection.
I
want
you
to
do
collision
avoidance
ahead
of
time,
so
you
don't
have
to
deal
with
the
collision
at
all.
D
N
That
that
same
collision
avoidance
algorithm,
I
think,
there's
still
potential
for
race
conditions
based
off
of
who
understands
the
state
of
the
network
at
any
given
time
as
far
as
calculating
the
names
and
determine
oh
somebody
else.
Has
that
particular
one
I'm
going
to
go
on
to
the
next
one.
K
If
there's
two
different
sets
of
applications
with
a
different
set
of
rules,
that's
when
the
problem
comes
in
yeah
yeah,
but
we
we
could
talk
about
what
you
anticipate
or
think
the
future
applications
will
be.
That
may
cause
the
collisions
and
address
it,
but
at
least
for
the
ship.
The
picture
you
showed
on
this
slide
there's
a
simple
solution.
K
C
C
K
Why
I
said
we're
just
clouding
the
discussion
by
calling
it
ssm
or
asm,
because
it's
right
now,
it's
on
just
a
layer,
two
switch,
so
we're
joining
groups
and
sources
are
sending
to
those
groups.
End
of
story
right
I
mean
ssm
and
asm,
is
a
concept
for
multi-hop
route.
Multicast
routers
right.
F
Yeah,
I
would,
I
guess
one
bit
of
advice.
I
guess
that
probably
each
of
us
who've
been
around
for
long
enough
to
know,
is
you
know
some
of
the
old
proposals
you
mentioned
madcap
and
there
was
masc
and
we
we
moved
away
from
this
many
years
ago,
and
there
were
good
reasons.
You
know
a
lot
of
complexity
not
worth
and-
and
we
ended
up
coming
up
with
much
better
static,
derivable
mechanisms.
F
I
think
what
dino's
suggesting
is
kind
of
a
you
know,
another
clever,
a
way
of
doing
that.
You
know.
We've
we've
come
up
with
unicast
multicast
prefix
mapping,
we've
come
up
with
glop.
Each
of
these
were
addressing
mechanisms
that
were
derivable,
simple
and
didn't
require
you
know
complex
protocols.
F
You
know
we
got
away
from
that
for
a
reason,
so
I
would
caution
against
any
any
trying
to
reinvent
a
wheel
that
we
abandoned
many
years
ago,
because
you
know,
I
think,
if
you
continue
down
the
kind
of
derivable
static
path
you
you
make
like
dino's
idea.
You
may
end
up
with
you'll,
probably
be
much
happier
in
the
end
than
having
some
server
and
service
with
a
weird
protocol
that
you
know
is
just
going
to
break
and
yeah.
K
This
is
dino
again
real,
quick
in
some
deployments.
I've
been
involved
with.
If
you
have
one
source
sending
to
multiple
receivers
ie
one
group
we
would
make
the
group
address
be
equal
to
the
lower
bits
of
the
source
address,
since
it
was
always
one
source
and
it
was
nice
because
if
you
wanted
to
look
at
content,
you
would
know
the
source
address
by
just
looking
at
the
group
address.
So
that's
even
that's
another
way,
but
that's
a
one-to-many.
Only
solution.
C
Yeah,
I
guess
I
can
also
mention
that
toilets
was
saying
often
today.
You
know
people
just
do
the
very
basic
thing
where
you
register
an
address
with
ian
and
just
say,
like
each
device
has
its
own
just
fixed
address
that
you
have
registered.
C
K
Yeah,
I
was
going
to
say
another
deployment
is
just
put
them
in
dns
and
have
the
source
under
the
same
name,
that
the
receivers
look
up
and
the
applications
just
doing
dns
lookup
that
maps
to
a
group
address.
So
that's
just
adding
to
what
stig
said
right.
C
K
Now,
if
you
want
to
look
into
the
future
and
you
do
multi-hop
routing
and
you
use
overlays,
you
can
now
have
independent
paths,
because
these
addresses
are
relatively
random.
The
hashing
gives
you
the
randomness
that
you
want,
so
you
can
do
a
lot
of
good
load
splitting
stuff
because
of
this
randomness,
that's
already
built
into
your
group,
addresses
using
the
the
not
the
first
suggestion
I
said
with
hashing,
so.
N
So,
as
I'm
thinking
about
this,
I
mean
again,
I
think
the
hashing
is
a
really
good
idea.
I
hadn't
thought
about
that
before,
but
I'm
wondering
is,
as
you
start
to,
you
have
to
detect
collisions
and
when
you
start
detecting
collisions
is
the
resulting
protocol
either
just
as
or
more
complex
than
a
protocol
that
just
dynamically
allocates
everything.
K
Good
question:
well,
what
you
do
is
you
want
to
do
collision
avoidance?
So
if
and
you
can't
do
that
on
all
the
hosts,
if
they
don't
want
to
join
all
the
groups
because
then
they
have
to
know
the
whole
scenario,
you
don't
want
to
have
a
protocol
to
do
it.
The
fact
is,
if
you
find
a
good
hash,
will
produce
pretty
good
randomness
across
32
bits,
so
you
may
not
have
to
worry
about
this
problem
now.
K
I
just
don't
want
to
say
that,
because
making
that
statement
means
it's
going
to
happen
right,
murphy's
law
right.
So
that's
why
I
said
ahead
of
time.
So
what
you're
doing
is
statically
you're
picking
these
names,
so
these
dns
names
is
a.abc.comb.abc.com,
and
then
you
run
it
through
this
python
program.
K
That
actually
does
the
hash,
because
the
source
and
receivers
will
do
that
dynamically
when
they
want
to
join
this
content,
the
applications
will
decide
which
of
these
names
they
want
to
join
or
whatever,
and
so
at
that
time
you
will
know
ahead
of
time
that,
since
these
things,
in
fact,
let's
let's
put
the
names
in
dns,
if
you
want
or
mdns
you
don't
even
have
to
change
that
to
that
deployment
and
then-
and
then
you
know,
because
you've
looked
at
all
the
current
groups
that
are
active
in
your
network
that
are
about
to
be
active,
and
you
know
that
the
432
bits
are
unique.
K
So
so
what
you
do
is
when
you
put
these
when
you
put
these
names
in
your
own
database,
run
the
program
across
all
the
names
and
it'll.
Tell
you
if
there's
no
collisions
and
if
there's
no
collisions
then
you're
good
to
go
on
your
network.
Now,
when
you
want
to
add
a
new
name,
you
run
it
n,
plus
one
across
all
of
them.
There's
still
no
collisions.
If
you
run
n,
plus
two
and
now
there's
a
collision,
then
you
that
name,
you
just
added
is
not
unique
enough.
K
N
We,
let's
say
we
do
that,
and
it
comes
down
again
to
when
you
integrate
another
piece
of
equipment
that
doesn't
do
that
right.
D
K
Yeah
you're
absolutely
right
and
the
chances
are
even
those
new
set
of
applications
that
are
not
going
to
follow.
This
algorithm
will
likely
not
collide,
not
guaranteed
but
likely
not
collide,
because
there's
enough
randomness
in
the
32
bits
right,
you
know,
and
the
thing
is,
is
if
we
use
all
the
the
first
format
you
showed
with
112
bits,
it's
a
no-brainer
in
your
lifetime,
you'll,
never
duplicate,
but
since
those
112
bits
are
going
to
map
into
only
32
bits
of
the
mac
address,
that's
where
you
run
into
the
problem.
K
K
K
Otherwise,
you
change
that
layer,
two
box
to
a
layer,
three
box
and
even
though
it's
one
hop
you'll
get
less
problems
with
collisions
right
because
now
the
groups,
the
groups,
are
differentiated
by
the
entire
ipv6
group
address
and
not
the
lower
32
bits
of
a
mac
address.
So
that'll
help
you
just
upgrade
the
layer
2
switch
to
make
it
a
layer,
3
router,
where
the
sources
and
receivers
are
directly
connected
right,
yeah,.
N
As
far
as
third-party
equipment
and
aesthetically
configuring,
those
and
all
that
I
guess
I
don't
have
a
high
degree
of
confidence
that
there
would
be
an
easy
way
for
our
customers
customers
to
do
that
or
even
know
to
do
that
I
mean.
Certainly
we
can
work
on
ways.
N
Right
yeah
so
and
then
they
go
integrate.
You
know
another
piece
of
equipment
that
doesn't
participate
in
this
address
allocation
scheme.
You
know
whatever
it
is.
You.
K
Know,
even
even
this,
no
no
I'm
saying
if
you,
if
you're,
really
worried
about
that
and
you
want
to
solve
the
one
percent
case,
it's
less
than
one
percent
collision
case
then
make
it
a
layer,
three
router,
and
now
you
have
the
whole
ipv6
group
address,
which
is
128
bits.
You
know,
I
think
it
I
think
the
rule
is,
is
that
the
likelihood
of
duplicating
an
ipv6
address
happens
in
like
120
years.
K
K
C
Yeah,
I
see
brianna's
here
online
here.
Did
you
have
any
comments
on
this
or
I'm
sorry
for
putting
you
on
the
spot?
I
know
you
had
some
thoughts
on
this.
P
Hey
hey
stig
yeah,
so
I
I
missed
the
first
half
of
the
presentation.
So
there's
probably
some
context,
I'm
missing
there,
but
it
certainly
does
seem
like
there
are
existing
ways
to
to
address
this
problem.
But
I'm
I'm
going
to
have
to
reserve
comment,
so
I
can
go
back
and
review
the
materials
and
and
actually
look
at
the
scenarios
to
figure
out
what's
going
on,
but
you
know
I
I
think
some
of
the
some
of
the
approaches
that
you
know
pointed
out.
P
D
C
Okay,
great
thanks
yeah,
I
would
say
my
feeling
to
you,
I
guess
yeah
speaking
as
just
a
participant,
is
it's
probably
good
to
try
to
avoid
like
big
grant
solutions
with
something
like
dhcp
or
medcap,
or
something
with
a
server
and
so
on?
It's
if
you
can
make
it
easy
with
that
without
any
single
point
of
failure,
or
you
know,
any
new
protocols
talking
to
a
specific
device
or
whatever
something
distributed
like
you
know,
suggested
sounds
much
better
to
me.
Yeah.
K
And
and
the
reason
we're
looking
for
simpler
solutions
are
all
the
points
that
torrelis
and
leddy
made
is
that
we
have
many
years
of
experience
with
these
complicated
protocol
solutions
and
they
haven't
taken
off
because
they're
just
too
complicated
and
people
don't
want
to
do
it.
They
don't
want
to
deploy
and
manage
a
madcap
or
dh
service
just
for
this.
K
So
if
we
can
find
a
distributed
way
of
doing
it
or
static,
it
usually
goes
a
long
long
way,
because
it's
not
if
it
works
or
doesn't
work,
they
all
work,
but
they
all
have
a
cost
associated
with
it.
And
so
we
want
the
cost
to
be
trivial
and
and
for
you
to
have
the
agility
to
maybe
change
the
group
allocation
mechanism
in
the
future
without
having
to
talk
to
vendors
and
stuff
like
that.
O
I
I
always
feel
you
know
somewhat
useless
of
trying
to
give
low
level
detail
recommendations
without
having
a
good
understanding
of
the
deployment
workflow
right,
so
I
mean
how's
the
stuff
deployed,
how
whoever
you
know
wants
to
see
something
is
dismantled
right
once
I
see
that
top-down
use
case
details
better,
and
maybe
that's
the
thing
that
you
may
want
to
write
down
just
as
an
informational
document.
If
you
kind
of
want
to
support
information,
then
I
think
it's
much
easier
to
help
with
the
design
decisions.
O
What
to
do
because,
as
I
said
right
most
most
likely,
one
ends
up
and
comes
up
with
cool
ideas,
and
then
there
is
a
stupid
work
around
and
you
know
whoever
buys
the
stuff
or
makes
the
investment
decision
thinks
that's
good
enough,
and
all
the
investment
for
the
better
stuff
is
wasted,
or
we
we
figure
out
the
key
points.
Why
you
know
something
like
this.
I
think
auto
negotiation
is
what
I've
heard
a
little
bit
from
dean,
or
so
is,
is
really
key
things
that
helps
okay.
D
O
But
I
mean
all
I'm
saying
is
right:
I
mean
we
need
to
link
whatever
the
suggestions
are
to
why
they're,
justified
and
necessary
from
you
know
the
the
operation
perspective.
What
what
you
know
the
use
case
trying
to
achieve.
C
Yeah,
I
think,
from
more
like
itf
process
point
of
view.
It
would
be
great
if
you
can
write
that
draft
and
basically
write
down
your
requirements.
C
N
Okay,
so
just
to
be
clear
next
step
is
to
write,
write
a
set
of
requirements
without
any
sort
of
proposed
solution.
Just
the
requirements.
C
O
Yeah,
I
I
think
really
just
let's:
let's
have
an
informal
discussion
about
that.
We
understand
the
use
case,
the
workflow
better,
and
then
I
think
you
know
it's
it's
it's
it's
easier
to
figure
out.
If
the
answer
from
stick
like,
I
think
we
have
a
clear
list
of
requirements
that
we
could.
You
know
help
you
write
if
that's
true
or
not
right,
I'm
at
this
point
in
time.
N
Yeah,
no,
I
think
that's
a
good
point
too,
and
I
made
an
assumption
about
that
that
there
would
be
an
understanding
about
how
these
things
were
connect,
and
I
didn't
realize
I
made
that
assumption
so
so,
thanks
for
helping
me
realize.
O
That
you
do
know
how
automatically
working
application
solutions
are
now
built
on
the
network
right.
You
have
all
type
of
crappy
equipment
with
thousands
of
nerd
knobs,
but
there's
these
addresses
or
whatever
else,
it's
the
application
devices,
the
switches
and
the
routers
and
you
add,
a
magical,
sdn
controller
and
somebody
goes
and
hacks
some
stupid
stuff
and
that's
being
resolved
right.
O
So
that's
the
standard
design
process
right
and
whoever
basically
is
trying
to
write
that
sdn
controller
software
has
to
collect
all
that
information
right
to
figure
out
how
to
make
it
run,
and
then
nobody
understands
what's
going
on
right.
So
I
mean
obviously
that's
that's
the
thing
that
is
lovely
if
we
can
avoid
it
right.
N
O
So
but
then
you
know
we
solve
different
sensors
right.
So
now
the
question
is
okay:
how
does
it
even
work?
Does
every
receiver
sees
every
sensor
and
how
is
that
receiver
figuring
out?
Which
sensor
is
providing
what
information?
So
there
are
multiple
temperature
sensors?
You
probably
you
know,
need
to
know
where
on
the
ship
they
are
so
that
on
the
receiver
you
can
display.
N
O
N
Sure
I
mean
I,
I
guess
I
was
trying
to
walk
the
fine
line
between
providing
too
much
information
and
not
enough.
We
can
talk
about
that.
However
much
you
want
one.
One
thing
that
might
be
useful
to
understand
is
that
nmea,
as
an
organization
helps
helps
companies
resolve
situations
where
there's
where
there's
problems,
where
they're
implementing
the
standard
differently.
But
aside
from
that,
there's
also
a
certification
process
that
every
device
goes
through,
that
tests,
things
like
source
address,
collisions
and
how
they
handle
that.
So.
O
I'm
trying
to
understand
it
from
the
use
case
side.
Right,
as
I
said,
I
mean
we're
sitting
there
and
trying
to
understand
it,
and
so
let's
say
we
have
a
receiver
device
that
I
guess
you
know
displaced
some
multiple
different
instances
of
the
same
type
of
sensors
like
temperatures
on
different
places
of
the
ship.
Is
that
what
could
happen?
That's.
O
N
N
O
So,
let's
take
it
offline,
but
that's
where,
where
I'm
trying
to
you
know
ramp
up
to
the
level
that
I
understand
what
you're
trying
to
achieve
and
then
I
think
only
can
I
give
recommendations
right,
which
is
why
these
requirements,
where
you're
trying
to
derive
your
understanding
from
the
application
to
what
the
network
should
do,
is
something
we
cannot.
I
cannot
comment
on
because.
A
That
was
amazing,
very
good
information,
good
presentation,
there's
a
lot
to
digest
there.
We
can
help
you
create
a
draft
if
you
want
to
go
that
route.
If
you
do
want
to
go
a
new
protocol
route,
we
can
help
you
with
that
as
well.
It
sounds
like
the
recommendation
is
to
not
do
that.
I,
if,
if
we
do
go
to
the
new
portable
route,
this
would
be
the
right
place
to
do
it,
otherwise
creating
an
informational
draft
that
probably
would
be
best.
A
C
Yeah,
maybe
I
want
to
clarify
too,
you
know
when
I
say,
write
a
draft,
I'm
not
saying
it
necessarily,
it
will
be
an
rfc
or
anything
just
so
we
have
something
written
down.
I
mean
you
can
send
an
email
of
course,
but
I
think
it's
good
to
just
write
a
very
short
draft.
Just
explain
you
know
your
requirements,
it
can
be
a
very
simple
thing.
Just
just
so.
We
have
a
common
reference
and
for
discussion,
kind
of.
P
All
right
thanks
mike
hey
everybody,
sorry,
I
can't
be
there
in
person,
but
if
you
go
hang
out
with
the
dns
folks,
they'll
they'll
make
all
sorts
of
snide
comments
about
how
my
schedule
kind
of
interferes
with
my
ietf
schedule,
just
want
to
do
a
quick
update
on
on
moving
rfcs,
33,
76
and
3810
to
full
standard.
P
Yes,
I'm
presenting
this,
but
you
know
there's
also
a
bunch
of
people
in
the
background
helping
me
out,
you
know
a
new
femi
tim
torelis
stig.
So
this
is
really
just
me
trying
to
reflect.
You
know
what
what
we've
been
able
to
do
so
next
slide.
Please.
P
So
I
I
published
a
03
version
of
the
two
biz
documents
a
couple
weeks
ago,
as
best
I
can
tell
it
captures
all
of
the
errata
and
identified
issues
that
has
has
been
raised
both
in
the
design
team
and
on
the
mailing
list
for
for
making
sure
that
the
documents
are
ready
to
go
to
full
standard,
except
for
one
thing,
next
slide,
please.
P
There's.
I
want
to
say,
like
six
or
seven
modifications
that
that
4604
makes
to
those
two
standards
for
the
operation
of
the
group
management
protocols
and-
and
it
is
a
pro
standard
in
and
of
itself,
and
so
the
the
open
question
really
is
is
is
how
do
we
want
to
handle
this?
P
So
I
I
see
two
options
and
the
one
I
think
I
recommended
on
the
mailing
list
was
we
actually
incorporate
the
protocol
changes
from
4604
into
the
two
biz
documents.
P
P
P
The
other
way
of
going
about
this
would
be
to
create
a
4604,
biz
and
advance
that
in
parallel
with
the
other
two,
but
I
don't
see
that
keeping
that
separation
makes
a
whole
lot
of
sense
may
actually
be
confusing
new
readers
and
then
we'd
basically
end
up
having
4604
biz
update,
3376
and
38
biz
next
slide.
P
You
know
alvaro
made
the
comment
on
the
mailing
list
that
we
would
want
to
make
sure
that
we
actually
provided
that
justification
in
the
shepherd,
write-up
and
and
maybe
possibly
in
those
two
documents,
but
most
likely
in
the
shepherd
write
up.
G
Hey
brian
ac,
linda
my
cisco
systems.
I
agree
with
that.
It
doesn't
make
sense
to
keep
them
separate
and
they
should
be
advanced
together
to
do
it
the
full
standard.
Don't
you
have
to
produce
some
other
document
on
the
implementation
and
do
this
survey
and
all
this
extra
work
or
don't
you
have
to
do
that?
No.
P
C
Stig
here
so
yeah,
you
feel
the
the
survey
that
was
done
covers
all.
You
need
to
ask
for
4604.
P
So
I
think
we'd
probably
have
to
go
back
and
do
some
additional
work
for
4604,
and
I
did
not
include
that
in
the
slides
as
a
work
item.
But
I
think
from
the
from
the
perspective
of
of
what
I
have
seen
in
an
operational
and
implementation
perspective,
that
that
survey
should
be
pretty
straightforward
and
and
wouldn't
be
a
big
time
sink.
C
I
think
it
would
be
a
good
idea
to
include
this,
because
I
I've
seen
I've
seen
implementations
that
you
know
implemented
just
igmp
with
ddrmldb2
and
then
somehow
overlooked
some
of
those
as
some
requirements-
and
I
think
the
only
reason
4604
is
a
separate
document-
is
that
it
was
kind
of
done
after
those
base
protocols
right
yeah,.
P
Yeah,
and
I
will
I
will
fully
admit
that
you
know
you'll
you'll-
find
that
I'm
listed
as
the
co-author
of
4604,
along
with
hugh
holbrook
and
brad
kane.
So
you
know
part
of
this
was
we
didn't
want
to
immediately
turn
around
and
open
up,
3376
and
3810
again,
given
that
people
were
trying
to
implement
those
versions,
while
while
we
were
also
working
on
the
ssm
side,
so.
D
D
K
K
P
A
P
I
I
know
that
yes
yeah,
we,
we
could
look
at
something
like
that,
but
I
definitely
think
that
that
would
be
a
next
kind.
P
P
So
I
guess
first
for
mike
and
stigg.
If
you
want
to
do
a
you
know,
a
consensus
call
on
the
mailing
list
or
if
you
want
to
declare
consensus
if
alvaro
is
sitting
there
and
can
back
you
up
that,
you
know
we'll
start
looking
at
the
60,
you
know
doing
a
4604,
incorporation
and
then
I'll
see.
If
I
can
talk
to
folks
who
were
who
worked
on
the
implementation.
A
P
C
C
Biggest
problem
is
just
like
you
know,
like
the
you
know,
yeah
just
dealing
with
yeah
if
you
have
sufficient
implementation
status
whatever
and
of
course
you
analyze
this,
you
know
to
see.
If
there's
some
parts
of
the
document,
you
know
that
haven't
been
implemented
or
isn't
mature
or
whatever
I
don't
know
how
you
feel
about
that
is
is
is
basically
all
of
4604.
You
think
something
that
everyone
implements
so
so.
P
I
I
think,
there's
there's,
there's
really
two
ways
of
looking
at
it.
When
we
wrote
4604,
we
specifically
marked
what
what
pieces
of
the
document
we're
modifying
3376
and
38.10.
D
D
C
P
D
A
Our
or.
J
Yeah,
hey,
I
wrote
a
thunder
rolling,
andy
yeah
so
just
to
to
point
out
for
the
process
point
of
view.
Just
so
we
don't
forget
for
the
future.
J
J
One
of
the
requirements
is
that
there
haven't
been
significant
changes
to
whatever
the
document
was
before
now
in
this
case,
because
we're
incorporating
this
other
thing,
it
may
look
like
there
are
significant
changes
right,
so
we're
going
to
want
to
and
ryan
already
said
it
there.
I
just
want
to
say
it
again
we're
going
to
want
to
justify
why
it
looks
like
there
are
significant
changes
when
in
reality
there
aren't
right
because
we're
moving
486
whatever
into
internal
standards
as
well
as
part
of
the
other
two
documents.
J
So
I
don't
know
if
we
already
have
a
shepard
for
these
documents,
but
if
we
don't,
we
should
probably
find
the
shepherd
now
and
start.
You
know
documenting
all
this
stuff
so
that
by
the
time
that
this
gets
to
the
iesg,
we
don't
face
questions
of.
Why
the
heck
are
you
changing
all
the
stuff
because
we're
not
we're
just
incorporating
the
changes
that
were
already
done
15
years
ago,
so
just
to
keep
in
mind
for
the
process
and
the
minutes
and
all
that
stuff
thanks.
C
C
That's
certainly
important
and
definitely
good
together,
shepard,
I
don't
know
if
it
matters,
but
one
thing
I
can
imagine
is
if,
if
someone
implemented
just
the
base,
igpv3
rfc
and
not
the
ssm
part,
not
4604,
then
the
problem
would
be
that
you're
not
compliant
anymore
or
wouldn't
be
compliant
with
the
full,
the
full
spec.
But
on
the
other
hand,
though,
you
really
want
everyone
to
implement
the
ssm
part.
A
A
A
O
Yeah,
I
haven't
read
it,
but
from
the
description
it
sounded
like
if,
if
that
would
be
something
like
a
yang
model
for
for
the
pro
for
for
programming
these
things,
I
mean
there
has
been
cli
to
do
these
things
on
the
various
vendor
equipment,
not
a
single
command
but
multiple
commands
through
which
you
can
combine
to
achieve
these
things,
and
you
know
lots
of
nice
hacky
customer
deployments
relying
on
that
stuff.
O
F
Lenny,
giuliano
juniper
and
yeah,
we
do
we
got,
we
have
a
gang
draft,
I
guess
you
haven't
reviewed
it.
Nope.
O
I
would,
in
the
first
place,
look
if
they,
if
they
come
up
with
good
current
use
case,
that
that
makes
somebody
excited
about
this
right
to
get
it
standardized.
Well,.
A
The
question
I
have
also
is
standardizing
static,
multicast
routes.
Is
that
a
thing
that.
O
C
Right
yeah.
I
also
think
you
know
this
is
something
that
everyone
implements
pretty
much,
but
they
might
do
it
in
slightly
different
ways,
and
I
don't
know
whether
you
want
to
standardize
one
specific
way
that
maybe
you
know
wouldn't
match
what
various
implementations
do
and
it's
very
local
to
that
device.
So
do
we
need
to
standardize
the
static
route
itself,
but
but
yeah
like
a
young
model,
for
instance?
That's
something
that
we
would
need
to
standardize.
K
If
you
want
to
standardize,
it
is
to
call
static
distribution
trees
because
you
it's
even
though
you
configure
the
route
in
one
router,
you
have
to
be
configured
consistently
all
the
way
downstream
as
well,
and
then
the
question
asked
to
ask
if
the
pat
is:
it
is
the
input
interface
that
you
can
figure
on
the
static
route,
the
current
rpf
based
on
what
unicast
is
saying
and
if
it
changes
should
it
change
or
should
it
not
because
it's
static.
F
Yeah,
I
mean,
technically
speaking,
I
think
static
is
a
protocol,
and
so
this
is,
for
you
know,
protocol
working
group.
The
question
I
would
have
is:
is
there
a
unicast
static
route?
Rfc,
you
know
whatever
we
did
for
unicast.
I
think
we
should
do
for
multicast.
If
we
didn't
need
it
for
unicast,
we
probably
don't
need
it
for
multicast
and
vice
versa,
but
if
there
is
an
rfc
somewhere
on
static
routing,
probably
not
a
very
interesting
rfc
and
probably
hopefully
short,
we
should
do
it.
O
Yeah
I
mean
that
that
there
should
be-
probably,
I
hope,
a
young
model
for,
for
you
know,
static
routing
entries
right.
So
that's
that's
the
rpf
stuff.
O
I
think
that
dino
was
referring
to
then
there's
this
ipi
gmp
static,
join
and
static
group,
and
I
think
those
were
pretty
consistent
june
francisco
and
since
then,
I've
kind
of
lost
track
of
who,
whoever
else
did
additional
stuff,
but
yeah
I
mean
this
stuff
has
been
deployed
and
people
before
even
there
was
the
word
sdn
controller
when
they
had
routing
problems
for
which
our
dynamic
routing
protocols
could
help.
You
know
some
of
these
embedded
type
of
networks
specifically
were
using
all
this
stuff.
But
again,
question
is:
is
there
sufficient?
O
C
K
So
I'm
glad
lenny
led
the
opinion
so
and
then
I'll
I'll,
just
echo
it
more
stronger.
I
think
this
should
definitely
not
be
specified
and
not
standardized,
because
then,
when
you
get
into
redistribution
mechanisms,
what's
what,
if
pims
running
over
this
router,
that
has
static
routes?
What
do
you
do
just
one
override
the
other
there's
a
lot
of
machinery
that
would
have
to
be
specced
out
to
get
this
right
and
if
you
provide
a
recommendation
and
it's
wrong,
it's
going
to
screw
up
networks.
So
let's
just
avoid
this
monster
altogether.
G
Yes,
ac
landing
cisco
systems,
I
wanted
to
just
say
the
rumors
of
a
static
routing
yang
model
are
not
exaggerated,
I'm
an
offer.
I
can't
remember
the
number
though,
and
and
for
the
yang
model
for
ospf.
We
got
together
all
the
me,
our
I'd
like
to
say
all
the
major
vendors
and
we
a
lot
of
things
that
we
had
left
unspecified
in
the
protocol.
G
We
did
put
into
the
yang
model,
which
would
you
know,
and
we
allowed
walt
in
many
cases
we
used
features
and
allowed
multiple
ways
of
doing
things.
So
we
could
get.
You
know
it
was.
It
was
people
from
I
mean
from
juniper,
cisco,
huawei
and
nokia,
I
think
were
the
people
that
were
worked
on
it,
and,
and
so
it
did
end
up
to
be
a
lot,
but
once
you
get
to
the
yang
model
we
did
get
into
this.