►
From YouTube: IETF106-TEAS-20191119-1330
Description
TEAS meeting session at IETF106
2019/11/19 1330
https://datatracker.ietf.org/meeting/106/proceedings/
A
So
we
are
at
the
IETF,
as
you
all
know,
and
we
have
process
that
governs
everything
we
say
and
relates
to
everything
we
say
in
the
session
and
how
we
contribute
to
the
IETF
if
you're
not
familiar
with
it.
Please
take
a
look
at
the
note.
Well,
URL,
it's
at
the
bottom
go
there.
Basically
anything
you
say
in
this
session
becomes
part
of
our
permanent
record.
A
A
Recording
both
video
and
audio
and
the
video
is
also
going
out
to
remote
participants,
and
we
do
have
a
couple,
please
make
sure-
to
use
the
microphone
and
state
your
name
when
you
come
to
the
mic.
Even
if
you
come
to
the
mic
multiple
times
we're
taking
notes
via
etherpad,
as
we
usually
do,
please
take
a
look
at
the
URL.
Actually,
this
is
the
wrong
URL,
but
it'll
point
you
to
the
right
one.
You
can
also
get
that
off
the
the
tools
page
or
the
agenda.
Please
contribute
to
that.
A
I'm
laughing
at
the
temperature
here
we
have
someone
sitting
in
the
front
with
a
blanket
where
it's
90
degrees
outside,
but
inside
it's
a
little
chilly.
So
since
the
last
our
last
meeting,
we've
had
no
new
RFC's,
but
we
do
have
a
couple
of
documents
that
have
gone
through
the
process
are
in
the
editor
queue.
A
Thank
you
to
those
who've
been
patient
with
our
process,
sometimes
there's
a
lot
of
comments
that
have
to
be
addressed
as
we
go
through
the
iesg
and
it
takes
a
little
diligence
to
get
through
and
it
does
pay
off
in
in
getting
the
documents
and
we're
looking
forward
to
seeing
these
new
RFC's.
We
have
one
document,
that's
going
through
iesg
processing
we
have
yet
we
don't
have
any
adoptions
or
new
errata
that
have
come
in
since
the
last
meeting
we're
meeting
twice
this
time.
This
is
the
first
session.
Thank
you
for
coming.
A
A
A
A
A
We'd
like
to
remind
the
working
group
that
we
have
an
IPR
process
that
we
follow
both
before
adoption
and
then
before
last
call.
We
ask
that
all
contributors
and
authors
directly
respond.
Obviously
anyone
else
in
the
working
group
can
respond,
but
without
a
response
from
all
contributors
and
authors,
we
don't
move
the
documents
forward.
A
B
We
look
at
the
status
of
the
working
of
documents.
Next,
these
are
the
working
group
documents
that
are
not
on
the
agenda
today.
These
will
be
covered
in
the
next
few.
Slides
first
up
is
the
a
CT
and
yang
document.
This
is
the
document
that
talks
about
applicability
of
various
young
models-
lacey
TN.
There
was
one
revision
published
for
this
in
august,
apart
from
fixing
some
material
knits.
It
also
addressed
comments
that
are
raised
by
seacams
transport,
NB
IDT
team.
This
these
comments
are
sent
to
the
list.
B
As
far
as
consensus
for
this
draft
course,
the
understanding
was
that
we
would
wait
on
that
generic
tea
model
drafts
to
progress
and
then
revisit
this.
That
remains
the
current
stance
in
the
meantime.
If
there
are
any
reviews,
please
do
send
them
in
next.
Is
the
draft
that
talks
about
gmpls
signalling
extensions
for
shared
mesh
protection?
No
new
revision
since
last
time
there
are
still
some
open
issues
that
need
to
get
our
trust.
B
B
Next
is
the
PC
native
IP
document.
There
was
a
revision
published
for
this.
The
authors
do
do
state
that
they
have
another
round
of
updates
before
they
can
say
it's
ready
to
progress
to
the
next
state.
There's
also
some
open
discussion
that
needs
to
be
had
about
moving
this
from
experimental
to
standards
track.
Lew
and
I
will
have
further
discussion
on
that
and
then
make
a
call
before
we
take
it
to
the
next
stage.
B
Next
is
the
PCC
sea
use
cases
document
no
changes
since
last
time,
I.
This
continues
to
be
a
living
document.
The
currently
there
is
no
intent
to
take
it
through
the
publication
process,
but,
as
always,
we
will
revisit
it
in
due
course
of
time.
For
now,
please
keep
reviewing
as
more
and
more
use
cases
get
added
to
this
living
document.
B
Next
is
the
RSVP
RM,
our
extensions
document,
no
changes
since
last
time.
The
author's
claim
that
the
raft
is
stable,
but
they
do
acknowledge.
There
is
another
round
of
update
that
needs
to
be
made
in
the
meantime,
they're
seeking
feedback
so
please
to
give
it
to
them
if
they
have
any
next.
Is
the
SF
aware
topology
Model
draft?
B
There
were
a
fair
number
of
comments
received
for
this
from
Tom
patch
on
the
list
most
of
those
caught
addressed
in
the
last
version,
but
there's
still
some
outstanding
issues
that
need
need
a
need,
an
update
to
cover
those.
Once
that
is
done,
the
others
are
stating
it
can
be
taken
to
jung
da-jung
depressed
review.
B
B
The
last
update
and
this
deck
is
for
the
key
topology
and
tunnel.
Modeling
draft
is
basically
the
tutorial
document
that
talks
about
how
to
ease
use
the
various
models
that
we
are
producing
this
again
a
living
document.
There
are
few
more
use
cases
in
the
pipeline,
so
keep
keep
an
eye
out
for
those
as
and
when
they
come
and
send
him
your
reviews,
if
you
have
any
that's
all
we
have
in
this
deck
first
up,
is
an
update
on
the
various
T
models.
Tarick.
C
C
This
document
covers
two
modules,
te
and
t
device,
the
yang,
so
the
status
is.
It
went
and
undergone
a
yang
dr.
review
on
revision
21.
We
had
received
several
comments
and
we're
working
on
addressing
them.
I'll
be
going
over
the
plan
to
address
each
comment
that
we
received
on
the
next
slide.
The
next
step
is,
we
will
be
addressing
the
comments
as
I
mentioned
and
after
that
we'll
be
requesting
a
working
group
master
home.
C
C
There
is
a
comment
of
using
groupings
for
for
single
instantiation
commonly
you
would
have
groupings
when
you
want
to
use
it
multiple
places,
it's
possible
that
we
were
thinking
and
in
fact
it
is
the
case.
Some
groupings
are
used
externally
by
other
documents
or
modules,
so
it
doesn't
appear
in
our
module
but
they're
used
in
other
documents.
So
this
is
under
investigation
at
the
moment
and
we
will
act
on
it
accordingly.
Accordingly.
C
C
C
C
C
So
the
second
document
is
yank
RSVP.
Currently
it's
at
revision
11.
It
has
two
modules,
RSVP
and
RSVP
extended.
This
had
undergone
a
Yank
doctor
review.
We
had
received
comments
and
addressed
all
of
them
in
fact,
and
there
are
no
open
issues
at
the
moment.
The
next
steps
we
want
to
request
a
working
group
last
call
and
take
it
to
iesg
next.
C
Specifically,
this
document
and
these
two
modules
I
think
they
can
progress
on
their
own
now,
they're
RSVP,
specific
they're,
not
traffic
engineering.
There
are
the
base
RSVP
I,
don't
think
they
need
to
wait
for
the
other
ones.
Okay,
that's
my
personal
opinion
by
the
way,
all
right
and
the
authors,
I
think
speaking
for
the
authors.
C
C
You
and
I
think
this.
This
is
the
the
last
document.
It
is
he
MPLS
and
it
has
a
single
module
there.
There
is
open
discussions
incorporating
MPLS
DP
constructs
into
this
module
will
work
with
Otello
and
the
team
to
see
if
we
need
another
document
for
this
or
another
module
or
we
incorporate
it
in
the
same
document.
A
Are
there
any
reservations
about
moving
these
documents
to
last
call
we'd
like
to
really
these
have
been
going
on
for
quite
a
while
and
they're
pretty
mature
I
know,
I
have
some
technical
comments
that
I
can
certainly
cover
on
the
list
and
I,
don't
think
blocks
last
call,
but
we
definitely
want
to
wrap
these
up.
So
if
there's
any
comments
on
them
from
people
who
have
reviewed
the
documents,
it
would
be
good
to
raise
them
now.
A
E
F
I'm,
assuming
more
from
rotten
monoxide,
come
here,
quick
update
to
toe
documents.
When
is
the
layer,
3
tier
topology
model
and
another
one
is
the
SRT
tornados
or
first,
let's
look
at
this
odd,
leery,
Tea
Party,
so
the
status
is
that
we
don't
have
any
change
instance.
Last
IETF
we
asked
is
resolving.
The
young
doctors
reveal
comments,
so
editorial
changes
had
been
completed
and
we
have
send
our
responses
to
the
questions
they
raised
and
we
haven't
heard
a
confirmation.
So
we
are
still
waiting
and
we
see
that
they
will
have
further
questions.
F
F
C
F
C
F
So
the
we
had
either
option
will
work
so
one
option
we
required
the
out.
The
key
extension
know
that
Ethernet
extension
and
MP
RTP
must
have
the
packet
extension,
the
other
one
make.
What
make
it
the
optional,
the
the
adoption
can
put
in
the
packet
options
and
make
it
work.
So
the
question
is:
do
we
have
any
preference
or
we
just
let
the
tea
come
people
do
whatever
they
want
to
do.
H
G
F
So
that
actually
packet
extension,
only
I
did
a
few
structures
for
like
performance
monitoring
and
some
other
packets.
Specific
options
is
that
nothing
to
do
with
the
labels
and
the
fun
way
is
all
the
normal
extension
you're
doing
for
the
ethernet.
It's
a
totally
independent,
so
they
don't
interfere
each
other.
G
F
F
So
that's
it.
So
we
are
trying
to
resolve
all
the
issues
and
never
move
forward.
That's
for
this
document.
The
next
one
is
the
SR
and
as
RTE,
so
the
chain
changes
very
high
since
last
time
are
the
alignments
with
the
latest
dependencies.
So
when
last
time,
when
we
received
the
uncocks
review,
they
had
some
comments
on
the
coping
we
used
from
the
sprint.
F
F
The
changes
we
are
not
belong
here
anyway.
So
then
we
have
some
clean
up.
Then
we
are
continuing
resolving
the
toxic
review.
We
send
all
the
replies
still
have
another
confirmation.
Yet
then,
the
next
step
will
be
completed
all
those
things,
and
so
we
keep
eyes
on
the
common
second
writing
model
whenever
they
change
anything,
we
need
to
the
change
accordingly,
that's
it.
Thank
you.
I
Yep,
a
Thai
speaking
so
on
my
command.
The
utility
went
into
the
first
chapter.
So,
given
that
option
wine
into
selected
besides
Ethernet
and
MC
STP,
are
there
any
other
packet
technologists
can
use
this
packet
models.
I
I
A
I
was
waiting
for
you
as
since
your
C
camp
chair,
I,
was
waiting
for
you
to
bring
in
some
technologies
from
there.
I
know,
there's
some
photo
and
at
least
some
thought
on
on
wireless
related
to
microwave,
but
that's
not
really
a
packet
technology,
but
there
is
this
boss,
that's
happening
tomorrow
on
Raw,
where
they're
talking
about
other
wireless
packet,
engineered
technology,
so
I
didn't
know.
If
that's
the
way
you
were
going
but
they're,
you
know
there
might
be
something
there.
I
A
But
if
so,
this
is
an
informal
question
to
the
working
group
is
how
many
would
be
interested
in
working
on
a
definition
of
srte
and
what
that
would
mean.
You
know
we
have
policy
SR
policy,
but
not
a
good
definition
of
sr
team.
Keep
your
hands
up
for
a
moment,
so
there
there's
probably
enough
people
to
actually
work
in
that.
So
one
of
the
questions
for
the
work
the
spring
working
group
chairs
is:
do
they
want
to
do
it
in
their
working
group
or
in
here?
So
thank
you
for
that
information.
J
Okay,
good
afternoon
I'm
going
to
present
an
update,
I'm
sorry
Bellotti
speaking
from
Nokia
I'm,
going
to
present
a
big
tear
guarding
a
young
mother,
four-part
computation
request.
Well,
I'm,
sorry,
we
have
some
problem
about
the
uploading
of
the
of
the
draft,
because
there
is
a
pending
issue
with
the
T
eternal.
That
apparently
was
expired.
I
said
they
need
to
put
a
view,
and
yesterday
we
succeed.
J
So
dissing
factor
is
the
table
that
we
prepare,
and
so
we
we
will
enter
to
the
option
to
and
and
with
this
proposal,
what
we
made
is
that
we
addressed
the
issue
that
the
disadvantage
that
for
for
option
two
apparently
is
related
to
this
dis
option,
so
they
need
to
define
association
between
part
that
has
to
be
used
in
the
in
the
same
tunnel
and
the
duplication
of
tunnel
parameter
per
tunnel.
In
case
you
have
multiple
requests.
So
basically,
the
proposal
permits
first
to
associate
multiple
Pat
requests.
J
That
is
intended
to
be
used
within
the
same
tunnel
and
the
second
is
succeed
to
avoid
repeating
the
settled
tunnel
third
tunnel
based
for
any
funny
requested
part
and
these
consequently
permitted
the
server
to
easily
understand
what
are
the
attributes
that
is
related
to
the
tunnel.
And
what
is
the
attributes?
That
is
a
configure
third
part.
J
J
So
when
they,
when
computing,
the
protection
to
add
protection,
add
to
an
existing
tunnel
or
referencing
an
entry
in
the
new
list
in
which
we
provided
a
list
of
Association
identifiers,
and
so
when
the
tunnel
does
not
exist,
you
you
can
have
this
association
identifier
between
the
different
requester
to
associate,
which
are
to
be
associated
with
the
same
time.
At
the
same
time
in
the
list
are
reported.
J
J
About
the
role
of
the
path
request
is
for
so,
if
it
is
a
primary
or
secondary
part,
the
the
other
another
part
of
the
of
the
possibility
is
a
2f
destructor,
so
the
tunnel
attributes
that
addressed
the
collection
of
the
attributes
related
to
the
tunnel.
In
case
you
have
the
unprotected
panel,
so
you
have
only
single
path,
not
requested
to
associate
any
requests
related
to
tange
added
pointed
so.
J
J
J
Instead,
the
5
are
specific
for
path,
computation,
RPC,
but
three
out
of
the
them
are
all
related
to
this
issue.
So
we
think
that
once
that
we
have
solved
it
and
this
proposal
can
can
be
providing
in
young,
we
can
have
an
easily
path
to
solve.
Also,
the
other
issue
that
are
forbidden,
internal
and
the
directional
pad
with
a
symmetric
part
properties
and
and
the
other
two
issue
are
one
ended,
editorials
or
review
of
terminology,
and
the
other
is
as
soon
as
the
young
model
is
stable.
J
So
the
next
step
is
obviously
we
continue
operation
with
the
T
eternal
model
outers,
because
we
have
still
five
opening
shoe
that
you
are
painting
together
with
them
and
provide
guidance
for
technology
specific,
so
sync
up
with
your
TN
tunnel
model
outdoors
and
w.zahn
and
flex
grid.
Obviously
our
plan
would
be
to
require
a
young
daughter
review
for
July
meeting.
C
Six,
okay,
so
you're,
defining
the
association
ID
here
as
32-bit
number,
we
have
defined
an
association
some
something
similar
to
Association
object
that
we
all
know
about
it's
already
defined
for
our
GP,
but
the
idea
would
you
would
have
an
association
type
as
well.
What
type
of
Association
you
want
is
that
carotid
nurse
diversity.
C
H
The
association
is
pointed
to
one
entry
in
the
list
below
the
Italian
Association
list,
where
you
provide
the
tunnel
attributes
and
then
you
say
these
paths
should
be
part
of
this
tunnel
and
then
there
is
a
role.
It
has
to
be
the
primary
path,
the
secondary
part
or
the
reverse
primer
or
the
reverse
secondary.
So
that's.
The
idea
is
that,
with
this
patter
associated
by
being
into
a
tunnel
not.
C
C
H
K
I
had
the
similar
question
because
in
both
be
seventies,
we
have
that
Association
so
bit
confused
by
that.
But
let's
move
on.
The
second
is:
why
is
it
a
choice
between
putting
a
reference
to
a
tunnel
or
a
tunnel
Association,
because
now
I
think
I
get
a
little
bit
idea,
because
you
don't
think
of
this
Association
as
a
bigger
Association,
where
we
can
associate
LSPs
across
tunnels
as
well.
But
in
your
case,
you
want
to
do
it
only
for
one
ton
of
like.
Is
that
what
what's
happening
here?
That's
why
it's
a.
K
K
In
other
words,
what
I
mean
is
in
other
protocols
and
in
the
yang?
Otherwise,
what
we
have?
We
are
a
much
more
generic
Association
concept.
Why
it
should
we
use
the
more
generic
Association
object,
because
that's
something
that
we
have
already
know
how
to
use
and
not
define
something
very
specific
to
your
yang.
That's
the
thing
that
I
want
you
to
explore
a
little
bit.
C
C
H
We
are
already
using
the
association
from
the
tunnel
model.
This
is
because
we
want
to
associate
that
paths
which
are
in
the
same
tunnel
and
in
the
tunnel
model
they
are
associated
by
by
the
structure
of
the
young
model,
and
yet
there
are
different
entry
is
the
same
part
request,
though
you
have
to
find
another
way
to
say
these
two
paths
are
the
primary
secondary
of
the
same.
J
H
H
Speaking
at
it
is
a
generic
comment
on
here
and
tunnel.
We
have
basically,
if
I,
look
at
the
latest
II
tunnel
model.
We
have
three
ways
to
associate
paths
one
by
putting
pass
into
the
same
tunnel
one
by
associating
all
the
time
all
the
paths
between
two
tunnels,
this
tunnel
level,
Association
and
one
at
a
path
level.
When
associating
two
paths
of
two
different
angles.
Maybe
we
have
to
find
a
way
where
to
describe
this
either
here
or
in
the
part
on
the
tunnel
model.
H
L
J
J
K
Hi
everyone
I'll
give
you
a
quick
update
on
set
of
V
and
Yanks
model
that
we
have.
The
model
that
we
are
discussing
is
the
VN.
The
first
model
is
the
ITF
geunyang
model,
and
then
we
have
2kpi
telemetry
model
which
augments
the
t
tunnel
model
and
the
VN
model.
And
finally,
we
have
the
service
mapping
model,
which
has
first
a
generic
set
of
mapping
types
defined
in
one
yang
model,
and
then
the
l,
3
sm,
l,
2,
sm
and
other
and
l
1
c
sm
augments
those
with
the
generate
grouping.
K
So
I
will
go
through
the
updates
in
all
these
models.
The
overall
comment:
we
did
a
bit
of
editorial:
cleaner,
yang,
formatting
references,
all
the
style,
guide,
changes
and
thanks
for
everyone
who
gave
comments
there,
we
also
move
from
word
to
XML,
which
was
also
a
big
task,
and
that's
why?
If
you
look
at
hard,
if
everything
is
little
bit
like
looks
like
the
whole
document
is
updated.
K
Ok,
so,
let's
start
with
V
and
yang.
So
we
know
what
it
is:
it's
just
it's
a
VN
yang
model
at
the
CMI,
it's
between
the
the
customer
and
operator.
It
gives
a
very
abstracted
view
of
the
virtual
network
slice.
It
relies
on
the
T,
topology,
abstract
node
and
uses
the
connectivity
matrices
to
define
how
the
end-to-end
connections
are
being
established.
K
We
had
a
comment
that
we
discussed
in
the
last
meeting,
which
was
Jana
B&B
established
without
having
the
customer
information
that
is
I
can
set
up
a
p2p
VN
member
without
having,
without
attaching
the
customer
information
at
the
time
of
the
uncreation
and
maybe
have
an
ability
to
add
the
AP
and
the
customer
facing
information
after
the
VN
is
already
established.
So
we
made
sure
that
we
can
support
that.
Of
course,
the
VN
creation
already
had
at
the
time
of
VN
creation.
K
You
need
to
have
something
called
as
an
AP,
which
is
just
a
shared
logical
identifier
between
the
customer
and
the
operator.
So
in
the
yang
model
we
allow
you
to
create
an
AP
with
only
a
P
information
so
that
the
second
requirement
can
be
established.
So
to
do
that
within
the
AP
container.
We
added
a
node
called
PE,
which
can
have
a
reference
to
the
PE
node,
and
why
are
that?
K
You
can
create
an
AP
with
just
the
P
information
and
later
on,
update
it
with
more
customer
information
once
you
have
it,
so
this
kind
of
satisfies
the
requirement
that
we
got
during
the
last
meeting.
So
this
is
how
the
change
looks.
Pretty
straightforward
change,
just
a
reference
to
the
node
ID.
So
that's
our
first
document.
The
next
is
the
telemetry.
This
one
has
some
a
does
two
jobs:
it
has
the
performance,
one.
K
K
K
N
O
K
O
K
To
go
yeah
so
the
second
model,
which
is
about
the
telemetry
this
model
we
augment
the
tea
tunnel
model
and
the
VN
model
with
the
telemetry
information.
Again,
the
telemetry
information
comes
from
T
types
itself.
We
are
augmenting
it
here
and
we
also
have
the
scaling
conditions
as
the
scaling
conditions
being
set.
So
those
are
the
two
things
that
this
young
model
does.
K
We
did
one
change
we
earlier
used
to
put
the
scaling
condition
the
operation
type,
which
is
when
you
have
multiple
parameters
or
how
do
I
consider
those
multiple
parameters,
whether
it
is
and
or
or
we
were
putting
it
in
an
outer
container.
We
moved
it
inside
that
would
allow
us
to
have
mix
of
and
and
or
for
multiple
metric
types.
So
we
can
say
that
delay
should
be
like
this,
and
jitter
should
or
jitter
should
be
like
this.
While
the
bandwidth
is
something
else,
so
we
can,
we
have
a
flexibility
of
making
those
changes.
K
Another
mistake-
maybe
was
there
from
the
previous
version,
where
we
were
not
augmenting
so
now,
since
we
are
all
menteng,
there
is
no
need
for
us
to
have
a
reference
to
the
same
tunnel
that
you
are
anyway
augmenting.
So
those
two
changes
were
done
in
the
both
the
te
KPI
and
the
VN
KPI
model.
We
had
one
comment
on
the
mic
last
time
which
was
about
how
do
we
use?
Can
we
use
percentile
or
mean
especially
coming
from
the
stamp
yang
model?
K
We
are
currently
relying
on
the
puffins
performance
metric
attributes,
as
defined
in
T
types
and
defining
a
new
metric.
We
can
at
this
stage
we
wanted
to
avoid,
and
we
could
not
figure
out
how
adding
it
only
for
this
model
would
help
so
I
had
one
small
discussion
with
Greg
that
what's
the
next
step
we
could
do.
I
will
continue
to
have
that
discussion,
at
least
in
the
text.
We
will
add
that
this
is
just
part
of
the
problem
that
we
are
only
giving
the
telemetry
from
what
we
can
learn
from
the
notes
there
cook.
K
There
are
other
techniques
out
there,
such
as
end-to-end
measurements,
etc,
which
can
also
be
applied
in
the
end.
Some
kind
of
text
I
will
at
least
add
and
I
will
pass
it
through
Greg.
That's
our
current
thinking.
When
it
comes
to
adding
new
metric,
we
want
to
avoid
defining
new
metric
again.
We
will
get
into
AI
ppm
and
other
working
group
space.
So
at
this
stage
we
don't
want
to
go
there,
but
we
can
say
that
this
is
just
part
of
the
the
telemetry.
This
is
not
everything.
A
Dan
who's
sitting
in
the
is
in
the
back,
who
who's
also
active
on
a
draft
in
net
mod,
related
to
event,
condition,
action
framework
and
I'm
interested
in
your
perspective
on
and
you're,
the
authors
of
this
drafts
perspective
on
how
either
that
work
can
be
applied
here
or
you
could
influence
that
work.
Basically,
that
works
doing
a
generic
mechanism
for
triggering
actions
based
on
events
that
happen
on
the
node.
K
A
O
Yeah
these
change
in
from
well
way-
and
we
actually
work
together
with-
is
a
model
job
actually
work
on
the
Issei
mode
of
action.
We
did
actually
support
this
kind
of
logic
test.
We
think
it
will
be
good
idea
to
define
a
basic
model.
We
can
you
know
let
this
job
leverage
some
group
in
defining
a
basic
model.
O
A
K
So
last
young
model,
which
is
our
service
mapping
yang
model,
this
young
model,
does
a
mapping
between
the
services
and
the
various
different
ee
models
that
we
have.
So
you
can
map
either
to
VN
or
t
topology
or
te
tunnel,
and
we
had
defined
a
t
and
service
mapping
types
which
is
a
generic
container
and
that
is
being
used
by
a
by
augmenting
various
service
model.
K
We
also
added
some
things
like
availability
and
isolation
requirements
which
are
currently
not
there
in
the
service
model
itself
and
that
can
be
used
when
you
are
selecting
and
making
decisions
at
the
VN
and
the
P
topology
level.
So
that's
how
your
model
looks
the
comment
that
we
that's
kind
of
open
and
we
had
some
internal
discussions.
Now
we
want
to
get
a
little
bit
feeling
from
the
room
service
model.
We
have
idea
how
to
do
this,
but
the
requirement
exists
at
the
network
model
as
well.
K
You
want
a
map
from
l3n
em
to
whatever
t
tunnels
are
being
used
within
my
domain.
So
technically
this
mapping
what
we
have
as
a
generate
t
and
service
mapping
can
easily
be
applied
to
l3
and
M.
As
well,
and
all
we
need
to
do
is
augment
the
l3
and
M
model
with
the
same
gender
ik
grouping
that
we
have
already
defined
and
you
could
easily
use
it.
The
question
would
be
that
it's
not
a
service,
it's
a
network
model.
Do
we
do
it
here?
K
A
G
K
That's
not
the
job
of
this
model.
This
is
still
T,
so
we
are
mapping
L
3
nm.
Once
you
have
an
entity
that
in
the
network
model,
this
is
my
l3
VPN
server
network.
How
do
I
map
to
what
are
the
te
tunnels
or
or
if
it
is
in
multi
layer
thing,
even
te,
topology
kind
of
information,
so
I
would
in
this
case
not
have
VM
I.
Would
when
I
augmented
make
sure
that
the
VN
choice
cannot
be
taken,
but
T
topology
and
T
tunnel
choice
could
still
be
used.
Okay,.
E
This
is
the
opportunity
for
a
little
advert
for
l3
nm.
At
least
you
give
some
context
so
l3
nm
is
a
recently
adopted
document
in
the
ops
area,
working
group
that
is
attempting
to
bridge
the
gap
between
the
way,
a
customer
requests,
a
layer-3
service
and
a
way
that
the
network
delivers
that
service
by
partitioning
their
functional
blocks
for
delivering
the
service
and
allowing
the
l3
service
to
be
expressed
with
a
few
network
aware
pieces.
E
It's
unclear
to
me
whether
you
would
need
to
also
do
the
service
mapping
for
that,
but
it's
also
unclear
to
me
that
you
wouldn't
I
would
suggest
the
thing
to
do
is
to
sit
with
the
authors
of
l3
nm
explained
to
them
what
your
service
mapping
does.
Have
them
explain
to
you
what
nm
does
and
then
try
to
see
whether
that
matches
or
not
yeah.
D
A
K
We
had
an
email
exchange
with
Oscar
and
other
authors
of
l3n
em.
They
liked
the
idea
they
think
it's
needed
even
on
the
mailing
lists.
This
question
actually
came
up
that
whether
this
could
be
done
so,
at
least
from
the
I
will
follow
what
Adrian
suggested
and
have
a
little
bit
more
in-depth
conversation,
but
at
least
at
the
very
high
level
on
emails.
There
is
a
consensus
that
this
is
done.
This
is
needed.
The
question
which
I
was:
where
should
we
do
it?
Should
we
keep
this
more?
K
This
document,
which
is
right
in
front
of
you,
only
focused
on
the
service
model
and
maybe
let
the
LC
nm
folks
continue
on
to
have
defined
the
l3
and
M
model,
plus
the
service
mapping
right
there
in
the
ops
area
working
group.
That's
one
approach.
Another
would
be
that
we
can
can
add
it
here
itself.
P
K
All
right,
I'll
have
a
chair
okay
anyway,
so
the
the
last
point,
which
is
which
has
a
which
is
also
a
pending
issue
for
us,
we
define
a
term
called
availability
and
we
don't
have
a
good
reference
for
it.
This
availabilities
may
be
from
the
service
ability
point
of
view
and
more
related
to
a
service
model.
It
defines
like
no
service
is
99%
on
99.99.
That
kind
of
thing
we
don't
have
a
good
reference
for
it.
So
if
somebody
has
any
suggestion
or
can
point
us
to
the
right
direction,
that
would
be
very
helpful.
K
L
Mercy
City,
yes,
actually
the
thing
is
that,
with
the
term
availability
we
use
it
colloquially,
but
at
ITF
we
don't
have
a
definition
for
it.
There
is
one
RFC
on
micro,
microwave
links,
availability
and
I.
Think
we've
done
this
work
in
C
camp,
but
it
defines
the
availability
which
is
very
specific
for
this
technology.
L
I
think
that
and
I
know
some
efforts
that
been
done
to
to
define
availability
for
the
packet
switching
because
the
term
has
been
defined
in
TDM
and
because,
if
there
is
no
data,
they
fill
in
information.
So
basically
it's
a
constant
stream.
So
that's
why
they
it's
easy
for
them
to
express
it.
I,
don't
know
any
viable
definition
for
packet
based
technology,
availability
and
I
would
encourage
to
use
another
term.
A
F
Thank
you,
this
eating
problem
calling
and
presenting
the
jobs
about
the
interworking
of
JMS,
consistent
and
centralized
control
control
assisted.
First
of
all.
Thank
you.
All
the
others
listed
in
disguise
and
this
Java
is
about
describing
how
the
GMB
are
distributing
control
plan
can
be
in
the
work
with
the
centralized
can
control
assistant
in
many
different
scenarios,
for
example
the
MIDI
domain
or
multi-layer
service,
provisioning
and
recovery,
etc,
and
main
trends
of
this
version
is
the
first.
F
F
This
is
the
background
of
this
job.
We
know
we
have
been
working
on
the
GM
has
for
many
many
years
and
because
of
the
Sdn
recently,
we
introduced
the
centralized
controller
into
the
control
control
plane.
A
lot
of
typical
architecture
is
a
CTA
architecture.
We
believe
that
this
centralized
control
system
and
the
distributed
JMS
control
system
are
not
competing
to
each
other,
but
they
can
work
together
to
make
a
better
control
now.
F
This
one
point
two
is
added,
is
newly
added
in
this
version
and
further.
The
second
method
is
about.
We
stop
in
and
two
as
the
previous
session.
So
in
this
case
we
don't
need
to
say
in
the
interpolation
between
domains
using
a
CV
PT,
but
using
the
centralized
controller
system
to
the
father
in
the
operation.
F
Similarly,
we
also
have
to
a
method.
The
two
point
one
is
about:
if
the
centralized
controller
do
not
have
the
information
of
the
inter
domain
link
that
the
label
of
the
in
determining
dental
node
can
assign
the
label
and
then
use
the
centralized
controller
to
distribute
it,
this
label
to
other
domains
to
create
the
end-to-end
path
and,
in
the
right
side
the
to
point
to
method.
We
assume
that
the
centralized
control
controller
system
can
be
aware
of
the
labels
of
the
inter
domain
link.
F
F
A
A
Or
someone
wants
to
set
a
contribution,
they
could
always
set
it
to
the
list
right,
yeah
yeah.
We
would
love
to
see
this.
This
work
sort
of
moved
towards
completion.
It's
pretty
old
concepts,
we've
gone
actually
full
cycle
because
we
introduced
ug
MPLS.
What
we
were
doing
was
figuring
out
how
we
can
displace
centralized
controllers,
so
you
know
we're
going
back
and
forth
now
so
right.
Thank
you.
Thank.
F
Q
A
F
As
it
possible,
you
know,
and
indeed
or
the
configuration
of
OAM,
that's
two
different
things
for
the
OEM
in
the
data
I
think
with
nothing
change,
just
as
we
have
before
and
for
the
control
plane.
I
think
we
can
continue
the
work
to
see
if
the
anchor
vibration
signaling
can
be
used
in
this
scenario,
if
yesterday
right
I
believe
is
yes.
A
N
You
yes
hi
afternoon,
everyone
so
given
the
importance
of
sort
of
maximizing
efficiency
of
some
of
this
work
at
the
ITF
and
using
working
group
time
efficiently.
This
is
really
first
of
all,
it's
a
relatively
recent
document.
We
started
working
on
this,
the
idea,
at
least
at
the
start
of
the
year,
we're
into
our
second
version.
We
want
to
try
to
highlight
how
operators
can
use
some
of
the
yang
models
that
are
being
developed
within
the
ITF
we've
got.
N
You
know,
hundreds
of
young
models,
thousands
of
yang
models,
even
and
what
we
need
to
do
is
actually
show
how
we
can
combine
these
to
deploy
services.
So
one
of
the
more
recent
discussions
is
how
we
use
the
actn
framework
and
so
essentially
the
functional
components.
The
interface
is
combined
with
the
data
models
to
deploy
packet
over
optical
services,
so
these
are
essentially
two
layers:
one
control
via
physical
network
controllers,
for
the
optical
domain,
split
into
two
domains
that
are
not
directly
connected
sitting.
N
On
top
of
that,
we've
got
packet
layer
with
additional
sort
of
domain
technology,
they're
managed
by
domain
physical
network
controllers
that
are
connected
across
and
into
the
main
connection.
So
essentially,
if
that's
our
deployment
model,
what
we
want
to
know
kind
of
operators
and
vendors
is
how
we
can
use
the
data
models
that
currently
exist
for
providing
multi-layer
services
so
packet
over
optical
and
furthermore,
this
would
be
a
set
of
procedures.
N
The
data
models,
what
part
of
the
data
model
that
we
will
use
and
then
things
sort
of
under
consideration
are
operational
and
security
aspects
as
well.
So
the
two
use
cases
that
are
currently
in
the
document-
and
we
we
didn't-
want
to
have
a
document
that
that
sort
of
boiled
the
ocean.
We
wanted
sort
of
two
specifics
scenarios.
The
first
is
obviously
the
multi
layer
but
multi
domain
coordination,
and
the
second
use
case
is
recovery.
So
when
you
detect
failure,
how
do
you
recover
from
that
failure
and
sort
of
various
permutations
of
that?
N
So,
if
those
are
the
two
main
use
cases,
we've
got
sort
of
subsections
of
each
of
those.
So
things
like
discovery
of
existing
resources.
You
know
links
next
hot
neighbors,
etc.
You
know
we
will
actually
talk
about
in
the
document.
What
protocol
mechanisms
are
available,
how
we
set
up
the
services,
how
we
coordinate
those?
You
know
what
data
models,
what
part
of
the
data
models
are
going
to
be
used
and
in
which
order.
N
So
essentially,
this
document
is
a
cookbook
that
talks
about
setting
up
multi-layer
services
over
sort
of
packet
and
optical
domains
using
the
context
of
a
CTN.
It's
a
very
simple
topology.
You
see
it
on
the
slide
here
so
to
kind
of
get
to
the
point
of
presenting
today.
What
we
want
to
do
is
encourage
more
operator
input.
So,
right
now,
we've
got
a
good
sort
of
blend
of
vendors.
We've
only
got
one
operator
currently.
N
What
we'd
like,
because
this
document
really
is
is,
is
to
highlight
how
we
can
actually
deploy
these
services,
which
data
models
to
use,
but
also
what
gaps
potentially
exist
as
well.
So
please,
operators,
especially
that
you
have
multi-layer
networks
and
ie
every
operator.
Potentially,
please
have
a
read
of
the
document
see
if
the
current
scope
is
suitable
for
your
environment.
We
already
highlight
in
the
current
document
what
data
models
are
candidates.
We
will
actually
have
examples,
code
examples
as
well.
N
This
may
be
a
combination
of
rest,
cough
Netcom,
so
JSON
and
yang
may
have
sort
of
xml
schemas
as
well.
So
questions
for
the
room.
I
would
like
to
ask
the
chairs
if
we
could
just
sort
of
have
a
quick
show
of
hands
to
see
who's
actually
read
the
document,
especially
if
you're,
not
an
author.
Oh
okay,
let
me
ask
the
question
then
thank
you.
So
can
I
ask
if
you're
already
a
co-author
of
the
document,
keep
your
hand
down,
but
who
has
actually
read
this
document.
N
K
N
So
so
that
other
document
essentially
seems
to
focus
more
on
the
IP
services
and
the
service
mapping
on
top,
although
of
course
that's
applicable
for
our
document.
We
are
kind
of
that
lower
layer,
optical
interaction,
so
I
think
that's
sort
of
sin
initiative,
yeah,
yeah,
they're,
complementary
rather
than
competitive,
but
if
we
need
to
make
that
clearer.
K
E
E
E
And
then
we
tried
various
management
techniques,
but
we
didn't.
We
didn't
do
public
humiliation
until
each
night
EF
meeting
when
I
get
to
stand
up,
and
so
that
works
and
maybe
we
should
do
it
more.
The
way
it
worked
was
we
posted
a
draft,
so
we've
actually
done
something
and
we've
updated
it
as
well.
What
this
essentially
does
is
take
3272
puts
it
all
into
the
new
format
and
tidied
some
pieces.
A
lot
of
the
references
were
ugly
and
got
cleaned
up.
E
Thank
you
lower,
and
we
tidied
some
of
the
text
and
added
some
small
pieces
of
new
text,
but
that
only
sets
us
up
to
know
that
there's
a
lot
of
new
work
to
be
done.
We
will
I,
think
change
our
working
practices
and
do
that
work.
We
are
already
30%
too
long
without
having
to
edit
our
text.
So
anybody
who
is
good
at
operating,
marking,
blocks
of
text
and
deleting
them
is,
is
welcome
to
work
with
us.
E
We
will
need
to
be
adding
text
for
your
favorite
protocol.
How
we
do
this.
The
design
team
will
meet
on
Thursday
morning.
I
hope
to
do
some
actual
active
edits
in
the
room
and
then
hand
out
assignments
to
the
team,
and
then
we
will
edit
in
the
normal
old-fashioned
way
of
me,
holding
the
pen
and
people
telling
me
what
they
want
changed
and
hopefully
that'll
be
more
productive,
and
we
will
do
then
multiple
revisions
to
keep
everybody
up
to
date.
E
If
you're
interested
in
this
join
us
by
sending
email
to
the
t's
list
to
the
design
team
list
or
direct
to
me,
I
suggest
we
need
at
least
one
more
substantial
revision
before
we
even
talked
about
adoption.
I
know
this
is
a
targeted
thing
for
the
working
group,
but
I.
Don't
believe
that
this
draft
is
is
meaningful
for
adoption.
R
Hello
good
afternoon,
so
this
presentation
is
likely
to
look
a
little
exotic
to
the
crowd
here,
so
I
am
working
in
both
an
AV
at
Siena
V
and
in
ITF.
So
I
got
here
because
the
Nellie
chica
le
couldn't
present
this
year's
also,
basically
a
couple
of
months
ago,
SECNAV
Center
liaison
to
ITF
T's,
and
this
is
the
presentation
for
this
liaison.
Basically,
so
there
are
several
documents.
So
for
those
who
don't
know,
it's
en
AV
is
basically
the
major
standard
framework
for
telecom
virtualization
and
there
are
a
number
of
deployments
in
the
real
world.
R
This
is
something
that
is
a
big
deal,
even
though
there's
a
lot
of
open
source.
That
is
also
competing
with
it.
But
this
is
something
which
is
actually
deployed
in
the
real
world,
so
Etsy
nav
does
have
a
framework
which
is
fairly
comprehensive
and
there
is
there
are
several
documents
are
quite
published.
Is
the
one
that
you're
looking
at
here
I've
had
22
was
a
report
that
tried
to
understand
how
you
could
connect
different
data
centers
in
different
locations
to
deploy
any
v4
any
of
the
network
services
across
those
different
locations?
S
R
Area
network
infrastructure
manager,
sorry
and
this
component
is,
is
something
that
is
being
used
here.
We
have
put
this
in
this
report
and
no
that's
the
first
version
of
presentation,
but
it's
ok
I'll
do
without
and
then
we
had
a
stage
2
specification,
which
is
called
ia32,
which
is
presented
here
which
try
to
explicit
the
requirements
for
this
wim
component,
and
we
have
worked
on
it
extensively
and
today
we
have
started
working
on
what
we
call
the
stage
free,
which
is
protocols
and
data
models
for
the
interface
to
this
wide
area
controller.
R
So
this
has
been
started
already,
so
we
have
tried
to
assassin
of
existing
protocols.
Actn
is
prominently
featured
in
this
document.
It
doesn't
mean
that
you
want
to
approve
a
CDN
as
the
interface,
but
at
least
we
want
to
understand
how
a
CTN
fits
in
the
picture
and,
of
course
how,
if
that
is
how
the
actn
designers
and
users
expect
the
specification
to
be
used.
R
So
the
interface
basics
that
we
have
on
this
interface
or
there
are
four
different
sub
interfaces.
One
of
them
is
for
the
multi-site
communication
services
management
interfaces
with
the
typical
crowd
operations,
but
also
operations
on
notifications
and
on
reservation.
We
have
a
capacity
management
interface
with
also
core
operations
and
topology
and
topology
information
queries
a
fault
management
interface,
which
also
allows
to
query
the
different
notifications
for
faults
and
performance
management
interface.
So
this
is
the
kind
of
concept
that
we
deal
with
at
that
level.
R
R
As
you
can
see,
on
the
left
hand
side
you
have
this
drawing.
That
shows
that
the
EM,
the
service,
Orchestrator
and
network
Orchestrator
are
considered
to
be
equivalent
to
the
MDS
c.
But
in
other
interpretations
we
think
that
the
MDS
C
is
actually
the
wim
itself.
So
clearing
that
understanding
is
something
that
you
could
help
doing
so.
Finally,
to
get
to
what
we're
typically
asking
for
the
the
ITF
reaction,
so
we
we
would
like
to
be
Sienna.
Vee
would
like
to
be
informed
of
the
relevant
RFC's
and
internet
draft
that
pertain
to
ITF
actn
I.
R
Think
it's
pretty
easy
to
do,
along
with
the
status
of
each
other's
document
and
the
date
of
completions.
If
any,
and
also
we
are
interested,
should
we
identify
some
specific
requirements
over
a
CTN
on
how
we
can
do
to
push
them
forward
to
our
ITF
I
think
I
know,
but
the
dates
are
the
two
ITF
meetings
are
there,
of
course,
one
thing
that
is
not
written
there,
but
which
is
prominent
interest
for
us,
is
to
understand
if
the
way
that
we
are
planning
to
use
a
CTN
is
what
you
think
our
actn
should
be
used.
A
R
I
think
that
the
easiest
way
would
of
course
be
through
shared
participation,
or
at
least
three
or
four
people
that
have
common
participation
in
both
ITF
and
at
Siena
V.
So
that's
the
quickest
way,
I
would
say,
but
we
doesn't
need
to
identify
someone
in
ITF
that
would
at
least
take
a
look.
So
generally,
we.
T
A
R
A
Case
you
would
be
asking
for
us
to
comment
on
that
in
the
way
that
we
would
do
that
as
see
who
is
interested
in
participating
if
you
submitted
an
internet
draft.
That
would
be
something
that
the
working
group
would
actually
definitely
look
at.
So
just
keep
that
keep
in
mind
how
the
process
works.
The
other
suggestion
is
to
talk
with
I
think
it's
the
IAB
that
manages
relationships
with
other
organizations,
I,
don't
believe
as
a
relationship
between
the
IETF
and
that's
Etsy
and
having
a
formal
relationship
might
house.
A
A
E
Farrell,
so
first
I
think
it's
really
good
news
that
a
CTN
is
reaching
out
beyond
this
working
group.
So
thank
you
for
that.
Thank
you
for
communicating
and
pointing
out
the
work
and
I
think
you're
right
that
the
most
efficient
way
of
achieving
progress
is
by
mutual
participation.
You
may
find
it
hard
to
get
people
to
go
to
even
more
standards
meetings,
so
emails
are
good,
be
careful
of
the
formal
relationship,
formal
liaison
thing.
E
There
is
no.
As
Lou
says,
there
is
no
formal
relationship
between
the
IETF
and
Etsy
at
the
moment.
That
would
take
time
to
set
up
and
send
in
a
formal
request
for
a
formal
response
will
fall
into
the
quagmire.
What
you
want
really
is
an
individual
to
be
sending
a
mail
to
that
tease,
saying
we're
doing
this
stuff.
Does
this
look
right
and
getting
other
individuals
to
comment
back?
That's
that's
the
effective
way
to
make
progress,
not
asking
for
the
IETF
s,
formal
consensus
opinion
on
something:
okay,.
S
Result
from
Nokia
another
thought
about
this
interface.
If
I
understood
correctly,
the
interface
is
trying
to
basically
address
the
connectivity
between
to
the
virtual
natural
function
in
different
data.
Centers,
the
upper
layer
is
a
request
in
the
connectivity,
the
new
initiative
that
we
have
on
the
network
slicing
design
team,
the
interface
that
we
are
try
to
address
I
think
could
be
applicable
here
as
well.
The
upper
layer
is
requesting
so-called
transfer
slice
or
connectivity,
which
are
the
logically
independent
connection
that
we
want
to
do,
and
this
might
be
another
the
way
to
do
this.
R
A
P
No
standpoint
is
in
my
previous
I
have
participated
in
Etsy
and
leadership
of
Etsy
doesn't
recognize
ATF
as
such,
so
saying
that
the
relationship
with
Etsy
would
be
deceiving.
What
you
see
here
is
particular
IG.
Trying
to
work
with
ATF
would
be
great
to
establish
this
relationship,
but
it
doesn't
really
and.