►
From YouTube: IDR WG Interim Meeting, 2021-01-26
Description
IDR WG Interim Meeting, 2021-01-26
A
Okay,
thank
you
for
the
last
five
minutes
of
life.
So
what
I
have
done
is
choose
chosen
to
take
a
little
bit
of
randy's
text,
which
was
a
little
bit
cleaner,
a
little
bit
of
g
structure
and
rearranged
things
a
little
bit.
A
We're
trying
to
say
that
we're
keeping
this
simple,
I
think
the
word
we
would
use
for
this
is
possibly
we
might
actually
keep
this
as
a
very
simple,
very
fundamental
set
of
machinery
to
discover
sessions.
You
want
to
try
to
put
everything
in
the
sun
under
here
or
at
the
very
least,
have
that
for
the
php
piece
of
stuff,
whether
or
not
we
actually
put
this
into
stuff
like
l3dl
or
other
protocols.
A
As
part
of
the
longer
discussion,
I've
squished
together
two
of
the
different
pieces
of
state
that
we
had
into
one
section.
A
The
fact
that
we
can
do
peering
either
on
interfaces
or
via
loopbacks,
something
that
we
have
long
discussed
just
now,
condensed
in
one
spot,
I've
tried
to
convince
things
down
into
transport
protocol,
endpoint
properties
and
things
needed
for
that.
So,
like
authentication
lives
there
liveness
mechanisms
such
as
bfd
lives.
There
interesting
question
becomes
if
we
start
talking
about
integration
with
other
bits
of
plumbing
for
non-ethernet.
A
I
also
put
gtsm
in
here,
since
that
was
a
thing
that
we
largely
expect
to
be
used,
but
we
had
not
really
discussed
so
that
is
a
new
edition
properties
of
the
bhp
session.
Our
session
parameters,
as
I'm
putting
it
here,
like
as
number
set
identifiers
and
supported
daffy
saffies,
and
I
have
chosen
for
at
least
this
passive
things,
to
talk
about
a
number
of
things
that
we've
had
in
the
various
proposals
either
called
groups.
Some
people
have
called
them
different
things,
but
effectively
a
way
of
advertising
the
device
roles.
A
This
is
an
attempt
to
say
that
a
device
role
is
we're
trying
to
describe
the
minimal
information
that
the
discovery
application
needs
to
provide
for
you
to
say
whether
or
not
you
want
to
try
to
appear
with
this
thing
once
you
actually
know
you
want
to
appear
with
it
whole
point.
Is
that
we're
going
to
defer
all
the
rest
of
the
work
down
to
the
bgb
open
machinery,
so
the
device
roll
thing
I
think
is
going
to
be
interesting
because
that's
going
to
provide
sort
of
like
the
transport
and
peer
selection
hints.
A
You
know
a
protocol
transport
requirements,
so
the
state
we
have
above
can
go
in
lots
of
different
things.
Part
of
our
discussion
is,
you
know.
We
have
several
proposals
that
carry
this
ticket.
A
We
have
to
decide
whether
we
want
one
or
more
for
a
given
profile
for
various
reasons
and
we'll
sort
of
briefly
touch
on
the
different
proposals
and
sort
of
how
they
bucket
that's
the
piece
of
cleanup
work
that
I
did
not
complete
before
this
meeting.
A
But
the
relevant
point
here
is
just
sort
of
using
bfd
as
an
analogy.
Eft
is
a
very
simple
packet
format
and
it
gets
stuck
into
same
protocol
but
in
some
cases
bootstrapped
by
many
different
things,
and
I
think
that's
probably
where
we're
going
to
end
up
with,
for
at
least
several
use
cases
I
haven't
touched
the
operator
configuration
section
because
it's
a
bit
of
a
cleanup.
A
I've
tried
to
condense
down
the
design
principles
a
little
bit,
and
this
is
where
my
cleanup
partially
stopped,
but
the
critical
things
that
overlapped
the
discussion
points
we've
had
before
we
have
effectively
give
originally
put
this
as
network
layer.
A
The
way
I'm
sort
of
describing
it
is,
let's
see
your
microphone
is
the
scoping
requirement
of
where
your
discovery
mechanism
needs
to
go.
So
as
an
example,
we
have
proposals
that
cover
layer,
two
layer,
three
and
layer.
Seven,
I'm
gonna
get
the
layer,
seven
example
merchant
here
and
part
of
how
cheap
it
is.
You
know
what
does
the
discovery
protocol
do
as
part
of
interaction
with
bgp?
A
What
we
want,
I
think,
no
sort
of
condensing
out
of
the
prior
notes
and
a
little
bit
of
our
discussion.
We
want
the
discovery
mechanism
to
be
generally
independent
from
php
session
establishment.
A
So
that
means
that
you
sh
you
shouldn't-
have
to
do
bgp
finite
state
machine
stuff
to
discover
the
same
session
you're
trying
to
appear
over
because
there's
so
many
pieces
of
information,
that's
a
bootstrapping
requirement.
So
the
intent
of
the
first
item
is
try
to
say
bootstrapping
requirements
for
a
session
need
to
be
clear
as
part
of
our
mechanism.
A
The
second
one
is
intended
to
say
that
we
generally
should
not
have
the
discovery
mechanism
impacting
the
bgp
protocol,
aside
from
setup
and
potentially
removal
of
the
sessions
that
we're
discovering
and
the
setup.
I
think
everybody
understands
the
removal
specifically
being
called
out
here,
because
it's
one
of
the
examples
of
draft
shoe
has,
as
part
of
its
machinery
being
very
much
like
ldp
when
you
lose
the
discovery
protocol.
A
The
intent
is
that
the
session
goes
down.
So
this
is
a
one
of
the
discussions
for
the
group
and
there's
also
the
case
where
we
may
use
existing
sessions.
You
know
for
discovery
to
do
things
and
that's
one
of
robert's
proposals
pause
here
to
see.
If
there's
commentary
on
the
the
metas
up
front
before
we
sort
of
hit
some
of
the
analysis
of
the
breakdowns,
no
for
the
candidates.
A
Yeah
and
actually
your
point
robert
this-
this
is
sort
of
a
bridging
topic
between
the
metas
and
what
we
may
want
out
individual
protocols.
Do
you
mind
deferring
that
for
a
second.
A
Any
other
commentary
on
the
stuff
up
front,
because
robert
is
petting
directly
into
where
you
think
we
need
to
talk
about
the
other
stuff.
C
A
So
we
have
two
sets
of
security.
The
first
set
is
specifically
for
you,
know
php
session
establishment,
and
I
actually
meant
to
call
this
out,
but
this
is
part
of
the
work
that
I
hadn't
done
and
my
response
to
you
this
morning.
Sue
is
mostly
to
point
out
that
there's
a
lot
of
stuff.
A
Sorry
for
bootstrapping
the
bgp
sessions.
We
do
need
enough
information
for
the
transport
to
figure
out
what
we're
doing
so.
If
you're
doing
bgp
am
I
doing
md5?
Am
I
doing
mao?
Am
I
doing
ipsec?
So
those
are
things
that
we
need
to
know:
first,
even
try
to
bring
up
a
tcp
session
to
the
appropriate
device.
A
The
thing
I
haven't
mentioned,
because
I
it's
absolutely
related
to
the
requirements,
but
it's
not
a
requirement
of
the
state
for
bgp.
It's
for
securing
the
protocol.
The
auto
discovery
protocol
itself.
A
That
itself
has
security
properties,
so,
like
l3dl,
has
a
well
thought
out
section
on
what
it's
supposed
to
do
for
itself.
It's
a
little
bit
thin
on
what
we
need
to
do
for
bgp
and
pretty
much.
Every
proposal
is
a
little
thin
on
what
we
do
for
the
php
session
itself.
That's
sort
of
understandable
past
that
point.
I
think
the
rest
of
the
proposals
to
date
really
haven't
spent
a
lot
of
detail
there
and
we.
C
That
warren
and
you
asked
for
what
what
are
the
open
pieces?
The
other
thing
is,
as
you
go
toward
a
transport
that's
multicast,
which
I
think
there
are
two
other
pieces.
I
had
noticed
in
what
I
think
you've
covered
in
the
choir
requirements,
but
you
may
tell
me
that.
C
A
So
if
I'm
gracking,
what
you're,
asking
correctly
the
transport
mechanism
has
its
own
security
properties
most.
A
Protocol
has
the
state
that
you
need
to
discover
bgp
sessions
and
decide
if
you
want
to
appear
with
them
most
of
that's
pretty
boring,
bgp
stuff,
here's,
my
peering
endpoints,
here's,
my
as
numbers,
here's
my
security
properties
for
things
like
do.
I
need
to
turn
on
bfd.
Do
I
need
gtsm?
Do
I
know
what
sort
of
encryption
do?
A
I
need
on
my
tcp
session
to
get
the
session
to
even
try
to
come
up
the
piece
that
I
think
hits
the
next
bit
is:
there's
the
bridging
piece
of
how
do
I
tell
my
discovery
protocol,
something
about
the
session
that
I
went
to
peer
with.
That
is
interesting,
so
I
can
help
choose
whether
or
not
to
do
it.
The
easy
example
that
we
have
out
of
b2b
clo
fabrics
is
you
know
if
I'm
a
aggregation
layer,
you
know,
depending
on
how
you
count
the
things
you
know
level
one
level
two.
A
I
may
only
want
to
peer
with
things
that
are,
you
know,
a
different
level
than
me
as
an
example.
That
is
a
piece
of
information
that
can
go
into
the
discovery
protocol
to
provide
the
hint
of
well.
C
Basically,
we
have
an
idea
what
the
data
is
and
because
of
an
idea
that
it's
an
asn
or
it's
a
ip
address,
that
we
have
some
concept
of
what
the
syntax
syntax
of
that
should
be,
and
the
contextual,
which
was
the
thing
that
you
just
mentioned
where
you
look
at,
is
this
guy
got
the
role
and
actually,
after
thinking
like
your
concepts
of
role
at
multiple
levels,
is
this
guy
got
a
role
in
the
clause
fabric?
C
C
A
Yeah
you
did,
and
what
I'm
sort
of
expecting
is
the
next
evolution
once
the
document
sort
of
hit
a
fully
complete
version,
one.
The
information
that
I'm
calling
state
will
eventually
be.
You
know,
sort
of
like
the
general
information
model
of
what
we're
passing
around,
and
you
know
the
implementations
of
that
are
going
to
obviously
be
in
the
different
protocols,
and
you
know
very
likely.
A
C
And
you've
done
a
nice
job
of
laying
that
here's,
the
crossover
in
the
requirements
that
I
still
had
trouble
with
and
again
before
I
say
all
of
this-
I
just
want
to
salute
the
fact
that
you
and
warren
have
done
a
tremendous
step
forward
in
this
document.
I
know
there
are
more
steps,
but
every
I'm
cheering
the
first
step
forward.
So
please
thank
you
for
that.
The
other
thing
that
has
a
mixed
security
issue.
C
If
you're
transferring
this
and
I'd
like
link
level
information,
we're
correctly
indicated
that
perhaps
we
should
be
only
passing
layer,
3
information
and
should
use
a
multicast
and
by
the
way,
robert.
I
I
like
the
idea
of
of
ip
multicast.
C
But
how
do
you
you
know?
How
do
you
if
you're
gonna
pass
information
about
link
level?
Is
there
a
security
issue
again
same
thing?
Is
that
a
requirement
is
that
something
we
look
at
later
on
down
the
pike
with
the
transport?
I
don't
know
the
what's
level
information
and
how
secure
you
need
it
versus
the
transport
and
I'm
really
trying
to
focus
specifically
on
the
information
first
and
leave
the
transport
to
later.
A
A
That's
sort
of
another
bridging
piece
for
security,
which
is
we
want
to
avoid
unnecessary
disclosure
outside
of
the
scope
of
things
that
we're
giving,
because
part
of
the
reason
why
we
don't
just
this
is
sort
of
discussing
to
you
know
robert's
proposal,
for
we
basically
stick
the
open
message
directly
in
multicast
is
sometimes
people
don't
want
to
tell
every
single
thing
that
your
routing
session
is
going
to
be
able
to
do
like
if
you're?
A
If
I'm
not
going
to,
let
you
pull
up
the
bgp
transport
session
for
t
speed
come
up
before
I
even
send
you
an
open
there's.
No,
there
are
people
that
just
simply
will
close
the
session
without
actually
telling
you
anything
about
it,
because
they
don't
want
to
give
you
information
about
what
the
box
is
doing.
This
is
sort
of
like
the
discussions
that
we
came
up
with
the
bgp
version
number
stuff
that
we've.
A
Last
couple
months
as
an
example,
so
the
nice
thing
about
a
transport
role
is
that's
effectively
a
bit
of
semi-opaque
information.
You
know
if
you're,
using
a
well
well-defined
number
like
this
number
means
that
this
is
a
close
fabric,
no
aggregation,
node,
you're,
obviously
providing
information
where
this
becomes
applicable
to
the
next
piece
of
the
conversation
is
well.
A
Where
is
your
security
boundaries?
What's
your
where's,
your
places
of
trust
as
warren
likes
to
point
out
and
when
we're
looking
at
our
transports,
what
we
have
now
basically,
is
l2
and
l3,
and
the
the
thing
to
look
at
from
those
for
at
least
the
carry
you
know
the
transport
purposes
occurring.
You
know
this
state
is
really
what
are
we
using
it
for
scoping,
rather
than.
D
When
we
have
an
open
mic,
did
you
want
to
say
something?
No,
I
think
I
just
going
to.
I
guess
it's
going
to
add
the
fact
that
there
are
likely
to
be.
F
Some
sets
of
roles
or
states
which
are
well
known
and
understood,
and
if
you
know
you
can
stuff
those
in,
but
if
you're
the
sort
of
person
who
cares
about
disclosure
or
if
you
just
have
devices
which
perform
odd
roles
like
you
know,
this
is
an
encapsulation
device
which
carries
stuff
off
of
the
network
that
you
should
learn
about.
F
Those
can
be
additional
sets
of
role
tags
so
chances
are
we
before
you
know
a
consideration.
Is
we
end
up
with
two
parts
of
a
namespace
or
code
space?
Where
you
know
one
through
one
thousand
are
well
known:
one
thousand
through
two
thousand:
are
user
defined,
slash
private
use,
type
things,
but
okay,
cool.
A
Nope
we're
in
agreement-
and
you
know
I
guess
relevant
to
the
point
that
we're
making,
if
you
don't
want
to
use
the
well-known
point,
for
you
know,
like
clo
fabrics,
you
know
for
some
sort
of
security
reasons
you
can
go
for
a
level
of
security
through
obscurity
by
choosing
your.
E
A
Point-
and
you
know
the
recommendation
I
would
typically
make
when
we
get
to
the
pdu
format.
Is
you
know
the
number
of
things
we
want
to
reserve
to
ietf
for
well-defined
roles
is
probably
relatively
small
and
there
should
be
a
large
code.
Space
for
first
come
first
serve
know
for
people
that
just
ask
for
them.
They
get
defined
by
atf
registered
idf,
but
the
majority
of
them
should
be
available
just
for
user
purposes,
but
so
we're
taking
this
as
the
next
point
about
scoping
back
to
our
transports.
A
We
have
two
scoping
context
that
I
think
we
care
about
here.
You
know
people
keep
on
saying
well,
multicast,
well
we're
talking
about
multicast
in
a
couple
of
different
contexts.
Now
we
have
link
l2
multicast
and
we
have
you
know
ip
multicast
and
to
some
extent,
that
already
gives
at
least
one
level
of
consideration.
So
one
of
the
message
threads
robert
was
asking
you
know:
could
we
restrict
this?
No
simply
to
point
to
point
links
as
an
example
and
the
problem
is
you
know
that
depends
on
what
you
mean.
A
You
know
by
point
to
point
and
how
modern
you
intend
that
to
mean.
So,
if
you're
talking
about
you
have
something
that
is
literally
something
that
does
old
style
t1,
that
is
literally
a
thing
that
connects
between
two
boxes
and
doesn't
really
have
any
life
outside
of
that.
Well,
that's
very
well
defined.
You
know
that
if
you
put
a
packet
on
that
wire,
it's
going
to
go
exactly
one
place.
A
You
have
the
old
style,
non-broadcast
multi-access,
you
know
like
frame
relay
or
if
you
take
no
evpn
as
an
example,
if
you're
a
link,
that's
talking
evpn,
really
it's
despite
the
fact
that
it
looks
like
a
broadcast
domain,
it's
really
an
mvma
in
terms
of
how
it
goes
across
the
actual
network.
You
just
can't
see
that
and
then
you
have
no
old
school
ip
multicast,
which
is
well.
I've
sent
this
thing
out
with
a
magic
mac
address
and
it
gets
distributed
to
everything
that
happens
to
be
if
it's,
ideally
all
routers.
A
A
If
you
care
about
talking
to
a
thing
that
happens
to
be
attached
to
the
wire,
you
then
care
about
by
talking
to
one
entity
or
multiple
and
how
that
actually
impacts
things.
If
you're
trying
to
build
a
fabric,
it's
probably
a
configuration
error
of
some
sort
for
you
to
actually
discover
more
than
two
additional
parties
on
the
wire.
A
If
you're
trying
to
build
something,
that's
you
know
connecting
edge
nodes
as
an
example.
That's
perfectly
fine.
This
protocol
needs
to
be
able
to
service
both
of
them,
but
that
means
that
you
have
to
sort
of
work
through
the
transport
implications
you
know.
Am
I
talking
to
exactly
one
thing,
many
things:
what
are
the
error
conditions
if
I
have
a
mismatch
and
do
I
have
enough
hint
in
my
transport
protocol,
like
that
device
role,
to
help
make
a
buy
selection
or
do
error
correction
for
it.
F
And
this
is
warren,
just
a
quick
thing
to
add
to
that.
Obviously,
this
is
a
place
where
we
need
working
group
feedback
as
well.
You
know,
as
with
everywhere
else
in
the
document,
but
this
central
this
is
sort
of
one
of
the
more
central
questions
and
that
it
drives
the
level
of
complexity
right
if
our
solution
were
or
if
our
problem
space
were
purely
point-to-point
links
where
we
know
that
there's
definitely
only
one
other
thing
on
the
wire.
F
The
solution
space
is
much
simpler
than
well.
This
could
possibly
be
lots
of
devices
that
can
only
get
certain
types
of
traffic
like
sort
of
the
evpn
type
space.
There's
also
a
related
thing
on
how
much
additional
complexity
are
we
willing
to
deal
with
in
order
to
solve
what
could
be
considered
sort
of
side
cases
or
pathological
cases?
F
If
it's,
you
know,
I
will
use
evpn
as
another
example.
If
it
only
carries
certain
types
of
traffic
or
doesn't
really
replicate
a
broadcast
network
very
well,
are
we
willing
to
deal
with
additional
complexity
in
the
bgp,
auto
conf
stuff,
to
support
what
could
be
a
very
small
number
of
users,
but
how
much
additional
complexity
do
we
want
to
solve
for
for
corner
cases
and
that's
a
design
team
question?
I
think,
hopefully
I
didn't
take
your
flow
too
much
away
while
going
down
my
soapbox
right.
A
F
A
A
That's
right,
but
I
think
you
actually
know
indirectly
hit
into
it
like
one
of
the
things
I
thought
I'd
add
to
the
prior
section,
but
either
skipped
over
it's
not
in
the
version
I
posted
is
extensibility.
A
It
has
a
lot
of
appeal
to
it
because,
obviously,
if
you
have
code
that
has
to
be
able
to
open
up
a
bhp
session,
you
already
have
the
parsers
no
code
for
the
stuff
lying,
but
we
end
up
with
an
interesting
mismatch
that,
depending
on
what
ends
up
in
that
open
message
capability
wise
as
an
example,
how
much
does
the
discovery
protocol
need
to
sort
of
stay
in
step
with
you
know?
Bgp
features,
php
open
messages.
Don't
evolve
super
often,
but
when
they
do,
you
know
it
tends
to
actually
be
a
big.
A
A
Since
robert's
not
responding,
I
guess
I'll
move
back
to
so
we're
looking
at.
You
know
the
scoping
of
where
this
stuff
goes
and
deciding
whether
or
not
we
have
enough
information
to
know
if
this
is
a
valid
scenario,
for
what
we're
trying
to
do
am
I
talking
to
one
thing:
am
I
talking
to
many
things?
Is
that
okay
past
that
point
most
of
the
stuff
in
the
various
protocol
mechanisms
fall
down
to
a
couple
of
interesting
headaches,
so
at
the
l2,
the
question
sort
of
becomes.
A
This
is
one
of
the
things
that
the
carp
working
group
ran
into
when
I
was
trying
to
specify
all
these
fancy
routing
security
things,
you
can't
get
something
that
looks
like
you
know:
ipsec
ike,
to
come
up
until
iep's
really
been
bootstrapped,
but
some
of
the
protocols
they
wanted
to
secure.
Now
we
needed
to
be
up
before
it
could
even
happen
in
the
case
of
you
know,
bgp
discovery
there's
less
in
the
way
of
requirements.
A
A
I
don't
think
that
we
actually
need
this
for
php
session
discovery.
I
think
we're
generally
expecting
that
ip
is
far
enough
up,
that
we're
gonna
be
able
to
do
that
sort
of
thing.
But
that
said,
this
is
an
example
where,
like
l3dl,
can
carry
the
state.
You
know
from
the
information
model,
that's
earlier
in
the
document
perfectly
fine
as
part
of
its
mechanisms
and
make
use
of
things.
A
So
if
l3dl
knows
their
bootstrap
lsvr,
you
know
it
could
also
be
a
carrier
for
the
same
information
to
bootstrap
other
php
sessions
and
where
this
sort
of
you
know
eventually
leads
us
as
well.
Is
there
may
be
more
than
one
solution
that
we're
wanting
to
provide
a
protocol
for
again
using
bfd
as
an
analogy,
you
can
carry
the
same
state
in
more
than
one
way
where
things
become
tricky
at
that
point,
is
you
have
to
have
some
sort
of
tie
breaking
mechanism?
A
You
know
robert
also
asked
him.
You
know
the
same
mail,
you
know,
could
we
just
simply
there's
a
little
bit
of
this
type,
multicast
scope?
Well,
if
you're
happy
with
the
considerations
of
what
you
talk
to,
how
many
things
might
be
there
and
have
a
way
to
pick
stuff,
you
know
in
terms
of
these
are
acceptable
sessions.
A
The
question
then
becomes
well
what
happens
if
I
also
have
a
similar
mechanism
that
just
says
I'm
going
to
look
at
all
of
my.
A
You
know
subnets
that
allow
for
exactly
two
hosts
and
now
that
to
be
a
bootstrapping
criteria
as
well,
and
you
eventually
have
to
do
some
level
of
tie
breaking
criteria
now.
Can
I
tell
if
the
thing
I'm
discovering
in
more
than
one
way
is
the
same
bgb
speaker
and
if
so,
if
I
have
more
than
one
transport,
what
do
I
want
to
do
about.
A
F
C
C
Real
strong
question:
if
you
could
use
ip
multicasting
robert
suggested,
you
know
that
that
restricts
things
to
a
certain
place,
because
people
have
said
you
know
if
you
get
to
multicasting
for
bgp
open
where
what,
if
was
the
wrong
place
and
there's
always
a
a
use
case
where
it
doesn't
work
and
there's
always
a
use
case
where
it
does,
which
fits
into
two
different
transports.
C
Do
we
use
this
to
pass
the
information
in
one
case
and
what
I
really
don't
have
in
my
head
is
so
here
are
the
things
that,
if
you
used
ipmulticast,
these
would
not
work.
F
So
one
a
quick
thought:
this
was
warren,
no
hats,
blah
blah
blah
et
cetera,
et
cetera.
I
should
mention
my
sort
of
disclosures
first,
I
really
really
like
the
ip
multicast
idea.
You
know,
I
think
robert
and
I
started
off
with
a
bunch
of
that
with
things
like
idr
socialite
and
then
robert's
document
after
that,
so
I'm
biased
towards
that
idea.
F
My
concern
is
one
of
the
primary
use
cases
I
see
for
a
lot
of
this
is
within
a
data
center
and
specifically
within
the
data
center,
with
a
clove
fabric
and
in
many
of
these
sort
of
initial
bring
ups
of
a
tow
fabric.
G
And
if
I
could
jump
in
there
there's
a
scale.
Our
experience
have
shown
to
that
very
point.
That
warren
just
said
ip
multicast
in
a
lot
of
data
centers
is
non-existent,
it's
completely
stable.
They
don't
even
use
it
for
anything,
and
and
for
that
reason
I
think,
while
it's
a
very
neat
technology,
we
should
probably
consider
since
we're
focused
on
data
centers
with
small
or
big.
We
should
probably
consider
building
something
on
top
of
the
technology
that
probably
is
prevalent
in
data
centers
rather
than
here.
H
Hi,
this
is
john.
How
do
you
even
use
ipv6
without
at
least
link
local
multicast.
G
I'm
not
I'm
not
talking
about
link
local
multicast
on
ipv6,
I'm
talking
about
ip
multicast
in
general.
The
link,
local
multicast,
is
simply
enabled
using
a
point
on
the
point-to-point
links,
but
there
is
no
multicast.
No.
B
B
Another
comment:
since
I
met
the
mic:
I
want
to
say
that
we
are
using
effectively
bgp
as
igp
and
why
we
should
go
beyond
what
igp
does
for
discovery
here.
A
Yeah
and
that's
that's
sort
of
the
point
I
want
to
hit
is
like
robert
you're
saying
that
what
you
mean
is
effectively
link
local
multicast.
What's
in
your
document
is
basically
ip
multicast?
Yes,.
E
A
We
know
yeah
terminology,
I'm
sorry,
I
apologize
for
it,
so
it's
actually
important
because
you
know
we
know
that
under
the
covers
that
ip
multicast
is
just
sticking,
you
know
stuff
into
funny.
L2
no
mac
addresses
that
expected
multicast
range,
and
you
know
those
of
us
who've
had
the
misfortune
to
deal
with.
You
know
the
way
switches
actually
handle
multicast.
A
We
know
that
in
many
cases
that
some
well-defined
cases,
like
all
routers
as
an
example,
is
something
that
probably
will
be
served
fairly
well
by
the
majority
of
switching
elements,
known
switch
hardware,
anything
else,
that's
more
general
purpose,
multicast.
Now,
good
luck
with
that
that
may
or
may
not
work
depending
on
the
hardware
and
in
the
really
gross
cases,
even
things
like
all
routers
or
things
like
igp
discovery
may
only
work,
because
it's
a
well-defined
bit
of
port
space,
not
because
it's
to
a
specific
address.
A
So
the
the
issue
that
we
do
know
is
that
ip
multicast
in
any
flavor,
even
to
something
as
generic
as
all
routers
may
not
be
as
general
as
we'd
like
it
to
be
part
of
the
discussion
we
should
have
is
like
I
said
we
can
view
this
as
a
scoping
consideration.
You
know
if
you're
using
a
l2,
you
know
it's
exactly
going
to.
B
Yes,
so
so,
basically,
since
we
are
talking
about
l2,
for
now,
let's
say
we
can
use
broadcast
as
well,
which
every
switch
handles
well.
A
With
exactly
the
same
headache
that
you
know
warren's
sort
of
getting
at
yeah
the
this
sort
of
shake
the
fabric
noise
from
bum
traffic,
it
becomes
a
little
bit
challenging.
Just
the
time
check.
I
do
have
a
hard
stop
at
top
of
our,
where
I
did
want
to
leave
at
least
leave
where
we're
at
today.
From
my
perspective,
this
decomposition
into
the
sort
of
blast
radius,
slash
no
scoping
constraints
of
what
we
do
talk
to
is
you
know
the
next
part
of
decomposition
that
we're
gonna?
A
I
was
gonna,
do
for
the
document
using
the
proposals
as
candidates,
for
that
is
that
is
that
still
seeming
like
a
good
way
to
carry
this
work
forward,
because
I
think
where
this
is
gonna
lead
us
is
here,
are
the
considerations
that
we
have,
and
you
know
what
the
scoping
sort
of
gains
and
loses
for
us
in
each
of
those
situations,
and
I
think
that
eventually
drives
the
conversation
of
you
know,
one
or
more.
C
This
works
for
me,
does:
is
there
anyone
else
that
has
issues
with
it
if
warner
or
jeff
won't
call
it?
I
will
folks
anything.
I
A
A
The
bgp
discovered
by
bgp
that
was
robert's
last
contribution
that
I
added
to
the
document
is
an
example
of
doing
that
ac
and
I
have
something
where
you
can
discover:
route,
reflectors
and
ospf
as
an
example
so
being
able
to
carry
this
state
and
other
things
for
bootstrapping
further
away.
I
think
you
know
the
work
will
be
more
generally
applicable.
So
that's
that's
a
goal
of
mine,
even
though
it's
not
necessarily
deliverable
for
the.
A
H
C
A
E
Are
you
going
to
discuss
the
regarding
the
l3
approach
in
next
meeting?
I
know
that
we
cannot
today,
you
have
the
presented
that
overall
and
you
are
going
over
the
l2,
but
we
you
in
the
l3
when
you
come.
There
are
different
approaches
and
we
are
going
to
discuss
next
week.
E
That
that's
good!
What
one
quick
comments!
My
knowledge
do!
Do
I
have
in
that
group
in
the
autocorn
group,
or
is
it
possible
to
add
me.
C
A
C
Add
themselves,
and
I
will
enable
you
as
a
poster
because
of
ipr
rules-
I
need
to
let
you
sell
that
and
I'll
just
pause
with
that.
If
so,
you
and
linda
should
be
adding
self
them,
and
if
I
don't
see
you
at
it,
I
will
add
to
myself:
okay,
okay,
thank
you.
Thank
you.
Thank
you.
Thank
you.
I
will
fix
that.
Okay
and
I
caustic
and
linda
and
jim.
If
you
will
add
yourself,
I
will
try
to
have
this
all
done
within
an
hour.
Okay,
okay,.