►
From YouTube: IETF112-OPSAWG-20211109-1200
Description
OPSAWG meeting session at IETF112
2021/11/09 1200
https://datatracker.ietf.org/meeting/112/proceedings/
B
D
I
manage
the
slides
there,
we
go,
they
just
took
some
time
to
process
and
they're
out
of
order.
D
All
right
well
we're
short
a
chair,
but
it's
7am,
my
time
noon,
utc!
So
hank!
If
you
want
to
kick
us
off,
I
guess
we'll
get
started.
A
Yes,
another
problem,
so
I
anticipated
hello
everybody.
This
is
our
ietf
112,
joint
ops
area
and
ops
area
working
group
meeting,
and
we
have
some
logistics
prepared
for
all
of
you.
Just
there's
a
red
text
here
that
tells
you
everything
you
say
and
post
and
utter
here
is
being
recorded.
A
A
Please
be
aware
that
if
you
are
uttering
anything
that
is
about
ipr
and
and
and
some
other
controlled
content
and
ip
here,
be
aware
that
that
disclosing
this
here
might
create
a
conflict,
so
take
care
of
that
we
will
record
everything
like
the
chat
and
and
the
own
or
something
is
happening
here
on
my
side,
the
chat
and
the
participants
and
everything
and
there's
a
lot
of
links
at
the
bottom
of
this
page
now.
A
A
So
this
is
the
in
addition
recently.
So
my
assumption
is
some
discussions
in
the
past
three
months
haven't
been
as
polite
as
they
could
have
been
so
so
I
think
we
are
striving
towards
a
constructive
discussion
and
I
think
that
we
all
expect
each
other
to
behave
accordingly.
A
So
there
are
some
professional
standards
here,
and
I
think
I'm
just
stating
the
very
obvious-
and
I
haven't
seen
anything
here.
That
is
the
question
about
that.
But
this
is
an
addition
to
our
our
notes
here
right
today
and
please
be
aware
of
that
again
and
there's
a
copyright
and
the
patents
guidance
as
a
best
practice,
if
you're
not
really
sure
how
that
works.
Please
look
that
up.
A
So
yeah,
as
this
is
all
our
online
meeting,
we
are
really
hoping
to
get
back
to
the
face-to-face
and
the
I
don't
know
screaming
in
their
faces
like
at
hand.
At
the
moment
this
is
not
possible.
Is
there
so
we
have
a
jabber
room
if
you're,
if
you're
familiar
with
java,
please
make
use
of
that.
A
There's
a
participation
guide,
how
to
use
the
meat
echo
if
you're
not
familiar
with
that,
but
apparently
you're
here
so
until
now,
I
guess
you've
crossed
that
threshold
already,
if
you're
experiencing
problems
with
that
there's
another
link.
I
think
that's
more
important.
That's
about
issues
if
you
find
something
really
annoying
here.
Please
raise
an
issue
on
this
link
below
here
at
the
bottom
of
the
slides
and
otherwise
when
you're,
not
speaking,
that
might
be
obvious.
A
Try
to
mute
video,
I
think,
is
not
a
big
of
a
problem,
but
if
you
don't
want
to
be
in
the
center
of
the
attention
also
turn
off
your
video,
because
all
of
this
is
recorded
next
slide.
Please.
A
Yeah
now
it's
us
our
tyrann
joined
us,
so
we
have
three
chairs
here
in
the
up,
say
wg
and
we
have,
I
think,
prepared
people
to
take
individuals
to
take
minutes
and
to
read
the
java
scribe.
So
this
is
a
call
to
the
group.
Now.
D
A
Excellent,
yes,
I
prepared
a
skeleton
minutes
so
so
insert
something.
Here
is
my
my
fault,
so
I
guess
it's
a
small
kind
of
guidance
yeah.
If
anybody
wants
to
follow
this
meeting
on
the
note
side,
please
follow
the
notes
link
here
in
the
the
slide
deck.
It's
also
on
the
data
tracker,
of
course,
and
you're
with
us
in
the
mid
echo.
So
that's
apparently
clear
next
slide.
Please.
A
Okay,
so
now,
in
the
past
four
months
we
made
yeah,
there
was
progress
and
this
is
a
busy
group.
As
most
of
you
are
aware,
so
we
published
a
new
rfc
which
is
9105.,
I'm
really
happy
to
see
tacx
plus
being
something
you
can
now
read
and
rely
on.
Thank
you
for
guiding
that,
through
the
gateway
function
that
is
isu
and
r48,
I
think
that
took
a
while
and
congratulations
to
authors
and
editors
here.
So,
on
the
other
hand,
here
we
have
something
that
is
already
an
irc
editor
q.
A
I
think
that
that's
just
now,
let's
work
anymore,
so
so
your
thumbs
pressed
that
there's
nothing.
That
is
a
threshold
there.
We
have
something
recently
being
moved
to
isu
publications
which
the
telemetry
id
I'm
hoping
to
see
progress
there
and
but
I'm
not
really
concerned,
and
I
can
I'm
happy
to
announce
that
I
think
that
we
agreed
on
consensus
here
in
the
working
group
with
the
l2
and
m
and
just
now
adrienne
is
in
the
queue.
I
guess
you
might
have
some
comments
on
this
as
an
ise.
E
I
am
working
on
this.
It's
a
a
stunningly
long
document.
So
sorry
it
takes
a
while
to
review
and
I'm
pleased
the
editor
is
working
with
tom
fetch,
also
addressing
some
comments
as
they
go
along.
So
I
I'm
hoping
to
complete
my
review
of
this
by
the
end
of
itf
week,
provided
that
the
itf
meeting
is
suitably
boring.
A
Which
is
I'm
not
commenting
on
this
so
probably
but
yeah?
I
I'm,
I
don't
see
any
hard
blockers
there.
Thank
you
adrian
for
taking
your
thorough
time
for
this
as
a
shepherd.
A
Is
it,
though,
okay?
So
that
might
be
a
error
on
my
part,
because
I
didn't
see
the
editor
queue
for
vpn
in
the
track
card.
To
be
honest,
but
okay,
then
we
have
two
options
for
this.
So
thank
you
for
adding
that
taran
and
so
so,
where
we
are
so
this
is
a
busy
pipeline.
As
you
can
see,
we
have
multiple
stages.
A
All
of
them
are
populated
and
utilized,
and
we
recently
adopted
two
other
ids
upon
the
licensing
content
and
about
the
historical
content
that
is
pcapp
and
we
will
have
specific
time
slots
assigned
to
that.
Looking
at
the
time,
I
really
have
to
go
far
faster
here.
Please
go
to
the
next
line,
so
these
are
just
agenda
items
so
pretty
much
you
can
see.
This
is
a
recap
of
the
what
we're
doing
here
today.
We
have
we're
going
with
administrative
first.
This
is
like
one
minute
left
for
me.
A
Basically,
and
then
we
go
through
the
adopted
items.
Next
slide,
please
again
a
lot
of
more
adopted
items
and
I
am
not
sure
how
elliot
is
going
to
do
this
in
two
minutes
but
sure,
let's
try
that
out
and
then
the
next
slides
we
have
the
related
work.
There's
also
a
lot
of
packed
agenda
here.
The
agenda
really
had
to
be:
let's
call
it
orchestrated.
A
There
was
a
lot
of
demand
for
time
and
I
think
it's
it's
great
to
see
all
of
this
contributions,
but
we
really
have
to
make
sure
that
time
next
time,
please
is,
is
taking
care
of.
So,
as
you
can
see,
we
might
interrupt
when
you
are
taking
too
long
and
typically
we
we
we'd
like
to
have
a
good
discussion
here,
but
today
I
guess
we
have
to
be
more
strict
than
usual.
A
So
sorry
for
that
in
advance,
but
sometimes
we
will
just
interject
and
say
next
presentation,
please
so
there's
in
the
end,
a
a
a
ephemeral
number
of
minutes
for
warren
rob
to
talk
about
the
office
area
agenda.
I
think
they
might
compress
that
a
little
bit
so
do
we
have
so
we
can
have
an
open
mic
in
the
end
and
wrong.
Yes,.
D
So
so
the
just
real,
quick,
the
the
ads,
have
said
that
if
they
need
the
time,
if
anyone
has
something
and
we'll
remind
you
an
hour
into
this,
if
anyone
has
something
just
put
it
in
the
chat
and
we'll
make
sure
there's
time
to
discuss
that,
if
not,
we
can
use
some
of
that
10
minutes
to
as
buffer
as
needed.
A
Yeah
cool
exactly
so
so
if
you
have
something
addressing
to
the
ops
area
directly,
which
is
the
joint
meeting,
of
course,
but
the
joint
means
a
little
bit
lopsided
thing
to
the
upside
wg
today.
So
with
no
other
words
from
my
side.
Let's
go
to
the
first
presentation
here
and
I
guess
it's
take
it
away.
G
This
is
a
picture
of
a
prototype
that
was
done
some
time
ago
on
this
assurance
graph.
Let
me
tell
you
that,
with
the
second
prototype
of
this
now
so,
okay
enough
for
the
intro
next
slide,
something
that
we
added
in
version
two
of
the
architecture
draft
is
that
we
made
it
clear
that
we
have
a
dag
directed
as
a
graph
by
adding
arrows
to
to
the
edges
there.
G
We
received
the
the
feedback
and
the
right
feedback
actually
from
elliot
and
and
and
kiriti
telling
that
in
some
situation
you
might
have
some
circular
references
circular
dependencies
into
your
graph.
The
example
that
was
mentioned
was
like
okay,
specifically
in
case
of
cloud
native
cloud
native
applications
right,
so
you
might
have
containers
and
vm
they
might
depend
on
dhcp
or
dns.
G
So
we
we
thought
about
thinking.
We
thought
about
having
a
simpler
example.
So,
typically,
an
engineer,
a
is
defining
interface
depends
on
the
link,
but
an
engineer
b
is
defining.
The
link
depends
on
the
interface
whenever
we
need
to
merge
those
two
smaller
assurance
graph.
Well,
we
will
have
an
issue
there
or
circular
dependency
and
that
that's
a
problem.
So
first
thing
is
that
iliad
and
kiriti
were
right.
It
could
happen.
G
E
f
will
depend
on
the
top,
so
from
a
point
of
view,
so
from
the
top
of
the
graph,
we
would
have
the
same
set
of
dependencies
and
the
same
node
for
c
d,
e
and
f.
So
this
is
not
part
of
a
standard.
This
is
a
proposal
to
mention
that
whenever
the
orchestrator
detects
the
circular
circular
dependencies,
he
should
not
allow
that
and
there
is
a
way
to
to
to
to
change
the
graph
to
accommodate
the
problem.
G
G
So,
what's
left
to
be
done
in
the
next
slide,
the
one
open
issue
we
have
in
mind
is
to
align
the
the
technology
was
the
two
nmrg
draft,
specifically
the
one
about
the
concept
and
definition
of
intent
based
networking
those
drafts
are
finalized
now,
so
we
were
good
on
that
front.
So
there's
something
we're
going
to
do
and
I
see
a
lot
is
in
the
in
the
line.
Let
me
go
for
the
last
slide
and
then
get
elliot's
feedback.
G
So
I'm
sure
that
you
guys
the
chairs
are
going
to
ask
right.
But
what
is
the
situation
next
steps
so
first
points.
Let
me
report
on
the
non-results
of
the
non-hackathon
meeting
that
we
were
not
having,
but
we
were
thinking
about
having
a
hackathon
about
the
how
to
combine
the
house
of
different
subservices
and
how
to
compute
the
status
of
the
service.
G
So,
typically,
whenever
we
got
like
an
mbls
vpn,
it
could
be
hub
and
spoke
or
it
could
be
fully
meshed.
So
what
do
you
report
as
a
combined
health
in
those
two
different
scenarios?
Well,
it's
not
that
obvious!
Basically,
the
answer
is,
it
depends,
so
I'm
stressing
this
because
we,
we
still
believe
it's
something
important
that
we
want
to
do
and
it
might
be
part
of
the
next
hackathon.
G
G
We
need
to
do
a
graphing
slot
message
now,
I'm
not
sure
if
those
two
would
be
part
of
the
same
draft
or
a
different
one
or
even
solidized,
but
these
are
things
that
we
that
we're
thinking
of
now
to
answer
the
question
that
the
chairs
might
be
asking
okay.
So
what
is
the
status?
I
believe
that
by
the
next
ietf,
if
no
more
issues
are
discovered,
it
would
be
time
to
last
call
those
two
drafts
and
I'm
done
so
eight
more
minutes
to
go
any
questions
or
feedback.
I
see
one
from
from
elliot.
C
Thanks
thanks
very
much
benoit,
I
think
the
strap
remains
incredibly
important.
Actually.
C
Really
incredibly,
so
I
just
I
can't,
I
can't
emphasize
it
enough
thanks
for
the
changes
just
in
terms
of
the
graph
transformations,
I
think
one
of
the
things
that
would
be
very
useful.
Would
I'm
not
sure
if
the
draft
has
it
yet
would
be
to
show
what
those
transformations
mean
operationally
in
terms
of
giving
maybe
an
example
or
two,
and
we
talked
about
dns,
maybe
maybe
follow
through
with
the
dns
example
as
to
what
that
means.
G
C
G
C
G
J
D
I
had
a
maybe
a
related
question
as
a
as
a
just
an
individual
contributor
on
your
level
of
indirection,
as
michael
put
it.
How
is
that
programmatically
determined?
How
do
you
decide
what
needs
to
be
inserted?
Is
that
top
level
service
to
remove
the
to
remove
the
loop
or
remove
the
circular
dependency.
D
G
Very
good,
so
let
me,
let
me
add,
some
more
text
to
it
now.
This
is
just
a
proposal
on
how
to
solve
it,
but
I
agree
with
you
what
I
call
an
empty
shelf
in
there
should
be
more
specified
I'll.
Take
that.
A
Yeah,
this
is
saying
as
a
contributor
also,
this
is
a
composite
service
problem
right,
so
identification
of
subservices
and
and
composition
of
sub-services
seems
to
be
of
essentially
here
so
so
that
is
something
that
should
be
transparent
around
all
the
consumers
of
this
information
and
you're,
going
to
do,
telemetry
and
and-
and
I
think
it's
very
important-
to
have
a
believable
and
and
and
sustainable
trustworthy
assertion
about
what
these
services
are
and
how
they
are
composed.
G
Okay,
I
will,
let's
not
forget
we
made
this
framework
open
so
that,
let's
see
multiple
controllers
with
multiple
part
of
the
graphs,
then
they
could
just
combine
these
and
if
all
of
them
depends
on
you
know
dns
or
dhcp.
This
is
the
same
one.
So
it's
actually
a
feature
that
you
could
combine
graph
from
different
sources
and.
A
K
This
is
as
a
contributor-
I
guess,
I'm
speaking
it's
just
one.
I
haven't
read
the
latest
version
of
draft
benoit,
but
I've
noticed
in
terms
of
removing
the
circuit
dependencies
rather
than
forcing
the
graph
to
change.
Did
you
consider
the
option
of
just
having
some
rules
effectively
to
break
that
the
circular
chain
so,
rather
than
changing
the
graph
you
could
put
in
some
or
some
annotation
to
say
at
this
point
I
want
to
break
that
chain,
but
keep
the
graph
the
same,
but
does
that
not
make
sense?
What
you're
trying
to
do.
G
Right,
so
that's
something
that
we
couldn't
enforce,
telling
you
shall
not
add
the
dependency
regular
dependencies
and
engineer
a
or
b
or
whoever
just
behave.
We
could
always
do
that
right,
so
the
first
thing
is
to
detect
it
to
see
if,
in
practice,
we've
got
many
of
those
currencies
right.
If
we
go
back
to
the
the
previous
slide,
it
might
be
just
a
question
of
educating
engineer
a
and
b
so
that
they
design
their
their
theirs
their
part
of
the
service
they're
the
same
way.
G
K
So
my
suggestion
was
actually
slightly
different
was
maybe-
and
again
I
haven't
looked
at
it.
Maybe
you
want
to
allow
the
circular
dependencies
but
put
a
mitigation
in
the
processing,
so
that
they're
not
an
issue
to
have
some
other
way
to
say
actually
at
this
point,
if
you
get
to
a
circular
dependency
with
the
the
changes
the
events
have
been
propagated,
you
then
break
the
chain
at
this
point
or
something
like
that,
I
was
wondering
you
considered
that,
rather
than
forcing
the
dependency
not
to
be
there,
it's
just
a
thought.
D
Some
of
these
things
been,
while
now
back
as
a
chair,
might
be
useful
to
bring
to
the
list
to,
because
in
your
your
next
steps
you
you
want
to
bring
it
to
last
call.
Some
of
these
would
be
good
extra
discussion
items
to
to
get
more
people
thinking
and
talking
about
the
sane
architecture.
A
Okay,
then
we
got
one
minute
left
here,
so
we
can
move
on
to
the
next
item.
If
there
are
no
other
comments
or
questions.
D
Little
a
little
out
of
order,
I
see
it
there
we
go.
I
Now
it's
your
turn
and
I
get
my
my
timer
reset.
I
really
like
the
timer.
It's
really
nice,
okay,
so
I'm
here
to
talk
about
final
throws
of
this
document
on
mud
and
iot
and
dns.
We
talked
about
it
last
time
at
ietf
111
as
well.
I'm
just
going
to
mention
that
that,
very
briefly,
there
is
a
different
document
on
acceptable
urls
and
my
belief
is
that
it's
completely
ready
to
go
forward
and
I
think
the
chairs
agreed
and
that's
why
there's
no
presentation
on
it
today
next
slide.
I
Please
next
slide,
please.
I
just
said
that
no
real
change
from
one
one,
one:
okay
and
we
had
a
conversation,
and
I
went
actually
back
to
watch
the
video
to
remember
what
happened,
and
I
tried
to
to
reengage
a
thread
on
the
working
group
about
this,
and
so
my
take
is
that
from
the
feedback
is
that
we
just
need
to
not
do
this
that
that
the
biggest
problem
here
is
iot
devices
that
do
dns
requests
that
may
not.
That
may
receive
geographically
specific
answers.
I
That
may
not
be
the
same
answer
that
the
mud
controller
gets
and
therefore
the
access
control
lists
would
not
be
set
up
by
niem
correctly.
So
when
we
discussed
this
last
time,
elliott
came
to
the
mic
and
said
he
thought
that
it
was
solvable.
I
I'm
I'm
not
sure
that
that's
the
case,
I'd
like
to
have
more
of
a
conversation
on
the
list
to
figure
out
whether
we
can
say
anything
at
all
other
than
don't
do
that,
and
that's
really
the
only
open
issue.
I
did
open
it.
Finally,
as
an
issue
on
the
in
the
github
and
next
slide,
I
think
that's
the
last,
that's
it
so
I
would.
I
I
would
really
love
to
have
a
little
bit
more
conversation
in
our
three
minutes
here
as
to
what's
actually
whether
we
can
say
anything
in
the
end
and
the
the
the
major
thing
that
I
want
to
emphasize
is
that
while
there
might
be
mud,
environments
and
mud
controllers
that
are
very
sophisticated,
that
have
integrated
dns
controllers
and
this
kind
of
stuff,
where
it's
possible,
the
question
is
for
a
manufacturer
is,
can
he
rely
on
that
and
I
think
that's.
C
I'm
not
sure
how
strongly
we're
disagreeing,
but
I
think
it's
worth
elaborating
that
just
a
bit
into
the
draft
and
then
you
know
I
think,
as
we
do,
it
will
kink
out
the
the
sort
of
issues
that
you
and
I
were
discussing
and
I'm
happy
to.
I.
I
I
If
you
do
this,
then
this
is
the
consequences.
I
think
that's
what
we
have
to
write
down,
perhaps
in
the
draft,
and
the
question
is
to
whether
we
want
to
make
normative
normative
changes
to
the
mud.
Controller
in
this
draft
is,
I
think,
an
open
question
and
I'm
happy
to
do
that,
but
I'm
just
not
sure
that
it's
meaningful
at
this
point
to
do
that.
I
A
Changing
that
to
the
p-cap.
A
I
There
we
go
all
right
now,
you'll
know
it's
a
different
presenter,
because
I
have
a
different
hat
there.
We
go
and
matches
my
shirt
today.
Okay,
so
we
went
through
working
next
slide.
Please.
I
We
went
through
an
adoption
call
in
october
for
these
documents.
There's
two
documents:
one
is
pcapp,
one
is
pcapng,
I'm
a
little
bit
confused
as
to
which
one
was
adopted
and
which
one
was
not.
I
think
it's
really
a
document
set,
I'm
not
sure
you
can
adopt
one
without
the
other,
or
it
makes
sense,
and
that's
really
what
this
co
this
presentation
is.
Conversation
is
about.
I
We
had
a
proposal
in
the
thread
about
the
conversation
about
having
a
third
document
which
would
just
create
the
link
type
registry
and
to
do
that
in
a
in
some
new
document.
So
I
guess
I
don't
have
a
strong
objection
to
that.
There's
about
280
existing
link
types
registered
and
they
need
to
go
into
the
iana
registry.
Somehow
one
there's
many
different
ways.
We
could
do
this.
I
I
believe
that
the
document
creates.
The
registry
should
initialize
it
and
had
a
conversation
some
months
ago
with
ayanna
about
how
they
would
like
to
ideally
receive
them
and
they
said
they'd
be
happy
to
have
xml
attached
and
it
it's
pretty
much
pretty
much.
We
could
do
that
easily
to
make
their
life
easier.
I
I
If
you
remove
that,
then
the
historical
pcap
could
go
via
ise
or
could
go
via
80
sponsor.
I
I
don't
particularly
think
it's
easier
harder
for
any
other
particular
way,
at
least
from
my
point
of
view.
It's
not,
but
the
the
goal
really
is
that
pk
pcap
ng
would
be
on
standards
track
for
that,
and
if
the
working
group
decided
that
pcapp
should
go
directly
to
historical
actually,
I
think
that
would
represent
the
reality.
Okay,
is
that
it's
out
there?
It's
happened.
It's
just
not
there
next
slide.
A
Yeah,
so
what
I
think
what
we
just
agreed
upon
in
the
working
group-
and
this
is
saying
as
a
chair-
is
that
yeah
pcapp
should
be
polished
and
go
direct
into
historical.
I
think
that
is
the
plan
and,
and
sometimes
the
messages,
though,
don't
convey
that
message
very
well,
but
I
think
that
was
its
initial
goal.
I
think
that
is
what
we're
targeting
here
for
from
jazz
point
of
view.
A
A
So
I
think
that's
a
logistical
problem,
not
a
intentional
problem,
so
I
assume
optimistically
that
that
there
is
actually
enough
support.
But
when
we
do
the
procedures,
I
think
people
have
to
follow
the
procedure.
So
that's.
I
think
the
only
reason
why
this
did
not
cross
the
threshold
yet
and-
and
we
can-
we
can
reconciliate
that
here
by
by
by
by
highlighting
yeah,
if
you
really
want
to
do
the
the
future
work
that
might
be
annoying
even
for
c
or
anything
like
that.
A
I
Possible
it
does
mean
that
the
pcap
document
would
reference
it
and
that's
fine
there.
It's
unlikely
that
they're
going
to
proceed
through
the
rfc
editor
queue
separately,
so
I
don't
have
a
problem
with
doing
that.
If
that's
what
the
working
group
would
prefer,
I
think
that
a
third
document
for
third
document's
sake
is
you
know
it's
a
good.
It's
a
good
cs
layer
of
indirection
to
do,
but
I
think
it's
a
bad
optimizing.
Ietf
resources,
point
of
view
to
do
so.
I
A
Yeah,
this
option
should
be
simply
put
on
the
list
and
I
think
there's
not
a
big
con.
This
is
not
a
contentious
topic.
It
just
is
a
topic
of
what
what
what's?
What's
the?
What's
the
solution
on
on
where
to
go?
It's
like
two
options,
maybe
do
the
pizza
upon
this
question
to
the
list
and
then
we
go
from
there.
H
Oh,
that's
good
thanks,
hello,
everyone!
This
is
paul
and
I'm
going
to
present
the
updates
on
this
network
and
vpn
service
performance
monitoring
draft
slide.
Please.
H
Last
call
and-
and
this
draft
is,
the
purpose
of
this
draft-
is
to
compliments
layer,
three
and
then
m
and
two
and
they're
two
of
them
and
after
in
a
figure,
we
show
that
this
this
model
is
to
used
together
with
their
three
in
them
and
they're,
two
of
them
after
provisioning,
using
that
two
models,
this
model
can
use
to
collect
status
of
this
vpn
performance
monitoring
and
then
exposed
to
the
service
orchestration,
and
the
modeling
approach
of
this
draft
is
to
augment
ietf
network
and
topology
model
in,
in
this
case,
the
the
the
network
and
vpn
performance
monitoring
can
be
associated
and
to,
and
then
that
helps
the
the
two
understand
why
the
vpn
performance
monitor
better
related
with
vpn
with
the
network
status.
H
So
here
we
right
now
we
in
the
github.
We
only
have
one
open
issue
and
that's
the
next.
Please
go
into
the
next
one,
then
I'm
talking
about
this
open
issue.
H
Yes,
this
issue
is,
is,
from
last
ietf
meeting
and
joe
made
the
comments
on
why
we
defined
the
performance
monitoring
source
to
use
a
string
other
than
other
type.
It
proposed
to
use
identity
type,
so
we
after
investigation,
we
think
and
also
at
that
time
there
is
some
other
suggestion
to
use
some
list,
as
the
this
performance
monitor
saw
so.
H
The
authors
had
some
discussion
and
they
proposed
to
use
identity,
to
define
the
different
performance
monitoring
approaches
that
the
the
controller
can
use
to
collect
the
performance
metrics.
H
H
So
so
in
we
propose
to
use
identity
to
define
this
pm
source
tab.
We
define
a
base
type.
Then
we
use
like
we
define
some
typical
method
to
to
get
this
metrics
like
pgpls
t-vamp,
and
what
dot
1731
like
each
for
the
layer.
Three
vpn,
the
two-way
pin
and
also
from
the
network
like
bgpls,
is
from
to
collect
to
collect
network
performance
matrix.
L
H
It
seems
I
can
yes
this
one
there's
a
discussion
with
the
the
authors.
The
authors
thought
that
under
right
now,
the
term
network
only
shows
the
termination
point
performance
statistics,
but
we
should
also
add
some
vpn.
H
Network
access,
although
specific
counters,
to
to
see
what's
the
difference
with
these
two
like
to
know
like
how
the
termination
metrics
and
how
the
per
vp
network
access
statistics,
so
we
propose
to
add
a
vpn
access
statistic
list,
so
I
show
here
some
new
notes.
We
are
proposing
to
add
in
in
this
way
we
will
add
some
specific
statistics
and
in
the
figure
I
I
show
the
what's
the
relationship
with
this
weapon,
access,
network
access
and
termination
point
next
slide.
Please.
H
And
this
is
another
issue
about
the
link,
specific
metrics
information
that
right
now
we
only
have
for
the
logical
link
or
the
like
the
link
in
layer,
two
or
layer
three
network
link.
H
H
Here
is
also,
and
some
proposal
to
to
change
to
the
cont
to
change
the
container
right.
Now,
it's
a
a
container
and
we
we
think
we
may
change
to
it
list
and
use
class
id
as
a
key
so
that
for
each
link
they
can
show
different
class
ids
performance,
monitor
statistics.
H
Right
now,
this
is
all
the
open
issues,
but
since
we
also
got
some
comments
from
the
mailing
list
that
greg
proposed
that
please
go
back
to
to
this
previous
slides
a
little
bit.
Yeah
grad
also
made
the
comments
on
this
delay.
Statistics
of
this
link
performance
monitoring
statistics.
H
He
thought
that
the
direction
definition
is
quite
confusing,
because
this
link
it's
it's
supposed
to
be
unit
direction,
but
we
we
we
define
direction,
seems
quite
quite
confusing
because,
because,
in
our
definition,
it
shows
its
will
be
a
one-way
or
two-way
for
this
direction
configuration.
So
I
thought
that
this
is
quite
confusing,
because
unit
direction
only
shows
this
is
a
can
can
only
have
one-way
delay,
so
he
proposed
we.
H
We
change
change
this
direction
to
some
source,
but
we
already
have
some
pm
source
defined
for
this
link
specific
one.
So
we
are
thinking
we
are,
so
we
are
proposed
to
remove
this
direction
to
to
make
it
clear.
H
Okay,
next
night,
piece.
C
Yeah
hi
sorry
for
taking
up
the
the
question
slots
so
much
if
we
could
go
back
to
slide
five
for
just
one
moment.
This
is
just
a
point
of
clarification.
Is
the
the
new
are
the
new
elements
under
vpn
networks?
Access
statistics
are
those
meant
to
be
aggregates
of
the
of
the
pm
statistics
or
art
or
or
am
I
or
am
I
misunderst,
or
is
it
the
content
inside
the
vpn
or
I'm
not
quite
sure
what
what
is
meant
by
those
objects?
H
Okay,
actually,
this
vpn
network
access
definition.
They
are
from
layer,
2
or
nm,
and
layer,
3
and
m,
and
here
because
it's
only
showed
in
vpn
overlay,
topology
and
but
actually,
since
the
one
termination
point
may
be
related
with
multiple
vpn
services.
H
So
the
authors
think
that
we
may
show
some
vpn
access
specific
one
counters,
because
they
they
could
be
different.
There
could
be
some
physical
one
represented
by
termination
points
counters,
but
we
could
have
some
like
vpn
could
use
sub-interface
in
that
way
they
have
their
own
counters.
So
can
I
answer
your
question.
C
Sort
of
I
would
just
say
in
the
interest
of
time
that
it
should
be
really
clear
where
the
statistic
where
the
counters,
what
the
counters
are
counting
in
terms
of
the
ascii
art,
and
I
think
that
would
probably
help
that's
not
something
we
normally
do.
But
I
think
in
this
case,
because
there's
so
much
virtualization,
you.
A
Yeah
thanks
and
elliot
you
sacrificed,
maybe
some
of
your
time,
but
we
will
accommodate
you
two
minutes
on
discovering
retrieving
software
transparency.
C
Okay,
so
so
many
times
somebody
had
a
timer.
This
is
a
draft
from
scott
and
myself
that
we
adopted
a
little
while
ago.
Next
slide,
please
the
this
is
all
about
what
software
is
on
a
system
and
what
vulnerabilities
does
the
software
have
next
slide?
Please
we
talked
about
this
all
the
same
time.
C
There
is
an
entire
architecture
around
this,
but
this
extension
is
mostly
around
the
upper
left
side
in
terms
of
how
we
learn
where
an
s-bomb
is
in
a
deployment,
and
so
it's
an
extension
to
mud
to
to
basically
point
to
where
and
where
one
could
get
an
spdx
file,
a
cyclone
dx
file
or
a
csaf
file
for
that
matter.
C
It's
format
neutral
next
slide,
please,
okay!
So
we've
done
the
yang
doctors
review.
What
we've
done
is:
we've
removed
the
ability
to
have
csaf
local
information.
That's
because
vulnerabilities
are
generally
announced
elsewhere,
that
and
not
generally
on
the
device
itself,
and
so
that's
the
the
only
change
really
in
in
terms
of
substance
and
it's
worth
discussion
on
the
list.
I'm
not
sure
if
I
have
a
next
slide,
but
maybe
next
slide
yeah
discuss.
C
So
the
only
thing
is,
I
think
we
need
some
more
of
the
reviews
before
we
go
to
working
group
last
call
which
I
was
hoping
to
do,
I'd
like
to
see
a
little
bit
more
implementation
on
the
part
of
the
open,
c2
people
and
I'm
talking
to
them
already
and
then
we're
discussing
this
in
other
contexts
as
well.
So
I
think
there
needs
to
be
probably
one
more
update,
but
the
reviews
should
continue
so
security
review.
C
A
A
M
Thank
you.
It's
marisol
palmeiro
here,
working
in
cisco,
cisco
systems,
I'm
based
in
madrid
bienvenidos,
is
the
part
of
we
are
really
happy
to
present
and
introduce
this
draft.
We
submitted
this
draft
in
august
this
year
and
now
we
have
been
publishing
a
revision,
two
together
with
frank,
brockners,
slender
kumar,
switovandari,
camilo
cardona,
and
with
that
we
can
go
to
the
next
slide.
M
Also,
when
referring
to
life
cycle
management
and
operations,
we
would
like
to
we
want
to
cover
on
the
draft
the
different
states,
since
we
as
users,
could
select
this
asset
that
we
have
been
defining
and
there
are
different
options
right,
depending
on
the
features
and
the
capabilities
that
that
specific
asset
can
offer.
There
is
a
selection
process
on
it.
You
can
buy,
you
need
to
place
to
do
the
placement
of
the
asset
and
the
installation.
M
With
this
we
are
getting
into
that
life
cycle.
You
need
to
license
the
asset
and
even
the
feature
you
will
need
to
select
with
features
or
capabilities
of
your
network
device
or
software
application.
You
need
to
enable
you
will
need
to
start
measuring
and
here
will
come
more
on
operations
data.
You
start
start
using
that
specific
feature,
and
you
will
start
working
on
the
operations.
M
It
might
be
false.
It
might
be
performance
issues
that
you
will
need
to
open
support,
case
management
or
incident
management
incidents
with
your
support
escalation
team
or
from
your
third
party
vendor
as
an
user
and
just
to
close
the
lifecycle
management,
you
might
need
as
well
to
renew
and
update
those
assets
at
a
certain
point
right
to
make
sure
that
you
can
continue
working
with
that
specific
assets
in
the
best
way.
M
M
All
this
is
the
work
of
our
network
and
engineers,
but
we
don't
have
to
forget
that
we
could
collect
other
metrics
that
might
not
be
that
relevant
to
the
day-to-day,
but
will
help
to
analyze
proactively
our
networks
as
well,
and
with
this
we
have
new
roles
as
well
that
come
into
the
pictures,
data,
science
teams,
business
leaders,
project
managers
and
architects
and
even
developers
right.
M
That
could
benefit
for
some
business
data
that
are
not
really
related
to
the
operations,
and
this
is
one
of
the
main
objectives
of
this
definition
of
lmo
and
the
data
model
defined
for
for
lmo.
I
want
to
reference
the
work
done
by
even
atlas
and
frank
brockners
that
they
presented
into
itf
in
the
in
march
2019,
and
you
have
the
reference
there
where
they
were
addressing
the
linkage
between
networking
data
applications,
data
and
business
data.
M
With
that
we
can
go
to
the
next
slide,
where
we
are
highlighting
the
in
this
draft.
We
are
covering
a
few
use
cases.
We
understand
that
it
might
be
for
much
more
and
we
could
address
much
more
use
cases,
but
this
is
an
example
of
the
motivation
to
get
to
write
this
draft
if
we
have
been
adding
the
revision
and
two
assets
in
use.
M
But
if
you
allow
me
to
refer
just
to
the
risk
mitigation
check
as
an
example
proactively,
depending
on
the
features
and
capabilities
that
are
running
in
a
certain
assets,
you
can
proactively
understand
based
on
on
the
hardware
and
software
that
is
running
as
well
on
your
different
networking
devices
of
software
applications.
M
Going
to
the
next
slides
and
just
trying
to
go
to
the
next
steps
as
well,
but
we
have
been
identifying
four
main
data
sets
with
different
attributes
on
it,
highlighting
assets
as
a
main
centric
point
of
our
draft,
but
also
covering
licensing's
licenses
usage
as
part
of
the
features
and
capabilities
of
of
that
asset
and
incident
that
might
be
linked
to
an
asset
or
even
to
a
feature
that
we
upgraded
as
well
in
the
revision,
co2
and
finished
with
the
next
slide.
M
M
Some
of
those
attributes
like
it
could
be
assets
in
use
address
how
we
identify
from
the
management
point
of
view
and
asset
with
that
mark,
an
ip
address.
We
have
been
introducing
new
attributes
for
it,
considering
additional
attributes
to
cover
concepts
like
combo
options
for
features
and
assets
within
licensing
and
also
we
have
been
addressing
in
version
0.2,
and
we
have
still
to
reiterate
on
that.
How
to
identify
an
organization
and
the
hierarchy
for
it?
M
G
So
I
I
believe
in
the
past,
this
draft
make
love
sense.
I
still
believe
this
makes
a
lot
of
sense.
That
could
be
very
important
in
the
future.
Obviously,
one
small
detail
about
the
naming
convention-
it's
not
really
about
life
cycle
management
and
because
everything
is
collecting
information
right.
All
the
things
in
your
young
modules
is
read:
only
I've
not
been
thinking
about
good
name,
it's
not
too
important,
but
just
something
to
observe,
and
even
your
abstract
mentioned
collects
now
in
the
industry.
This
is
the
third
point
in
history.
G
G
We
start
to
have
capabilities
discovery
in
the
context
of
telemetry
you'll
see
a
draft
about
a
data
manifest
later
in
the
session.
So
we
start
to
see
more
and
more
of
these
inventory
high-level
information
that
are
network-wide
more
business-oriented,
so
really
want
to
make
sure
that
we
align
on
the
definition
of
all
these
right,
because
if
this
drive
becomes
very
important,
it
will
be
a
success
if
it's
multi-vendor
right,
because
in
the
end
most
networks
are
just
multi-vendor.
G
J
M
Perfect,
thank
you,
benoit
and
really
appreciate
I
I
I
the
comments
that
you
made.
You
were
right
right
on
the
naming.
We
were
discussing
internally
how
to
get
to
an
a
good
name,
and
we
are
not
close
to
change
that.
If,
if
it's
required
internally
within
cisco,
we
call
it
differently
but
yeah.
I
really
appreciate
on
the
comments
as
well
to
align
with
other
drafts.
We
have
been
already
doing
an
exercise
with
elliot
on
considering
his
bomb
and
yeah.
It
would
be
really
good
to
align
and
make
it
multi-vendor.
D
Marisol,
you
have
quite
a
few
steps
here
and
benoit
touched
on
a
couple
of
others.
These
are
would
be
great
things
to
bring
to
the
list
and
discuss
as
you
you
look
to
make
these
decisions
again,
assuming
you
want
to
take
this
draft
further
in
ops,
awg.
Having
that
those
conversations
and
engaging
the
the
broader
operations
and
vendor
interests
would
be
extremely
useful,
and
I
think
you've
got
some
good
items
here,
I'm
particularly
interested
in
the
last
one,
but
we're
out
of
time.
D
While
ken
gets
set
up
here
remember,
if
you
have
any
items
for
ops
area,
the
open
mic,
please
just
let
us
know
in
the
chat,
so
we
can
know
to
budget
that
time
we're
kind
of
on
schedule,
but
we're
having
some
technical
difficulties.
It
seems,
if
need
be,
we
can.
D
D
D
Let's
move
to
the
inband
flow
learning,
I
don't
know
sorry
we'll
back
to
you
benoit
we'll
go
to
manifest
for
streaming
telemetry,
which
is
next,
because
dan
needs
to
move
to
the
the
end,
and
ken
will
come
back
to
you
right
after
benoit's
presentation
here
just
so,
we
can
keep
things
moving,
so
I
need
manifest
something
there.
We
go.
G
G
Okay,
so
what
is
the
issue
we
start
to?
Have
an
industry
money
capability
discovery
from
routers,
even
the
per
node
recovery
discoveries
like
the
first
two
drafts
are
in
there
to
you,
know,
tell
you
what
you
could
do
with
streaming
telemetry.
G
The
third
one
tells
you
what
you
could
be
doing
with.
You
know
whether
a
per
node
as
the
quality
of
unchanged
or
not.
What
is
the
current
or
the
minimum
cadence?
You
could
get
anything
like
this.
G
G
G
G
We
don't
think
so,
because
if
you
receive
the
value
42
and
a
single
value,
can
you
assume
that
you
receive
this
as
unchanged?
Maybe
not.
Maybe
it
was
simply
the
only
value
that
you
are
receiving
or
if
you
receive
a
collection
period
and
in
your
time
series
you
see
the
value
second
6
11
17,
whatever.
G
G
Maybe
because
the
device
is
busy,
maybe
because
it's
under
stress,
maybe
because
it's
unsupported
whatever
even
the
the
router
os
like
you-
receive
42,
but
from
two
different
routers,
an
old
one,
with
an
old
os
with
a
bug,
a
new
one,
with
a
new
os
without
a
bug.
So
it's
key
if
you
want
to
interpret
the
data,
it's
key
to
get
the
context.
G
G
So
this
information
about
the
context
must
be
streamed
with
the
data
and
store
along
with
the
collecting
data.
So
if
you
stream
the
data
somewhere
else
like
in
the
end,
maybe
in
a
big
data
lake
for
further
analysis,
the
context
must
follow
now.
This
must
be-
and
we
just
I
just
showed
in
the
previous
slides,
the
instant
draft,
which
is
right
now
in
the
rfc
editor
queue,
which
is
a
draft
that
gives
you
a
file
based
on
the
yang
format,
and
this
is
the
way
that
this
information
should
be
stored.
G
So
if
we,
if
we
go
to
the
next
slide,
so
two
young
modules,
one
is
the
platform
manifest.
So
typically,
what
is
the
hardware
model?
What
is
the
os
type?
What
is
the
version
and
with
the
old
draft
that
joe
clark
and
I
wrote,
which
is
the
yang
module
behind
the
yang
catalog
we
have
identified?
We
have
we
attempted
to
model
those
values
and
since
those
values
are
used
in
the
catalog-
and
there
are
people
introducing
you
know
with
a
file
called
platform,
metadata
they're
introducing
information
about
those
device,
we
could
be
reusing
it
now.
G
We
also
want
to
send
or
to
link
the
information
about
the
available
yang
modules,
but
also
deviation
that
are
on
that
device.
Again.
If
I
take
the
example
of
router,
1
old
and
router
2
new
without
the
bug,
maybe
the
deviations
are
different.
So
that's
also
something
that
we
need
to
interpret
the
data.
G
When
would
you
change
its
platform
manifest
when
there
is
a
change
in
the
platform?
Typically
a
reboot,
a
new
os?
Something
like
that
in
the
next
slide
slide,
you
would
see
the
pian3
of
all
the
the
information
the
first
curly
bracket
comes
from
the
yang
model
behind
the
yang
catalog
and
the
second
one
comes.
We
just
reuse,
the
yang
library
module
okay
in
the
next
slide.
G
C
G
Receive
the
single
value
of
42,
what
does
it
mean?
Whether
suppressed
we
don't
see
is
used,
meaning
that
it's
a
feature
where,
if
you're
going
to
send
the
same
value?
Well,
actually
don't
send
it.
The
value
has
not
changed.
It's
still
42,
but
it's
still
important
to
understand
if
you're
having
polling
with
super
presidency
or
change
the
requested
collection
period
and
what
is
the
current
one?
G
Maybe
because
it's
not
supported,
maybe
because
the
routers
are
stressed
whatever,
and
we
update
this
data
manifest
whenever
the
collection
condition
changes,
you've
got
a
new
subscription
or
a
different
collection
or
something
change.
Now
we
speak
a
lot
about
ai
and
machine
learning.
So
if
you
want
to
analyze
the
data,
it's
important
to
get
all
the
context.
G
G
Okay
in
the
next
slide,
so
this
is
the
basic
idea:
I've
been
showing
you
so
far.
What
are
the
improvements
that
we've
been
identifying
clearly
identify
how
data
manifest
should
be
collected?
Well,
telemetry
makes
sense
right.
You
just
push
this
along
with
the
data,
but
do
you
want
to
acknowledge
it?
Do
we
want
to
set
on
a
regular
basis?
G
G
G
So
in
conclusion,
in
the
last
slide,
we
propose
to
normalize
the
way.
Contextual
information
about
data
collection
is
stored.
It
should
be
safe
with
the
data
moved
with
the
data
and
would
allow
us,
as
a
later
reusability
or
later
contact
information
to
sorry.
Let
me
rephrase
that
it
will
allow
us
later
not
to
use
the
context
to
interpret
the
data,
so
there
is
github
which
updated
in
the
data
tracker
so
feel
free
to
give
me
your
feedback
on
this.
D
We
have
elliot
and
rob
and
hey.
Oh
my.
We
have
a
lot
we're
not
going
to
be
able
to
take
everyone,
but
let's
elliot,
let's
start
with
you.
K
Actually,
I've
put
my
question
in
the
chat,
so
then
I
can
see
it
there.
My
quick
comment
is:
have
the
platform
manifest?
Have
you
considered
using
yang
packages
as
a
way
of
describing
what
the
yang
modules
are
supported,
which
gives
you
hierarchical
capabilities,
but
I
can
discuss
something
on
the
list
describe
it.
If
that's
helpful,.
A
Thank
you.
So
this
is
a
chair,
so
so
we
we
have
this.
There's
this
s-bomb
effort,
and
and
now
you
are
trying
to
do-
manifests
that
are
literally
the
the
contents
and
the
provenances
of
the
things
you
want
to
run.
Is
there
overlap.
G
That
was
my
point
to
marisol
in
the
precession
that
we
start
to
see
all
these
type
of
inventory
and
we
would
need
to.
A
Okay,
so
that
should
be
an
a
dedicated
effort
and
I
I
would
happy
to
to
contribute
to
to
organizing
that
thank
you.
D
Frank
is
that
a
quick
question,
if
not
might
need
to
take
it
to
the
list
yeah.
L
It's
a
quick
one.
I
think
that's
to
the
earlier
comment.
L
I
think
it
would
make
sense
to
go
and
delineate
pure
inventory
type
things
that
you
have
in
the
draft
from
things
that
are
again
about
runtime
information,
because
collection,
cadence,
actual
collection,
cadence
in
those
settings
are
again
about
operational
runtime
information
and
we
might
want
to
go
and
treat
them
differently,
because
also
the
accuracy
of
what
you
can
retrieve
from
an
operational
perspective,
collection
cadence
been
a
really
a
big
can
of
warmth,
as
opposed
to
things
that
are
kind
of
static,
like
hardware
id
router
version
and
the
likes,
and
I
would
agree
that
I
think
we
want
to
go
and
merge
certain
pieces
with
murray
salzburg.
D
D
J
Great,
so
I
am
gonna
discuss
a
little
bit
about
what
we're
doing
in
its
and
how
we're
using
snmp
and
the
reason
we
need
to
update
it
to
1.3
for
tls.
J
J
So
the
cisa,
among
others,
definitely
recommend
using
snmpv3
over
basically
dtls
according
to
rfc
6353.
J
What
we're
looking
for
is
basically
an
update
of
6353
to
clarify
exactly
how
we
implement
snmp
over
tls,
1.3
now
or
dtls
1.3
either.
One
next
slide
so
with
that
the
its
community
realized
that
no
active
effort
was
being
undertaken
in
the
ietf
right
now.
So
we
looked
at
different
things.
We
looked
at
changing
protocols
completely.
We
recognize
that
among
a
lot
of
people,
snmp
is
kind
of
out
of
favor
now,
but
nonetheless,
when
we
looked
at
different
options,
the
its
community
decided
that
it
is
much
better
for
us
to
stay
with
snmp.
J
J
We
have
put
together
a
draft
and
we
would
like
to
have
that
draft
adopted
by
the
ietf
and
we're
very
interested
in
working
with
you.
The
alternative
is,
it
would
probably
be
developed
as
our
own
internal
standard,
but
it
makes
a
lot
more
sense
to
work
through
the
ietf
next
slide.
J
So,
just
as
a
quick
summary
of
the
changes
that
are
needed,
the
driving
changes
I
alluded
to
is
updating.
1.3
tls
1.3
uses
a
2
octet
identifier
for
the
cyber
suite
now
sorry
cipher
suite
now,
rather
than
a
one
octet
for
the
hash
algorithm
and
another
one
octet
for
the
encryption
algorithm
that
changes
the
fingerprint
that's
recorded
within
the
rfc
6353
mids,
and
that
creates
some
ambiguities
of
how
all
of
that
should
be
handled
a
couple
different
ways
to
resolve
this.
J
J
There
are
other
clarifications
that
should
be
made,
such
as
updating
references,
clarifying
authentication
privacy
are
always
provided
next
slide
and
then
some
more
subjective
changes
such
as
whether
we
use
zero,
rtt
and
other
issues.
So
if
we've
identified
all
of
those
in
our
draft,
we've
made
proposals
but
we're
willing
to
negotiate
any
of
these.
The
key
is
reaching
consensus
so
that
all
implementations
do
it
the
same
way
and
next
slide.
J
So
that
really
brings
us
down
to
three
major
questions,
the
first
of
which
is
you
know.
We
presented
this
actually
at
the
last
ietf
meeting
to
the
security
dispatch
group.
They
liked
the
idea
they
ended
up,
pushing
this
over
to
the
to
this
working
group
as
its
natural
home.
So
does
yapzog
wish
to
adopt
this
work
and
then,
if
we,
assuming
that
we
do
do
that,
then
how
do
we
best
address
the
fingerprint
issue?
C
Yes,
hey
thanks
thanks
ken
for
the
for
this
presentation.
I
just
have
a
question
for
you,
which
is
how
well
fielded.
Do
you
believe
rfc
6353
is
in
its.
J
Somewhat
limited
right
now,
it
is
our
security
is
not
where
it
needs
to
be.
There
is
a
major
effort
within
the
federal
highway
administration
to
improve
our
security,
and
this
is
a
part
of
that
effort.
C
Okay,
yeah,
if
I
think
that
goes
to
what
we
do
with
the
document
format,
just
from
my
purposes,
I
think
we
should
stop
playing
ping
pong
with
this
document.
If,
if
it
seems
reasonable
to
get
us
to
tls
1.3,
it's
not
a
small
effort.
We
just
went
through
this
with
with
an
emu
for
eep.
C
It
takes
a
little
bit
of
work,
you're
doing
the
work.
You
seem
to
have
a
community
of
interest
to
do
the
work.
You
know,
assuming
that
other
participants
are
willing
to
step
up
and
say
yeah
I'll
implement,
then
I
think
we
should
adopt,
but
I
also
think
this
work
needs
to
be
really
closely
brought
back
to
the
tls
working
group
just
so
that
they
know
what's
going
on,
because
ops
area
doesn't
have
tls
expertise.
C
K
Rob
I'm
just
going
to
make
a
comment.
I
don't
know
this
is
with
lady
hat
on
not
really,
but
I
do
think
it's
important
that
the
itf
should
do
this
work
in
the
sense
that
I
think
it's
important
that
we
keep
our
protocol
secure.
So
I
think
it's
a
matter
of
finding
what
the
best
path
through
that
is
in
terms
of
one
of
the
questions
here
about
updating
or
obsoleting.
K
I
think
that
that
depends
on
the
size
of
the
changes
if
it
could
be
done
sensibly
as
an
update
that
might
be
might
be
a
better
choice
potentially,
but
that
can
be
worked
out.
D
I
think
that
has
been
brought
up
on
the
list
already
when
kenneth
raised
this
and
with
the
chair
hat
on.
I
think
it
is
worth
bringing
up
the
question
of
adoption.
I
agree
with
elliot's
comment
that
the
ping-ponging
probably
isn't
needed
anymore.
We've
got
snmp
expertise
here
and
and
if
we
can
get
the
collaboration
with
tls
and
the
working
group
wants
to
work
on
this,
we
can
certainly
raise
the
question
and
see
where
to
go
from
there
and
and
rob.
I
agree
with
you.
D
I
don't
see
anyone
else
l.a
unless
you're
in
the
queue
to
ask
another
question,
nope
well
kind
of.
Thank
you
very
much.
We'll
take
the
action
to
raise
the
the
question
of
adoption
to
see
what
what
the
working
group
wants
to
do
with
this
work
since
you've
clearly
put
initial
effort
into
it
and
see
where
we
go
from
there.
D
So
next
we've
got
in-band
flow
learning.
Let's
see,
what's
this
one.
D
B
I'm
moving
from
train
number
five.
Okay,
thank
you
chair.
So,
on
behalf
of
other
authors,
I'm
going
to
present
this
draft
of
problem
statement
and
requirement
for
in-band
flow
learning,
so
this
product
is
also
proposed
in
ippm,
wt
and,
and
the
authors
discussed,
we
think
it's
more
related
to
the
operation
and
management
functions
for
flow
performance
monitoring.
B
So
today
we
present
here
to
hope
to
achieve
more
suggestions.
Okay,
so
next
time,
please.
B
So
the
objective
of
this
contribution
is,
first
to
analyze
the
challenges
of
in-band
flow
learning,
identifications
for
the
flow
performance
measurement
in
the
operators
networks.
B
So
a
large
skill,
deployment
of
4g
and
5g
wireless
base
stations
and
enterprise
services
may
cause
problems
for
us
to
deploy
the
implant
flow.
Learning
and,
second,
are
the
requirements
of
inventory
learning
to
solve
the
problems
for
deploying
event,
performance
monitoring
and
second,
to
provide
scenarios
for
the
inventory
learning,
including
ingress
flow
learning,
egress
flow
learning
and
hope
by
hop
flow
learning
and
also
auto
flow
aging.
B
Oh,
I
can.
I
can
only
see
this
two,
so
that's:
okay,
okay,
okay,
step,
three!
So
for
the
problem
statements
and
first,
it
is
always
difficult
to
get
the
flow
informations
in
our
real
networks,
so
including
the
characteristics
like
ports,
ip
addresses,
dscps,
etc.
To
set
up
the
intense
instance
for
the
flow
performance
monitoring,
for
example,
in
4g
and
5,
t2c
and
2b
is
nervous
because
of
some
entire
effects
or
base
station
adjustments
and
uvf
extensions,
which
are
always
hands
in
our
networks.
B
So
for
the
open
data
by
the
end
of
march
2021,
so
china
mobile
has
already
deployed
404
410,
000
5g
stations
and
also
we
have
400
000
slicing
packing
networks,
equipments
for
the
backhoes
and
enterprise
services.
B
D
And
make
sure
you
have
your
over
your
five
minutes.
So
if
you
can.
B
Okay
finish
quickly:
I
will
quickly
finish
the
requirements,
so
the
requirements
for
the
implantable
learning
may
involve
ingress
and
egress
for
learning
and
how
by
helpful
learning,
and
so
also
the
auto
flow
aging
to
recycle
the
resource.
Okay.
So
because
there's
not
enough
time,
so
I
will
just
go
next
slide.
B
So
the
next
step,
so
where
we
will
update
the
draft
according
our
feedbacks
and
later
will
propose
more
contributions
on
the
mechanisms
of
the
impactflow
learning
functions,
so
also
we
want
to
discuss
whether
this
kind
of
draft
is
can
belong
to
ippm
or
obs
awg.
Okay,
thank
you.
D
That's
quite
true,
and
I
would
suggest
you
bring
it
up
on
the
on
the
list
or
question
there
about
applicability
and
we
can
have
a
discussion.
Thank
you.
D
All
right
talo,
I
believe
you
are
next
on
data
model
for
optical
network
inventory,.
N
Thank
you.
Thank
you,
mr
chairman.
I
am
from
hawaii
and
I'm
presenting
on
binary
of
quarters
this
rough
that
we
have
submitted
to
the
second
working
group
and
but
I
think
we
could
be
interested
for
the
observer
working
group
as
well.
That's
why
I'm
presenting
here
next
slides,
please,
okay!
This
is
an
eye-level
overview
of
what
are
we
doing,
and
why
do
we
need
this
model?
So
we
have,
I
discovered
from
some
work.
N
We
have
done
with
operators
that
inventory
management
is
a
key
function
in
their
oss
system
and
today
is
performed
through
interfaces
like
corba,
xml
or
restful.
But
what
is
missing
is
a
standard
young
data
model
that
could
be
used
to
retrieve
the
network
inventory.
So
the
inventory
information
from
the
whole
network,
through
an
an
mbi
interface
of
a
network
controller
and
the
rfc
348
that
we
found
is
actually
limited
to
the
hardware
management
of
a
single
device.
N
So
it's
not
a
network
level
model
because
you
measure
a
single
device
and
that's
much
more
than
just
inventories.
Just
do
the
whole
hardware
management.
So
what
we
need
is
something
which
is
just
inventory
and
for
a
network
model
and
the
intention
that
we
have
is
to
to
come
up
with
a
model
that
is
generic
and
applicable
to
multiple
technologies,
including
ip,
not
only
optical,
but
also
ip
and
microwave
devices,
and
that's
the
reason
why
we
are
asking
a
question
for
the
first
version.
N
N
So.
The
key
question
that
we
need
to
discuss
is
which
working
group
should
we
go
for
for
the
next
steps?
So
we
with
the
economist,
we
have
an
initial
draft,
but
we
want
to
improve
it
to
make
it
more
generic
and
we
would
like
to
understand
which
are
the
working
group.
So
at
this
point
we
have
a
three
candidate
c
camp
net,
mod
and
observer
working
group,
and
any
other
opinion
is
also
welcome,
and
the
suggest
my
plan
is
here
to
discuss
here
is
more
where
to
to
continue
this
work
for
the
technical
discussion.
N
C
Hi
again,
thanks
for
taking
my
question
italo
and
thanks
for
the
draft,
I
think
you
have
the
misfortune
if,
if
my
account
is
not
wrong
of
being
the
fifth
draft
today
to
cover
something
relating
to
inventory,
and
so
the
word
is
maybe
getting
overused
or
it
may
be,
that
it's
being
properly
used,
but
unfortunately
with
five-minute
presentations.
It's
really
hard
to
tell
so.
C
My
suggestion
is
that
this
is
a
good
opportunity
for
an
interim
to
bring
these
all
to
to
bring
a
discussion
around
where
all
these,
what
the
map
of
the
world
looks
like
with
regard
to
inventory,
so
that
we
know
which
draft
is
meant
to
cover
what
purpose?
What
drafts
need
to
be
combined
whether
there
needs
to
be
a
working
group
for
this
or
or
whether
it
happened
a
new
working
group
or
whether
it
happens
an
existing
working
group.
C
N
Okay,
thank
you
makes
sense
to
me
just
to
clarify
this
inventory
of
the
hardware.
So
what
are
the
boards,
the
racks,
the
shelves
and
the
ports
you
have
deployed
in
the
network?
I
understand
an
inventory
is
overloaded
terminal.
D
Yeah,
it
might
not
be
a
bad
idea,
given
the
various,
maybe
maybe
overlap,
maybe
not
overlap
to
to
have
a
deeper
conversation
on
that
it
doesn't
have
a
lot
of
time
to
pull
I
for
one.
I
need
to
read
this
one
to
get
a
better
feel
where
it
might
go,
but
certainly
discussing
or
asking
on
the
list
to
see
who
here
in
hops.
Awg
is
interested,
wouldn't
be
a
bad
idea
and
the
chairs
we
can
talk
about.
D
Maybe
we
do
want
to
do
something
to
bring
together,
marisol
benoit
your
work
and
get
more
of
that
holistic
approach
to
inventory.
Well,
thank
you
for
the
presentation
in
tala.
D
Okay,
let's
see
if
chin,
I
think,
leave
you
and
then
we'll
go
to
dan
lee
for
the
final
presentation.
So
this
is
on
service
attachment
points.
D
O
Okay,
great
hello,
everyone.
This
is
ching.
Thank
you
chair
to
accommodate
this
topic
as
the
last
one,
and
I'm
like
to
present
this
sap
network
model.
Next.
O
So
this
is
another
new
job
actually
used
to
be
the
uni
topology
chapter
that
will
be
proceeding
in
the
opswg
and
we
actually
derive
from
the
l3,
nm
and
l2nm.
So
this
model
actually
can
work
together
with
lcm
and
l2m
to
provide
a
close-loop
lifecycle
management
for
vpn
service.
So
these
usa
use
cases
has
been
documented
in
the
opswg
automation
framework,
which
you
can
publish
it,
and
actually
we
revive
this
ui
topology
draft,
because
currently
l3
nm
lgm
are
stable.
So
compared
to
the
previous
version,
we
make
a
several
change.
O
Actually,
first,
we
haven't
abandoned
the
ui
topology
terminology,
because
this
technology
a
little
bit
confusing
because
it
mostly
represents
a
demarcation
point
in
online
network
between
c
and
pe.
So
we
rename
as
sap
and
to
add
a
clarity
and
in
addition,
actually
we
clarify
how
this
model
relates
to
the
other
model.
For
example,
t
topology
model
nano
topology
model,
and
this
detail
has
to
be
can
be
seen
in
page
10
and
also
we
actually
make
several
changes
first,
actually,
we
we
actually
augment
a
nano
topology
model.
O
Actually,
it
is
a
network
model
with
a
new
theological
type
list
to
indicate
what
a
service
type
we
can
support
for
them
or
errors
or
vpn
or
nano
sizing,
and
we
also
add
a
service
type
list
and
a
service
description
for
each
service
attachment
pawn
in
section
four
and
six
and
we
change
the
type
for
service
attachment
to
the
interface
type,
because
it
is
more
reflective
what
it
is
in
section
four
and
six,
and
in
addition,
in
section
three,
we
clarify
one
service,
multiple
view
and
some
other
changes,
including
reference
update
and
we
also
add
a
new,
also
vector
from
nokia.
O
So
today
I
want
to
have
quick
discussion.
Two
question:
one
is
how
these
work,
together
with
l3
nm,
how
it
reflected
into
the
lsu
and
ltm
and
the
other
is
actually
written
on
the
list
about
what
is
the
usage
example.
Look
like
next.
O
So
the
key
elements
in
this
model
is
sap.
We
call
the
service
attachment
point,
so
it
is
a
general
concept
in
the
deployment
of
the
network
service,
for
example,
vpn,
service
or
html
service,
and
actually
this
sap
will
use,
decide
where
you
can
attach
or
where
you
can
deliver
the
service
and
actually
this
model
really
designed
for
the
service
orchestration
layer.
O
So
it
provides
a
capability
exposure
to
the
surface
oxygen
layer,
so
soviet
architecture
layer
really
want
to
know
the
capability
of
available
end
points
in
the
connection
resource
in
online
networker.
O
So,
in
the
end
to
end
the
connectivity
service
that
may
span
across
the
multiple
domains,
so
you
may
need
to
know
what
is
the
sequence
of
the
domain?
What
is
the
point
of
interconnect
connection
to
use
so
the
the
model
design?
Actually,
we
augment
from
the
network
model,
which
is
rc8345?
O
So
how
it
works
with
lc
and
m.
Actually,
as
we
know,
actually
l3nm
can
be
used
to
configure
a
vpn
service
and
we
can
use
this
sap
nano
topology
model
to
expose
the
capability.
So
this
can
build
a
closed
loop.
So
take
a
l3
vpn
service
example.
So
we
can
provide
one
vpn
service
but
a
multiple
view
for
the
custom
view.
It
is
the
first
of
you.
Actually,
it
will
relate
to
the
l3
sm
and
what
is
the
custom
view?
O
Srm
will
provide
an
actually
operator
view
or
nano
controller
view,
so
it
really
mean.
Actually
you
can
know
where
you
can
allocate
a
pe
based
on
location
selected
by
the
customers
and
what
rtid
are
located
for
the
specific
pe
and,
in
addition,
we
want
to
provide
another
third
view.
Actually
we
call
the
sap
view.
This
really
helps
you
to
to
know
where
you
attach
the
service
in
the
service
topology
on
overlay
topology,
where
you
can
deliver
this
kind
of
service.
O
So
here
we
give
a
simple
example:
actually
they
really
show
you,
for
example,
soviet
oxygen
can
send
a
capability
query.
You
want
to
look
up
some
node
capability,
for
example,
take
a
p
x
example.
They
really
want
to
look
up
what
service
we
can
provide
for
specific
interface,
for
example
g064
or
ge06,
for
so
you
can
see
actually
for
g061.
O
Actually,
it's
not
active,
but
it
is
ready
to
receive
the
service
configuration
other
for
the
the
interface
g0464.
Actually
it
can.
You
know,
support
two
separate
interfaces.
One
is
associated
with
error,
vpn,
the
other
associated
with
l2
vpn.
So
we
can
use
this
model
to
represent
this
kind
of
node
information
and
expose
it
to
the
service
operation.
So
they
can
build
this
automated
management
tool
to
know
what
a
service
project
looks
like
where
the
service
is
attached,
so
it
also
can
be
supported
in
the
antenna
connective
service
spanning
across
malibu
domain.
D
O
Yes,
for
nano
slicing,
actually
there's
a
design
team.
We
actually,
we
do
have
actually
met,
actually
follow.
This
activity.
Try
to
align
with
another
slicing
activity,
aligned
with
the
technology
terminology,
yeah
sure.
D
Good,
okay,
so
on
the
working
group
adoption
call.
This
is
something
we
can
bring
up
to
the
list
you've
presented
this
before,
and
I
know
this
work
has
happened
in
conjunction
with
the
various
network
models
so
to
if
we
can
raise
it
and
see
what
the
broader
working
group
feels.
D
Thank
you
chin,
and
I
think
this
is
our
last
presentation
on
source,
address,
validation,
use
cases
and
gap
analysis,
so.
P
The
traditional
internet
architecture
lacks
the
validation
of
a
package
source
address
a
sender
can
fold
the
source
address
when
sending
packets,
which
is
also
known
as
source
address,
spoofing
with
source
address.
Spoofing
attackers
can
carry
various
attacks,
such
as
reflective,
ddos,
so
source
address,
validation,
save
is
necessary,
mutually
agreed
norms
for
routine
security
manners
is
calling
on
network
operators
to
implement
save.
P
P
P
P
P
P
P1
is
the
source
address
prefix
of
router
3
p1
prime,
is
the
spoofed
p1
by
router
2
p1.
Double
primes
is
the
spoofed
p1
by
routers
in
es3,
intro
esc
aims
to
avoid
spoofing
from
inner
es
in
as2
route.
1
and
route
4
should
drop
the
package
with
p1
prime
from
router
2,
where
except
the
package
with
p1
from
router
3
inter
esc
aims
to
avoid
spoofing
from
external
pieces.
C
P
P
P
P
P
P
Inherited
force
negative
problems,
we
take
as4
as
an
example:
as5
is
its
provider.
S3
is
experienced,
as1
and
s2
are
its
customers
when
s4
runs
efp
uips
at
customer
interfaces.
The
same
rule
is
packaged
with
source
addresses
belonging
to
es4's.
Customer
code
can
arrive
from
every
customer,
so
it
says
in
es4
customer
coin
converts
each
other
when
as4
runs
lose.
C
P
P
P
P
In
order
to
avoid
false
positives
and
reduce
false
negatives
as
much
as
possible,
save
should
follow
the
real
data
forwarding
path.
To
this
end,
a
path
probing
method
can
be
taken,
that
is,
the
source
router
sends
probing
packets,
carrying
source
information.
Then
each
intermediate
router
can
generate
safe
rules
based
on
source
information
and
the
incoming
interface.
P
More
specifically,
when
interfaces
cannot
learn
complete
forwarding
information,
a
combination
of
allow
list
and
the
block
list
can
improve
the
accuracy
besides
design.
Designing
a
practical
probing
method
needs
to
consider
many
practical
issues
such
as
high
skill
ability.
The
design
should
not
induce
much
overhead
and
high
deplorability.
P
P
D
We
are
out
of
time
lynching,
and
I
I
adrian
mentioned
that
when
you
discuss
this
in
interior,
the
recommendation
was
to
discuss
with
opsec,
which
I
think
makes
sense.
So
I
I
would
suggest
bringing
it
up
over.
There
would
be
a
good
next
step.
D
Thanks
and
well
with
that,
we
are
just
about
two
minutes
remaining.
I
don't
know
warren
rob
if
you
want
to
say
any
parting
words,
and
then
we
can
let
everyone
go.
Q
Yep,
I
guess
I'll
quickly,
just
say
something
so
first
off
thanks
again
to
the
ops,
awg
chairs,
for
you
know
doing
this
and
we
let
them
have
the
extra
time.
If
anybody
would
like
to
come
and
talk
to
robert
about
any
ops
area
stuff,
we
will
both
be
looking
in
gather
town.
So
you
know
that
will
be
basically
our
equivalent
of
the
normal
ops
area.
Open
mic.
So
see
you
all
there.
If
you
would
like
to
come
along
and
chat
with
us.