►
From YouTube: IETF109-OPSAWG-20201120-0500
Description
OPSAWG meeting session at IETF109
2020/11/20 0500
https://datatracker.ietf.org/meeting/109/proceedings/
A
C
B
B
C
Yes,
sir,
I
can
do
this.
Okay,
let's
start
hello.
Everyone
welcome
to
the
opposite,
wg
and
ops
aerial
meeting.
This
is
an
online
virtual
meeting
for
itf
109
as
usual.
We
start
from
the
note.
Well,
please
make
sure
you
understand
the
note
well
and
those
important
legal
issues.
Basically
all
the
contributions,
including
your
write-up,
the
presentation,
the
audio
video
need
to
follow
the
item
rules.
C
D
C
C
C
Good
here
is
the
working
group
status
and
during
the
past
three
months,
rfc
aka,
86
and
rfc
8907
are
published
for
from
this
working
group.
Congratulations
to
the
authors
and
thanks
to
the
contributors,
the
young
model
automation
framework
draft
is
now
in
the
rfcq.
We
do
not
have
much
thing
to
do.
The
tech
cn
data
model
is
sent
to
the
asg.
C
The
network
telemetry
framework
draft
finished
the
working
group
last
call
we
are
reaching
for
the
shop
at
the
right
half.
We
nearly
adopted
three
drafts:
the
vpn
common
yen
model,
mod
tls
profiles,
funding
and
using
geofeed
data
and
two
existing
drafts.
The
l2
and
m
and
l3
nm
are
going
well.
All
of
them
are
very
readable.
I
encourage
more
people
to
read
and
comment
and
joe
and
hank
do
you
have
anything
to
add.
B
I
I
think
the
I
think,
alex
clem
is
acting
a
shepherd
on
ntf,
as
I
recall,
or
maybe
it's
yeah.
I
think
it
was
ntf
and
we
will
be
hearing
from
the
l3
sm,
nm
l2nm
and
the
common
model.
Here
we
just
adopted
geofeeds.
I
I
think
randy
commented
that
the
submission
queue
had
just
closed,
but
but
now
that
it
reopened
it's
it's
been
rebranded
as
a
an
ops,
awg
document.
B
Everything
is
up.
All
of
these
slides
that
you'll
be
seeing
are
up
in
data
tracker
there.
There
is
a
ops
area
section
at
the
end
of
this
rob
was
telling
me
that
they
were
a
little
late
in
getting
the
slide.
So
I
imagine
if
they
have
anything
we'll
we'll
get
that
up
in
data
tracker
as
well.
For
you
to
look
at
yeah,
I
think
it's
all.
I
had
to
to
add
here.
F
B
G
G
The
draft
was
recently
adapted
by
the
working
group
after
several
comments
from
both
this
working
group
and
dls
working
group.
So
in
the
last
couple
of
revisions,
we've
been
updating
the
draft
to
address
these
comments,
so
I'll
be
going
over
these
major
updates
and
taking
any
further
questions
and
comments.
Next,
like
please,.
G
One
of
the
major
comments
that
we
got
from
the
tls
working
group
was
to
not
include
any
tls
values
which
we
were,
including
in
the
prior
versions.
The
main
reason
was
that
grease
values
are
supposed
to
be
used
for
test
purposes
to
test
the
extensibility
failures
in
case,
if
the
peers
are
not
able
to
understand
the
new
parameters
and
start
failing.
G
For
example,
if
a
details
parameter
is
not
specified
in
the
mud
tls
profile,
but
it
is
recognized
by
firewall,
then
in
that
case
it
would
recognize
that
as
an
unrecognized
software
or
on
authorized
software
and
can
take
remediation
action,
for
example,
in
this
case,
if,
if
the
chacha
20
cipher
stream
is
not
specified
in
the
mud
tls
profile,
but
the
parameter
is
already
known
to
firewall,
then
the
firewall
can
take
various
actions
either
it
could
be
blocking
the
flow
or
quarantining
the
iot
device
and
remediating
the
device
next
slide.
Please.
G
The
other
one,
which
is,
which
is
the
major
one
for
to
handle
cases
where
you
have
grease
values
or
any
other
unknown
values.
In
those
cases,
the
firewall
would
not
take
any
action.
For
example
in
case
where
the
charger
20
history,
cipher
stream,
is
not
specified
in
the
tls
profile,
and
it
is
unknown,
then
the
firewall
would
ignore
it.
So
this
is.
G
G
This
is,
this
is
a
this.
Is
the
problem,
probably
with
the
race
conditions
that
whether
the
iot
device
gets
updated
with
the
new
tls
extensions
or
tls
versions
versus
the
firewall
getting
updated
before
that?
So,
for
example,
if
the
iot
devices
get
updated
to
support
new
extensions
or
new
ciphers
and
the
firewall
is
not
ready,
then
what
would
happen
is
the
mud.
Tls
profile
would
get
updated.
G
The
same
applies
to
any
other
tls
extension
or
even
new
tls
versions.
For
example,
if
there
is
a
new
tls
version,
for
example,
is
1.3
and
it's
specified
in
the
mud
tailless
profile,
but
the
firewall
is
not
aware
of
it.
Then
it
would
be
triggered.
So
this
basically
ensures
that
both
the
administrator
of
the
iot
device
and
the
network
security
provider
are
aware
of
the
firewall,
not
recognizing
new
parameters,
and
if
the
firewall
is
not
readily
updatable,
its
protection.
Efficacy
is
going
to
decrease
with
time
next
slide.
Please.
G
We
have
also
updated
the
young
module
to
address
several
comments
that
we
received
from
med
and
others,
especially
to
make
sure
that
we
have
an
inr,
dtls
young
profile
to
include
the
dtls
versions
and
dtls
parameters,
and
those
values
are
being
used
in
the
acl
which,
in
turn,
is
used
in
the
mud,
tls
profile
next
slide.
Please.
G
Spk
insight
is
basically
pinning
a
specific
public
key
or
a
certificate
like
self-send
certificate
and
certificate
authorities
are
specific
to
each
iot
device.
We
have
seen
iot
device
based
on
manufacture,
make
and
model
use
certificate.
Specific
certificate
authorities
which
vary
from
device
type
to
device
type
and
those
values
have
to
be
defined,
has
to
be
maintained
and
defined
by
the
manufacturer
itself.
G
Inr
dtls,
profi,
tls
and
dtls
profits
does
not
maintain
any
registries
for
dtls
versions,
because
the
way
the
versions
are
maintained
today
is
because
of
extensibility
in
tls
1.3,
a
new
extension
has
been
introduced
in
which
the
version
is
defined.
So
that's
the
reason
they
are
not
maintaining
any
registry
for
that.
H
C
C
C
I
I
I
So
that's
why
we
we
have
already,
I
would
say,
a
fair,
stable
version
when
we
we
presented
the
document
to
the
working
group,
so
the
the
first
version
that
we
that
we
released
addresses
mainly
the
comment
that
we
received
during
the
the
working
of
last
call
said.
There
are
some,
I
would
say,
minor
editorial
ones
from
from
the
rule,
to
better
articulate
how
the
the
camera
vpn
model
will,
I
would
say,
can
be
reused
by
future
revisions
of
the
the
the
current
l3
service
model
and
and
il2.
I
I
We
would
like
to
be,
I
would
say
more
exhaustive
there
and
that
can,
I
would
say,
delay
the
publication
of
the
l3
l
training,
but
after
all
after
discussion
with
the
with
the
theme
and
also
with
the
implementers,
I
think
that's
as
as
as
we
are
just
defining
some
kind
of
library,
it's
just
fine
to
to
relax
this
conference
that
you
can
put
there
what
we
think
that
are
really
available
and
reusable
from
the
the
current
model.
So
we
updated
the
the
document
to
include
them.
I
I
would
say
specific
items
that
are
that
are
not
reused,
for
example
in
the
l3
nm
draft,
but
are
will
be
reused
in
the
there
was
also
a
comment
from
italy
about
the
the
the
overall
scope
of
the
draft.
He
proposed
that
we
not
respect
the
the
kind
of
types
and
the
group
technology
to
the
vpn,
but
to
define
it
as
a
service
generic
model
and
that
one
we,
I
think,
yeah
for
me,
that's
we
are
going
too
far
there.
I
I
I
I
Joe
has
already
sent
a
request
to
the
to
the
young
doctors
to
have
an
earlier
review
of
the
document
that
we
think
that's
we
we
start
to
have
something
which
is,
I
would
say,
in
in
good
shape.
Modulo
this.
I
would
say
this
happened
in
action
on
the
m,
so
we
hope
to
have,
I
would
say,
feedback
from
them
and
we
will
address
that
as
soon
as
we
receive
them.
I
B
B
Yeah,
okay,
cool.
I
wanted
to
make
sure
so
you
you
commented
on
the
thing
yeah.
These
will
be
they'll
go
through
last
call
altogether
and-
and
we
just
put
in
a
working
yang
doctor,
early
review,
I've
read
the
the
latest
common
model
document,
no
major
thoughts
on
my
part
as
a
contributor,
but
one
thing
I
noticed
is
there:
there
are
a
few
comments
in
there
early
on,
like
this
might
be
applicable
to
l2
xm's
or
something
along
that,
and
I
thought
I
like
that.
B
I
like
that
you
were
at
least
at
least
initially
starting
to
group
things
or
or
have
com
elements
that
that
one
might
use
in
this
type
of
model,
either
at
a
certain
layer
or
a
certain
type
of
yang
module,
but
it
seemed
to
get
lost
towards
the
end,
meaning
at
least
the
way
I
read
it.
I
things
seem
to
be
mixed
between
sms
and
l3
and
l2,
and
I
I
guess
my
suggestion
is
more
of
a
knit
really
is.
B
Is
I
like
that
organization
to
be
able
to
where
possible,
keep
things
side
by
side
where
they
make
sense,
so
that,
if
I'm
looking
for
things
that
are,
I
don't
know
what
the
best
kind
of
organization
is.
But
if
I'm
looking
for
things
that
are
more,
maybe
l2
versus
l3
and
then
within
that
you
have
nm
versus
sm.
B
I
A
Hi
good
morning
guys
so
now
that
med
has
presented
you
the
common
module.
Now
we
are
going
to
go
through
the
two
modules,
the
l3
and
the
l2
modules
that
use
this
one.
So
here
also,
you
have
the
g
tripos,
where
we
keep
all
the
issues
so
in
the
l3
and
then
preco.
We
keep
all
the
issues
for
three
names
in
the
20m1,
the
similar
form
too.
However,
we
decided
to
keep
all
the
junk
together
in
the
l3
nm
prepo
for
better
checking.
A
So
we
do
continuous
checks
on
the
on
the
junks,
all
the
of
the
three
modules
together.
Okay,
so
if
you
want
to
go
for
the
latest
code,
it
is
the
l3
name,
repo
that
holds
all
of
them.
The
common
l2
r3
okay.
So
next
is
like
this
okay.
So
first
I'm
going
to
tell
you
a
couple
of
slides
about
what
are
the
latest
in
the
changes
since
the
last
idf,
so
we
were
waiting
to
have
the
common
module
to
address
all
the
young,
all
the
young
doctors
of
your
comments.
A
We
also
had
some
clarifications
of
the
use
of
appendix
a
so
we
we
included
this
list
of
available
implementations,
so
we
just
follow
the
guidelines
for
rfc
6982
about
the
implementation
status
section.
So
we
put
all
the
clarifications
also,
we
did
a
lot
of
cleanup
of
the
of
the
groupings,
so
you
know
that
the
first
version
of
m3nm
had
a
lot
of
a
lot
of
groupings.
A
So
now
all
the
groupings
are
in
the
common
module,
so
here
we
are
reusing
all
of
them,
so
in
the
latest
version
available
in
indeed,
I
think
we
have
only
one
grouping
left
in
l3.
N1
is
a
just
a
pure
l3
specific
grouping
that
is
not
nm
grouping.
That
is
not
reusable
for
for
other
parts.
Okay,
so
this
new
young
module
uses
all
the
all
the
vpn
common
that
has
been
explained
so
also
we
added
some
text
in
the
draft
explaining
the
rationale
and
which
are
the
relation
with
this
coming
home
module.
A
Also,
we
added
some
section
on
the
sample
uses
of
the
other
3m
model,
so
to
explain
so,
for
example,
how
to
use
it
to
for
enterprise,
layer,
3dps
services
for
multi-domain
cases,
and
we
plan
to
add
some
some
more
here,
just
the
explanation.
Okay,
also,
we
added
some
completed
explanations
of
the
of
the
different
sections
of
the
draft.
So,
for
example,
we
explain
the
the
role
of
the
vpn
profiles
and
some
some
examples.
A
A
Er
also,
we
added
some
text
to
to
explain
the
underlay,
the
underly
transport.
You
know
that
the
underlying
transport
here
is
in
in
the
vpn.
What
are
you
using
to
er
between
the
pes?
So,
for
example,
if
you
are
using
traffic
engineering,
if
you
are
using
ldp
segment
route,
etc?
Okay,
then
these
complements
too.
There
is
some
work
done
in
the
tias
working
group
where
they
are
doing
the
extensions
okay.
A
So
if
you
choose
to
have
a
t
as
under
the
transport,
all
the
extensions
that
tell
you,
which
is
the
mapping
is
that
of
the
mapping
of
the
tunnels
to
the
to
the
service
itself.
That
is
done
in
tia's
working
group
extending
the
a
l3
nm.
Okay,
also,
we
had
an
issue
pending.
I
think
it
was
like
the
last
two
three
itfs.
J
A
A
So
we
have
just
in
this
version,
we
solved
the
all
the
open
issues,
a
indeed
house,
so
we
have
just
a
few
open,
a
few
open
issues
since
the
last
one.
So
you
see
that
I
have
number
here
that
is
in
indeed
half
so
so
you
see
we
are
in
the
180
something
just
open
because
all
the
previous
ones
were
were
close.
A
We
have
some
suggestions,
also,
for
example,
for
the
for
the.
If
we
want
to
incorporate
to
the
to
the
young
model
service
visibility
flag.
Okay,
so,
instead
of
we
are
just
using,
we
are
using
the
model
to
request
a
till
the
creation
of
a
new
series.
So
we
wanted
to
double
check
if
we
can
use
it
for
also
for
service
visibility,
not
only
creation.
A
A
There
are
some
manual
things
to
add
on
the
on
the
static
routes
also,
we
have
from
the
original
l3sm
and
we
have
the
access
to
the
content
service
to
the
cloud
service
provider.
So
we
need
to
double
check
whether
this
still
applies
also
to
the
network
model,
and
we
also
need
to
use
the
commentation
of
ipv4
addresses
in
the
and
ipv6
in
the
in
the
examples.
Okay,
so
with
just
minor
comments
here.
So
let's
go
to
the
next
last
slide.
A
So
so
with
this,
we
think
that
all
the
issues
that
we
have
within
the
qualification
of
the
last
draft
were
were
solved.
So
just
minor
issues
has
left
us
as
explained
er.
We
are
using
all
the
the
common,
the
common
module,
so
we
think
this
is
in
this
version
is
stable.
It's
not
gonna
suffer
major
changes,
so
it's
almost
ready
for
the
working
group
class
call
so
as
in
the
other,
as
also
said
in
the
common
module.
A
Okay,
so
for
the
l2nm,
as
in
the
previous
case,
we
updated
the
the
young
module
to
use
the
vpn
command
module
groupings.
Also
in
the
text
we
have
started
to
do
some
editorial
work,
to
explain
the
common
relation
with
the
draft
and
add
the
different
explanations
of
the
of
the
groupings
that
are
that
are
used
and
some
editorial
improvements.
So
we
explain
the
vpn
profiles,
the
signal
and
options,
the
vpn
networks,
connections,
etc.
A
A
So
next
slide,
please
so
here,
as
we
mentioned,
that
the
l3
name
was
very
stable
and
this
l2
name
is
much
stable,
but
there
is
only
one.
There
is
one
major
thing,
but
we
need
to
finalize
to
to
consider
the
the
draft.
Let's
say
stable.
Iran
is
the
complete
avpr
support.
Okay,
so
I
think
among
all
the
different
layer,
two
types
all
of
the
others
were
pretty
much
covered,
but
the
vpn
still
had
a
had
some
some
gaps.
A
So
in
order
to
support
the
vpn
creation
for
the
service
type,
we
need
to
cover
the
different
flavors
of
pva
vpn
vs
land
uspn,
the
classical
vpn.
We
need
to
add
the
internet
segment
identifier,
and
there
are
some
specific
service
parameters
like
the
english
regulation.
They
are
biproxy,
suppression,
anti-proxy,
etc.
So
there
are
particular
vpn
parts
and
also
we
need
to
cover
the
particular
pvp
service
parameter.
So
for
the
pvp
case
also,
we
need
the
pvb
vpn
flavor.
A
Also,
we
need
to
cover
the
rtrds
that
we
are
releasing
all
that
from
the
vpn
code
module
we
need
to
address
value.
Also,
we
will
use
that
for
the
vpn
common,
we
need
to
add
the
bridge
domain,
the
mod
type
and
also
we
need
to
add
all
the
I
am
backbone
identifier.
Components
to
include
them
here.
Next
slide,
please
so
also
related
to
the
to
the
vpn
people
studying
is
contributing
with
a
lot
of
issues.
So
here
I
just
put
a
sample.
A
Even
after
creating
these
slides,
there
were
more
comments,
reason
or
more
issues,
reason
in
the
jit
regarding
evpn.
So
you
see
that
still
we
have
quite
quite
a
few
work
on
the
vpn
okay
and
then
we
also
have
some
common
l2
things.
So,
for
example,
they
haven't
shown
how
the
present
type
is
different
from
the
access
priority,
when
we
were
requested
also
to
add
examples
of
the
l,
two
and
m
okay
so
similar
that
we
did
in
the
l
three
and
here
to
add
some
some
examples,
and
there
is
also
an
issue.
A
H
Just
as
a
participant,
so
just
a
quick
question,
I
I
think
you're
splitting
up
of
the
tree
output
in
the
documents
is
useful.
I
did
wonder
whether
or
not
it
might
also
be
useful
to
include
the
full
tree
out
put
in
the
appendix,
so
I
I'm
not
sure
I
feel
that
strongly
about
it,
but
it's
just
something
to
consider.
Maybe
it
might
make
it
too
long.
H
A
H
Well,
that
sounds
reasonable.
Then
that
sounds
like
reasonable
answer.
If
it
ends
up
being
so
far,
indented
due
to
the
depth
of
it,
then-
and
it's
not
useful,
then
that
makes
sense,
and
it's
always
possible
that
people
could
generate
this
from
tooling
fairly
easy
anyway.
So
that's
not
too
much
of
a
concern.
H
I
I
would
say
to
to
to
the
comments
from
moscow
that
this
this
will
be,
I
would
say
it
will.
It
will
be
split
over
tens
of
pages
and
it's
really
hardly
readable
and
personable
by
bed.
Readers
there's
also,
I
would
say
one
more
logistic
issue
there
is
that
the
the
current
tools
when
generating,
I
would
say,
the
the
the
young
tree
tables
we
will
end
with
the.
I
We
are
modifying
manually,
the
trees
that
you
can
you
can
you
can
you
can
pass
the
net
check,
so
it
would
be
a
really
a
nightmare
for
us
if
we
include
that
one,
because
we
won't
have
that
possibility
to
modify
manually
the
trees
and
so
on.
So
I
would
personally
avoid
having
that
the
default
tree
there.
We
can
put
it
on
the
github
and
we
already
have
a
copy
of
that
in
the
github
and
we
can
add
a
pointer
if
the
work
working
group
won't
decide
that.
I
I
If
we,
I
would
say
at
the
if
we
fix
a
medicine
or
did
not
to
say
that,
yet
if
by
the
middle
of
next
year
we
don't
have
a
stable
version
or
we
still
see
comments
on
the
ill-2
nm,
it
would
be,
I
would
say,
feasible
that
we
we
just
run
the
working
of
last
call
on
the
3m
and
the
the
common
model
or
we
we
have
to
hope
to
get
started
on
the
a2nm.
So
this
this
this
is
a
risk
that
I'm
seeing
on
on
the
set.
H
H
B
B
That
said,
I
think
there's
definitely
interest.
I
don't
think
leaving
l2m
off
would
would
cause
it
to
never
progress,
but
I
I
think
there's
there's
value
in
making
sure
everything
is
is,
is
properly
sewed
up
on
all
of
them.
That's
one
chair's
opinion,
but
it
looks
like
so
far.
I
don't
know
if
we're
gonna
get
many
more
10.
People
have
raised
their
hand
that
they
have
read
it.
B
B
B
So
it
seems
that
there
is
lots
of
hands
going
up
quickly.
I
mean
we
had
10
total
hands
raised
on
the
last
one.
We
have
seven
hands
raised,
no
hands
not
rays.
Eight
hands
raised
more
hands
going
up,
so
I
I
think
it's
worth
considering.
I
I
think
chances
are
if
we
put
this
out
on
the
working
group,
alias
that
that
chances
are
that.
That
would
be
the
case.
B
I
would
speaking
as
co-chair,
encourage
the
the
inter
the
the
the
people
in
the
working
group
working
on
this
to
to
work
through
those
issues.
Let's
see
if
we
can
get
some
some
more
reviews
like
a
and
we
talked
about
a
yang
doctor's
early
review
of
the
l2
and
m,
let's
see
if
we
can
get
some
of
those
issues
resolved,
but
it
sounds
like
there's
certainly
interest
in
in
getting
the
l3
nm
out
there,
assuming
that
we
make
sure
that
the
common
module
is
sufficiently
common.
I
Thank
you.
Thank
you,
and
one
last
I
would
say
information
is
that
we
have
many
implementers
that
are
involved
in
this
work
and
we
have
an
appendix
in
which
we
we
we
provide
a
pointer
to
to
all
to
each
of
these
implementations
and
all
this
information
is
available
on
the
github,
so
yeah.
So
this
is
a
joint
work
which
is
currently
done
with
the
involvement
of
mini
paper.
A
B
B
B
E
Okay,
this
draft
was
revised
during
adoption,
so
take
it
home
feed
it
and
be
nice
to
it,
and
it
should
be
good
to
you,
the
suspects.
I
don't
know
why
massimo
wanted
to
start
this.
I
did
most
the
drafting
work,
warren
and
eric
klein
who's,
too
modest,
to
be
here
on
from
google
brought
in
the
google
work,
which
you'll,
see
and
russ
did
the
security
stuff
next
slide.
Please
ipg
location
is
to
deal
with
country,
regulations
and
localization
etc.
E
I.E,
you
know,
there's
a
special
version
of
game
of
thrones
playing
in
washington
dc
now
and
you're
not
supposed
to
see
it
anywhere
else.
Next
slide,
please,
who
does
geolocation
here?
Are
the
organizations
providing
the
service
of
if
you
have
an
ip
address,
they
will
give
you
a
good
guess
as
to
where
it
is.
The
quality
of
the
guesses
vary
considerably.
E
E
If
you
go
to
watch
that
version
of
game
of
thrones-
and
you
can't
I.e
if
your
data
for
your
ip
address
are
incorrect,
you
have
to
contact
all
of
those
people
and
they
take
weeks
to
turn
things
around,
and
you
see
people
putting
out
pleas
on
anag
every
week
saying
I'm
in
bialystok,
and
I
can't
watch
whatever
next
slide.
Please.
The
basic
problem
is
that
this
is
uncoordinated
and
all
those
different
providers
of
information
are
kind
of
almost
doing
research.
E
So
there's
no
real
data
repository.
There
is
no
ground
truth.
Okay,
next
slide,
please!
So
how
do
they
come
up
with
their
guesses?
Heavily
used?
Dns
stated,
who
is
data
dns
in
the
sense
that
lots
of
routers
have
location
in
their
names,
etc,
etc?
Tons
of
strange
magic,
but
to
the
rescue
a
gang
of
pretty
much
googlers?
E
Who
have
this
problem?
Big
time,
of
course,
came
up
with
rfc
8805,
which
is
a
definition
of
a
csv
file
which
can
for
prefix
ranges
have
country
and
state
or
whatever
font
city,
and
that's
the
granularity,
because
finer
they're
worried
about
in
some
places.
If
you
get
down
to
the
postal
code,
it
reveals
personal
information
too
much,
so
this
is
about
the
limit
of
the
game,
but
rfc
8805
describes
geofeeds
files
next,
the
four
form
next.
Thank
you.
The
format
is
the
rfc.
E
E
E
E
E
E
E
E
So
what
we
propose
is
to
have
a
digest
of
the
main
body
of
the
file
of
piece
you've
been
looking
at,
is
digested
and
then
signed
by
the
private
key
of
the
relevant
rpki
certificate
for
the
covering
prefix.
This
is
optional
by
the
way,
of
course,
aaron
being
a
unicorn
doesn't
use
highneck
numbers,
they
use
knit
range,
but
it's
the
same
act
next
slide.
Please
here's
an
example
of
the
strong
signature.
E
Okay,
it's
now
because
it
is
signed
by
the
key
of
the
rpki
record
for
that
range.
That
signature
cannot
be
good
for
some
other
geofeed
pointer
into
this
file.
So
when
there's
a
signature,
it
can
only
represent
one
address
space
next
slide:
please
you
can
parse
bulk,
who
is
data?
The
rirs
all
provide
bulk
data
over
ftp,
et
cetera,
et
cetera.
E
E
E
B
E
B
C
K
K
If
you,
the
drop
packets
can
can
undergo
some
deep
inspection
and
the
some
metadata
can
be
can
be
fetched
from
these
drop
packets
can
be
sent
to
the
host
or
the
software
queue,
along
with
the
type
of
exception
that
that
that
has
invoked.
This
drop
and
some
metadata
in
this
case
like
in
and
out
interface
and
some
other
metadata
which
I'll
be
covering
in
the
in
the
next
slides
next
slide.
K
K
K
K
So
if,
when
the
packet
drop
happens
or
when
a
traffic
drop
happens,
what
is
the
reason
for
the
traffic
drop
which
flow
has
encountered?
This
drop,
which
includes
the
packet
content,
which,
which
gives
us
the
source
source
for
source,
port
and
destination
board
source,
ip
destination
ib
and
a
few
other
details
and
some
additional
metadata,
including
what
what
the
flow
direction
is.
What
the
next
app
index
is
input
and
output
interfaces
and,
and
a
few
other
details,
if,
if
needed
next
slide,
please.
K
So,
focusing
on
this
on
this
draft
we
have-
we
have
proposed
a
new
information
element
called
forwarding
exception,
called,
which
is
a
unique
identifier,
describing
the
the
reason
for
the
for
the
traffic
drop,
some
irregularity
or
some
traffic
drop.
So
we
have
this.
This
particular
forwarding
exception
code
can
can
have
different
data
records,
indicating
what
forwarding
error
has
caused
the
traffic
drop.
So
this
can
be.
We
have
identified
a
few
common
ones.
An
implementation
may
choose
to
encode
its
own
internal
device.
K
K
In
addition
to
the
forwarding
exception
code,
we
have,
we
also
had
the
need
to
export
what
the
next
stop
id
is.
A
next
stop
id
is
something
that
that
identifies
the
destination
inside
a
particular
device,
typically
represented
in
a
forwarding
path
as
an
index.
So
this
this
is
very,
very
useful
in
order
to
fetch
more
details
on
on
what
the
what
the
next
stop
in
the
next
hub
looks
like,
and
the
next
stop
that
the
packet
would
take.
K
So
in
order
to
do
some
deep
inspection,
so
this
this
next
stop
id
would
could
include
some
information
about
the
outgoing
interface
and
the
forwarding
features
configured
on
the
packet
path,
etc.
So
there's
a
unique
identifier
on
any
on
every
on
on
every
device,
so
this
this
is
something
that
will
be
really
useful
in
identifying
the
next.
The
next
stop
details
on
on
every
packet
next
slide.
Please.
K
It
includes
it
includes
some
of
the
some
of
the
fields
that
that
are
key
now
in
order
to
identify
the
which
which
devices
is
dropping
the
packets
and
and
which
flow
is
actually
encountering
this
crop,
so
it
can
be
represented
in
in
any
format
any
which
format
we
see
two
different
formats
here
and
it
any
any
number
of
fields.
Any
any
number
of
other
metadata
fields
can
be
added
to
this
template.
K
K
K
B
So
I
I
had
one
as
a
contributor
on
the
next
top
id.
I
I
wasn't
really
clear
on
what
that
would
be,
or
or
I
imagine
this
would
be
something
that's
very
vendor
specific
and
there
would
be
some
way
of
decoding
that
64-bit
value,
because
you
you
don't
really
give
a
very
prescriptive.
You
said
it
could
be
egress
interface,
it
could
be
other
forwarding
characteristics,
but
there's
nothing
that
I
saw
in
the
draft.
B
That
was
like
here's
an
example
or
anything
prescriptive
of
of
what
that
could
be,
and
I
know
in
one
template:
you
have
egress
interface
there.
So
I
imagine
there's
other
richness
that
that
would
give
you,
but
I
wasn't
clear
on
exactly
how
I
would
if
I
was
implementing
this,
how
I
would
populate
that.
B
L
This
is
hello
yeah.
We
can
hear
you
hello,
I'm
saying
that
this
is
okay
yeah.
I
I
log
in
from
hobby,
but
I
think
this
is
a
truly
a
useful
use
case
yeah,
because
we
know
that
in
the
ip
there's
always
something
the
forwarding
errors,
so
I
think
the
detailed
information
act,
of
course,
will
to
help
the
troubleshooting.
I
think
this
is
a
useful
use
case
piece,
yeah.
G
I
guess,
can
you
hear
me,
we
can
yeah
hey
I'm
one
of
the
co-op
for
this,
so
I
think
there
was
a
question
related
to
what
does
the
next
stop
actually
mean
right.
So
I
I
just
wanted
to
add.
So
imagine,
let's
say
in
a
normal
forwarding
path.
A
packet
arrives.
You
do
a
lookup
in
the
forwarding
table
right.
Typically,
the
result
of
the
lookup
is
a
next
stop.
G
The
tech
top
is
nothing,
but
it
represents
recording
path
that
the
packet
will
eventually
take
and
it
is
supposed
to
translate
into
packet
going
out
of
a
specific
interface.
So
obviously
packet
is
able
to
successfully
go
out
of
that
interface.
Then
you
will
also
have
the
ingress
interface
material
time
permission
set,
as
is
displayed
in
the
template
right,
but
let's
say
the
drop
happens
somewhere
in
between
right.
You
need
to
know
which
path
the
packet
was
taking.
So
next
stop
id
in
that
case
can
be
that
id
with
internal.
G
Your
system
represents
that
forwarding
path
and,
let's
say
a
bunch
of
show,
commands
on
your
node
or
or
metadata
that
you
have
would
wear
on.
The
controller
can
be
used
to
correlate
saying
that
this
next
hop
id
actually
represented
this
outgoing
interface
and
therefore
the
packet
during
this
process.
B
M
K
K
K
N
N
First
is
the
quickly
reporting,
especially
the
adp
protocols,
containers
need
to
be
reported
reported
quickly
and
the
second
is
the
high
performance
means
processing,
maybe
the
binary
encoding.
It
has
the
more
better
the
performance
than
other
encoding
and
the
study
is.
We
want
to
get
a
protocol
that
is
the
easier
to
standardize
and
analyze,
though
by
the
monitoring
scope
at
first
we
want
to
support
the
includes
the
adp,
ldp
and
svt
and
river,
and
so
on.
N
N
N
The
cause
may
be:
systematic,
reflux
or
acid,
snapship,
driving
or
driving,
and
so
on,
and
another
use
case
is
sdb
and
secondation
failure
during
the
isis
flooding.
However,
sometimes
the
lsp,
the
synchronization
feeling
happens,
the
cost
maybe
has
a
lot.
Maybe
the
first
day
the
identity
is
not
creative
advice.
Is
the
white
history
or
transmission
error
or
is
received,
but
now
the
current
process?
N
Okay,
so
we're
recording
the
accordion
that
we
introduce
the
case
under
the
original,
the
motivations.
So
we
we
stress
in
the
two
solution
options.
The
operation
one
is
bmp-like.
We
can
also
define
the
new
bmp
message
types
and
the
game
from
work.
Our
new
protocol
and
open
tool
is
a
telemetry
based.
We
can
define
the
young
module
for
s
for
assist
the
message.
L
Robin
hello
yep,
we
can
hear
you
okay,
robin
from
javi.
I
added
some
add
some
of
the
points.
Besides
the
presentation,
in
fact,
that
we
truly
have
this
work
two
years
ago,
but
we
later
we
we
explained,
we
found
that
there's
a
lot
of
a
lot
of
things
that
happens
in
the
routine
area,
so
that
these
are
the
points
that
we
truly
identify.
The
possible
use
cases
that
that's
necessary
to
export
the
idp
protocol
data.
L
B
B
I
think
people
from
I
want
to
say
grow,
as
I
recall
commented,
so
it
might
be
good
to
get
just
to
get
their
take
on
this
as
well
from
the
routing
area.
It
sounds
like
maybe
you've
already
done
some
of
that,
but
bringing
that
into
the
the
working
group
would
be
would
be
useful
to
trigger
or
catalyze
some
of
those
conversations
on
the
list.
L
H
L
I
understand
your
point
in
fact
in
this
draft
this,
in
order
to
propose
this
is
the
new
protocol
here
is
also
mentioned,
because
in
this
draft
we
propose
that
the
reusing
the
pmp
for
this
for
this
requirement
user
just
to
extend
several
the
message
type
only
used
for
the
for
the
idp.
So
this
is
the
this.
Is
the
proposal
in
this
draft,
and
also
you
mentioned-
that's
the
possible.
L
This
is
the
young
model
yeah,
because
we
also
use
the
learned
discuss
with
some
of
the
young
model
experts
and
also
because
of
a
little
concern
is
that
to
export
the
the
protocol
the
protocol,
the
package
through
the
model
I
we
are
not
experiencing
enough
in
this
one,
so
we
would
like
to
collect
the
more
feedback.
Yes
through
this
the
main
list.
Well,
thanks
very
much
for
your.
H
Just
just
to
add
one
more
comment
to
that,
then
I
again
it
goes
back
to,
I
think,
focus
on
on
clearly
what
the
data
is,
that
you
want
to
export,
and
then
that
might
help
guide
you
with
what
the
right
answer
is.
Is
there
may
be
that,
actually
that
you
want
to
try
and
do
it
both
ways?
I
have
bmp
extensions.
If
that's
possible,
I
don't
know
bmp
very
well
and
also
define
it
in
yang.
One
other
comment
was
about
the
encoding
performance
of
using
xml
json
and
a
different
path.
H
L
B
C
O
O
Oh,
it
seems
not
complete
with
the
figure,
but
actually
this
figure
is
from
rp
41
76,
it's
about
the
framework
for
layer,
3,
vpn,
operational
and
management,
and
this
figure
is
about
the
customer
view
of
the
different
vpn
manager
function
and
you
can
see
on
the
bottom
of
this
figure.
There's
a
vpn
assurance
function
there.
So
it
means
that
the
the
customer
doesn't
aside
from
the
the
older
implementation.
O
O
O
O
Given
the
working
group
has
already
worked
on
the
modeling
based
framework
for
automation
of
service
and
network
management,
we
can
see
that
the
figure
is
from
the
automation
draft
and
and
there
three
nm
and
layers
three
two
nm
have
have
been
developed
to
fit
for
the
service
delivery,
automation
process,
but
the
performance,
monitoring
and
notification
is
still
missing
there,
so
this
draft
is
trying
to
fill
this
gap,
so
this
is
the
our
function
of
this
draft.
So
next,
please
next
slide.
Please.
O
Our
modeling
cons
approach
is
to
augment
rc
83
45
because
it
has
defined
the
physical
network
topology.
So
our
thinking
is
we
all.
We
can
augment
that
dropped
with
a
more
vpn
performance,
monitor
data
to
extend
it
on
it.
So
we
can
see
a
whole
picture
of
the
vpn
services
on
the
performance
monitor
part.
O
O
Our
proposal
is
to
extend
the
nodes
and
sometimes
links
or
termination
points
with
the
corresponding
vpn
data
on
it.
So
in
that
way
we
can
not
only
associate
the
vpn
services
via
the
underlay
network
topology,
but
also
we
can
see
on
on
that.
On
top
of
that,
what
the
current
european
statistics
is
like
what
kind
of
topology,
and
what's
the
current
european
routine
pair
on
each
site,
the
usage
later
on
that
and
on
the
bottom.
O
O
This
draft
has
been
discussed
in
last
ietf
meeting
and
also
we
also
give
some
also
proposed
to
be
discussed
in
one
of
the
layer,
three
and
them
working
core
meeting,
so
we
have
some
comments
from
there,
so
we
updated
the
draft
to
satisfy
those
comments.
So
we
think
this
draft
is
try
to
fill
the
missing
pieces
of
the
whole
closed-loop
yarn-based
system.
O
B
If
we
do
a
last
call.
So
if,
if
you
could
even
bring
it
and
announce
it
talk
about
some
of
the
issues
that
you've
address
some
of
the
conversation,
that's
happened
on
those
core
calls.
That
would
be
very
useful
to
get
some
recorded
conversation
recorded
discussion
about
this.
So
then
we
can
we
we
can
get
to
calling
for
a
working
group
consensus
on
adoption.
P
P
Now
this
is
an
update
of
a
previous
draft.
The
this
draft
focuses
far
less
on
mud
and
far
more
on
s-bombs
and
how
to
share
the
introduction
has
been
rewritten
to
make
that
clear,
but
largely
speaking,
the
content
in
terms
of
the
the
model
for
mud
is
the
same,
and
we
have
the
definition
of
the
with
a
well-known
suffix
defined.
The
security
considerations
have
been
added
to
we
there's
one
or
two
more
mechanisms
we
want
to
add
in
terms
of
being
able
to
advertise
different
sorts
of
retrieval
mechanisms.
P
P
B
D
Yeah
as
an
individual
hi
elliot,
you
were
talking
in
the
last
slide
about
retrieval
and
some
hints.
Maybe
I
am
aware
that
stephen
bangert
and
dave
waltermeyer
from
nist
were
introducing
the
rolly
mechanism
to
retrieve
software
inventory
related
information.
Maybe
that's
that's
something
to
look
at
here.
P
Yeah
I
mean
so.
The
the
purpose
of
this
work
is
to
point
at
the
different
types
of
mechanisms.
There's
not
going
to
be
a
single
one,
but
I
think
it's
probably
you're
right.
We
should
make
sure
that
we're
coordinating
with
them
this
draft
by
the
way
is
co-authored
by
scott
rose,
also
from
nist.
So
I'll
make
sure
that
he's
talking
to
his
colleagues.
B
P
B
B
H
B
H
B
E
H
That's
good
yeah!
Okay,
all
you
thank
you
so
so
so
welcome
to
the
ops
area,
part
of
the
meeting
and
from
warren
I-
and
I
think
the
main
thing
we
would
like
to
to
discuss
here
is:
I
have
some
discussion
on
the
itops
russian
group
charter
that
we're
trying
to
charge
at
the
moment.
I
would
also
like
to
mention
that
warren
and
I
having
an
ops,
ops
area
ads
meeting
after
this.
So
that's
on
the
agenda.
H
If
anyone
is
interested
in
talking
to
warren-
and
I
there's
an
opportunity
I'll
try
and
remember-
to
put
a
link
into
that
at
the
end
of
this
as
well.
So
if
anyone
wants
to
any
further
discussion
issues
with
warren-
and
I
there's
an
opportunity
after
this
meeting
during
the
break
so
so
to
give
some
background
here-
go
to
the
next
slide.
H
H
So
there's
been
discussion
about
having
some
some
sort
of
ops
or
iot
based
working
group
and
for
quite
a
long
time
in
the
sg
long
lot
longer
than
before.
I
joined
and
in
the
last
four
months
or
so
warren,
and
I
have
been
trying
a
lot
harder
to
try
and
get
that
that
charted
and
set
up,
and
I
think
we
are
almost
over
the
hill
now.
But
it's
but
worth
discussing.
H
The
aim
of
this
is
to
really
have
a
focal
point
for
discussion
of
issues
related
to
iot
operational
issues
and
also
trying
to
act
as
almost
like
a
coordination
point
where
lots
of
different
work
is
happening
in
the
ietf
and
protocols
related
to
iot.
But
sometimes
it's
hard
to
coordinate
all
of
those
or
know
what's
going
on.
H
And
the
idea
here
for
iot
ops
is
to
have
a
working
group
where,
where
that
can
also
be
coordinated
in
some
way
and
discussed
and
things
so,
people
know
what's
going
on
and
gives
an
opportunity
for
people
outside
of
iit
outside
of
ietf
to
be
able
to
bring
new
iot
related
work
into
the
iatf.
If
they
don't
quite
know
where
it
should
go
so
at
the
moment,
there's
a
perception
that
it's
sort
of
quite
hard,
if
you're
external
to
itf
and
I've
got
work
related
to
iot
to
know
where
to
bring
it.
H
There's
no
sort
of
focal
point,
and
the
aim
of
this
working
group
is
to
try
and
do
that.
It's
a
bit
different
from
a
regular
working
group
in
the
sense
that
it's
expected
to
be
a
bit
more
discussion
focused
and
and
related
rather
than
just
working
on
producing
documents.
So
it
has
a
bit
more
of
a
mops
feel
if
anyone
and
if
you're
aware
of
mops
but
the
expectation
is
it
can
do
some
work.
So
it's
okay
for
it
to
be
discussing
informational
documents
or
bcps
and
to
be
discussing
potential
new
work.
H
H
So
some
discussion
points
it's
worth
saying
that
there's
actually
been
some
further
discussion
this
week
on
this,
and
I
think
we
sort
of
resolved
some
of
this.
I
believe
the
general
agreement
between
the
discussion
we've
had
is
that
is
that
still
should
not
do
protocol
work
directly
and
instead
it
says
here
perform
a
dispatch
function.
I
think
again,
the
word
dispatch
isn't
necessarily
the
best
choice
and
we
might
take
that
out
of
the
charter.
H
H
H
Q
Hi
yeah
thanks
for
this,
so
this
this
has
been
wait
a
lot
more
than
the
nine
months.
Something
like
this
should
I
take
the
most
so
so
I
I
do
think.
The
the
one
area
that
you
know
on
on
quick
look
I
didn't
see
quite
was
that
you
know
the
aspect
of
toi
from
you
know:
iot,
application
solutions
to
you,
know
people
doing
the
network
layer,
part
or
the
protocol
stuff
and
vice
versa.
I
think
that
would
be
a
really
cool
thing
if
we
could
get
more
of
that
right.
Q
Q
During
this
enrollment
discussions
we
had-
and
I
think
that
equally
applies
to
you-
know
routers
and
switches
and
all
the
other
networking
gear
we
had
so
far,
but
I
don't
think
we
have
traditionally
called
routers
and
switches
iot.
You
know
big
service
provider
core
router
also,
but
I
think
a
lot
of
the
you
know.
Q
H
Okay
to
to
answer
both
those
two
points
on
the
first
one:
yes,
it's
definitely
a
desire
for
people
to
bring
like
tois
and
information
from
other
places
here,
so
so
that
is
one
of
the
desires
that
this
is
a
forum
where
people
can
make
those
presentations,
and
that's
that's
actually.
One
of
the
reasons
why
we
wanted
it
to
be
a
working
group
rather
than
just
a
mailing
list,
is
to
have
that
timely
agenda
such
that
that
those
presentations
could
occur.
So
so
that's
that's,
definitely
a
goal
here.
H
I
don't
know
whether
it's
helpful
to
have
anything
in
the
chat
related
to
that
or
not
so
that
so
that's
a
question
to
have
or
whether
it's
sufficient
just
to
be
able
to
understand.
What's
there
in
terms
of
the
second
question
in
terms
of
defining
what
iot
is,
I
think
we
want
to
try
really
hard
not
to
do
that,
and
I,
I
guess
I've
given
some
partial
definition
of
what
it
means
in
this
in
this
case,
and
I
think
we
could
be
fairly
flexible
with
its
scope.
H
I
think
mostly
people
will
will
know
it
when
they
see
it
and
we
don't
need
to
worry
too
much
about
it
and
and
give
the
chairs
the
working
group
some
flexibility
in
terms
of
what
they
define
iot
and
if
it
looks
like
it's
becoming
going
out
of
scope,
then
we
can
rein
it
in
again,
but
I
think
for
the
moment,
it'd
be
better
just
to
have
a
loose
definition,
see
how
it
progresses.
And
if
we
need
to
tweak
anything
after
after
six
months
or
a
year,
then
we
can
do
so.
H
F
So
then,
to
largely
agree,
I
think
that
you
know
we've
been
trying
to
get
something
like
this
done
for
a
very
long
time.
We
keep
running
into
the
perfect
being
the
enemy
of
the
good
for
getting
it
set
up
and
so
getting
something
started.
So
we
can
at
least
begin
discussions
and
then
you
know
recharge.
I
want
to
prove
that
we're
not
completely
crazy,
I
think,
would
be
a
safer
way
to
go
for
obvious
reasons.
D
D
H
So
my
answers,
I
would
assume
not.
I
would
assume
that
the
iot
directorate
still
serves
very
useful
purpose
for
doing
reviews
of
documents
that
iot
related
I'd,
rather
those
go
to
an
iot
directorate
rather
than
coming
to
this
working
group.
So
I'd
see
that
continuing,
I
I
don't
know
exactly
everything
that
goes
on
in
the
iot
directory.
I've
only
joined
it
relatively
recently.
I
know
some
of
the
sort
of
discussion
and
coordination
is
happening
there.
It
may
end
up
that
that
this
is
a
better
forum
for
that.
If
that
answers,
your
questionnaire.
H
F
P
I'll
just
be
brief
and
say
that
I
I
think
this
is
perfectly
fine
idea.
I
think
it's
actually
way
overdue
and
I
I
think,
warren
and
and
rob
and
all
of
those
preceding
area
directors
have
taken
a
swing
at
this.
The
the
text
to
me
is
is
good.
The
only
thing
I
will
just
add
is
that
this
I
I
do
view
the
iot
ops
stuff
more,
as
you
know,
to
make
sure
that
the
the
left
two
aspects
right.
P
It's
a
locus
for
new
work
so
that
you
know
people
want
to
come
into
the
ietf.
They
can
at
least
hear
about
what's
going
on
in
iot
and
then
maybe
bring
some
work
along
there
on
their
own.
The
second
is
to
keep
us
from
tripping
over
ourselves
and
and
to
that
end,
there's
just
approving
the
working
group
will
get
us
there.
We
will
need
it's
necessary,
but
not
sufficient.