►
From YouTube: IETF99-IDR-20170720-0930
Description
IDR meeting session at IETF99
2017/07/20 0930
https://datatracker.ietf.org/meeting/99/proceedings/
C
C
C
D
A
There
will
be
chair
slides
for
the
first
couple
minutes,
if
you
would
add
to
the
Ethernet
Pat,
go
to
your
tools,
page
in
IDR,
find
the
Ethernet
pad
and
help
the
scribes
or
people
taking
notes
with
your
correction
of
your
name,
correction
of
something
that
said
at
the
mic.
Oh
by
the
way,
I
should
start
the
mic
procedure
out.
Hello,
I'm
sue,
Harris,
I'm,
your
friendly
IVR
chair,
and
this
is
John
Scudder.
This
is
gee
our
secretary,
please,
if
you
need
help
we'll
be
glad
to.
B
A
Have
a
new
note:
well
John's
addressing
it,
so
maybe
you
want
to
take
a
look
at
it.
It's
not
that
you've
seen
in
a
hundred
million
times,
but
it's
a
new
note.
Well,
you
can
see
that
it
covers
more
and
more
notice.
It
covers
the
ITF
plenary
session.
Is
G
ITF
working
group
birds
of
a
feather
I,
be
anything
you
say
here,
that's
so
that
we
can
all
share
our
joint
work.
Any
questions
oh
and.
C
B
You
probably
most
of
you,
know
this,
but
many
of
us
need
to
be
reminded
especially
need
to
be
reminded
that
if
I
say
just
gotta
do
tomorrow
at
worsen,
it's
not
very
nice
for
the
note
taker,
but
if
I
say
John
Scudder
juniper
networks,
then
they
have
some
hope
of
maybe
spelling
my
name
a
little
bit
like
what
my
name
is
so
I
for
some
reason,
people
who
speak
slowly
and
clearly
all
other
times
say
their
names
really
fast,
I've
noticed
so
try
not
to
please.
Thank
you.
B
B
B
This
was
always
always
a
terrible
idea
or
you
know
well
whatever
provide
feedback
which,
since
the
the
author's
back
to
the
drawing
board
again
but
anything
but
silence,
please
okay,
so
we
have
at
least-
and
you
know,
unless
I
missed
something-
five
new
working
group
documents
and,
let's
see
of
which
three
segment
routing
ones
there
was
in
several
of
the
working
group.
Adoption
calls
there
were
various
different
suggestions
about
you
know.
Can
we
merge
these
two?
Can
we
merge
these
three?
Can
we
adopt
the
encoding
of
this
one
into
this
other
one,
etc?
B
There
didn't
seem
to
be
consensus.
You
know
strong
working
group
consensus
to
do
any
of
those
things.
We
spoke
to
the
the
various
authors
and
said:
what
do
you
guys
think
and
with
the
sort
of
enthusiasm
you
might
have
guessed,
nobody
was
very
excited
to
go
and
Andrey
spin
their
document
for
this.
So
as
of
now,
we
have
adopted
them
as
three
separate
documents
and
they're,
also
at
three
different
sort
of
levels
of
maturity.
B
B
B
Oh
right,
isn't
it's
not
early
allocation?
Sorry,
it's
a
related
thing,
which
is
implementation
which,
as
almost
everyone
in
the
room
knows
in
IDR,
we
have
the
relatively
unusual
requirement,
tradition.
Call
it
what
you
will
of
saying
we
want
to
have
implementation
of
protocols
before
we
send
them
to
the
iesg,
and
the
question
came
up.
I
think
Joe
brought
it
up
a
few
months
ago
like.
Why
do
we
allow
things
to
go
to
a
working
group
last
call
before
we
have
evidence
of
implementation
and
it's
it's
a
fair
question
so
far.
B
Should
we
change
our
procedures
in
this
group
to
say
we
want
at
least
two
reported
implementations
before
proceeding
on
to
working
group.
Last
call
I
see
Randy
looking
pained.
So
actually,
why
don't
I
wanted
a
pause
here?
Sorry,
I
don't
have
it
on
slide
where
I'm
just
asking
the
question
to
the
room,
shall
we
have
a
yeah
go
to
the
mic.
F
Randy
Bush
I
J,
the
problem
is,
it
will
make
a
queue
that
has
mixed
things
in
it
and
right
now
you
have
two
separate
queues
right.
That's.
B
F
G
For
the
sake
of
verifying
internal
consistency
and
the
actual
capability
to
do
implementations,
I
think
a
last
call
will
be
much
more
informed
for
all
participants
involved.
If
somebody
says
hey
I
made
an
actual
implementation,
it
at
least
compiles.
If
we
forego
that
step,
then
we
cause
ourselves
additional
work.
If
we
have
to
go
back
or
even
worse,
if
something
is
published
and
we
then
discover
mistakes,
we
have
to
wear
the
cone
of
shame.
So
I
think
the
quality
of
documents
will
significantly
improve.
If
we
ask
for
implementations
before
last
call,
instead
of
after.
H
The
purpose
of
last
call
as
you've
mentioned:
it's
not
necessarily
that
no
drop
it
to
the
RFC
editor
for
our
stuff.
You
have
the
waiting
for
implementation
state.
The
tracker
lets
us
actually
track
of
that.
By
having
the
last
call
done,
we
get
the
working
group
to
sort
of
shake
out
any
the
semantic
issues
so
that
the
spec
is
clear
so
that
people
actually
could
do
something
and
actually
get
a
interoperable
set
and
if
you're
lucky
zero
issues
are
found.
J
Thank
you.
Is
you
linden
cisco
systems,
I'd
like
to
completely
agree
with
jeff
that
what
you're
doing,
if
you
delay
it
more
your
baton,
you're
further
back,
ending
the
whole
publication
process
and
you're
making
the
implementers
put
forth
even
greater
gamble
that
what
they're
doing
is
going
to
change
so
you're
raising
the
entrance
barrier
on
implementations?
By
doing
this,
thank.
A
You
I
have
one
other
question.
I
sat
in
the
grow
and
working
group
and
notice
that
we
had
yet
missed
another
RFC
that
was
useful
for
the
ops
people,
that
there
was
a
community
draft
that
had
waited
four
years
for
for
fight
a
asses.
How
does
that
affect
all
of
this
weight?
You
know
because
we're
trying
to
get
to
the
early
allocations
to
make
sure
you
have
those
code
points.
K
A
Okay,
that's
a
that's
a
valid
additional
question.
We
have
a
challenge
and
Mahesh
probably
hit
RP.
No
knows
that
I've
talked
to
him
about
the
challenge.
The
yang
doctor's
new
requirements
is
that
all
things
being
published
at
this
point
go
through
the
revised
data
store.
However,
we
have
the
IDR
mantra
that
we
will
only
release
to
our
see
things
which
are
fielded
the
field
of
the
pre
model.
A
That's
on
the
current
IVR
adoption
and
as
an
ID,
our
draft
is
actually
being
deployed,
but
it's
not
going
to
be
a
revised
data
store
I
have
talked
to
our
friendly
a
ad
and
we
will
actually
probably
publish
the
deployed
one
and
publish
a
revised
data
store
one
at
the
same
time.
At
this
point,
we
may,
for
the
good
of
other
working
groups,
publish
the
revised
data
store
one
without
implementations.
A
L
H
Jeff,
as
this
is
exactly
what
versioning
and
yang
is
for
you
know,
we
have
a
version
of
this
Beach
be
stuff
that
is
shipping
its
matted
RFC
status.
It's
not
to
be
conformed
with
the
stuff
that
we're
wanting
to
go
to
the
on
that
said.
Itf
wants
us
to
move
to
this.
It's
perfectly
fine
to
ship
a
to
dad,
oh
that
matter.
If
it's
the
new
thing
and
based
on
how
this
code
tends
to
work,
it's
not
usually
a
giant
challenge
to
reorganize
your
code.
What
your
customers
want!
H
A
A
K
A
B
That
was
an
excellent
tangent.
Thank
you,
so
yeah
back
onto
the
boring
status
update,
so
we
have
had
a
couple
early
allocations,
so
there's
there's
a
whole
whole
nother
segment
to
talk
about
kind
of
what
we
can
do
better
and
on
this
coming
up
so
I'll,
just
you
know,
say:
we've
got
a
couple,
early
allocation
requests
in
progress
and
we
have
one
that
we
completed
recently
so
code
points
are,
you
know
flowing
along
and
I
think?
Finally,
we
have
had
I
believe
two
new
IPR
disclosures.
B
F
B
It's
a
great
question
and
I'm
gonna
ask
us
to
hold
it
until
the
very
next
talk
which
I
have
some
slides
on
the
subject,
and
then
we
should
talk
about
it.
Thank
you
just
to
and
I
think
we're
almost
wrapped
on
this.
We
have
a
wiki.
This
is
the
slide
that
we've
projected
before
my
perception
is
we
don't
aren't
getting
a
lot
of
use
of
it?
Maybe
it
maybe
it's
a
write.
Only
document
I'm
not
sure
actually
can
I
have
a
well.
B
B
It
would
be
interesting
to
know
you
know
either
at
the
mic
if
you
feel
like
it
or
you
know
an
email
or
in
the
hallway
or
whatever,
what
we're
doing
right,
what
we're
not
doing
right,
you
know
it
is
there
information
you
wish
you
could
get
to
and
you
isn't
available
as
the
licking
out
working
for
you
for
some
reason,
or
do
you
just
feel
like
you've
got
all
the
information
you
need,
so
why
should
you
go
looking
for
more
right?
We
have
an
agenda.
B
N
B
Awesome
can
we
have
that
in
the
in
the
notes
players?
Actually,
if
you
that's
right,
you
don't
have
a
laptop
with
you,
so
you
can't
put
it
in
the
ether
pad
yourself,
but
but
for
those
who
do
have
laptops
and
can
open
the
ether
pad.
One
useful
thing
you
can
do
is
make
sure
that
you
know
if
you
make
a
point
like
that,
make
sure
that
it
appears
in
the
minutes.
It's
makes
it
much
more
likely
that
the
chairs
will
remember
to
do
it
later
alvaro
or.
O
B
B
We've,
you
know
we,
we
have
a
working
group
policy
and
I
think
sort
of
generally.
It
is
thought
in
the
IETF
to
be
good
policy
that
if
you've
got
a
registry
that
has
an
allocation
policy
from
which
code
points
are
supposed
to
come.
You
should
get
your
code
points
from
the
registry
and
you
shouldn't
just
compile
them
into
your
code
or
you
shouldn't
use
some
out-of-band
method.
For
you
know
self.
Allocating
code
points,
that's
what
the
registry
is
for.
It's
to
allocate
you
code
points
it's
so
that
you
don't
have
to
self
allocate
them.
B
But
people
keep
doing
this
and
you
know
they're
good,
experienced
people
and
they
presumably
have
a
reason
other
than
you
know,
I'm
not
listening
to
you
and
so
I'm.
Just
gonna
do
whatever
I'm
doing,
and
you
know
they're
not
doing
it
to
you
know,
make
me
feel
bad
or
to
give
me
extra
work.
So
there
must
be
some
other
reason.
So
I
wanted
to
stand
up
and
talk
about
kind
of.
What
are
what
might
the
reasons
be?
B
B
A
better
option,
and-
and
the
second
one
you
know
answer
they're
kind
of
stuck
in
my
mind-
is
we've
got
this
slow
heavyweight
process
and
co-development.
You
know
moves
at
you
know
time
scale
this
much
and
you
know
ietf
process
move
that
time
scale
this
much
and
they
don't
match,
and
it's
unreasonable
for
you
to
ask
me
to
slow
down
my
code,
development
and
deployment,
because
you
know
you
want
me
to
jump
through
a
bunch
of
bureaucratic
hoops
to
get
a
code
point
okay.
B
So
let's
talk
about
that
I,
try
not
to
put
walls
of
text
on
slides,
but
as
I
was
preparing.
These
I
was
looking
through
RFC
8126,
which
is
the
newly
minted
advice
for
writing.
Ayana
consideration
section
and
it's
it's
a
somewhat
long
document,
but
it
has
some
good
stuff
in
it.
I'm
just
gonna
read
this
because
I
think
it
captures
what
you
know.
The
essence
of
our
problem
is
here
so
while
it
is
sometimes
necessary
to
restrict
what
gets
registered,
for
example,
for
limited
resources
such
as
bits
in
a
byte
and
etc.
B
B
B
B
The
the
next
few
slides
I,
think,
are
and
are
basically
two
things.
One
is
to
make
sure
that
people
know
what
policies
are
available
when
we
create
a
registry,
and
the
second
is
to
make
sure
that
people
know
that
registry
policies
are
not
set
in
stone,
they're
not
handed
down
to
us
for
one
hi.
They
are
policies
that
we,
the
working
group,
have
set
for
ourselves
for
our
registry
registrations
and
we
can
change
them.
B
Ok,
so
there's
there's
a
zoo
of
10
different
policies
that
are
outlined
in
that
RFC
and
you
know
we're
not
required
to
use
those
exact
temp
it's,
but
the
fact
that
somebody
has
sat
down
and
thought
through
them
means
that
I
would
certainly
rather
reuse
their
work
than
invent
a
new
policy
for
myself
if
at
all
possible.
So
there's
there's,
you
know,
notably
permissive
policies
that
I'm
aware
of
first-come,
first-served,
first-come,
first-served
literally
you.
How
many
people
here
have
have
registered
something
in
FCFS
registry?
Okay,
so
you
know
a
decent
number
of
people.
B
You
go
to
a
forum
you
put
in
I.
Think
it's
your
name.
Your
email
address
a
symbolic
name
for
the
the
code.
Point
you
want,
you,
click
go
the
nice
people
at
I,
ana
within
a
business
day
or
to
send
you
a
number
or
you
know,
whatever
kind
of
value
you're
registering
for
it's
really
that
easy.
It
is,
you
know,
maybe
slightly
slower
than
you
know,
putting
a
number.
B
B
One
of
the
objections
to
you
know
so
I
put
out
as
a
straw.
Man
hey,
why
don't
we
just
change
a
whole
bunch
of
stuff,
the
FCFS
one
of
the
objections
to
that
was,
or
at
least
I.
Maybe
this
was
me
projecting
onto
Adrian's
comment.
He
may
not
actually
have
said
this,
but
was
well.
You
know,
there's
there's
no
sanity
checking
at
all
and
do
we
really
need
to
go
all
the
way
towards
you
know:
anarchy,
cats
and
dogs
lying
down
together
and
you
know
there's
no.
Who
knows
what
could
happen?
B
There's
also
an
expert
review
process
which,
as
long
as
you're
not
freaked
out
about
the
the
risk
of
the
expert
becoming
some
kind
of
tin-pot
dictator,
it's
almost
the
same
as
FCFS
except
some.
You
know,
there's
a
an
expert
who's,
basically
the
guardian
of
the
registry,
who
gets
to
say
yeah
that
seems
reasonable
or
you
what
hit
the
breaks.
B
We
need
to
talk
about
your
registration
request,
but
but
the
expert
review
process
as
long
as
the
expert
has
sort
of
the
right
expectations
about
what
their
job
is,
I
think
can
be
almost
as
lightweight
and
then
there's
various
restrictive
policies
and
a
bunch
of
our
code
points
are
under
one
of
these
standards.
Action
specification
required
and
then
two
related
ones,
RFC
required
an
IETF
review.
B
All
of
these
basically
say
something
like
you
have
to
be.
You
have
to
have
an
RFC
number
to
get
your
to
get
your
code
point,
and
this
is
what
people
have
said
you
this
is.
This
doesn't
actually
make
sense,
especially
in
a
group
that
requires
implementation
before
getting
an
RFC
number.
There's
an
obvious
circular
dependency
there.
So
to
break
the
circular
dependency,
we
have
early
allocation,
I
talked
about.
B
B
B
You
ought
to
be
able
to
to
get
your
group
your
your
thing
adopted
as
a
working
group
draft,
so
that's
kind
of
the
bar
that
we
apply
once
you've
done
that
or-
and
we
are
in
parallel
with
your
working
group.
Adoption
request.
We've
done
that
multiple
times
in
the
last
year.
You
can
request
an
early
allocation.
We
pull
the
list
about
it
once
we've,
you
know
let
that
pull
spire
and
assuming
there's
no
objections.
Men
assume
movie,
don't
think
you're
crazy,
which
I
don't
think.
B
We've
ever
actually
had
that
happen,
but
we
reserve
the
right
to
think
you're
crazy.
Then
we
ask
for
the
the
code
point
and
you
know
the
ad
generally
says:
yeah
okay
and
then
we
send
it
off
Diana
and
then
we're
done
so
this.
You
know,
okay,
as
long
as
everybody's
on
their
game.
This
can
take.
You
know
three
weeks
ish.
B
What
can
we
do
about
getting
people
their
code
points
when
they
need
them?
I
can
see
about
three
different
options.
We
can,
you
know,
follow.
The
beatings
will
continue
until
morale
improves
strategy.
Where
we
say
well,
people
keep
putting
code
points
in
their
drafts.
We
must
not
be
yelling
at
them
enough.
B
We
should
yell
louder
that
doesn't
sound
fun
for
anyone
not
fun
for
me
anyway,
I
don't
know,
or
we
can
just
embrace
anarchy
and
say
you
know,
do
whatever
you
need
to
do
and
we'll
we'll
clean
up
the
bodies
later
if
we
have
to
and
we're
gonna
totally
stop
yelling
at
anyone.
We're
gonna
stop
even
trying
to
control
what
you
put
in
your
in
your
drafts.
Just
do
anything
that
doesn't
really
make
sense
to
me.
You
know
speaking
as
a
working
group,
member
and
I.
B
B
You
know,
if
that's
what
the
working
group
consensus
actually
is,
I
think
we
would
have
a
problem,
but
it's
it's
a
potential.
This
is
kind
of
like
when
you
go
to
your
doctor
and
they
say
you
know
you've
got
this
this
terrible
illness
and
you
say
well
what
are
my
options
and
they
say:
well,
you
you
always
have
the
option
of
not
being
treated.
That's
your
right!
So,
okay,
the
working
group
has
the
option
of
not
being
treated
or-
and
this
is
the
one
that
I
brought
up
in
the
on
the
mailing
list.
B
Last
week
we
can
say
what,
if
we
have
a
process,
that's
supposed
to
do
something
for
us,
and
people
aren't
finding
that
that
process
is
working
for
them.
Maybe
we
should
change
the
process
and
in
this
case,
there's
a
fairly
simple
path
to
doing
that,
which
is
we
can
say.
Oh
look,
there's
a
registration
policy
here,
that's
not
working
well
for
us.
There's
another
registration
policy,
that's
available
that
might
work
well
for
us.
B
Should
we
move
along
to
reclassify
some
or
all
of
our
registration
policies
and
the
it's
absolutely
administrative
work
to
do
that
you,
you
know
you're
just
going
through
registries
and
saying
well,
this
makes
sense.
This
doesn't
make
sense,
that's
it
and
then
you
write
a
short
RFC
that
says:
I
Ana
is
it's
nothing
but
an
eye
on
a
consideration
section
and
it
says:
I
Ana
is
requested
to
change
this
policy
on
this
registry.
B
To
that
and
then
you
get
at
working
group,
that's
called
and
then
you
progress
it
to
RFC
and
then
boom
you're
done
so
I.
Don't
intend
that
we're
gonna
come
to
any
final
conclusion
here
in
this
room,
but
it
seemed
like
it
was
a
current
topic.
We're
here
in
the
room,
we've
got
mics
go
I'm
gonna
sit
back
down
now
so
Kate
Bedell
arcus.
L
P
Bill
Fenner
a
resident
works
I
just
wanted
with
when
we
went
through
this
exercise
eight
ten
years
ago
there
was
a
lot
of
concern
about
taking
these
code-point
registries
that
had
a
couple
of
hundred
spots
available
and
making
them
first-come
first-serve
like
what
would
we
do
if
someone
came
along
and
registered
two
hundred
code
points
using
you
know,
just
made-up
I,
don't
have
an
answer
to
that
and
I
don't
want
to
say,
don't
do
it
I
want
to
make
sure
that
question
is
considered
yep.
B
That's
I'm
gonna,
respond
to
that.
There's
I
thought
about
creating
a
slide
on
that,
but
it
turns
out
that
that
RFC
8126
talks
about
some
of
that
stuff
in
detail.
So
probably
the
best
next
step
is
go
and
read
it,
but
my
own
answer
to
that.
One
is
first
of
all.
If
we're
concerned
about
that,
we
can
choose
expert
review
instead
of
FCFS,
which
gives
you
just
as
you
know,
this
thin
gatekeeper
layer
where
the
gatekeeper
can
say:
hey,
you're,
hey
skipper,
it
looks
like
you're
trying
to
register
200
code
points.
B
Would
you
like
some
help?
Foolin
with
that
or
another
option
is
to,
and
we
see
this
a
lot
is
to
divide
up
a
space
into.
You
know
you
get
a
hundred
a
sub
rating
of
a
hundred,
that's
you
know
FCFS,
and
then
you
just
reserve
the
rest
so
that
you
know
there
you
can't
get
a
run
on
the
bank.
That
runs
you
all
the
way
out.
So
I
think
those
are
two
options
we
could
consider.
F
F
B
Q
It
is
in
their
Zenith
Phillips
I
have
a
question
above
the
process,
so
the
proper
process
is
from
idea,
Draft
allocation
from
Ayanna,
Garcia
and
so
on.
Motif
I
mean
it
here,
I'm
speaking
for
myself,
I
have
idea
after
that
implementation,
on
only
after
that,
a
draft,
so
I
was
just
trying
to
to
try
my
idea
to
find
out
if
she's
working
and
for
this
purpose,
I've
slaughtered.
Some
attributes
I
even
put
these
implementation
on
the
github
without
any
purpose,
to
make
it
public
to
make
it
public
use
just
two
for
just
a
test
case.
B
B
Another
answer:
is
you
make
your
code
point
configurable
and
force
your
user
to
configure
it
and
configuration?
Neither
of
these
are
great
answers,
so
the
the
next
answer
after
that
is
one
of
these
other
more
permissive
allocation
policies
which,
with
oh
by
the
way
I
didn't,
say
this
in
the
slides
anywhere
but
I
think
we
should
never
ship
another.
You
know
spec,
that
has.
Q
Q
B
G
Job
Snyder's
and
PT
I'd
like
to
respond
to
what
Brenda
Bush
said
where
you,
you
know
just
railroad
over
the
squatter
that
doesn't
always
work.
For
instance,
in
the
case
of
large
BGP
communities,
we
noticed
that
the
legitimate
owner
of
the
BGP
path
attribute
at
the
time
it
was
Ferdie,
was
actually
the
victim
of
other
people.
Squatting
on
that
code
point
had
the
BGP
large
community
attributes
crashed
the
offending
vendor
perfect.
G
The
incentive
would
have
been
on
the
operator
that
has
the
code
with
the
squads
code
points,
but
the
incentive
lay
actually
with
the
developers
of
the
path
attribute
and
the
operators
that
were
experimenting
with
the
path
attributes,
and
this
is
precisely
why
RC
8:09
free
was
presence.
We
deprecated
all
these
code
points
because
very
often
the
squatters
do
not
feel
any
pain.
It's
the
users
of
the
code
point
that
fuel
pain,
so
yeah
railroading
offers
welders,
does
not
work
deprecating.
G
Their
code
points
is
a
valid
strategy
and
I
think
we
should
continue
to
do
that
if
we
observe
squad
up
code
points
and
furthermore,
I
am
in
favor
of
more
permissive
assignment
policies.
If
so
far
the
most
of
the
augmentation
is
it's
too
hard
to
get
a
code
point.
So
let's
make
it
easier
and
that
takes
away
that
arguments.
G
I
I'd
say
that
shortly
when
we
are
squatting,
we
duplicate
a
good
point.
So
basically
it's
it
lost.
So
it's
already
very
be
amiss
here.
So
we
give
it
to
anyone.
It's
already.
First
come
from
server.
I
put
it
in
the
draft.
I
put
it
in
my
implementation,
I
say
it's
too
late
on
either
I
got
a
good
point
or
it's
Dupree
get
it,
but
we
listed
so
I
would
call
for
permission
all.
B
Right
thanks
so
excellent
discussion.
I
am
hoping
that
in
the
next
few
weeks
we
can
move
beyond
discussion
to
actually
making
a
decision.
What
we're
gonna
do
mostly
what
I've
heard
at
the
mic
is
sure.
Let's,
let's
reorganize
our
registry
is
to
reflect
people's.
You
know
needs
better,
and
that
would
be
my
preferred
outcome.
B
The
the
next
steps
are,
if
we
follow
that
path
are
to
have
somebody
write,
a
draft
that
proposes
concrete,
and
you
know
how
that
reorganization
will
be
and
what
it
will
look
like
afterwards,
and
then
we
go
through
the
normal
working
group
process
of
you
know:
bashing
the
draft
talking
about
the
draft,
adopting
it
and
progressing
in
so
we
need.
You
know
if
we're
going
to
follow
that
someone
needs
to
step
up
and
write
a
draft
yeah.
L
Kaor
patel
arcus
again,
since
you
summarized
I
think
for
me
the
problem
is
not
the
process.
You
can
put
any
process
you
want
as
long
as
the
process
takes
less
than
two
days
if
you're
gonna
take
three
weeks,
whoever
has
the
process
and
takes
three
weeks.
That's
to
me,
that's
the
source
of
scoring
when.
B
And
that's
kind
of
what
I
was
trying
to
say
is:
let's
the
fact
that
we
have
a
problem
doesn't
mean
that
people
are
bad.
The
fact
that
we
have
a
problem
means
that
people
have
needs
that
our
process
doesn't
meet,
so
we
can
either
tell
people
not
to
be
bad,
which
is
terrible
or
we
can
fix
our
process
so
that
it's
easier
to
follow
the
process
and
not
follow
it,
which
is
what
I'm
hoping
we
can
do
and
and,
as
you
say,
time
is
a
big
element
of
that.
So.
B
My
answer
to
that
is:
why
are
we
talking
about
this
in
IDR
and
the
answer
is
because
I
might
be
our
co-chair,
not
not
the
routing
ad
and
also
the
way
that
the
IETF
is
structured
is
most
of
the
work
gets
done
in
working
groups
and
different
working
groups
do
have
you
know
different
traditions,
at
least
we're
not
inventing
new
process
here.
That's
that
was
kind
of
the
point
of
my
earlier
slides
is
we
have
a
bunch
of
process?
That's
already
defined
it's
up
to
us
to
pick
one
that
works
well
for
our
community.
H
Jeff
Oz,
and
it
is
a
problem
in
other
working
groups-
I'm,
actually
helping
other
internal
people
work
through
some
old
sins
of
the
past
and
other
technologies.
So
this
is
not
a
problem
just
idea,
but
to
your
specific
point:
no,
why
are
we
having
this
conversation
here?
Bgp
tends
to
have
greater
sins
because
no
we're
global.
You
know
the
problem.
The
job
is
no
bringing
up
of
sure.
You
can
grab
a
point
if
you
squat
on
it.
The
other
person
that
suffers
is
the
one
that
actually
tries
to
get
at
the
point
legitimately.
H
B
R
R
The
presentation
of
the
on
the
flow
spec
draft
that
we
are
working
on
this
is
actually
meant
as
a
replacement
for
RBC
5575.
Current
flows
back
standard
I.
Don't
think
I
need
to
waste
too
much
time
on
the
flow
spec.
Actually
is
it's
this
thing
where
we
can
exchange
flow
filters
together
with
flow
actions
via
BGP?
R
Why
do
we
need
this?
This
update
for
the
current
specification
actually
I
can
give
you
an
example
from
a
service
provider
a
point
of
view.
Last
year
we
built
something
like
this,
where
we
had
like
four
different
vendors
in
the
network.
We
had
a
box
from
juniper
cisco,
who
are
we
and
also
Alcatel,
with
a
Nokia
sticker
on
it
in
the
lab,
so
we
built
like
a
full
mesh
with
BGP.
R
We
had
everything
set
up,
and
then
we
threw
a
few
flowspec
filters
into
the
network
and
what
happened
is
that
the
network
just
literally
burned
down
most
of
the
BGP
sessions
started
to
flap
Isis,
look
got
crazy
and
so
on.
So
there's
there's
obviously
there's
something
wrong
and
it's
not
that
we
are
hunting
bugs
because
yeah
the
bugs
need
to
be
fixed
at
at
the
at
the
vendors
side,
but
it
turned
out
that
there
is
some
general
lack
of
interoperability
and
when
we
dug
a
little
bit
more
into
the
problems
we
saw
well.
R
There
are
some
unclear
specification
sections
in
the
specification
and
it
tends
to
be
quite
hard
for
the
manufacturers
to
to
actually
implement
that
consistently
and
Susan
also
pointed
out
that
there
is
this
unspecified
behavior
on
interfering
flow
actions.
We
encode
those
actions
into
extended
communities,
so
we
so
it's
possible
to
have
an
action
that
says:
ok,
please,
the
rate
limit
that
particular
flow
to
10
megabit
and
have
on
the
same
NLR
I
attach
the
extended
community
that
says,
ok
rate
limit
to
1
gigabit,
and
this
is
not
specified
in
the
original
document.
R
It
also
turned
out
that
already
there
is
a
clarification
needed
for
RFC
5575
to
get
the
redirect
action
right,
which
is
one
of
the
fundamental
actions
built
into
the
protocol
and
I,
was
also
sitting
on
some
mailing
lists
over
the
last
1/2
year
and
answering
questions
on
flowspec
implementation
and
was
always
reading
through
the
document
and
trying
to
get
answers,
and
it
was
not
always
possible
to
get
answers
from
RSC
5575
on
that.
So
what
did
we
actually
change
with
our
draft
in
the
RFC?
R
The
other
two
changes
to
RFC
5575
I
mean
there
are
numerous
of
editorial
changes
in
it,
but
and
I
need
to
point
out
that
we
are
fully
compatible
with
the
RFC
5575,
so
we're
not
breaking
anything
what's
out
there.
It's
just.
We
are
like
more
precise
how
its
needed
to
be
done
and
more
precise
names.
We
are
much
more
precise
on
the
encoding
of
on
the
end
of
the
NLRA,
because
this
is
where
we
saw
many
things
breaking
it's
a
it's
a
little
bit
of
complex
another
I.
R
Obviously,
but
we
saw
many
bgp
notifications
happening
because
just
of
the
encoding
there's
one
fundamental
numeric
operator
built
into
the
NLRA
that
allows
us
to
compare
ports
with
with
value
that's
built
in
there,
and
there
are
big
comparisons
and
so
on,
and
we
were
just
just
more
precise.
We
try
to
document
all
the
different
cases
that
are
in
there.
R
So
this
just
doesn't
fit,
and
actually
all
the
implementations
that
were
that
we
were
looking
are
in.
They
were
just
acting
on
that
as
to
be
a
transitive
community,
I
mean
there's
one
exception.
There's
go
PGP.
They
really
had
some
extra
code
in
it
to
make
this
extended
community
non-transitive,
which
is
ridiculous,
so
so
we
define
it
to
all
extend
all
the
communities.
R
The
flow
actions
that
are
in
the
document
should
be
transitive,
we
added
rate
per
packets
action,
which
is
more
or
less
the
same
at
rate
limit
by
bytes,
and
we
did
some
changes
to
the
redirect
action.
That
I
pointed
a
pointed
out
before,
which
is
one
we
pulled
in,
although
the
clarification
information
that
is
in
our
see
767
4,
which
actually
defines
the
encoding
of
the
extended
community.
So
we
put
this
into
into
this
draft.
I
should
have
been
there
right
from
the
beginning.
R
Then
we
renamed
it
from
redirect
to
RT
redirect
and
there's
one
reason
for
this.
There
are
other
drafts
out
there
with
redirect
actions,
and
we
just
wanted
to
be
more
specific
on
what
this
redirect
actually
is.
So
there
is
an
I
redirect
to
IP
next
top
out
there
as
a
draft
so
which
is
to
want
to
get
out
of
the
way
there
and
then
there
is
this
whole
new
section
on
traffic
actual
interference.
R
So
what
should
happen
if
we
have
a
like
rate
limit
to
10,
megabit
and
rate
limit
to
one
gigabit
in
one
update
at
the
same
time?
So
what
we
said
is
just
treat
it
as
bgp:
withdraw
just
ignore
it.
Don't
don't
spread
it
anymore
and
don't
use
it
for
anything,
and
we
also
defined
what
those
what
what
is,
inter,
what
is
the
interference
so
how
which
what
traffic
actions
that
can
actually
interfere?
R
And
we
also
said
ok,
please,
all
all
new
drafts
out
there,
defining
new
traffic
actions
should
actually
state
how
how
interference
between
traffic
actions
should
be
handled
with
this
new
traffic
action
and
I
very
recently,
I
put
in
a
appendix
to
the
to
our
draft,
which
just
points
out
this
list
of
changes,
because
I
think
so.
This
list
is
other
most
fundamental
changes
that
we
did
to
RFC
5575.
So
it
makes
it
easier
for
for
a
vendor
or
for
implementing
this.
R
H
Jeff
as
thank
you,
this
actually
is
very
useful,
having
dealt
with
not
only
our
own
bugs
know
from
the
first
implementation
of
this,
but
also
with
my
prior
employers,
no
finding
of
no
such
bugs
because
they
read
the
document.
It
was
not
clear
when
comma
I
did
have
is
specifically
about
the
communities
and
the
in
clarity
when
you
have,
for
example,
irate
limit
no,
and
you
have
more
than
one
of
them,
unfortunately,
extended
communities
of
this
type
have
this
problem
everywhere
at
IETF
that
no
they
try
to
do
with
PGP.
H
The
best
working
group
is
completely
littered
with
magic
communities
that
do
something
that
they
don't
define.
What
to
do.
Would
he
get
more
than
one
of
these
types,
I'm,
not
sure
that
we
want
to
go
into
specification
or
how
they
deal
with
a
sort
of
thing.
It's
honestly,
the
kind
of
thing
that
either
I
idea
or
best
probably
should
write
a
document
and
say
here's
what
we
should
do
about
this
as
a
general
thing.
B
A
L
L
So
a
question
was
asked
on
an
implementation
status.
Well,
we
have
implementations
specifically
to
support
application
for
this
draft,
which
is
signature
ordering
based
e
policies,
and
the
deployments
for
these
implicit
implementations
have
also
been
planned.
So
it's
about
to
happen
soon.
The
work
on
implementation
reports
is
in
progress.
All
vendors
are
encouraged
to
filled
in
the
implementation
report.
L
There
was
a
another
question
that
would
have
that
was
asked,
which
was
in
context
of
RFC
five,
five,
six
six.
So,
as
you
know,
this
draft
oxalates
5512,
which
is
a
normative
dependency
on
RFC
55
66.
For
those
of
you
who
don't
know
what
RFC
55
66
outlines,
it's
primarily
the
useful
for
the
IPSec
tunnels.
L
L
Some
other
suggestions
that
we
have
received
there
was
a
need
in
couple
of
subtle
ways
to
increase
the
length
to
to
operate.
It
was
a
good
suggestion.
We
have
already
incorporated
that
in
the
later
draft
revisions.
There
was
a
question
that
the
current
draft
supports
v4
sub,
clearly
for
v4
d,
s
failed,
and
so
the
question
was
for
v6
and
we
have
not
incorporated
it
as
of
now.
L
We
are
waiting
for
a
use
case
and
we
don't
have
a
good
use
case
yet.
That
being
said,
the
draft
does
provide
extensions
in
case
for
the
future
TL
ways
that
need
to
be
defined.
So
we
believe
if
there
is
a
compelling
use
case,
we
can
always
write
a
companion
draft
for
this
and
progress
that
separately.
L
Changes
to
the
text
with
regards
to
bare-bones
tunnel
TLB
bare-bones
tunnel
TL
v
is
usually
a
TL
v
that
only
carries
tunnel
type
and
the
end
point.
It
doesn't
carry
any
in
caps
and
capsulation
information
associated
with
the
tunnels,
so
the
ref
v
said:
don't
use
this
TL
v.
Essentially,
let's
go
and
use
extended
community
instead
to
be
backwards
compatible
and
that
six
of
the
draft
sort
of
loses
this
rule
and
lets
you
use
both
the
bare-bones
TL
v
as
well
as
the
end
cap
extract
community.
L
There
was
also
a
suggestion
on
the
mailing
list
where
folks
said
hey,
why
not
just
carry
only
one
tunnel
TL
v
instead
of
allowing
an
option
to
carry
multiple
and
the
authors
feel
that
an
ability
to
announce
multi
Tunnel
is
an
important
feat.
Tunnels
is
an
important
feature,
and
it's
it's
a
flexible
thing
to
do
so.
We
like
to
leave
it
in
the
draft.
Having
said
that,
implementations
could
always
choose
to
restrict
their
implementation
to
only
source
single
tunnel
TLV
if
they
want.
L
Lastly,
there
was
a
question
about
a
need
for
destination
map
filled
in
n,
VG
r
e
sub
TL
v,
and
this
is
essentially
used
to
specify
destination
MAC
header
inside
for
for
the
inner
Ethernet
header,
and
the
suggestion
on
the
mailing
list
was
to
use
the
draft
format
or
the
proposal
that
is
listed
here
in
the
drop
yong.
The
problem
with
that
suggestion
is
that
the
draft
has
been
expired
for
four
plus
years.
L
It's
not
a
working
group
draft
and
the
current
TL
ways
that
we
have
defined
are
in
accordance
with
RFC
7637,
which
itself
is
the
RFC
outlining
in
which
GRE.
So
the
authors
thought
it's
best
to
leave
the
current
desk
in
capsule
encapsulation
TL
v
as
is,
and
not
fiddle
around
with
it.
So
with
that
I
think
the
authors
have
addressed
almost
all
the
comments
that
we
have
received
so
far.
The
hope
is
to
close
on
to
the
implementation
reports
fairly
quickly
and
then
probably
finish
you,
the
last
call
and
get
it
towards
the
standardization
questions.
B
H
Good
morning,
I'm
jeff
has
you
probably
figured
out
by
now,
since
I've
been
up
the
microphone
a
bunch
of
times
so
I'm
here
to
talk
about
the
route
server
BFD
features.
Now
this
is
our
fourth
update
analyst
we're
sort
of
slowly
converging
on.
You
know
the
the
encoding
formats
that
we
need
to
deal
with
for
this
feature,
and
this
is
actually
generated
a
very
interesting
amount
of
discussion
to
briefly
go
over
what
the
feature
is
for
so
in
route.
Server
environments,
especially
exchange
points
layer,
two
partitioning
happens:
this
causes
black
holes.
H
Problem
is
what
do
you
do
about
this?
When
you're
using
route
servers
route
servers
are
ebgp
proxied
via
an
external
device?
Normally
you'd
run
BFD
directly
to
each
of
the
clients,
but
since
you're
doing
it
via
a
proxy.
You
know
this
option
does
not
directly
work
for
you.
This
means
that
our
sort
of
test
changes
a
little
bit
for
our
ebgp
case.
You
know
the
suggestion
we're
making
is
that
use
BFD
to
test
the
reach
ability
of
the
individual
next
stops.
H
If
you
fail
the
BFD
reach
ability
test,
you
just
simply
make
the
route
ineligible
for
selection,
just
as
if
it
was
an
IP,
GP
type
route.
The
big
trick
here
is
that
route
servers
exchange
their
routes
in
such
a
way
that
no
some
peer
may
actually
receive
a
route
with
a
given
next
top
and
the
other
peer
that
is
sourcing
that
next
top
may
not
receive
the
receivers
next
top
itself.
H
H
The
other
thing
that
this
feature
does
and
where
most
the
document
actually
spends
its
time
is
the
ability
to
not
only
learn
the
set
of
next
hops,
but
also
inform
the
route
server
of
the
actual
reach
ability
from
the
perspective
of
these
routes
or
clients.
This
allows
the
route
server
you
know,
potentially
when
it
makes
sense
where
the
route
server
to
do
so
to
potentially
select
a
different
set
of
routes.
H
You
know
for
to
replace
the
ones
that
are
no
longer
reachable,
and
one
way
to
think
about
this
is
that
this
is
allowing
the
route
server
to
receive
your
proxied
view
of
whether
the
next
stop
is
reachable
or
not.
So,
in
terms
of
changes
to
the
document.
Since
oh
and
we've
done
significant
cleanup
of
the
specification
and
the
encoding,
we
got
rid
of
the
negative
State.
H
The
document
had
at
that
point
been
through
four
distinct
sets
of
editors,
and
the
style
had
definitely
shown
that
and
John
Scudder
took
the
pen
up
and
significally
clean
things
up.
So
hopefully
this
takes
care
one
of
the
biggest
things
that
people
come
at
it
and
that
the
doctor,
it
was
hardly
read
and
the
state
exchange
is
so
much
simpler.
At
this
point,
the
next
top
information
base
idea
still
remains,
but
the
ideas
actually
been
split
into
the
idea
of
you
know
a
reach
esque
and
reach.
H
Tell
mechanism
now
I'm
asking
you
to
track
this
next
top
I'm
telling
you
what
the
next
harvest
our
state
is.
From
my
perspective,
in
terms
of
the
messaging
we've
decided,
they
lift
a
no
and
Stefan
coding
this
the
beach
be
extended
communities
and
having
the
mechanism
track
through
there.
We've
gone
and
lifted
know
that,
according
that's
closer
to
what
we
see
out
of
the
best
typing
coatings
with
a
structured
and
alright.
H
Basically,
whether
this
is
a
reach
ask
or
reach
tell
and
report
the
state
of
whether
it's
no
unknown,
meaning
that
the
bfg
session
itself
is
not
actually
up
yet,
which
may
never
happen
if
it's
not
enabled
I'll
give
ensign
or
whether
it's
up
or
down
past.
That
point
is
just
the
next
hop,
that's
being
tracked
in
terms
of
known
issues
on
the
document.
The
procedure
for
using
the
next
hop
state
from
the
clients
view
is
not
listed
in
the
curt
as
being
optional.
The
current
document
that
was
sort
of
an
oversight
is
part
of
cleanup.
H
Now
our
goal
is
not
to
mandate
route.
Servers
must
do
this.
There
are
operational
environments
for
some
route
server
providers
that
they
simply
do
not
want
to
do
this,
but
even
so,
even
if
you're,
just
using
this
for
the
clients
to
make
use
of
the
BFD
State,
this
is
actually
not
potentially
an
interesting
minute
telemetry
for
the
route
servers
anyway.
H
Also
the
procedure
for
about
the
reach
ask
needs
to
be
slightly
clear
about,
but
we
set
the
statements
to
now.
This
is
generated
a
unusually
large
amount
of
discussion,
not
an
IVR,
so
that
means
people
actually
read.
The
document
have
an
opinion
on
it,
so
that's
great
so
answering
some
of
the
individual
points.
Why
isn't
this
a
or
F,
no
or
F,
being
an
outbound
route
filter?
Well
part
of
the
problem
is
this?
H
Information
is
highly
dynamic
or
F's
tend
to
have
this
implication
that
there's
an
explicit
refresh
in
there,
whether
or
not
you
actually
doing
an
actual
route
refresh
is
actually
up
to
the
implementation
by
the
current
or
F
specification,
but
the
sort
of
internal
implication
there
or
a
feature
is
that
it's
actually
policy.
This
is
closer
to
the
route
resolution
than
policy.
So
I
don't
think
that's.
This
is
really
a
good
fit.
Additionally,
we
have
our
t
constrain
as
a
published
piece
of
work.
H
Now
that
shows
us
that
we
can
use
route
exchanges
way
to
help
no
control
no
signaling
of
stuff.
The
other
thing
that
makes
our
F
slightly
complicated
is
the
or
F
procedures
actually
document
that
they
are
treated
is
M
policies
and
in
the
future,
if
no
ahrefs
actually
do
get
other
forms
of
deployment.
The
route
server
environment.
This
sort
of
complicates
the
ability
to
use
this.
For
of
this
piece
of
the
feature.
H
Another
observation
is
that
if
you
are
actually
informing
the
route
server
that
a
next
hop
is
not
usable,
what
do
you
do
about
that
in
the
case
where
you
have
a
pure
ORD
up,
depending
on
what
your
implementation
calls
such
things
and
there's
multiple
peers
inside
of
that,
potentially
not
even
from
the
same
autonomous
system
that
it
may
not
be
able
to
react
appropriately?
So
an
example
of
this
is
some
route.
H
Server
environments
have
the
default
view
that
you
subscribe
to
may
have
hundreds
of
peers
in
there
and
one
peer
reporting
that
I
can't
get
to
this
next
top
may
make
that
environment
no
to
the
point
where
it
just
simply
cannot
respond
and
give
that
one
peer
note
new
stuff,
that's
totally
reasonable.
However,
that's
not
also
the
only
way
route
servers
are
deployed.
Now
several
people
playing
bird
route
exchanges,
including
the
co-authors
on
our
document,
actually
deploy
a
browser
review,
no
proton
a'mma
system.
H
Another
consideration
is
No.
Why
do
you
want
to
do
this?
You
want,
you
know:
they'd,
be
able
to
get
alternate
paths
from
the
route
service
perspective,
rather
than
just
simply
avoiding
the
black
holing,
avoiding
black
holding
on
its
own
is
a
massive
win.
Getting
the
alternate
paths
is
a
bigger
win
to
allow
the
actual
exchange
point
to
have
no
good
value.
H
Could
we
get
this
a
different
way
that
letting
the
route
server
just
simply
choose
based
on
this
proxied
next
hop
reach
ability?
Now?
Why
don't?
We
use
add
paths?
Well,
the
answer
is
you
certainly
could
use,
add
paths
matter
of
fact
you
could
use
add
paths
in
conjunction
with
this
as
well,
but
some
of
the
considerations
that
we
had
when
we
were
discussing
this
is
that
number
one.
Some
IXP
simply
don't
want
to
use
that
paths,
and
apparently,
in
many
cases
now
client
routers
don't
want
to
use
it
for
various
reasons.
H
This
could
be
a
limited
amount
of
memory
and
it
could
also
be
something
along
the
lines
of
just
simply
the
policy
of
the
receiving
peers.
There's
a
couple
of
other
considerations
that
make
ad
pass
a
little
tricky,
the
first
one
being
that,
even
with
add
paths,
you
typically
choose
some
number
of
additional
paths
to
send
along
based
on
exchange,
point
topologies
and
path
diversity.
H
There
is
a
possibility
that,
even
if
you
say
no,
for
example,
give
me
no
two
paths,
so
you
have
a
backup
that
second
path
may
also
not
necessarily
be
reachable
based
on
how
types
of
partitions
happen.
Now
an
example
at
the
Frankfort
exchange
which
I
have
stats
on
is
down
below
the
a
thousand
ports.
No,
it's
possible
that
a
partition
may
actually
isolate
a
whole
set
of
neck
stops
and
therefore
the
next
test
path
may
still
not
necessarily
be
useful.
Looks
like
care
may
have
a
point.
H
It
hasn't
really
been
clarified
for
how
it
worked
in
a
about
server
environment,
which
is
ebgp,
but
not
really.
There
is
a
prior
draft
that
Pradesh
Mahara
had
done
years
ago,
with
some
of
the
implications
of
ebgp
for
Route
servers
and
no
just
for
consideration.
No,
this
is
the
de
Kix
Frankfurt
topology
and,
as
you
can
see,
no
there's
a
chance
for
potentially
a
large
number
appears
to
be
isolated
by
a
layer
to
partition.
No
that
may
actually
cause
those
problems.
H
I
have
one
more
slide
and
happy
to
take
questions
so
the
the
last
one
is
Anchorage
and
a
few
other
people,
you
know
Robert
I,
think
was
actually
on
there
cut
out
eight
that
sort
of
last
minute
draft
of
no.
How
could
we
do
this
a
different
way
and
I
think
there's
actually
some
good
ideas
in
there.
The
first
one
is
that
you
know
that,
in
terms
of
the
BFD
stuff
part
of
the
reason
why
we
needed
the
ability
to
learn
the
desktops
from
the
route
servers,
because
58
81
requires
both
sides
and
provisioned.
H
H
Also,
to
pick
a
specific
example
now,
Broadcom
does
not
have
the
ability
to
update
their
58,
maybe
one
implementation
because
of
the
way
they
have
on
their
Asics
and
those
are
in
the
last
lower
and
routers
and
switches
larger
vendors,
noticeably
spit
up
a
new
set
of
code
for
their
86
and
they're
done
and
now
sort
of.
Finally,
the
the
BFD
portion
of
the
RSP
of
the
document
is
really
no
the
smallest
bit
of
the
procedure
here,
mostly.
H
L
H
Draft
zero
zero
before
working
that
adoption
actually
used,
the
next
stops
a
fee.
What
we
decided
after
we
were
going
through
the
exercise
is
that
it
wasn't
quite
a
good
fit
and
we
didn't
want
to
know
a
face.
Distorting
you
know
that
draft
in
a
way
that
didn't
really
make
sense
for
the
actual
main
purpose
of
that
draft.
So
yeah
we
we
went
there.
We
decided
wrong
answer
a.
J
H
Go
away
no
so
I,
so
I'm
gonna
throw
two
things
back
at
you.
The
first
one
that
or
from
the
perspective
of
the
route
server
probably
is
a
little
bit
more
work
than
the
route
servers
are
typically
expected
to
do.
The
main
consideration
there
is
route
server
policy
tends
to
actually
be
structured
around
actual
policy
rather
than
IGP
reach
ability.
You
know
that
exchange
point
is
considered
flat.
So,
okay,.
M
H
You
can
technically
use
some
of
the
plumbing,
but
it's
not
really
a
good
fit,
but
the
second
one
is
if
I
were
to
come
up
to
you
as
the
OSPF
chair
and
recommend
that
you
have
a
whole
bunch
of
different
organizations.
I'll
run
a
cooperative,
no
protocol,
no
for
changing
topology,
but
the
shirts
same
shared
secret,
I,
suspect
you'd.
Give
me
a
funny
look
I.
H
S
T
Yeah
yeah
one
of
those
OSPF
neighbors,
decides
to
get
out
of
sync
and
then
all
of
them
get
to
rebuild
their
adjacencies
again.
That
happens
all
the
time.
Oh
it
absolutely
is
true
not
with
your
implementation
good.
Well,
maybe
you
should
talk
to
Cisco
tonight.
T
So
the
way
you
solve
that
on
their
infrastructure
is
to
not
use
the
route
reflectors,
actually
because
they're
kind
of
a
liability
with
because
you
you
can
actually
can't
see
which
of
your
neighbors
is-
is
the
one
that's
in
fact
black
holding
towards
you,
so
I
think.
Work
in
this
area
is
actually
super
useful,
yeah.
H
G
Job
Snyder's
NCT:
can
you
go
back
to
the
depicts
topological
over
fume,
so
the
case
of
a
partition
is
actually
very
clean-cut,
but
in
reality
at
least
common
operational
practice
is
that
the
moment
an
internet
exchange
of
this
size
becomes
partitioned
in
any
meaningful
way?
It
usually
does
not
mean
that
all
the
fibers
got
cut
cleanly.
G
It
means
that
something
went
very
wrong
like
a
loop
or
and
in
such
cases
I,
don't
think
it's
a
desirable
property
to
receive
backup,
perhaps
from
the
route
server,
but
I
would
rather
just
want
to
shut
down
anything
that
goes
over,
that
internet
exchange
as
a
possibility,
so
I
like
with
with
route
server
BFD
jobs.
If
the
participants
have
very
fast
detection,
that
is
a
very
desirable
property.
G
I,
don't
think
it's
desirable
to
offer
alternative
paths
at
any
cost,
because
when
a
few
sessions
go
wrong
often
it
means
the
whole
exchange
is
poisoned
and
you
just
need
to
wait
a
few
hours
before
you
get
traffic
back.
Of
course,
this
is
only
applicable
to
the
internet
exchange,
use
case
and
I
understand
from
you
that
there
are
other
use
cases
that
are
not
internet
exchanges,
but
where
route
service
could
be
useful.
So
perhaps
you
will
be
interesting
to
see
if
in
the
draft,
something
to
that
effect
can
be
documented
to
not
offer
alternative.
H
F
F
F
The
there
is
a
distinct
problem
that
a
fair
number
of
the
participants
in
exchange
are
on
routers,
with
insufficient
memory,
etc,
etc.
That's
why
they're
using
routes
are
two
reasons
to
use
we're
out
server.
One
less
configuration
I,
don't
have
to
add
peers
manually,
but
to
is
I
can't
hold
all
the
routes.
F
Lastly,
the
route
servers-
if
you
read
the
RFC,
are
really
designed
for
this.
It's
just
an
easy
because
they
are
keeping
the
fully
implementation
implemented.
This
is
what
everybody
has
in
bird
at
their
exchanges
today
are
keeping
two
separate
rib
for
each
customer,
so
it's
real
easy
when
that
customer
says
I
can't
get
to
next
top
32
to
deliver
the
next
best
path.
R
R
Think
it's
a
good
idea
to
use
like
some
kind
of
auto
provisioning
VFD
here
on
the
other
side,
I
really
like
the
route
server.
To
give
me
all
its
routes
and
even
alternative
paths
is
there
are
any
so
I'm,
not
sure
if,
if
like
putting
this
states
that
we
already
have
on
the
routers
connected
to
the
exchange,
exchanging
that
with
the
route
server
and
making
more
and
more
overhead
making
the
decision
on
the
route
server
more
complex
that
can
be
easily
distributed
on
on
the
routers
connected
there.
H
R
Yeah,
actually,
the
thing
is
I
think
the
complaint.
It's
just
adds
very
much
to
the
complexity
of
what
you're
bringing
up
here,
because
you
need
all
these
state
exchanges
and
everything.
So
if
you
just
if,
if
you
just
have
this
BFD
Auto
of
all
the
provisioning
in
there,
it's
maybe
much
easier
and
we
have
much.
We
are
much
faster
at
the
goal
to
health
like
no
black
holding
a
dykes
piece,
maybe
yeah.
H
So
I
do
and
make
the
observation
that
every
single
peach
of
the
implementation
has
to
implement
the
resolve
ability
condition
that's
part
of
40
to
71.
Now.
Can
you
reach
us
next
hop
if
you
can't
this
route
is
removed
from
selection?
It's
part
of
standard
route
selection,
so
mostly,
what
this
protocol
is
doing
is
just
proxying
mail.
That
state
know
from
the
perspective
of
the
client
so
that
the
route
server
can
do
exactly
what's
a
standard
part
or
forty
to
seventy
one.
H
N
H
Not
say
complex
I
said
it's
brittle
support
that
you
said
correct,
so
no,
no,
you
Laura
and
Broadcom
stuff
supports,
know
a
single
happy,
FD
single,
happy,
ft.
Spec
wise
requires
the
endpoints
to
be
provisioned,
but
the
check
that
change
258
81
to
allow
for
the
wild
card
stuff
is
not
a
hard
change
the
protocol,
but
it's
just
a
matter
of
you
know
how
do
you
actually
get
it
out
into
stuff?
That
is,
chip
based?
No.
N
Q
M
Q
Q
So
here
are
a
few
examples
that
were
taking
place
during
last
a
few
months.
There
are
four
relics,
all
these
relics,
I
think
there's
more
than
1000
prefixes.
The
second
one
even
resulted
in
a
denial
of
service
for
n
number
of
networks,
and
if
we
are
looking
at
this
list,
only
one
of
these
networks
was
a
stop
one.
So
for
me
it
seems
obvious
that
the
problem
of
relics
is
more
general.
It
is
not
related
only
to
stab
networks,
it's
just
happening
on
the
transit
on
the
big
transit
on
the
local
TV
ones.
Q
So
it's
it's
just
happening,
and
if
we
are
speaking
in
about
the
problem,
even
more
general
I
see
is
a
middle
term
goal
is
a
simplification
of
BGP
configuration
process.
We
need
to
help
not
only
newcomers
but
or
help
engineers
to
configure,
which
should
be
in
a
simple
way,
without
bringing
any
risks
to
other
parties.
But
ok,
let's
move
back
to
our
smaller
small
goal
of
frantic
prevention.
Q
Giving
relations
between
internal
systems
its
have
five
values,
including
complex,
which
is
may
add,
hoc
to
help
in
situations
when
the
simple
four
roles
are
not
enough.
It
also
includes
a
IOT
C,
which
is
non
transit,
attribute
it's
just
a
flag
and
if
roles
are
configured
the
each
with
the
help
of
IO
to
see
it
just
prevents
ice
P
from
leaking.
That's
all,
and
we
got
a
few
really
good
questions
about
the
travel.
Q
So,
let's
just
imagine
that
we
have
got
a
software
update
and
with
these
draft
implemented,
and
but
the
old
configuration
file
has
no
roles.
So
what
should
we
do?
Should
we
raise
a
part
of
our
error,
or
should
we,
for
example,
made
some
default
well
you're
off
roles,
I,
think
these
both
of
these
options
are
not.
Q
Q
It's
just
solves
the
problem
of
the
router
update.
We
do
not
need
default
value
of
rows
anymore,
so
it
looks
fine.
We
also
removed
complex
because
complex
was
a
at
hawk
and
it
resulted
in
more
questions
that
it's
salt
and,
unfortunately,
and
for
those
who
are
looking
still
for
more
flexibility
to
opportunity
to
make
the
links
complex.
Okay,
just
do
it
just
keep
doing
what
you
are
doing
now.
Q
You
do
not
need
roles
in
these
huge
roles
when
the
situation
is
simple
and
be
happy
with
this,
but
removing
the
mandatory
status
of
roles
I
have,
of
course,
its
own
trade
off,
because
when
we
had
mandatory
status,
everybody
should
stuff
rose.
If
nobody
will
set
up
roles,
this
mechanism
will
become
useless,
but
I
hope
these
will
not
happen
by
itself
roles
simplified
their
configuration
process.
Q
Instead
of
set
up
filters
using
communities,
you
are
just
able
to
set
up
one
configuration
option
and
prevent
your
own
ever
from
a
leaking,
so
I
believe
it
will
become
popular
by
itself.
There
is
also
a
BGP
rejection
draft
that
states
make
a
statement
that
if
there
is
no
policy,
there
will
be
no
announces,
no
exchange
of
around
and
so
on.
Q
So,
but
we
do
not
say
about
of
it.
If
the
policy
must
be
configured
manually
or
it
will
be
configured
automatically
in
case
of
rose,
we
also
have
a
strict
mode
which
could
be
used
as
a
motivation
when
one
ice
P
may
try
to
enforce
usage
of
roles
by
the
other
side
and
Rose
may
have
a
number
of
other
applications,
including
route
leak
detection
mitigation.
M
Q
The
IELTS
e
is
just
a
path
attribute,
so
you
are
able
to
configure
each
with
your
pair
prefix
policy
great.
If
their
roles
are
configured,
the
aisle
to
C
will
be
set
automatically.
So
the
draft
will
just
do
not
cover
this
situation.
We
can
make
a
clarification
and
figure.
It's
on
your
upon
your
policy.
If
it's
needed,
you.
V
Don't
think
the
draft
needs
to
say
that
if
it
is
configured
complex
per
prefix,
in
that
case,
the
operator
would
configure
it
but
play
per
prefix
shouldn't
the
draft
say
that
in
that
case,
from
the
configuration
you
can,
you
can
automatically
state
sec.
Iot
see
it
should
say
something
along
those
lines
shouldn't
it.
If.
Q
You
are
configuring.
Your
policies
to
set
up
iot
see
each
is
not
made
out
to
matriculate
so
automatically
to
set.
If
there
are
also
archive
figures,
I
so
it's
just
an
option.
For
example,
if
if
you
have
some
complex
behavior
between
you
and
your
during
a
not
peering
partner
but
another
complex
partner,
so
you
are
able
to
set
up
IOT
C
in
according
to
your
policy,
but
they're,
perfect
policy.
Q
V
V
Q
V
My
feeling
is
a
configuration,
something
in
the
configuration
doesn't
mean
that
you
can.
You
cannot
write
half
code,
that
that
takes
information
from
the
configuration
or
to
do
what
you
need
to
do
with
regard.
What
we
are,
after
all,
looking
for
is
to
have
an
intra,
is
messaging
from
ingress
to
egress,
and
that
messaging
is
IOT,
see
in
this
draft
right
and
someone
else
could
be
using
community
for
that.
V
W
E
Q
A
G
Job
Snyder's
entity
from
the
I
talk
so
much
Department
somewhere
in
the
draft.
You
say
that's
where
they
offer
say
that
if
a
open
policy
mechanism
is
used
that
is
considered
to
satisfy
the
BGP,
reject
RFC,
yeah
I'm,
not
sure
if
that
wording
is
entirely
appropriate
within
the
context
of
what
I
think
the
open
policy
approach
is
trying
to
do.
G
The
BGP
reject
RFC
applies
to
any
and
all
address
families,
simply
because
it
was
argued
that
you
can
never
know
what
the
actual
intention
is
of
setting
up
an
address
family
and
exchanging
information
in
that
API.
So
exchanging
nothing
unless
you
configure
it
to
do
otherwise
is
a
safe
approach.
I
think
the
open
policy
specifically
applies
to
ipv4
and
ipv6
unique
has
strout's
and
it
would
be
not
wise,
I
think
to
open
it
up
for
any
ensel
ap
is
so
the
offers
could
consider
the
argument
to
limit
it
to
fee
for
and
fee
six.
G
L
L
Ko
Patel
I
am
actually
in
favor
of
making
it
generic
and
make
it
as
a
default
policy
for
all
the
other
address
families
where
we
don't
see
a
need,
but
we
see
a
need
making
it
as
a
default,
particularly
for
the
VP
and
address
families.
So,
while
the
applicability
is
there
in
my
mind
from
a
code
perspective,
the
code
could
signal
and
have
different
applicability
for
me
for
and
v6,
because
there
are
relationships
in
VPN.
You
could
use
it
at
an
interest
level
in
a
different
manner
versus
a
pece
level.
Q
Q
G
Q
B
D
When
that's
going
on,
it's
not
clear
to
me
how
the
peer-to-peer
role
that
this
draft
would
impose
would
impact
the
distribution
of
the
VPN
v4
routes
with
other
nni
providers
that
might
be
involved
in
providing
the
same
VPNs
and
I.
Think
trying
to
second-guess
how
those
arrangements
are
made
would
be
pretty
hard,
I
think
I.
Think
in
in
general.
The
thing
that
I
don't
love
about
this
is
brood.
Distribution
policy
is
fundamentally
a
it's
a
it's
a
policy
thing
which
lives
in
address
families
and
we're
trying
to
impose
it
at
the
session
level
and
I.
Q
Okay,
thank
you
very
moment.
I
think
I
will
try
to
get
you
at
the
also
at
lunch
and
discuss
it
because
I
needed
a
clarification
in
it.
So
now
I'd
like
to
address
a
few
questions
to
the
working
group
members.
These
questions
are
from
authors
through
working
group
because
we
do
not
have
a
consensus
scale.
First,
one
seems
to
be
minor
but
eats
logs,
so
there
are
other
location
of
protocol.
So
we
have
two
scenarios
to
send
notification
they're
similar,
but
different.
First
one.
Q
If
we
have
a
conflict,
pairing
roles,
we're
saying
invocation
say
one:
if
one
side
is
using
strictmode
into
the
other
side
is
not
using
Rosa
or
not,
configuring
rolls
it
will
be
again
a
notification.
The
question
is:
do
we
need
to
sub
codes
or
ones
of
code
and
what
is
current
best
practice
for
such
situations?
So
please
advise.
E
G
Job
Snyder's,
on
the
flip
side,
the
sub
codes
within
its
context
will
mean
something
and
the
site
that
is
in
strict
mode
can
associate
a
different
meaning
to
the
same
number
than
the
site.
There
is
not
in
strict
mode
I,
don't
know
if
this
is
a
big
or
small
registry
and
whether
we
are
pressed
for
code
points,
but
ok,
ok
should
I.
Q
Q
Q
We
don't
have
a
consensus
here
from
my
perspective,
Ronald
leak,
detection
medication
is
also
imported.
It
is
just
to
have
laws
about
guns
and,
at
the
same
time,
to
keep
for
selling
the
body
armor,
which
is
needed
for
some
situation.
Nasty
situations
and
also
around
leak,
detection
and
mitigation
could
be
helpful
at
the
state
of
partial
deployment,
just
decreasing
the
color
of
the
damage.
Q
V
V
V
It
is
a
prevention,
then
you
do
need
a
way
of
signaling
between
ISPs,
so
that
when
the
route
passes
from
one
one
ISP
through
the
customer
areas
to
another
ISP,
the
customer
is
not
doing
any
of
this,
but
the
to
is
fees
can
signal
to
each
other
that
have
must
have
a
way
of
signaling,
so
that
so
that
the
the
second
ISP
knows
there
has
been
a
route
leak
and,
and
that
will
take
care
of
a
lot
of
situations
where
the
deployment
is
is
passion
right.
Yes,.
A
W
M
Q
A
A
At
this
point,
I'm
gonna
apologize,
but
we're
we're
gonna
have
to
trim
the
conversation
I
read
by
the
way
I.
Thank
you
all
for
providing
all
the
good
feedback
to
Alexander.
I
really
encourage
this
topic
to
go
a
couple
layers
more
I'd
like
to
ask
the
room:
is
there
interest
in
having
an
interim
or
virtual
or
physical
on
this?
If
so,
would
you
hum
I
hear
some?
U
The
scenario
to
be
addressed
to
a
traffic
theory
network
or
critters
I
want
to
know
the
congestion
sitter's
of
the
exit
links.
The
following
tutorials
will
benefit
from
knowing
the
congestion
as
editors
information
as
in
a
real
one
within
one
years.
Please
look
at
the
picture
on
this
page
autonomous
system
has
three
asbr
Java,
6.7
and
rotate.
U
U
U
The
suggested
solution
can
be
used
both
in
a
network
with
the
central
controller
or
without
yet
for
the
network,
with
with
a
central
controller.
Btb
areas
can
also
be
used
to
get
the
congestion
status,
of
course,
for
the
network
with
retriever
actors.
Routed
reflectors
are
the
command
to
enable
at
past
infection
energy
to
advertise.
U
U
U
U
Although
with
oscillation
and
traffic,
all
these
oscillations
may
be
caused
by
the
introduced
melody,
those
are
the
main
issues.
We
discussed
a
lot
in
the
previous
meetings
and
unlist,
but
when
taking
the
consider
is
the
considerations
here,
are
you
to
account
I
believe
the
suggested
method
can
be
used
in
a
control
control
scope
of
network,
for
example,
the
BGP
receiver
may
choose
to
only
entrust
the
congestion.
If
there
is
information
advertised
by
some
specific
autonomous
systems
are
advertised
by
the
autonomous
systems
within
two
or
three
halls.
U
B
E
Julio
for
Deutsche
Telekom
I
missed
in
the
presentation
some
indication
of
what
your
thoughts
of
the
dynamics
occurring
on
the
a
trigger
on
this
attribute
would
be
the
other
and
I
think
I.
Think
that
should
be
well
understood
and
the
other.
The
other
very
short
comment
is:
if
I
read
your
slide
right,
you
are
limited
to
links
at
256
gigabyte,
a
bits
I
think
it
was
I
think
we
are
already
beyond
that
scope
and
we
actually
deployed
technology.
U
A
B
We
have
been
criticized
in
the
past
people
in
this
room
for
polishing
drafts,
to
the
point
where
they're
already
done
before
we
accept
them
as
working
group
draft.
So
just
as
a
reminder,
the
you
know
the
the
bar
for
accepting
as
a
working
group
draft
should
generally
be.
We
want
to
work
on
this
problem.
We
think
this
is
pretty
much
the
right
idea
and
now
you
know
that's
the
point
where
we
adopted
and
then
we
can
polish
it
after
that
I.
A
X
U
And
we
have
community
container,
so
maybe
I
will
consider
to
choose.
Another
community
to
deliver
is
congestus
leaders,
but
you
know
the
you
can
handle
community,
it's
a
widely
used
so
to
to
to
to
to
delivery
the
local
local
different
policies
to
the
the
bt
period.
Hers
the
Pacific
community
container
is
also
optional
solution.
A
B
U
U
So
do
you
want
to
do
this?
You
notice
people
speculoos
our
starch
in
testing,
set
our
ribs
according
to
the
AFI
and
as
a
fi,
paris
after
meditation
and
or
during
processing.
The
ribs
then
populated
to
use
a
dedicated
hardware,
which
surely
is
shared
with
access
introduced
as
a
dedicated
hardware,
is
much
more
expensive
and
special
immediately
when
compared
with
the
folding
in
from
each
base.
Your
the
40d
from
each
base
can
contain
several
millions
or
several
millions
entries
when
Phyllis
Berg
is
used
for
dynamic
traffic
flow.
U
Steering,
the
number
of
respect
rose,
increases
and
changed
are
frequented
so
to
save
the
limit
hit
expensive
space
of
the
dedicated
hardware
that
is
better
to
populate
some
Frostburg
rules
to
to
fail.
If
possible
and
waiting
the
destination.
Perfect,
beautiful
sparrows
are
suitable
to
be
our
populate
through
the
veil.
U
U
U
So
only
the
technician
previous
habit
helped
through
sparrows
that
passed
the
partition
and
the
ordering
process
are
certified
to
be
published
into
the
phony
from
base
and
your
first
Bible
rules
have
a
hair
power.
It
is
an
Estonian,
a
GP
and
BT
billion
entries,
so
to
calculate
the
formula
three
steps
we
have
to
do
first.
Well,
when
populate
human,
the
FIP,
the
Frostburg
Rose,
are
preferred.
We
have
the
cross
found
in
IDP
and
BGP
routing
entrance.
U
N
B
So
there
are
other
comments,
I
guess
we
can
take
it
to
the
list.
Thank
you.
J
J
The
requirements
for
this
is
a
lot
of
times.
You
want
to
discover
your
peers,
you
don't
want
a
dynamic,
you
don't
want
to
have
to
configure
every
peer
so
that
you
can
have
minimal
configurations,
especially
if
you're,
using
BGP
and
in
a
data
center
as
the
routing
working
group
graph
I
forget
76
whatever
it
is.
So
what
this
does
is
it
and
you
also
want
to
be
able
to
not
only
appear
on
the
interface
address,
but
the
loopback
addresses,
and
additionally
one
thing
we
thought
that
would
give
us
capabilities
beyond.
J
What's
currently
being
used,
is
being
able
to
learn,
authentication
met,
met
methods
and
potentially
pass
other
state
that
you'd
need
to
use
those
authentication
method
mechanisms,
just
as
a
review
we're
going
to
use
lldp.
That's
a
triple
e
802
2.1,
a
b,
it's
implemented
on
just
about
every
vendors,
routers
and
switches
we
already
have
there
already
is
an
I
Triple
E.
J
Curve,
a
mechanism
for
advertising
organizationally
specific
tlvs
inside
of
lldp.
Now
all
we
have
to
Diana
base
done
in
RFC
I
guess
they
don't
have
the
name
RFC,
but
it
was
by
Donald
as
so,
we
already
have
you
know
I,
owe
you
i4i
Anna.
So
all
we
need
to
do
in
order
to
do
this.
That
I
can
see
is,
for
us
to
add
an
Diana
registry
for
ie
ie
TF,
we're
going
to
organizationally
specific
tlbs.
J
J
So
in
the
last
one
in
order
to
appear
on
loop
by
loop
back
addresses-
and
we
discussed
this
quite
a
bit
among
the
offers
was-
we
were
going
to
actually
add
in
delete
routes
based
on
lldp,
and
we
decided
that
ll
VP
is
really
discovering
mechanism
making
it
a
rip.
Client
isn't
really
a
good
idea
and
I
think
that
would
that
would
also
raise
the
bar
on
on
implementation
of
this.
So
we
got
rid
of
that
completely
we're
still
allowing
two
hot
peering
via
lldp
discovery,
except
we're.
Making
the
reach
ability
outer
scopes.
J
You'd
have
to
you'd
have
to
have
that
through
some
other
mechanism,
and
we
also
I
also
added
a
peering
wildcard.
This
is
similar
to
things
that
have
been
in
other
drafts
for
dynamic
discovery
of
what
address
families
are
being
used
for
peering
addresses.
So
if
you
use
the
0
0
couple
for
a
fee
Safi,
that
means
that
you'll
appear
on
all
your
configure
to
address
families.
Now
we
now
because
this
really,
you
don't
mean
we
really
want
to
use
this
because
the
capabilities,
negotiation
things
would
happen.
J
You'd
only
want
to
use
it
in
deployments
where
the
address
families
are
fairly
homogeneous,
the
mix
of
them.
Secondly,
for
a
s
transitions,
we
are
we,
you
can
now
advertise
up
to
two,
a
SS
we
added
an
optional.
These
are
all
optional
added,
an
optional
PGP
identifier,
sub
dlv,
you
you
learn
it
during
open.
You
don't
really
need
it,
but
what
we
thought
we
could
use
this
for
validation
and
also
what
Sean
pointed
out
was.
You
could
have
a
local
heuristic
to
not
not
prevent
but
decrease
the
likelihood
of
a
connection
collision
with
bite
d'alene.
J
Name,
not
sure
if
this
is
the
right
thing,
but
we
have
now.
Keychain
is
kind
of
a
quasi
IETF
standard
with
the
IETF
keychain
yang
model,
and
you
could
use
that
keychain
with
either
md5
or
TCP
a
authentication
next
steps.
It
turns
out
that
vendors
are
already
have
some
limited
mechanisms.
For
example,
a
lot
of
people
are
supporting
discovery
of
the
link,
local
address
and
peering
on
it,
using
a
neighbor
discovery,
type
ev6,
neighbors
discovery
and
the
router
or
advertisements
in
neighbor
discovery.
This
is
this
is
a
little
bit.
J
You
know
this
is
this
is
kind
of
just
a
big
hammer
because
you
just
peer
on
whoever
whoever
is
on
the
point-to-point
link
and
you
don't
have
any
information
on
address
families
or
a
fennec
ation
or
any
validation.
So
we
would,
you
know,
based
on
interest
if
I
think
there's
a
lot
more
here.
Additionally,
I
learned
I
have
learned
and
we're
going
to
add
that
that
vendor
as
a
contributor,
that
there
are
some
vendors
that
are
using
their
own
lldp
organizationally
specific
Thiele
T's
to
discover
bgp
peering.
Y
Y
Don't
see
why
your
why
we
are
suddenly
going
to
a
layer,
2
protocol
that
may,
for
example,
not
even
be
supported
if
I'm
talking
on
a
GRE
tunnel
that
I
want
to
set
up
a
bgp
peering
over
and
I
would
actually
suggest
you
take
the
entire
thing,
put
it
into
ipv6
MD
and
have
the
same
theories
there
may
be
in
the
new
packet
or
whatever
I.
Don't
care,
you're
doing
the
very
same
thing,
your
multi
casting
out
your
data
for
setting
up
the
peering.
You
don't
need
to
go
to
that
I
believe
with
it.
Y
J
Y
L
Q
Patel
arcus
so
don't
implement,
it
will
get
you
a
free.
Will
quote,
don't
worry,
but
the
point
is
the
reason
to
take
it
to
lldp
is
that
there
is
no
discovery.
Protocol
available.
That
is
fairly
generic
enough.
That
applies
to
number
of
networks
and
lldp
is
the
only
one
out
there.
So
it's
a
compromise.
I
really.
N
To
prove
comments,
rubber
traffic,
so
one
comment
is
about
error
handling.
If
you
messed
up
your
TLV
sub,
tlvs
will
be
GP
and
ldq
will
fail.
Then
it's
worse
right
and
the
second.
Even
with
vanilla,
LDP
you
can
get
the
peering
IP
address
and
do
wid.
You
be
open
blindly
to
all
a
facade
this
configure,
which
data
center
it's
pretty
much
just
one
one
or
two
one,
so
you
don't
need
any
extra
TLB
sub
theories
to
achieve
your
functionality.
That's
not
that's!.
M
A
AA
Good
morning,
I'm
a
croissant
from
highway
company
and
my
colleague
is
on
line
and
also
there's
a
course
or
a
phone
call
from
our
Chinese
top
Internet
company.
By
do
so
today,
we
want
to
introduce
a
very
simple
method
for
thee
to
have
that
hybrid
scaredy
engine
to
Europe
your
lives
of
fast
link
Staters,
so
nowadays
managing
a
large
number
of
switcher
links.
AA
You
know,
Taylor
sent
from
a
controller
is
a
difficult
skill
problem
so
from
our
requirement
of
our
clients,
Marty
hop
BGP
is
more
and
more
widely
used
due
to
PGP
product
pressure
caused
by
point
or
in
connection
in
a
hyper
Security
Center
and
also
it
should.
We
have
many
solution
to
self
problem,
but
it
has
some
limitation.
For
example,
the
PGP
keep
live
mechanism
and
some
other
similar
mechanism
may
resulting
high
convergence
delays
and
the
PFD
stated
Monohan.
AA
So
it's
our
solution.
First
step
the
controller,
send
your
update
message,
a
one
to
the
first
device
r1
and
once
again
the
message
is
sent
now
empirical
just
once,
and
if
the
daughter's
can
establish
appear
and
the
message
a
one
contains
a
one
hoc
community
attribute
and
its
prefix
is
used
to
identify
device
r1.
AA
Sorry
and
finally,
if
link
stayed
or
changed
our
to
send
a
message
back
to
the
contour,
with
either
nouns
or
withdraw
type,
and
why
the
controller
receives
a
one
update
message
from
our
two.
So
first,
it
can
locate
corresponding
link
based
on
prefix
and
source
IP
in
the
message,
and
if
the
message
is
dot,
announce
type
links,
data
is
normally
and
otherwise
links.
Theory
fort,
and
we
want
to
notice
here
that
we
do
not
pay
for
any
link.
AA
AA
J
AA
B
P
S
We
could
use
bt
pls,
but
it's
too
heavy
you.
What
we're
trying
to
do
is
automate
the
process
of
configuring
BGP
and
a
link
detection
together
and
if
a
bit
yeah
or
a
community
can
do
it.
That
just
makes
the
self
configuration
much
better
that
there
are
many
other
ways
I
mean
you
could
for.
If
you
think,
a
little
bit
outside
the
box
of
BGP,
you
can
do
it
with
a
propriety
protocol.
Also.