►
From YouTube: IETF-IDR-20210621-1400
Description
IDR interim meeting
2021/06/21 1400
A
B
B
B
B
A
E
B
I
think
once
sue
is
able
to
reconcile
her
issues
with
being
able
to
hear
us.
We
can
get.
B
B
B
So
the
intent
is
to
run
this
very
similar
to
the
flow
spec
interim.
We
just
had.
We
have
roughly
10
minutes
worth
of
slides,
that's
current
status
and
no
current
thinking
on
things
and
then
the
purpose
for
the
remainder
of
the
interim
is
to
you
know,
have
good
discussion
about
the
contents
and
you
know
try
to
see
if
we
can
achieve
consensus
from
there
prior
to
me,
flipping
slides
is
everybody
able
to
see
the
slides
at
good
resolution.
B
Thank
you,
ignis
alvaro,
okay,
so
our
agenda
is
talk
about
the
scope
of
our
discussion
and
what
state
we're
going
to
probably
want
to
carry
in
the
protocol,
the
transport
and
bgp
protocol
considerations.
For
that
you
know
what
protocols
do
we
end
up
creating
from
the
state
and
the
security
considerations
for
that
protocol?
B
So,
one
of
the
things
to
have
in
mind
as
we're
discussing
you
know
the
state
and
potentially
extension
mechanisms
is
you
know
how
much
is
likely
to
be
common
plumbing
from
one
scenario
to
the
other
and
after
that,
what
level
of
extensibility
might
we
need
both
in
terms
of
additional
state
and
maybe
changes
in
security
scenarios
as
well?
B
So
this
is
largely
the
same
slide
that
was
presented
at
the
last
ietf.
It
was
summary
from
the
auto
configuration
design
team
and
no.
This
is
where
a
lot
of
our
discussion
happened
on
the
mailing
list,
just
as
a
review.
The
no
session
state
that
pgp
needs
to
get
a
php
session
to
come
up.
Is
you
need
your
ip
addresses?
B
B
Okay,
we'll
see
if
this
stays
the
same
and
if
anybody's
having
problems?
These
are
exactly
the
same,
slides
that
are
available
in
pdf
form
on
the
interim
website,
and
I
can
paste
the
url
if
we
get
stuck
a
little
bit
later
there
so
again
continuing
transport
security.
B
We
have
to
agree
on
what
those
things
are
going
to
be
so,
for
example,
if
using
tcp,
md5,
ao
ipsec
or
you
know
quick
or
something
else,
you
need
to
actually
agree
on
what
those
things
are
going
to
be
for
your
ip
transport
to
come
up
and
bring
up
your
session
if
you're
doing
gtsm.
B
You
have
to
agree
on
that.
For
the
session
to
be
able
to
come
up,
bfd
is
an
interesting
edge
case.
There
are
currently
incompatible
implementations
about
how
vfd
impacts
your
bgp
session
in
the
field.
The
dfd
strict
document
that
is
idr
is
intended
to
address
that
point.
So
if
bfd
is
getting
used
and
you
have
inconsistency,
your
session
won't
survive.
So
this
is
a
piece
of
state,
but
maybe
it's
a
piece
of
state
that
goes
away
is
part
of
other
work.
B
The
second
half
of
the
story
is
just
after
you
get
your
session
up
or
what
you
need
to
get
the
session
up.
There's
a
question
of
whether
you
want
the
session
to
come
up
in
the
first
place.
You
know.
F
B
The
session
is
effectively
acceptable
to
the
thing
that's
discovering.
You
know
that
session
via
the
auto
discovery
mechanism,
the
stuff
that
implementations
will
take,
a
look
at
are
things
like
as
numbers
potentially
bgp
identifier,
especially
for
duplicate
session
detection.
If
you
happen
to
have
things
discovered
at
more
than
one
layer,
the
list
of
address
families
that
you're
capable
of
appearing
at-
maybe
you
don't
want
to
you
know
with
a
given
session.
That's
all
the
advertising
itself
is
v4.
B
When
you
know
a
v6
session
might
be
what
you're
looking
to
appear
with
a
very
contentious
bit
of
discussion
is
whether
device
role-
and
some
flavor
you
know-
is
a
discovery
mechanism-
would
be
useful.
No
examples
of
that.
If
you
were
building
a
b2b
fabric,
you
know
using
standard
cloth
topology,
knowing
the
position
of
your
device
or
discovered
device
inside
of
the
fabric
may
help
you
choose
whether
or
not
you
might
appear
with
it.
Now.
B
What
that
actually
looks
like
was
left
for
a
future
discussion,
and
part
of
this
was
how
do
we
do
discussion
extensions,
a
big
portion
of
the
discussion
that
we
had
as
part
of
the
list
traffic
after
we
published?
Was
you
know
that
the
session
protocol
state
is
somewhat
contentious?
You
can
get
it
potentially
via
the
auto
discovery
protocol.
B
You
could
also,
as
many
people
point
out,
get
it
discovered
via
bgb
open,
so
an
advantage
is
that
prevents
potentially
conflicting
state,
but
it
does
mean
the
only
way
for
a
client
to
figure
out.
If
you
have
an
acceptable
peer
is
the
try
to
connect-
and
this
has
a
couple
of
interesting
impacts
in
terms
of
scale,
and
you
know
just
generally
the
ecosystem
that
auto
discovery
works
on.
So
an
example
is
how
fast
do
you
try
to
connect
after
you
do
a
discovery?
B
How
often
you
try
to
reconnect
if
you
decide
that
first
time
I've
learned
a
piece
of
configuration
state,
no
from
the
session
that
I
don't
like.
Maybe
it's
changed.
How
do
I
figure
that
out?
So
if
we
allow
things
like
the
standard,
bhp
timers
to
run,
this
means
that
you
are
constantly
beating
up
on
a
given
device
for
well.
Some
people
pointed
out
data
center
style
scare
scale.
B
B
But
how
often
you're
trying
to
retry
becomes,
you
know
part
of
the
problem
and
there's
also
the
fact
that
if
you
do
allow
bhp
session
get
established
in
any
flavor,
it
means
that
resources
get
allocated.
So
where
you
terminate
your
discovery
for
the
bhp
session,
if
you're
using
bgp
itself
can
be
very
important,
you
probably
want
to
terminate
the
session
before
it
gets
established
just
to
make
sure
that
you're
not
doing
things
like
causing
the
ribs
to
spool
up.
B
Transport
considerations
are
probably
our
biggest
thing.
You
know,
as
we
talked
about
in
the
prior
slides
needed
to
know
the
endpoints,
gtsm,
authentication
and
bfd
state
in
terms
of
the
plumbing
for
bgp
effectively
bgp
once
it
just
has
an
auto
discovery
mechanism
present,
it
can
be
treated
as
a
manual
start
from
the
existing
state
machine.
B
B
A
B
B
B
B
Okay,
so
the
interaction
with
the
state
machine
is
an
interesting
set
of
questions
that
hasn't
gotten
a
lot
of
discussion
outside
of
the
design
team,
so
sure
you
can
just
simply
consider
bgb
having
been
prodded
with
a
manual
start
event.
However,
we
probably
don't
want
four
actual
discovery
scenarios
to
rely
on
exactly
the
state
machine
as
specified,
so
things
like
timers
probably
are
things
that
people
want
to
make
more
aggressive.
You
know
if
you
discover
something
and
you're
trying
to
build
a
fabric
out
of
it.
Now
you
don't
want
to
wait.
B
It
starts
becoming
interesting
problem
and,
as
I
mentioned,
depending
on
your
implementation,
most
implementations
tend
to
wait
till
you
get
to
establish
before
you
have
problems
with
spooling
up
resources
that
might
have
to
get
instantly
freed
up.
If
you
no
disconnect
rapidly
so
once
we've
actually
decided
on
our
protocol
state.
B
What
sort
of
protocols
do
we
actually
create
from
this
stuff?
You
know
the
general
consensus
that
we
seem
to
have
arrived
at
is
we
probably
want,
especially
for
data
center
environments,
some
sort
of
layer,
two
mechanism,
it
doesn't
route,
you
can
tell
instantly
that's
on
the
same
link
and
the
security
and
privacy
considerations
are
potentially
very
constrained
for
any
other
scenario,
outside
data
centers
and
potentially
even
including
data
centers,
probably
a
layer,
3
mechanism
and
it
likely
will
require
some
flavor
of
multicast.
B
This
does
also
change
the
security
and
our
last
slide.
Our
security
considerations
are
going
to
be
an
important
thing.
You
know
a
key
point.
That's
been
made
over
and
over
auto
discovery
does
not
bypass
our
bgp
security
mechanisms,
so
everything
that
we
have
securing
bgp
is
still
present.
This
just
means
that
we
have
to
have
things
advertised
in
the
protocol
that
those
things
actually
work.
F
B
Something
that
the
security
ads
would
like
us
to
have
taken
care
of
and
yeah
one
of
the
other
things
is.
Our
security
ads
will
very
likely
require
some
level
of
information
attached
to
discovery,
protocol
that
provides
minimal,
authentication
and
some
level
of
integrity,
and
certainly
it's
a
common
practice.
You
know,
even
when
you're,
specifying
such
things
that
one
profile
for
that
may
actually
be
null.
B
In
most
cases
it's
likely
be
some
sort
of
shared
secret
and
whether
or
not
there
is
a
mechanism
on
there
to
allow
the
packets
to
be
stamped
with
announced
to
make
sure
that
you
don't
have
replay.
That's
that's
likely
part
of
the
discussion
and
we
have
several
techniques
that
are
well
deployed
for
it.
That
is
not
a
problem.
B
As
we
were
discussing
in
the
list,
the
discovered
open
mechanisms,
the
main
consideration
for
learning
all
the
state
is
discover
it
open,
is
how
aggressive
you're
try
able
to
try
to
get
the
stuff
and
how
long
you
may
care
to
remember
it.
Based
on
your
timers,
a
potential
mechanism
that
lets
us
avoid
beating
up
on
the
receiving
peer
is,
we
include
this
part
of
the
session
state.
B
A
version
number
sequence
numbered
knots,
pick
whatever
the
appropriate
term
is
now
that
we
derive
at
that
lets.
You
know
that
you
know
the
sessions
configuration
has
changed.
It
makes
sense
for
you
to
try
again,
so
this
potentially
provides
us
a
much
lighter
weight
piece
of
state
that
can
be
carried
in
the
protocol
that
still
lets
us
largely
use,
discovered
open
and
those
are
the
chair,
slides
I'm
going
to
cycle
back
to
this.
Is
our
discussion
slide
if
anybody
would
like
us
to
flip
to
specific
one?
B
B
No
care
we're
not
able
to
hear
you,
you
haven't
shared
your
bike,
yet
randy,
please.
D
B
So,
given
the
number
of
problems,
one
thing
we
may
want
to
reconsider
is
whether
she
would
cancel
the
session
and
attempt
to
try
again
later,
maybe
with
a
different.
D
B
B
Okay,
it's
one
of
the
well
advertised
links
off
the
interim
page.
I
guess
for
the
future,
we'll
make
sure
to
make
do
a
copy
and
paste
of
the
actual
join
me
deco.
B
D
B
D
H
When
we
discuss
this
other
configuration,
there
were
like
four
different
approaches:
right,
there's
layer,
two
approach:
there
is
using
igp
to
distribute
information.
So
I'm
not
confused
on
this.
Why
do
we
have
to
worry
about
the
tcp
session?
I'm
just
a
little
maybe
cannot
link
the
two
together.
Do
we
still
consider
like
the
layer,
two
lldp
kind
of
appear
on
discovery.
B
So
to
answer
your
question
linda
each
of
the
protocol
examples
that
we
had
were
a
way
to
distribute
information
to
allow
bgp
to
come
up
so
whether
that's
lodp
the
mechanism
from
xiaohu
the
igp
mechanism
that
ac
had
had
for
discovering
route
reflectors.
This
is
all
about
discovering
that
there's
a
bhp
pure
present.
B
You
know
the
fundamental
question,
and
this
is
the
purpose
of
this
slide
is
regardless
of
which
protocol
you
use.
There's
a
minimal
set
of
information
that
you
have
to
have
to
bring
up
a
peering
session
and
they'll
actually
do
the
work
of
you
know
connecting
to
something
that
has
been
discovered
so
the
stuff
that's
highlighted
for
the
session
transport.
B
You
know
if
you're
told
by
lodp
as
an
example
that
there's
a
php
peer
there,
you
need
to
know
what
addresses
are.
You
need
to
know
what
security
is,
and
you
know
these
are
all
things
that,
in
order
for
b2b
to
even
send
an
open
message,
you
have
to
know
what
those
things
are
and,
if
you're
running
at
a
layer,
3
type
protocol,
there
is
some
potential
that
the
layer,
3
header
information,
might
provide
you
an
endpoint
hint,
but
that's
information.
H
So
is
it
approp
appropriate
to
say
that
those
information
had
to
be
present?
That
means
all
the
four
like
how
many
proposals
we
had.
We
had
like
five
different
drafts
right.
I
remember
make
sure
that
each
of
them
must
be
able
to
derive
those
information
through
whatever
whatever
they
propose.
Is
that
the
goal.
H
B
A
bunch
of
proposals
that
didn't
talk
about
what
was
minimally
required
and
it
turned
out
that
when
we
analyzed
most
of
the
protocols
that
analysis
is
the
appendix
for
the
design
team
document.
Now
a
lot
of
them
came
up
with
a
lot
of
consistent
ideas,
so
hitting
back
to
a
point
that
randy
was
raising.
B
You
know
as
number.
Yes,
you
do
need
that
to
bring
up
the
session,
but
mostly
you
need
it
because
determine
if
the
session's
acceptable.
So
as
an
example.
If
my
discovery
mechanism
tells
me,
I
have
a
possible
peer
at
10.1.1.1
and
I
want
to
decide
if
I
can
appear
with
it.
What
do
I
care
about?
Well,
I
need
to
get
my
bhp
session
up,
so
that's
getting
a
tsp
session
to
port
179
running
and
then
at
that
point
it's
going
to
send
me
an
open
message
and
I'm
going
to
send
an
open
message.
B
Part
of
that
through
normal
bgp,
is
deciding.
Is
this
acceptable,
as
randy
was,
I
think,
leaning
towards
you
know
normal
bhp
configuration
I'm
going
to
say
that
I
have
a
neighbor
10111
at
as100?
B
That's
part
of
my
configuration
and
it
has
to
have
some
matching
configuration
that
decides
whether
it
likes
my
peering
session
or
not,
but
for
auto
discovery
purposes.
Maybe
I
don't
need
to
know
that
it's
you
know
as100,
especially
if
it's
a
fabric,
I
may
just
care
that
it's
a
you
know
appear
of
some
sort.
I
will
learn
from
it
that
it's
as100
and
then
decide
at
that
point.
Whether
I
want
to
you
know,
hang
up
the
phone
or
continue
connecting.
D
You've
used
some
funny
terms
in
there
deciding
whether
you
want
to
make
a
connection
et
cetera.
Could
we
stick
with
the
discovery
and
open
and
if
you
need
more
terms,
fine,
but
what
do
I
need
to
issue
the
open
all
right.
B
B
C
E
Yeah
thanks
jeff,
I
did.
I
hear
you
mention
that
instead
of
these
session
protocol
state
parameters
that
we
have
something
like
like
a
profile
id
or
some-
you
know
some
yeah,
some
identifier
or
some
tag
or
whatever
being
exchanged.
Instead
of
all
these
parameters
to
help,
perhaps
the
receiving
router
do
some
some
kind
of
checking
or
validation
before
it.
You
know
even
allows
the
connect.
B
So
where
I've
been,
you
know,
speaking
of
that,
so
I
can
leave
out
device
role
as
one
of
the
qualifiers
for
that.
But
you
know
just
using
sticking
the
standard
rfc
4271
bgp.
F
B
The
open
messages
we're
going
to
exchange
our
pgp
identifiers,
which
are
effectively
router
ids,
we're
also
going
to
exchange
capabilities.
It
gives
us
the
avi
saffies
and
we're
also
going
to
exchange
our
as
numbers.
So
as
part
of
that
procedure,
you
know
literally,
the
state
machine
basically
has
a
acceptability,
no
procedure.
E
Yeah
correct,
however,
when
so
so,
when
the
session
is
ins,
let's
say,
connect
is
triggered
what
I
I
may
have
as
a
router
I
may
have
you
know
different
profiles
right.
I
may
have
one
profile
to
let's
say:
connect
to
connect
to
this
compute
nodes
or
the
servers,
or
something
like
that.
I
may
have
a
different
word
different
profile
up
towards
the
fabric.
E
Taking
a
data
center
example
even
to
do
the
connect.
Would
I
not
need
to
have
some
like
which
profile
do
I
use
to
do
the
connect
from
my
side.
B
B
You're
not
incorrect,
but
it's
a
matter
of
applicability
rather
than
what
the
auto
discovery
has
to
have.
So
this
is
where
the
discussion
for
device
role
was
part
of
the
reason
why
it
ended
up
in
the
requirements
and,
unfortunately
became
contentious.
B
D
B
E
B
Potentially
so
so,
the
working
from
the
data
center
example
that
we
were
discussing
during
the
design
team
discussions
consider
like
a
simple
bgb
fabric
if
you're
doing
a
standard,
no
fabric
from
the
rfc,
your
leaf
nodes
all
have
individual
as
numbers,
your
aggregation
layer,
you'll
usually
have
a
single
as
number,
and
then
your
spine
layer
will
have
a
different
as
number
than
that,
and
you
know,
part
of
the
problem
is,
if
you
just
say
pure
with
the
thing,
that's
at
the
other
side
link
and
I
don't
care
what
it
is
well,
certainly,
the
profile
needs
to
change.
B
Where
you
are
right
yep,
so
the
question
becomes.
Even
if
you
have
discovery,
what
do
you
use
for
acceptability
in
accession?
So
as
an
example,
if
I'm
a
leaf
node-
and
I
want
to
appear
with
my
aggregation
node-
basically,
I
have
an
acceptable
as
list
I'm
willing
to
appear
with
anybody.
That
is
this
as
number
you
may
still
have
misconnectivity
in
terms
of
where
you
are
the
radix
for
the
switch
itself,
but
you're
not
going
to
end
up
with
loops
or
other
broken
bgp.
B
If
you
have
that
as
number,
you
know
whether
you're
going
to
want
to
appear
at
this
or
not.
If
I
have
the
identifier
and
I
have
the
potential
from
more
than
one
discovery
mechanism,
maybe
I
prefer
one
transport
like
v4
versus
v6
versus
the
other,
so
there
is
an
acceptability,
no
criteria
very
likely.
E
Okay,
so,
okay,
so
if
I
were
to
this
thing
kind
of
try,
to
paraphrase
it,
the
the
profile
on
the
router,
which
is
which
it
is
supposed
to
use
for
for
the
open,
is
determined
by.
Let's
say
what
is
associated
with
the
specific
interface
after
that
all
the
other
validation
or
you
know,
role
or
you
know
whatever
it
may
be,
would
be
part
of
the
let's
say
the
bgp
negotiation.
E
B
It's
a
fair
summary,
although
it's
sort
of
open
discussion,
no
so,
okay,.
B
B
The
acceptability
checks
can
be
built
in
just
simply
is
a
access
list
on
as
numbers,
but
if
you
want
to
try
to
have
a
little
bit
easier
mode
where
you
don't
want
to,
you
know
have
to
be
continuously
reproducing
the
as
numbers
for
the
leaves
potentially
just
simply
saying
this
is
a
leaf.
Roll
is
sufficient,
but
no
that
was
again
a
little
contentious.
F
Hello,
can
you
hear
me
we
can
hear
you
super
speaking
as
a
working
group
working
group,
my
ml
member.
I
do
agree
to
the
last
line.
B
No,
a
lot
of
our
discussion
that
we
had
on
the
mailing
list
about
whether
or
not
discover
it
open
was
good
or
not,
and
things
can
work
perfectly
fine.
I
think,
even
like
your
lsvr
scenarios,
if
you
had
omitted
the
as
number
you'd
bring
up
the
connection
and
then
decide
you'd
have
to
hang
up,
you
know
very
soon
and
then
you're
back
to
retry
mechanisms
afterwards,.
F
And
we
were
trying
to
nip
that
part
upon
a
startup,
because
in
a
lot
of
cases,
convergence
and
how
fast
you
bring
up
the
sessions
and
how
fast
you
converge
are
often
important.
So
we
wanted
to
nip
that
as
fast
as
part
of
the
discovery
message
and
let
the
operators
know
that
you
have
a
misconfiguration
in
place.
Thank
you.
F
G
Okay,
cool
sorry
about
that
earlier
so
now
looks
like
it
is
connected
yeah,
so
I
was
kind
of
trying
to
extend
what
linda
was
asking,
and
so
now
we
have
that
two,
two
l
two
protocols,
part
of
this
discovery
and
two
l3
protocols
now
and
we
have
kind
of
specified
the
requirements
part
of
this
auto
discovery
mechanism.
G
B
That
is
absolutely
the
next
step.
We
had
failed
to
reach
no
consensus,
the
first
round
of
whether
this
is
even
the
right
state.
There
is
a
lot
of
discussion
about
that
once
we
actually
do
agree,
that's
the
right
state.
The
next
question
is:
what
protocols
do
we
do
yeah?
The
draft,
actually,
you
know,
does
the
comparison
of
the
proposals
that
we
have
on
the
board.
B
As
you
mentioned,
we
have
no
two
different
l2
protocols
and
I'm
going
to
call
them
two
and
a
half
to
three
l3
protocols
and
part
of
the
analysis
that
we
did
for
the
design
team
work
was
to
say
if
these
things
are
the
state
that
we
care
about
what
needs
to
change
in
each
of
the
proposals
to
take
care
of
that.
For
the
most
part,
it's
either
add
a
little
bit
of
information
or
potentially
change
where
the
information
is
present.
B
There's
also
discussions
about.
You
know
what
level
of
statefulness
the
protocol
itself
may
want
to
have.
So,
as
an
example,
you
know
the
lldp
mechanism
is
just
simply,
you
know
broadcast,
but
it's
not
very
frequent
based
on
the
definition
of
the
protocol
that
they
have.
You
know
in
ieee,
lsoe
has
the
mechanism
that
is
effectively
some
extent
an
advertisement,
but
you
know
its
intent
is
to
build
a
session
and
the
case
of
the
l3
protocols
we
basically
have
you
know
like
xiaohu's
draft,
is
effectively
ldp
hello
mechanism,
for
you
know
bgp.
B
No,
that
one
is
actually
building
a
full
session
rather
than
just
simply
a
hello
protocol,
I'm
there
so
that
one
actually
involves
a
level
of
statefulness
which
we
may
or
may
not
want.
Robert's
partial
solution
effectively
is
just
basically
bgp
open
inside
multicast.
G
Packet,
so
question
is:
like
hey:
do
we
kind
of
plan
to
work
in
all
the
protocols
like
a
this
part
of
this
auto
discovery
mechanism?
What
is
proposed
that
we,
if
we
need
it
to
be
extended
for
the
l2
and
l3,
for
all
the
protocols
we
kind
of
try
to
now
extend
or
like
a
minimally?
We
kind
of
that
would
be
a
kind
of
viable
recommendations
we
kind
of
take
two
or
or
just
all
the
protocols.
That's
what
I
was
kind
of
trying
to
get
in
like
what
would
be
the
priority.
B
Well,
my
expectation-
this
is
one
that
require
broader
input
from
the
rest
of
the
chairs.
Is
that
we'll
very
likely
want
a
l2
mechanism?
You
know
that
idr
decides
to
adopt
and
al-3
mechanism,
so.
B
What
would
happen
is
if
we
agree
that
this
is
a
state.
We've
now
got
information.
We
can
send
back
each
of
the
authors
of
the
various
proposals
to
say
here's
what
we
think
the
mechanism
should
have
you
know,
please.
You
know,
update
your
proposal
to
cover
that
and
then
the
working
group
can
decide.
You
know
as
part
of
adoption
phases
and
discussion
what
we
want
to
do
and
then
maybe
pick
an
updated
version
of
one
of
the
existing
proposals,
or
perhaps
we
draft
a
new
one.
C
So,
thank
you.
This
is
the
this
is
the
important
part
kasich
is
that
we
agree
on
what
we
absolutely
need,
perhaps
to
quote
other
people
donald
and
randy.
C
It's
the
minimum
amount
of
state
we
need
for
the
data
center
and
then,
if
we
go
beyond
the
data
center,
what's
the
minimum
state,
we
need
for
a
different
use
case.
Maybe
it's
use
case
on
an
exchange
point.
F
G
No,
I
absolutely
agree
because
what
you
mentioned,
that's
once
we
kind
of
badly
agree
and
that's
what
I
was
kind
of
kind
of
getting
into
that
part
like
it
then,
based
on
that,
we
kind
of
extend
that
auto
discovery
mechanism
for
the
ixp
exchange
points
right
like
a
so.
This
is
the
kind
of
point
like
a
which
one
we
kind
of
agree
on
and
how
do
we
kind
of
extend
from
there
beyond
data
centers?
Yeah
absolutely
agree.
C
C
B
C
So
that's
our
real
goal.
Folks,
for
this
is
to
get
some
sort
of
consensus,
so
I'll
I'll
make
a
specific
call.
Is
there
anybody
on
this
discussion
point
that
feels
these
the
b
either
bgp
session
transport
state
or
the
session
protocol
state
we
have
listed
is
not
what's
needed.
Do
we
get?
Shall
we
leave
a
device
con
roll?
Could
we?
What
can
we
lean
down.
B
B
We've
also
discussed
on
the
list,
and
I've
reviewed
it
here
that
having
some
sort
of
hint
that
the
session
protocol
state
information
now
can
be
put
into
the
protocol.
So
we
can
avoid
having
to
ask
you
know
open
up
the
bhp
session
over
and
over
again
to
see
if
something's
changed
care,
given
example
in
lsoe
about
why
they
actually
do
the
as
number
present
there
would
there
be
any
objection
to
having
some
sort
of
hint
that
the
session
protocol
state
has
been
updated.
B
So
it
would
be
part
of
the
session
discovery
state.
Let
me
give
an
explicit
example
what
this
would
look
like
you
know,
just
at
least
my
thinking
are.
D
B
We
have
a
let's
call,
it
configuration
version
number
just
to
have
a
proposal,
and
that
starts
off
as
one
and
you
don't
know
anything
about
session
protocol
state.
So
you
connect
to
you
know
the
device
you've
discovered,
and
then
you
see
that
well,
it's
as
number
is
100..
It's
like
well,
100
is
not
who
I
expect
to
connect
to
the
question
becomes.
Do
you
want
to
try
again
at
some
point
you
know,
could
could
the
operator
maybe
change
something
that
maybe
makes
that
an
acceptable
connection?
You
know,
maybe
they
had
a
misconfiguration,
you
know.
B
B
An
alternate
mechanism
is
that
that
configuration
version
gets
bumped,
it's
no
longer
one.
You
would
remember
that
one
was
not
acceptable,
it
becomes
two,
you
know,
then
you
connect
to
it
and
you
see
that
something's
changed
and
then
you
can
maybe
change
your
mind
and
decide
that
it's
now
acceptable
to
connect
to
it
or
maybe
not.
But
you
don't
need
to
necessarily
let
your
bgp
retry
timers
fire
over
and
over.
B
E
I
think
that
is
fair.
However,
it
does
expose.
I
think
you
also
mentioned
it
during
the
initial
part
of
you
know
somebody
just
keeping
on
trying
stuff
just
to
and
and
the
router
let's
say
would
have
to
you
know
just
keep
re-trying
not
at
its
normal
retry
period,
but
faster
and
just
keep
failing
over
and
over
again,
as
somebody
increments,
this
nonce,
because
we
don't
have
the
actual
informed
passed
it
just
yeah.
I
think
you
mentioned
yeah,
that's
the
one
yeah
so
we'll
have
to
capture
that
somehow.
B
Absolutely
and
those
are
considerations
that
the
security
ads
will
definitely
at
the
very
least,
want
us
to
discuss
if
not
solve
in
the
grand
scheme
of
transport
attacks.
B2B
is
not
going
to
ever
be
terribly
fast
at
this
sort
of
thing,
just
that
those
of
us
who've,
written
bgp
implementations
know
that
they
can
be
very
sensitive
to
sessions
coming
up
and
down,
even
if
they
don't
really
do
anything,
got
it
yeah
thanks.
B
So
some
level
of
information
signed
across
the
security
portion
of
the
discovery
protocol
probably
will
need
to
be
there
to
help
you
avoid.
You
know
some
sort
of
misleading
attacks
and
again
the
tax
space
will
differ
depending
whether
you're
in
a
layer,
two
environment,
where
everything
is
directly
attached
versus
layer.
Three,
the
one
place,
that's
an
interesting
hybrid
of
the
two
problems
is
like
a
internet
exchange.
Point:
okay:
here
you
have
the
mic.
B
You've
mentioned
how
you
have
the
as
number
in
there
to
help
you
avoid
forming
inappropriate
sessions,
but
lsoe
also
has
like
part
of
the
other
information
for
the
session
present,
but
not
all
of
it.
What
sort
of
mechanisms
do
you
have
in
your
implementation
to
decide
whether
you're
going
to
retry
something?
If
you
know
you
think
it's
acceptable
and
the
session
just
doesn't
come
up
for
some
reason.
F
So
one
example,
particularly
in
context
of
as
change,
is,
if
I,
if
I
receive
a
lsoe
update
from
you-
and
I
don't
expect
the
as
number
that
I'm
seeing
from
you-
I
will
not
initiate
a
bgp
session
as
and
when
I
see
an
update
from
you
with
the
right
as
number
I
go
up
to
the
bgp
register.
That
and
say
now
is
the
time
to
open
up
the
session,
and
I
mark
that
change
with
an
appropriate
time
stamp
to
let
the
operators
know
hey.
F
B
Okay
and
timer
wise,
how
aggressive
is
the
implementation
in
trying
to
connect.
D
I
forget
that
number,
but
the
point
is
that
it's
tunable.
So
if
you
expect
open
failures
and
you
want
to
receive
those
updates
quickly,
then
you
know
run
your
lse
lsoe
updates
the
higher
frequency.
D
F
D
D
D
D
You
know
it
has
it's
not
just
the
session
number.
It
has
the
transport
blob
number.
B
Okay-
and
I
will
actually
own
towards
being
the
you
in
the
question
for
device
role,
you
know
that's
an
idea
that
I've
seen
discussed
and
you
know
generally
supportive
of
partially,
because
for
some
of
the
easy
mode
scenarios
it
does
potentially
have
the
chance
to
help.
D
B
B
F
B
For
extensions,
the
sort
of
toward
your
other
point,
no
worrying
about
carrying
large
number
of
things,
it's
more
a
matter
of
figuring
out
completeness
of
the
solution,
and
since
this
state
might
be
carried
in
various
mechanisms
that
you
may
not
have
a
lot
of
space,
we
do
have
to
understand
what
the
critical
piece
of
information
is
as
you're
talking
about,
and
also
potential
fragmentation
of
that
stage.
Necessary
l3dl
does
actually
nice
job
of
that
fragmentation.
D
As
to
the
device
roll
attributes,
I
did
not
have
the
hubris
to
think
I
could
come
up
with
a
clearly
delineated.
This
is
what
we
should
standardize
and
everything
beyond
there.
Well
we'll
leave
that
for
future,
but
you
know
you've
got
more
time
in
the
cockpit
on
this.
So
I
bow
to
your.
C
C
C
D
F
Yes,
thanks,
I
was
going
I
I
was
going
to
say
that
the
over
and
beyond
data
centers
jeff.
It
absolutely
makes
sense
when
you
start
to
talk
about
roles
in
context
of
say,
for
example,
is
the
router
in
the
forwarding
part
I.e
the
route
reflector
versus
a
core
or
an
edge
router
right
or
a
cpe,
and
this
rules
would
start
to
make
a
lot
more
value.
B
Right,
we
may
end
up
moving
from
device
role
to
more
general
informational
tlvs,
and
that's
that's
where
the
conversation
I
think
randy
and
robert
both
motivated
when
you
can't
explicitly
know
what
the
roles
are,
and
some
of
these
roles
may
be
inappropriate
for
some
environments,
sure
they're,
just
numbers
that
are
occupying
a
namespace
but
end
of
the
day.
What
you
want
is
some
ability
to
have
numbers
that
you
can
talk
about
in
a
useful
way
in
your
implementation.
C
Sue
thanks
that
jeff
and
randy
and
caravan
the
question
that
I'm
sort
of
as
a
moderator
saying:
are
we
okay
with
this
as
a
future
extension?
Should
it
be
now
and
left
sort
of
tlvs
doesn't
matter
so
that
we
can
sort
of
close
these
off
and
do
we
foresee
in
device
roles
things
that
l3
vpn
or
best
might
be
wanting
to
use
to
create
different
things?
E
Moment
we
expand
its
applicability,
any
number
of
things
may
or
could
potentially
come
up
so
yeah,
I
think,
having
some
degree
of
extensibility
would
be
good,
but
I
guess
doing
it
with
bgp
as
part
of
the
open
or
capability
is
probably
a
better
better
way
to
do
that
for
an
expanded
role,
kind
of
a
thing
or
deployment
here
in
the
data
center.
You
know
we're
talking
probably
more
like
link
local
or
layer,
two
so
yeah
for
for
other
profiles.
Doing
it
in
bgp
would
be
my
suggestion.
B
Okay,
building
at
your
point,
ketan
one
of
the
discussion
points
we
did
have
as
part
of
this
is
you
know,
when
would
some
of
this
optional
information
be
more
appropriate
for
the
discovery
protocol
versus
the
php
session?
You
know
as
a
capability,
you
give
it
as
example,
and
we
mostly
have
gone
down
the
path
of
you
know.
Maybe
the
you
know
version
hint
as
a
way
of
determining
whether
you
should
reconnect
to
get
information
is
a
perfectly
fine
way
to
do
that.
B
B
Probably
one
of
the
biggest
things
that
would
make
us
lean
that
direction.
That's
come
out
of
the
discussion
for
the
design
team
is
about
message
size
in
many
cases
we're
trying
to
stick
this
discovery,
information
potentially
piggybacking
into
other
protocol
pdus
that
may
not
have
a
lot
of
space.
The
example
is
lodp,
so
having
an
extension
mechanism,
that's
mostly
discovered
at
bgb
open,
allows
us
to
not
worry
about
that
problem.
Quite
so
much.
B
B
B
The
question
robert
specifically,
was
a
good
portion
of
the
discussion
about
what
belongs
into
the
state.
You
know
the
required
session
transport
state
and
the
stuff
of
the
slide,
this
label
session
protocol
state
and
how
much
should
be
done
is
discover
it
open
was
motivated
by
you
know,
conversations
you
initiated.
B
Are
you
happy
with
things
with
what
we're
suggesting,
which
is
session
protocol
state
moves
into
discover
it
open,
potentially
with
a
version
number
so
that
we
know
whether
to
recheck
or
not.
B
B
F
B
B
No
problem
robert
clearly
we're
not
having
a
good
meeting
go
morning.
B
You
know,
via
bgb,
open
that
we'd
provide
a
hint
inside
of
the
audio
discovery
protocol
that
you
know
the
version
has
changed
and
you
need
the
check
again
and
that
we
do
want
to
have
some
ability
in
the
discovery
protocol
to
have
extensions
for
the
future
and
at
that
point,
we'd
probably
be
taking
the
design
team
draft
back
to
the
working
group
and
repeating,
and
hopefully
concluding
the
adoption
the
process
afterwards.
If
that's
true
is
it
becomes
effectively
a
archived
document
and
the
next
stage
is
to
move
on
to.
C
So
we
anticipate
closing
off
on
the
design
document
having
an
adoption
call
before
itf,
and
then
you
know,
if
you
have
something
you
think
you
really
want
to
start
proposing
based
on
these
concepts
to
go
ahead
and
start
taking
proposals,
we
won't
block
those
once
we
make.
This
second
call
we're
we're
trying
to
go
through
that
fairly
quickly,
seeing
we're
not
seeing
much
debate
jeff
I've
lost
your
screen.
Is
that
me,
or
is
that
just
a
latin?
C
Are
we
having
another
meat
echo
moment
new
screen?
Thank
you.
C
Jeff,
okay,
so
folks
we're
going
to
ask
one
more
call:
operators
if
you're
working
with
operations
tell
us
if
there's
some
problem,
just
as
you
saw
the
flow
spec
will
probably
summarize
this
meaning
and
then
ask
for
comments
and
then
take
it
into
another
adoption.
So
we'll
open
it
one
more
time,
any
calls
any.
B
So
alvaro
had
mentioned
that
he
was
going
to
be
having
homework
happen
around
him
and
may
not
easily
be
able
to
come
to
the
microphone
but
alvaro.
This
is
your
time
to
speak.
If
you
have
any
comments.
I
Hey
jeff,
no,
I
don't
really
have
any
comments.
The
discussion
seems
to
be
going
well
and
the
next
steps
that
you
guys
have
learned
seemed
seem
fine
to
me.
So
no
thank
you.
Thank.
A
C
C
Here
wow,
we
might
just
have
a
a
a
wrap,
jeff
and
care.
I
think
jeff,
then
any
closing
comments
you
have
and
then
we'll
call
it
an
eve
afternoon.
B
C
Super
I'm,
I
will
probably
try
to
get
the
minutes
out.
The
you
should
be
able
to
watch
the
medical
within
a
day
once
I
do
that.
C
G's
connection
wasn't
really
good
to
take
notes,
so
we'll
take
notes.
Once
we
see
the
meat
echoes,
please
let
us
know
these
longer
sessions.
We
may
have
some
additional
ones.
C
Some
of
them
will
be
general
working
group
listening
sessions
and
some
of
them
will
be
very
targeted
on
drafts.
What
we're
finding
is,
with
the
new
virtual
environment,
we've
gotta,
take
these
listening
sessions
off
the
itf
meetings
and
stay
to
just
sort
of
presentations
and
short
bursts.
So
you
may
see
some
more
of
these.
C
These
two
were
general.
If
I
have
a
specific
to
a
draft,
we'll
call
it
something
like
an
interim.
That's
for
a
specific
draft
with
that
we'll.
Thank
you
very
much,
and
I
thank
jeff
for
all
of
his
presentation
and
thank
you
again.
B
Is
asking
on
chat?
Is
the
document
already
working
group
document?
You
are
correctly
observing
that
is
labeled
as
if
it
is,
but
that's
because
I
mispublished
it.
No.
It
is
not
cleared
working
group
adoption,
even
though
it
has
that
name.
If
we
decided
it
was
not
going
to
be
a
working
group
document,
then
I
would
put
out
a
tombstone
that
said
that
we
did
not
actually
reach
consensus.