►
From YouTube: IETF106-GROW-20191122-1220
Description
GROW meeting session at IETF106
2019/11/22 1220
https://datatracker.ietf.org/meeting/106/proceedings/
B
C
C
These
are
resources
relevant
to
the
working
group,
our
agendas
online,
the
materials
for
the
agenda.
We
have
a
mailing
list,
a
jabber
room-
and
this
brings
me
to
the
point
of
looking
for
a
volunteer
to
the
jabber
scribe.
So
anybody
in
the
room
able
to
connect
to
the
meet
echo
website
and
monitor,
may
the
meet
echo
jabber
room
Gordon.
Thank
you
for
your
thank
you
for
this.
We
also
need
a
Staker.
C
A
D
A
D
The
mic
in
your
hand,
it
will
not
bite.
You
speak
into
the
mic,
stand
onto
the
seven
parallel
or
sorry,
seven
perpendicular
lines,
five
of
which
are
transparent,
so
that
me
Tico,
can
see
you,
that's
it.
What
okay?
We
have
some
existing
drafts,
here's
the
status
for
them.
You
can
look
at
the
tools
page
to
delve
deeper.
If
you
prefer,
the
two
question
marks
for
adopt
is
I.
Think
we
forgot
to
send
that
to
the
IHG.
We
have
a
couple
of
things
that
are
that
are
iesg
to
send
to
the
iesg.
C
The
input
mechanism
to
this
discussion
is
higher
the
mailing
list.
We
will
not
be
taking
these
decisions
in
this
meeting,
but
yeah
check
out
the
mailing
list
reads
the
proposed
charter
and
reflects
your
thoughts
on
that.
For
those
of
you
who
don't
know
what
a
Charter
is.
A
charter
defines
the
purpose
of
the
working
group.
C
That
purpose
is
then
expressed
in
goals,
which
brings
it
slightly
closer
to
tangible
action
items
and
then,
in
terms
of
action
items,
those
are
called
milestones,
so
we
go
from
the
most
abstract,
the
Charter
to
goals
milestones
which
are
actionable
things
on
which
we
can
measure
our
performance.
Now
it
is
very
it's
a
cultural
aspect
of
ITF
wildly
deviate
from
the
milestones.
That's
okay!
We
don't
need
to
make
it
an
exhaustive
list,
but
it
is
good
for
newcomers
to
have
an
understanding
of
what
this
working
group
does.
C
E
B
A
E
E
If
this
is
the
mechanisms
of
the
TLB
draft
that
currently
in
our
growth
draft,
that
powder
will
explain
later
and
well
what
status
is
something
that
we
don't
have
right
now
and
BMP
scan
it
can
actually
be
obtained,
let's
say
implicitly
from
the
review,
source
or
I
guess
doing
some
comparison
between
ribs,
that's
complicated
that
might
change
depending
on
the
implementation.
That
I
think
is
nice
to
have
an
explicit
mechanisms
of
high
of
marking
this
this
information.
Now
we
also
have
a
recent
field
right
now.
E
It's
a
free-form
string,
we'll
discuss
that
in
a
second
or
what
how
that
can
change.
The
idea
of
the
recent
field
is
this
is
to
say
why
there's
a
certain
pad
status
for
a
path
and
well
I
mean
we
saw
it
as
a
way
of
troubleshooting,
maybe
else
for
a
specific
use
case
Oh.
What
let's
see
this
version?
Basically
has
editorial
changes,
but
we
are
thinking
of
making
a
that's
a
more
drastic
change
in
the
next
one.
Here
are
some
of
the
changes
we
might.
E
E
We
had
this
field
as
a
free
form
string,
because
we
did
not
want
to
parametrize
reasons
so,
but
status
is
actually
complex
to
parameterize,
so
finding
a
finite
set
of
states
now
a
free
form
and
now
are
reasons
that
sounds
very
daunting
so
but
well,
if
this
is
very
complex
and
I,
don't
know
what
the
spirits
of
the
group
is
with
the
BGP
shut
down
feature,
so
we
might
need
to
move
this
to
something
else,
we'll
thinking
about
it.
How
to
do
it?
E
Second,
is
the
pad
status
length
so
right
now
we
the
but
status,
is
a
bit
filled,
so
you
can
basically
mark
different
pad
status
which
allows
you
for
having
different
levels
of
granularity,
but
right
now
it's
just
two
bytes
we
might
maybe
this
becomes
very
successful
and
do
not
laugh
and,
and
so
maybe
in
the
future,
we
have
many
pad
status.
So
maybe
we
want
to
protect
the
mechanism
having
the
pad
status
being
a
variable
field.
We
would
also
think
about
it
now.
E
I
think
we
should
remove
or
we
we
have
been
discussing,
that
the
definition
of
the
actual
pad
status
is
something
that
should
not
fall
into
this
draft.
Is
it's
quite
complex,
for
instance,
multipath
you
go
and
try
to
look
for
a
document
explaining.
That
is
not
easy.
Maybe
that's
not
exist,
maybe
some
draft
here
or
there,
but
it's
not
clear
stated
so
we
might
not
have
pad
status
defined
in
the
draft,
but
hopefully
somewhere
else,
either
other
draft
or
I,
don't
know
yeah
now
or
god,
something
so
so
yeah.
E
So
we
might
have
something
some
passwords
as
examples,
but
we
do
not
plan
to
define
pad
status
in
the
draft
and
finally,
we
might
add
some
notes
on
the
optional
nature
of
this
feature.
So
the
feature
itself
is
is
optional
right,
you
don't
have
to
add
it.
If
you
don't
want,
that's
the
idea,
also
the
recent
field.
So
if
the
recent
field
at
the
the
nature
right
now
the
field
is
that
you
to
our
it?
E
If
you
don't
support
her,
if
you
don't
want
to,
but
it
may
also
fall
into
the
pot
status,
so
it
might
happen
that
we
define
many
pots
that
was
very
granular
and
an
implementation.
Don't
only
super
cell
set
of
them
and
it
may
be
feasible
that
we
somehow
either
of
line
or
some
other
way.
We
that's
fine
and-
and
that's
okay-
I
mean.
Maybe
you
don't
support
that
level
of
granularity
and
just
a
subset
of
the
pad
status?
That's
it
I
have
nothing
else
to
say.
G
So
I'm
Paula,
chant,
affirm
entity
and
I
have
four
drafts
to
present.
So
first
is
the
LA
crib
extension
of
BMP.
It's
something
relatively
old
like
starting
2017.
We
had
visibility
in
la
crêpe.
You
know
for
for
BMP,
and
you
know,
since
the
last
meeting
there
as
being
essentially
no
changes
to
the
draft,
we
may
have
only
captured
something
during
the
BMP
accattone
on
Sunday
I.
Hope
Thomas
will
have
the
time
at
the
end,
to
comment
more
on
that.
It's
more
recommendation.
You
know
small
gaps.
Maybe
it's
worth
adding
a
few
words
there.
G
Then
we
have
the
draft
about
essentially
adding
TLV
support
to
peer
down
and
route
monitoring
messages.
The
problem
statement
is,
very,
you
know,
very
simple,
like
we
have
a
table
with
four
like,
and
one
of
the
legs
is
not
equal
to
the
others,
and
so
we
want
to
make
all
the
legs
equal
right,
and
so
the
idea
is
simply
to
add
that
optional
canvas
to
route
monitoring
to
peel
down
and
we
bump
the
version
of
the
protocol
just
for
backward
compatibility
right
and
since
last
meeting
the
draft
got
adopted
by
the
working
group.
G
Thank
you
very
much.
There
have
been
only
some
minor
editorial
changes
and,
if
you
remember
my
presentation
in
Montreal,
we
did
leave
kind
of
on
purpose
under
specified
that
that
peered
down
because
appear
down
its
is
own
beast
right.
So
it's
even
more
uneven
surface
than
the
other
messages,
and
so
that
scope
that
got
scoped
a
little
bit
better
like
you
can
see
the
text
over
there.
G
Essentially,
you
have
code
one
entry,
there
is
a
BGP
notification
and
then,
after
the
notification
you
can
do
the
TLD
essentially
like
you
do,
for
the
route
monitoring
for
the
code.
Two,
there
is
a
mandatory
to
field
to
byte
field
for
to
give
additional
information,
and
after
that
you
can
put
the
TLV
data
and
for
the
other
I
mean
there
is
no
extra
data.
So,
just
after
the
message
you
can
put
the
tlps-
and
this
is
it
for
this
draft.
Next
steps
really
I
think
it's
extremely
simple.
There
is
no
open
questions.
G
G
H
Jeff
as
sure
you
can
make
me
stand
up
and
talk
I
think
there's
a
desire
to
try
to
make
this
done
no
soon.
The
work
is
no
fairly
reasonable,
fairly
straightforward
in
the
grand
scheme
of
things
and
I.
Think
what
you're
going
to
find
is
this
work
is
the
plug-in
architecture
for
a
lot
of
the
other
stuff
you're
wanting
to
trying
to
do
for
the
rest
of
the
group.
If
you
try
to
finish
this
now
before
the
other
work
sort
of
cascades
into
it,
you
get
to
do
it
again.
I
G
Then
I
have
and
something
new
compared
to
the
other.
You
know
ITF
105,
which
is
the
support
for
enterprises,
specific
tlvs
right.
So
in
the
other
one
in
the
other
draft
we
are
defining
the
tlvs,
and
here
we
are
defining
a
mechanism
to
have
you
know,
enterprise
specific,
not
a
younger
governed.
You
know
pelvis,
so
even
before
the
program
you
know,
I
already
said
the
problem
statement,
so
I
can
go
ahead.
Essentially,
so
that's
that's
the
thing
like
you
know.
G
You
may
have
some
enterprises
specific
stuff
that
you
want
to
carry
and
some
vendor
to
and
other
don't
there
is
a
you
know,
a
pre
standardization
phase,
and
so
we
essentially
want
to
avoid
squatting
right.
I
have
already
noticed
squatting
from
at
least
one
implementer.
I
saw
a
message,
type
100.
So
let's
say
let
I
would
just
say
like
it's
a
a
nice
way
for
work.
G
It
is
totally
not
a
new
work
like
it
will
see
at
the
end
that
what
I
am
proposing
here
is
simply,
you
know,
borrowed
by
IP
fix,
and
you
know
landing
that
on
BMP
and
the
other
thing
is
that
why
we
are
not
merging
this
with
the
other
draft
is
because
the
other
draft
is
scoped
to
only
two
messages
right,
so
there
was
a
few
logics
over
there.
The
other
draft
is-
and
you
know
applies
only
to
do
two
messages,
and
this
applies
to
all
of
them
and
potentially,
since
its
kind
of
backwards
compatible.
G
What
we
are
doing
here,
since
there
is
no
tlvs
defined
that
used
the
first
bit,
we
can
even
apply
that
to
BMP
version
3.
If
you
want
right
so
there
are.
There
were
a
couple
of
things
that
in
induced
us
to
not
merge
the
two
works
so
for
who
is
not
familiar
a
pang,
it's
pretty
private
enterprise
number
and
it
is
assigned
by
a
younger
or
actually
you
go
request
to
a
young
and
the
young
a
gives
you
one,
and
you
know
the
goal.
G
I
have
already
said
it
and
things
like
that,
so
the
TLV
governed
by
a
Jana.
It's
a
super
simple,
like
you
know,
it's
a
TLV
like
we
know
hit,
and
you
see
the
first
bit.
It's
that
the
it's
the
EBIT
right.
So
it's
set
to
zero
if
it's
a
younger
governed
and
it's
that
one
if
it
is
enterprise
specific
and
if
it
is
interpreted
specific,
essentially
in
the
first
four
byte,
because
the
pang
is
four
byte
long.
G
The
first
four
byte
of
the
value
is
the
enterprise
number
and
then
followed
by
that
there
is
the
value.
To
be
honest
with
you.
There
is
no
many
open
questions
as
I
was
saying:
I
mean
I'm,
just
we
have
just
borrowed
something
existing
and
working
and
we
landed
it
over
here.
I
go
to
comments
like
oh.
If
you
do
this
mechanism,
then
you
want
to
do
it
elsewhere
in
BMP
message:
types
that
you
want
to
recommend
it
for
subtypes
and
whatever
so
questions
and
maybe
option
John.
F
Scudder
we
have
seen
at
least
one
proposal
of
this
kind
in
IDR,
also
and
I.
Think
it's
fine!
It's
it's.
You
know
technically
a
good
solution
to
the
problem.
The
pushback
that
I've
heard
in
that
context
basically
amounts
to
yeah.
But
but
when
I,
when
I
move
my
you
know
you're
you're
sort
of
proposing
it,
as
this
is
a
playground
that
I
can
experiment
in
and
then
once
my
thing
is
standardized,
then
I
have
to
go
and
actually
change
my
my
packet
format.
F
You
know
because
you
had
two
different
headers
there
and
which
leads
me
I
mean
I.
Guess
we
have
to
try
it
to
find
out
how
it
actually
plays
out
in
the
Wild
West
right.
But
you
know:
there's
probably
some
aphorism
like
nobody
ever
ever
got
rich
or
I
can't
put
it
together
now.
But
might
you
know
under
estimating
the
laziness
of
software
developers
yeah,
which
I
I
don't
think
it's
guaranteed
that
that
providing
this
nice
structure
will
get
rid
of
squatting
but
I
guess
we
might
as
well
try
yeah.
G
Thank
you
thank
you,
and
you
know
just
as
a
comment
on
the
laziness
and
whatever
I
totally
agree
with
you.
I
mean
we
already
know
what
happened
with
IP
fix.
So
you
write
on
the
draft
that
this
isn't
transitioning
mechanism
very
nice,
and
then
you
know
code
points
for
being
enterprise
specific
forever
right.
So.
F
F
So
so
so
what
you've
got
there
is
you
know
if
you
catenate
that
you've
just
got
a
six
byte
number,
so
you
could
also
just
be
like
yeah.
Here's
your
you
know,
six
byte
first-come-first-served
registry
and
everybody.
Can
you
know
it's
so
big
that
you'll
never
run
out
of
numbers?
So
just
everybody
go
crazy.
That's
that's
another
way
of
looking
at
it.
H
Jeff
has
I
think
John's,
referring
to
his
work.
That
I
did.
This
was
draft
ia.
Tf
draft
has
BGP
extended
experimental.
The
the
key
properties
in
there
were
that
it
did
actually
use
the
private
enterprise
numbers
this
way
to
give
people
their
own
playground.
The
other
thing
that
was
specifically
in
there,
which
some
people
didn't
like
some
people,
no
thought
was
a
good
idea,
is
when
people
pick
a
magic
number
within
their
own
enterprise
space,
because
enterprise
space
is
just
the
anchor
for
your
own
play
space.
H
You
still
have
to
have
no
an
internal
registry
which
you
have
to
expose
the
outside
world,
that's
one
of
the
headaches,
but
people
very
seldom
get
a
feature
right,
the
very
first
time.
So
if
you
assign
a
feature,
ID
100
and
then
change
how
it
behaves,
do
you
simply
ship
new
code
under
100
and
break
everybody?
Or
do
you
know
Revit
or
choose
a
new
code
point
and
this
sort
of
devolves
back
to
the
talks
I've
given
in
a
couple
of
different
working
groups
on
managing
code
points?
H
Second
minor
point:
the
majority
of
my
comments
on
the
BMP
stuff
is
going
to
I
think
devolve
down
to
a
few
very
simple
core
points.
I
can
take
them
to
the
list
again
have
been
the
discussions
line
with
some
of
the
other
authors,
but
if
there's
five
minutes
at
the
end,
the
agenda,
but
the
chairs
entertain
a
possibility
of
me
talking
to
the
group
for
five
minutes.
H
C
C
So
the
conflicts
of
pen
to
me
is
that
if,
within
your
organization
with
your
applications,
you
need
to
do
a
thingy
that
is
appropriate.
But
if
we
have
vendors
using
pen
to
push
their
products,
I
would
much
more
like
to
try
and
bring
and
keep
the
group
together
so
that
we
have
one
uniform
understanding
of
what
BMP
is.
C
But
I
also
recognize
that
squatting
is
a
very
undesirable
behavior
and
one
observation
is
that
first-come,
first-serve
and
a
large
number
space
could
be
very
effective
if
you
lower
the
barrier
to
get
a
number
that
will
encourage
people
to
just
take
the
number
the
enterprise
number.
It's.
It's
not
a
vendor
extension
number.
Two,
it's
a
very
it's
within
one
single
administrative
domain
and.
G
The
point
I
essentially
have
replied
to
your
point,
but
also
to
just
point
so
essentially
the
the
reason,
this
kind
of
makes
sense
to
me
like
I,
understand,
lowering
the
bar,
and
everything
is
that
you
know
in
the
end
of
this
is
a
game.
P
is
not
something.
A
routing
protocol
is
not
something
that
it
should
be
understood
by.
Let's
say
two
organizations
right,
so
it's
you
are
monitoring
something,
and
maybe
you
want
to
expose
some
metadata
and
that
metadata
applies
to
one
vendor,
but
not
the
other.
G
So,
in
a
way
doing
a
younger
government
should
be
realistic
right.
So
if
I
want
to
expose
some
metadata
for
something
that
I
do
have,
but
another
vendor
doesn't
have,
then
it
is
not
realistic
to
standardize
it,
and
this
kind
of
mechanism
allows
to
you
know
not
squat,
so
still
the
vendors
to
do
their
own
stuff,
but.
G
Without
squat
in
the
the
public,
the
public
space
right
so
I
mean
there
are
things
that,
in
my
opinion,
not
realistic
to
standardize.
I,
don't
know
I
want
to
you
know:
I,
don't
want
to
give
examples,
but
there
are
things
that
cannot
clearly
be
standardized,
and
this
is
a
mechanism
that
can
help
their
shared.
J
Much
Akamai
so
I
think
job
I.
Think
one
of
the
points
here
is
that
sometimes,
when
we're
implementing
things
you
know
and
and
Akamai
we
have
a
number
of
our
own
implementations
that
pass
data
around
that's
important.
You
know,
you
know
we
kind
of
need
to
have
a
standardized
place
to
put
these
types
of
things.
Even
if
it's
not
part
of
the
official
IETF
standard
is
that
sometimes
there's
a
need
for
additional
namespace
I.
J
Think
that's
what
we've
seen
with
a
lot
of
the
other
languages
like
JSON
or
whatever,
where
you
can
actually
add
additional
metadata
easily
and
such
so
I.
You
know
I
I,
understand
the
sentiment
of
yeah
we're
standards
body
and
it
kind
of
is
a
little
bit
different
there,
but
yeah
I
can
talk
to
you
afterwards
about
it.
C
K
G
L
Hi
so
I
published
this
draft.
Just
recently,
it
came
from
discussion
with
Paulo
actually
about
four
BMP
collectors,
defining
a
mechanism
to
store
BMP
messages
and
record
them
as
a
archive
format.
So
I
snuck
this
together
as
an
initial
idea
which,
which
was
to
use
MRT,
which
is
explicitly
designed
for
that
purpose.
It's
for
storing
routing
protocol
transactions
as
it
refers
to
it
and
well,
you
know
it's.
It's
well
supported.
It's
well
known
for
storing
bgp
data
and
especially
in
things
like
route
views
and
rays,
and
it
supports
tight
code.
L
The
initial
attempt
was
to
just
define
width
message
inside
a
header
that
says
where
it
came
from
and
who
sent
from
and
to,
and
then
just
put
the
message
in
there
now
that's
sort
of
an
opening
point
for
discussion,
because
the
the
main
issue
with
it
is
that
the
way
MRT
files
are
usually
done.
They
get
split
by
time
intervals.
Maybe
they're
split
every
five
minutes
and
the
messages
are
always
standalone.
L
They
need
to
be
parsed
independently
of
you
know
the
previous
file
and
such
which
means
that
the
information
about
the
encoding
of
the
bgp
update,
which
is
usually
based
on
capabilities
that
were
negotiated
at
the
beginning
of
the
session,
end
up
needing
to
be
encoded
into
the
MRT
format.
To
so
that
the
parser
knows
how
to
read
it.
Examples
of
this
being.
L
Now
that
pain
of
leads
to
the
questions
that
I
had,
which
was
where
the
responsibility
for
ensuring
that
lies.
There's
options
of
the
BMP
sender,
communicating
enough
information
to
represent
that
one
of
the
this
actually
led
onto
the
the
TLV
draft.
That
Paulo
has,
which
was
adding
support
for
the
to
add
plv
encode
encodings
to
represent
these
different
income.
L
Whether
this
draft
should
just
be
specified
for
BMP
v4
and
ignore
they
not
use
it
for
other
versions
of
BMP,
then
the
receiver
can
just
record
the
incoming
message,
or
should
the
monitoring
station
be
the
one?
That's
writing
the
message
be
responsible
for
providing
the
information
on
how
to
read
this
message
at
a
later
date.
L
This
is
an
example
of
what
currently
happens
for
the
BGP
type
and
MRT,
where
it
basically
has
a
list
of
permutations
that
get
added
to
every
time.
The
wiring
coding
changes
with
a
capability
which
has
happened
a
couple
of
times
so
far,
there's
still
a
few
more
permutations,
but
it's
not
the
nicest
and
yeah
the
MRT
format
has
subtypes.
We
could
use
the
same
mechanism
as
the
BGP
type
to
also
encode
the
permutations
into
the
subtypes,
or
ignore
that
and
define
some
extra
header
fields
to
represent
the
different
encodings.
L
L
K
Colin
hi,
whether
you're
speaking,
what
you
are
talking
about
is
essentially
stuff
in
the
presentation
layer,
rim
kind
of
I'm
surprised.
My
previous
remark
on
doing
something
on
the
presentation
layer
might
actually
benefit
here.
No
idea
how
complex
it
is
to
transition
to
something
that
is
more
future-proof.
M
Hi,
this
is
your
uncle
from
Hawaii,
so
I
have
three
drafts
to
discuss
with
you
today.
The
first
one
is
BGP
route
trace
using
BMP
okay.
So
yet
this
on
the
0-3
draft
version,
we
have
Thomas
from
Swiss
come
onboard
and
he
has
helped
prepare
this
version
with
a
lot
of
good
suggestions,
and
we
can
take
a
look
so
here's
the
changes
that
we
make
to
the
second
version.
The
first
big
change
is
that
we
have
tried
to
restructure
the
whole
format.
M
Previously.
You
know
the
information
regarding
prefixes
and
policies
and
the
attributes
there
kind
of
you
know
mixed
together.
So
this
time
we
try
to
put
things
where
they
all
belong
together,
and
so
that's
why
we
come
up
with
a
policy
TLV
and
where
we
put
all
the
sins
that
related
to
the
policy
together,
okay
and
then
we
have
done
some
renaming
so
the
first
one
is
that
we
change
the
previous
hop
to
the
root
origin
and
the
second
is
we
changed.
The
vrf
table
name
TLV
to
vrf
table
TLV.
M
That's
because
we
add
infilled
to
this
TLV,
which
allows
you
to
put
the
a
prf
table
ID.
So
so
you
have
both
the
name
and
the
ID
name
better
for
visualization
and
the
ID
is
can
be
used,
for
you
know
precise
mapping
or
searching
stuff,
and
we
also
we've
made
this
tell
via
also
optional,
and
then
we
renamed
the
optionals
2008
use
20
of
e,
and
we
add
an
example
how
we
can
use
this
DOB
and
we
also
redefined
the
policy
classifications.
Okay.
So
let
me
walk
you
through
these
two
Yogi's.
M
So
the
message
looks
like
this:
still,
we
have
the
prefix
information
and
any
comprises
of
different
events.
Then,
for
each
event,
we
first
have
the
you
know:
timestamp
information
and
some
other
information
relates
to
the
prefix,
and
then
we
get
the
table
TLV
and
policy
TLV.
So
above
above
this
part,
which
are
you
know
the
it's
about
the
prefix
you're
monitoring
and
about
the
reason
or
yeah.
M
D
M
So
this
govt,
actually
is,
has
has
made
a
I've
made
a
lot
of
changes
to
it,
so
every
simulated
policy
is
put
in
here.
So,
first
of
all,
we've
add
two
black
bits.
The
first
one
is
still
the
one
will
previously
have,
which
is
the
map,
the
matching
or
mismatching
bit.
It
tells
you
if,
if
match
condition
is
met,
okay
and
then,
if
there
is
a
match
of
the
policy,
the
P
bit
will
tell
you.
The
result
of
this
match
is
permit
or
deny
so.
M
If
it's
permit,
then
we
can
use
the
a
bit
which
is
stands
for
if
there's
difference
or
not,
of
the
pre
and
post
policy
attributes.
In
other
words,
it
tells
you
if
there
are
further
actions
taken
regarding
the
attributes.
If
you
have,
for
example,
if
you
have
like
changed
the
next
hop
or
not.
So
if
the
tippet
is
unset,
then
we
shall
not
include
the
post
policy
attribute
govt
in
the
message,
because
it
with
it'll
be
the
same
as
a
precursor:
okay,
so
and
attribute
govt.
These
are
still
the
same
and
for
the
string
govt.
M
The
example
is
something
that
I
have
discussed
with
Thomas
who
thinks
that
if
we
don't
want
to
use
the
policy
format,
we
define
the
in
this
draft
we
probably
could
use
you
know
something
that
you
want
to
carry
to
represent
your
policy
so
here
for
some,
we
can
use
the
ex
pass
of
your
policy.
Your
models
here
to
represent
represent
the
policy
information
or
you
can
combine
both
the
policy
govt
with
the
string,
govt,
okay,
so
well
up.
M
I
would
like
to
get
some
feedbacks
from
the
working
group
here
which
basically
are
about
the
future
direction
of
this
draft.
So
this
I've
talked
to
different
people
and
I
do
see
you
know
different
opinions
or
comments
on
the
draft
something
you
know.
This
draft
is
a
little
bit
over
complicated
over
complicated,
and
maybe
it
can
target
a
very
specific
use
case,
but
some
other
think.
Well,
it's
good
I
can
get
all
the
information
I
need,
and
maybe
you
can
don't
do
something
in
the
server
side
to
to
extract
information.
M
You
need
to
to
insert
into
different
apps
so
yeah-
and
this
is
something
that
I
want
to.
You
know
ask
the
working
group
to
help.
You
know
refine
the
drafts
and
well.
The
second
is
use
case
and
so
I
think
the
direction
should
be
use
case.
Driven
so
shall
we
identify
some
use
cases
to
help
converge
the
draft
yeah.
So
that's
for
the
first
structure,
any
comments.
K
K
Actual
content
and
intention
and
use
certainly
has
complexity
and
are
not
completely
sure
whether
I
am
really
happy
to
go
there.
But,
following
up
to
my
previous
two
remarks,
the
complexity
that
comes
in
by
the
customized
presentation
layer
certainly
does
not
help
a
lot.
I.
Very,
very
much
would
like
to
see
an
approach
like
define
your
complex
data
structure
in
something
like
CD
DL
and
if
you
want
to
have
a
dense,
binary,
encoding
use.
K
Just
the
C
bore
encoding
and
parsing
mechanism,
and
let's
not
talk
about
the
presentation
layer
and
for
parsing
any
more
and
just
lift
up
the
discussion
to
more
of
a
semantic
level
where
we
would
be
talking
about
symbolic
fields
and
data
structures
and
stuff
like
that
kind
of
yes
again
like
in
my
previous
remark.
It
is
not
completely
clear
whether
this
is
the
guinea
pig
to
try
to
do
this.
The
first
time,
but
looking
at
the
complexity
of
a
presentation,
I
actually
think.
Yes,
it
would
be
a
very
interesting
guinea
pig
thank.
C
Job
Snyder's
NZT
one
thing
to
respond
to
ridiger
I
think
it
is
an
interesting
notion
if
we
could
get
to
a
higher
level
of
discussion
to
focus
less
on
what
does
this
bits
on
the
wire
mean
and
more
to
talk
about
symbolic
meanings?
That
is
an
admirable
goal.
You
suggest
that
Seaboard,
it
is
on
my
to-do
list
to
go
to
the
Seaboard
working
group
because,
as
far
as
I
understand,
they
don't
have
primitives
such
as
an
IP,
prefix
and
IP
address
and
and
other
things
and
I
think
we
would
do
ourselves
at
this
surface.
C
H
To
go
to
that
working
group,
Jeff
has
and
specifically
responding
that
it's
the
exact
same
comment,
I
made
to
you,
know
partially
adjust
the
CRISPR
or
on
the
mailing
list,
there's
a
lot
of
binary
encodings
that
are
wonderful
for
Transport.
They
give
you
know
encapsulation,
that's
great,
but
the
presentation
layer
on
top
of
them
is
not
rigorous
enough
for
that.
Our
applications.
H
It's
fine
for
us
to
specify
things
and
Yang
and
have
them
actually
rendered
in
a
different
format,
because
it
provides
a
hint
to
the
underlying
code
how
to
do
the
rendering
just
cuz
it's
a
byte
string
underneath,
if
you
tell
it
in
the
yang
layer,
that's
an
IP
address.
This
means
that
code
that
actually
is
eating.
Seymour
can
Percy
Moore
notice
that
map's
the
underlying
IP
type
and
run
the
validator
in
that
format.
M
So
the
second
draft
I'm
going
to
discuss
is
B
me
for
rules.
Ik
detection,
so
well
I've
been
trying
to
get
a
figure
that
best
represents
where
this
dropped
stance.
It
might
be
a
little
ugly
to
watch.
I
walk
you
through
it.
So
so.
First
of
all,
this
draft
is
a
ruling
detection
method
and
it
allows
you
to
detect
the
leaks
that
happen
in
your
local
s,
not
the
upstream
or
downstream,
and
it
allows
you
to
find
the
issues
that
happens
at
the
u.s.
SPR.
M
So
maybe
the
egress
here
is
misused
by
I
want
to
express
you
know
the
propagation
direction
of
the
route,
for
example
in
this
figure
the
rotor.
For
so,
if
we
have
done
some,
you
know
inbound
or
outbound
policy
is
configured
here
and
the
route,
for
example,
received
from
your
provider,
is
airily
sent
to
another
provider
and
then
for
such
case,
we
can
use
this
draft
to
identify
a
leak.
Okay
and
a
few
considerations
or
say
I.
M
Think
benefits
of
this
draft
is
that,
first
of
all,
it's
a
simple
single
IP
deployable.
You
don't
need
to
like
have
corporations
or
depend
dependencies
of
you
know
things
from
other
ISPs,
and
the
second
good
thing
is
that
you
don't
need
to
rely
some
database
lookup
and
stuff
like
that,
and
the
search
thing
is
that
this
kind
of
detection
is
prefix
level
and
for
this
point,
I
will
have
a
question
about
I.
M
Have
a
question
for
the
working
group
in
the
later
page,
and
the
circle
thing
is
that
it
for
my
own
sending
list
it
doesn't,
you
know,
overlap
or
a
conflict
with
some
of
our
existing
Messrs,
and
actually
they
can
like
be
complimentary
to
each
other.
As
you
know,
something
I've
pictured
in
this
figure.
Okay,
so
here
are
the
changes
we've
made
in
the
four
versions.
M
So
shall
we
do
like
just
bgp
session
detection
or
prefix
level,
because
for
if
we
want
to
do
just
bgp
session
level,
then
we
probably
don't
need
any
extensions,
because
the
open
policy
allows
you
to.
You
know,
exchange
tea
of
the
rows
and
then
it's
carried
in
the
peer
up
messages.
So
you
have
the
information,
but
the
best
thing
is
that
you
cannot
refuse,
and
you
know
some
complete
complex
cases
where
some
prefixes
are
don't
obey
to.
You
know
the
session-based
relations.
M
I
Alexander's
Yandex,
first
of
all,
thank
you
for
covering
some
of
my
comments
in
the
slides.
I
need
to
admit
that,
since
you
dropped
at
the
moment,
is
relies
on
BGP
rules
to
get
information
about
different
relations.
There
is
no
option
to
get
rose
per
perfect
because
it's
just
and
just
no,
it
doesn't
work
like
this.
I
You
know
my
position:
I
would
prefer
to
have
a
draft
that
will
describe
common
use
cases
for
beam
P,
because
it's
a
moment.
So
there
is
no
such
work
and
with
what
we
have
we
have
has
a
signals
that
can
be
used.
We
have,
we
may
end
up
with
one
two
three
signals
and
to
get
them
in
beam
B
before
we
apply
an
mitigation
policy
makes
sense
for
me
thanks.
J
Shared
much
Akamai,
I
think
one
of
the
biggest
challenges
in
discussing
this
is
that
what
actually
defines
a
route
leak
is
highly
business
specific.
It's
not
just
about
the
ASPA
role
or
about
you
know
stuff,
because
individual
prefix,
in
one
case,
you
may
actually
want
to
let
out-
and
you
may
not
want
to
let
other
prefixes
through
and
that
business
logic
is
something
that
is
not.
That
may
be
unique
to
the
individual
company
and
I.
J
Think
is
something
that's
very
hard
for
outsiders
to
infer
what
the
actual
intent
is
without
you
know,
intent
based
routing,
which
is
really
what
BGP
is
I've
sent
you
the
NRL
I.
This
is
my
intent.
Is
that
you
please
route
this
and
I
think
that
that
that
is
the
challenge,
and
how
do
you
identify
these?
J
Is
that
we
we
don't
have
a
good
understanding
of
how
to
communicate
this
to
each
other
and
there's
a
lot
of
granularity
that
can
exist
in
it,
and
we
have
a
lot
of
tools
that
we're
using
to
do
this
via
BGP
communities
or
something
else
to
try
and
prevent
these
types
of
things.
But
I
think
that
that
that's
one
of
the
biggest
I
think
challenges
with
this
type
of
a
you
know.
This
type
of
a
draft
is
BMP
is
an
excellent
protocol
for
monitoring
stuff.
J
M
For
the
comment,
so
if
no
other
comments-
let's
move
to
the
last
one
okay,
so
the
last
draft
is-
is
about
enhanced
a
loop
detection
for
BGP
routes.
So
the
changes
to
the
previous
version
is
that
we
have
converged
our
proposals
to
two
options
for
both
inbound
and
outbound
policy
processing.
So
the
first
option
is
that
when
you
detect
a
route
with
a
slope,
then
you
do
some
analyze
based
on
some
local
database,
and
the
second
option
would
be
you,
you
know,
use
BMP
extension
to
export
the
roots
with
a
slopes.
M
So
the
first
one
does
not
need
any.
You
know
changes
to
existing
protocols
and
the
second
one
we
have
proposed
to
use
the
mirroring
message
with
a
new
within
you
code
type
for
the
information
T
of
e
to
carry
the
routes
with
as
loop
detected.
So
you
can
put
the
roots
with
look
after
the
T
of
e
type
and
yes
in
the
last
field.
So
that's
act
and,
as
I
have
discussed
this
case
with
Alex
previously,
and
he
mentioned
some
news
cases.
You
know
the
the
draft
was
previously.
M
You
know
intended
for
detecting
hijack
cases
and
Alex
mention
something
that
you
can
use.
Also
such
detection
to
find
some
configure
configuration
errors
of
your
neighbor,
a
SS.
If
I
understand
it
right
and
I
think
ice,
you
can
like
send
the
case
to
the
Mellon
list
for
further
discussion,
or
you
might
want
to
bring
it
up.
Yeah.
I
Yandex,
so
my
message
was
that
the
way
to
state
it
in
the
draft,
so
you
are
taking
to
account
BGP
updates.
Where
is
your
own
at
own
system?
Number
in
the
highest
path,
is
not
limited
to
the
scope
of
what
is
called
what
is
causing
the
drought,
hijacks
or
I
will
call
it
our
root
leaks,
because
it
may
also
happen
when
some
of
your
prefixes
are
rejected
by
your
upstream
provider
and
they
are
sending
you
back
these
prefixes
that
I
received
from
other
side.
I
Can
be
added
to
your
previous
draft,
so
I
believe
that
being
P
has
a
lot
of
options
and
to
be
used
and
with
the
eating
experience
how
it
can
be
used.
What
information
can
be
it'll
easily
retrieved
for
this
kind
of
monitoring
and
can
be
moved
into
informational
draft?
That
would
be
very
interesting
for
the
industry
and
also
make
a
help
for
being
PTO.
Take
order
to
take
up
to
get
a
higher
rate
of
deployment
yeah.
N
C
N
Hi
everybody
Thomas
Carr
from
Swisscom.
You
might
have
noticed
that
on
Saturday
Sunday
we'd
had
hackathon,
and
the
goal
from
our
group
was
basically
to
do
some
interoperability
testing
between
collector
and
routers.
In
terms
of
BNP,
local
rip
and
adjacent
city
bout,
we
could
use
an
updated
via
shop,
be
MPD
sector
and
PM
acct
to
to
validate
that,
basically,
with
a
simple
set
up
here
with
three
routers
and
identified
some,
let's
say
interesting
things
which
we
put
on
the
mailing
list
and
would
like
to
encourage
you
to
give
us
some
feedback.
N
One
thing
was
about
PNP
local
rip.
When
a
router
has
an
a
local
originated
out
in
its
local
group,
we
noticed
that
the
next
hop
attribute,
depending
on
the
vendor,
might
be
different.
It's
either
like
127,
0,
0,
1
or
0
0
0,
RFC
4279
doesn't
really
specify
what
the
next
attribute
should
be
when
it's
directly
exposed
from
the
router
and
it's
propagated
out
of
the
router.
There
versal
definitions
there.
N
N
Another
thing
which
we
found
was
regarding
Jason
C
rip
out.
There
seems
to
be
different
vendor
implementations
regarding
the
P
hop
message
depending
if
post
and
pre
policy
is
configured
or
not
depending
on
the
implementation
we
have
one
or
more.
You
have
up
messages
with
different,
pier
headers,
so
also
please
on
the
mailing
list
feedback
house.
N
If
you
think
that
either
both
is
acceptable
or
we
should
clearly
define
whatever
you
shoot
in
this
case,
just
get
one
pier
up
messages
or
if
multiple
PL
of
messages
is
decide
desired,
result
well,
we
will
go
on
and
in
the
next
hackathon
107
we
can
continue
to
to
validate
some
future
drafts
regarding
path
marking
our
policy
attribute
racing
and
annuity
Elvis,
and
that
was
the
group
thanks.
A
lot.
H
D
G
It's
about
compressing
route
monitoring
messages,
so
it
is
believed
that
let's
a
BMP
may
generate
a
lot
of
data,
especially
without
being
a
tribal
law,
creep,
pre
and
post
policies,
the
LDS
and
all
of
that,
and
then
essentially
the
proposal,
I
would
say,
is
quite
simple:
quite
intuitive.
It's
just
like
you
flag,
compression
information
in
the
init
message
using
the
TLB
stir,
you
have
a
new
message
type
because
of
course
this
is
not
compatible
with
existing
route
monitoring
messages
and
essentially
apply.
G
F
We
have
two
comments
at
the
mic:
John
Scudder,
so
I
hadn't
heard
of
this
work
prior
to
the
beginning
of
this
meeting,
so
I
quickly
went
and
looked
at
the
draft.
It's
admirably
short
I
had
read
the
Tonys
draft
in
IDR
previously
and
I
liked
that
work
so
sort
of
by
extension.
I
like
this
work
to
the
the
one
warning
is
that
just
sort
of,
as
you
know,
kind
of
a
process
thing
Tony's
draft
is
still
an
individual
submission.
So
if
you
move
ahead,
we'll
probably
need
to
figure
out.
You
know
how
to
make.
F
G
O
Agnostic
Adonis
Equinix
speaking
as
a
working
group
member
and
a
happy
user
of
compressed
BMP.
Yes,
this
is
needed.
The
solves
this
addresses
a
real
problem
in
the
field
and
not
necessary
the
lack
of
capacity
on
the
bits
on
the
pipe,
but
on
the
processing
side
of
received
EMP
messages.
A
couple
of
commands.
What
you
are
proposing
is
to
compress
one
single
message
and
the
results,
if
you
would
compress
a
vector
with
the
same
dictionary,
would
be
noticeably
better.
O
The
other
thing
is
about
when
you
restart
the
compressor.
An
important
use
for
for
BMP
is
storing
and
replaying
that
data
later.
That
means,
if
you
start
a
compressor
at
the
start
of
a
session,
you
need
to
replace
everything
from
a
beginning
having
a
mechanism
stating
that
you
start
to
compress
either
add
some
some
amount
of
messages
at
some
amount
of
seconds
or
something
like
that
seems
to
be
usable
functionality
to
have
I.
G
See,
first
of
all,
thank
you
for
your
comments.
We
have
definitely
to
look
how
to
up.
Is
this
better,
like
you
were
essentially
saying
not
only
compressing
but
also
batching
things
together,
so
we
have
just
to
study
how
to
do
that
and
propose
something
to
it
to
your
other
point,
the
one
to
restart
a
compressor.
So
in
the
draft,
what
we
say
is
essentially
that
there
is,
like
you
know
around
her
producing
an
you,
know,
BMP
data
and
then
the
collector
as
the
the
compressor.
So
in
a
way
it's
not
stretched.
G
This
is
not
stretching
to
beyond
that.
Like
so
you
decompress
it
and
then
maybe
you
have
I,
don't
know
what?
No,
so,
essentially,
you
should
not
so
should
not
save
the
compressed
message
should
compress
it,
but
I
understand
that
what
you
say
is
that
you
may
want
to
save
the
actual
raw
message.
I
understand
that
yeah
we
have
to
see
also.
C
C
It
can
be
of
paramount
importance
to
very
very
quickly
understand
what
the
hell
happens
on
the
wire
and
what
is
propagating
for
the
global
routing
system,
and
if
we
were
to
compress
BMP
messages,
I
would
have
significant
concerns
depending
on
how
that
compression
is
storm.
What
the
state
of
the
dictionary
is
how
the
dictionaries
are
exchanged,
whether
we
can,
whether
we
would
hamper
our
ability
to
very
quickly
react
now.
C
Bmp
from
my
perspective-
and
this
is
just
my
view-
it's
not
the
critical
path.
It
is
a
telemetry
or
monitoring
protocol
and
if
monitoring
breaks,
we
our
flying
blinds,
which
can
be
very
unfortunate
but
are
still
flying
in
some
direction,
so
I
would
I'm
less
hassle
them
to
consider
compression
in
BMP,
but
I
I
will
notice
that
compression
in
BGP
is
I,
think
in
context
of
internet
routing
a
potential
source
for
lots
of
problems.
C
I
J
You
know
from
the
mic,
but
I'm
kind
of
curious
on
this,
because
my
sentiment
is
somewhat
similar
to
jobs
in
you
know
trying
to
do
this
I'm
very
concerned
about
any
delays
in
the
messaging,
because
we're
trying
to
use
the
data
for
real-time
event,
detection
of
you
know,
potentially
anomalous
or
malicious
actors
and
I
know
compression.
You
know
compression,
isn't
really
that
heavyweight,
no
more
than
any
any
of
the
Kryptos
or
anything
else,
but
and
any
delay
is
something
that's
very
concerning
to
me.
Thank.
G
H
Thanks
for
the
time
so,
I
hadn't
intended
to
give
a
presentation
here,
but
my
commentary
and
for
much
all
of
these
things
that
we're
seeing
for
BMP
is
coming
down
to
a
lot
of
very
common
points.
So
I'll
make
the
statement
here
and
then
maybe
depending
exactly
what
the
written
group
thinks
I
can
summarize
it
down,
maybe
in
an
internet
draft
or
other
wiki,
or
something
that
so,
if
I
had
to
give
a
quick
presentation
and
I
try
to
keep
this
much
less
than
five
minutes.
It'd
be
architectural
implications
of
PDU
formats
and
router
implementations.
H
The
big
problem
that
we
have
here
is
that,
and
you
know
somebody
who's
recently
like
in
front
of
me.
Online
BMP
does
have
use
cases.
They
have
use
cases
beyond
simple
telemetry.
We
have
certain
very
large
service
provider
networks
that
are
using
them
to
power
their
Sdn
implementations,
so
things
that
slow
that
down
make
such
vendors
rather
cranky.
So
there
is
strong
need
to
be
aware
that
these
things
are
little
more
complicated
than
just
making
the
PDUs
easy.
The
hackathons
are
very
good
for
proving
out.
Can
you
actually
decode
the
format's?
H
Can
you
actually
do
something
with
things?
Is
the
format
well-structured,
but
it
doesn't
necessarily
help
you
answer
the
question
about.
You
know
if
I'm
writing
a
BMP
implementation
that
integrates
with
an
actual
BGP
implementation.
What's
going
on
here
and
there's
some
extent,
that
argues
that
not
enough
of
the
right
people
are
actually
sitting
at
the
hackathons
as
well.
H
Thankfully,
we
have
some
people
that
can
do
both
and
we
shouldn't
see
about
getting
a
few
more
of
them
involved
in
that
sounds
as
well,
but
the
core
observations
really
come
down
to
a
very
small
number
of
items.
Item
number
one.
This
is
basically
BGP.
Now
we
do
know
from
a
lot
of
experience
that
BGP
scales
based
a
number
of
PDUs
that
get
exchanged
now.
This
is
in
terms
of
the
protocol
in
terms
of
formatting
things
and
to
some
extent
and
receiver,
the
receiver
is
being
in
many
cases.
H
General
purpose,
PC
type
applications
means
that
we
don't
have
anywhere
near
the
same
impact
that
a
actual
router
would
so
that's
less
of
a
concern,
but
it
does
mean
that
the
formatting
site
is
still
a
problem.
So
what
that
means?
Is
that
anything
that
degrades
route
packing
as
we
would
normally
do
in
BGP
can
be
a
problem
for
the
implementation,
and
this
ties
in
the
second
problem,
which
is
you
know,
that
the
options
that
we're
currently
looking
at
for
extending
BMP
are
largely
just
tacking
on
this
optional
TLV
to
the
bottom
of
a
message.
H
What
that
means
is
that
that
optional
TLV
needs
to
apply
to
the
entire
contents,
and
so
the
path
attribute
for
a
given
a
fee
Safiye
and
some
number
of
em
larai
inside
that
package.
If
you're
intending
this
information
to
apply
to
subsets
of
that
NL
RI,
you
are
doing
a
forced,
D
packing
of
the
message.
H
We
can
actually
do
something
about
this.
No,
we
can
actually
change
or
format
so
that
the
tlvs
no
or
such
that
you
have
path
attribute
s--.
We
have
another
ID
and
we
have
stuff
with
a
despair
to
that
owner
is
telemetry.
This
allows
us
to
do
the
job
of
allowing
optional
things
to
go
in
there
without
necessarily
doing
degrading
the
per
packet
case.
H
The
other
thing
that
we
have
as
a
general
problem
in
the
architecture
is
that
BGP
is
ranked
elementary
for
we
have
ribbon.
We
have
lower
than
we
ever
about
low
cribs
with
effectively
an
illusion
of
what
the
current
routing
table
is,
and
the
ribbon
about
in
many
cases,
have
strong
correlation
to
people's
internal
data
structures,
and
this
means
that,
if
you're
looking
to
attach
some
sort
of
interesting
state,
if
you're
lucky
that
state
actually
exists,
no
solo
group
is
an
example.
Many
implementations
I
actually
keep
track
on
the
runtime
basis.
H
Why
did
I
not
accept
this
prefix?
No,
this
is
one
of
the
pieces
of
data.
People
are
looking
at
export.
If
you
have
that
data,
that's
great,
but
the
minute,
you
don't
actually
have
some
piece
of
data
and
it's
interesting
to
you
and
it
belongs
the
protocol.
You
are
forcing
the
implementation
to
do
one
of
two
general
things:
either
extend
its
internal
data
structures,
so
that
state
is
tracked.
That
has
a
cost.
You
know,
especially
in
terms
of
memory
and
if
you're,
a
real
router
you're
running
a
potentially
an
older
Hardware.
H
The
addition
of
a
single
word
of
memory
on
a
common
data
structure
can
knock
you
over
some
of
your
limits,
so
you'll
find
from
traditional
router
vendors,
a
lot
of
hesitation
to
do
things
that
end
up
being
persistent
state
that
gets
attached
around,
which
leaves
us
pretty
much
for
any
of
the
optional
mechanisms
there
needs
to
be
some
way
to
very
quickly.
Attach
data
to
the
information,
so
ribbon
is
an
example.
If
I
want
to
know
what
bit
of
policy
was
actually
doing,
this
can
I
Drive
it
from
the
policy
engine
itself.
H
Well,
certainly
running
policy
lets
you
get
that
information,
but
you
probably
don't
want
to
take
the
hit
of
actually
writing
the
policy
real
time
with
this
and
keeping
around
the
state.
You
know
just
long
enough
to
shove.
It
down.
Vmp
potentially
could
be
a
problem,
because
who
knows
how
long
that
states
got
linger
based
on
back
pressure,
we've
kept
the
conversation
about.
H
Why
do
we
need
compression
is
to
some
extent
really
not
the
fact
that
BMP
is,
you
know
a
socket,
it's
just
the
TCP
pipe,
just
like
every
other
thing
on
the
planet
and
that,
if
you
can't
keep
up
with
the
data
stream
you're
creating
back
pressure
on
information
that
needs
to
be
retained.
So
that's
an
impact
as
well,
and
if
you
can't
drive
even
if
you
can
derive
this
stuff,
you
know
that
it
needs
be
attached
a
very
quick
basis,
there's
still
the
cost.
H
You
need
to
do
some
level
of
nokey
comparability
from
one
data
store.
You
know,
in
this
case
your
ribs,
which
are
highly
optimized,
to
make
your
beach
be
fast
note
to
some
data
store
that
may
not
be
know
very
fast,
and
what
we're
doing
in
each
of
these
different
presentations
is
providing
some
level
of
annotation
and
oh,
these
objects
that
are
running
around
bgp
for
efficiently
and
finding
ways
to
effectively
don't
throw
obstacles
in
front
of
them
to
make
them
slower.
H
So
my
recommendations
know
is
that
we
know
try
to
remember
that
the
core
use
cases
do
need
to
be
kept
and
enabled
now.
This
means
that
these
things
are
optional
features
hopefully
and
stay
optional,
because
some
of
these
things,
if
they
were
not
optional,
I,
would
have
to
tell
some
of
our
larger
customers
don't
use
them.
They
will
degrade
your
Sdn
use
cases
for
things
that
are
optional,
especially
for
telemetry
type
applications.
That's
great!
H
You
know,
let's
look
at
changing
the
format
a
little
bit
so
that
the
information
hairy's
better,
doesn't
break
gnome
packing
things
and
the
last
one
is
no
really
a
presentation.
Layer
comment
know:
if
we're
going
to
tangle
these
things
up
several
the
things
that
we're
actually
talking
about
involve
putting
some
sort
of
string
on
there.
You
know
the
fact
that
might
be
a
ski
or
utf-8.
This
is
partially
irrelevant
the
thing
that
most
of
us
who
spend
a
lot
of
time,
doing
performance
measurements
on
our
systems
for
things
that
need
to
be
really
streamlined.
H
We
know
that
scanf
or
whatever
your
language
of
choice
mechanism
for
parsing,
strings
or
integers
is
very
expensive.
Just
simply
turning
a
prefix
IP
prefix
in
ascii
format,
into
a
simple
four
byte,
no
value
with
one
byte
worth
of
prefix
that
gets
expensive.
After
a
while-
and
ideally
you
don't
do
that,
so
what
this
means
is
be
very
careful
about
deciding
that
no
especially
noisy
information.
H
That
may
be
very
repetitive
now,
if
you
have
a
set
of
recent
strings,
that
the
router
is
going
to
say
that
I,
don't
like
this,
don't
send
that
recent
string
10,000
times
and
make
them
parse
it.
Each
time
find
a
way.
No
similar
IP
fix
to
exchange
a
dictionary.
But,
let's
you
say,
here's
what
the
string
table
is
and
a
sick
number
100
in
here
for
this
entry
from
no
no
I
make
it
nice
and
competant
anyway.
That's
my
comments.
H
P
H
Certainly,
one
way
to
go
know,
so
one
of
the
things
that
have
popped
up
in
some
of
the
presentations
is
like
reasons
why
we
didn't
accept
a
thing.
You
know
some
of
these
things
are
common
behaviors,
that
you
know
we
really
should
be
standardizing
anyway.
I
think
when
this,
when
flavor
of
this
actually
popped
up
an
idea,
I
think
your
Nan's
Mitchell
presentation.
My
commentary
was
some
of
these
things.
H
Absolutely,
as
a
good
value,
add
deserve
a
registry
of
here
common
cases
that
we
do
things
and
that
should
be
maintained
somewhere,
but
there's
going
to
always
be
something
that's
proprietary,
you
know
so
like
I
may
know
something
that's
been
rejected
by
a
policy
and
I
want
to
actually
add
on
a
little
bit
of
additional
annotation.
Based
on
my
implementation,
you
know,
if
that's
a
repetitive
string
exchange.
The
repetitive
string
is
something
you
could
just
indirect.
G
The
way
in
which
it
is
at
the
very
very
moment
if
you're,
remembering,
let's
say
last
ITF
in
a
Montreal
I
made
kind
of
so
we
had
the
one
draft
from
Hank
Smith
right
originally
and
then
essentially
it
was
not
too
complex,
but
let's
say
too
long
to
to
dispersive
and
and
things
like
that,
and
so
essentially
we
broke
it
down
in
a
few
suction.
So
one
we
are
executing
the
TLV
part.
G
Maybe
the
easiest
part
is
just
but
powerful,
and
things
like
that
power
is
pulling
the
sense
that
it
can
get
some
critical
mass
more
use
case.
It
can
a
little
bit
unlock.
You
know
BMP
right,
and
then
there
was
another
part
which
we
didn't
tackle,
which
is
the
restructuring
of
the
message
types
I
think
you
know
we're
all
a
little
bit
rotating
around
that.
Maybe
we
want
to
restructure
this
route
monitoring
message
and
things
like
that.
So
my
question
is:
do
you
also
think
sittings
in
this
direction?
G
H
C
You
mentioned
that
it
would
perhaps
be
good
to
have
write
some
of
these
things
down.
I
would
very
much
appreciate
it
if
you
did
commit
your
faults
to
paper
or
keyboards
and
would
share
with
the
group,
because
I
think
you
are
offering
us
foundational
insights
that
can
help
us
better,
develop
protocols,
and
it
is
much
appreciated
that
you
are
willing
to
share
that
with
us.