►
From YouTube: IDR WG Interim Meeting, 2021-01-19
Description
IDR WG Interim Meeting, 2021-01-19
A
B
So
I
have
a
question
kind
of
comment.
So
what
I'm
hearing
here
is
completely
out
of
discovery
where
there
is
no
ip
reachability.
There
is
no
igp
running.
For
example,
all
there
is
peers
which
are
not
on
the
same
subnet
like
in
ixp
environment.
So
that's
perfectly
valid
for
part
of
the
auto
discovery
effort.
B
C
B
B
A
So
this
is
warren,
maybe
I'm
just
misunderstanding,
but
I
had
thought
that
the
auto
design
team
was
specifically
focused
on
data
center
stuff.
That's
a
perfect
question.
Yeah
and
our
other
document
I
think,
is
more
the
stuff.
That's
not
data
center
right
which
to
me
feels
like
it
might
be
sufficiently
separated
from
this
that
it
can
continue
in
parallel
right
that
it
gets
discussed
in
idr,
not
in
the
design
team,
because
it's
solving
a
different
problem.
But
obviously
that's
just
my
view.
I'd
like
to
know
what
the
chairs
think.
C
D
The
the
first
focus
was
on
data
center,
whether
the
design
team
went
and
went
beyond
that
to
look
at
the
when
an
igp
is
a
second
focus,
because
I'd
like
to
see
an
initial
draft
coming
out
of
a
design
team
or
a
group
of
authors
to
spur
that
I'd
love
to
see
both
coming
at
the
same
time.
But
that
may
not
be
possible
warren
that
was
in
the
slides
from
last
week
and
that
I
considered
you
started
with
the
design
team.
You
have
a
march
toward
the
february.
D
Excuse
me
toward
the
february
delivery
date
for
the
march
rtf
to
try
to
get
the
data
center
information
out.
If
I
have
someone
who
wants
to
run
it
parallel
and
you
have
enough
steam
to
do
the
when
I
xp
that's
fine,
but
the
goal
was
first
data
center.
Then,
when
I
xp,
am
I
much
more
clear
about
that
after
last
week,
warren.
E
A
Things
are
much
more
likely
to
be
ibgp
pairs,
the
ones
that
you're
automatically
bringing
up
you're
more
likely
to
have
direct
layer.
Two
connectivity
that
you
know
any
packet
you
send
is
likely
to
get
there
and
things
are
likely
more
likely
to
be
a
single
hop
away
in
general,
and
these
are
all
just
huge
generalizations
right.
There
exceptions
to
all
of
them
in
general.
A
Also
the
policies
are
likely
to
be
less
complex,
bgp
policies
I
mean,
but
there
may
I
mean
what
we
build
here
might
also
be
applicable
to
the
wan
case,
but
that's
not
the
primary
focus
of
what
we
build
happens
to
also
work.
You
know
across
across
the
internets
that
might
be
good,
but
it's
not
a
strong
set
of
requirements.
A
E
I
feel
that,
with
those
assumptions
within
data
center,
then
the
auto
configuration
will
be
much
simpler
than
in
the
one
case
right.
So
I
I
think
it
should
be.
It
would
be
nicer
if
we
have.
The
assumption
like
here
is
the
data
center
requirement,
a
data
center
scenario,
some
of
the
assumptions
put
in
the
front,
and
then
we
talk
about
requirement
and
here's
the
when
he
has
general
assumptions-
and
he
is,
I
thought
that
would
be
kind
of
more
clear,
so
we
can
be
more
focused.
F
C
We're
this
sort
of
overlaps,
a
bunch
of
things
and
the
reason
why
I'm
not
trying
to
not
talk
about
the
land
cases
in
other
cases
right
now.
What
I
believe
we're
going
to
end
up
with
is
here's
the
you
know,
requirement
requirements
for
the
elements
bgp
needs
to
know
to
bring
up
its
peering
sessions
and
that's
going
to
effectively
result
in
a
information
model
data
model
that
lets
us
actually
say:
here's
how
to
bring
bgp
up
and
some
of
those
things
will
be
generally
applicable.
C
C
What
I
would
really
like
to
do
is
make
sure
that
when
we
have
our
information
model
put
together
for
here's,
the
things
that
are
required,
we've
done
at
least
enough
of
the
analysis
for
the
other
scenarios
to
say,
here's
things
that
are
the
same
here
are
the
differences
between
them
and
the
motivation
for
that
is
part
of
our
protocol.
Design
is
mainly
here's
what
the
pdus
look
like.
You
know
to
get
things
to
talk
to
each
other,
how
they
get
sense.
C
F
G
C
C
So
what
we're
not
actually
even
covering
inside
of
the
discussions
to
date
in
any
of
the
proposals
is
what
is
the
thing
actually
being
secured?
No
l3dl
is
actually
a
counter
example.
It's
actually
modestly
well
specified
that
it's
covering
the
discovery,
information
inside
l3dl
and
that's
great
now
that
that's
helping
you
build
your
trust
relationship
for
that
protocol
layer.
C
So
the
the
auto
discovery
information
is
a
thing
itself
subject
to
security.
The
bjp
session
that
you
may
end
up
forming
from
auto
discovery
also
is
a
thing
subject
to
securing
that's
a
distinct
element.
Where
things
get
a
little
bit
messy
is
in
some
cases
you
may
not
want
exactly
one
mechanism.
So,
to
give
an
easy
example,
let's
say
that
you're
reeling
as
a
appearing
entity
you're
not
willing
to
accept
no
authentication.
C
You
are
willing
to
use
ipsec,
a0
or
md5,
but
for
each
of
these
you'll
need
keychain
hints
so
that
each
of
the
endpoints
can
arrange
for
it.
So
now
you've
actually
taken
it
to
not
only
a
set
of
ip
endpoints
that
have
to
be
addressed,
and
we
haven't
talked
about
the
do
you
do
parallel,
v4
v6,
you
know
separate
v4,
v6,
a
or
v4
or
v6
over
six
over
four.
Now
those
are
all
variations.
C
That
draft
shoe
covers
a
little
bit,
not
completely
but
better
than
the
other
ones,
but
once
you've
actually
decided
you
know
for
a
given
transport
endpoint
set
that
you're
willing
to
do.
How
do
you
arrive
at
a
set
of
security
information
that
you're
willing
to
attempt
to
peer
over
on
that
and
that
that's
not
hard?
It
overlaps
a
little
bit
with
what
the
ip6
is.
A
D
I
I
believe
one
thing
I'd
like
to
clearly
see
is
the
difference
between
requirements
and
the
difference
between
reviewing
proposals
to
be
clearly
set.
I
think
that's
one
thing
that
I
liked
in
the
sort
of
structure
that
she
had,
so
is
that
something
you
feel
comfortable
with
jeff
and
warren
and
the
rest
of
the
team.
C
Well,
so
part
of
the
point
of
noting
that
the
authentication
proposals
are
massively
underspecified
is
the
requirement
that
we
end
up
needing
is,
you
know,
is
a
requirement
that
we're
going
to
say
you
have
to
advertise
exactly
one
association
that
you're
willing
to
do
well,
in
that
case,
you're
precluding,
you
know
some
sort
of
authentication
that
could
be
different
between
the
different
parties.
You
know.
Basically,
if
you
don't
say,
there's
got
to
be
some
method,
if
you
say
there's
some
method
by
which
you
can
advertise
more
than
one
authentication
type.
C
D
A
Proposals
are
not
fully
fleshed
out
because
people
don't
want
to
spend
a
huge
amount
of
time
to
answer
every
possible.
You
know
or
document
write
up
every
possible
part
of
the
solution
if
it's
not
going
to
be
used,
so
I
get
the
feeling.
Some
of
them
have
this
sort
of
and
don't
worry,
we
can
make
other
things.
Other
tlb,
slash,
authentication
work
here,
but
we're
not
documenting
it
in
excruciating
detail,
because
that
might
just
be
wasted
time.
A
C
C
A
Things
mean
there
is
also,
I
guess
this
is
kind
of
going
down
a
rattle,
but
there's
also
the
many
people
are
happy
to
do
authentication.
But,
okay,
if
you
don't
as
well
right-
and
this
is
more
not-
this
is
where
it
sort
of
strays
out
of
the
data
center
into
external
things.
But
a
lot
of
people
view
the
md5
and
similar
as
just
a
really
strong
checksum,
not
a
real
secret,
and
so
does
that
need
to
be
addressed
or
not.
You
know
that
we
can
talk
about
in
the
requirements
and
also.
C
The
nice
thing
is-
and
this
is
something
that
check
with
sue
and
john
about
the
document
states
up
front
in
both
of
the
flavors
that
we're
not
intending
to
drive
this
document
towards
rfc,
let's
just
simply
publish
to
the
itf
here's
what
we
think
the
requirements
are.
This
has
a
specific
impact
that
you
know.
C
H
C
Right
so
the
the
in
using
requirements
language
we
have
to
discuss
this.
This
is
for
securing
bgp.
This
is
a
discovery
protocol.
We
have
to
discuss
this.
You
know
a
a
proposal
must
discuss
what
the
security
mechanism
is
for
securing
a
discovery
protocol
and
since
it
is
also
going
to
be
carrying
information
for
securing
a
bgp
session
and
we're
providing
endpoint
information,
there
must
be
enough
information
for
bgp
to
be
able
to
perform
a
transport
session,
which
therefore
means
that
the
requirements
has
to
say
an
implement.
C
Well,
you
know
that
you're
talking
to
the
thing,
if
you
know
that
you're
talking
to
something
at
the
end
of
the
link
and
you're
willing
to
just
trust
it,
because
it's
the
thing
at
the
end
of
the
link
now
that's
a
security
implication.
You're
welcome
to
use
no
authentication
as
an
example,
or
you
could
decide
that
you
don't
trust
the
people
who
are
managing
your
wires
and
therefore
you
actually
have
this.
So
the
operational
security
section
has
to
be
done
in
each
of
the
proposals
covering
these
points.
A
A
If
I
don't
trust
the
people
plugging
stuff
in
and
I
want
authentication,
I
have
to
do
a
bunch
of
pre-configuration
on
the
device
between
before
it
all
gets
plugged
in
and
turned
up,
and
so
that
has
implications
for
how
much
of
the
auto
conf
stuff
happens
by
itself
and
how
much
you
know
my
orchestration
system
needs
to
do
whatever
the
case.
One
thing
I
did
want
to
mention
is
jeff
and
I
are
listed
as
editors
on
the
document.
A
C
C
C
C
Can
you
move
that
piece
of
information
out
of
transport
and
into
bgp,
maybe
in
part
of
the
open
messages,
that's
a
possibility
as
well,
so
that
that's
where
one
of
the
interesting
scoping
lines
will
be
for
how
do
you
actually
allow
for
the
full
auto
configuration
picture
for
full
ztt
rather
than
just
transport?
It
gets.
D
C
The
initial
draft
is
going
to
again
try
to
heavily
point
out,
for
the
information
model.
Here
is
what
information
is
required
to
get
the
transport
job
done
and
we'll
try
to
throw
in
some
level
of
first
level.
Discussion
of
you
know
for
other
things.
If
you
need
help
with
the
transport
layer,
it
may
belong
here,
but
the
the
line
once
you're
able
to
form
any
sort
of
transport
session.
The
line
blurs
very
quickly
because
you
know
b2b
open
at
that
point-
can
do
the
job
for
you
and
that's.
D
A
So
this
is
warren.
I
think
the
main
thing
is
people
to
read:
slash,
re-read
the
existing
set
of
documents
that
they're
familiar
with
them
and
can
point
out
where
we've
missed
things
or
where
we've
got
things
incorrect
or
interesting.
Notices
like
this
particular
proposal
solves
this
thing,
which
you
know
on
reflection,
turns
out.
It
really
is
actually
a
requirement.
A
D
D
C
C
I
need
to
also
re
read
the
github
procedures,
because
you
know
my
personal
inclination
for
a
lot
of
the
stuff.
Is
I
just
push
out
stuff
in
private
branches
that
has
to
do
items
in
there
and
as
long
as
it's
in
private
branch,
you
know
it's
not
considered
canonical.
I'm
just
not
sure
what
ietf
tends
to
say
about
that.
Since
I
lost
track
of
that
discussion
about
a
year
ago,.
A
Yeah
I
mean,
I
think,
that
a
lot
of
the
stuff
is
sufficiently
still
open
it
up
in
the
air
that
you
can
just
stick
it
in
the
main
branch
you
know
in
github
and
we
just
don't
push
it
as
a
draft
up
to
the
ietf,
and
so
people
can
just
read
the
main
one.
My
concern
is:
if
we
have
27
different
sub-branches,
it's
hard
for
people
to
see
understand
how
they
fit
together.
D
And
and
my
reading
of
the
policy,
as
I
read
it
last
week
in
the
two
rfcs
which
warren
I
hope
that
represents
the
two
rfcs
represents,
the
itf
policy
is
its
working
group
or
working
group,
slash
design
teams.
So
my
reading
is
jeff
if
it's
more
comfortable
for
you
to
do
it
in
the
main
branch.
Do
it
in
the
main
branch,
because
it'll
be
easier.
Private
branches
are
useful.
If
we
have
some
major
disagreement
so
just.
G
G
People,
if
you,
if
you
guys,
are
going
to
be
the
editors
we're
going
to
review
like
we
said
that
was
going
to
be
the
mode
of
operation.
I
don't
see
any
reason
you
know.
If
you
want
to
do
something,
you
could
publish
it.
You
know
you
know,
publish
the
first
draft
or
I
guess
you
don't
want
to
want
people
to
review
it.
Maybe
that's
not
a
good
day,
but
you
know
if
only
two
people,
I
can't
see
creating
branches.
A
And
one
quick,
important
clarification:
those
rfcs
on
github
are
not
the
ietf
policy.
There
are
some
ideas
and
thoughts
on
how
you
all
might
want
to
use
github.
Oh
right,
we
specifically
people
can
correct
me,
but
I
believe
we
specifically
do
not
have
policies
on
using
it
habits.
Just
there
are
some
ideas
on
how
you
know
things
we
found
that
have
worked
well
all
right.
If
you
want
to
deviate
from
them,
that's
okay,
too,.
C
And
one
of
the
things
that
github
also
allows
us
to
do
is
structure
our
things
towards
open
issues,
so
once
we've
actually
broken
things
down
to
specific
issues
that
need
a
conclusion
can
track
the
issues
there.
The
discussion
doesn't
have
to
happen
in
the
system.
I
know
some
people
have
done
that.
My
general
inclination
is
once
we've
gotten
things
down
to
this
must
be
addressed.
We
can
use
the
issue
tracker
if
we
feel
like
it.
I
don't
have
a
strong
opinion
about
doing
that.
I'm
quite
happy
wrangling
that,
through
email.
A
A
C
D
So
I'd
like
to
have
something
that
we
work
against,
because
that
that
helps
and
jeff's
the
reason
he
I
asked
jeff
what
his
timing
was
is
because
it's
that's
fairly
close,
then
that's
a
good
thing
in
the
meantime,
there's
a
lot
of
documents
to
read
and
reread
cossack,
which
I
I
sent
out
in
the
that
were
included
in
the
last
powerpoint
slide
I
sent.
I
will
also
send
this
powerpoint
slide.
Excuse
me
this
slide
that
jeff
mentioned
in
email.
If
you'd
like
to
see
that
as
well.
H
H
C
The
you
know
very
tersely:
once
we've
decided
what
goes
inside
of
the
protocol,
we
have
multiple
flavors
of
multicast
involved.
You
know
whether
it's
you
know
yeah.
We
have
outright
unicast
mechanisms.
You
know
like
we
could
do
this.
No
by
arp
discovery
as
an
example
for
a
form
of
unicast
for
multicast.
We
have.
Obviously
you
know
l2
you
know
like
lodp
does
is
one
of
its
forms.
C
Ls
l3dl
also
does
things
both
to
the
ieee
802
idea
of
multicast
to
the
directly
attached
stuff
or
across
the
switch
fabric.
You
know
there
are
different
macs
for
that
and
then
ip
multicast
leverages
those
mac
addresses
to
flood
across
the
entire
multicast
domain.
That's
you
know
all
things
on
this
link,
but
a
link
is,
you
know,
basically,
an
entire
switching
domain
from
a
l2
standpoint
and
each
one
of
these
things,
I
think,
has
implications
for
different
environments.
C
So
as
an
example,
if
you
believe
that
you're
largely
a
boring
link
that
is
not
really
ethernet,
it's
mostly
meant
to
be
used
as
a
point-to-point,
a
l3
multicast.
You
know
talking
to
that.
They
tell
you,
there's
one
thing
there
as
you
expect,
and
they
tell
you
there's
more
than
one
thing:
they
decide
what
to
do
about
that.
If
you're
trying
to
do
things
for
switch
fabric,
you
may
only
want
to
talk
to
the
thing.
C
That's
on
the
direct
opposite
end
of
your
port,
in
which
case
you
want
to
use
a
different
encapsulation
for
that
and
part
of
the
discussions.
That's
going
to
have
to
happen
is
since
there's
going
to
be
multiple
domains,
potentially
with
multiple
protocols
for
syncing
it.
Potentially
those
protocols
are
serving
other
purposes.
C
C
C
D
Okay,
so
what
I
understand
from
this
week's
work
is
that
jeff
and
warren
are
going
to
get
together
and
put
a
straw.
Man
out.
Everyone
in
the
meantime
is
going
to
go
and
read
all
the
documents
that
were
sent
out
I'll,
send
a
list
again
and
then
we'll
review
and
comment
on
the
bgp,
auto
conf
list
and
we'll
get
together
next
week
to
have
any
in-person
in-person
discussions,
jeff
and
warren
as
editors.
It
would
be
helpful
if
you
suggest
any
points
you
need
clarification
by
monday
next
week.
A
D
Okay,
I
will
try
to
listen
to
the
recording
and
send
out
notes
to
try
to
help
everyone
come
up
to
speed,
but
I
thank
you
all
for
your
time.
I
really
appreciate
you
re-engaging
and
spending
some
time
to
to
get
the
data
center
portion
out
and
robert,
please
throw
in.
I
think
we
lost
robert
I'll,
send
him
a
note.
I
really
want
him
to
continue
to
push
stuff
for
the
exchange
point
have
a
great
day.
I
think
we're
done
jeff
and,
let's
warn
you
or
someone
else,
has
another
point.