►
From YouTube: IETF111-GROW-20210727-2130
Description
GROW meeting session at IETF111
2021/07/27 2130
https://datatracker.ietf.org/meeting/111/proceedings/
A
E
B
C
A
A
A
A
A
A
Second,
to
last
sriram
with
an
analysis
on
bgp
community
as
they
observed
them
in
the
default
three
zone
and
a
agenda
item
that
is
on
the
text
file,
but
not
on
this
slide
is
paolo
lucenti.
Who
will
give
an
update
on
bmp
tlv?
So
we
should
not
forget
that
after
sriram
apollo
has
an
update
as
well
and
that's
it.
For
today
I
would
like
to
hand
over
microphone
and
video
and
screen
sharing
to
thomas.
A
E
Yeah,
hello,
everybody
give
you
a
small
update
on
what
we
did
last
week
in
the
bmp
hackathon.
E
So
again
we
were
focusing
on
performance
tests
around
bmp,
basically
on
the
what
is
the
impact
on
bmp
low
clip
the
additional
tlvs
also
around
path
marking,
especially
when
the
bmp
session
is
stable,
unstable
and
also
when
the
bgp
peers
are
either
in
stable
condition
or
being
re-established
entirely.
E
So
you
want
to
see
basically
what
is
the
impact
on
on
the
pgp
propagation
delay
so
whenever
bmp
is
enabled
or
not,
or
also
if
on
the
congestion
state,
that
the
bmp
monitoring
is
always
being
able
to
export
the
the
rip
state
properly
or
not?
E
So
that's,
basically
the
software
we
used
here
at
the
end,
a
small
blog
post.
If
you
want
to
establish
your
own
lab
setup
here,
just
that
the
lab
overview
so,
on
the
left
hand,
side
the
injection
from
exa
bgp,
where
we
ingested
one
million
vpn
before.
A
E
A
And
can
you
press
oh
yeah,
perfect?
Thank
you
so
much
good.
Okay,
I
will
seize.
My
interruption.
Can.
E
E
Route,
which
has
a
bmp
adjacency
rib
out
configured
the
cloud
reflected
in
between
where
we
did
the
manipulation,
the
pier
flaps,
the
bmp
flaps
and
pe
router,
basically
importing
all
the
routes,
and
we
are
comparing
the
adjacency
rib
out
versus
start
tracing
syrip
in
where
we
measure
the
propagation
delay
throughout
the
route
reflector
in
between
when
bmp
is
enabled
or
not.
E
So
the
test
automation
is
progressing.
This
time
we
were
also
able
to
measure
most
of
the
the
things
through
a
young
push.
E
We
have
you
know
in
the
meantime,
four
different
operating
system
running
next
step
will
be
to
scale
higher
in
the
topology,
also
use
the
sis
concentrators
as
route
reflectors
and
see
there
what
the
difference
are
and
also
we
are
looking
forward
on
improved
timestamping
on
huawei
vrp
speaking
of
timestamping.
E
E
This
is
the
the
yang
models.
We
are
used
to
actually
measure
the
the
b2p
and
the
cpu
impact,
the
cpu
impact
and
the
memory
impact-
and
this
is
one
test
result
here.
E
So
basically,
we
are
measuring
the
the
the
latency
then
either
on
the
on
the
stable
condition
on
on
the
left
side,
when
bgp
is
in
stable
condition
on
the
right
side,
when
we
are
flapping
the
bgp
piers,
and
you
can
see
the
difference
when
on
in
in
the
middle,
the
the
the
how
to
reflect
the
pmp
is
enabled
or
not,
and
it
shows
that
there's
the
slide
overhead
we
have
on
the
propagation
delay
when
bnp
is
enabled.
E
This
is
the
difference
between
also
on
the
propagation
delay
when
bmp
either
is
turned
on
off
or
the
bmp
is
flapping.
E
Here
the
the
the
cpu
impact
when
the
the
bgp
all
the
bgps
on
the
route.
Reflector
is
a
flapping
in
terms
of
cpus
utilization
and
memory
utilization.
E
Here
the
the
the
tuning
parado,
which
is
basically
in
this
case
just
in
transit,
mesh
measuring
bmp,
adjacency
rep
out
and
depending
on
the
the
central
route,
reflected
the
huawei
if
bmp
turned
off
or
on,
we
don't
see
any
any
difference
in
here.
So
basically,
the
the
bmp
on
the
route
reflector
doesn't
change
or
doesn't
have
any
negative
impact
on
on
the
entire
routing
topology.
E
Here
the
same
view
on
the
pe
route
on
the
cisco
side,
also
more
or
less
showing
a
very
similar
picture,
yeah,
so
the
I
would
say
the
taste
automation
helped
a
lot.
We
were
this
time,
not
progressing
that
fast
as
we
wanted.
E
A
B
A
A
A
G
You
yeah
I'm
right
handed
I'm
in
zurich,
switzerland,
it's
also
11
48
pm
over
here.
Let
me
figure
out
how
how
to
present
the
slides.
B
G
There
you
go.
Thank
you
so
hi
there,
I'm
rihanna
I'm
going
to
present
about
basically
an
idea
that
I
had
to
allow
the
sharing
of
looking
glass
addresses
through
bgp,
just
as
a
disclaimer
upfront
like
I
don't
really
mind
in
which
way
this
is
going
to
be
implemented.
I
just
wanted
to
bring
the
idea
up.
G
So
the
current
implementation
in
the
draft
here
in
the
document
which
I
put
on
the
data
tracker
is
just
like
one
way
it
could
be
done
and
I'm
really
open
to
any
feedback
that
you
have
on
how
to
actually
do
this
so
next
slide.
Please.
G
So
the
problem
that
I
wanted
to
solve
with
this
mechanism
is
that,
when
you're
turning
up
a
new
bgp
session,
how
do
you
know
that
the
peers
that
you're
announcing
the
routes
to
have
actually
accepted
it?
How
do
you
know,
there's
no
misconfiguration,
maybe
there's
a
filter
that
has
a
typo
in
it,
and
the
rights
that
you
want
to
announce
are
being
dropped
like
in
the
mechanism
that
we
have
now.
G
You
would
just
manually
have
to
go
and
check
that
and
when
you're
doing
things
like
anycast,
when
you're
announcing
the
same
prefix
in
multiple
places,
if
you
just
ping
the
address
that
you
won't
know,
is
it
going
to
the
right
place.
So
what
if
you
could
programmatically
check
that
the
new
point
of
presence,
you're
turning
up,
has
come
up
online
and
healthy
next
slide?
Please,
so
the
the
current
way
that
I
believe
people
check
for
route
acceptance
is
through
looking
glasses.
G
G
So
the
human
operator
can
then
go
go
to
that
web
page
type
in
some
prefixes
and
check.
That
hey
is.
Is
this
looking
glass
showing
a
view
from
the
peer
that
I
expect
the
peer
to
see
and
this
process
is
very
manual?
It's
one
off
you
can't
really
programmatically
probe
and
see
like
one
month
in
the
future
is
something
changed.
Is
it
still
working
correctly
next
slide,
please?
G
So
the
idea
that
I
had
was
to
add
a
new
administrative
message
by
using
this
multi-protocol
reachable
and
multiple
to
call
unreachable
path
attribute
in
the
bgp
update
message.
There
was
a
bunch
of
discussion
in
the
mailing
list
about
like
how
to
do
this.
When
I
first
emailed
the
mailing
list,
I
think
someone
brought
up
the
idea
of
using
the
address
family
and
that's
kind
of
how
I
went
down
this
path.
G
There
was
also
some
discussion
of
the
bgp
operational
message,
which
I
thought
was
really
cool
as
well,
but
I
didn't
really
see
any
implementation
of
that,
which
is
why
I
kind
of
went
down
this
path
here.
So
in
this
approach
it
would
use
the
payload
in
the
multi-protocol
path
attribute
to
put
like
a
type
length
value
in
there,
and
one
of
these
tovs
can
be
containing
the
autonomous
system
number
and
a
looking
glass
for
that
autonomous
system
number.
So.
H
G
Approach
lets
you
send
it
to
direct
peers
as
well
as
forward
looking
glass
urls
for
peers
of
peers,
for
example,
if
you
want
to
see
what
the
looking
glass
address
for
a
tier
one
isp
is
when
you're
at
least
as
next
slide,
please.
G
G
Direct
peers
can
send
their
looking
glass
themselves
and
one
way
I
thought
that
the
propagation
could
work
would
be
that
if
an
intermediate
a
s
forwards
a
route
to
one
of
its
other
peers,
it
would
know
whether
that
other
peer
has
a
looking
glass
and
they
could
then
forward
that
looking
glass
address
to
the
pier
which
sent
it
the
route
next
slide.
Please.
G
So,
just
as
an
example
say,
we
have
a
leaf
as
that
connects
to
some
transit,
as
which
has
then
like
some
tier
one
isps
above
it.
So
when
the
leaf,
as
connects
to
the
transit
aes,
the
transit,
as
can
say
hey,
this
is
my
looking
glass
and
then
the
leafyis
can
check
for
acceptance
in
the
transit
to
see
whether
the
route
went
to
that
first
hop
and
then,
when
the
transit
as
forwards,
the
routes
to
its
upstreams
like
es1,
2
and
3.
G
Here,
the
transit,
as
could
then
forward
on
the
looking
glass
addresses
back
down
to
the
leaf
as
in
the
leaf,
as
can
then
probe
those
up
streams
to
see
whether
the
routes
has
been
accepted
there
or
if
there's
any
prefix
filtering
issues
or
rpki
issues
or
other
other
issues
with
that
and
in
a
similar
way,
that
could
be
done
in
a
internet
exchange.
Write
reflector
on
the
right
next
slide.
Please.
G
So
there
are
a
bunch
of
open
issues
with
with
this
kind
of
proposal,
one
of
which
is
that
the
rfc
8522,
which
defines
looking
glass
interface,
which
I
kind
of
piggybacked
upon,
doesn't
actually
specify
any
machine
readable
data
in
there.
It
just
outputs,
freeform
text,
from
whatever
the
looking
glass
decides
to
return.
Some
people
mentioned
that
we
could
use
a
top-level
domain
of
bgp
and
then
just
put
all
the
looking
glasses
in
there,
and
that
would
be
how
you
would
discover
them,
and
it's
unclear.
G
G
So
that
was
all
I've
prepared
in
the
slides
I'd
like
to
open
up
the
floor
to
any
discussion.
If
you
have
a
few
minutes.
A
We
have
some
time
I
saw
jared
march
first
in
the
queue
jared
go
ahead.
F
Yeah,
I
think
we've
been
kind
of
hunting
around
this
in
the
industry
for
a
number
of
years,
there's
been
this
concept
of
like
twitter
for
bgp
a
way
to
send
messages
and
looking
like
different
things,
and
I
I
specifically
have
an
operational
problem
around
you
know
discovering
not
if
it's
propagated
far,
but
I
want
to
understand
if
the
like,
if
the
provider
or
the
adjacent
device
has
actually
accepted
the
prefix,
because
I
I
think
that
there's
a
lot
of
things
for
work,
especially
you
know
you
mentioned
anycast
in
your
use
case
and
cast
prefix.
F
When
you
look
at
it
externally,
it's
just
going
to
have
an
as
path,
and
that's
that's
not
going
to
tell
you.
It
was
accepted
by
the
partner
device
that
you
may
have
a
pgp
session
with,
and
so
I
think
that
there's
there's
likely
some
there's
work.
That
should
be
done
here.
I'm
not
sure
if
it
would
be
here
or
an
idr,
for
you
know
the
messaging
or
a
way
to
basically
or
get
a
copy
of
the
data
from
the
partner
dice
device
via
bmp
or
something.
F
But
you
mentioned
things
like
rpki
invalids
and
I
think
that
I'm
sure
I'm
sure
I'm
already
hearing
like
jeff
haas
in
the
back
of
my
brain
talking
about
the
challenges
in
trying
to
understand
why
the
partner
device
has
rejected
a
route
as
well
and
the
additional
code
complexity.
That's
going
to
put
into
the
bgp
implementation
to
understand
why
the
policy
engine
of
the
partner
device,
but
I
I
really.
F
G
Just
to
add
to
that
last
note
there
I
think,
there's
still
value,
even
if
the
code
doesn't
programmatically
know
what's
wrong,
just
to
be
able
to
detect
and
flag
an
alert
saying
there
is
something
which
is
abnormal
would
still.
J
Middle
of
the
night
here
as
well-
yes,
I
I
largely
echo
what
jared
said.
I
think
it's
a
it's
a
genuine
problem
that
you're
trying
to
solve.
I
don't
think
I
think
that
going
down
the
trying
to
auto
discover
the
location
of
looking
glasses
is
the
wrong
is,
is
is
a
fundamentally
flawed
approach
and
the
reason
for
that
is
the
the
problem
that
jared
mentioned
doesn't
isn't
just
any
cast.
J
It's
any
any
pair
of
asses
where
there
are
multiple
adjacencies,
because
typically
people's
looking
glass
interfaces,
certainly
true
for
us
are
not
going
to
give
you
access
to
go
and
look
at
the
ribs
of
every
single
router
in
the
network.
Typically,
it's
you
know
one
per
pop
or
one
per
region,
or
something
like
that
and
trying
to
glean
from
those
interfaces.
J
Whether
or
not
a
specific
prefix
is
showing
up
on
a
specific
adjacency
requires
all
sorts
of
additional
knowledge
of
your
neighbor,
like
what's
their
igp
topology,
look
like
what
are
their,
what
are
their
loot
back
addresses
you
know,
etc,
etc,
etc.
So
I
just
don't
think
that
that's
ever,
I
think.
Even
if
you
solved
the
machine
readability
problem,
we
had
a
standard
interface
and
we
had
a
you
know
a
neat
way
of
discovering
all
of
this
sort
of
thing.
J
A
An
additional
challenge
here
may
even
be
that,
even
if
the
adjacent
router
has
accepted
the
prefix,
we
don't
know
if
it
will
propagate
beyond
that,
because
local
policy
attach
no
advertise
or
there
may
be
other
paths.
I
So
I
guess
two
sets
of
comments.
The
first
one
for
discovery,
no,
certainly
posting
stuff
into
bgp.
You
know
that's
what
the
admin
style
messages
were
useful
for
and
the
lack
of
implementation
shouldn't
bother.
You
too
much.
You
know,
basically,
by
asking
for
something
that
can
do
a
fee,
safy
you're
asking
for
people
to
change
their
code.
They
do
this
stuff
anyway.
I
I
could
also
observe
that
you
could
just
literally
stick
this
information
into
a
dns
ptr
record
for
the
ip
address
that
you're
appearing
with
with
the
service
provider.
So
there's
there's
ways
for
us
to
sort
of
publish
this
in
a
public
format
and
that
we've
had
discussions
for
among
people
in
this
group
about
we're
sort
of
in
need
of
general
internet
service
provider.
Registries
of
various
words.
This
is
just
another
flavor
of
that,
so
this
this
might
be
worth
solving
in
a
directory
style
sense.
Something
gross!
I
You
know
absolutely
within
charter
to
do
is
just
say
here:
here's
a
way
for
us
to
actually
get
together
and
start
gathering
this
stuff
in
a
common
place,
common
taxonomy,
common
data
model,
all
good
stuff.
The
second
point
you
know
just
sort
of
talking
back
to
jared.
No,
we
we,
we
had
a
personal
comment,
conversation
about
what
a
feature
you
know
that
sort
of
an
echo
service
would
look
like
and
a
true
echo
service
of
you
know,
parroting
back
exactly
what
you
sent.
I
It
was
sort
of
tricky
you're,
effectively
turning
the
full
loopback
mode,
especially
if
it's
on
demand
into
an
actual.
You
know
another
bgp
peer,
so
that
that's
sort
of
something
that
would
impact
your
scaling,
but
that's
actually
not
the
thing
that
I'm
terribly
concerned
about.
We
know
sort
of
what
that
would
look
like
what
I
think
is
probably
a
more
interesting
discussion
point
for
people
in
this
group
is
to
decide
what
the
privacy
implications
of
this
would
be
from
a
service
provider
perspective
and
privacy
means
a
little
bit
something
weird
here.
I
I
I
may
not
want
to
show
you
that,
so
there
may
be
a
good
motivation
to
say.
Yes,
I
have
accepted
your
route
and
it
is
indeed
eligible
for
route
selection
and
if
it
stops
there
now,
basically
what
the
echo
service
would
look
like
is
getting
back
a
list
of
here's,
the
prefixes
that
I've
accepted,
forgive
naffy,
saffy,
potentially
with
adpaths,
and
that
is
a
fully
tractable
feature
past.
That
point,
I
think
the
privacy
considerations
kick
in
and
the
operators
in
this
group
are
going
to
be
strongly
opinionated
it'll,
be.
H
Hi,
I'm
I'm
going
to
be
sorry
because
I'm
going
to
feel
to
sound,
very,
very
bad.
The
road
to
alice
have
good
attention
and,
and
I've
seen
enough
rfc
to
see
that
one
is
again
a
good
idea
which
I
think
is
going
to
get
little
traction
from
vendors
or
not
going
to
do
things
right
also,
I
must
admit
I
have
as
a
developer
kind
of
an
addition
to
use
afisafee
to
carry
non-office
of
information,
and
I
think
we
are
well.
H
H
What's
what
you
want
you
want
to
do,
I
think,
is
trying
to
solve
a
genuine
operational
issue,
and
I
can
genuinely
say
you
must
have
put
a
lot
of
effort
in
that
that
document
to
try
to
get
done
and
I'm
sure
that
job
as
well
knows
how
painful
it
can
be
to
try
to
get
draft
through.
I
do
not
believe
that
I
personally
will
support
certain
documents.
Whilst
I
can
see
very
that
you
have
a
need
and
you're
trying
to
help.
So
I'm
very
sorry
to
be
one
a
voice,
not
supporting
the
idea.
G
Sure
no
worries
I
mean
I'm
also
happy
to
not
pollute
the
name,
space
of
athletes
and
staffies
with
this
other
random
thing,
which
is
not
addressing
like,
even
just
for
me
to
understand
what
this
was
and
how
to
fit
it
in,
like
seemed
pretty
nasty
to
stuff
it
in
there.
I
think,
like
the
operational
message
would
be
great,
and
maybe
I
can
like
look
into
that
further.
A
K
Am
I
being
heard
okay
kind
of
I'm
not
into
discussing
how
to
present
the
information?
What
I'm
interested
in
first
is:
what
function
are
we
actually
looking
for
and
what
is
what
are
functions
that
are
reasonable
to
look
for
and
what
functions
may
actually
kind
of
disturb,
and
there,
I
think,
actually
providing
feedback
about.
The
probably
few
rejects
that
someone
has
in
his
ingress
policy
is
really
of
interest
if
someone
actually
leaks
the
whole
table.
Of
course,
the
flood
of
messages
also
are
kind
of
useful.
I
K
Reason
why
a
certain
rejections
happens
and
kind
of
in
the
function
that
is
of
interest.
Obviously,
that
would
work
nicely
together
and
kind
of.
I
would
even
think
that,
without
global
standardization
of
all
possible
causes
of
why
someone
doesn't
want
a
route,
exchanging
exchanging
exchanging
with
your
neighbor,
if
you
are
seeing
codes
for
rejections,
the
table
that
is
used
in
the
particular
case,
probably
probably
is
not
completely
unfeasible
unfeasible
like
actually
the
conventions
used
on
your
coding
in
communities
is
something
that
is
not
yet
globally
standardized
to
all
the
details.
K
Again,
I
have
not
been
thinking
that
much
about
how
to
code
the
damned
stuff,
but
I
think
it
would
be.
It
would
be
a
good
thing
to
figure
out
how
to
how
we
could
address
this
functionality
and
kind
of
going
for
really
look
going
for
looking
glasses
and
looking
into
large
tables
force,
not
tracking
certain
routes.
Looks
ca,
looks
like
something
that
is
kind
of
less
attractive.
G
So
thanks
completely
agree
that,
like
the
thing
you
propose
to
only
get
feedback
on,
the
ones
which
were
rejected
even
from
direct
here
would
be
really
useful
in
the
case
where
there's
something
clearly
wrong
with
what
you're
announcing.
I
think
that
that
could
be
the
future
direction
of
way
to
bring
this.
F
F
I
think
there's
a
lot,
there's
a
lot
of
potential
here
for
scope
and
feature
creep
as
well,
where
people
are
going
to
say.
I
want
this
or
I
want
that.
I
I
think
that
the
simpler
that
we
would
keep
a
solution
in
this
space,
the
better
I
think,
distributing
you
know,
locations
for
looking
glasses
and
stuff.
I
think
is
it's
going
to
be
interesting,
but
that's
going
to
be
much
more
useful
to
do
through.
You
know,
you
know
posting
it
on
a
web
page
and
just
people
keeping
an
up-to-date
list.
F
I
think
for
this
there's
probably
the
probably
the
most
interesting
pieces
of
work
here
are
around
what
the
operator
requirements
are
for
the
space
and
focusing
on
whatever
that
minimal,
viable
set
of
requirements
are
and
then
determining
what.
If
any,
protocol
changes
or
additions
would
need
to
be
done
and
liaise
with
idr
to
determine
you
know
what
what
those
are
and
how
to
how
to
get
those
implemented,
because,
as
jeff
mentioned,
understanding,
what
the
whether
or
not
a
route
is
eligible
for
path.
F
Selection
is
probably,
as
far
as
I
think
we
could
probably
get
and
also
remember,
there's
a
lot
of
really
complex
networking
things
that
people
do
these
days
and
so
that
are
that
use
the
internet
protocols,
but
aren't
the
internet.
So
people
run
lots
of
things
like
vrfs
and
other.
You
know
other
interesting,
affy,
safies
internally
and
trying
to
go
and
implement
something
that
works
across
those
as
well
or
to
talk
about
that
solution.
Space
will
get
incredibly
complex
very
quickly
if
we
try
to.
F
If
we
try
to
cover
all
of
that,
so
I
think
you
know
focusing
on
what
an
operating
requirement
would
be.
I
think
like,
like
that's
my
concern,
I'd
be
happy
to
work
with
you
to
at
least
talk
about
what
the
operational
requirements
I
have
in
my
environment,
which
is
which
I
think
is
relatively
modest,
but
you
know
what
we'd
have
to
see.
What
other
you
know.
Things
and
I'd
be
willing
to
work
with
you
to
get
something
to
present
to
the
working
group
on
that.
A
All
right
raihan,
thank
you
so
much
for
coming
to
this
working
group.
I
think
this
is
your
first
presentation
in
the
grow
working
group.
It
is
thank
you.
Thank
you.
I
hope
it
was
enjoyable.
A
It
appears
there
is
many
avenues
to
to
follow
up
on
this
work.
I
think
part
of
the
working
group
enjoys
talking
about
very
specific
problem
statements
so,
for
instance,
how
to
find
a
looking
glass
uri
is
a
different
problem.
Then
is
my
route
accepted
or
not
and
of
course,
there's
overlap
to
some
degree,
but
but
the
first
can
perhaps
maybe
be
exchanged
through
an
operational
message
or
via
dns
or
appearing
to
be,
or
the
rpki
or,
and
then
the
second
question
is
the
route
accepted
or
not
has
certainly
so
some
challenges.
A
A
A
L
B
I
L
C
L
L
Okay,
good
and
I
asked
to
I
asked
to
share
slides
chris.
If
you
can
allow
that,
I
can
then
control
the
slides.
It
seems
all
right
so
this
is.
We
only
have
like
17
minutes
for
the
next
two
talks,
so
I'll
try
to
be
as
quick
as
possible,
so
this
work
is
related
to
analysis
of
propagation
of
regular,
extended
large
communities.
This
is
joint
work
with
lilia
hanachi.
L
L
Slide
so
the
motivation
for
this
study
there
are
drafts
that
are
in
progress
in
the
ietf,
the
applications
there
require
ec
lc
transitivity,
at
least
over
a
few
hops.
L
The
gout
the
grow
route
leaks
detection
mitigation
draft
is
an
example,
so
the
question
is:
can
they
get
the
transitivity
of
lcec
that
they
need
there
are
there
were
there?
Was
an
extensive
discussion
on
idr
grow
list
about
that,
so
we
decided
to
focus
on
studying
and
measuring
the
propagation
of
ec
and
lc
to
help
that
discussion
next
slide.
L
So
some
basics
about
the
measurements
we
make
use
of
route
views
and
write
press
data
we
consider
only
unique
prefix
as
path
and
in
the
community
combinations
and
the
technique
used
by
here
in
this
study
is
similar
to
what
was
used
in
the
streibelt
study.
You
look
at
the
as
number
in
the
community
match
that
is
number
with
the
with
the
same
thing
in
the
path
and
then
from
there
to
the
left.
L
The
update
is
assumed
to
propagate
for,
in
this
example,
from
3
4
9
1,
the
update
propagates
two
hops
to
the
left,
most
almost
recent,
as
so
it's
a
two
half
propagation.
In
this
example,
the
community
could
have
started
much
earlier
than
three
four
nine
one,
and
so
in
that
sense
it
is
a
conservative
estimate
of
the
number
of
hops
of
propagation.
L
There
are
other
reasons
that
are
listed
here.
Why?
The
why
this
number
of
hops
estimate
could
be
a
conservative
or
low
estimate?
We
can
move
on
to
the
next
slide.
L
L
L
Please
so
this
is
an
example
of
an
update
with
with
ec
the
extended
community
is
represented
as
unknown
attribute
in
the
update.
So
we
look
at
that
number
16
in
the
middle
is,
is
the
id
for
ionia
assigned
id
for
the
for
the
extended
community
so
and
the
global
administrator
ea
ea2b,
the
hex
notation,
is
converted
into
59947
decimal
and
in
this
case,
from
there
it
propagates
two
hops
to
the
leftmost,
as
so
two
half
propagation
next
slide
please.
L
L
The
black
hole
community
can
be
represented,
encoded
in
two
ways:
the
as
number
of
the
of
the
rtbh
remote
triggered
black
hole
provider
followed
by
666
or
the
wkc
65535
666
next
slide.
Please.
L
So
there's
a
notion
of
for
the
black
hole
community
as
distance
to
the
rtbh
service
provider
and
also
the
propagation.
So
if
we
look
at
this
example,
3356
is
the
rtbh
provider
and
the
originating
the
originating
as6147
adds
the
community
it
propagates
two
hops
to
3356
the
the
rtbh
provider.
So
two
hops
is
the
as
distance
in
this
case
and
the
propagation
is
in
this
case
the
community
propagates
all
the
way
away
across
from
right
to
left
in
the
air's
path.
So
the
number
of
hops
is
three
next
slide.
Please.
L
And
then
we
take
care
of
some
additional
things
related
to
related
to
how
we
take
care
of,
like
the
trans,
transitivity
counts
for
the
ass,
and
some
special
consideration
needs
to
be
given
for
black
hole
community
and
that's
what
we
do.
We
explain
in
this
slide.
We
can
skip
this
slide
next
slide.
L
So
this
is
where
the
results
slides
start.
We
have
it.
We
are
looking
at
right
raise
july
july,
15th
the
full
day,
24
hours,
total
number
of
updates,
52
million.
Out
of
that,
we
extract
the
unique
number
of
prefix
parts
and
various
types
of
communities
we.
We
also
provide
data
analysis
on
the
number
of
transitive
vcs
number
of
transitive,
two
octet
transitive,
four
octet
and
a
variety
of
statistics
related
to
the
black
hole
community
involving
the
666.
L
So
one
thing
to
note
here
is:
there
is
also
zero
zero,
which
is
the
so-called
internet
community.
We
do
see
like
about
18
000
of
them.
Internet
community
means
it
can
propagate
to
anywhere
in
the
internet.
L
So
this
is
large
community
propagation
distribution.
We
see
it
propagates
all
the
way
up
to
ten
halves
fairly
reasonably
high
numbers
at
one
hop
to
hop
three
hop
propagation.
Zero
hop
simply
means
that
the
the
last
the
leftmost
a.s
happens
to
be
the
peer
of
the
of
the
collector.
L
So
this
community
and
the
community
is
in
the
community,
matches
the
left
most
as
in
the
path,
so
it
didn't
top
it
didn't
propagate.
L
Otherwise,
we
see
one
hop
to
hop
three
hops
fairly,
reasonably
good
numbers
for
the
large
community.
Next
slide,
please
extended
community
similar.
We
see
reasonably
good
numbers
for
two
three
four
hops
there's
a
large
bump
at
zero,
because
some
peers
tend
to
send
a
large
number
of
routes
with
ec.
L
Don't
know
why
so
all
these
400
5000
routes
at
zero,
they
all
come
from
one
single
as
somewhere
in
singapore,
but
what
we?
What
this
type
does
tell
us
is
that
there
is
propagation
across
like
up
to
four
five
six
hops
right
next
slide,
please!
L
L
So
here
one
thing
to
point
out
here
is:
we
are
looking
at
the
ass
that
propagate
and
about
3800
per
asses
in
all
propagate
either
rc,
lc
or
ec.
And
if
you
ask
the
question,
what
percentage
of
transit
asses
propagate
these
32
is
the
answer
and
then
22
major
isps,
propagate
rc
and
only
a
small
number,
three
or
four
propagate
lc?
L
That
may
not
be
bad
news,
because
the
the
applications
for
lc
and
dc
may
be
such
that
they
require
the
lc
to
propagate
only
to
the
tier
2
transit
provider,
or
maybe
the
tr1
transit
provider,
and
then,
after
that,
it
does
not
propagate
anymore
and
that's
why
we
don't
see
tier
1,
major
isps,
propagating
lcec,
possibly
so
jeff
haas
commented
to
me
in
an
email
earlier
that
you
need
to
look
at
the
application,
some
kind
of
a
catalog
of
of
applications
and
what
kind
of
transition
they
require
and
then
do
the
measurements
against
the
knowledge,
a
knowledge
base
of
applications
for
these,
and
we
can
try
to
attempt
to
do
that.
L
So
this
is,
these
results
are
similar
to
what
are
in
this
stri
belt
paper.
Regular
communities
propagate
also
quite
substantially
over
over
many
apps
ops,
next
slide,
two
more
slides
so
so
for
the
black
hole
community.
The
the
brown
curve
shows
the
number
of
hops
to
the
rtbh
provider.
The
blue
curve
shows
the
number
of
hops
end
to
end
that
the
black
black
hole
community
propagates,
the
average
of
the
of
the
number
of
hops
to
rtbh
provider,
is
about
three.
L
The
average
of
the
number
of
hops
to
the
for
the
total
propagation
end
to
end
is
about
five.
So
there's
a
difference
difference
of
two,
so
it
should
not
propagate
behind
beyond
the
rtbh,
but
it
seems
to
propagate
or
yeah
continue
propagating
next
slide.
Please.
L
Now
here
we
are
showing
the
top
25
asas
that
propagate
any
of
these
communities.
So
it's
a
ranking
of
ass,
based
on
how
many
rc,
lc
or
ec
they
propagate
and
in
the
rc
clay
case,
more
than
half
of
the
top
top
25
are
tier.
One
ass
right
continue
next
slide.
L
L
Considering
this
questions
for
the
working
group
are
what
are
working
group
thoughts
on
support
for
use
of
lcec
in
applications
drafts
where
transitivity
is
needed,
would
the
working
group
make
any
new
recommendations
for
operators
concerning
handling
of
lcec
yeah?
Thank
you.
I
can
stop
there
and
take
questions.
I
Can
you
hear
me
now
yeah
good
detroit's
meet
echo,
so
the
what
your
slides
have
proven
is
that
we're
actually
seeing
stuff
being
passed
around
in
transitive
fashion,
so
that's
partially
what
you're
trying
to
answer
for
your
application?
L
That's
it
yeah,
okay,
so
yeah,
so
I
mean
your
comment
to
me
in
the
email.
I
think
it's
along
those
lines.
L
List
of
I
mean
a
compilation
of
applications
that
use
eclc
and
then
do
the
measurements
against
those,
so
that
that
will
give
us
an
additional,
better
picture
as
well.
L
K
Hi
in
some
discussions
I
raised
the
the
consideration
of
what
hygiene
should
be
applied
to
what
you
are
announcing.
K
K
Well,
okay,
spreading
unknown
viruses,
because
you
are
not
applying
a
mask
where
you
do
not
know.
What
you
are
doing
quite
obviously
is
something
that
does
not
match
with
the
concept
of
being
responsible
for
what
you
are
doing.
K
M
Hello,
I
will
try
to
be
super
duper
quick.
So
let's
go
to
next
slide,
please
just
to
recap:
what
we
have
in
this
draft
is
that
not
all
bmp
message
types
do
support
tlvs
in
the
you
know,
original
design,
so
root,
monitoring
and
peer
down
were
left
out,
and
with
this
draft
we
are
trying
to
add,
you
know,
tlp
support
for
those
and
contextually.
We
bump
the
version
to
version
four
for
backward
compatibility
next
slide,
please.
M
First,
fifth,
version
of
the
draft
was
submitted
earlier
today,
very
sorry
for
the
last
minute
thing,
but
there
is
totally
no
drama
going
on,
so
the
previous
version
expired.
We
so
refreshed.
Just
you
know
the
we
bumped
the
version.
We
incorporated
a
very
useful
comment
from
jeff,
where
he
was
saying
that
we
have
generic
tlvs
and
indexed
tlvs
and
the
indexes
the
tlds
apply
only
to
root
monitoring
messages
right.
So
thanks
jeff
for
the
input,
it
was
very
valuable.
M
Also,
we
had
one
of
our
quotas,
hank
smith,
that
here
he
asked
to
be
removed,
since
he
has
a
new
employer,
and
so
he
didn't
want
to
be
associated
with
this
draft
anymore.
Next
slide.
Please
so
a
recap
of
what
I
just
said
like
we
have
jerich
and
indexed
tlbs
right,
so
one
and
two,
so
you
can
clearly
see
the
difference
between
the
two.
M
It's
super
duper
simple,
so
the
first
is
just
the
tlv
and
then
the
second
is
a
tlv
where,
where
sandwiched
between
length
and
value,
you
have
these
two
octets
of
an
index
right.
The
purpose
is
to
have
these
index
tlds
as
part
of
the
root
monitoring
messages,
so
that
you
can
address
one
specific
nlri,
which
is
included
in
a
bgp
update
message
carried
by
the
root
monitoring
message
next
and
last
slide
please.
M
So
we
are
doing
a
little
bit
of
preparations
for
next
version.
So
if
you
read
the
current
text
of
the
version
5,
you
see
that
root
monitoring
message
can
contain
both
generic
and.
I
M
Plvs
right,
why
is
that?
It's?
The
reason
is
very
valid.
It's
because
you
want
to
address
something
for
the
whole
bgp
update
message
like
this.
A
bgp
update
message
is
packed
with
the
ad
pad.
Okay,
and
maybe
you
want
to
address
some
a
characteristic
of
the
specific
nlri
reasons
for
that
may
appear
in
other
drafts
that
use
tlvs
like
the
bmp
pod
marking,
okay.
So
what
is
the
problem?
M
Is
that
auto
parsing
is
broken
by
allowing
both
generic
and
indexed
tlvs,
because
then
a
parser
would
need
to
know
would
need
a
specific
knowledge
and
know
which
tlvs
are
generic
and
which
one
are
indexed?
Okay.
So
let's
try
to
fix
it.
So
two
options
proposed
that
we
could
think
of
so
we
only
allow
indexed
the
tlbs
and
we
give
semantic
meaning
to
index
zero
where
we
say
that
index
zero
applies
to
the
whole
bgp
message
and
of
course,
if
we
don't
like
the
index
zero,
it
could
be.
M
You
know
all
ones,
for
example,
maybe
because
there
are
already
implementations
counting
from
zero.
But
let's
say
we
give
semantic
value
to
one
specific
index
and
we
say
that
applies
to
the
whole
bgp
message
and
then
all
the
others
means
that
it
applies
to
specific
nlri
and
the
other
would
be
to
go
another
way,
which
is
you
know.
We
either
have
a
specific
flag
space
or
something
like
that.
You
know
carved
into
the
tlv
type
field,
but
the
thing
is
that
you
know
if
you
go
with
flags.
M
Let's
remember
we
have
already
another
draft
that
wants
to
add
a
flag,
the
ebit
flag,
the
enterprise
bit
flag
and
so
having
flags
carved
out
of
a
tlv
type.
You
know
it
gets
very
clumsy
how
you
pack
stuff
you
get
very
variable
land.
It
could
be
a
little
bit
messy
so
boxed
in
red.
We
have
you
know
what
we
think
is
you
know
the
best
solution.
M
It's
maybe
not.
You
know
the
best
design,
but
you
know
it's
simple.
It
achieves
what
we
want,
and
you
know
I
don't
really
see
drawbacks
we
with
that
right.
So
it's
definitely
not
the
most
beautiful
design,
but
you
know
it
it's
functional.
M
A
A
Going
once,
how
are
you
on
running
code
with
bmp
tlv,
paulo
and
team.
M
So
we
have
already
running
code
with
huawei
devices
exporting
tlvs
and
pmsct
receiving
them.
We
have
also
a
prototype
made
with
scopy,
which
is
something
to
craft
in
packets,
let's
say
and
that's
it
and
that's
working
up
to
version
five
and,
of
course,
with
version
six.
If
we
go
to
only
indexed
tlds,
then
this
has
to
be
changed.