►
From YouTube: IETF102-IDR-20180719-1810
Description
IDR meeting session at IETF102
2018/07/19 1810
https://datatracker.ietf.org/meeting/102/proceedings/
A
B
C
D
C
D
C
C
We're
getting
toward
the
end
of
the
week
so
you've
noted
that
note
well
many
times,
but
nonetheless,
please
note
it.
I
can't
actually
believe
how
many
times
I
shouldn't
even
confess
this
on
an
open
mic
button.
How
many
times
I
saw
this
before
I
actually
went
and
read
the
RFC,
and
you
know
what
goes
worth
reading
the
RFC
okay.
C
It
would
be
our
our
belief
it.
The
chairs,
belief,
is
we're
just
about
there
and
then,
after
that
there
is
an
interesting
discussion.
They
have
about
syntax,
so
reruns
talk,
I'm,
hoping
we'll
focus
primarily
on
the
questions
of
semantics
and
I'm,
hoping
the
working
group
will
engage
either
now
at
the
mic
or
later
on
the
mailing
list
to
help
us
settle
any
remaining
open
questions
and.
C
Then
we
can
build
this
intact
stuff
later.
The
syntax
stuff
is
potentially
a
very
attractive
bike.
Shed
I
would
prefer
that
we
not
paint
it
in
this
meeting
today.
But
just
you
know,
in
the
interest
of
full
disclosure,
the
chairs
and
the
author's
had
a
meeting.
Was
it
just
yesterday
and
I?
Don't
remember
who
was
responsible
for
throwing
this
idea
out?
It
might
have
been
me
or
might
not.
C
Maybe
it
was
Alex
I
Oh,
like
you
know,
we
talked
in
the
past
about
doing
this
with
the
community
instead
of
the
path
attribute,
and
maybe
we
can
really
do
this
with
the
community
and
a
bunch
of
configuration
and
make
it
into
a
BCP
and
send
the
whole
darn
thing
over
to
grow.
So
maybe
that
will
maybe
that
that
maybe
that
will
come
back
to
haunt
us,
but
it's
a
bike
shed
I
would
prefer
not
to
paint
right
now,
but
Kher
wants
to
tell
us
what
color
it
will
be.
I.
E
D
E
C
So
another
interesting
thing
that
has
happened
over
the
last
well
a
couple
weeks
during
the
working
group.
Adoption
call,
but
also
in
the
hallways
and
meeting
rooms
here
is
you
know
we
have
had
it
fully
bludgeoned
into
our
heads
that
number
one
multiple
working
groups
are
interested
in
topics
that
you
can
generally
lump
under
the
heading
of
auto-discovery.
Different
people
want
to
autodiscover
different
things,
but
there's
a
whole
lot
of
overlap
between
it.
C
C
C
But
it's
an
imperfect
world
and
what
we
have
is
a
prepared
presentation
on
the
proposal
that
this
group
has
been
discussing
for
a
while,
and
also
we
invited
Randi
to
give
Randy
Bush
to
give
the
a
talk
that
he
gave
previously
at
LSB
R,
which
is
which
is
oriented
towards
LS
PR,
but
I
think
it.
It
sets
up
a
fair
number
of
the
requirements.
C
E
C
A
So
now
we've
come
down
to
another
thing:
the
chairs
want
to
confess
is
that
we're
looking
at
the
BGP
data
model?
It
looks
like
it's.
It's
been
nmd
aid
network
management,
data
store
architecture.
It
replaces
the
old
model
in
case
any
of
you
know,
there
was
a
model
proposed
by
another
set
of
authors,
but
they
haven't
gone
forward
with
it
when
they
found
they
wanted
to
have
it.
They
must
have
it
MDMA
we're
going
to
go
to
working
group
last
call
at
the
end
of
the
meeting.
A
F
A
F
A
F
H
So
good
evening,
so
we
we
met
the
two
sets
of
author
teams.
Mez
met
in
London.
We
had
a
good
meeting.
Then
we
discussed
continue
to
discuss
these
things
through
email.
We
made
some
progress,
but,
as
John
said,
there
is
agreement
to
a
merger
solution,
but
not
quite
a
complete
agreement.
So
what
I'm
going
to
do
today
is
so
we
have
the
draft
and
the
changes
will
happen
still.
H
It
is
because
of
the
considerations
of
attribute
versus
community
and
and
other
issues
we
had
we
had
so
we
have
the
draft
and
also
a
design
discussion
document.
Please
take
a
look
at
both
of
those
and
offer
some
feedback
so
quickly
like
what's
going
to
happen
in
this
talk,
is
that
I
should
mention
to
you
that
Alex
and
I
had
the
opportunity
to
meet
face
to
face
several
times
this
week
to
go
over
the
subtleties
and
the
details,
and
so
it's
been
a
very
good
conversation
between
us
and
lot
of
things
clarified
and
we
have.
H
The
kind
of
two
team
leads
from
the
two
drafts,
so
I
should
mention
that
there
are
some
things
there,
where
we
have
reached
better
understanding
how
to
do
things
between
the
two
of
us
and
because
of
that,
some
of
the
things
in
the
slides
may
not
be
quite
accurate,
or
we
don't
quite
have
agreement
on
those
and
point
those
out.
So
we
have
design
a
design,
B
and
also
the
EO
T
C.
H
So
I
want
to
mention
those
three
things:
the
the
code
that
the
current
a
or
T
C
proposal,
as
it
was
the
originally
OTC
so
between
what
we
are
trying
to
do
here
is
that
each
AAS
in
the
path
inserts
what
we
call
our
LP
information.
So
it
could
be
in
the
form
of
InDesign,
a
the
a
s
number
and
an
RL
p-value,
to
indicate
whether
the
update
is
being
sent
up
to
a
provider
or
to
a
customer
or
a
peer.
H
It
occupies
less
space
less
memory
in
in
this,
nothing
is
set
when
the
update
is
being
propagated
up
and
s
number
of
the
sending
a
s
is
inserted
when
the
update
is
being
sent
to
a
customer
or
a
peer,
and
originally
your
TC
design
is
similar
to
design
B,
except
that
it
has
room
for
only
one,
a
s
number,
so
the
first
very
first
areas
that
set
a
bit
indicating
it's
going
to
a
customer
or
PL
that
that
stays.
So
that's
the
difference
in
so.
H
Accordingly,
as
you
go
from
left
to
right,
design,
a
to
design,
v2,
the
originally
or
TC
the
amount
of
memory,
the
amount
of
processing
potentially
decreases
and
the
complexity
decreases,
but
as
but
with
design
a
and
design
B.
There
is
more
information
that
that's
being
propagated
in
the
our
LP
and
because
of
that,
the
in
terms
of
being
able
to
detect
multiple
leaks,
etcetera.
There
is
better
functionality
and
then
there
is
a
trade-off,
also
like
I
mentioned
before,
with
respect
to
the
memory.
H
But
yes,
but
for
whatever
reasons
s4
doesn't
have
an
alternative
and
Desai,
and
because
it's
coming
from
a
customer
on
a
customer
interface
it
for
life
in
order
not
to
cause
unreachable,
ax
t
is
for
decides
to
accept
and
propagate
it
as
well.
Then
it
goes
to
a
s5
and
at
a
s7
there
are
two
routes
being
received,
one
from
a
peer
and
another
one.
Is
that
leaked.
It
goes
down
into
the
customer
towards
a
customer
and
then
leaks.
So
with
more
information
in
like
with
with
design
a
or
design
B.
H
H
You
you
would
prefer
p2
to
you.
You
would
like
three
to
to
prefer
the
customer
route
over
the
provider
route
in
order
to
not
have
the
persistent
oscillations
in
case
both
are
leaks,
and
for
that
p2
has
to
be
able
to
know
that
the
route
from
p3
is
a
leak
and
out
from
p0
is
a
leak,
and
it
has
to
prioritize
the
customer
out
over
the
provider
route.
There
are
a
couple
of
ways
to
do
it.
One
would
be,
for
example,
to
check
whether
p0
is
is
in
the
path
of
the
provider
route.
H
You
would
have
another
attribute
or
value
that
is
carried
in
the
update,
which
indicates,
for
example,
p0
will
say
that
I
saw
a
leak,
but
I
don't
have
a
choice:
I
don't
have
an
alternative
route,
so
I
selected
it
and
I
sent
it
to
the
two
providers,
but
at
the
same
time
it
has
this
additional
attribute
or
or
information
in.
It
adds
to
the
update
to
indicate
that
I.
H
It
was
a
leak,
but
I
still
am
still
propagating
it,
and
with
that
information,
p2
can
now
set
the
local
craft
to
zero
on
both
of
these
routes,
and
then
it
will
go
with
the
longest
path
and
it
will
make
the
right
right
decision
right,
selection
and,
and
we
can
avoid
the
oscillation
so
like
with
that
I
can
skip
the
next
light
because
I
already
covered
that.
So
so
that's
pretty
much
it
in
in
brief.
H
So
main
thing
we
want
to
focus
today
is
if
you
have
some
feedback
on
design
a
or
B
well
great,
but
that
may
change,
because
we
are
considering
very
likely
moving
to
large
community.
So
we
would
like
you
to
focus
more
on
the
I
mean
on
today.
If
we
can
get
some
comments
from
you
suggestions
about
attributes
versus
large
community,
perhaps
we
can
focus
the
discussion
on
that.
Thank
you
that.
I
Yeah
I
take
apart
some
Cisco
Systems
about
a
year
ago,
I
put
in
a
draft
for
another
solution
to
this,
which
it
sends
a
large
community.
That
says
these
are
my
up
streams
and
it
sends
it
to
the
neighbor
only
so
that
way,
if
that
neighbor
gets
one
from
somewhere
else,
it
can
check
whether
that
upstream
is
there
or
not.
So
did
you
see
that
I
mean
I
was
going
to
present
it,
but
I
didn't
have
enough
time
to
update
it.
H
A
I
A
J
Attribute
is
better,
but
it
will
take
years
before
the
software
will
be
shipped
and
stars
configured
and
so
on
so
on
and
so
on.
Now
we
have
ASB,
which
is
much
more
powerful,
that
anything
that
we
can
get
with
our
shield
community
or
whatever.
It
is
because
it's
also
capable
to
detect
not
only
mistakes
but
also
malicious
activity,
and
that's
why
we
decided
that
we
need
sattell
in
place
as
soon
as
possible
and
just
before
before
we
will
have
a
phase.
J
If
we
will
have
an
attribute
or
community
attribute
at
the
same
time,
HP
will
be
delivered.
It
will
make
no
sense.
So
at
the
same
time
we
know
the
limit
zone
of
the
communities,
so
it
may
be
stripped.
There
will
be
some
issues
for
sure.
So
please
comment,
it's
a
so
it's
it's,
not
a
choice
for
the
draft.
Some
kind
of
strategic
choice
for
the
whole
prop.
So
please
that
device.
K
C
F
L
M
L
M
C
I
would
like
to
close
this
conversation
right
now,
I'd
like
to
encourage
people
to
take
advantage
of
the
in-person
time
we
have
left
to
have
hallway
conversation,
or
you
know,
over
dinner
or
whatever,
and
I
would
like
to
encourage
people
to
review
the
draft,
specifically
with
an
eye
toward
the
semantics
and
not
the
encoding.
There
are
two
different.
You
know
design
a
design
beyond
that
bullet
there.
C
C
H
A
O
E
E
P
H
H
E
H
I
H
E
E
Q
E
Q
I
I
Extended,
why
extended
we're
making
the
extended
community
longer?
And
the
reason
for
this
is
that
we're
going
to
be
able
to
write
the
code
very
quickly
because
it's
just
extending
the
extended
communities,
it's
just
taking
the
extended
community
code
and
just
adding
little
bits
and
pieces
to
cut
and
paste
it
and
change
the
size
by
24
bits,
24
updates.
And
why
is
it
fixed
length
well
again,
because
we're
gonna
roll
out
the
code
quickly?
I
Aha,
we
we
have
a
and
when
you
what
I'll
derive
to
order
derive
identifies
you
want
to
take
existing,
identifies
and
sticking
together
to
make
water
Matic
identifies
and
to
be
able
to
fit
those
into
anything.
You
need
more
space.
So
that's
why
that
is,
and
it's
a
specific
case
we
needed.
That
was
in
a
VPN
target
to
put
an
ESI
and
an
Ethernet
tag.
I
Okay,
now
I
added
added
a
couple
more
things
right,
so
we
have
transit
of
a
non-transitive,
extended
communities.
There's
been
some
issues
with
that.
There's
been
in
several
cases
where
we
have
wanted
to
have
community
communities
and
extended
communities
go
a
few
hops,
perhaps,
but
not
throughout
the
whole
internet
right
so
leaking
a
community
throughout
the
whole
in
in
there
accidentally
is
a
big
deal,
so
I
thought:
let's
take.
Let's
use
two
bits
for
transitivity,
and
so
we
can
have
four
different
transitivity.
So
now
the
first
one
is
administration
transitive.
I
Now,
to
make
that
happen,
we
we
configure,
we
add
a
configuration
to
the
neighbor
ship
that
is
in
the
same
administration,
but
they
fault,
there's
always
a
different
administration.
Okay,
the
other
one
would
be
a
one-time
transitive.
That
means
you
can
send
in
a
community
to
your
neighbor
a
s,
but
it
will
not
go
to
the
next
neighbor
is
so
it's
just
one
time:
I
klo,
which
er
sale.
I
I
The
RT
constraint,
because
if
we
have
a
nuke
extended
community
with
new
rap
targets
in
it
right,
we
need
an
ERT
constraint,
so
there
were
several
possible
ways
to
handling
this,
so
this
is
not
nailed
down,
but
I
preferred
and
some
other
people
here
seem
to
prefer
to
have
a
new
RT
constraint,
address
family
and
so
then
so
it'll
be
nearly
exactly
the
same
as
the
current
RT
constraint
will
just
filter
the
extra
extended
communities
where
the
regular
RT
constraint
filters,
the
regular
extended
communities.
But
now,
since
we
had
a
new
address,
family
I
thought.
I
Oh,
we
have
some
other
problems
with
our
key
constraint
and
something
that's
been
there
for
quite
some
time
it
hasn't
been
solved
is
what
happens
if
you
put
an
RT
into
regular
unicast,
ipv4
or
ipv6
update,
because
RT
constraint
wasn't
specified
for
that
address
family.
It
was
only
specified
for
VPNs.
So
if
you
have
it
in
a
non
VPN
aiders
family,
what
do
you
do
so?
There's
no
clear
answer
for
that.
So
in
this
one
I
just
put
an
Fe
selfie
into
it
to
say
for
the
specified
Fe
Safi.
I
I
I
E
M
E
E
It's
a
working
group
document,
I
suggest
we
leverage
this
over
that,
therefore
their
way,
we
only
have
one
Safi
in
future
to
worry
about
other
things.
The
code
changes
now
that
you
explained
earlier
in
in
the
presentation
that
the
whites
being
too
complicated
to
implement
suddenly
becomes
very
simpler.
R
S
Jeff
as
I
think
you
know
what
half
my
comments
are.
Gonna
be
sure
we
can
take
the
bit
of
the
white
communities
the
container
we
already
did
the
refactoring
initially,
if
we're
looking
at
large,
we
could
do
that.
That'd
be
one
way
to
look
for
it.
Let's
stick
to
your
presentation,
though,
what
I
would
like
to
be
changed
out
of
your
minimally
for
this
to
move
Ford
I'd
love
that
you
did
transitivity
yay.
Let's
do
that
you're
doing
fixed
bytes
I.
S
Don't
like
that,
the
fact
that
you
happen
to
have
some
union
in
your
data
structures
that
makes
you
wonder,
have
the
specific
size.
That's
your
implementation!
I!
Don't
have
that
my
implementation,
let's
not
do
that
if
you
put
just
that
field
at
the
beginning
of
it,
so
that
we
can
variable-sized
them
and
say
that
this
type
must
be
this
size
and
you
can
know.
Do
your
parsing
that
way!
That's
great
I'm,
happy
with
that
done!
I
R
I
R
That
point
you
can
only
use
the
the
extended
community,
I
mean
the
XX
in
the
community
and
not
the
other
one.
So
when
you
you
end
the
migration
of
all
the
EVP
MPs,
you
can
actually
get
rid
of
the
external
community
only
if
only
there
extracts
than
the
community.
Otherwise
there
is
no
gain
right.
Yeah.
R
I
C
M
R
I
L
L
That
also
meant
that
we
wanted
exactly
the
same
transiti,
so
I'm
not
clear
on
what
the
technical
solution
is
like
you
do
here.
So
the
outcome
of
what
you
define
here
is
entirely
reasonable.
I
would
love.
These
features
be
really
nice.
If
we
have
pieces
of
encoding,
that
would
either
stay
within
the
ASN
or
just
one
hub,
but
how
we
solve
this
as
a
working
group
will
be
a
challenge,
because
if
you
put
it
on
the
attributes
itself,
it
may
be
too
broad
and
it
will
cover
everything
contained
within
the
attributes.
L
But
if
you
do
it
per
community
or
per
color
or
kerfing.
That
may
also
not
be
ideal,
but
we
have
to
keep
in
mind
what
users
expect
and
when
we
talk
about,
for
instance,
extract
standard
communities
or
large
communities.
People
associate
transiti
with
that
and
that
we
need
to
think
ahead
of
pushing
this
to
market
on
how
we
think
the
audience
will
perceive
this.
I
I
C
B
A
T
I,
just
focus
on
spend
a
bit
on
this
slide,
which
is
really
the
requirement
that
we
had
in
mind
on
this
working
on
this
draft,
we're
looking
for
a
neighbor
discovery
mechanism
for
BGP
and
which
runs
on
top
of
ipv4
and
ipv6.
So
you
know
it
can
work
on
any
of
this
make
any
I
could
be
for
v6
or
dual
stack,
and
you
know
supported
authentication
mechanism
for
security
focused
on
BGP
requirements,
because
we
have
lldp
and
BFD
for
lioness
and
other
discovery.
T
So
we
just
look
for
the
BFD
part
of
sorry
BGP
part
of
it,
but
we
wanted
to
make
this
extensible
for
signaling
of
BGP
information.
The
queue
requirement
was
for
auto
discovery
of
neighbors
and
bootstrapping
for
BGP
TCP
sessions
between
directly
connected
nodes
based
on
feedback
and
even
requirements.
We
wanted
a
separation
of
discovery
and
liveness
for
BGP
neighbors.
So
there
is
a
discovery,
part
of
it
and
maintenance
of
the
adjacency
and
then
based
on
feedback.
T
H
T
This
is
a
hello
message
which
is
used,
useful,
UDP
port
179,
and
it's
sent
to
link
local
addresses,
so
it
can
be
used
over
both
ipv4
and
v6.
There
are
the
key
TL
ways
that
are
used
here.
One
is
the
peering
address
so
that
the
directly
connected
neighbors
can
learn
the
address
to
which
set
up
the
BGP
TCP
session.
T
Then
there
is
a
link
attributes
which
indicates
the
IP,
v4
and
v6
addresses
and
identifiers
so
that
the
link
can
be
described
accurately
in
you
know
BGP
LS,
but
also
we
can
do
some
other
checking
like
subnet
matching
and
any
other
policies
that
we
may
want
to
keep.
There
is
a
neighbor
TLV
which
actually
includes
the
discovered
neighbors
and
their
status.
This
is
to
ensure
a
two-way.
T
You
know
acceptance
before
bringing
up
the
BGP
peering
over
it,
because
the
session
neighbor
may
be
rejected.
For
some
policy
reason
there
are
certain
optional,
tlvs
T
one
is
the
local
prefix
TLV.
This
is
really
the
prefix
route
that
needs
to
be
programmed
via
this
neighbor
discovery
mechanism
to
ensure
that
there
is
reach
ability
between
the
loopback
addresses
when
doing
the
peering.
You
know
over
them
it's
required
when
the
pairing
is
done
with
interface
addresses.
T
C
K
K
How
can
we
route
in
something
of
this
scale?
Ospf
is
okay
to
500.
Nodes
is
maybe
a
thousand
they're
limited
because
they
repeatedly
flood
everything.
This
is
your
cloths
on
OSPF
or
is
is
thank
you.
Miyazaki
BGP
is
great,
as
updates
are
infrequent.
It
only
signals
change,
okay,
it
scales
because
of
that
it.
So
therefore,
this
is
probably
the
major
reason
it's
become
common
in
large-scale
data
centers,
but
ecmp
can
be
wider
than
heck.
K
K
There's
the
Union
standards,
the
accumulation
of
all
the
features
everybody
wanted
and
intersection
standards
only
those
things
everybody
absolutely
had
to
have
I'm
a
fan
of
the
latter.
When
Russ
Housley
was
talking
to
the
ITU
for
the
ITF,
he
said.
Let
me
understand
it,
you
add
features
until
the
nose
stop
and
they
said
well,
we
don't
like
to
think
of
it
that
way,
but
that's
in
fact
what
happens.
So,
let's
not
do
that.
What
are
the
must-haves?
K
K
We
want
to
maintain
layer,
2,
liveness
and
Su
and
I
have
a
confusion
here
and
what
I
really
mean
is
the
layer.
2
is
up
not
layer.
3
you've
got
being
BFD
and
other
things
for
that.
But
if
layer
2
changes,
it
needs
to
be
signaled
very
quickly
and
then
a
northbound
API.
This
whole
thing
was
done
for
BGP
SPF.
K
There
are
other
paths:
security,
I've,
been
told
data
center,
ops,
don't
think
of
security
at
this
layer.
I,
don't
think
that's
reasonable
and
some
have
finally
spoken
up.
Certainly
we
need
authentication.
Is
my
neighbor,
the
person
that
the
note
that
I
think
it
is?
Is
it
authentic
kated
to
talk
to
me
over
this
interface?
Do
we
need
an
integrity
that
I
question,
but
this
is
one
of
the
things
that
may
drive
the
PD
use
over
1500
bytes?
Why
do
I
care
about
that
wait?
A
minute
non
features.
K
K
K
It
should
be
extensible
so
that
we
can
add
authentication,
maybe
link
costs,
etc,
etc.
John
I've
been
discussing
adding.
What's
the
flavor
of
my
labor,
my
neighbor.
Is
it
a
spine?
Is
it
a
leaf,
etc?
So
I?
Think
of
that
as
colors,
and
we
might
have
two
of
them,
the
other
fonts.
So
I
can
have
magenta
Comic
Sans.
K
K
So
one
of
the
candidates
we
have
in
front
of
us
today
we
have
lldp,
we
have
something
like
is-
is
link
discovery,
Alvaro,
tossed
edge
control
protocol
over
the
fence
at
me
and
I
think
he
regrets
it
because
I've
been
teasing
him
about
it
ever
since
bgp
neighbor
under
discovery.
You've
just
heard
that
song
and
something
that
I've
been
working
on
with
care
link
stayed
over
ether.
K
Ld
pre
is
an
I
Triple
E
protocol,
and
now
the
magic
number
1500
appears
he
could
want
a
big
PD
you
and
you
hit
IPR.
Okay,
it's
a
bit
complex
it.
In
some
circumstances,
it
won't
go
through
a
switch
in
others.
It
will.
What
do
you
really
want
here?
Are
the
nodes
switches,
in
which
case
you
really
don't
want
it
to
go
through
a
switch.
It
does
beaconing,
but
not
keep
allies.
It's
viable,
okay
is
is
discovery,
at
least
it's
a
an
ITF
protocol.
It's
complex
enough.
K
Q
K
Mstc
devices
RFC
1812
I-
think
it
is
host
requirements,
didn't
include,
is,
is
it
was
OSPF
edge,
control
protocol,
it's
a
transport
control
by
eiope,
Triple
E.
It's
really
a
transport,
it's
layer
to
transport,
it
does
flow
control,
reliability
non
reorder,
neither
its
reinventing
PCP
thanks
Alvaro
at
least
I
got
to
read
something
BGP
neighbor
auto-discovery
is
introduced
in
ITF.
Very
new
needs.
The
peering
address
to
get
the
peering
address.
It's
a
s
base
can't
use
other
identifiers,
not
really
discovery
at
all,
it's
configuration
and
then
it
doesn't
maintain
like
this
link.
K
A
C
We
do
have
a
few
minutes
for
conversation,
yeah,
I,
I,
guess
really
what
I
said
at
the
beginning.
We
we
have
I
mean
sure
we
don't
normally
hum
in
this
room,
but
let's
home,
how
many
hum,
if
you
think
the
general
topic,
as
presented
in
the
last
two
presentations
and
others
that
have
come
to
us
of
discovering
in
the
BGP
context,
is
one
that
this
group
should
work
on.
C
C
I
guess
the
other
thing
that
I
would
like
some
some
honey
ratification
on
is.
It
is
the
chairs
impression
that
we
are
at
the
beginning,
rather
than
the
end
of
defining
what
we
think
our
ID
ours
requirements
are
for
discovering.
We
don't
think
that
we
have
a
solid
set
of
requirements
yet
so
I
just
like
to
get
a
home.
If
you
pretty
much
agree
with
that
statement
that
we
do
not
yet
know
what
our
requirements
are.
C
K
C
Yeah,
actually
it
was
a
trick
question
because
in
either
case
that
means
that
you
would
like
to
participate
in
a
interim
to
nail
down
what
those
requirements
are.
Half
of
you
have
got
some
requirements
to
bring
to
the
table,
and
half
of
you
have
got
a
interest
in
evaluating
the
requirements
of
the
first
half
and
now
I
would
like
to
open
the
mic
Jeff.
S
Has
two
points
in
reverse
order,
so
Randy's
motive,
Randy's
motivation
for
presentation
is
partially
due
to
LS
VR.
That
has
a
liveness
requirement.
We
do
not
have
that
piece
that
may
bias
the
solution
if
we're
trying
to
be
general
second
comment,
is
I
think
that
the
majority
of
the
solutions
they've
been
offered
in
this
space
have
significant
overlap.
So
I,
don't
think
we're
really
that
far
in
terms
of
the
actual
requirements.
S
I
do
think
that
we
have
a
few
details
like
the
yellow,
TP
draft
for
examples
out
there,
because
we
thought
we
had
a
specific
limitation
that
we
needed
to
know
for
data
center
type
equipment
that
the
general
bgp
solution
doesn't
I.
Don't
see
that
as
an
obstacle
I
did
you
see
that
is
you
know
one
of
the
things
that
needs
to
be
answered.
I.
E
Ka
patel,
arcus
I,
agree
to
what
Jeff
says.
The
only
thing
I
would
add
is
if
we
are
going
to
take
this
work,
we
probably
want
to
think
of
this
work
with
an
understanding
that
this
has
an
applicability
to
M
I,
miss
DC's,
but
can
be
generally
applied
and
could
be
applied
even
beyond
BGP.
In
certain
cases,
Allah
think
bfv,
like
mechanism
materia,
which
is
more
generically
applied,
so
have
a
surgical
insertion
point
from
a
network
perspective
in
mind,
but
make
it
a
generic
sure.
C
And
I'll
just
cut
in
to
point
out
that,
of
course,
LS
VR
has
their
own
requirements,
and
the
ad
has
I
think
very
sensibly
asked
you
know
the
chairs
of
the
two
groups
to
get
together
and
basically
said
you
know,
can't
you
people
figure
out
how
to
bring
forward
one
instead
of
two
things.
So
we
we
have
had
some
requests,
not
not
a
hard
requirement,
but
a
request
to
try
to
come
up
with
unified
proposal
instead
of
two
different
proposals.
That
does
do
almost
the
same
thing.
Yeah.
U
Definitely
this
at
least
surrenders
analysis
very
useful.
One
thing
that
hit
me
was
thinking
about
it
that
most
of
the
large-scale
data
centers
that
they
are
being
built
or
going
to
be
built
a
predominantly
gonna,
be
around
I,
P
basic,
so
hope.
That's
the
case.
Randy
said
that
I
mean
if
you
make
that
assumption.
I
don't
make
that
assumption
would
be
useful
to
leverage
something
that
we
have
in
ipv6
and
they
were
discovery.
U
P
P
C
And
I
actually
also
want
to
you
know,
take
privilege
to
respond
a
little
bit
and
just
say
you
know,
although
this
this
grid,
you
know,
is
what
it
is
and
it's
a
useful
grid.
We
should
keep
in
mind
that
you
can
have
a
set
of
requirements
that
are
then
met
by
a
set
of
technologies.
They
don't
have
to
be
met
necessarily
by
just
one
technology.
One
protocol
yeah.
P
N
K
V
V
C
E
I'm,
just
gonna
reply
really
put
to
our
list
comment
up.
Jumbo
frames
is
good
to
have,
but
not
necessarily
D
way
of
doing
it
and
then,
as
Randy
said,
there
are
other
issues
with
lldp
where
you
know
it
goes
to
a
switch
you
may
not
want
to.
You
may
not
want
this
information
to
go
beyond
1/2,
so
putting
extra
constraints
seems
like
adding
more
complexity
here.
So.