►
From YouTube: IETF109-TEAS-20201116-0900
Description
TEAS meeting session at IETF109
2020/11/16 0900
https://datatracker.ietf.org/meeting/109/proceedings/
A
Hello,
welcome
to
the
tease
workbook
on
our
virtual
or
online
ietf
109..
We
have
I'm
blue
burger,
pavon
burum's
online.
I
think
we
have
matt,
I'm
not
sure
if
matt
is
here
but
he's
always
very
helpful
and
as
our
working
group
secretary
as
usual,
the
material
is
online.
You
can
also,
if
you
click
on
the
chat
button,
you
should
be
able
to
see
the
links
to
that.
A
Excuse
me
and
you'll
also
see
the
link
to
code
emd,
which
is
our
collaborative
minute.
Taking
please
do
go
join
us
there
there's
only
a
few
people
there
right
now.
Please
join
us
there
and,
if
you
hear
comments
said
during
the
session,
please
help
by
capturing
those,
particularly
if
you
also
say
comments.
A
This
is
a
formal
ietf
meeting,
which
our
note
means.
Our
notewell
applies
and
everything
we
say
and
do
here
is
governed
by
our
process
and
become
part
of
our
permanent
record.
Obviously
we're
using
meat
echo
for
this
meeting.
If
you're
joining
us
today
live
you
know,
that's
how
you
joined.
We
also
are
reporting
and,
as
usual
minutes,
audio
and
video
will
be
published,
and
so
again
everything
you
say
here
is
part
of
that
record.
A
As
always
seems
to
happen,
we
end
up
with
a
very
packed
agenda,
no
matter
how
much
time
we
request,
we
always
seem
to
fill
it,
which
is
great,
that's
nice,
to
have
an
active
working
group.
This,
the
only
thing
that's
changed
since
originally
published,
as
we
reordered
things
a
little
bit.
So
if
you
happen
to
look
at
the
the
first
version
of
the
agenda,
you
may
find
yourself
moved
around
in
time
and
in
order
we
there
was
a
minor
tweaking
on
time
just
to
fit
all
the
requests.
A
We
will
continue
to
be
working
this
way
for
a
while,
as
everyone
has
seen,
itf
109
is
sorry.
This
is
updated.
A
bunch
of
different
slides
ietf110
is
going
to
be
online,
so
our
next
one
is
online.
We're
online.
Now
we'll
continue
working
this
way
for
a
while.
A
A
For
interims,
you
can
also
request
an
interim,
although
we
we
will
initiate
those
as
we
think
necessary,
as
you
saw
sometimes
we
initiate
and
they
they
don't
quite
work
out,
as
happened
with
our
last
interim,
but
we
we
want
to
use
these
online
meetings
between
idf's
to
keep
our
process
going
so
that,
even
though
we're
not
meeting
in
person,
we
keep
the
momentum
going.
A
Our
formal
ipr
process,
which
we
do
polls
both
that
accept
working
group
acceptance
and
as
part
of
our
last
call,
hasn't
changed,
and
but
I
think-
and
I
think
everyone
is
familiar
with
it,
but
it's
always
good
to
show
this
to
remind
newcomers
we're
going
to
work
through
walk
through
the
active
drafts
in
a
moment.
Pavon
will
do
that
in
terms
of
where
we
are
from
the
publication
process.
We
have
one
new
rfc.
A
This
is
actually
quite
the
bit
of
work
that
was
done
to
get
us
here
and
it's
a
it's
a
a
significant
foundational
document
in
in
our
yang
work,
and
this
is
about
this-
allows
us
to
represent
te
topologies
in
yang.
It's.
It
took
quite
a
while
to
get
there
and
we
really
appreciate
all
who
contributed
to
it
and
their
hard
work.
A
We
have.
We
have
one
document
that
is
with
the
iesg.
There
was
actually
fun.
I
I
think
you
were
gonna
talk
about
this
on
the
in
the
next
slide
deck,
so
I'll
leave
it
for
there
and
we
also
have
had
one
new
adoption.
Since
the
last
meeting
we
haven't
received
any
liaisons,
we
have
jointly
sent
one
liaison
and
it
shows
what
our
recent
drafts
and
rfcs
as
well
as
working
group
changes
it's
available.
A
B
B
So
we
currently
have
21
working
group
documents,
they're
all
listed
here-
five
of
those,
the
ones
that
are
marked
in
blue
or
on
the
agenda.
Today
there
is
one
draft
the
pc
native
ip
draft
that
lou
was
referring
to
earlier,
is
currently
under
isg
processing.
It's
actually
currently,
with
our
ad
there
was
a
new
revision
published
for
this
over
the
weekend
addressing
deborah's
comments.
B
There
will
be
further
guidance
on
the
proposed
status
of
this
document
that
would
be
provided
in
a
few
days
time,
so
the
guidance
would
be
to
change
the
proposed
status
to
a
informational,
so
keep
an
eye
out
for
that
email.
So
that
leaves
us
with
15
other
documents.
The
status
of
each
of
them
is
covered
in
this
deck.
The
modeling
drafts
for
t,
let's,
let's
stay
on
the
let's
see
on
the
yeah,
the
modeling
drafts
for
t
and
rsvp
and
l3
and
sr
topology
augments-
are
all
nearing
completion.
B
They've
all
had
a
young
doctor
review
done.
We
also
have
tom
petch
diligently
reviewing
each
of
these.
Thanks
to
him,
the
authors
have
been
making
sure
that
each
of
his
comments
do
get
addressed.
There's
also,
this
new
expectation,
rather
recommendation
from
the
young
doctors
to
add
a
json
instance
of
the
young
model
in
the
appendix
of
the
draft
in
which
the
model
is
proposed.
So
the
plan
for
most
of
these
documents
is
to
address
the
last
set
of
comments
from
tom.
B
Add
the
json
instance
to
the
appendix
and
then
request
working
with
last
call.
So
in
the
meantime,
it
would
be
great
if
you
could
get
some
more
reviews
and
feedback
and
on
the
usability
of
these
modules,
there
are
a
couple
of
young
documents
that
are
listed
here
as
ready
for
young
doctor
review.
Those
are
the
act
and
vn
yang
and
the
path
computation
young
documents.
B
We
initiated
the
review
process
for
both
of
these
documents
over
the
weekend.
We
also
have
three
documents
marked
in
red
here,
which
are
currently
in
expired
state.
The
authors
have
promised
to
revive
those
this
week
so
before
we
move
on
to
the
next
slide
deck.
There
are
a
couple
of
topics
that
I
would
like
to
double
click
on.
So
let's
jump
to
slide
six.
B
Yeah,
so
this
is
the
smp
raft.
There
are
a
couple
of
open
items
for
which
the
others
are
seeking
some
inputs.
They
did
start
a
couple
of
threads
for
this
on
the
list.
Adrian
did
chime
in
on
one
of
them.
I
would
encourage
others
to
participate
in
those
threats
and
help
the
others
close
them.
B
This
is
the
document
that
discusses
pce
cc,
use
cases
a
few
meetings
back.
There
was
some
debate
on
whether
they
should
just
remain
as
a
living
document
and
not
go
through
the
publication
process.
We
decided
then,
to
revisit
the
status
of
this
document
at
a
later
point
in
time.
We
believe
it
is
that
time
now
the
authors
have
just
requested
to
change
the
state
of
this
document
to
adopt
it
for
working
group
info
only.
B
We
would
like
to
get
some
opinions
in
on
this
before
we
make
the
change.
We
understand,
there's
been
a
fair
bit
of
work
put
in
to
get
this
document
to
the
stage
and
don't
really
want
to
discourage
folks
from
making
similar
contributions
going
forward.
So
if
the
authors
or
anybody
who
wants
to
chime
in
with
their
thoughts
yeah,
it
would
be
great.
C
So
I
think,
based
on
the
past
comments,
we
we
thought
that,
because
the
isg
itself
was
not
preferring
too
many
use
cases
documents.
Basically,
when
the
extension
work
was
almost
ready
and
these
documents
have
done
their
job
of,
like
you
know,
convincing
the
working
group
and
the
itf
that
this
work
is
needed.
C
So
that
was
the
understanding
we
were
in,
but
we
would
respect
whatever
opinion
that
the
chairs
and
the
ads
suggest-
and
if
there
is
a
push
to
publish,
we
would
of
course
be
more
happy
to
publish
it
because
we
have
done
the
work.
But
we
are
following
the
guidance
that
has
given
to
us.
So
we
are
completely
open
to
what
you
throw
our
way.
B
Okay,
fair
enough,
anybody
else
would
like
to
chime
in
so
lou,
and
I
would
discuss
this
with
ada
and
make
a
call
on
it.
We
will
share
the
outcome
of
that
discussion
on
the
list.
B
I
will
stop
here
with
respect
to
this
tech
I'll,
let
you
go
through
the
rest
of
the
slides
and
also
the
reports
that
are
sent
to
the
list
in
leisure.
Please
do
send
out
an
email
on
the
list
if
you
find
anything
missing,
so
any
quick
questions
on
the
status
of
any
working
route.
Any
working
group
document
before
we
invite
drew
to
present
the
star
the
next
presentation.
C
C
So
we
have
nine
yang
models
here
we
have
a
vn
yang
model,
augmenting
of
te
and
vn
for
kpi
telemetry
and
a
bunch
of
service
mapping
model
where
a
generic
types
model
and
then
augmentation
of
various
service
models
and
network
model.
So
let's
go
over
an
update
of
each
of
them
next
slide.
C
And
maybe
one
more
you
can
yes,
so
this
is
a
introduction
to
what
vn
yang
is.
This
is
the
young
model
for
vn
operations?
It
is
from
the
customer
point
of
view
we
use
heavily
the
abstract,
topology
and,
and
the
connectivity
matrix
to
to
represent
the
vn
model,
and
it
is,
it
is
a
higher
abstraction.
It
is
from
the
customer's
point
of
view,
and
this
has
been
sort
of
like
getting
ready
for
a
while.
C
So,
if
you
guys
remember,
in
the
last
meeting,
we
presented
an
and
suggestion
from
kenichi
ogaki
from
kddi,
where
he
would
want
wanted
to
make
a
change
to
the
vm
compute.
We
discussed
that
during
the
last
meeting
and
that
change
has
been
incorporated
in
the
draft,
so
the
basically
the
change
allows
the
vn
compute
rpc
to
be
a
single
rpc
that
can
be
used
to
make
a
single
call
to
get
the
result
or
the
vn
result
in
one
call,
as
I
mentioned
earlier,
since
we
were
dependent
on
t
topology
earlier.
C
This
was
a
two
call
so
that
they
wanted
to
simplify
and
the
way
to
simplify
was
pretty
straightforward.
We
optionally
included
two
groupings
in
the
vm
compute.
These
are
the
te
types
grouping
for
generic
path,
constraints
and
t
types
grouping
for
generic
path.
Optimization
by
reusing
these
two
groupings
in
vn
compute.
We
are
able
to
now
get
the
results
and
pass
all
the
information
needed
for
vn
computation
in
one
rpc
call.
This
has
been
done
at
the
vl
level,
as
well
as
at
the
vn
member
level.
C
So
this
is
the
main
change
that
we
have
done,
but
continuing.
There
were
some
more
comments.
That's
in
the
next
slide,
so
those
are
our
current
pending
work,
so
the
pending
work
is.
There
was
a
request
from
kenichi
that
if
we
can
describe
this
in
a
buy
a
figure,
so
that
has
been
us,
so
we
have
a
figure
pending
that
we
will
add
for
vm
compute.
There
are
some
editorial
comments
that
are
still
pending
from
tom
petch.
C
I
kind
of
missed
them
when
I
was
updating,
I
I
realized
it
later
so
when
I
was
making
these
slides.
So
I
will
update
on
that
and,
as
I
said
earlier,
that
I
think
we
are
ready
for
yang
doctor
review.
So
this
finishes
the
vn
compute.
If
you
have
any
questions,
I
think
you
can
jump
to
the
queue
I
can
answer
right
now
or
at
the
end
of
all
the
three
presentations
either
way
it's
good
with
me,
but
I'll
continue
to
save
some
time.
So
the
next
update
is
the
kpi
telemetry
yank.
C
We
have
two
yang
models
here,
which
augments
the
t
model
and
the
vn
model.
It
adds
the
various
pm
telemetry
characteristics,
as
well
as
the
scaling
intent
mechanism
into
these
two
model.
This
allows
the
customer
to
subscribe
to
whether
at
the
vl
level
or
at
the
t
tunnel
level,
various
pm
characteristics
as
well
as
we
have
a
concept
called
automatic,
autonomic
scaling
intent,
which
has
been
been
there
from
the
start.
So
the
update
in
this
document
next
slide
is
it's
pretty
basic.
C
We
had
a
change
added,
some
editorial
cleanup
of
the
yang
model.
There
were
some
references
that
were
incorrect,
so
that
got
fixed.
We
had
a
comment
that
we
should
describe
how
the
vl
level
performance
metric
is
calculated.
So
we
have
added
that
detail
in
the
description
of
how,
at
the
vl
level,
these
metrics
are
computed,
which
is
usually
the
max
of
the
vn
members.
C
So
that's
the
minimal
change
in
this
document,
the
next,
what
we
have
next
slide.
So
next
we
have
the
te
service
mapping
gang.
As
I
said
this,
there
are
a
bunch
of
augmentation
in
this
model.
C
I
will
just
quickly
describe
what
this
model
is
in
the
next
slide,
so
the
role
of
this
tea
service
mapping
model
is
to
create
a
mapping
relationship
between
various
service
models
that
we
have
in
itf,
l3,
sm,
l2,
sm
layer,
1
csm,
as
well
as
we
also
allow
the
same
grouping
to
be
used
for
the
network
models
as
well,
and
we
map
these
service
and
network
model
to
our
these
yang
models
at
various
levels
at
the
topology
level
at
the
tunnel
level
or
at
the
vn
level.
C
So
the
main
reason
why
we
do
this
so
that
we
could
have
a
very
seamless
service
operation
that
when
the
customer
is
thinking
in
terms
of
l3
sm
and
underlying
there
are
te
tunnels
involved.
We
have
a
a
mapping
between
how
those
services
are
being
delivered
using
the
un
underlay
te
resources.
This
allows
us
to
do
various
monitoring,
diagnostic
and
various
other
things
to
maintain
this
mapping
next
slide.
C
So
what
what
has
been
updated?
As
you
know,
l3
and
m
and
l2
nm
were
added
in
the
last
update,
which
we
discussed
in
the
working
group,
we
added
a
thing
called
tea.
C
Mapping
template
there
was
a
support
for
sr
policy
that
was
added,
so
these
were
all
the
changes
that
we
made
last
time
and
they
were
a
comment
on
the
mailing
list
again
from
kenichi,
and
we
are
very
thankful
for
or
to
him
to
come
to
come
up
with
new
use
cases
as
he's
implementing
this
model,
so
one
requirement
that
they
had
was
they
wanted
to
map
one
l3
sm
to
actually
multiple
vm
models,
and
they
said
that
they
have
a
use
case
that
that
is
use
that
is
needed
for
this
and
we
discussed
on
the
list.
C
It
doesn't
harm
us
to
have
a
mapping.
I
think
the
most
usual
case
would
be
one
is
to
one
case,
but
if
an
operator
wants
to
further
break
it
down
into
multiple
vms
and
maintain
them
separately,
for
some
reason
it
doesn't
harm
from
the
yang
modeling
point
of
view.
So
that's
why
this
change
has
been
made,
and
this
was
discussed
on
the
list
in
the
past
as
well.
Apart
from
that,
the
changes
were
there
were
some
errors
in
our
ex
parts
that
were
pointed
out
to
us,
which
we
have
fixed
after
posting.
C
This
update
there
was
some
more
discussion
which
is
on
the
next
slide,
where
kenichi
asked
us
to
also
handle
kios
profile,
which
I
will
describe
so
the
what
you
see
are
the
two
further
augments
that
we
discussed
on
the
mailing
list,
that
that
needs
to
be
added,
which
is
at
the
l3
vpn
site
level.
They
have
a
keyos
profile
and
they
allow
you
to
create
a
custom,
qos
profile
and
give
constraints,
etc
right
there
at
the
site
level.
C
So
there
they
wanted
to
maintain
a
mapping
between
these
custom
qos
profile
and
the
vnap
that
is
created
by
our
to
to
service
this.
This
custom
qos
profile,
so
that
one
is
to
one
mapping.
We
are
maintaining
maintaining
it
here,
so
we
wanted
to
get
more
feedback
from
people,
especially
who
have
implemented
l3sm
and
have
feedback
on
this.
Whether
this
augment
makes
sense
and
if.
C
Needs
to
change
we
will.
We
will
make
that
change
in
the
next
slide,
and
that
covers
all
the
changes
that
we
have
made
in
the
last.
These
three
yang
models
any
comments.
B
B
D
Now,
can
you
hear
me
now,
okay,
that
one
so
my
question
is
in
in
the
latest.
I
changed
that
you
that
was
proposed.
It
was
announced
on
l3sm
to
map
the
qs.
So
would
that
also
apply
12
12
3
nm.
C
Yeah,
I
think
that's
a
very
good
question.
I
I
feel,
like
you
know,
that
custom
keyos
class,
if
it
is
existing
in
the
l3
nm,
then
of
course
it
would.
I
have
to
check
whether
that's
the
case
or
not,
and
I
think
you
can
answer
it
right
away.
You
would
know
whether
you
have
something
like
custom
qs
profile
in
l3
and
m
as
well.
D
C
A
E
Hi
chairs,
I
was
actually
going
to
present
my
screen
remotely
if
possible.
I've
just
requested.
E
Yeah,
yes,
okay,
let's
see
if
this
works
I'll,
be
a
guinea
pig.
I
actually
appreciate
that
better
for.
A
E
E
Okay,
hi
guys
it's
it's
morning
here
in
the
uk,
I'll
be
talking
about
the
applicability
of
ac
tn
to
poi
packet
optical
integration.
E
There
is
two
documents,
actually
that
attempted
to
show
the
applicability
of
actn
to
poi,
and
actually
the
document
that
you
see
currently
is
the
merger
of
these
efforts.
That's
why
we,
we
do
have
quite
an
exhaustive
list
of
sort
of
authors
and
contributors.
You
know
good
percentage
actually
of
the
tease
working
group.
E
So
what
is
the
intention
of
the
work?
It's
really
to
show
almost
a
cookbook
of
how
you
would
take
the
functional
architecture
of
actn,
the
various
functional
components,
the
specific
interfaces
and
what
procedures
and
protocols
specifically
data
models
you
would
use
in
order
to
set
up
and
operate
packet
over
optical
services.
E
So
this
is
really
important.
I
think
work
because
it
it
highlights
all
of
the
the
discussions
that
we're
having
with
sort
of
the
separate
protocols
and
data
models
and
how
we
will
use
those
in
order
to
sort
of
deploy
these
services
and
from
an
operator
perspective
as
well
as
a
vendor
perspective.
It's
important
to
know
if
these
procedures
and
models
are
actually
suitable
and
and
fit
for
purpose.
E
We
spend
all
this
time
actually
developing
yang
models,
but
you
know
how
efficient
are
they
and
you
know
what
are
the
gaps
tends
to
be
sort
of
after
we've
deployed
them
in
the
field
if
there
isn't
sufficient
interrupt
or
implementation
early
on
in
the
development
of
the
document
itself,
and
so
we
we
know
actually
that
the
focus
of
the
work
is
going
to
be
on
the
southbound
interfaces.
E
So
it's
predominantly
between
the
multi-domain
service
coordinator
and
the
underlying
controllers,
or
managers,
you
say
the
the
physical,
the
packet,
physical
and
the
optical
physical
network
controller,
and
ideally,
when
we
finish
the
work,
we
will
have
a
fairly
good
understanding
of
what
are
the
available
models.
Some
are
optional,
you
know
how
are
they
used?
Were
there
specific
implementation
or
technology
gaps?
Are
there
operational
management
security
issues
that
that
were
not
identified
during
the
development
of
of
some
of
these
procedures
and
protocols?
E
So
how
about
a
reference
architecture?
Well,
it's
fairly
formulaic.
Essentially
it's
sort
of
four
domains.
So
we
have
a
hierarchy
of
our
packet
layer
that
sits
on
top
of
the
optical
layer
and
then
sort
of
sort
of
horizontally.
E
We've
got
domain
one
and
domain
two,
and
these
these
interfaces
in
black
are
between
the
mdse
and
then
the
packet
and
the
optical
pncs
respectively,
and
then
we've
got
a
further
set
of
interfaces
between
the
pnc
and
the
optical
pnc
to
the
actual
layer,
the
technology
domain,
where
the
the
actual
sort
of
nodes
sit
and
you
already
there
are
a
number
of
generic
and
technology-specific
models
that
we
can
use
and
we're
seeing
a
number
of
kind
of,
not
necessarily
issues
but
some
sort
of
clarifications
that
that
may
be
needed
there
and
I'll
cover
that
a
little
bit
later.
E
What
isn't
in
scope,
of
course,
is
above
the
mdse,
but
it
it
turns
out
actually
that
some
of
the
operators
who
are
involved
in
the
work
are
very
interested
in
sort
of
having
that
discussion.
But
for
the
time
being,
it's
it's
kind
of
out
of
scope.
E
So
if
you
were
to
read
the
document
in
its
current
form,
we've
we've
managed
to
do
sort
of
the
first
pass
of
merging
the
sort
of
prior
prior
two
documents
that
I
highlighted
earlier.
So
we
currently
have
two
phases
that
we're
working
on
phases
or
scenarios.
I
suppose
you
might
call
these,
but
it's
it's
how
we
generate
the
the
view
of
the
network,
so
our
sort
of
physical
network
topology
discovery
and
then
existing
service
topology
discovery.
E
How
that
information
is
carried
between
the
various
pncs
to
the
mdsc.
There
are
some
sort
of
procedures,
some
aspects,
sort
of
operationally
that
that
are
kind
of
interesting
to
consider,
and-
and
this
includes
things
like
the
link,
discoveries
and
the
attachments
discovery.
So
some
operators
might
see
this
discovery
mechanism
as
being
a
a
sort
of
security
risk.
E
You
know
other
operators
may
see
it
as
something
that
would
be
nice
to
have
so
whether
it's
static,
whether
there's
some
sort
of
automated
process
that
that's
kind
of
some
of
the
discussion
that
we're
having
in
the
document
currently.
So
I
mentioned
already
that
we've
identified
the
common
young
models.
You
know
so
the
tea
service
and
the
topology
young
models,
and
then
we've
got
our
sort
of
technology,
specific
extensions
or
augmentations
that
we're
using
as
well
and-
and
this
is
essentially
the
the
ingredients
that
we're
using
as
part
of
our
our
cookbook.
E
There
are,
of
course,
some
service
models
that
that
we
are
considering
as
well
for
some
of
the
the
packet
aspects.
Sorry
not
serve
service
model
network
model,
so
our
l2
nm
and
our
l3
and
m
models
there
and
another
aspect
to
consider
here-
is
the
the
the
ongoing
discussion
whether
to
use
the
the
the
uni
topo
versus
client
topo.
So
essentially
your
what
augments,
rfc
8345
with
the
service,
attach
attachment
point
abstraction
discussion.
E
We
know
that
that
what
we're
sort
of
highlighting
in
our
document
is
occurring
as
a
parallel
discussion
in
things
like
the
ops
area
and
actually
sort
of
in
in
other
documents
here
in
teas
and
also
ccamp.
So
there
are
some
discussion
points
around
around
the
implementation
of
of
htm
and
poi
that
that
are
still
ongoing.
So
clearly
the
work
that
we're
doing
is
just
kind
of
feeding
into
some
of
that
parallel
discussion.
E
E
E
E
We
can
actually
prune
you
know
or
distill
some
of
this
discussion
text
to
make
it
sort
of
a
little
less
bloaty
in
the
document,
but
at
least
for
the
time
being,
we've
just
kind
of
captured
all
of
the
discussion
and
probably
sort
of
spent
too
much
effort
working
on
our
assumptions
and
documenting
those
assumptions
so
maybe
going
forward.
E
We
will
definitely
try
to
prune
that
text
down,
but
some
of
the
meat
of
the
document
here
are
is
contained
within
section
four,
because
this
is,
you
know
how
we
actually
solve
some
of
these
scenarios.
So,
as
I
mentioned
already,
you
know
how
we
populate
the
topology
and
current
connectivity
and
then
how
we
establish
our
sort
of
optical
and
then
packet
services
on
top
of
that.
E
So
what
are
we
currently
working
on?
Well,
there
are
at
numerous
open
issues.
These
are
sort
of
tracked
here.
Sort
of
the
the
current
trend
seems
to
be
to
use
github,
and
we
will
be
mindful,
of
course,
not
to
do
all
of
our
work
by
github
what
we
will
sort
of
attempt
to
continue-
and
I
hope
we've
achieved
this
so
far-
is
to
address
some
of
the
sort
of
the
issues.
E
The
open
discussion
points,
for
instance,
there
may
be,
you
know
how
we
discover
and
populate
inventory
in
the
mdsc
from
the
pncs.
What
are
the
service
attachment
points
that
we're
using
versus
some
of
the
discussion
around
uni
and
client
and
what's
actually
being
exposed
you
these?
These
are
discussions
that
can
occur
ideally
on
the
t's
working
list
mailing
list,
but
we
will
also
be
sort
of
discussing
these
during
our
almost
weekly
call
that
we
actually
have
for
this
particular
piece
of
work
and
then
reporting
some
of
the
findings.
E
Some
of
the
conclusions
that
we
reach
on
these
separate
calls
on
the
mailing
list
itself,
some
of
them
the
other
sort
of
hot
topics
at
the
moment,
are
around
isolation.
We
know
that
sort
of
you
know,
network,
slicing
and
and
isolation,
so
sort
of
providing
circuits
providing
a
bandwidth
to
your
particular
customers
or
particular
topologies
that
are
then
represented
in
the
mds
kind
of
a
a
hot
topic,
and
whether
that's
soft
or
hard
isolation
continues
to
be
an
ongoing
discussion.
E
What
what
we
haven't
addressed
in
the
document
that
that
will
be
in
the
next
version
are
some
of
the
some
of
the
additional
operational
issues
and
drew
just
kind
of
highlighted
that,
with
some
of
the
telemetry
discussion
on
the
previous
talk,
so
not
only,
of
course,
are
we
providing
network
connectivity
for
sort
of
packing
over
optical
services,
but
we
almost
certainly
will
want
to
monitor
that
connectivity
and
in
the
event
of
some
kind
of
degrade
in
service,
and
certainly
lots
of
connectivity,
it
needs
to
be
reported
adequately
and
appropriate
action
needs
to
be
changed
or
appropriate
action
needs
to
be
taken
and
potential
network
changes
will
incur.
E
What
what
isn't
as
sort
of
discussed
in
the
document
currently
is.
Is
things
like
sort
of
pre-computed
path,
protection
for
either
type
of
service?
That
seems
to
be
just
a
a
step
too
far.
At
this
point.
E
B
Okay,
we
have
joel
in
the
queue
joel
go
ahead.
G
G
Just
wait
for
that
slide
to
show
up,
so
this
is
rsc
320
bis.
So
3272
is
the
overview
and
discussion
document
for
traffic
engineering
in
the
internet
and
way
back.
We
decided
that
it
would
be
helpful
to
update
this
old
document,
so
we
did
a
couple
of
revisions
and
then
it
got
adopted
in
july
and
it
has
been
silent
since
then,
and
in
my
opinion,
silence
is
not
particularly
helpful.
It
is
not
indicative
of
work
in
progress.
It's
really
indicative
of
nobody
having
the
energy.
G
So
since
I
had
volunteered
in
inverted
commerce
to
be
the
editor
of
the
work,
I
updated
in
early
july
just
to
capture
a
couple
of
points
that
were
raised
during
the
adoption
poll,
in
particular
whether
the
components
of
traffic
engineering
all
needed
to
be
present
for
a
system
to
be
truly
traffic
engineering,
and
this
is
phrased
in
terms
now
of
te
versus
partial
t
e.
G
Since
then,
I've
embarked
on
editorial
polish
so
going
through
the
the
text,
which
was,
I
think,
somewhat
in
daniel
leduc's
tone
of
voice
and
been
polishing
it
a
little
bit.
The
o2
came
out
start
of
the
month
where
I'd
reached
2.4.1
I've
just
posted
03
today,
where
I
have
reached
section
5.3,
which
is
almost
exactly
halfway
through
the
document.
G
So
I'll,
keep
working
on
that
and
from
here
on.
The
choice
of
how
we
proceed
is
either
we
get
some
input
from
the
working
group,
anyone
or
everyone,
and
that's
edits
or
text
suggestions
or
comments
or
complaints.
G
G
Depending
on
how
short
of
time
I
am
and
then
asking
the
chairs
to
get
on
and
last
call
it
in
the
new
year
as
early
as
possible,
because
one
way
or
the
other,
it's,
I
think
it's
clear
that
the
working
group
will
have
finished
whatever
it
thinks
needs
doing,
and
we
need
to
get
that
review
and
and
be
finished.
A
So
I
see
someone
typing
in
comey
md
a
comment.
It
would
be
good
if
they
made
the
comment.
I
C
Working
group,
I
think,
when
we
started
out
this
work,
our
main
intention
was
that
we
can
point
to
this
document
when
somebody
outside
the
working
group
may
be
brte
comes
to
mind
and
sr
policy
and
srte
discussion
that
we
had
so
should
we
also
evangelize
this
work
and
say
like
look.
We
have
now
a
good
reference
being
ready
and
see
if
outside
the
working
group,
people
can
start
using
it,
and
that
could
also
give
us
some
inputs
whether
we
have
succeeded
in
our
mission
in
clarifying
what
is
te
in
2020.
G
I
think
I'm
picking
that
from
the
bottom.
Yes,
if,
if
if
people
are
able
to
use
it,
it
will
give
us
a
good
idea
that
we've
done
a
good
job
but
before
pushing
it
out
for
other
people
with
us
saying
this
is
the
reference
I
would
like
to
hear
more
than
just
me
saying
this:
is
this
document
captures
our
opinion
and
I'm
not
hearing
that
at
the
moment.
G
That
would
be
perfect,
so
please
have
a
have.
A
look
at
the
document,
grab
a
section
and
write
some
text,
I'm
only
looking
for
each
of
these
sections,
I'm
only
looking
for
sort
of
three
paragraphs.
Otherwise
the
document
becomes
unbalanced,
so
it
shouldn't
be
big
work.
J
G
B
Okay,
thanks
adrian
thanks
for
driving
this
forward,
there
is
still
a
fair
bit
of
work
to
be
done,
so
if
anyone
is
interested
in
contributing,
please
do
reach
out
to
adrian
and
see
how
you
can
help.
B
We
are
now
moving
to
that
segment
of
the
session,
for
which
most
of
you
have
been
waiting
for
and
are
up,
but
not
are
75
minutes
of
network
slicing
topics
coming
up.
So
after
the
last
ietf,
we
did
an
adoption
poll
for
a
couple
of
documents
that
were
produced
by
the
design
team.
The
calls
failed,
but
it
did
generate
a
lot
of
great
discussion.
B
It
sort
of
resulted
in
a
bit
of
a
research
resetting
with
respect
to
the
terminology.
The
authors
have
been
focusing
on
addressing
the
comments
that
were
raised
during
the
adoption
poll
and
we
will
hear
from
them
about
it
in
a
little
bit.
The
discussion
on
the
list
seems
to
suggest
that
we
are
converging
on
some
controversial
items
so,
like
everyone
else,
I'm
also
eager
to
see
how
this
session
progresses.
So
before
we
bring
yari
in
to
give
a
brief
update
on
the
design
team.
Do
you
have
anything
else?
B
A
B
K
Yeah,
so
if
you
can
just
move
to
the
next
slide,
so
my
intent
was
not
to
speak
at
length,
just
sort
of
give
a
very
high
level
status
report
and
you
know
way
forward,
and
you
know
where
are
we
and
where?
Where
are
we
not
so?
As
vishnu
mentioned,
we
attempted
to
do
a
working
adoption
in
august
or
in
the
summer,
which
didn't
succeed,
but
I
think
there's
reason
to
think
that
we
can
succeed
and
we
are
close.
K
The
issues
during
the
summer
were
primarily
around
terminology
names
in
particular
and
isolation,
a
few
other
topics
and
since
then
a
lot
of
work
has
happened.
A
lot
of
discussion
has
happened.
K
Revisions
have
been
made,
I
believe,
on
the
name
issue
of
or
calling
these
terms.
A
particular
thing
is
that
that's
a
solved
issue,
but
one
would
observe
that
once
you
move
past
some
issue
like
this,
like
you
don't
like
the
name
of
a
thing,
it's
only
then
that
some
people
actually
get
to
think
more
about
the
actual
content
or
substance
of
things.
So
I
think
some
of
the
discussions
that
we've
seen
recently
is
in
that
category
that
okay
now
we
sort
of
put
that
thing
past
us.
K
K
I
think
my
advice,
at
least
for
this,
is
that
we
should
find
what
we
have.
What
is
the
commonly
acceptable,
minimal
set
of
things
and
move
on?
The
reason
for
that
is
really
that
I
mean
there's
a
lot
of
things
that
we
could
do.
Let's,
let's
agree
on
the
on
the
simple
things
and
the
the
concepts
discussed
here
are
actually
important
for
other
work
and
maybe
not
in
terms
of
like
actual
reference
to
you
know,
document
dependency
as
such,
but
there's
a
lot
of
work.
K
That
sort
of
you
know
enters
the
space
one
way
or
the
other,
and
if
we
actually
had
some
agreement
about
the
terms.
K
What
are
we
even
talking
about,
and
I
think
that
would
be
beneficial
to
keep
the
keep
the
thing
together
and
so,
for
instance,
anything
that's
discussed
in
in
in
this
section
of
the
agenda
like
it's
highly
dependent
on
this
so
and
the
final
comment
is
that
you
know
the
we
had
a
design
team,
the
design
team
produced
some
results
that
were
discussed
by
the
working
group
and
we've
intentionally
wanted
to
move
the
discussion
to
the
working
group
like
it's,
not
that
the
design
team
has
much
that
much
discussions.
K
It's
mostly
practical.
If,
if
anything,
so
everything
is
really
in
the
hands
of
the
working
group,
and
so
you
know
we,
we
design
team
have
no
particular
status,
the
authors
can
propose
stuff
and
they
they
have
and
they
revise
documents.
Thank
you
for
that,
but
I
think
the
agreement
needs
to
be
found
in
the
working
group
amongst
all
of
us.
So
so
I
think
that's
the
setup
for
kiran
and
others
to
start
talking
about
the
actual
details
and
substance.
M
M
N
Next
slide,
please
so
an
overview
of
the
changes
so
things
you
look
at
the
left
column.
They
have
been
pretty
stable.
Even
if
we
have
gone
through
different
discussions
in
between
two
itfs
108
and
109
and
interim
meeting,
our
core
definition
hasn't
changed
the
way
we
describe
the
characteristics
of
structure
and
stakeholders
different
sections,
they
haven't
changed
a
whole
lot
in
terms
of
the
content.
N
We
also
got
a
feedback
that
security
consideration
should
not
be
left
empty,
so
some
text
was
provided
there
and
we
also
got
some
feedback
to
remove
a
lot
of
descriptive
text
from
the
document
and
probably
make
it
a
candidate
for
framework
draft
later
on
next
slide.
N
N
So
in
interim
meeting
it
was
mentioned
that
transport
slice
is,
as
the
name
is
not
acceptable.
It
was
non-starter
so
we
pulled.
The
mailing
list
came
up
with
14
suggestions
and
it
seems
that
idf
network
slice
was
the
name
which
was
majorly
selected
and
if
you
want
to
see
the
pluses
and
minuses
of
all
the
names
mentioned
here,
I
have
attached
two
slides
at
the
bottom,
so
you
can
look
at
it
later
on
next
slide.
Please.
N
N
In
our
document
we
qualify
term
ietf,
because
there
was
a
great
amount
of
discussion
that
there
are
other
parts
in
the
network
where
you
would
use
network
slicing,
so
ietf
network
slices,
not
an
end-to-end
solution,
so
having
some
kind
of
a
prefix
or
a
qualifying
term
for
ietf
technologies
was
necessary
and
the
definition
remains
the
same.
Whatever
we
had
as
transport
controller
is
now
called
idf
network
slice
controller
and
accordingly
we
have
changed
nses
and
nsres
as
well.
Next
slide,
please.
N
And
in
terms
of
improvement,
I
got
a
lot
of
review
comments,
mainly
from
adrian,
where
we
kind
of
restructured
the
document
changed
the
nesting
in
the
sense
some
sections
were
pulled
out
at
the
top
level
and
that
we
also
deleted
lot
of
stuff
to
make
document
more
readable-
and
I
mentioned
earlier
that
now
we
have
a
better
text
for
slo
sli
and
it's
easy
to
read.
N
Also
it
blends
in
with
rest
of
the
sections
much
better
and
the
there
was
a
general
feedback
that
you
should
not
be
talking
about
too
many
details
about
realization
of
the
slices
in
this
definitions
draft.
So
we
took
lot
of
section
related
to
that
and
some
of
the
use
case
description
we
had
from
the
document.
N
We
also
had
quite
a
lot
of
discussion
on
what
vertical
or
horizontal
slices
mean,
and
we
have
taken
that
out
for
now,
and
hopefully,
framework
document
will
find
some
space
for
that
kind
of
explanation.
But
right
now
we
just
described
the
concepts
that
how
you
would
extend
the
slices
using
hierarchical
or
sequential
mechanisms.
N
Yes,
it
is
possible
that
in
some
cases
there
are
certain
slos
that
will
satisfy
isolation
requirement,
but
in
other
cases
the
customer
may
have
explicit
requirement
because
they
feel
the
need
that
okay.
I
I
feel
that
this
thing
will
not
negatively
impact
me,
so
I
would
explicitly
ask
for
that.
N
So
we
decided
to
keep
that
text
there
and
I
just
described
why
it
should
be
slo
or
not.
So
we
are
not
going
to
get
into
that
debate
and
there
was
a
discussion
that
we
should
just
keep
a
play
a
placeholder
and
not
provide
any
text
before
work
grouping
option.
N
N
So
this
is
where
we
are.
I
personally
think
that
we
could
go
ahead
with
give
a
group
adoption
adoption.
Mainly.
The
reason
is
that
a
lot
of
people
have
contributed
here
and,
yes,
we
are
still
discussing
couple
of
items,
but
by
and
large
document
has
remained
stable
from
last
six
months.
Of
course,
readability
has
improved
a
lot
as
we
kept
refining
things,
and
so
the
open
issues
are
rather
incremental,
and
hopefully
we
can
converge
on
them.
So
that
was
my
last
slide.
Thank
you.
F
I
really
wish
you
hadn't
put
in
text
on
the
isolation,
because
I
would
really
like
to
be
able
to
adopt
the
document,
but
the
text
you
have
put
in
doesn't
work.
It
isn't
a
definition.
It
instead
introduces
ambiguity
that
maybe
there's
something
here.
Maybe
there
isn't
we
had
agreed
to
leave
placeholder
in.
N
F
F
Allow
me
to
finish
katan.
The
working
group
can
improve
the
document,
but
at
the
same
token,
though,
I
am
not
as
a
work
group
member
obliged
to
adopt
text
that
I
think
is
actually
wrong,
and
in
this
case
I
think
the
text
you
have
put
in
is
wrong
and
that's
an
obstacle
tie
to
adoption
places
where
it
needs
refinement.
I
of
course,
there's
places
that
need
refinement
that
doesn't
bother
me,
but
when
it's
wrong
and
misleading
and
actively
misleading.
As
far
as
I'm
concerned,
there's
a
problem.
N
O
F
N
G
B
I'll
come
back
again
seems
like
everybody
got
disconnected.
E
M
B
A
So
I
think
we
were
in
the
middle
of
a
discussion
with
between
joel
and
kiron.
R
A
Or
right,
so
let
me
kick
it
off
with
a
question
to
you
all.
Yes,
what
I
think
I
heard
you
say
is
that
no
definition
of
isolation
would
be
acceptable
to
you.
That's
not!
No.
I
think
that's
what
I
heard
you
really
say.
F
I
don't
well,
I
do
not
believe
there
is
a
definition
of
isolation
that
is
useful,
but
I
am
perfectly
willing
to
allow
for
discussion
and
proposal,
but
the
definition
that
has
been
proposed
is
not
useful
and
I
don't
know
of
a
useful
definition.
So
I
can't
very
well
propose
one
I
mean
tom
said
so
joel.
Why
haven't
you
proposed
a
definition?
And
the
answer
is
because
I
don't
think
it's
a
useful
concept
to
the.
A
Task,
okay,
I
I
think
we
can
note
that
and
move
to
the.
A
F
A
F
N
Yeah,
sorry,
I
didn't
realize
I
was
on
mute.
So,
yes,
we
have
started
some
discussion
and
what
we
got
was
initially
scratched
text
from
people
who
are
already
in
the
queue
to
once
answer
that
one
feedback
is,
we
are
going
to
strip
down
lot
of
information
which
is
related
to
realization
and
have
a
minimal
text
so
that
there
is
a
way
to
express
isolation
from
a
customer
perspective.
N
And
one
thing:
we
are
clearly
saying
that
we
are
not
making
taking
a
stance
that
isolation
is
always
related
to
slo
and
it
can
be
met
by
all
the
slos.
You
could
have
additional
parameters
that
or
some
additional
characteristic,
which
could
come
from
a
regulatory
perspective
or
it
could
come
from
security
side
of
things
or
the
perception
of
the
customer
who
wants
to
deploy
that
slice.
So
we
just
want
to
provide
a
mechanism
to
express
that
characteristic.
A
I
think
it'd
be
really
good
to
take
this
discussion
more
and
follow
it
up
on
the
list
by
joel.
If
it's
okay,
we
have
a
bunch
of
people
in
the
queue
and
we
got
a
little
delayed
because
of
the
meat
echo.
I
think
it'd
be
good
to
give
them
an
opportunity
to
speak
as
well.
If
that's,
okay,
there,
okay
thanks
stuart
europe.
P
Well,
I
I
will
start
with
making
a
fundamental
objection
to
the
position
that
joel
was
taking.
It
is
not
his
working
group,
it
is
not
his
right
to
object
on
behalf
of
the
working
group,
it
is
the
working
group
to
take
a
decision
and
he
may
or
may
not
be
in
the
rough,
and
I
think
that's
a
position
that
the
chairs
should
take
as
to
isolation.
P
I
find
it
a
useful
concept
and
found
it
a
useful
concept
in
the
days
when
we
were
working
on
vpn
plus,
because
it
it
to
my
mind
it
does
describe
the
concept
of
two
services
operating
in
different
universes.
P
A
I
think
that's
correct
of
chairs.
I
have
not
heard
it
stopping
for
questing.
I've
heard
an
individual's
objection
and
you
know
it's
duly
noted
and
will
continue
to
be
discussed
on
the
list.
But
it's
as
you
say,
it's
just
one
individual's
objection.
K
Yeah,
this
is
a
difficult
topic
and
you
know
this
is
the
reason
why
I
I
said
that
it's
important
for
us
to
agree
on
the
pits
that
we
we
do
agree
and
move
on,
and
actually
we
had
a
really
good
process
on
this
name
issue
like
we
had
people
propose
alternatives.
You
know
you
have
an
issue
with
what
we
had
here's
some
alternatives
that
you
know
and
pros
and
cons,
and
let's
discuss
that
and
and
make
a
decision.
We
didn't
quite
follow
the
same
process
in
in
this
other
discussion.
K
K
Time
to
do
that
perhaps
but
yeah,
so
it
should
be
noted
that,
like
lots
of
people
do
have
differing
opinions
on
this
aspect.
I
I
do
too
by
the
way.
I
I
think
the
current
text
is
somewhat
misleading.
There's
been
some
discussion
on
the
list.
Actually,
if
you
follow
those
like
adrian
posted,
a
suggestion
of
a
fairly
drastic
cut
down
of
the
text,
joel
has
said
that
he
doesn't
like
to
mention
it
at
all
and
and
so
on.
K
K
Not
not
not
like
nailing
down
the
things
that
we
need
to
we
need
to
do.
I
think,
for
me,
what's
important
here
is
that
we
do
mention
these
concepts
because
it
is
talked
about
in
the
industry,
but
we
need
to
relate
it
to
our
concepts
and
and
it
we
can't
have
the
situation
where
we
have
like
this
concepts.
Like
you
know,
you
have
reserved
bandwidth
and
then
wink
wink.
You
don't
actually
have
a
certain
bandwidth,
but
if
you
have
this
other
property,
then
you
have
reserved
bandwidth
but
wink
wink.
It
doesn't
actually
work.
K
So
you
know
there
are
some
issues
there
and
I
I
think
we
would
do
the
industrial
service
if
we
actually
sort
of
tried
to
relate
the
industry
terms
to
what
we
are
speaking
about,
and
I
think
that
would
be
totally
fine,
because
we
still
are
talking
about
isolation,
then
in
the
document
and
we're
not
overselling
it
we're
not
confusing
anything.
K
We
are
relating
that.
You
know
this.
This
aspect
can
be
represented
by
those
things
that
we
have
elsewhere
in
the
document
and
and
then
we
move
on,
and
the
final
comment
is
that,
like,
I
think
part
of
the
objective
that
joel
had
was
that
you
know
whose
default
goes
into
the
document
like
we
have
several
opinions
about
this
stuff.
Obviously
the
working
group
decides
all
of
us
together,
but
but
I
understand
his
position
that
he
doesn't
want
to
start
from.
K
You
know
somebody
else's
definition
if
he
would
like
to
have
his
definition,
perhaps
or
start
from
a
blank
sheet
of
paper
where
everybody
is
on
the
same
position.
Kind
of
so
I
you
know.
If
it
was
me,
I
would
either
start
with
empty
section,
placeholder
or
adrian's
definition.
I'd
be
happy
with
adrian.
A
Okay,
so
jeff
you're
up
and
I'd
like
to
cut
the
line
if
possible,
because
we
are
well
over
on
the
slot
sure.
So
since
I
you
just.
I
While
it's
not
observable,
it's
definitely
something
and
customers
should
be
able
to
request
I've
seen
this
in
my
life,
it's
definitely
business
and
working
agreement,
so
I
believe
it
should
be
there,
whether
it's
under
definition
or
whatever
we
already
have
in
the
draft.
We
can
find
the
text
as
long
as
we
want
to
come
with
the
text
and
some
definitions
not
to
oppose
to
anything.
S
C
B
H
Okay,
I
just
want
to
say
that
actually,
because
network
lies,
the
network
slicing
is
not
only
defining
itf
and
for
the
whole
industry.
Isolation
is
described
in
almost
all
the
number
slicing
related
documents
and
also
in
itf's
history.
It
has
been
mentioned
in
the
vpn,
related
requirements,
frameworks
and
solutions.
H
So
my
opinion
is
clarifying
the
meaning
of
isolation
in
the
itf's
context
and
its
relationship
with
the
other
network.
Slicing
related
activity
would
be
really
useful
and
we
have
been
working
hard
to
separate
the
requirement
from
the
implementation
of
the
isolation,
and
I
think
many
people
give
very
good
comments
and
suggestions,
and
I
hope
we
could
work
together
to
polish
it
rather
than
just
say:
no,
we
don't
need
it
yeah,
that's
my
opinion.
U
And
the
current
document
reflects
their
agreement
of
the
design
team
or
of
their
those
who
are
listed
as
authors
on
this
document.
A
Sure
what
question
you're
really
asking
in
the
end,
we
have
to
agree
as
a
working
group.
What
the
term
is
so
it's
sort
of
you
know
whoever
contributed
to
it
doesn't
have
special
standing.
We
have
to
reach
consensus
as
a
workforce,
so.
U
U
So
I
I
think
that
there
is
that's,
since
there
is
no
agreement,
then
why
to
have
something
which
is
questionable
present
to
the
working
group
for
adoption.
U
V
Okay,
yeah.
My
comments
are
more
along
the
lines
of
what
greg
just
stated.
I
I
think
there
there
are
differences
of
opinion.
I
don't
think
it
was
asserted
that
it
was
just
joel
that
had
this
opinion,
I
don't
think
that's
correct.
V
It
seems
like
something
this
controversial
to
the
group
we
can
put
in
and
then
ask
for
working
group.
Adoption
is
a
little
premature.
It
would
be
better
to
leave.
The
placeholder
in
the
document
have
a
reasonable
discussion
about
the
definition
and
then,
if
there's
agreement,
add
text
I
at
this
point
with
the
text
in
there
I
would
be
against
working
group
adoption.
I
mean
we
have
to
start
with
what
we
agree
with
not
with
what
we
don't
agree
with.
Thank
you.
A
All
right,
thank
you
very
much.
Clearly,
there's
more
work
to
be
done
on
this
before
we
move
to
adoption,
kieran
and
the
authors
have
said
that
they
will
continue
to
discuss
it
on
on
the
list.
I
think
that's
a
a
good
next
step,
I'll
pavon
and
I
will
talk
between
ourselves
as
well
as
with
yari
of
whether
or
not
it
makes
sense
to
have
informal
or
a
formal
interim
on
just
this
this
piece.
A
A
It's
not
one
one
one
person
or
one
set
of
people
don't
dictate
to
the
rest
of
the
working
group,
it's
consensus
and
clearly
we
don't
have
it
yet
on
at
least
the
isolation
term,
and
it
sounds
like
there's
some
good
energy
to
help
move
us
forward
and
we'd
like
to
see
where
that
leads
us
and
again,
we'll
we'll
talk
with
yari
about
what
the
next
step
is
on
an
informal
or
formal
meeting
pavan.
Anything
you
want
to
add.
That's
one.
K
A
A
B
No,
I
agree
with
that.
I
mean
we
are
at
a
stage
where
we
need
to
make
a
call.
So
I
think,
given
that
the
discussion
is
happening
and
a
few
proposals
have
been
made,
let's
yeah,
let's
discuss
that-
I
mean
I
I'm
not
taking
the
place
holders
thing
totally
out
of
the
equation
yet
but
yeah
I
mean
let's
discuss
it
over
the
next
week
or
so
and
see
if
there's
a
need
for
another,
interrupt.
M
The
topic
of
this
presentation
is
application
of
ietf
network
slicing
in
5g.
On
behalf
of
my
quarters,
I'm
going
to
present
this
one
next
slightly.
M
All
the
terminology,
everything
that
has
been
done
in
nsdt
is
reflected
here,
and
the
content
of
this
draft
is
it's
shown
here,
how
itf
network
slice
related
to
5g
how
they
are
related
and
everything
related
to
that
northbound
interface
and
details
of
the
ietf
network
slicing.
Is
there
well
described
in
the
in
the
draft
next
slide.
M
As
you've
seen
here,
and
it
is,
is
basically
taking
that
from
the
definition
drop
network
slicing
as
a
concept
is
related
not
only
to
5g
but
other
use
cases
in
this
trap.
Specifically,
we
are
going
to
talk
about
5g
network
slicing.
How
is
relates-
and
we
try
to
address
everything
that
happened
on
the
nfct,
the
how
it
relates
to
5g.
M
If
you
go
to
the
next
slide,
it's
trying
to
then
next
to
us
like
trying
to
just
give
a
context
visually
how
that
relates
that
to
5g
the
for
the
end-to-end
network
slice
as
a
whole.
As
you
see
here
from
the
left
to
the
right,
we
have
started
from
the
ue
user
equipment,
all
the
way
to
the
rand
domain
to
transport
domain
and
the
core
domain.
How
various
area?
Alright.
This
domain
related
to
end-to-end
network
is
clearly
shown
here
that
end-to-end
network
slides
as
a
whole
has
component
in
the
ram
transport
or
core.
M
The
portion
which
is
related
to
our
work,
is
the
yellow
one
that
is
related
to
itf
network
slice.
This
is
important
to
note
that
this
picture
and
it's
applicable
to
other
use
cases
as
well,
that
that
network
is
life
is
not
end-to-end
network
slide.
You
know
this
is
important
to
understand
that
why
we
call
it
ietf
network,
slides
related
to
the
end-to-end
context.
M
M
To
see
the
same
problem
from
the
different
angle,
as
you
seen
here,
starting
from
bottom
up
of
this
picture,
I
have
different
networks.
I
have
run
network,
I
have
various
transport
networks
and
I
have
a
core
network.
Whatever
transport
network
provides
is
providing
the
connectivity
between
various
components
and
in
a
specific
in
5g.
I
try
to
show
the
component
that
needed
to
be
connected,
because
the
whole
idea
of
ietf
network,
as,
like
definition,
starts
from
the
connection
with
a
specific
sla,
slash
slo
in
the
5g.
M
In
a
specific,
the
connectivity
that
we
do,
we
do
connectivity
inside
the
run
network.
We
are
doing
the
connectivity
between
run
network
and
core
network
and
potentially
in
the
core
network.
These
are
various
transfer,
slices
or
sorry
ietf
network
slices,
which
well
described
in
the
document.
Why
we
need
that
depends
under
your
rand
deployment.
There
are
various
changes,
your
values,
item,
network
slice
will
be
introduced
and
it's
I
also
refer
to
the
definition
graph
and
picture
that
we
use
in
the
context
of
5g
next
slide.
M
Please
I
have
two
more
slides
the
so
the
definition
draft
in
this
case
there's
a
summary
of
the
work.
We
will
define
the
itf
network,
a
slice
use
case
in
the
5g
and
in
a
specific,
the
nbi
that
we
need.
We
discussed
that
there
are
potential
some
augmentation
needed
to
be
done
in
the
nbi.
The
draft
there
is
some
informational
model.
We
are
still
working
on
that
one,
but
this
is
the
main
topic
of
this
draft
and
last
slide.
M
We
are
seeking
for
feedback
comments.
We
continuously
aligned
this
drive
with
nstt
work
and
everything
that
is
happening
in
the
in
a
specific
in
the
area
of
the
nbi
that
we
need
and
the
proposed
the
draft
and
enhancement
will
be
presented
in
the
next
idea.
W
Document
and
about
the
section
three
for
5g
n2n
splicing,
I
think
if
the
work
is
related
to
ietf,
it
is
primarily
the
splitting
maybe
slicing
requirements
and
the
mapping
mapping
transport
slice
to
other
slices
from
different
domains.
So
I
think
maybe
this
part
of
work
could
consider
to
combine
with
the
existing
work
in
this
working
group.
I
think
maybe
you
have
also
read
our
document
about
the
factory
end-to-end
network
slice.
In
my
opinion,
I
think
it
can
be
combined
and
what
do
you
think.
M
I
will
take
a
look:
let's
have
that
one
on
the
mailing
issue.
If
there
are
some
synergy
between
those
documents
for
sure
we
can
do
that.
B
B
B
H
H
So
I'm
asking
which
topic
will
be
the
most
important
for
this
draft,
and
some
of
this
other
part
may
be
relatively
overlapped
with
some
work
in
the
design
team
and
also
the
northbound
interface
model
and
as
she
should
mention
to
enter
a
slice
mapping,
I
draft-
maybe
my
suggestion
will
be.
M
If
I
understand
your
question
correctly,
so
this
document
for
the
first
two
items
that
you
mentioned,
that
are
not
overlapping
but
rather
try
to
extend
the
abstract
definition
that
we
have
for
ietf
network
applies
in
the
5g,
so
northbound
included
definition
on
that
and
for
the
last
item,
as
I
mentioned,
if
there
is
synergy
we
can
combine,
so
I
know
that
we
don't
have
time
to
go
through
more
detail,
but
if
there
are
other
comments,
please
put
it
in
the
main
links
and
we
can
cover
accordingly.
B
Thank
you,
lewis,.
T
Perfect:
okay,
hello,
one!
If.
T
Okay,
so
the
the
motivation
of
this
work
of
this
document
is
basically
to
consider
the
or
I'm
not
sure
if
this
is
proper.
Sorry,
this
is
for
the
use
cases
right
not
for
the
okay.
T
The
detail
was
wrong,
I
think,
but
I
think
this
is
the
proper
presentation.
So
this
is
one
the
one
about
use
cases
yeah,
so
the
yeah
essentially
here
is
that
we
we
don't
have
yet
a
clear
view
of
what
could
be
the
potential
use
cases
in
that
the
consuming,
let's
say
the
itf
network
slices.
T
So
we
will
go
quickly
through
the
different
use
cases
already
identified
in
this
document.
The
first
one
will
be
about
5g
services
is
related
with
what
the
result
was
presented
before,
so
the
objective
will
be
essentially
to
support
and
to
end
network
slices
as
defined
for
5g
systems,
essentially
in
3gpp
and
regarding
any
node
interface
attributes.
We
could
consider
as
low
such
downlink,
uplink,
throughput
or
slice
qos
parameters,
for
instance,
and
plus
a
additional
characteristics
such
a
group
communication
support,
support
of
non-ip
traffic,
etc.
T
Regarding
procedures,
we
could
consider
here
where
the
procedure
is
defined
in
3dbp
for
a
slice
flight
cycle,
for
instance
inside
instance,
allocation
slices
as
a
location,
the
allocation
modification
status,
et
cetera,
et
cetera,
the
guardian
applicability
of
the
network
slice
in
this
context
essentially,
would
be
for
the
m3
and
9
and
6
interfaces
in
order
to
support
the
different
slice
types
defined
in
3dpp.
It
has
mobile
problem,
ultra
large
variable,
low
literacy
and
so
on
so
far
taking
as
references.
T
T
The
applicability
clearly
will
be
the
the
communication
between
these
remote
and
api
pops
in
order
to
support
the
different
slos
that
could
be
requested
by
this
connectivity.
The
reference
here
are
the
a
couple
of
specs
from
hcnb
the
iphone
32
and
the
soul
17,
which
specify
the
the
respective
behavior
for
these
communications
next
slide.
Please.
T
The
last
documented
use
case
would
be
the
one
of
run
sharing
here.
The
objective
would
be
the
provision
and
connectivity
between
cell
sites
and
interconnection
points
between
operators
for
essentially
for
delivering
the
traffic
from
the
this
share
radio
sales
sites
regarding
mbi
attributes
that
could
be
expected
to
be
for
sure
as
a
low,
such
a
maximum
and
guaranteed
rate,
bounded,
latency
packet
loss
rate,
etc
and
additional
characteristics
such
as
secure
connection,
ip
addressing
and
so
respect
to
the
mpi
procedures.
T
That
could
be
expected
for
the
use
case
with
the
provision
of
connectivity,
services,
collection
of
performance
and
fault
data,
etc.
Applicability
of
the
itf
network
lies
in
this
context
would
be
the
multi-tenancy
of
mobile,
front-hall,
mid-hall
and
backhaul,
and
the
reference
is
this
is
not
not
normative,
but
is
the
descriptive?
Is
the
metric
internet
form
what
paper
and
from
whole
background
shedding
next
slide?
Please.
T
T
After
that,
the
idea
would
be
to
elicit
common
slos
attributes
and
procedures
for
all
the
cases
in
such
a
way
that
we
could
document
in
an
additional
chapter
within
the
draft
and
with
respect
to
the
group.
So
the
idea
here
would
be
the
other
presentation
to
collect
feedback
and
comments
from
the
working
group
to
check
if
this
work
could
be
a
progress
as
part
of
the
work
in
the
neighborhood
licensing
design
team
and
for
sure
to
prepare
a
new
version
for
for
next
meeting,
and
this
is
all
from
my
side.
T
T
So,
regarding
the
problem
to
to
be
addressed,
that
the
impacts
on
how
they
destruct
the
potential
structure
in
terms
of
components
of
the
neglect
less
controller
is
to
understand
that
there
will
be
two
essential
procedures
to
be
performed
by
the
networks,
less
controller.
T
Essentially,
the
mapping
of
the
itf
negotiator
requests
as
coming
from
the
from
the
customer
and
then
the
realization
of
those
those
slices
regarding
the
data
models,
we
could
consider
two
different
views:
the
customer
view,
which
is
a
focus
on
the
individual
itf
network
slice,
request,
the
customer
and
the
provider
view
that
essentially
consider
all
the
devices
being
provisioned
being
realized
in
the
network.
So
these
two
different
views
are
complementary
and
necessary
for
making
it
work.
T
So
the
goal
of
the
document
is
essentially
to
identify
the
major
networks
like
controller
components
and
how
the
associated
data
models
apply
to
to
these
components
or
to
the
interface
interfaces
between
components.
Next
slide,
please
so
zooming
in
into
the
a
high
level
structure
of
that
is
reflected
in
the
neighborhood
slice
definition
document.
T
Sorry,
so,
regarding
the
structure,
we
identified
these
two
major
components:
the
mapper
that
would
be
the
the
component
in
charge
of
processing
the
customer
request
and
putting
it
in
into
the
constant
context
of
the
overall
itf
network
slices
in
the
network
and
the
realizer.
T
That
would
be
essentially
the
one
that
processed
the
complete
view
of
all
the
slices
and
decides
the
proper
technologies
for
realizing
the
itm
network,
slides
below
in
the
itf
technologies
used
for
that
and
regarding
the
models
you
can
see
in
the
in
the
picture,
in
the
middle
three
different
interfaces
that
are
labeled
as
a
b
and
c.
So
the
first
try
of
mapping
the
models
to
the
these
interfaces.
T
T
So
the
next
step
would
be
to
solve
some
open
points
that
our
signal
has
to
do
items
in
the
into
the
document
we
have
identified
two
so
far,
so
one
would
be
the
breakdown
of
ns
mapper
and
ns
realizer,
as
these
major
components
that
we
do
for
c.
The
second
one
to
this
would
be
to
discuss
the
complementarity
of
the
formation
models
for
satisfying
type
one
and
type
two
services
as
per
act
rfc.
T
So
the
point
here
is
that
we
need
to
discuss
to
understand
the
model
label,
as
b
could
also
accomplish
on
customer
request,
as
customer
slice
request,
then
to
collect
feedback
and
comments
from
the
working
group
for
sure
to
propose
a
draft
as
a
grid.
T
Sorry
as
a
great
outcome
of
the
ts,
neighbors
like
design
team
by
the
way,
the
all
the
co-authors
of
this
document
are
co-authors
of
the
two
proposed
models.
So
there
is
a
concept
on
that
and
then
to
prepare
a
new
version
for
next
meeting
and
that's
all
from
my
side.
B
We
have
adrian
in
the
queue
adrian.
G
Yeah
thanks
thanks
luis
for
this
document.
I
think
it's
useful
to
pull
things
together.
The
way
you've
done.
Can
I
ask
you,
beg
you
to
go
and
look
at
rsc
8309,
which
is
the
ops
area
working
group
view
of
how
young
models
are
composed
to
provide
a
top
to
bottom
delivery
of
a
service
and
maybe
map
to
that
or
use
some
of
that
terminology
to
be
consistent
with
what
the
ietf
has
already
done.
B
Okay,
boris,
can
you
keep
it
short.
J
So
I
will
try
lewis
very
short
question:
could
you
mention
what
network
controller
could
be
optional,
because
in
some
cases,
network
nsc
will
be
more
than
enough
to
provision
it,
so
network
controller
could
be
like
optional
in
in
several
cases.
In
my
opinion,.
T
So
do
you
refer
to
the
the
ones
at
the
bottom
right
totally?
The
bottom.
T
J
T
Q
Okay,
okay,
can
you
hear
me
yeah,
I'm
here
to
present
for
the
iep
network
slice
northbound
interface
yeah
model
next
slide.
Please.
Q
Luis
just
mentioned
that
there
could
be
multiple
net
itf
network
slice
related
model
to
be
like
implemented
in
in
four
different
for
different
networks
like
controller
and
this
draft
is
the
goal
of
this
draft
is
to
define
a
northbound
interface
young
model
and
since
the
the
terminology
has
been
changed
for
the
for
for
the
network
slides,
so
this
draft
has
been
changed,
so
you
can
notice.
Q
The
name
has
changed,
because
we
have
been
this
proposed
for
discussion
in
in
the
working
group
and
also
a
network
slice
design
team
for
several
times
so,
and
this
young
model
is
quite
consistent
with
the
ietf
network.
Slice
definition
drop.
So
this
is
the
reason
why
we
changed
the
name
and-
and
we
also
received
some
comment
about
how
our
how
this
mbi
model
to
work
with
the
relationship
with
other
young
model.
So
here's
we
give
the
some
explanation
about
things.
Q
Itf
has
a
classified
ser
young
modules
into
different
categories
and
like
there
could
be
service
model
and
network
model
and
also
the
device
model.
So
the
mbi,
the
this
ietf
network,
slice
and
bi
model
falls
into
the
category
of
service
model.
Also
lewis
mentioned
this
is
from
the
consumer
view,
and
this
model
maybe
will
work
together
with
other
layers
model
to
integ,
to
be
integrated
together
to
fulfillment
the
ietf
network,
slice
service
and
network
management
coordination.
Q
Based
on
the
the
discussion
of
ietf
network
slice,
definition,
mbi
young
model
should
fill
the
the
requirements
that
this
model
should
work
not
only
for
the
configuration,
but
also
for
the
monetary.
So
when
modeling
this
model,
we
think
the
young
model
should
fail
these
requirements
and
this
young
model,
like
borrow
the
definition
from
itf
network
slice,
definition
draft
like
the
ietf.
Q
The
left-hand
side
is
the
view
from
the
slice
definition
draft.
It's
a
view
from
a
much
higher
level
and
there
could
be
a
one
itf
network
slice.
They
will
be
related
to
different
nse,
that's
natural
slice
endpoints.
Q
So
I
just
gave
some
high
level
design
consideration
about
the
network
slice
connection
group,
because
some
of
our
authors
think
there
could
be
use
cases
that,
in
one
ietf
network,
slides
could
be
multiple
different
slo
requirements
for
different
network
slice.
Q
Members
members
means
that
a
a
pair
of
network
slice
endpoints
connections.
So
we
created
this
new
concept
in
in
the
modeling
and
also
we
think
we
need
to
create
a
network
slice
member
concept
to
to
for
the
for
the
monetary
modeling.
So
here
that's
a
the
modeling
thinking
and.
Q
Yeah,
yes,
yeah,
yeah,
okay,
then
we
finished
this
part
and
our
consideration
is.
We
would
like
to
seek
more
comments
from
the
working
group
and
and
more
input
for
the
designing
modeling
designing.
So
that's
all
for
these
slides.
Thank
you.
T
T
R
A
X
Yep
great,
thank
you
hi
and
my
name
is
tariq.
I'm
one
of
the
authors
and
the
topic
is
realizing
network
slices
slices
in
ipm
plus
networks.
Next
slide.
Please.
X
X
Oh
okay,
so
a
quick
overview
of
the
agenda
I'll
cruise
over
the
introduction,
with
whatever
time
I
can
crunch
in,
I
want
to
talk
about
the
slice
per
hop
definition
and
how
it
facilitates
the
creation
of
the
slice
and
see
if
I
can
go
over
the
multiple
approaches
to
network
slicing
that
we
have
in
the
draft
and
then
that
close
off
with
the
next
steps.
X
So
the
solution
we
adopt
is
based
on
the
diffserv
principles
for
network
slicing,
the
network
resources,
the
shared
network
resources
and
to
ensure
the
proper
placement
of
the
of
the
path
and
getting
the
traffic
treatment
for
for
sliced
traffic.
When
it's
traversing
the
shared
network
resources,
the
solution
we're
proposing
is
agnostic
to
the
path
control
technique
used
to
set
up
the
path
in
the
slice
domain,
be
it
sr
rsvp
or
others
it
it.
X
It
takes
into
account
that
slices
will
have
to
be
created
dynamically
and
changed
managed
dynamically,
and
on
demand
and
yeah,
we
we
we
have
consideration
for
different
types
of
traffic
carried
over
the
same
slice,
and
for
that
we
rely
on
the
diffserv
class
selector
field
in
the
different
data
plane.
Technologies
next
slide,
please.
X
So
there
are
three
approaches
to
the
solution
that
to
realize
network
slicing
one
is
a
control
clean,
only
slicing
of
the
network
resources.
The
second
is
a
data
plane
only
slicing
of
the
network
resources
and
the
third
is
the
combination
of
control,
plane
and
data
plane
slicing
of
the
resources
in
in
in
our
solution.
We,
as
I
mentioned
we,
we
introduced
this
slice
per
hop
definition.
X
This
definition
encompasses
a
data
plane,
size,
selector,
a
a
set
of
parameters
for
the
data
plane,
resources,
a
qs
profile,
the
perhaps
behaviors
of
related
to
the
slice
as
well.
X
X
Once
we
have
laid
down
the
the
data
model,
the
other
approach
is
disseminating
this
or
exchanging
this
in
a
routing
protocol
like
igp
or
bgp,
and
the
last
is
the
manual
configuration
of
the
of
the
definition
next
slide.
Please.
S
I'm
sorry,
I
can't
hear
you
can
you
wrap
up
so
we
have
some
time
for.
X
Indeed,
okay,
all
right,
so
the
the
hub
definition
I
mentioned
that
contains
the
slice
data
plane,
slice
selector,
it's
it's
a
field
that
is
carried
in
the
packets.
There
are
multiple
variations
for
this
I'll
leave
you
to
go
over
the
multiple
options
and
where
one
is
more
suitable
for
different
use
cases
or
deployments.
X
We
mentioned
that
there
is
a
qs
profile
associated
with
a
slice.
Can
we
move
on
to
the
next
slide?
Please
and
as
well
the
control
plane
resource
management,
the
different
parameters
associated
with
it?
Lastly,
the
topology
that
defines
the
links
and
nodes
associated
with
the
slice.
X
So
these
are
the
pieces.
There
are
three
slides
and
subsequent
slides
here
that
define
different
approaches
to
network
slicing.
The
first
one
is
the
data
plane
only
slicing
in
in
that
one
there's,
no
network
state
maintained
in
the
control
plane.
The
second
one
is
the
control
plane,
only
slicing
of
the
network
resources,
and
in
here
we
have
the
resources
in
the
control
thing
being
sliced
without
consideration
or
without
the
data
plane
being
knowledgeable
about
slices
and
the
last
one.
X
The
last
one
is
the
combination
of
the
two
of
the
of
the
previous
two.
We
think
that
the
last
one
will
give
us
the
strict
guarantees
that
we're
looking
for
at
least
we're
trying
to
standardize
in
ietf.
X
Unfortunately,
I
don't
I
didn't,
I
don't
have
much
time,
but
okay,
so
for
in
terms
of
next
steps,
we
are
going
to
coordinate
with
a
number
of
drafts
that
are
already
out
there
with
respect
to
prodigal
extensions
for
slice,
aware
traffic
engineering,
we
do
request
the
working
group
to
review
the
document
and
give
us
feedback,
and
we
appreciate
that.
I
don't
know
how
much
time
do
I
have.
I
have
another
set
of
slides
that
describe
the
slideshow.
A
Are
you
available,
you
were
going
to
try
a
different
account.
Y
Yeah
a
unified
administrative
instance,
identifier,
ai,
is
used
to
distinguish
different
virtual
network
resources
for
both
interdomain
and
into
domain
network
slices
scenario.
Now,
let's
look
at
the
ai
from
the
following
six
items.
The
first
is
identifier
of
the
dedicated
virtual
network
for
the
slides.
The
second
is,
it
supports
end-to-end
slicing
and
the
third
is
advised
unified
lsi
across
multi-domain
of
transport
network.
The
forces
area
is
one
of
the
constant
criteria
of
the
color
template
and
the
color
template
template
with
ai
provides
a
more
flexible
control.
Y
The
fifth
is
the
uniform,
color
template
for
all
overlaid
service
mapping
to
analyze
results.
The
sixth
is
its
ai,
meets
the
link
required
requirements
from
3gpp.
It
is
independent
of
the
exerting
domain
partitions
of
the
network,
and
it
is
also
the
independent
of
the
exiting
and
the
lay
frame
and
all
voting
technologies.
Y
There
is
no
modification
to
the
forwarding
tables
except
close
policy
process.
Next,
please
there.
There
is
an
example
of
our
solutions.
In
fact,
there
are
two
tablets:
red
and
blue.
The
red
bullets
include
node
h,
one
two,
three
four
e
and
link
between
one
one,
two
one
three
one:
four,
three
four
and
the
fourier.
Y
The
blue
topology
include
node,
eight
one,
two,
three,
four
e
and
link
between
x,
three,
three,
four,
three
one,
one,
two,
three,
two,
four
two
and
two
e:
let's
see
the
process
of
creating
the
slice,
the
first
select
the
ai
to
the
slice
and
the
second
allocates
resources
to
the
ai.
The
third
is
ai.
Information
is
advertised,
draw
control,
place
the
control
at
the
controller
connect.
The
resource
information
with
ai
through
bdpr
is
then
the
controller
can
build
the
corresponding
and
they
can
calculate
different
paths.
Y
Yes,
here
as
a
set
of
tn's
last
resources,
identifiers,
our
solutions
to
both
soft
and
hard
isolations
for
l3
interface,
less
obsolescence
in
igp
domain
is
numbered
or
unnumbered
l3
link
could
be
configured
with
ai
information
under
synchronized
among
idp
numbers.
The
idp
link
state
page
database
will
contain
out
three
links
with
ai
information
to
support
a
t-pass
computations
ticker
account
take
account
of
ai
criterias.
Y
Each
out
three
link
could
be
configured
to
belong
to
a
single
ai
or
multiple
ais
for
l2
interface,
slice,
isolation.
Each
l2
member
link
of
our
three
parent
links
destined
to
be
config
to
belong
to
a
single
ai
at
different
l2
members.
Link
will
have
different
single
ai
configuration
with
different
agency
sets.
How
to
number
could
be
any
type
interface
such
as
internet.
Y
Y
Yes,
this
is
a
multiple
domain
deployment.
It
is
easy
to
provide
into
in
which
network,
including
the
inter
domain,
is
some
deployment
adopt
pplu
for
setup
set
up
the
bdpr
usp
and
only
service
will
directly
over
the
bpr
usp.
If
the
only
service
have
the
requirement
of
the
te
which
defined
as
the
color,
the
bdplu
will
also
support
the
color,
the
pplu
labels
will
allocated
pro
color
the
below
is
option
b
in
the
domain.
It
can
also
provide
end-to-end
visual
network,
including
the
inter
domain
link.
Y
It's
the
an
end-to-end
srt
with
sdn.
The
pdprs
will
be
used
to
inform
the
topology
information's
contained
the
ai
to
the
control
controller.
The
controller
can
calculate
the
sr
path
based
on
the
information
for
the
enter
domain
link.
Btpis
can
advertise
the
direct
protocol
type
or
firstly,
put
in
the
domain
interconnections
to
idp
instance,
then
always
important
import.
The
data
date
from
idp
protocol
source
next,
please.
Y
Yes,
this
is
combined
with
sr
flex
algorithm.
There
are
two
scenarios
for
inter-domain
case:
sdn
controller
concrete.
We
n
for
air
is
ais
based
on
ai
and
we
aim
for
fa
ais
based
on,
respectively
sdn
controller
computers.
End
to
end
segment
relates
to
its
contains
multiple
es
and
based
on
different
topologies.
Y
However,
for
distinguished
model
mode
and
border
border,
node
iai
with
indulgence,
igp
magic.
Y
Yes,
next,
please,
yes,
this
draft
also
will
resist
retest
some
standard
ar
values
to
represent
different
types
of
ai
like
normal
urlc
and
t
next,
please,
and
for
the
indulgence
of
us,
let's
type
e-m-b-b,
I'm
iot
we
2x
will
be
to
be
defined
and
will
be
defined
in
future.
Yes,
next,
please
comments.
Welcome
thanks.
B
Okay,
loose
yeah:
can
you
introduce
your
draft
in
a
minute
or
two
and.
T
Yes,
can
you
go
directly
to
slice
three?
I
I
will
do
on
top
of
that
slide.
Number
here
scenario,
so
yeah,
basically
in
the
in
this
route,
what
we
are
trying
to
address
is
the
situation
that
now
operators
are
starting
to
deploy
computing
facilities.
T
There
is
a
wide
deployment
of
different
sizes,
a
different
number
of
resources,
so
the
idea
would
be
to
to
have
a
joint
topological
view
of
both
the
working
and
computing
resources,
such
a
way
that
we
could
take
better
decisions,
immediate
decisions,
taking
into
account
also
the
the
compute
domain,
not
only
the
network
domain,
but
the
compute
domain.
So
somehow
this
is
similar
approach
that,
as
the
one
following
the
drive,
itfts
service
on
our
topology
model,
so
it
is
even
is
a
an
original
piece
of
work
of
that
draft
that
has
taken
its
proper
life.
T
So,
in
the
pictures
scenario,
essentially,
you
can
see
there
are
the
different
data
center
pops
with
different
resources,
and
the
idea
would
be
to
incorporate
the
description
of
those
resources
into
into
a
model
augmenting
the
the
te
model.
These
resources
could
be
raw
resources,
cpu
memory,
storage
or
being
described
in
terms
of
quotas
or
or
bundles,
and
we
drop
either
an
example
like
in
the
cmtt.
A
Thank
you
very
much
for
do
the
quick
summary
apologize
about
the
interruption
in
the
middle
which
squeezed
that
already
tight
meeting
closer.
Please
stay
tuned
to
the
list,
participate
in
the
list,
discussion
and
look
there's.
We
have
look
for
both
the
formal
and
informal
meetings
that
happen
regularly.
We
remind
everyone
that
the
informal
meetings
are
open
to
all
and
your
contribution
is
most
welcome.
A
Thank
you
all
so
much
in
participating
in
this
active
meeting
and
we
look
forward
to
resolving
some
of
the
open
discussions
and
moving
forward
with
adoption
with
the
design
team
documents
once
we
seem
to
have
some
better
agreement
on
the
terminology
again,
thank
you
all
and
really
appreciate
the
contribution
and
hard
work.