►
From YouTube: IETF105-TEAS-20190723-1330
Description
TEAS meeting session at IETF105
2019/07/23 1330
https://datatracker.ietf.org/meeting/105/proceedings/
A
A
Our
agenda
has
been
posted.
There
really
hasn't
been
any
significant
change.
That's
been
posted,
we
are
doing
etherpad.
As
usual,
I
asked
everyone
to
jump
on
and
help
us
capture
comments
that
are
made
at
the
mic.
You
don't
need
to
capture
everything.
That's
spoken
during.
They
hate
the
slides,
that's
captured
in
the
slides
and
the
videos,
and
it's
really
the
discussion.
That's
important
to
capture
in
the
notes
we
are
at
the
IETF.
You
didn't
notice,
which
means
we
have
our
note.
Well,
we
have
rules
that
govern
our
participation
and
our
contribution
to
the
IETF.
A
If
you're
not
familiar
with
it.
Please
take
a
look
at
that
URL
on
the
bottom,
but
basically
everything
you
say
here
or
at
any
meeting
at
the
IETF.
It
becomes
part
of
our
record
we're
streaming
we're
recording.
Please
say
your
names
as
you
come
to
the
microphone.
That's
helpful
for
those
who
are
remote
as
well
as
for
when
you
go
back
to
take,
make
sure
we
have
accurate
minutes.
I
am
on
Jabbar
and
if
anyone
else
wants
to
jump
on
Jabbar,
that's
great
but
sometimes
I,
don't
always
come
on.
A
A
A
We
have
some
other
documents
that
are
being
that
are
going
through
the
normal
is
cheap
processing,
and
so
it's
always
but
again
to
see
the
work
of
the
working
group
heading
towards
publication.
Of
course,
that's
why
we're
here
we
have
a
couple
of
newly
adopted
documents.
I
believe
they
are
both
on
the
agenda.
A
A
The
session
information
changes
between
the
sessions,
in
particular
the
audio
stream,
will
change
there.
Everything
else
stays
the
same,
including
thankfully
the
room
we
do
have
a
beverage
break
for
20
minutes
between
3
and
3:20.
We
do
intend
to
take
that
break.
It
is
our
hope
that
we
can
run
through
our
agenda
faster
than
what
we
have
listed,
but
we
also
do
have
this
extra
long
time.
The
ex
is
actually
more
time
than
we
requested,
so
we'll
take
advantage
of
it.
A
A
We've
had
no
liaisons
or
communication.
Since
the
last
meeting,
I
just
realized
I
meant
to
go
and
check
Arata
I'm,
not
sure
if
we
had
any
errata
that
came
in,
but
we
should
mention
that.
That's
my
bad
Pavan
says
we
didn't
have
any.
So
that's
didn't
miss
anything
here,
that's
good!
As
usual.
Just
a
reminder:
we
have
a
formal
IPR
process
that
we've
adopted
in
the
working
group.
A
We
do
encourage
everyone
to
use
the
mailing
list.
It's
a
great
place
for
discussion.
It's
a
great
place
to
make
sure
that
your
colleagues
are
in
sync
with
the
activity
that
the
progress
you've
been
making
on
a
draft,
and
it's
a
great
way
to
report
those
private
conversations
that
happen
inevitably
happen
between
authors
and
that's
it
for
the
first.
B
This
is
the
set
of
documents
working
group
documents
that
are
not
in
the
agenda
today,
so
we'll
walk
through
the
status
of
each
of
these
in
the
next
few
slides
first
up
is
the
AC
TN
yang
document
no
changes
since
the
last
ITF.
In
previous
meetings,
we
agreed
that
we
would
wait
for
the
generate
key
models
to
progress
to
the
publication
stage
and
then
revisit
this.
We
are
not
there
yet.
So
in
the
meantime,
if
we
can
get
in
a
few
more
reviews,
that
would
be
very
useful.
B
Next
is
the
enhanced
VPN
document.
There
was
a
revision
published
for
this
early
this
month
there
was
a
section
added
for
covering,
inter
domain
and
inter
layer
network
scenarios,
the
authors
intend
to
add
more
details
and
operational
considerations.
We
do
have
some
work
relevant
to
this
coming
up
in
the
second
session,
so
this
topic
would
get
revisited
again.
B
Next
is
the
PC
native
IP
document.
There
was
a
revision
published
for
this
in
April.
This
carried
primarily
some
a
tutorial
changes.
The
authors
may
make
a
few
changes
to
the
document
based
on
how
the
scenarios
document
progresses
through
the
publication
stage.
There
is,
there
was
an
open
question
on
if
and
when
the
status
of
this
needs
to
be
changed,
so
we
would
let
it
stay,
as
is
for
now
and
revisited
at
a
later
point
in
time.
B
Next
is
the
PC
CC
use
cases
document
there
was
a
revision
published
for
this
in
July
there
was
some
text
added
to
state
that
this
is
a
living
document
to
catalog
the
various
use
case
of
PC
CC,
and
that
there
is
currently
no
intent
from
the
authors
to
publish
this
as
an
RSC.
This
point
of
debate
would
be
revisited
at
a
later
point
in
time.
B
B
This
is
the
RSVP
RM,
our
extensions
draft.
There
was
a
section
added
in
the
new
revision
covering
Express
links
at
this
point.
They
are
requesting.
The
authors
are
requesting
further
review
and
feedback
from
the
working
group.
So
please
do
give
it
a
read
and
reach
out
to
the
authors
on
the
list.
If
you
have
any
questions
or
concerns
with
approach
being
taken.
B
Next
is
the
SF
aware
topology
model?
There
haven't
been
any
changes
to
this
since
the
last
ITF,
but
the
authors
do
feel
that
it
it's
mature
enough
to
warrant
a
young
doctor
to
take
a
look
at
it.
So
we'll
make
sure
that
happens.
Next
is
the
long-standing
key
metric
recording
craft
at
this
stage.
Last
year
we
were
on
the
verge
of
killing
this,
but
the
authors
of
miraculously
turned
this
around.
They
did
publish
a
revision
yesterday
and
asked
for
the
authors.
B
There
are
no
more
open
issues
and
they
are
ready
to
take
it
to
the
last
call.
I
did
skim
through.
The
document
then
seems
like
all
the
outstanding
comments
have
been
addressed.
I
would
request
the
working
group
to
do
the
same
and
reach
out
to
the
authors.
If
there
are
still
any
concerns,
we
do
intend
to
take
it
to
the
list
pretty
soon.
B
B
Next
is
the
tutorial
document
that
we
have
for
using
the
tea
topology
and
towel
modeling
tunnel
models.
This
again
falls
under
sort
of
a
living
document
bucket.
There
is
currently
no
urgency
to
take
it
to
the
next
stage
the
authors
do
have
I
have
identified.
They
have
identified
a
few
or
scenarios
to
cover,
so
please
do
review
them
as
they
come
and
reach
out
to
the
others.
If
there
are
any
particular
scenarios
that
aren't
currently
available
in
the
document,
the
last
document
in
this
deck
is
the
path
computation
data
model
there.
B
They
were
a
few.
This
seems
to
be
an
outdated
slight,
but
yeah.
There
were
some
comments
that
were
received
on
the
list
from
I
believe
Olivia
and
Julian.
They
were
a
couple
of
use
cases
that
are
added,
but
those
did
not
translate
into
any
young
model
changes.
The
authors
do
have
a
few
open
issues
on
the
gate
that
need
to
get
taken
care
of,
and
they
do
believe
that
this
would
be
ready
for
a
young
dog
distributive
or
the
next
idea.
That's
all
we
have
in
this
deck.
D
So
I'll
go
over
the
updates.
From
the
last
time
we
met
I'll
present
some
open
issues
and
finally,
we'll
talk
about
the
next
steps,
X
piece.
So
the
first
document
is
the
yang
te
which
covers
the
tunnels,
LSPs
constructs
and
attributes
that
model
on
the
device,
as
well
as
on
off
the
device
or
a
controller.
D
Next,
please
so.
The
first
open
issue,
the
this
this
model
or
this
document
went
through
a
round
of
yang
doctor's
review
and
we
got
recently
comments.
The
author's
will
be
going
ahead
and
the
first
feedback
we
got.
This
is
on
the
right
track
and
and
we
will
be
addressing
the
cons
that
we
got
next.
These.
D
D
D
As
I
was
mentioning,
the
name
collision
can
happen
on
the
controller
if
the
controller
learns
of
from
different
devices
with
the
same
name.
What
we
had
suggested
is
for
learned,
tunnels
or
four
state
tunnels
from
devices
we
will
append
the
ingress
ID
to
the
name
so
that
it's
unique
so
an
example
is
a
tunnel.
R1
foo
will
be
distinguishable
from
r2
foo,
where
r1
and
r2
are
the
ingress
routers.
D
D
D
So
this
is
this
is
one
way
we
could
distinguish
it
in
the
in
this
case.
The
third
case
is
a
controller,
has
a
configured
tunnel
with
a
name,
and
then
it
learns
a
tunnel
with
the
same
name
and
what
we're
suggesting
is
we
have
penned
the
prefix
the
same
prefix
we
are
introducing
can
be
configured
with
a
different
value
on
the
controller,
for
example
remote.
D
D
The
next
draft
is
the
RSVP
model
draft.
We
have
two
modules
in
it.
The
model
covers
the
attributes
of
the
RSVP
protocol
and
signaling
parameters
per
session
per
neighbor
and
per
interface.
Next,
please
so,
for
this
draft,
it
went
through
a
round
of
doctor's
review
comments
and
we
got
the
feedback
and
addressed
it.
So
we
had
some
knits
to
address
added
nets.
We
had
state
containers
which
was
in
conflict
with
nmda,
and
we
removed
that
we
had
to
expand
some
names
of
Leafs,
some
pluralization
of
nouns.
D
There
as
well,
we
added
some
normative
references
for
imported
mod
modules.
Next,
the
second
update
the
four
four
sessions
of
RSVP.
We
had
a
single
list
and
we
were
putting
in
this
list
two
types
of
sessions:
IP
RSVP
sessions
and
rsvp-te
sessions.
The
key
of
these
two
sessions,
as
defined
into
RFC
2205
and
3209
they're
different
P.
So
one
suggestion
was
for
the
ease
of
lookup
of
a
section,
a
session
to
use
the
actual
real
key
native
key
that,
rather
than
having
a
index
that
we
needed
to
a
walk
to
match
on
the
specific
session.
D
C
A
D
So
we
added
a
couple
of
our
pcs
with
our
GP
model,
specifically
to
clear
sessions,
specific
session
or
all
of
the
sessions
and
the
clear
RSVP
neighbor.
We
have
a
hello
session
established
with
that
neighbor
and
we
wanted
to
clear
it
again.
It's
a
specific
session
or
all
of
the
sessions.
The
notifications
we
piggybacked
on
the
publish/subscribe
model
and
we
added
a
section
and
draft
to
talk
how
we
can
leverage
that
max.
Please,
with
with
this
the
next
steps
we
for
the
first
draft,
we've
addressed
all
of
the
yang
doctors
review
comments.
D
There
we
go
with
another
round
of
internal
review,
but
we
will
be
asking
soon
for
working
group.
Last
also,
we
asked
the
working
group
if
you
have
anything.
For
example,
now
Lu
had
pointed
out
the
IPSec
support.
Please
raise
the
issue
before
we
call.
We
ask
for
working
group
last
call
the
second
draft,
the
ete
tunnel
modeling
we
had
as
I
mentioned,
received
some
comments
from
the
yang
doctors
review.
We
will
be
addressing
those
and
we
will
be
requesting
a
working
group.
Last
call
after
that.
The
last
two
documents
there.
D
B
Hi,
this
is
true
from
far
we
have
the
question
regarding
the
name
collision
and
especially
the
first
point
in
the
name
collision,
which
was
regarding
the
controller
learning
the
tunnel
name
from
devices
which
is
the
same
right
and
you
using
r1
r2.
So
do
you
have
little
bit
more
details
about?
Where
will
our
one
string
will
come
and
and
how
would
you,
where
is
this
coming
from
r1.
D
That's
a
fair
point,
so
one
one
proposal
was
to
use
the
source
address
which
we
have
already
in
the
model,
but
we
think
that
you
know
it
can
be
a
DNS
name
or
or
maybe
a
configurable
name
on
the
of
the
Ingres
itself,
but
so
far
we
said
the
source
address
is
going
to
be
appended.
For
example,
if
you
think
that's
not
user-friendly,
we
should
look
into
the
different
option.
I'm.
B
D
B
This
problem
shows
up
only
if
the
controller
is
trying
to
put
everything
in
the
same
data
scope,
and
the
assumption
is
that
the
controller
knows
whom
it's
getting
it
from
and
it
will
take
the
corresponding
source.
Id
n
dependent.
How
you
know
the
society
I
mean.
The
assumption
is
that
there
is
because
you
are
getting
the
data
out
from
a
particular
source.
You
use
that
particular
source
ID
am
dependent.
E
So
this
is
a
working
group
document,
so
we
have
some
changes
since
last
revision.
This
model
hires
some
dependencies.
There
are
two
other
document
with
depend
on:
when
is
the
IDF
ki-jung
T
types?
Another
one
is
32
party,
so
post
dependency
models
have
been
changed
since
last
revision,
so
we
updated
our
model
to
align
with
them.
Then
each
of
those
two
documents
has
two
modules,
so
we
need
a
line,
possibly
all
the
other
modules
there.
E
Another
piece
of
changes
would
be
the
trying
to
resolve.
Doctors
reveal
comments.
This
is
an
ongoing
process.
We
have
fixed
the
editorial
errors
and
we
will
start
still
discussing
the
other
comments
which
is
ongoing.
So
particularly
this
is
one
we
need
to
explain
the
relationship
in
the
hierarchy
of
our
topology
to
the
related
dependencies.
We
have
argumentations,
we
have
a
difference,
so
we
also
imported
some
several
types
model,
so
this
is
need
to
be
resolved
and
another
issue.
E
This
discussion
was
brought
up
in
last
IETF,
so
it's
about
performance,
metrics,
unity,
reaction
or
link,
and
the
discussion
was
that
usually
for
the
accurate,
when
we
delay
measurement,
we
need
the
clock
synchronization,
but
in
on
some
system
such
kind
of
mechanism
is
not
there.
In
that
case,
the
system
where
yours,
a
two-way
measurement
to
do
the
estimate
divided
the
two
way
delayed
by
two.
So
in
that
case
the
two-way
measurement
measure
could
be
useful,
so
crack.
You
have
more
comment
on
this:
okay,
okay,.
F
E
E
F
Actually,
it
would
be
useful
if
quark
synchronization,
the
question
is
that
how
it
can
be
determined,
that's
a
interesting
question
and
problem
where
the
clock
synchronization
quality
is
sufficient,
so
it
may
be.
The
clock.
Synchronization
does
exist.
The
quality
of
the
clock
synchronization,
maybe
not
at
the
level
requirement,
because
there
might
be
some
applications,
for
example,
Auto,
reliable,
low
latency
communication
in
5g.
That
requires
very
high
quality
of
clock
synchronization.
What
I
want
to
say
is
that
using
two-way
measurement
to
calculate
one-way
metrics
is
useful.
E
G
E
H
E
So
hold
on
there
so
right
so
back
to
laser
modeling
right
so
internal
modeling.
Do
you
see
any
changes
need
to
be
added
to
this.
F
F
Again,
as
I
mentioned,
I
think
that
clock
synchronization
and
quality
of
clock
synchronization.
It's
very
it's
a
separate
question
and
it
something
that
I'm
not
aware
of
methods
to
quantify
it
and
how
to
monitor
it.
How
to
measure
the
quality
for
their
performance
measurement.
We
can
discuss
how
your
model
related
to
stampy
and
model,
which
is
IBM
working
group
draft
right.
E
So
please
be
reminded:
this
is
a
team,
although
we
are
not.
This
is
not
performance
metric
for
measurement
model
right,
so
internal
te
T
matrix
here.
Yes,
so
we
are
using
the
three
types,
so
the
krupin's
there,
and
if,
if
you
have
something
need
to
be
added
that
that's
probably
more
troublesome,
because
it's
already
passed
Rosco
so
and
then,
if
it's
okay,
you
can
live
with
this
then
I'll.
E
F
E
E
Then
after
last
revision
we
also
tell
some
changes
to
align
the
most
recent.
The
spring
I
saw
young
model,
so
we
took
their
latest
grouping
and
use
that
we
also
have
this
model
revealed
by
young
doctor
and
we
have
a
fixed,
some
auditorium
problems
and
then
now
we
still
discussing
some
issues
to
be
resolved.
E
When
is
the
one
comment?
Is
about
constraints
and
some
of
the
attributes
relatively
to
ice.
Are
we
added
those
constraints
to
our
model,
but
I
think
in
the
better
way
would
be
to
add
those
into
the
coping
we
are
using
fun.
So
this
is
the
ice,
our
spring
be
our
model.
So
we
talk
to
the
houses
up
after
days,
so
we're
trying
to
see
if
we
can
move
those
changes
to
the
base
model
and
also
there
is
a
discussion
but
the
URI
format,
user
ID.
So
this
this
is,
we
don't
have
much.
E
B
Hi
everyone-
this
is
truth:
I'm
will
be
presenting
two
presentations.
The
first
one
is
on
the
Vienna
yank,
so
I
think
this.
We
know
that
VN
is
the
customer
facing
yang
model,
which
she
uses
lots
of
things
from
the
T
topology
and
the
d
tunnel
model.
The
relationship
is,
as
shown
in
the
figure,
though,
nothing
has
changed
here.
B
The
main
changes
in
the
document
is
we
added
a
introduction
in
the
introduction
section,
a
details
about
how
this
model
can
be
used
in
the
5g
use
cases,
and
this
is
something
that
is
being
gonna,
be
discussed
specifically
in
the
second
half
of
the
tease.
You
have
some
topics
on
5g,
so
we
also
linked
it
up
in
the
a
CT
and
VN
yang,
and
we
hope
that
this
young
model
can
be
a
basis
for
virtual
network,
even
in
the
5g
world.
B
Apart
from
that,
the
changes
were
mostly
editorial
so
far,
and
we've
made
some
clarifications
in
our
diagram.
Make
the
pointers
to
the
JSON
examples
little
bit
clearer
so
that
people
who
read
the
model
can
understand
how
this
model
uses
the
connectivity
matrices
of
the
T
topology
to
show
the
relationship
between
the
million
members
in
the
yang
model
itself?
One
change
was
that
we
were
using
the
LTP
without
reference,
so
we
changed
that
we
have
now
using
a
reference
so
that
it
has
to
be
asked
configured
in
the
topology
model.
B
And
apart
from
that
in
the
yang
model,
we
added
reference
statement
to
make
sure
that
wherever
we
are
referring
a
leaf,
we
have
a
pointer
to
a
draft
or
an
RFC.
So
these
were
the
changes.
But
the
main
thing
is
the
open
questions
that
were
discussed
on
the
list
and
we
don't
have
a
resolution
on
that.
Maybe
the
first
one
is
pretty
straightforward.
It's
just
a
understanding
question,
but
that
led
to
the
bigger
question,
which
is:
can
a
VN
member
be
from
P
to
PE?
So
the
concern
came
from.
B
Currently
we
define
VN
as
a
list
of
VN
members
and
where
a
VN
member
has
a
source
and
destination
a
P
and
a
P
according
to
us
is
a
logical
identifier
between
the
C
and
a
PE.
So
we
always
expect
the
C
customer-facing
information
to
be
a
key
part
of
our
definition
of
VN
member.
But
for
some
use
cases
folks
are
saying
that
they
want
to
create
a
virtual
network
first
and
then
attach
the
customer-facing
information
later
so
set
up.
B
For
instance,
a
set
of
tunnels
which
are
starting
from
P
to
P
I
am
NOT
attaching
customer
information.
Now
let
me
set
up
a
set
of
tunnels
and
then,
when
I
do
the
customer
mapping
I
can
do
the
C
mapping
easier.
So
the
first
question
is:
should
we
allow
this
and
if
we
allow
it,
what
will
be
the
possible
ways
to
do
it
and
some
of
the
possible
solutions
that
I
could
think
of?
We
kind
of
wrote
it
down
and
we
had
some
discussions,
but
we
did
not
have
any
resolution.
I
Actually,
what
do
you
suggest
that
you
change
the
API
I
think
it
makes
sense,
but
I
refer
to
the
figure
pair
and
I
figure
floating
of
the
actn4
work?
Actually,
the
supportive
you
know
for
AP
supported
the
customer
view
and
operator
view
for
the
an
opponent
could
be
the
C
and
it
could
be
the
P.
So
we
already
covered
that.
Yes,.
B
Yeah,
so
that's
why
just
changing
to
AP
will
solve
the
problem,
but
I
think
the
bigger
problem
we
should
focus
on
is:
can
we
have
a
VN
member
without
any
customer
with
just
p2p?
So
so
ap
is
a
identifier
between
C
and
PE.
You
need
to
have
at
least
some
C
information.
What
we
really
want,
your
requirement
is,
let
us
have
just
p2p.
We
are
member
without
having
any
attached
C
II,
so
so
that
requirement
we
want
to
drill
down
a
little
bit
and
see
how
we
can
solve
it.
B
B
I
But
secondly,
issue:
since
you
know
you
follow
the
ACM
for
my
paralegal
14,
you
support
a
custom
view
and
operate
of
view,
so
you
need
to
distinguish
if
you
change,
if
you
have
each
other.
So
how
do
you
do
that?
Actually,
the
solution
you
may
propose,
you
may
introduce
some
indicator
whether
it
is
custom
view
or
it's
operator
view.
Another
choice
is
you
may
introduce
the
additional?
Maybe
we
call
the
node
ID
and
to
support
this
p2p
connectivity,
yeah.
B
B
B
Can
actually
yes,
you
can
use
it
as
it
is
without
making
any
change
it's
just
an
identifier.
We
have
done
that.
For
instance,
when
you
configure
a
vrf
you
can
you
bind
the
loopback
interface
to
the
vrf.
It's
just
like
that,
like
usually
it
is
for
the
customer-facing
interface,
but
your
loopback
interface
can
also
get
binded
to
an
vrf,
so
I
am
kinda
equating
the
concept
of
the
there.
You
don't
need
to
change
anything,
it's
just
when
you,
when
you
don't
know
the
information
bind
loopback
later
on,
attach
the
actual
customer
interface.
I
B
A
I
Yeah,
no,
no
I
think
that
this
is
the
moto
ad
as
I
comment
on
it
is
that
I
want
you
this
the
model
should
be
generic
remote,
oh,
not
a
couple
ways
that
a
city
and
framework
but
I
just
a
few
example,
because
you
know
that
arrived
from
the
ICT
and
framework.
So
there's
some
example,
there's
some
figure,
so
we
may
actually.
A
I
J
So
we
obviously
could
be
used
in
many
configurations
right.
So
my
understanding
is
that
you
see
VM
as
a
node,
which
has
basically
links
open-ended
links
right
and
it's
isn't
it's
the
the
responsibility
of
what
you
call
tea
service
mapping
to
assign
sees
to
to
year.
So
if
it's
all
done,
it
should
be
decouple
to
write
it.
It
doesn't
have
to
come
as
a
single
thing.
You
can
talk
about
VM
like,
for
example,
like
an
abstract
apology
or
set
of
tunnels
independently
from
the
users
of
that.
So.
B
J
Yeah
I
I
think
that
the
VM
as
the
service
doesn't
include
clients
of
the
surahs.
It's
actually
the
model
that
map's
clients
for
the
service.
It
could
be
done
at
the
same
time
or
later
or
it
could
be
changed
at
any
time.
All
right.
You
can
take
one
C
and
put
another
one
without
any
any
modification
of
VM
all
right,
so
I
think
it's
perfectly
legal
to
think
about
V
and
without
seas.
Okay,
thank
you.
L
L
B
So
this
one
is
the
recently
adopted
document,
so
I'm
sure
you
all
have
would
have
read
it
and
it
will
be
fresh
in
your
memory
and
what
does
this
model
do
if
it
is
not
that
we
define
the
performance
monitoring,
telemetry
information?
So
these
are
the
two
yang
models
which
augment
the
T
model
and
the
VN
model,
and
it
includes
the
performance,
the
performance
monitoring
parameters
which
you
could
subscribe
to,
and
apart
from
that,
it
also
has
this
scaling
information.
B
So
most
of
the
changes
that
we
did
in
the
recent
this
was
to
describe
the
scaling
but
much
more
clearly,
because
I
think
the
performance
parameters
were
pretty
clear,
but
the
concept
of
what
is
scaling.
And
what
do
we
mean
by
these
terms
that
we
are
using?
That
was
not
here,
so
we
worked
on
improving
and
adding
clarification
for
that
added,
a
terminology,
section,
etc,
and
also,
why
are
examples
described
the
network
autonomics
part?
And
what
do
we
mean
in
the
context
of
this
document?
B
There
was
a
comment
with
respect
to
what
is
the
right
reference
for
the
notification
mechanism,
the
security
section
I
on
a
section
and
all
the
other
yang
style
guides
and
references,
etc.
Thanks
to
everyone
who
commented
during
the
adoption
process,
while
we
made
these
good
changes
to
the
documents.
So,
regarding
the
terminology,
this
is
something
that
we
kind
of
put
down
in
our
document.
The
key
performance
data-
that's
pretty
clear.
These
are
the
set
of
parameters,
performance
parameters,
delay,
delay,
jitter
things
like
that
that
we
are
monitoring
on
the
VL
level
and
T
level.
B
We
describe
what
is
scaling
in
our
document.
That
is
either
you
are
scaling
in
your
resources
or
scaling
out.
So
within
the
context
of
a
tea
tunnel
of
how
your
resources
can
be
modified,
that's
what
we
mean
by
scaling
and
with
the
intent
what
we
meant
was
put
conditions
like.
While
you
are
monitoring
these
parameters,
you
could
also
put
conditions
that
this
condition
on
that
parameter
should
be
met
and
at
that
time
I
should
scale
in
or
scale
out.
B
So
that's
what
we
meant
by
the
the
scaling
conditions
and
the
intent
that
we
put
so
by
combining
the
actual
data
in
the
yang
model,
plus
these
conditions
for
scaling
and
scaling
out.
We
are
meeting
the
requirements
for
network
autonomics
within
the
limited
scope
of
the
T
and
the
VN
model.
So
that's
how
is
with
respect
to
the
terminology?
So
hopefully
this
can
help
clear
up
some
confusion
that
was
there
earlier,
so
this
part
hasn't
changed.
B
We
are
simply
augmenting
these
models,
adding
performance
parameters,
putting
the
scaling
conditions
etc
with
respect
to
scaling,
which
is
the
one
which
we
may
have
to
drill
down
a
little
bit,
so
basically
how
we
are
setting
the
scaling
condition.
You
are
mentioning
whether
you
need
to
scale
up
whether
this
is
a
scaling
out
condition
or
a
scaling
in
what
kind
of
metric
you
want
to
monitor
at
the
time
of
scaling.
What
is
the
value
when
it
reaches
that
threshold?
B
That's
when
the
condition
is
hit,
and
also
you
have
a
ability
to
put
multiple
conditions
that
you
can
be
monitoring,
multiple
parameters,
so
whether
it's
an
aunt
condition
or
condition
min
max
things
like
that.
We
could
combine
multiple
performance
parameters
and
threshold
values
via
the
scaling
operation
type
and,
of
course,
we
did
not.
We
wanted
to
make
sure
that
there
are
some
durations
involved,
that
the
threshold
must
be
read
must
be
met
for
a
particular
time
and
there
should
be
some
cooldown
time
before
the
same
conditions
get
hit
again
to
solve
those
problems.
B
We
had
put
these
parameters,
and
this
is
one
example
where
you
are
scaling
for,
while
monitoring
the
two-way
delay
metric
with
a
threshold
value
of
300,
milliseconds
and
scaling
conditions
for
utilized
bandwidth
for
again
some
MB,
and
by
combining
these
two
conditions,
you
are
saying
that,
when
this
particular
condition
is
met,
I
must
scale
out
in
this
particular
manner.
So
this
is
still
work-in-progress.
This
is
the
thing
that
we
have.
J
What,
for
example,
we
try
to
introduce
basically
some
automation
based
on
young,
which
doesn't
do
it
in
the
form
of
logic
rather
than
in
terms
of
configure
beliefs,
defines
the
thresholds
defines
the
combinations
of
different
things
that
triggers
particular
event
and
actions.
According
to
this
event,.
E
F
F
In
our
discussion
in
IBM
working
group
and
with
their
feedback
from
those
or
using
active
measurement
performance
in
the
field
on
the
network,
so
what
we
learn
is
that
min
and
Max
are
not
very
useful.
Metrics
minimum
and
maximum
mean
is
a
little
bit
more
useful,
but
what
is
most
useful
is
a
percentile
and
usually
they
do
three
levels
of
percentile
95
99
in
99.9,
and
these
may
be
used
as
thresholds.
So
once
you
have
a
test
session,
you
can
determine
their
percentile
of
the
test
session
and
compare
it
to
the
threshold.
M
M
Craft
about
the
te
telemetry
generally,
this
model
is
augmenting
the
Tito
Nova,
which
is
a
very
general
and
the
technology
free
model.
So
we
have
also
the
plans
to
integrate
those
kind
of
technology,
specific
performance
monitoring
parameters
here
or
we
allow
the
augmentation
for
the
technology,
specific
performance,
monitoring
parameters.
B
Right
now
in
T's,
of
course,
we
we
don't,
but
we
hope
like
now.
If
there
is
an
interest,
we
can
take
some
work
to
seek
out
which
can
use
this
as
a
base
and
add
any
technology
specific
things
onto
it
right
now.
We
don't
have
anything
but
yeah.
If
there
is
an
interest,
we
can
further
talk
about
it.
What
we
can
take
you
Zika.
L
One
of
them
was
clarifying
the
difference
between
SNP
share
mesh
protection
and
SM
RMS
reservation,
as
already
defined
in
SC,
48
72,
and
another
comment
we
got
was
about
what
to
do
for
APS
configuration.
We
have
also
worked
with
some
new
co-authors
on
how
to
describe
notifications
and
we
have
new
coders
that
provided
input
to
this
update.
L
So
what
is
the
problem?
We
had
arrested
with
notification?
What
happens
is
that,
since
the
protection
part
that
is
reserved
is
shared
by
multiple
protecting
Alice
pizza,
it
could
happen
that
the
failure
on
protecting
Alice
pin
number
2
will
make
unavailable
for
protection
switching
a
protecting
LSP
number
1,
and
we
want
to
notify
the
Edendale
end
of
this
protecting
LSP
that
this
part
is
no
longer
available,
such
that
it
doesn't
try
to
activate
this
part,
as
the
activation
will
fail
and-
and
the
solution
we
have
found
is
that
we
may
be.
L
The
solution
could
be
that
the
node,
where
the
text
susanna
Binion
available,
send
a
pattern
or
a
reservation
error
with
the
sakoda
policy,
control,
failure,
harder,
preempted
them
and
also
it's
set
the
past
state
remove
flag
must
not
set
it
because
the
reason
is
that
we
want
to
notify
the
end
until
ended
area.
The
protection
part
is
not
available,
but
we
don't
want
the
LSP
to
be
tore
down
and
we
would
like
to
get
that's
the
solution
we
found,
but
our
discussion.
L
We
were
not
under
percent
sure
and
we
wanted
to
get
feedback
from
the
working
group
about
whether
we
have
resolved
the
problem
and
this
exactly
the
right
way
or
to
implement
to
notify
the
endpoints
not
to
activate
a
part
but
without
tearing
down
the
state
and
then
when
issues
become
an
away
available
back
again.
So
the
protecting
LSP
number
two
is
no
longer
active,
you
get
the
APS
and
then
you
go
back
to
it.
Put
pattern
reservation.
Yes,
Perry.
D
L
Yeah
yeah
almost
not
aware
of
this
option:
okay
yeah.
We
can
think
about
that
yeah.
It
is
not
to
tear
down
and
to
let
the
end
as
the
LSP
is
not
don't,
try
to
activate
it
with
ApS.
That's
that's
intention.
Yeah,
okay,
good
suggestion.
Thank
you.
Okay.
Then.
The
second
open
issue
that
we
are
discussing
is
about
the
SNP
preemption
priority
in
edo
edo
tree.
There
are
the
rules.
L
While
the
idea
is
that
when
the
s
and
the
protection
LSP
is
preempted,
we
want
to
keep
the
state
again
as
before.
So
the
ID.
Our
feeling
is
that
we
should
not
use
the
GMP,
let's
set
up
and
all
the
priority,
but
we
should
have
a
new
object
that
carry
the
SNP
preemption
priority,
and
then
we
have
two
options:
one
is
to
define
a
new
object
or
the
other
option
is
to
define
a
new
field
within
the
protection
object,
and
we
don't
have
any
strong
opinion
about
which
one
of
the
two
we
prefer
like.
L
L
N
L
L
L
Not
only
photos
are
in
agreement,
so
input
from
the
working
group
is
really
appreciated.
The
one
is
to
kill,
say
this
outer
scope,
since
it's
for
further
study
in
edo
edo
tree
and
let
every
vendor
figured
out.
What
to
do.
Another
option
could
be
to
define
a
new
object
and
say:
is
the
content
is
vendor?
Specific
third
option
could
be
to
define
a
new
object,
which
is
a
sort
of
TLV
structure.
Where
you
can
say
some
types
are
allocated
for
standard
tracker.
In
case
of
we
have
a
standard
technology
specific
aps
we
can
develop.
L
We
can
say
for
this
specific
aps
protocol,
that's
the
the
days
of
the
structure
of
the
TLV
and
some
other
can
be,
for
example,
expert
review
or
private
allocation
for
vendor
specific
aps.
So
I
mean
any
opinion
about
what's
the
best
approach,
because
we
don't
have
a
standard
reference
for
the
aps,
so
we
do
have
these
three
options:
the
please
open
issue.
We
will
get
input
and
then
we
want
to
resolve
this
open
issue
and
get
further
feedbacks
and
comments.
A
L
L
A
A
A
H
L
A
A
L
And
there
is
nothing
about
that,
because
the
preemption
priority
for
SMR
is
relying
on
gmpls
a
top
priority.
But
and
that's
with
the
fact
that
the
preemption,
the
prior
the
LSB,
is
preempted
and
removed
from
the
from
the
control
plane.
And
here
what
we
want
is
to
keep
in
the
control
plane
and
not
activate
that
in
the
data
plane
and
so
I
think
is.
A
L
A
L
What
what
about
a
PS
configuration
I
mean
it's
just
trying
to
allow
people
to
add
their
own
just
basically
to
if
they
need
to
configure
not.
Everybody
needs
to
really
add
a
new
object,
because
if
you
rely
on
the
GLSL
expediently
fire
to
identify
your
LSP
in
the
data
plane,
you
don't
need
to
configure
anything,
but
some
many
some
people
it
may
implement
ApS
and
using
one
byte
ID,
and
then
you
you
cannot
get
it.
H
C
L
A
O
L
My
cutie,
the
situation
is
the
following:
eddo
eddo
tree:
it
doesn't
define
any
ApS
protocol.
The
sections
is
for
further
study,
so
there
is
no
generic
protocol.
That
applies
to
every
technology,
so
we
in
engineering
gmpls,
we
cannot
define,
we
have
maybe
to
go
specific
and
the
only
technology
that
is
today
defined
for
j4
SNP
is
OTN
SNP
or
you
SNP,
and
in
that
case
we
don't
have
any
aps
protocol
defined.
We
didn't
agree
on
the
format
so
idea.
Under
the
way
everybody
is
deploying
G
SMP,
with
its
own
SM
people,
I.
Think.
O
Their
opportunity
lays
on
I
to
say
we're
doing
this
doc
to
document
it
it's
when
it's
not
working
group
yet,
but
we
had
the
requirements.
This
is
working.
It's--That's
lays
on
and
asked
asked
the
question:
if
what
their
expectations
are,
because
the
other
is,
we
should
maybe
do
a
vendor
specific
one.
H
G
A
M
Good
afternoon
this
humming
from
Holly
and
I'm
going
to
present
the
interworking
between
the
GM
PRS
and
the
central
or
centralized
controller
system.
So
this
worker
is
the
30
the
in
last
month's,
and
we
have
brief
quick
update
in
July
to
capture
and
incorporated
some
offline
feedback
from
different
operators
and
vendors,
so
the
main
changes.
We
also
capture
the
open
issue
on
the
list
between
before
the
working
group
adoption
to
enable
more
interworking
scenarios,
who
is
more
explicit
text
descriptions
on
different
scenarios.
M
So
this
time
we
updated
by
adding
more
details,
mainly
on
Marty
Tom,
a
scenario
and
we
are
continuously
working
on
adding
the
multi
layer
as
well.
So,
let's
see
what
has
been
changing
so
far
in
the
last
update,
so
basically,
we
originally
were
focus
on
the
kind
of
GMP
RS
domain.
What
we
have
have
been
enabled
on
among
the
devices,
but
now
we
are
also
received
some
feedback,
saying
that
this
architecture
should
be
general
general
enough
to
allow
the
interworking
between
the
non-gm
pairs
to
me
and
the
GM
parents
to
me.
M
So
the
red
block
is
something
we
add
to
the
figure
saying
that
the
architecture
on
the
perspective
of
architecture,
the
system
can
allow
the
interaction
between
the
GMP,
RS
and
non-gm
pairs.
But
all
the
scope
of
this
draft
west
still
emphasizing
the
interworking
between
the
controller
and
the
GMP
RS
domain,
which
is
a
red
power.
M
So
and
then
we
also
update
the
scenarios
by
providing
text
on
how
to
do
the
service
provisioning
and
especially
for
the
multi
domain
cases,
and
from
this
page
and
the
next
page
we
are
providing
that
has
to
enable
both
end-to-end
service
provisioning
and
also
pass
segment
solution.
So
this
pay
tree
is
about
the
end-to-end
narrow
and
we
have
two.
M
There
are
a
ton
of
this
itani
in
their
job
and
the
whole
RSP
enable
would
be
covered
by
the
head
end
notes
and
by
using
the
RSVP
tea
protocols
to
do
the
signaling
work,
and
this
processor
can
also
be
changed
a
little
bit
to
make
an
alternative
procedure
and
make
best
use
of
the
controller.
Saying
that
the
to
say
the
first
step
is
still
the
same
to
trigger
the
provisioning
from
the
orchestrator
to
the
controller.
M
But
the
second
step
is
slightly
different
because
the
both
of
the
controllers
in
the
domain
can
initiate
their
respective
head
and
now
the
to
start
off
the
gen
PRS
signaling,
and
we
also
assume
that
there
is
GMP
our
signaling
in
the
domain
and
also
we
can.
We
implies,
as
the
ero
label
is
included,
the
Internet's
heater
from
the
controller
tools.
I
had
a
note.
M
We
have
also
have
some
considerations
on
provide
more
detailed
about
the
multi-layer
and
the
protection
risk
to
toleration
and
also
the
controller
reliability,
which
has
three
subsections
in
the
current
draft
need
to
be
treated
all
the
text,
and
we
are
also
targeting
all
adding
more
descriptions.
All
non-gm
parts
domains
are
working
which
may
introduce
some
different
issues
than
the
previous
version
of
traps.
That's
how
the
date
update.
B
B
H
H
So
we're
supposed
to
be
revising
it,
because
technology
has
changed.
Our
understanding
of
te
has
changed
and
broadened,
and
recent
discussions
in
in
a
number
of
working
groups
in
this
area
have
become
I,
don't
know
confused
about
the
term
te.
So
we
worked
out
that
the
terms
in
the
document
that
exists
are
not
adequate
for
today,
and
the
references
are
considerably
out-of-date.
So
we
plan
to
revise
it
next
slide.
H
H
So
what
have
we
actually
achieved?
Not
a
huge
amount?
We
met
in
Prague
and
decided
how
we
would
work
and
how
we
would
split
up
the
work,
and
then
we
converted
the
current
RFC
to
cram
down
to
give
us
something.
A
base
document
to
edit
and
I
did
most
of
that
AC
created
a
github
venue
for
us
and
put
the
mark
down
there,
and
a
few
of
the
teams
started
to
make
some
changes
or
whatever
the
magic
term
you
used
for
doing
stuff
in
github,
but
then
next
slide
we
got
stuck
I.
H
H
So
I
present
the
chairs-
and
maybe
the
working
group
with
four
options-
option.
One
reboot,
which
we've
kicked
the
team
that
we
currently
have
to
do
some
real
work
option
two
is
kicked
that
same
team
but
used
different
tools
and
techniques
and
hopefully
deliver
option
three
replace
some
or
all
of
the
team,
including
probably
me
an
option
for
simply
give
up
on
the
idea
of
revising
this
RFC
discuss.
H
J
B
D
P
Pleading
guilty
as
well
in
non-contributing
efficiently
as
far
as
understood
option
three
looks
quite
pointless
because
you
need
to
find
replacing
people
on
the
first
set
of
people
failed
to
take
the
time.
I
have
afraid
options
really
really
quite
fast
to
option
for
so
for
me,
between
I'm
one
and
two.
It's
up
to
the
leader,
but
I
agree
with
deserve
a
second
chance
to
try
one
more
or
two.
First.