►
From YouTube: IETF115-TEAS-20221108-1300
Description
TEAS meeting session at IETF115
2022/11/08 1300
https://datatracker.ietf.org/meeting/115/proceedings/
A
B
Hello,
welcome
to
the
teas
working
group
in
London,
good,
to
see
everyone
here
physically
and
virtually
appreciate
everyone's
participation.
I
am
Lou
Berger.
This
is
pavon
biram,
my
co-chair.
We
also
have
Luis
Contreras
here.
Is
our
secretary
yeah
great
to
be
here
in
person
and
great
to
have
everyone
online?
B
This
is
the
ITF
notewell.
We
have
a
process
that
covers
participation
and
basically
everything
you
say
here
becomes
part
of
our
permanent
record
and
is
a
contribution
to
the
ITF.
If
you're
familiar
with
this
braid,
if
you're
not,
please
take
a
look
at
that
URL
off
of
the
main
ITF
page
and
familiarize
yourself
with
our
processes
and
policies.
B
The
ITF
also
has
a
code
of
conduct
which
talks
about
how
we
should
interact
with
each
other.
Basically,
it's
saying
be
professional,
be
courteous,
it's
okay
to
have
good
and
maybe
even
a
little
heated
discussion,
but
keep
it
Technical
and
please
always
treat
each
other
with
respect.
And
of
course
we
have
a
document.
Bcp
54
governing
this.
B
For
this
meeting
we
have
both
on-site
and
remote
participants.
We
are
going
to
try
very
hard
to
keep
the
playing
field
level
between
both
and
so
each
can
participate.
Equally.
Part
of
that
is
what,
if
you're
in
the
room,
if
you're
on
site,
we
use
the
on-site
tool
to
part
to
control
our
participation.
Specifically,
if
you're
going
to
go
to
the
mic,
we
really
ask
that
you
use
the
tool
and
join
the
queue
just
like
any
other
remote
participant.
B
It's
also
how
we
identify
who's
been
in
the
room,
and
this
is
also
important.
This
is
our
virtual
blue
sheets,
so
everyone
in
the
room,
we
ask
to
scan
the
QR
code
and
jump
on
the
on
the
tool.
If
we
do
decide
to
talk
about
adoption
or
anything
on
the
procedural
side,
we
will
do
polling
through
this
tool
and
that
will
be
we're
not
going
to
raise
hands
like
we
used
to
or
hum
we're
going
to
use
the
tool.
B
So
it
really
is
important
if
you
want
to
fully
participate
in
this
meeting,
to
scan
the
code
and
and
jump
on
the
other
thing.
On
the
slide,
we've
been
asked
to
remind
people.
The
policy
of
this
meeting
is
wear
a
mask,
so
please
wear
a
mask
fully
completely.
There's
masks
in
the
front
if
you
need
one.
The
exception
to
this
is
that
if
you're
at
the
front
speaking
you
can
optionally
remove
the
mask,
you
don't
need
to
we're
wearing
ours.
B
You
can
wear
yours,
it's
up
to
you,
remote
participants,
you're
here,
that's
great,
so
you've
that
you've
done
the
hard
part.
We
do
ask
that
if
you're,
not
speaking
to
mute
your
mics-
and
that
includes,
if
you're
presenting
sometimes
Echo,
is
introduced
in
by
remote
participants.
So
if
you're
taking
questions
just
meet
yourself
during
the
Q
a
period.
B
I
think
we've
talked
about
most
of
this
except
I
didn't
mention
that
we
have
our
joint
note
taking
going
on
as
well.
If
you
look
in
the
chat
session
on
meet,
Echo
you'll
see
a
link
to
our
note
taking
page
and
please
join
us
there
and
help
make
sure
your
comments
are
appropriate.
Captured
or
comments
of
your
colleagues
are
also
represented.
B
We
have
a
pretty
packed
agenda.
We
are
not.
We
don't
expect
any
changes.
The
one
thing
I'll
mention
is:
is
we
actually
have
two
sessions,
so
we
have
a
they're
back
to
back,
but
because
of
the
way
media
cooperates,
we
will
be
taking
a
break
between
the
sessions.
B
We
have
an
incoming
liaison
that
actually
we
have
multiple
Liaisons.
We
have
one,
that's
pretty
interesting.
It
talks
about
gaps
that
the
Etsy
folks
would
like
to
see
addressed
and
by
the
work
in
the
different
working
groups.
We
think
that
this
is
definitely
worth
reviewing
and
the
way
we
have
done
Liaisons
in
the
past
is
we
take
proposals
from
the
group.
You
know
we're
contribution
driven
here
and
then
curate.
What
comes
in
from
the
group
and
then
send
a
formal
response.
C
B
Yes,
I,
don't
know
if
he's
online,
you
know
he
was
in
the
last
meeting.
I
was
in
I,
don't
see
him
I,
think
that's
wonderful
and
if
oh
Scott
is
in
the
queue
okay.
D
Yes,
thanks:
I
was
just
waiting
for
my
microphone
to
become
hot,
so
thanks
Loa
yeah
I
was
he
beat
me
to
it.
You
were
talking
about
the
Etsy.
One
I
was
going
to
wait
to
make
that
point.
So
if
anyone
has
anything,
they
want
to
do
or
update
to
the
otnt
standardization
plan.
E
D
B
All
right,
that's
great,
and
typically
we
have
done
those
responses.
I
think
ccamp
has
taken
the
lead,
I
I
think
you
know
wherever,
whichever
group
you
want
to
run
it
in
that's
good,
but
please
advise
the
other
groups,
which
group
will
will
be
focusing
the
discussion
on
and
until
then
just
keep
every
all
the
the
four
groups
coordinated.
Thank
you
appreciate.
It.
B
We
are
all
familiar
with
working
remote,
because
this
is
just
a
reminder
that
you
have
working
group
resources
available
to
you.
If
you
would
like
to
start
having
informal
public
meetings
like
we
do
on
certain
topics,
and
we
also
can
schedule
interims,
as
is
appropriate,
based
on
working
for
Pinterest.
B
We
have
a
formal
process
at
this
point.
This
is
pretty
old,
so
I
don't
think
we
need
to
talk
about
it.
B
And
something
new
that
has
come
up
from
the
routing
80s
and
I'll.
Do
you
want
to
say
something?
B
B
F
B
Thanks
so
the
routing
ads
have
asked
to
change
the
timing
of
routing
directorate
reviews,
so
in
the
past
running
directorate
reviews
were
done
during
ietf
last
call.
The
request
is
that
we
perform
it
before
submitting
the
documents
to
the
isg
in
general.
We
will
do
that
along
with
working
group
last
call,
but
sometimes
it
might
be
after
particularly
because
we're
catching
up
to
the
new
process.
B
G
Okay
good
afternoon
next
on
the
agenda
is
the
working
group
document
status
next
slide.
G
G
There
are
three
documents
colored
in
blue
or
that
are
on
the
agenda
today,
so
that
leaves
us
with
18
documents.
The
status
of
each
of
these
18
documents
is
part
of
this
slide.
Deck
I
will
not
be
walking
through
the
status
of
each
and
every
one
of
those.
In
this
session,
like
always,
I
will
double
click
on
a
select
few
and
select
few.
That
we
believe
need
some
immediate
attention
and
dwell
on
those
for
the
rest
of
them.
G
You
can
walk
through
the
slides
at
your
own
pace
and
ask
questions
if
any,
you
can
also
check
the
history
of
each
of
these
documents
in
the
data
tracker
to
fetch
the
current
status,
we
have
been
fairly
conscious
about
keeping
this
current
and
update
up
to
date.
So
please
make
use
of
that
as
well.
Can
we
jump
to
slide
four.
G
This
is
the
act
and
POI
applicability
document.
There
was
a
comment
from
the
chairs
earlier
about
adopting
a
technology
agnostic
approach
for
describing
the
various
use
cases
that
are
discussed
in
this
document.
There
was
a
question
on
how
to
go
about
doing
this.
There
was
some
clarification
given
offline
to
the
authors
yesterday
and
I
believe
the
authors
have
agreed
to
make
the
relevant
changes
in
the
next
revisions.
G
This
is
the
act
nvn
young
document.
The
authors
have
stated
that
this
document
is
ready
for
last
call.
So
we
would
like
to
request
the
working
group
to
review
this
in
anticipation
of
an
upcoming
last
call.
If
there
are
any
questions
or
concerns,
please
do
reach
out
to
the
authors
on
the
list.
The
next
document
that
we
would
like
to
draw
your
attention
to
is
on
Slide
10.
G
This
is
the
pceccu
scales
document.
We
did
conduct
an
early
routing
diet
rate
review
for
this.
There
were
some
comments
that
came
out
of
this.
There
was
a
revision
that
was
published
yesterday,
I
believe
addressing
some.
If
not
all,
of
the
comments
that
were
raised,
we
would
like,
like
to
request
authors
to
close
the
loop
on
this
with
the
reviewer
makchen
and
we'll
take
it
to
the
next
stage.
After
that,
let's
skip
to
slide
15..
G
This
is
the
young
path
computation
document.
We
took
revision
18
of
this
document
through
working
group
last
call.
There
were
several
comments
that
came
in
during
the
working
group
last
call.
Most
of
them
have
been
discussed
on
the
list
and
the
proposals
for
addressing
those
have
also
been
articulated
on
the
list.
As
part
of
this
exercise,
some
of
the
groupings
and
identities
were
moved
to
the
IDF
T
type
Stockman.
G
The
itft
types
update
document
is
on
the
agenda
today
and
itala
would
be
elaborating
a
bit
more
on
that,
so
the
plan
for
this
document
is
to
take
it
through
a
second
last
call
along
with
and
the
itft
types
update
document.
The
next
document
would
like
to
draw
attention
draw
your
attention
to
us
on
slide
19,
if
I'm
not
right,
I'm,
not
wrong.
Okay,
this
is
the
young
PE
document.
The
the
status
of
this
is
quite
similar
to
that
of
the
previous
document.
G
Most
of
the
comments
that
were
raised
during
the
working
of
last
calls
have
been
addressed
again.
There
were
some
reusable
identities
that
moved
to
the
te
types
update
document
So.
The
plan
again
is
to
move
this
to
through
a
second
last
call,
along
with
the
T
Test
update
document.
Those
are
the
documents
that
we
wanted
to
draw
your
attention
to.
Are
there
any
questions
on
any
of
the
working
Department.
D
H
Okay,
what
is
the
background
of
the
work
is
that
we
have.
We
defined,
identify
the
need
to
update
the
itft
type
CM
module,
which
has
been
published
here
at
776,
and
we
have
a
new
definitions
in
terms
of
identities,
groupings
and
type
devs
which
have
been
taken
from
the
itft
and
the
ITF
part
computational
year
modules,
which
are
important
group
plus
gold.
Some
of
them
were
identified
before,
as
some
other
were
identified
during
the
working
group.
H
Let's
call
comma
resolution
and
based
on
that,
with
respect
to
the
previous
version,
what
we
notice
that
the
scope
is
a
little
bit
larger
than
before.
At
the
beginning,
we
were,
we
were
addressing
just
tiny
updates,
one
identity
right,
one
grouping
and
one
type
Def,
and
now
we
have
a
little
bit
more
identities,
but
the
the
changes
more
compared
to
the
whole
a776
and
the
work.
H
H
What
we
did
in
this
version,
We
formatted
the
document
as
a
beast,
but
we
didn't
copy
all
the
text
from
the
existing
RFC,
but
we
just
put
somebody
was
not
about
where
these
existing
text
has
to
be
moved
and
we,
the
plan,
is
to
resolve
this
editors,
not
before
they
worked
into
Pascal.
H
We
got
some
comment
during
the
adoption
to
have
some
appendices
describing
the
process
why
we
decided
this
process,
so
we
added
this
this
appendix
and
in
this
appearance
we
also
reference
some
new
process
that
has
been
proposed
in
networking
group
in
the
last
ITF,
which
may
be
another
way
to
move
forward
on
this
rafter
and
we've
also
added.
This
attendance
is
temporary.
H
So
we
move
the
some
identities
from
the
itft
and
ATF
computation
and
we
added
a
new
set
of
identities
for
the
spec
objective
functions,
because
we
identified
that
the
objective
function
in
the
current
error
see
are
more
for
path
than
than
for
us
vector
and
we
alsoleted
some
mistakes
that
have
been
done.
Some
spec
objective
functions
which
were
should
be,
should
be
under
the
new
identity
other
than
the
new
one,
and
we
got
some
coming
from
Ayana
and
we
fixed
the
Ayana
sections
accordingly,
next
piece:
okay,
so
the
process.
H
The
reason
why
we
did
that
the
resource
note
is
because
we
have
two
options
at
this
moment
in
time.
One
is
to
keep
working
as
an
rrc
business
and
basically,
what
we
need
to
do
is
with
some
nodes
we
describe
what
has
been
changed
so
to
help
people
reviewing
only
what
we
change
rather
than
what
has
been
already
discussed
and
agreed
a
few
years
ago,
and
the
second
option
is
to
follow
the
new
process
that
is
under
discussion
in
networking
group.
H
The
only
problem
is
that
this
process
is
has
been
presented,
but
there
is
no
clear
definition,
so
it's
not
yet
fully
defined.
So
it's
easy
people
to
follow
it
at
this
moment
in
time.
So
the
proposal
now
is
to
be
a
little
bit
opportunistic,
so
to
keep
working
as
a
business
and
as
soon
as
we
are
ready
for
working
with
classical,
we
can
address
the
let
us
not
and
move
forward
as
Abyss
or
if
as
soon
as
the
if
the
new
ID
they
describe.
J
K
B
Well,
I
I
think
I
wear
a
couple
of
hats
here,
probably
too
many
but
I.
Also
chair
that
mod.
There
is
no
new
process.
There
was
an
idea
saying
it
would
be
good
if
we
had
a
new
process.
We
don't
even
have
anything
formal
on
that.
So
pretend
that
doesn't
exist
because
in
reality
it
doesn't
exist.
Yeah,
so
I,
don't
think
I
think
you
only
have
one
option.
H
Yeah,
okay,
okay,
so
we
prove
to
see
the
way
to
be
okay.
Next
slide,
please,
okay,
we
got.
We
have
two
major
outstanding
comments
from
each
other
that
was
raised
during
the
adoption.
One
is
about
being
able
to
have
a
union
I
mean
to
have
a
different
type
of
identifiers
from
node
links.
H
Intermission
points,
for
example,
we
have
a
node,
ID
is
a
URI,
and
you
know
the
instead
of
the
quota,
and
the
proposal
raised
on
the
list
is
to
update
the
details
to
make
a
union
between
a
doctor,
quad
and
a
URI,
and
the
second
issue
is
feedback.
We
got
on
using
a
binary
as
a
TTP
identifier
and
again,
a
proposal
is
to
change
it
as
a
union
between
a
binary
and
your
right.
H
These
two
comments
are
planned
to
be
discussed
during
the
weekly
call
we
arriving
on
Friday
but,
of
course,
any
feedbacks
from
the
Middle
East,
and
this
meeting
are.
L
H
H
Slide,
so
what
are
the
next
steps
is.
Okay,
we
have
the
new
other
definitions,
but
we
don't
have
text
they
describe
this
part
of
the
yarn,
so
we
can
completely
simulator
and
work
to
to
be
done.
We
we
will
keep
updating
this
draft
based
on
the
ongoing
Volume
Plus
and
our
computation,
and
so
we
will
keep
in
sync
with
the
other
two
documents
we
can
address.
Any
other
comments
we
can
receive
from
the
working
group
more
than
welcome
and
we
think
we
maybe
consider
this
working
group.
H
C
N
F
N
A
reminder:
the
motivational
digital
was
the
following.
At
the
beginning.
In
the
working
group
we
started
to
to
develop
the
finger
document
and
the
mbig
model,
and
so
but
was
not
a
detail
beyond
the
use
cases
and
the
the
needs,
the
attributes
or
the
procedures
that
we
wouldn't
need
to
be
supported
in
an
average
size
controller
and
all
the
the
slicing
stuff.
N
N
Sorry
and
the
drug
was
adopted
before
Philadelphia
meeting
before
the
previous
one,
so
yeah.
We
have
provided
some
updates
in
this
version
next,
please
so.
The
use
cases
documented
before
the
the
adoption
was
the
the
list
that
you
can
check
there:
the
5G
Services
the
NAB
base,
Services,
networking,
sd1
and
the
radio
functional
splits
we
took
all
of
them
in
order
to
derive
from
there
again
attributes,
slos
and
and
procedures
that
could
be
required
to
be
supported
by
an
average
size
controller.
Next,
please
so.
N
The
updates
from
from
the
adoption
said
that
the
document
was
adopted
before
Philadelphia
meeting.
We
generated
0-0
person
just
during
Israel
if
a
meeting,
but
we
we
didn't.
C
N
Forward
in
the
in
the
content,
so
we
had
a
this
version,
took
the
two
different
directions:
one
to
progress
on
the
technical
content
and
the
second
to
address
the
comments
received
to
be
in
the
adoption.
The
major
contribution
in
dc01
version
is
about
the
comments
being
that
were
received
and
we
have
had
some
small
technical
content,
but
anyway,
this
version
could
be
seen
or
should
be
seen
as
an
intermediate
version.
We
need
to
finalize
the
address
and
all
of
the
comments
and
for
sure
complete
the
technical
work,
so
yeah
consider
this
as
an
intermediate
version.
N
So
going
into
the
progress
on
the
technical
aspects,
we
have
a
starting
to
draft
the
use
case
of
the
data
center
interconnection,
so
there
were
some
initial
ideas
that
we
need
to
elaborate
further,
but
at
least
there
is
some
somehow,
the
the
high
level
view
the
high
level
lines
or
what
they
we
intend
to
report.
In
this
use
case,
we
also
added
a
new
section
regarding
the
gaps
with
respect
other
ITF
networks
like
efforts.
N
This
was
coming
from
one
of
the
comments
received
and
is
actually
relevant
to
have
a
summary
of
the
the
different
gaps
that
we
could
identify
as
a
consequence
of
elaborating
on
the
attributes,
as
a
loss
of
the
other
other
different
use,
cases
for
sure,
and
then
yeah
certainly
needed
as
well.
The
alignment
with
the
framework
document
and
minology
there
was
some
misalignment,
and
this
has
been
tried
to
be
fixed
in
in
this
version.
N
Even
on
the
title,
the
title
was
referenced
in
the
MBI,
we
received
a
comment
from
Alien
with
the
idea
of
changing
NBI
by
Network.
Services
lies
interface,
so
we
also
fixed
this
in
the
in
the
title
of
the
document
us
to
do.
For
the
next
person,
the
idea
is
to
complete
the
data
center
intercognition
use
case.
So
from
that
work,
let's
say
to
elicit
the
requirements
that
could
be
derived
from
the
use
case.
N
There's
laws,
attributes
so
far
the
procedures
and
so
then,
to
complete
the
section
5
about
the
summary
of
attributes
and
procedures.
We
asked
we
have
now
some
some
summary
in
this
respect,
but
there
are
missing
parts:
for
instance
the
SLA,
the
service
level
expectations
is
not
complete,
so
the
idea
is
to
complete
that
part
as
well
and
yeah
for
sure
whatever
other
technical
aspect
that
could
not
be
present
yet
in
the
document
and
the
working
group
consider
as
necessary
to
be
documented
there.
N
Next,
please,
regarding
the
comments
received,
we
receive
a
lot
of
comments
within
the
adoption
phase,
so
thanks
all
the
working
group
for
for
them,
we
started
to
address
in
them
gradually,
so
we
were
not
able
to
to
have
all
of
them
addressed
in
in
time.
I
have
added
a
number
of
backup
slides
with
the
different
detail
comments
received
marking
in
green
those
that
we
considered
has
been
addressed
in
the
current
version
and
keep
it
on
black
those
that
has
not
been
yet
addressed.
So
this
can
be
checked
by
by
your
own.
N
The
idea
will
be
for
sure,
a
part
of
improving
the
or
trying
to
address
this
in
the
document
to
answer
the
the
receiver
comments,
one
by
one.
So
this
is
also
something
pending
from
our
site
to
to
do.
The
proper
answer
to
the
comments
received,
I
mean
answer.
Bi
email
I
mean
so
for
the
passion
CO2.
N
What
we
expect
is
to
complete
the
review
of
the
comments
to
provide
the
the
proper
answer
to
all
of
you
that
provided
those
comments
and
iterate
on
there
on
the
on
the
ones
that
probably
could
not
be
easily
resolved,
or
that
we
could
have
a
different
view
so
essentially
going
to
next
ATF.
With
all
the
comments
received
address
as
much
as
we
can
next,
please.
N
So
as
next
steps,
we
want
to
complete
the
work
in
progress.
The
data
center
interconnection
use
case
the
gaps
on
the
related
with
respect
to
related
itl
Network
slice
efforts,
so
the
framework,
the
MBA
young
model
and
so
on
and
complete
the
summary
sections
so
yeah.
That
could
be
essentially
the
input
for
those
other
works
in
in
this.
N
If
as
well,
if
needed,
or
is
a
working
group
considered
necessary
to
include
relevant
some
other
relevant
cases
to
document
them
as
well
yeah,
if
there
is
something
that
you
consider
that
is
necessary
to
take
into
account
and
finally
to
collect
feedback
and
the
comments
from
the
working
group
one
more
time
and
prepare
a
new
version
for
next
ITF,
with
all
the
comments
received
being
addressed.
Hopefully,
so
that's
all
for
my
site,
I
guess.
G
Any
comments,
thanks
for
the
progress
I
I,
do
see
that
you
try
to
fix
the
title.
It's
still
a
bit
verbose.
Maybe
you
could
simplify
it.
Just
call
it
IDF
Network
slice,
use
cases
and
service
attributes
and
leave
it
at
that.
Okay,
okay,
perfect.
L
Hello:
everyone,
my
name,
is
rosarokui
from
Siena
on
behalf
of
my
co-authors
and
contributors,
I'm,
going
to
give
you
the
status
of
the
NBI
young
model
for
ietf
Network
slice
services
makes
a
slight
place
a
short
summary
of
release,
treat
of
the
document
we
have
a
weekly
meeting
and
during
that
victim
we
think
we
go
through
all
the
the
issues
that
we
have
open
issues.
We
go
through
all
and
I'm
glad
to
say
that
we
more
or
less
close
majority
of
the
issues
in
very
specific.
L
L
The
second
one
is:
we
are
improving.
The
SLO
SLE
template
again
that
we
are
having
some
enhancement
from
that
area.
Number
three
is
something
that
I'm
going
to
talk
about
that
one
in
detail
in
the
next
slide,
but
the
idea
of
the
sap
ID
that
we
added
or
peer
sap,
ID
Sabia,
stands
for
service
access
point.
We
took
that
idea
from
the
introduction
of
this
in
a
framework
and
based
on
the
request
from
Ryan
from
Telos.
L
We
realized
that
there
is
something
missing
so
I'm
going
to
go
through
this
one
in
more
detail
in
the
next
slide,
but
suffice
to
say
that
the
whole
idea
in
most
cases
is
applicable
to
CE
base
slicing
when
your
service,
the
STP
demarcation
point,
is
on
the
CE
side
and
the
prime
example
of
that
one
is
the
5G.
So
we
go
through
that,
and
there
is
some
question
that
we
want
to
ask.
L
We
took
the
idea
of
the
sub
and
we
are
introducing
and
we
call
it
Pearson
the
next
one
number
four
is:
there
was
some
discussion,
even
in
the
previous
ITF
that
how
we
can
introduce
some
custom
topology
I'm
as
a
customer
I,
want
to
create
an
idea.
Network
sliced
by
I
have
a
specific
topology
I
want
to
refer
to
that
one
as
well.
I
want
to
give
more
flexibility.
We
are
referring
that
again.
L
L
So
you
will
see
the
26
issues
closed
for
our
open.
So,
as
I
said,
we
are
more
or
less
ready
to
go
to
the
last
call.
We
will
talk
about
that,
but
I'm
encouraging
you
to
take
a
look
at
the
GitHub
that
we
have.
If
there
is
any
issue
that
you
think
is
not
addressed
properly.
Please
refer
to
us
and
from
that
aspect
that
I'm
going
to
for
the
next
U.S
like
going
through
those
four
issues,
some
of
them.
L
We
still
want
to
ask
the
whether
or
not
the
way
that
we
do
is
correct
or
not,
or
there
is
room
for
improvement.
So
next
slide,
please,
before
going
through
four
issues,
the
concept
of
stop
the
concept
of
sub
is
introduced
as
a
serious
access
point
and
is
mainly
technology
specific.
The
idea
that
you
have,
let's
just
take
a
look
at
the
picture
here-
I
want
to
create
an
end-to-end,
an
itm
Network,
a
slice,
a
from
ce1
to
ce2
from
ce1
and
ce2.
The
topology
is
a
black
box
or
should
be
a
black
box.
L
You
don't
want,
as
an
operator,
to
expose
the
gods
of
your
network
to
ce1
or
ce2
from
that
as
well.
If
see,
a
customer
wants
to
create
Network
slides
from
stp1
to
scp-2,
which
residing
on
two
CES
how
we
can
give
information
of
the
network
in
such
a
way
that
it's
a
kind
of
generic.
At
the
same
time,
we
are
not
revealing
operators
Network.
This
is
the
idea
of
the
sub
and
how
we
want
to
do
it
again.
L
So
think
of
the
sap
ID
similar
to
that
concept
and,
as
you
will
see
here,
the
idea
of
the
sap
ID
or
we
call
it
peer
support
ID,
because
we
want
to
inform
the
or
infer
that
this
is
from
the
peer
perspective.
We
introduce
this
one
into
the
model.
We
think
this
is
addressing
the
question
that
was
raised,
but
we
are
still
open
to
the
different
interpretation
or
different
question.
If
there
is
something
and
I
realized
that
Adriana
is
going
to
address
that
one
and
we
can
take
questions
most
likely.
L
A
It's
Adrian
yeah
I'm,
not
I'm,
not
well
I'm,
seeing
this
sack
stuff
for
the
first
time
in
in
this
document
and
I'm
struggling
to
understand
what
the.
A
L
Definitely
there
are
some
instances
there
are
lots
of
attribute
optional.
So
if
this
is
the
case,
if
you
are
a
customer,
don't
you
you
really
don't
care
about
that.
So
in
that
case,
if
you
most
likely
don't
need
to
specify
that.
But
if
you
care-
and
there
is
an
example-
maybe
Ryan
can
you
know-
comment
on
that-
one
if
you
care
about
that
one,
if
you
want
to
have
some
the
information
from
the
core
of
your
network,
so
this
app
ID
is
helping
from
that.
So
it's
obviously
optional.
A
L
L
P
Thanks
for
the
question
Adrian,
so
it's
meant
to
be
a
labor
abstraction.
We
don't
have
between
the
sdp
and
the
attachment
circuit.
The
attachments
circuit
to
me
naturally
latches
to
more
physical
attributes
that
I
may
want
to
reveal
the
state
of
in
my
network
slice.
But
when
it
comes
to
points
in
the
network
that
I
want
to
identify
as
places
you
can
put
virtual
functions
like
if
you're
building
a
5G
Network-
and
you
want
to
position
your
UPF
in
certain
places,
a
sap
can
be
very
useful
in
a
customer
wanting
to
distinguish
between.
P
Where
can
I
put
these
when
I
have
the
ability
to
do
so,
where
they're
fluid
and
if
the
sap
had
more
attributes
than
what
we
started
with
here.
So
I'm
hoping
we
could
dig
into
that
in
further
revisions.
You
could
decide
where
you
wish
to
place
your
sdp
for
a
certain
connectivity
path
based
on
the
constraints
that
sap
to
sap
connections
can
offer
you.
So
it's
a
layer
of
abstraction
we're
missing.
A
So
I
think
Ryan
and
I
are
going
to
sit
down
sometime
with
a
piece
of
paper
and
try
and
draw
this,
because
what
I
heard
him
just
say
was
he
wants
to
be
able
to
flexibly
place
his
sdps
to
support
functions
in
the
network
and
and
I'm
not
seeing
a
difference
in
that
case
between
a
sap
and
an
sdp,
because
in
that
case
the
the
the
the
sdp
is
not
inside
the
CE.
The
sdp
is
at
the
edge
of
the
provider
network,
but
we
we
need
to
draw
this.
L
Definitely
bring
all
the
Ultras
to
this
discussion
as
well
just
want
to
make
sure
that
we
capture
everything
so
just
to
make
sure
we
went
through
this
one,
at
least
for
two
or
three
sessions.
There
was
pros
and
cons
exactly
as
Adrian
mentioned.
Do
we
needed
I
thought
Sabi
just
mentioned
in
the
framework
in
one
sentence
and
whether
or
not
we
have
to
do
it
and
from
that
aspect
definitely
we
are
open
to
any
suggestion
and
we're
going
to
get
the
idea
of
this
one
from
the
different
Advantage
One.
L
E
So
yeah
I
have
I.
Have
one
general
question:
do
you
believe
that
the
current
model
which
you
defined
is
suitable
for
Assurance
or
okay?
It
may
be.
It
needs
to
be
augmented
by
some
additional
parameters.
Maybe
for
insurance.
You
need
something
else,
but
do
you
believe
it's
in
principle
suitable
for
Assurance,
especially
in
so
complicated
things
like
closed
loop
control
and
intent
based
Assurance
Etc
or
you
believe
it
should
be
something
different.
The
young
model
for
Assurance
should
be
not
completely
not
related
to
your
current
health
model.
L
E
General,
because
what
you
have
now
is
definitely
for
ATF,
Network
slice
right
and
sooner
or
later,
Assurance,
especially
in
closed
loop
control
in
intent,
based
model
Assurance
will
be
needed
sooner
or
later
right,
and
there
are
two
choices.
One
choice
is
to
try
to
augment
your
current
young
model
and
other
choice
is
developed
completely
different,
completely
new
young
model,
which
will
be
in
no
correlation
to
the
current
one.
Do
you
believe
the
Assurance
is
for
this
model
or
it's
something
completely,
not
related.
L
L
Assurance
is
very
important.
The
address
that
one
based
on
the
model
and
when
you
talk
about
orchestration
or
anything,
it's
above
that
model
per
se,
the
concept
is
completely
valid,
but
it's
not
directly
related
to
this
one.
So
if
you
need
or
you
if
you
want,
you
can
have
side
discussion
on
that
one
and
more
than
happy
to
go
through
what
your
thought
is
and
if
there
is
anything
that
needed.
B
O
Hi
kiriti
compeller,
so
I'm,
halfway
with
where
Adrian
is,
but
not
all
the
way
there
one
thing
I
would
suggest
is
instead
of
numbering
the
saps
sap
one
sap
to
sap
one
again
and
the
idea
being
that
oh
I
know
that
saps
are
on
different
devices.
You
should
just
say
these
are
my
saps
one
through
n,
whatever
n
is,
and
the
correspondence
between
an
sap
and
a
PE
should
be
opaque,
so
I
mean
the
way
I
look
at
it
in
the
picture.
L
But
sure
understand
what
you're
trying
to
say,
but
at
least
this
picture
is
trying
to
convey
the
idea
of
the
step
explicitly,
but
you
would
definitely
in
that
case
I
mentioned
at
the
beginning.
Itf
network
is
a
black
box,
and
this
is
the
idea
just
think
about
that
that
we
don't
know
anything
about
internal.
L
If
you
are
operator,
doesn't
want
to
expose
that
one
to
C1
and
CO2,
and
that
is
a
correct
way
if
you
want
to
be
part
of
the
discussion
more
than
happy
to
shoot
you
as
well
and
let's
go
through
it
since
everybody
is
here,
just
go
through
yeah.
Okay,
thanks
no
problem.
So
for
the
rest
of
the
presentation,
we
go
through
some
of
the
update
for
the
four
issues
that
I
mentioned.
If
you
go
to
Nexus
slide,
please
so
a
custom
topology.
L
This
is
discussed
in
the
previous
Yankovic
and
the
idea
was
if
I
want
from
the
north
one
intervals.
I
want
to
introduce
some
specific
topology
that
I
want
to
realize
my
ITF
networker
slice,
and
it
is
possible
to
do
it.
So
this
was
the
question
that
we
tried
to
address
and
the
idea
was:
can
we
use
the
T
topology
model?
So
there
are
some
potential
problem
with
that
and
there
is
some
another
draft
that
otn
slicing,
which
is
more
or
less
using
our
model
as
a
base.
L
So
the
whole
question
is
whether
or
not
t
topology
is
appropriate
for
this
one.
So
the
one
idea
of
the
key
topology
is
is
technology
specific
is
a
te
Network
and
the
whole
idea
of
the
Northbound
is
agnostic.
Well,
the
concept
that
we
have
so
from
that
that's
right.
It
seems
that
the
TA
topology
might
not
be
good
enough
for
this
application
that
we
have
it's
good
for
VN
and
actn,
because
they
talk
about
the
key
topology,
and
this
is
one
thing
that
we
want
to
also
discuss
whether
or
not
the
way
that
we
have.
L
G
Networks,
the
T
I
mean
I
I.
There
was
a
document
that
was
presented.
The
few
ideas
back
I
think
it
allows
the
author
on
that,
where
there
was
an
attempt
to
make
RFC
8795
be
classified
as
a
t
aware
topology,
as
opposed
to
being
just
a
teet
apology.
G
So
it
brings
in
a
lot
of
things
that
some
of
the
base
topology
models,
do
not
have
things
like
information
sources
and
the
idea
of
connectivity
connectivity,
matrices
everything
is
there
in
875,
you
could
have
a
you,
could
use
it
for
a
networks
where
for
defining
topologies
that
do
not
have
any
T
attributes,
it
would
still
work.
So
if
you
look
at
it
as
a
t
away,
topology
It
just
fits
them.
L
If
this
is
the
case,
we're
more
than
happy
to
take
that
phone
again,
we
are
open
to
any
suggestion
if
there
is
any
question
or
any
to
comment
on
that
one
more
than
happy
to
take.
L
The
second
issue
that
we
cover,
if
you
go
to
the
next
slide,
is
the
question
about
whether
or
not
we
need
connection
group
for
connectivity
constructs.
So
just
refresh
our
memory
in
network
slide
framework.
They
talk
about
connectivity,
construct
connectivity
construct
has
some
characteristic,
one
of
them
in
a
specific
is
SLO
SLE
and
the
whole
idea
is.
We
want
to
have
an
iitf
Network
slice,
which
has
multiple
connection
or
connectivity
construct,
and
potentially
the
SLO
and
SLE
of
those
constructs
are
different.
L
So
another
word
you
can
have,
for
example,
an
ITF
Network
as
well
as
V10
connection.
Four
of
them
have
a
specific
SLO.
Six
of
them
have
another
to
realize
that,
although
connect
connection
group
is
not
explicitly
mentioned
in
in
framework
for
us
to
realize
that
concept,
we
introduce
connectivity
connection
group.
So
basically,
connection
group
has
a
bunch
of
connection
with
a
specific
SLO
and
SLE,
and
a
network
slice
can
have
multiple
of
that.
L
So
this
was
the
idea
that
if
you
have
only
a
single
slsle,
it
seems
that
connection
connection
group
might
not
be
needed
because
the
we
introduced
that
one
to
have
multiple
SLO
SLE,
but
we
think
that,
with
the
model
that
we
have
is
very
clean
design,
although
in
some
cases
it's
Overkill,
you
don't
need
that,
but
having
that
one
is
giving
us
very
good
design
concept
that
each
sum
that
you
want
to
create
a
construct.
You
create
group.
L
First,
you
specify
the
SLO
in
SLE
and
after
that,
you
the
to
the
app
connectivity
construct
to
that
one
I
realized
John
is
the
line
and
we
can
take
questions
right
now.
Q
I
Joel
Halpern
from
Erickson
I
appreciate
that
this
model
may
be
cleaner
from
a
Yang
perspective,
but
it
strikes
me
that
having
one
set
of
descriptions
that
we
use
in
the
framework
and
then
use
in
other
drafts
that
builds
from
the
framework
and
a
different
set
of
descriptions
of
the
same
Concepts
using
different
words
and
different
terminology
in
the
Yang
model,
is
going
to
make
things
very
hard
for
folks
who
haven't
lived
through
the
description
of
well.
This
is
actually
the
same
thing
as
that.
L
Just
want
to
make
sure
that
before
going,
I
never
mentioned
whatever
you
just
said.
I
just
said
that
the
connection
connection
group
is
the
new
thing
that
is
introduced.
Yet
everything
else
is
exactly
as
defined
in
network
slice
framework.
All
the
terminology,
all
the
things
attribute.
Everything
is
already
there
I'm,
not
sure.
Q
L
Any
other
question
comments:
I,
don't
know
how
much
time
I
have
I,
don't
see
the
timer,
but
in
few
minutes
I.
B
L
Oh
okay,
so
perfect,
so
the
third
issue
that
we
want
to
cover-
or
we
the
that
the
discuss
this
one
actually
at
IIT
114
and
there
wasn't
any
progress.
If
you
look
at
the
left
hand
side,
the
issue
is
that
to
be
technology
agnostic
we
introduce,
as
you
see
the
red
protocol
and
OPEC,
we
introduce
some
attribute,
which
is
basically
value
and
identity.
So
we
didn't
want
to
have
any
specific
protocol
related
attributes.
We
try
to
go
with
the
OPEC,
we
just
specifying
an
attribute
and
then
a
value
for
that.
L
So
this
is
good
from
the
modeling
perspective
and
from
the
technology
agnostic
perspective.
But
if
you
look
at
the
right
answer,
this
might
bring
some
interoperability
issues
and
the
the
question
here
is
how
we
can
solve
that
one.
We
need
some
advice
from
The
Young
doctor
to
give
us
some
advice:
how
to
do
it
and
again
we
are
open
to
that
question.
I
guess
I
think
this
is
this
was
raised
by
Italo
if
I'm
not
mistaken.
So
maybe
you
can
add
some
comment
here.
H
Yes,
the
question:
my
first
question
is:
why
do
you
need
such
a
type
of
definition
versus
going
as
as
usually
Young
when
you
have
to
find
all
the
leaves
with
their
types,
because
I'm
not
clear
at
understanding?
What
is
the
problem
you
are
trying
to
solve
because
in
other
models,
what
you
do
you'd
say:
okay,
you
say
these
are
the
attributes
that
I
need
to
configure
to
get
this
configuration.
And
frankly
you
say
what
is
the
type,
the
rent,
the
pattern
and
all
this
stuff?
By
doing
this
OPAC
way,
I,
don't
understand.
H
Okay,
I
see
all
the
problems
with
interoperability,
because
then
you
require
some
offline
negotiation
which,
where
you
have
to
do
exactly
the
same
with
what
you
put
in
Yang.
What
is
the
name
of
the
attribute?
What
is
the
type
of
the
range
and
all
the
stuff?
So
why
you
don't
do
that
in
young?
What
is
the
problem
you
are
trying
to
solve,
which
is
difficult
for
me
to
understand.
I.
L
Give
my
answer,
but
Drew
and
boy.
You
also
feel
free
to
provide
your
answer.
As
you
see
here
on
the
sdp
side
for
the
protocol,
one
there
is
to
specify
all
the
product
protocol
that
you
want
to
support
btp
aesthetical,
but
he
didn't
want
to
go
that
way
from
that.
That's
where
you
will
see
the
technology.
H
You
don't
want
to
put
IP
in
the
yam
model,
but
then
in
the
young
instance
you
have
to
write
AP
and
the
controller
needs
to
be
IP
aware.
You
cannot
configure
an
IP
protocol
without
being
IP
technology
specific.
So
why
do?
What?
What
is
that?
Why
do
we
need
a
model
which
appears
to
be
Technologic
when
the
real
implementation
of
that
model
will
definitely
be
technology
specific,
because
the
value
that
you
can
write
there
are
technology
specific
attribute.
You
have
to
write
it
down.
Ip
you
have
to
write
it
down.
H
H
M
M
M
I
totally
understand
that
we
are
not
checking
it
in
the
Yang
model.
Now
we
have
to
implement
that
logic
of
checking
somewhere
else,
but
at
least
the
Yang
modeling
would
be
simpler
and
we
I
know
that
we
have
a
different
point
of
view
there
and
that's
why
we
want
to
Arbiter
from
maybe
young
doctors
or
something
where
we.
M
Our
question
is:
if
we
have
a
young
model
that
we
would
want
to
be
technology,
agnostic,
not
follow
the
typical
approach
of
defining
a
base
model
and
then
augmenting
IP,
Optical
microwave,
all
the
things
that
we
have
done
in
the
past.
If
you
want
to
define
a
single
model
which
remains
technology,
agnostic
and
up
apply
this
logic,
how
do
we
find
a
good
middle
ground?
That's
where
we
are
struggling
and
we
are
discussing?
We
are
still
open
to
all
the
suggestions
from
experts.
H
L
What
is
your
suggestion
at
all
just
put
everything
there?
Maybe.
H
C
H
That
will
let
also
the
user
know
if
you
support
IP,
you
advertise
the
IP
augmentation.
If
you
don't
support
Apu,
don't
advertise
the
pigmentation,
so
the
user
will
know
what
type
of
information
it
can
configure
using.
We
cannot
confuse
otherwise
again,
you
can
do
that.
You
just
have
to
do
it
offline
and
you
have
to
reinvent
do
another
mechanism
that,
for
which
I
I
see
younger,
is
trying
to
solve
this
problem
by
saying
that
with
the
young
library
and
all
this
stuff
is
going
to
give
all
the
information
that
you
need.
H
L
M
Yeah
so,
for
instance,
in
that
metric
type,
all
the
values
are
not
of
the
same
type
like
sometimes
we
use
decimal,
sometimes
fraction,
but
we
have
this
decided
that
we
are
going
to
just
use
un64
and
it
is
the
job
of
the
implementer
to
look
at
the
metric
type
and
decide
what
the
value
should
be
and
check.
Similarly,
our
idea
was
that
when
we
have
a
particular
identity,
we
can
say
what
is
the
type
we
are
expecting
when
this
identity
is
used.
M
For
instance,
if
the
identity
is
IP,
we
can
say
the
format
in
string
in
the
Yang
description.
You
are
writing
it.
You
are
not
writing
it.
Using
the
the
Yang
must
statement
or
the
string.
This
thing
so
I
think
it
is
still
possible,
but
yeah
I
think
we
are
not
converging
on
this,
so
we
do
need
external
help
and.
F
I
was
from
future
we
just
a
quick
comments
on
the
opaque
attributes,
so,
basically,
with
the
OPEC
athletes,
we
are
not
going
to
be
able
to
validate
the
value
with
Yanks
with
the
young
schemat
right
and
that's
one
thing,
and
second
thing
is:
if
there
are
a
little
complex
attributes,
that's
a
little
Beyond,
a
simple
value.
L
B
It
sounds
to
me
that
it
might
be
good
to
bring
in
an
early
Yang
doctor
review
and
comments
to
help
with
this.
We
already
told
them
about
it.
Yeah
so,
in
my
experience,
is
that
in
general,
the
the
models
were
developing
were
trying
hard
to
move
away
from
putting
restrictions
and
descriptions
and
to
move
towards
allowing
automated
validation
as
I
was
just
talking
about,
and
so
it
would
go
against
sort
of
where
you're
headed
and
where
you
have
to
have
some
other
context
to
know
the
types
to
me.
B
It
sounds
like
you're
going
to
do
some
really
hard
validation
of
a
lot
of
when
statements
to
say.
You
know
when,
when
we're
set
to
this
type,
this
the
UN
64
has
these
allowed
values
and
that
that
seems
like
a
lot
of
more
complexity
than
just
having
a
choice,
statement
and
I
think
you'll
get
that
from
getting
a
Yang
doctor
to
really
work
with
you
and
we'll
we'll
deal
with
it
a
little
differently.
B
But
this
there
are
cases
where
we've
done
augmentation
and
to
allow
for
multiple
Technologies
and
I'm,
not
sure
why
not
to
just
follow
one
of.
J
L
R
Do
we
put
here
everything
that
we
need
in
a
specific
way
or
not,
and
we
ended
up
okay,
this
need
to
be
used,
so
we
decided
to
put,
for
example,
if
you
have
the
sample
of
the
bdb,
it's
a
bgp
billing
that
you
need
to
put
so
we
put
the
the
structure
with
the
let's
say:
minimal,
set
minimum
set
of
things
that
need
to
be,
as
they
say,
agreed
between
the
the
customer
and
the
and
the
network,
and
it
was
not
just
a
collection
of
values
that
we
consult.
R
So
sometimes
you
need
to
put
soup
trees
there.
So
this
is
why
just
having
a
collection
of
opaque
values
and
might
not
fit
all
the
cases,
so
I
think
it
would
be
better
to
have
a
placeholder
and
maybe
to
have
just
okay
bdp
specific
building.
Here
you
can
have
it,
it
has
a
completely
structure,
but
it's
a
complete
well
defined
and
you
can
exchange
it
with
the
customer
and
you
don't
have
anything
left
out.
Otherwise,
you
might
have
a
trouble.
Okay,.
M
But
you're
taking
time
from
others,
just
a
tiny
comment,
I
think,
like
you
know,
what
has
happened
is
over
time
initially,
when
we
were
proposing
ITF
networks
like
saying
there
was
this
whole
thing
about.
We
already
have
other
service
model,
they
are
different,
realization
technique
and
we
wanted
at
that
time
the
requirement
on
top.
M
So
was
not
trying
to
attend
another
working
group.
M
So
what
I
was
saying
was
at
that
time.
The
requirement
was
that
we
wanted
to
keep
this
model
as
much
technology
agnostic
as
possible.
That
was
a
very
explicit
requirement
from
the
top
that
we
didn't
want
to
add
too
many
details
about
l3sm
l2sm,
how
it
is
realized.
So
we
really
were
thinking
of
that
and
I
have
seen
now
that
things
have
changed
a
little
bit.
People
do
realize
that
this
model
is
anywhere
needed,
irrespective
of
this.
M
So
if
we
want
to
get
more
feedback-
and
this
was
very
useful-
and
if
the
general
mood
of
the
working
group
is
that
we
should
get
out
of
this
opaque
way-
and
this
is
the
base
IDF
Network
slice
and
then
you
need
to
add
more
L2
stuff,
okay,
go
and
augment
with
L2
characteristics,
with
L3
characteristics,
with
bgp,
with
IP
with
otn.
If
that's
the
direction
that
we
are
going,
I
think
it
would
be
good
to
be
more
explicit,
and
then
we
can
take
that
direction.
L
Issue,
for
is
a
simple
IP
address
related,
so
we
just
change
something
to
be
very
specific
to
prefix
and
the
IP
address.
This
is
a
minor
issue.
I
just
put
it
there
for
the
completeness,
because
I
specified
that
we
have
four
issues
and
last
slide
is.
If
there
is
any
other
comments,
more
than
welcome
to
take
them
and
I
think
we
are
ready
for
the
last
call.
G
We
are
now
moving
on
to
the
individual
draft
section.
This
is
another
of
those
Network
slice,
instantiation
documents
we
do
have
Fair
number
already.
So
we
would
like
to
request
our
various
authors
to
see
to
find
Opportunities
where
you
can
merge
with
existing
documents.
N
So
as
a
reminder,
the
context
of
the
what
motivated
this
draft
was
that
we
have
a
number
of
of
artifacts
to
to
play
with
on
one
hand,
we
have
the
idea
of
never
aslay
services
with
the
requirements,
the
first
framework
and
attributes
and
functionalities
or
procedures,
so
we
have
one
hand
of
the
neighborhood's
work.
On
the
other
hand,
we
have
all
the
idea,
Network
automation,
work
regarding
service
models,
Network
models,
the
models
on
this,
every
mapping
of
to
this
team
and
models,
and
also
the
ACLS.
N
So,
with
these
articles,
we
did
tools
together
with
existing
architectures,
like
kctn
or
the
service
model
of
the
explanational
service
models.
We
figured
out
how
to
collect
all
these
all
this
work
and
trying
to
do
a
a
a
way
of
how
to
use
or
how
to
to
play
with
the
demo
less
models
and
the
service
and
network
models
in
a
way
that
we
could
Define
and
and
straightforward
way
of
using
all
of
them
next,
please.
N
So
we
consider
also
a
potential
architectures.
This
was
a
kind
of
brainstorming
exercise
to
understand
how
we
could
play
with
the
fact
of
having
the
functionality
of
ITF
network
is
less
controller
either
as
part
of
a
network
orchestrator
or,
let's
start
around
element
or
a
part
of
a
network
controller.
So
these
are
ideas
that
are
now
reflected
in
the
router.
N
Probably
we
need
to
work
a
little
more,
a
little
a
bit
more
on
that
they
make
the
sense
or
not
to
understand
they
make
sense,
but
well,
at
least
by
now
we
are
considering
this,
so
we
will
have
different
ways
of
of
realizing
that
there
never
is
controller
in
an
overall
architecture
in
a
service
provider
side.
So
this
was
a
reminder
as
well.
So
next,
please
so
the
updates
in
in
this
in
this
version.
Well,
we
updated
the
for
ITF
in
Philadelphia
and
also
for
this
other
ATF.
N
So
for
the
best
on
zero.
Four,
we
corrected
a
number
of
well,
we
collected
figure
five
that
was
essentially
how
to
what
could
be
the
relationship
between
the
its
Network
slice
model,
the
NBA
young.
We
respect
the
service
model
and
the
network
model,
so
we
clarify
some
point
in
the
figure
that
was
not
so
clear.
We
also
added
the
description
of
the
the
how
to
map
the
parameters
of
the
network,
the
the
MBI
with
respect
the
layer,
3sm
or
the
larger
2sm
so
trying
to
reconcile.
N
Let's
say
what
could
be
the
attributes
in
the
different
models
and
see
what
could
be
missing
or
what
how
they
could
match.
We
move
also
from
the
annex
the
the
relationship
of
this
model.
Then
bi
will
respect
the
service
model
and
we
fix
a
number
of
typos
that
were
there
in
that
version.
Also
updating
the
references
in
some
cases
from
previous
adopted
plots
to
actual
rfcs
for
this
ITF.
We
also
have
the
work
in
the
general
alignment
with
respect
the
technology.
N
N
So
what
we
are
proposing
here
is
that
we
could
have
probably
two
or
two
paths
to
to
follow:
either
the
to
translate
the
ITF
and
average
life
service
model
to
as
a
service
model
right
either
layer,
2
or
ir3
or,
alternatively,
we
could
take
the
ITV
negro
slide
service
model
and
translate
it
to
a
network,
a
network
model,
so
both
path
seems
for
us
have
feasible.
N
N
So
our
next
steps
we
we
will
work
on
version
zero.
Six,
the
the
idea
is
to
review
the
architectural
models
that
are
represented
at
the
beginning,
so
to
understand,
if
all
of
them
make
sense
or
not.
If
there
is
something
missing,
so
probably
we
could
be
necessary
to
clean
up
a
little
bit
the
the
different
options.
This
is.
These
were
just
for,
illustrating,
let's
say
the
possibilities,
and
with
that
having
an
idea,
what
could
be
the
kind
of
translations
that
we
could
require?
N
Also,
potentially,
could
be
the
case
that
we
could
consider
the
the
service
is
being
requested
by
a
service
model,
and
then
the
realization
is
done
through
a
network
slide.
This
could
be
maybe
the
case
of
using
otn
slicing
so
having
a
a
ladder,
3
service
model
that
is
later
on,
so
how
entirely
or
partially
being
implemented
and
realized
by
otns
slicing.
So
we
will
document
this
as
well.
N
We
need
to
complement
and
complete
the
relationship
between
the
mbir
model
and
the
layer,
three
and
layer,
2
Network
models
and
yeah,
and
we
will
keep
working
on
on
detailing
the
different
implementation
options
and
and
the
operational
considerations.
So
as
as
final
statements,
the
idea
would
be
to
collect
feedback
from
all
of
you
and
yeah.
We
will
and
we
would
like
to
to
request
adoption
or
have
it,
at
least
in
in
the
horizontal
version
of
this
document,
maybe
targeting
next
ITF
or
this
idea.
If
the.
B
D
N
So
I
will
also
present
this
elder
drought,
which
is
about
the
nevertheless
controller
restructures.
What
could
be
what
could
be
a
functional
structure
of
the
network
advice,
controller
and
how
the
different
data
models
could
fit
to
these
different
functional
capabilities?
I
will
present
on
behalf
of
my
cloud
assessment.
N
So
next,
please
yeah
the
idea
just
again
as
a
reminder,
so
we
are
defining
the
neighborhoodless
controller
in
the
frequent
document
as
the
central
piece
in
order
to
to
take,
let's
say,
the
expression
of
the
an
average
life
intent
and
translate
it
to
the
realization
of
the
network,
slides
interacting
with
different
controllers,
underneath
so
from
that
idea
we
departed
and
we
they
are
out
for
the
golfers
of
the
different
or
the
initial.
Let's
say:
models.
N
We
we
were
working
together
and
trying
to
figure
out
what
could
be
the
devotional
behavior
that
we
could
expect
in
internal
of
an
averageless
controller
and
from
that
discussion
we
realized,
or
we
consider
that
that
could
be
two
main
functions-
the
what
we
call
never
slice
mapper
and
what
we
call
negortalized
realizer.
N
The
mapper
will
be
essentially
the
the
functional
comment,
the
component
that
process
the
customer
request
coming
from
the
mbig
model,
digest
such
as
request
such
requests
and
put
that
data
size
request
in
the
context
of
all
the
rest
of
slices
that
are
in
in
the
provider
side
right
and
then
we
have
the
the
realizer
that
will
be
the
the
functional
component
that
essentially
a
Associated
technology
related
or
technology
specific
aspects
and
then
interact
with
the
network
controllers.
N
Underneath
for
the
realization
of
the
of
the
slides
in
in
the
figure
that
you
can
see
in
the
central
part
of
the
picture,
we
identify
like
three
kind
of
reference
points,
a
b
and
c,
and
we
try
to.
We
start
to
do
the
mapping
of
the
system
models
in
each
of
these
parts.
So
in
the
in
the
reference
point
a
essentially,
we
consider
that
we
will
have
the
customer
View
for
the
network,
as
a
slice
request
so
essentially
would
correspond
to
the
mbir
model
that
was
presented
by
rasa
a
few
minutes
ago.
N
In
the
reference
point
B,
we
could
have
a
kind
of
Provider
View,
including
much
more
detail
and
and
seeing
how
these
slides
requests
could
be
I
mean
it
could
coexist
with
other
slices
and
also
having
a
more
detailed
view
of
the
netherologist
request,
and
we
could
have
a
technology
and
not
agnostic
resource
view.
It
would
correspond
to
the
the
draft
Liberties
Transportation
or,
alternatively,
some
technology
specific
augmentation,
as
could
be
the
the
the
one,
the
document
for
otn
slicing.
N
They
see
camjan
okayness
license
and
finally,
on
the
reference
point
C,
we
expect
to
have
that
the
models
per
network
controller
and
essentially,
we
would
play
with
the
models
that
we
have
just
commented
in
the
presentation
before
that,
what
has
been
documented
in
in
Dr
guilty's
average
sensation.
So
layer
3
is
a
layer,
three
layer,
2
Series
model
and
enabled
models
essentially
next
slide,
please
so
the
update
having
the
following
investment
zero.
Two,
we
added
reference.
We
referenced
to
additional
models
like
in
the
case
of
ovn.
N
So
somehow
we
try
to
make
consistent
with
what
is
done
and
which
is
describing
in
the
frequent
document
and
for
the
realizer.
We
were
considering
that
the
realization
would
be
the
one
in
charge
of
generating
the
filter,
topologies
disposing
the
Telemetry
information
from
those
filter,
topologies
and
so
again
being
consistent
with
what
is
being
described
in
the
fragile
document.
N
We
also
other
reference
to
additional
models
like
the
ITF
Northwest
instantiation
that
they
presented
before,
and
we
included
some
security
considerations
as
well
and
finally,
for
October
I
mean
for
this
ITF.
We
have
working
in
a
general
alignment
on
with
the
terminology
or
the
framework
document
that
is
evolving
along
the
time.
So
we
essentially
clean
up
the
document
and
policy
in
in
that
respect,
also
refining
a
little
bit
the
text
so
next
place.
Q
And
Charles
Halpern
from
Ericsson
I'm
a
little
concerned
by
something
on
your
previous
slide,
and
this
may
have
been
in
earlier
drafts
and
I
just
didn't
realize
it.
I
have
no
problem
with
the
concept.
Ual
notion
a
person
realizes
perfectly
reasonable,
descriptive
technique,
but
when
you
start
talking
about
standardizing
a
model
for
how
the
those
two
are
related
and
requiring
by
a
standard
that
that's
what's
exposed,
we're
constraining
the
implementation
of
the
network
slice
controller,
we
usually
try
to
avoid
constraining
implementation,
and
these
two
are
two
components
within
the
same
implementation.
Q
N
I
I
understand
your
point.
The
idea
that
we
had
in
mind
was
essentially
told
us
how
to
use
the
different
models.
How
what
could
be
the
relationship
so
I
think
that
is
necessary
to
have
a
kind
of
drama,
how
to
use
them
and
how
they
are
related.
I
understand
your
point
that
maybe
going
farther
than
that
and
trying
to
standardize
in
a
fixed
manner
that
would
be
the
the
only
way
could
be
could
be
hard.
N
It
could
be
probably
should
be
open
to
implementation,
but
somehow,
with
the
different
tools
that
we
have
the
different
artifacts
we
need,
we
feel
the
need
of
having
a
kind
of
guidance.
How
could
they
could
be
related
in
such
a
way
that
we
can
understand?
Let's
say
the
other
relationship
happen?
Then
we.
B
Q
N
I
Smart
tutorial,
the
data
modeling
work
fundamentally
describes
what
can
be
implemented
right.
The
base
model
should
include
what
we
are
planning
to
use.
Yank
allows
augmentation
towards
potentially
going
to
be
used,
that's
not
included
today.
It
cannot
be
anything
to
everybody
right.
We
need
to
limit
this
cop
and,
what's
going
to
be
implemented,
that's
the
goal
really.
N
Okay,
so
as
next
steps
that
we
are
again
to
collect
feedback
and
comments
from
the
working
group
as
the
one
that
we
have
received
to
and-
and
we
would
like
to
once-
we
have
this
this
structure
to
to
use
this
as
a
reference
structure
for
potential
negative
control,
architectures,
maybe
a
first
try
could
be
to
try
to
to
play
with
the
actm,
which
is
in
the
draft
fight.
Yes,
this
applicability
hdns
license
to
see
how
the
map
realizer
could
fit
more
or
less
that
that
architecture.
This
is
an
idea
and
yeah.
N
B
B
And
we'll
give
this
about
30
seconds
and
then
read
out
our
conclusion
from
the
poll.
M
Hi,
this
is
true.
It's
just
that
the
boundary
between
these
two
documents
that
you
presented
is
not
very
clear
to
me,
as
in
I,
do
understand
that
in
one
we
are
focusing
on
mapper
and
realizer
as
an
abstract
concept,
and
maybe
in
the
second
one
you
are
saying:
let's
take
L3,
VPN
and
L3
SMS
service
and
realize
this,
but
I
feel
like
you
know
they
go
sort
of
hand
in
hand.
This
separation
is
very
arbitrary
to
me.
N
Yeah,
so
how
these
second
document
is
I
kind
of
assume
on
the
internet
of
the
network
address
controller
in
the
first
one
necessarily
we
are
talking
about
the
boundaries
of
the
network
is
less
controller,
as
you
said,
probably
yeah
we
divided
in
that
way,
probably
could
be
one
single
document
for
everything.
I'm,
not
sure,
but
one
is
focusing
on
the
functionality
of
the
neighborhood
is
controller,
the
other
one
on
how
to
play
with
the
models
in
the
boundaries
list.
B
So
I
think
we've
gotten
pretty
good
showing
of
the
feeling
of
the
people
in
the
room,
both
physical
and
virtual.
We
have
about
almost
a
third,
basically,
a
third
of
the
people,
responding
and
almost
all
of
them
positive,
so
I
think
there's
definitely
interest
in
the
work.
There's
support
for
it
we'll
talk
about
whether
we
do
an
adoption
call
or
wait
for
the
next
meeting,
I
think
and
we
as
the
chairs.
Thank
you.
Thank
you.
K
Hi,
my
name
is
Paul
and
I
will
be
presenting
this
model
and
also
the
like
the
status
that
this
model,
and
also
an
Archie
policy
model
like
from
other
anaki,
pausing
young.
So
next
next
I
think.
K
So
some
background
here
because
a
while
ago,
Lewis
just
mentioned
about
that
excuse.
B
Me
please.
K
So
when
it
comes
to
because
slice
framework
defined
the
three
basic
connectivity
point
to
point
point
to
multi-point
and
any
to
any
that
mesh
connectivity
when
it
comes
to
the
mapping
to
the
to
the
resources,
then
like
Lewis
just
mentioned,
there
could
be
some
direct
way
that
directly
map
to
the
underlay
network
resources,
like
he
mentioned
in
their
in
his
two
drafts.
That
could
be
like
a
t
pass
or
some
other
some
other
resources.
K
But
here
in
our
an
RPM
model,
we
are
trying
to
focus
on
how
to
map
any
to
any
connectivity
construct
how
that
can
be
mapped
to
the
underlying
network
resources.
Along
with
that,
the
last
framework
defined
that
the
connectivity
should
meet
that
SLO
and
SLE
requirements,
SSE
requirements
Define
that
the
isolation
expectation.
K
So
that's
the
reason
why,
like
two
anaki
can
be
created
to
like
each
anati
has
Can
Has
Its
own
dedicated
resources
per
that
NRP
and
then
each
connect
any
to
any
connectivity
can
map
to
that
particular
NRP.
K
So
why
we
think
this
anaki
yam
model
is
necessary
because
for
NFP,
then
how
that's,
unless
a
network
slides
controller,
understand
that
that
angle,
laser
resources
can
support
any
to
any
connectivity
with,
like
short,
his
past
forwarding,
so
in
because
framework
defined
that
NRP
policy
has
the
basic
topology
and
resources
components
to
support
any
to
any
connectivity.
We
still
need
more
other
components
like
the
control
play
to
understand
whether
this
an
IP
can
support
an
uphillware
routing
here.
K
Oh
then
I
gave
that
some
summary
on
these
updates.
Like
I
just
mentioned,
we
had
some
discussion
with
Anarchy
policy
colleagues
and
we
had
five
weekly
meeting
talking
about
how
to
converge
this,
to
young
models
and
based
on
the
discussion
we
had.
K
Some
updates
on
the
first
is
about
the
control
plane
that
we
make
it
that
clear,
clear
that
this
Anarchy
model
needs
to
support
an
RP
over
routing,
and
we,
we
also
add
a
new
flag
to
mark,
because
a
Nike
model
to
support
this
and
Uphill
very
rotting
that
the
energy
topology
model,
unlucky,
topology,
is
quite
consistent
needs
to
be
consistent
with
this.
The
routing
needs
to
be
consistent
with
the
topology
and
another
update
is
about
that.
How
to
show
the
underlay
topology
with
NRP
resources
dedicated
to
to
that
topology
links.
K
So
that's
the
other
part
that
we
we
are
update.
So
next
slide.
Please
here,
I
want
to
give
the
like
some
some
wording.
Discussion
status
like
we
have
the
the
discussion
with
an
apple
policy
and
we
think
most
of
the
the
NFP
components
we.
K
We
have
more
understanding
about
this
and
we
think
there
are
five
major
components
of
this
NRP
yeah
modeling,
the
first
I
just
mentioned
already
like
defined
in
the
NRP
in
a
slice
framework
and
so
I
think
the
two
NRP
related
Yamato
addressed
each
from
this
perspective,
like
in
our
model,
we
mostly
focus
on
how
to
support
the
RPO
very
team
to
support
any
to
any
connectivity,
the
other
another
Anarchy
policy
model
try
to
like
Define
a
t
pass
aware:
an
RP
policy
model.
K
So
that's
a
major
difference.
I
gave
the
like
four
points
that
we
are
working
on,
that
we
try
to
like
accommodates
in
the
two
different
options
here
and
the
the
black
points
that
we
show
that
we
we
both
agree
that
the
resource
reservation
is
something
we
need.
They
all
need
it,
but
the
other
four
we
we
are
talking
about
it.
How
to
convert
these
two
and
I
think
the
currently
we're
doing
the
the
first
step,
how
to
dealing
with
the
another
thing
instant
Asian.
K
But
we
also
think
there
are
monitoring
and
also
an
epic
device
model
is
a
is
also
necessary,
but
we'll
get
to
that
after
we
we
I
Converge
on
that
unlucky
institution
one
so-
and
this
is
my
summary
from
my
my
understanding
from
the
five
weekly
discussion.
K
G
I'm
one
of
the
quotas
on
the
NRP
policy
document,
like
Paul,
said
we
have
been
having
regular
sync
UPS
on
trying
to
merge
the
two
documents
I
mean
I
would
like
to
think
that
you
have
made
a
great
deal
of
progress
in
at
least
at
least
putting
together
a
common
set
of
components
that
make
up
what
we
call
NRP
policy
there
is
there
is,
there
are
still
there's
still
some
work
to
be
done,
I
think
they're,
very
close,
but
not
there.
G
Yet
I
would
suggest
having
a
series
of
open
bi-weekly
meetings
over
the
next
few
weeks
and
try
and
close
them
close
on
them
and
have
something
ready
for
adoption
before
the
next
meeting.
Thanks
for
the
update.
B
That's
great
to
see
the
progress
you
know,
as
we
asked
in
the
previous
document,
bringing
together
the
different
perspectives
into
a
consolidate
document.
Just
helps
us
all
progress
the
work.
So
thank
you
very
much
really
appreciate
the
I
know
it
can
be
challenging
to
bring
together
the
different
perspectives,
but
that's
what
we
need
to
do
here.
B
So
thank
you
very
much,
really
appreciate
it
and
with
that
we're
actually
going
to
end
what
is
that
a
minute
40
seconds
early
and
we're
going
to
rejoin
here
in
half
an
hour
or
31
minutes,
and
thank
you
all
for
a
great
session
look
forward
to
the
next
one.