►
From YouTube: IETF109-GROW-20201117-0900
Description
GROW meeting session at IETF109
2020/11/17 0900
https://datatracker.ietf.org/meeting/109/proceedings/
C
D
D
All
right
so
about
a
minute
we
can
probably
get
started.
We
have
maybe.
D
Again,
all
right,
we
have,
I
think,
five
for
six
percent
six
presenters,
something
like
that.
It
would
be
great
if
the
presenters
could
first
before
we
get
going
too
far
along
decide
whether
or
not
they
can
actually
make
their
microphone
and
presentation
work.
We
can.
I
think
I
have
all
the
presentations,
so
we
can
run
the
presentations
for
you.
D
C
H
I
I
D
D
Okay,
all
right,
so,
let's
back
up
in
the
slides,
hello,
you're
in
bangkok,
it's
or
at
least
bangkok
time,
it's
the
girl
working
group
at
itf
109.
If
you
are
in
the
wrong
room,
you
probably
should
change,
but
this
one
could
also
be
fun.
D
D
D
D
We're
to
need
somebody
to
take
some
minutes
just
to
take
the
notes.
D
Okay,
so
do
that
and
then
the
jabra
scribe.
I
guess
I
think
john
scutter
said
that
we
could
just
use
the
existing
chat
thing
to
do
that,
so
that
was
in
the
last
meeting.
I
was
in
with
him,
so
we'll
just
do
that:
okay
right,
there's,
not
really
any
rehash
or
agenda
bashing.
If
there's
things
we
have
a,
I
think
a
two
hour
slot.
So
if
there's
things
that
we
need
to
talk
about
after
these
six
presenters
after
an
hour,
we
can
certainly
take
time
to
do
that.
D
D
C
C
It
was
quickly
adopted,
and
it's
relatively
straightforward.
However,
there
we
need
to
get
it
right,
because
the
idea
is
to
provide
some
guidance
to
the
community.
C
A
lot
of
authors
on
this,
I'm
not
sure
if
anybody
else
is
on
this
call,
but
we
just
wanted
to
just
give
an
update
for
those
that
are
not
familiar
with
this
work.
We
wanted
to
make
you
familiar
with
it
and
get
some
of
your
feedback.
C
So
the
background
is
back
in
nanog79,
doug
midori
presented
a
some
information
on
as
path
prepending
and
the
problems
that
have
come
from
it
and
participants
asked
if
there
was
any
sort
of
a
bcp
in
ietf
or
any
other
sdo,
and
the
answer
was
no,
and
so
we
decided
that
it
would
be
good
idea
to
to
do
so.
The
itf
should
have
a
position
on
this,
and
this
working
group
agreed,
and
so
the
problem
is
that
excessive
as
path
pre-painting
has
caused
routing
issues
on
the
internet.
C
It
can
cause
routing
issues
on
the
internet,
and
so
our
objective
is
to
provide
guidance
to
the
internet
community
with
how
best
to
utilize
as
path
pre-pending
in
order
to
avoid
negatively
affecting
the
internet
to
offer
offer
alternatives.
The
challenge
here
is
to
decide
in
this
draft
if
we
want
to
encourage
or
discourage
as
path
prepending,
if
we
discourage
it
offer
some
alternatives,
people
are
using
it,
so
we
need
to
be
careful
not
to
to
negatively
attack
it,
so
it
we
need
to
just
you
know.
C
Some
thought
that
we
should
just
say
it
how
it
is
and
just
call
people
out
for
what
they've
done,
but
generally
the
the
feeling
is
that
we
shouldn't,
and
so
we
haven't,
although
we
do
point
two
urls,
including
yours,
jeff
and
doug's,
and
you
can
easily
find
some
real
world
examples
that
we
generically
refer
to
there's
a
variety
of
use
cases,
variety
of
reasons,
people
use
afas
path,
prepending,
some
of
those
are
included
here.
C
Maybe
we
didn't
include
all
of
them,
preferring
one
isp
or
another
isp,
one
asbr
over
another
asbr,
utilizing
one
path
exclusively
and
another
as
a
backup
signaling
to
indicate
that
one
path
may
have
a
different
amount
of
capacity
than
another
and
in
some
cases,
isps
don't
accept
traffic
engineering
using
communities,
and
so
it's
felt
that
prepending
is
the
only
option,
and
so
we've
mentioned
those
in
the
draft.
C
We
mentioned
a
few
problems
where
using
s
path,
prepending,
it
negatively
impacts
the
internet,
including
things
like
an
attacker
wanting
to
manipulate
traffic
to
a
prefix
and
list
some
shady
data
center
to
make
that
same
announcement
with
a
shorter,
the
same
prefix
with
a
fabricated
shorter
as
path
and
that
malicious
route
would
be
preferred
if
rpki
wasn't
being
used
during
a
routing
leak.
You
know
one
in
one
country
could
have
routes
that
are
elite
and
it
could
be
just.
C
It
was
a
mistake
not
maliciously,
and
those
are
preferred
because
in
other
countries,
prefixes
are
being
announced
with
excessively
prepended
paths,
and
so
the
illegitimate
route
would
be
preferred
over
the
legitimate
route,
and
it
can
also
cause
problems
with
platforms.
Memory
usage
by
bgb
speakers,
particularly
where
asps
are
included
in
netflow
messages.
C
We
do
offer
some
alternatives
to
as
path
prepend.
If
that's
the
route
that
we
need
to
go
and
we
probably
need
to-
or
we
do
need
to
make
this
more
robust
and
maybe
offer
some
other
alternatives
using
predefined
communities
that
are
mapped
to
particular
behavior-
is
one
alternative
or
that's
allowed
and
where
an
isp
provides
that
support,
announce
more
specific
routes
on
the
preferred
path.
If
that's
also
supported,
you
can
also
use
origin
codes
when,
as
pass
or
equivalent
length,
you
can
advertise
paths
with
an
origin
where
you
can
have
one
path
preferred
over
another.
C
And
this
is
probably
the
most
important,
I'm
guessing
part
of
the
the
draft
that
we
need
to
further
develop,
and
this
is
probably
where
maybe
most
of
the
discussion
will
take
place,
but
we
in
the
draft.
What
we
currently
say
is
that
network
operators
should
ensure
pre-painting
is
absolutely
necessary,
because
many
networks
have
excessive
pre-pending.
C
We
use
some
of
doug's
information
that
he's
done
and
to
state
that
there's
no
need
to
prepare
more
than
five
pre-pen
more
than
five
asses.
I
think
in
jeff's
paper
on
ap
nick
also.
I
think
they
would
also
agree
with
that,
and
we
include
a
diagram
that
shows
that
ninety
percent
of
the
aspas
lanes
are
five
asns
or
fewer
in
length,
and
that's
so
that's
why
we
say
that
and
some
people
you
know,
do
20
30
or
more
asp
path.
Pre-Pens,
of
course,
don't
pre-paint.
C
The
s
ends
that
you
don't
own
pre-pending
to
all
like.
If
you
have
multiple
providers
and
you're
just
preparing
to
all
of
them.
Maybe
you've
done
that
because
you
had
you
were
perpending
to
one
and
not
to
another,
but
you
discontinued
one
link
and
you
just
continued
to
prepend
on
the
one
link
that
you
still
have
active.
C
C
So
that's
kind
of
a
quick
run
through
we
again.
Thank
you
for
all
your
comments.
It's
been
good.
We
at
the
very
initial
stages
of
this.
We
need
to
make
sure
that
we
get
this
right,
because
we
think
that
the
itef
should
have
a
clear
recommendation
to
the
community
and
if
we
have
time
for
questions,
let's
take
them.
K
I
start
myself
in
the
queue
but
as
there's
been
no
no
thing
I'll
just
start
anyway,
I'm
jeff
houston
I'd
actually
like
to
see
a
bit
more
practical
advice
in
this.
You
talk
about
at
some
section.
You
know
if
you
have
to
prepare
and
do
so
carefully,
but
you
know,
perhaps
what
she
might
also
know
is
a
best
practice
is
actually
what
you
should
do
is
actually
enumerate
what
your
routing
policies
are
intended
to
achieve
before
you
even
go
down
the
prepending
path.
In
other
words,
the
operator
really
should
understand.
K
K
K
C
Thank
you
for
your
document
that
we've
referenced.
It's
been
very
helpful
to
us
so
yeah.
If
there's
no
more
questions
chris,
then
we're
just
going
to
continue
to
develop
this
and
we'll
send
it
to
the
list
and
please
pay
particular
attention
to
the
recommendations,
because
we
want
to
make
sure
that
we're
all
in
agreement
on
those
thanks.
D
H
Good,
okay,
great
so
good.
Today,
I'm
thomas
gough
from
swisscom,
I'm
presenting
the
bnp
young
project
on
the
virtual
hackathon
itf-109
for
the
growing
netconf
working
group.
H
In
this
hackathon
in
regards
of
bmp
we're
focusing
on
this
bmp
draft,
where
we
also
see
later
some
presentations
in
this
working
group,
but
also
also
regarding
ipfix
and
bgp
local
rip
correlation
with
iphix
identity,
90
and
as
well.
We
were
also
testing
performance
impact
of
pnp
in
terms
of
cpu
and
energy
resources
on
the
route
processor.
H
H
So
this
time
new,
this
is
the
fourth
time
in
the
itf
hackathon.
We
added
some
more
different
type
of
vendors,
so
maybe
this
is
cryo
6r,
xc,
juniper
noise
and
also
f4
mounting
an
open
source
routing
system,
all
of
them
exposing
ibfx
and
bmp.
H
H
This
is
currently
working
progress
on
the
data
collection
site
on
pmact,
the
decoding
of
the
bmptlds,
namely
on
our
policy
attribute,
tracing
and
emp
path,
marking
continued.
We
have
now
pretty
good
coverage
there
and
also
some
extensions
in
device
of
correlating
egb,
location
and
iphix
has
been
done
and
as
well
on
the
udp
notif
data
collection.
H
This
is
just
an
example
on
the
time
series
database
regarding
empire
policy
attribute
tracing.
You
can
see
here
on
screenshots
from
an
apple
sp
router,
basically
for
given
ethics
in
a
birth
through
which
birth
down
policy
and
also
type
of
policy.
H
This
prefix
has
been
propagated
through
here,
another
example
of
egyptian
local
ipfix
correlation,
showing
basically
on
the
pe
about
the
test
flow
being
successfully
correlated
with
bgp
standard
communities.
H
H
On
the
huawei
vlp
site,
the
support
of
path
marking
and
our
policy
attribute
racing
has
been
extended
and
adopted
to
the
latest
releases
as
well.
The
coverage
on
europe
no
different
distributor
for
the
young
push
data
collection.
H
This
is
an
example
for
two
data
sets
where
we
were
interesting
hundred
thousand
and
five
hundred
thousand
rounds
to
see
the
impact
on
cp
usage,
as
expected,
since
the
bgp
propagation
has
impact
on
the
cpu
usage,
the
cpu
usage
increased,
but
due
to
the
back
pressure
mechanism
of
the
bgp
to
bmp
implementation
within
the
bgp
process,
almost
or
the
the
memory
increase
is
very
minimal.
H
On
the
wireshark
on
the
desector
side,
the
work
is
currently
ongoing
to
also
support
the
path
marking
tlv
and
the
udp
notif
implementation.
So
we
are
looking
very
forward
within
the
next
one
or
two
weeks.
You
have
that
one
and
done
as
well
what
we
learned
in
the
hacker
tom
yeah,
it's
the
fourth
time,
so
the
team's
getting
really
worked
nicely
together.
H
I
want
to
thank
all
the
people
who
were
within
the
group
is
alexis
dolly
from
vaya
shark.
We
had
many
people
joining
from
inside
the
university
siena
and
sang,
and
also,
of
course,
huawei
ndt
and
some
from
swisscom.
D
D
All
right,
I
guess
no
question
is
vivio
around
and
do
you
want
to
do
your
own
presentation
or.
H
So
if
you
quickly
look
at
the
bgp
protocol
which
bmp
monitors,
then
essentially
we
have
two
different
entities.
We
have
rips
so-called
routing
information
basis,
which
is
just
a
list
of
prefixes
with
attached
attributes
and
an
example
of
this
is
a
pgp
update
message
that
can
be
seen
on
the
right
side.
Now
we
have
so-called
route
policies
which
operate
on
the
routes,
so
they
can
modify,
drop.
H
H
If
you
wanted
to
know
what
routes
are
actually
installed,
independent
of
the
bgp
peering,
we
enabled
access
to
the
local
rip,
and
this
is
also
so,
if
you,
if
you
imagine
that
a
bgpp
receives
hundreds
of
thousands
of
updates,
but
only
a
tiny
subset
of
them
actually
modify
the
forwarding
state
of
the
router.
It
makes
it's
a
big
efficiency
game
if
you
just
monitor
the
local
rip,
but
monitoring
the
low
grip
also
enables
certain
correlations
that
were
not
possible
without
it.
H
That's
the
case
in
mpls
vpn
network,
and
sometimes
there
are
multiple
paths
for
a
prefix.
For
example,
if
you
have
a
network
that
is
built
with
redundancy
in
mind
and
there,
the
goal
is
to
have
an
additional
path,
marking
draft,
where
you
can
see.
Okay,
this
path
for
this
prefix
is
the
primary
path.
This
password
is
a
backup
pass,
so
we
can
see
the
redundancy
throughout
the
network
and,
as
a
last
step,
we
enabled
access
to
route
policies
where
we
can
see
which
policies
were
triggered
and
which
modified
routes
and
how.
H
And
what
we
have
is
that
if
multiple
vpns
want
to
share
the
same
prefix,
which
should
be
possible,
then
we
need
a
way
to
sort
of
distinguish
them.
H
If
you
want
to
do
a
correlation
on
the
vpn
level
and
as
has
been
shown
by
thomas
in
his
previous
presentation,
this
is
the
lab
network
that
we
tried
to
experiment
with
bmp.
We
have
a
couple
of
beer
artists
in
the
middle
row.
Then
we
have
multiple
vendors,
cisco
who
are
by
juniper,
and
we
even
use
f
for
routing.
As
c
routers.
We
have
a
route
reflection.
We
have
spyron
for
traffic
generation.
H
Now
we
wanted
to
do
here
is
that
we
first
wanted
to
export
the
data,
so
we
had
to
specify
which
trips
and
which
address
families
is
obviously
vendor-specific.
Then
we
use
the
collection,
software
pmact,
which
we
are
previous
as
well,
and
there
was
there.
The
route
distinguisher
that
we
just
mentioned
before
was
used
to
correlate
ipfix
and
bnp
message.
So
in
the.
C
H
We
want
to
achieve
a
correlation
in
this
type
of
network
that
I
showed
on
a
vpn
level
under
time
across
the
two
planes
to
make
cause
and
effect
visible
so
on.
The
bottom
is
the
screenshot
of
the
application,
where
we
see
on
the
left
side
the
control
plane
with
different
filters
for
standard
communities
which,
as
I
said,
encode
vpn
information,
rip,
selection
and
also
timestamps,
and
if
you
just
want
to
look
at
an
example
query.
Let's
say
we
have
a
query
where
we
say
for
a
specific
vpn
show
me
a
certain
rip.
H
For
example,
the
chase
ribbon
pre-policy
and
its
correlation
to
the
forwarding
plane
and
the
events
that
we're
interested
in
is
just
enabling
so
removing
and
enabling
an
interface
on
a
vpn
level.
So,
on
the
left
hand,
side
we
have
removing
of
the
interface.
So
as
soon
as
we
take
the
interface
down,
we
have
pgp
updates
propagating
through
the
network,
which
are
then
exported
with
bmp.
H
Now
we
can
see
here.
On
the
left
hand,
side
is
the
control
plane
graph
where
the
nodes
or
the
vertices
are
just
the
loopback
addresses
of
the
routers
and
the
edges
are
the
next
tops
and
we
use
prefix
here
as
an
aggregated
form,
because
there
are
multiple
prefixes
that
can
have
the
same
next
top
and
the
edges
are
color
coded
and
red
means
that
which
we
just
withdraw
message,
and
the
interesting
thing
is
that
for
one
this
is
on
a
vpn
level
and
on
the
other
hand,
which
is
correlating
time.
We
have
this
vertical
bar.
H
That
shows
where,
in
the
forwarding
plane,
this
event
actually
happened
and
because
we
used
or
we
disabled
an
interface
that
was
generating
traffic,
we
can
see
that
the
traffic
broke
down.
At
the
same
time,
and
after
a
couple
minutes,
we
re-enabled
it
again,
and
here
the
caller
is
screen.
That
means
we
have
a
pgp
update
message
that
was
captured
with
bmp,
and
then
the
traffic
pattern
went
back
to
normal,
and
so
this
is
just
a
toy
example.
This
just
shows
that
what
kind
of
information
that
we
can
get
out
of
it.
H
So,
if
you're
interested
in
this
kind
of
event,
we
can
dig
a
little
deeper.
For
example,
you
can
see
okay,
let
me
change
the
the
rip
on
the
left-hand
side.
Now
we
have
the
adjacent
strip
out
for
exactly
this
event,
for
enabling
the
interface
and
here
again
the
nodes,
are
the
loopback
addresses
of
the
routers.
H
The
edges
are
the
next
hops
and
we
have
additional
fields
that
when
we
click
on
the
edges
that
we
can
see
the
prefixes
that
had
this
specific
prip
and
bgp
next
up
tuple
and
on
the
right
hand,
side.
We
have
the
route
policies
that
were
mentioned
in
previous
presentations
as
well,
and
this
is
essentially
a
bipartite
graph
with
the
bmp
routers
that
exported
the
bmp
data
in
one
set
and
the
route
policies
in
another
set
and
the
edge
label
is
appearing
over
which
that
route
policy
is
triggered.
H
And
let's
say,
if
you're
interested
in
more
information,
then
we
can
just
click
on
a
certain
vertex,
for
example,
this
one
up
here
and
then
we
have
a
an
additional
additional
information,
for
example,
policy
class.
This
route
policy
corresponding
to
whether
the
route
policy
was
matched
whether
the
route
was
permitted
and
so
on,
how
we
even
included
an
an
additional
text
field
where
we
actually
use
an
rpc
call
with
with
netconf
young,
where
we
called
or
queried
the
router
directly
for
its
route
policy
and
as
a
maybe,
to
conclude
it's
just
a
toy
example.
H
D
D
F
Yes,
let
me
try
that
I'm
technology
is
one
of
my
weak
points,
so.
J
F
F
J
F
F
F
F
Fantastic
fantastic.
I
cannot
see
the
I
can
see
only
my
presentation,
okay,
so
very
quickly,
two
updates
on
the
tlv
draft
and
on
the
tlv
ebit
draft.
F
So
I
start
from
the
tlv1
we,
you
know
problem
statement
of
the
tlv,
just
as
a
super
quick
recap
like
extend
support
for
tlv's
to
all
bmp
messages,
so
cover
specifically
with
monitoring
and
peer
down,
and
in
order
to
achieve
that,
we
bump
the
version
for
backwards
compatibility
and
so
what
happens
since
igf-106,
since
we
didn't
present
at
107
and
108,
it's
that
we
had
two
new
versions:
the
three
and
four
so
just
for
historical.
F
F
So,
of
course
we
didn't
want
to
be
just
positional,
like
you
know,
basing
on
some
sort
of
ordering
of
the
tlps,
because
that
can
be
very
easily
screwed
up.
So,
for
just
for
a
little
bit
of
history,
something
that
we
never
presented-
and
you
know
we
already
deemed.
C
F
Destruction
of
a
few
months,
our
first
attempt
went
to
go
for.
Let
me
let
me
call
them
tlv
containers
to
achieve
that.
Tlb
containers
would
be
like
that.
You
have
a
tlv,
for
example,
let's
say
for
pot
marking
and
then
inside
that
tlv
you
have
some
tlvs
right
so
and
the
subtle
this
would
be
just
ordered.
You
know,
specifically
the
way
in
which
you
want
to
you
know
the
the
first
dlv
would
be
matching
the
first.
You
know
angular
I
and
things
like
that.
F
This
method,
you
know
we
deleted
it
from
history
because,
let's
say
it
was
bringing
you
know
some
disadvantages.
It
was
a
little
bit
complex.
Also
you
have
the
problem
when
you
don't
want
to
attach
a
tlb
to
a
specific,
a
specific
angular.
I
like
you,
have,
I
don't
know
three
four
five
rise
and
you
want
to
attach
it
tlb
only
to
the
first
and
to
the
third
and
to
the
fourth.
So
it
was
come
becoming
a
little
bit
clutchy.
You
can
have
null
tlvs,
but
it
was
bad.
F
So
we
restored
a
little
bit
of
simplicity
in
the
whole
thing,
and
so
in
version
4,
which
was
published
just
yesterday.
We
have
indexed
what
we
call
indexed
tlds.
So
essentially
it's
just
a
super
normal
tlb.
It's
just
that
the
very
first
value,
the
first
two
bytes
of
the
value
it's
the
index,
so
the
index
starts
at
zero,
so
the
index
zero
would
be
for
the
first
tlb
and
and
so
forth,
super
cool.
F
For
the
moment
we
are
leaving
to
the
let's
say
to
the
specific
application
you
know
so
the
index
tlv
would
be
like
a
recommendation.
Let's
say
like
how
to
encode.
You
know
per
nlri
dlvs
and
it's
left
to
the
specific.
F
For
the
moment,
it's
left
to
the
specific
application,
the
knowledge
that
you
know
there
will
be
an
indexes,
so
the
the
tlp
it's
indexed
or
it's
per
nlri.
In
other
words,
we
are
not
adding
a
flag
or
anything
like
that
to
say
that
the
specific
nlri
is
indexed
right.
We
may
think
about
that.
F
F
You
know
experience
where
you
know
you
have
this
tlb
kind
of
protocol,
where
everything
auto
parses
very
nicely
so
be
able
to
have
you
know
a
flag
for
something
would
be
nice,
but
you
know
we
are
open
for
feedback
and
on
that
other
changes
we
added
the
operational
considerations
section,
which
is
largely
based
on
jeff,
has
feedback
thanks
very
much
jeff
for
your
feedback
and
there
were
minor
editorial
changes.
F
I
present
also
this
and
maybe
then
we
can
do
questions
at
the
end
if
there
is
any
so
on
the
ebit
side
of
the
things.
What
is
the
you
know
problem
statement?
I
I
will
actually
kind
of
skip
the
ebit
problem
statement,
because
there
was,
you
know,
a
quite
a
large
recap
on
the
mailing
list
on
what
this
is
about.
So
you
see
here,
you
know
the
problem
statement
mentioned
in
the
draft,
but
we
went
also
through
you
know
some
other
possible.
F
They.
It
emerged
on
the
mailing
list,
a
few
other
possible
use
cases
for
this
draft
right,
and
so
what
is
the
status
and
next
steps?
And
this
is
my
last
slide,
so
there
is
not
really
many
open
questions
since
you
know
there
was
not
much
feedback
to
this
draft.
A
couple
of
weeks
ago,
I
sent
an
email
with
a
little
bit
of
a
recap
and
asking
a
little
bit
for
support,
not
support,
and
things
like
that.
I
think
we
received
some.
F
You
know
positive
feedback,
so
definitely
positive
feedback,
no
negative
feedback
and
the
actual
feedback
is
going
to
be
processed.
That
there
was
quite
some
suggestions
from
thomas
graf.
Thank
you,
thomas
for
that,
and
you
know
question
for
the
chairs
like.
Shall
we
go
for
adoption
for
this
draft
and,
as
always,
I
hope
we
have
an
exit,
zero.
D
A
D
I
I
Okay,
so
I'm
going
to
start
so
I'm
yunnan
from
huawei,
and
it's
actually
been
a
year
since
I
presented
this
draft
at
itf
106..
I
I
You
know
status
of
this
draft
and
also
I
would
like
to
discuss
with
the
working
group
how
we
can
like
take
this
draft
one
step
further,
so
first
I'll
I'll
quickly,
recap
you,
with
the
hacksaw
example
that
we
have
for
this
feature
and
then
we're
going
to
look
at
the
latest
status
of
the
format
and
then
we'll
discuss
the
next
steps.
I
Okay,
so
in
a
nutshell,
what
this
draft
is
does
is
that
it
basically
records
the
processing,
the
root
policy
processing
in
the
device
and
then
encapsulate
the
root
policy
processing
data
with
bmp
and
also
export
the
data
using
a
new
bmp
message.
I
So
in
this
figure
you
can
see
in
the
in
the
left
column,
there
are
different
data
data
fields.
These
are
the
raw
data
fields
that
you
catch
from
the
bmp
retrace
message
and
then
in
the
right
part,
what
you
can
do
is
like.
Basically,
you
drag,
you
know
different
data
fields
to
either
the
filtering
column
or
the
show
column,
okay.
I
So,
for
example,
in
this
example,
we
want
to
show
you
in
the
last
five
minutes
what
this
.71
router
is
doing
under
a
certain
vrf
indicated
indicated
by
this
rd
and
then
in
the
show
column.
Basically,
you
can
select
different
fields
to
structurize
the
data,
to
the
way
that
you
want
to
viralize
the
data.
So
here
we
sorry
so
here
we
showed
three
data
fields.
The
first
is
the
brf
name
and
then
the
policy
class,
and
also
the
policy
name
so
for
this
router
under
the
vrf
c20.
I
Basically,
we
can
see
here
we
have
four
types
of
policies:
the
inbound
policy,
the
vrf
export
and
the
root
withdrawal
and
outbound
policy,
and
we
can
also
see
that,
under
each
policy
class
under
a
a
specific
root
policy
name,
how
many
events
is
going
on?
Okay
and
for
those
names
with
with
an
r.
It
basically
means
the
policy
either
either.
The
policy
is
not
configured
under
a
specific
group
policy
or
you
know
the
route
is
processed.
You
know
by
some
default
configurations.
I
So
next
we
wanna
zoom
into
this
two
events.
I
So
what
we
can
see
from
the
the
raw
data
parsed
is
that
it's
actually
two
two
prefixes
dot
ten
and
dot
252,
which
are
received
from
the
same
bgp
peer
and
they
are
processed
by
the
inbound
policy
and
the
policy
is
a
match
and
the
match
result
is
to
permit
the
policy
and
then
this
policies,
div
field,
tells
you
whether
the
bgp
attributes
before
the
policy
and
after
the
policy
is
different.
So
if
it's
one,
then
it
basically
means
it's
different.
I
So
to
look
at
the
the
the
detailed
difference
you
you
want
to
go
to
the
pre-policy
attributes
and
the
post
policy
attribute,
but
here
we
didn't
actually
fully
parse
the
two
fields,
but
once
you
do,
you
can
see
the
difference?
Okay,
so
that
finished
the
the
quick
recap-
and
this
is
the
latest
format
that
we
have
for
the
root
trace.
I
In
fact,
from
the
zero
three
and
the
row
four
version,
we
didn't
make
very
big
changes
to
the
format,
just
minor
ones,
and
also
I
I
want
to
talk
about
the
details
of
the
formats.
Instead,
I
want
to
discuss
something
else
with
you,
so
I'll
just
go
ahead
and
skip,
and
this
is
the
changes
from
the
last
version.
Okay,
and
so
a
big
thing
that
I
want
to
discuss
with
the
working
group
today,
is
that
how
can
we
move
this
work
forward?
I
And
before
that,
I
want
to
update
you
with
the
current
implementation
status
of
the
of
the
draft
and
also
some
deployment
status
and
future
plans?
Okay,
so
we
have
now
a
huawei
vrp
latest
version
that
supports
the
latest
draft
as
a
bmp
client,
and
we
have
pmact
that
supports
the
latest
version
draft
as
the
bmp
server,
and
we
also
have
wildshark
that
supports
the
parsing
okay
and
for
deployment.
I
We
have
been
testing
this
feature
in
the
swisscom
test
lab
for
almost
for
over
a
year
and
for
actual
deployment
in
in
the
production
network.
What
the
information
I
have
here
is
that
first
it
there
could
be
plans
in
the
tension
network.
Actually,
this
draft
is
also
a
requirement
from
the
tencent
and
who
is
also
one
of
the
co-authors,
and
the
second
is
the
new
ixp
in
china.
I
Luckily,
I
was
involved
involved
in
this
ixp
project
since
this
I
think
this
year
may
and
I've
been
introduced
since
feature
to
them
they
are
pretty
interested,
but
for
the
exact
you
know,
deployment
plan
I
I
currently
don't
have
and
also
for
hoy
cloud.
They
also
have
plans
to
deploy
this
feature.
I
Okay,
so
with
you
know
these
things
going
on
what
I
I
want
to
ask
from
the
working
group
and
also
the
chairs,
is
that,
shall
we
consider
the
adoption
of
this
draft
as
a
working
group
document
and
also
we
would
like
earlier
allocations
for
the
following
code
points,
because
we
are
going
to
deploy
the
feature
in
actual
networks
unless
that's
a
plan,
but
I
do
understand
there
are
still
concerns
and
maybe
even
big
concerns
from
the
working
group
and
I'm
I.
I
I
would
really
like
to
discuss
these
concerns.
L
Hi
jeff
ask:
wasn't
it
the
case
at
some
point,
we
talked
about
changing
the
registration
policy
for
the
bmp
message
types.
I
I
think
the
real
issue
here
is
that
we
don't
have
any
first
come
first
serve,
and
this
is
a
good
candidate
for
that.
D
E
L
It
is
currently
still
half
the
code.
Points
are
standards,
action,
the
other
half
or
specification
required.
L
L
So
not
speaking
for
the
chairs
of
this
group,
my
memory
of
specification
required
is
that
a
internet
draft
is
present
and
it
doesn't
even
necessarily
have
to
be
an
internet
draft.
You
could
actually
do
standards
in
another
organization
and
just
simply
say
this
is
where
it's
specified
at.
E
Specification
required
is
weird,
I
don't
remember
the
details,
but
I
think
it's
it's.
It
may
not
work
the
way
you
said,
but
standards
action
certainly
can
you
can
get
an
early
allocation
and
I
don't
think
standards
allocate
standards.
Action
technically
requires
you
to
be
a
working
group
draft
which
is
kind
of
weird.
It's
it's
chairs
discretion.
E
A
M
So
so
specification
required
I'll
put
the
actual
text
in
the
chat,
but
basically
the
designated
expert
has
to
say
it
seems
mostly
sane
and
then
you
need
a
permanent
and
ready
of
a
readily
available
specification,
so
it
needs
to
be
sort
of
relatively
stable.
It's
unclear
that
an
internet
draft
is
that
if
it's
expected
that
the
format
and
protocol
will
still
be.
I
D
D
J
G
So
as
a
brief
recap,
the
idea
of
this
draft
is
that
is
to
convey
bad
status
over
airbnb,
so
bad
status
being
whether
a
path
is
installed,
whether
whether
a
path
is
not
that
so
whether
about
this
best
path,
whether
it's
the
whether
or
not
it's
not
a
best
part
where
you're
we're
still
using
it
for
forwarding,
so
we
call
that
primary,
whether
it's
a
backup
path.
So
this
kind
of
thing
did
you
mention
it
on
his
on
also
his
on
his
stock.
So
is
that
kind
of
so
the
data
could
be
useful.
G
I
guess
for
some
use
cases
it
depends
on
the
bmp
dlp
draft
and
on
the
eb
draft
two
that
paul
just
mentioned.
So
we
also
have
a
reason
field,
which
now
is
optional.
The
reason
field
could
include
stuff
like
hey.
This
path
is
best
path
because
I
don't
know,
has
higher
local
preference
stuff
like
that,
so
it
might
be
a
bit
complicated
to
for
for
every
use
case,
but
it
could
be
useful
for
troubleshooting
yeah.
We
decided
to
set
it
as
optional
now,
since
it
might
not
be
useful
every
time.
G
Okay,
as
overview
of
the
latest
changes,
so
we
didn't
show
it
for
a
while.
We
actually
have
been
iterating
over
it.
It's
very
related
to
what
paolo
mentioned
about
the
index.
So
we
have
decision
which
and
paulo
just
described
it-
that
we
could
not.
So
it
was
complicated
to
point
out
what
the
tlb
to
which
nlri
was
specifying
we
was.
It
was
referring
to.
So
we
did
some
hacking
issues.
So
not
somehow
we
did
some.
We
play
with
positions
a
bit,
but
it
was
too
complicated.
So
we
went
into
this
index
thing.
G
So
basically,
it's
a
field
numeric
field
in
which
you
you
may
you
you
define
there
to
which
prefix
on
the
bgp
update
you
this,
the
the
specific
tlb
you're
referring
to
seems
to
be
fine.
So
far,
so
we
also
implemented
a
bit
that
basically
allows
you
to.
So.
If
you
have
your
own,
I
mean
your
own
company
status
or
your
own
reasons.
G
Then
there
are
no
standardized,
then
you
can
use
that
one,
and
then
I
mean
you
can
do
any
status
you
you
wish
until
those
styles
are
properly
standardized
hopefully-
and
we
also
set
the
reason
code
now
to
be
optional,
so
it
does.
I
guess
it
doesn't
waste
time
if
you're
not
implementing
it
and
those
are
basically
the
the
main
changes
that
we
have
the
next
one
please
in
the
implementation
side,
so
we
were
doing
these
hackathons
every
every
itf.
G
Well,
I'm
not
so
much
involved,
but
the
draft
has
been
there
for
a
while,
but
we
realized
that
waiting
for
every
itf
to
let's
say
how
an
iteration
on
the
draft
between
the
router
and
the
collector
was
taking
too
long,
and
we
had
very
good
good
discussions
about
it.
G
So
we
wanted
to
have
something
quickly,
so
let's
say
quicker
iterations
about
the
the
the
messages
and
how
the
format
and
all
of
that,
so
we
ended
up,
let's
say
implementing
bmp
in
this
framework
python
framework
called
scapi,
which
is
basically
a
framework
that
allows
you
to
forge
packets,
so
we
have
kind
of
a
prototype
for
bmp.
Now
it
works.
G
So
it
includes
the
tlb,
the
dlp
options
and,
in
particular
the
path
study
option
we
made
that
work
with
the
premises
of
the
collector
and
that
allows
us
to
let's
say,
have
a
quicker
iterations.
G
Thomas
olivier
also
showed
that
we
have
been
testing
this
now.
Let's
see
more
end
to
end
between
router
and,
let's
say,
information
systems
on
the
hackathon
project,
I'm
not
going
to
mention
any
more
about
that,
but
has
been.
This
is
good
to
try
to
work
out
practically
in
an
end-to-end
environment.
The
next
one.
Please.
G
So
as
the
rest
of
the
drafts,
we,
I
I
think
we
have
enough
iterations
on
this
draft.
The
data
is
there
we,
but
status
can
be
useful
for
some
for
some
use
cases.
We
don't
have
a
way
of
conveying
that
information,
so
that's
basically
the
gist
of
the
draft.
G
L
Hi,
it's
jeff
a
quick
comment
on
the
index
hack.
I
I
think
it's
a
nice
hack,
the
I
think
major
challenge
there
is
that
it's
sort
of
assuming
that
the
receiver
is
capable
of
parsing
out
the
nlri
which,
for
cases
where
you're
using
route
monitoring
monitoring,
is
mostly
used
for
things
that
are
been
accepted
by
the
stack
and
are
able
to
be
validated
for
route
mirroring
or
something
else
similar.
G
Right
in
that
regard,
I
have
to
say
that
I
have
discussed
with
the
the
growth
elb
authors
well,
basically,
that
that
this
kind
of
infrastructure
should
should
lay
more
in
the
tlb
draft,
so
that
should
be
mandated
by
by
that,
let's
say,
general
architectural
draft
than
on
the
specific,
let's
say,
content
dlps,
because
if
every
content
dlp
does
anything
differently,
then
that
would
become
kind
of
a
mixture
but
but
yeah.
I.
D
D
E
M
Hi
thanks
for
reminding
me,
I
believe
that
the
action
item
is,
I
need
to
chat
with
alvaro
who's,
got
some
comments
or
questions
on
sort
of
making
sure
that
we're
not
overstepping
our
bounds.
I
think
there
are
also
some
comments
from
randy
on
some
definitions
and
things
like
securing
bgp
and
things
like
that,
but
yep
yeah
right.
Sorry.
D
Okay,
seeing
nothing
else,
I
suppose
see
you
in
four
months.
If
there's
something
we
need
to
talk
about
in
the
meantime,
always
please
ask
the
list:
if
the,
if
we
can
set
up
an
interim
meeting,
it's
very
easy
to
do
for
us.
We
just
need
two
weeks
or
so
notice.