►
From YouTube: TEAS WG Interim Meeting, 2020-04-23
Description
TEAS WG Interim Meeting, 2020-04-23
A
A
So
some
administrative
pieces-
and
hopefully
this
ended
up
in
the
chat
that
everyone
can
see
the
slides-
are
all
posted
at
the
this
interim
link,
the
etherpad
pleased
drawing
the
etherpad.
It's
actually
really
important
this
time
and
at
least
add
your
name
to
the
end.
That's
where
our
virtual
blue
sheet
exists
and
once
you're
there
please
stay
around
and
add
any
notes
to
each
of
the
each
of
the
slots.
You
don't
have
to
take
notes
on
what
is
being
presented
on
the
slides,
just
the
conversation
that
happens
afterwards
in
there
and
by
the
way.
A
A
A
A
A
Our
agenda
is
unchanged
from
what's
posted.
What
we
try
to
do
is
focus
on
what's
happening,
updates
from
the
design
teams
and
what's
going
on
there
and
talk
about
new
things
that
the
working
group
may
decide
to
work
on
for
regular
working
group
documents
that
are
progressing,
we
asked
to
do
status
the
list,
as
we
usually
do,
and,
unlike
usual,
we're
not
going
to
have
our
normal
working
group
discussions
on
active
documents.
A
We
want
to
have
those
on
the
list
and,
if
there's
sufficient
discussion
on
a
particular
topic,
we
can
hold
another
interim
on
just
that
specific
topic.
We
are
going
to
run
through
what
was
sent
to
the
list
at
a
high
level.
Pelant's
gonna.
Do
that!
That's
next!
Okay!
Next
slide,
please
there
was
one
liaison
that
was
actually
sent.
This
was
joint
work
with
if
I
should
have
listed.
The
other
working
groups,
in
particular
C
camp,
took
the
lead
on
the
response.
So
we
appreciate
that
so
that
was
one
outgoing
liaison.
Nothing
incoming
next.
A
A
So,
as
I
talked
about,
we
in
addition
to
our
normal
use
of
the
working
group
mail
list,
we
really
are
four
during
this
time
or
not
meeting
face-to-face.
We
think
the
the
list
is
even
more
important
and
we
really
want
to
encourage
discussion
on
as
I
said
before,
on
working
group
documents,
but
also
new
documents.
If
you
have
something
new
that
you
think
is
you
want
the
working
group
to
pay?
Please
discuss
it
on
the
list.
Don't
wait
for
the
next
face-to-face
meeting.
A
So
that's
it
at
one
point
I
was
gonna
add,
but
of
course,
I
have
forgotten
that
I
will
be
watching
jabber.
So
if
you
want
to
speak
at
speak
at
the
mic,
remember
to
say
plus
Q
Q
in
WebEx,
if
you
want
something
say
repeated
jabber
Mike
for
some
reason,
maybe
you
don't
have
audio
just
put
like
at
mic
in
front
of
it
in
the
jabber
window.
B
Good
morning,
good
afternoon,
good
evening
hope
everyone
is
doing
great.
They
do
appreciate
all
for
taking
the
time
out
to
join
this
virtual
session.
During
these
difficult
times,
my
name
is
Pawan
biram
I'm,
the
other
co-chair
for
this
working
group
and
lumijean
I'll
quickly
walk
through
the
status
of
some
of
the
working
group
documents.
We
currently
have
19
working
group
documents
with
us.
All
of
them
are
listed
here
as
Lu
mentioned.
None
of
these
are
in
the
agenda.
B
For
today's
session
we
had
requested
the
authors
of
the
working
group
document
to
send
in
status
to
the
list
thanks
to
everyone
who
sent
those
in
the
documents
for
which
we
haven't
received
any
status
updates
or
suffixed
with
them
asterisk.
On
the
slide,
we
do
request
those
authors
to
send
out
the
status
to
the
list.
We
have.
One
document
in
an
expert,
State
and
I
have
requested
the
authors
of
that
document
to
send
an
update
on
their
plans
for
reviving
this.
That's
the
RSVP
rmr
extension
document.
B
B
If
you
have
any
questions
or
comments
or
concerns,
the
authors
of
some
of
these
documents
would
also
be
starting
dedicated
threats
on
the
list
to
discuss,
focused
open
items,
the
authors
of
the
tea
service
mapping
document,
for
instance,
they
promised
to
start
a
it's
like
discussing
the
mapping
to
the
l2
l3
network
models.
Please
do
chime
in
with
your
thoughts
and
opinions
regarding
that
on
the
list.
There
are
also
a
couple
of
documents
for
which
the
authors
have
claimed
that
the
document
is
working
group
last
call
ready.
B
B
There
are
also
a
couple
of
young
documents
for
which
the
authors
are
requesting:
a
young
doctors
review.
We
will
get
the
process
rolling
for
those
as
well.
You
can
find
the
complete
set
of
collated
status
updates
on
the
remainder
of
this
deck.
I
will
not
go
through
each
of
these
individually.
Here,
you
can
go
at
them
in
leisure.
If
there
are
any
questions
regarding
the
working
of
documents
or
we
can
take
them
now,.
C
A
D
Pc
CCC
use
cases
I
thought
that
we
had
come
to
the
conclusion
that
you
won't
find
it
in
the
list.
So
you
will
find
interest.
Okay,
yeah,
that
this
continues
to
be
a
living
document
and
no
intention
to
publish
as
an
RSC
so
I
don't
know
how
how
we
actually
crack
that-
and
maybe
it's
worth
stuffing
something
in
the
data
tracker
to
say
that
or
perhaps
it
should
go
in
the
abstract
of
the
document
just
so
that
we
don't
keep
coming
back
to
it
and
saying
what's
the
status.
B
Yeah,
fair
enough,
we
we
did
discuss
this
in
the
earlier
meetings
and
I.
Guess
that
lead
from
the
working
group
then
was
that
we
would
keep
it
as
active
as
long
as
people
want
to
discuss
the
use
cases
and
then
we'll
take
a
call
on
the
fate
of
this.
At
a
later
stage,
I
mean
we
could
indeed
doing
that
or
yeah
I
mean,
as
you
said,
if
there's
something
in
the
beginning
of
the
document
and
that's
tracked,
I
think
that
would
make
things
clearer
for
folks
who
don't
have
the
history
of
this
document.
D
Right
certain
looking,
those
were
long.
Memories
will
remember
that
we
set
up
a
design
team
to
look
at
revising
RFC
3272
and
those
with
incredibly
long.
Memories
will
remember
that
this
was
a
document
written
around
the
time
of
rsvp-te
and
mpls
te
describe
in
the
background
and
tools
for
traffic
engineering
in
the
internet
so
slide.
D
D
The
mechanisms
that
we
use
have
developed
substantially
we're
also
seeing
that
quite
a
few
working
groups
are
using
the
term
te
with
their
best
base
reference
being
3272
which
really
isn't
suitable
for
that
purpose.
So
the
design
team
is
chartered
to
do
a
complete
revision,
obviously
using
a
lot
of
the
old
text,
but
updating
definitions,
adding
new
text
where
there
are
new
technologies,
streamlining
the
historical
material,
we're
streamlining
is
a
euphemism
for
deleting
and
tidying
up.
The
references
which
were
quite
a
mess
slide.
D
So,
just
to
make
the
point
that
the
this
issue
is
very
much
alive.
I
did
a
quick
look
for
recent
discussions
of
the
term
te
in
the
routing
area,
and
I
came
up
with
this
list
of
ten
working
groups
that
are
all
mentioning
te
in
one
way
or
another
and
some
extent
and
excusably
making
their
own
definition
of
what
they
mean
by
te
according
to
their
circumstances
and
its
uses
that
they
don't
really
have
anything
to
point
to
as
a
decent,
stable
reference.
D
So
we
need
to
address
what
does
everyone
mean
when
they
say
traffic
engineering?
Are
they
all
talking
about
the
same
thing?
Do
they
mean
all
of
te
or
just
some
aspects
of
te
and
that
that
one
turns
out
to
be
quite
important,
so
some
people
may
mean
traffic
steering
some
people
may
mean
resource
reservation.
Some
may
mean
network
planning
and
the
clarity
is
missing.
There's
also
a
degree
to
which
we
tend
to
reinvent
tools
and
techniques.
D
D
So
the
process
we
are
using
to
revise
the
draft
is
it's
no
longer
github
and
cramdown.
We
decided
to
use
that
initially
and
turned
out.
We
were
all
way
too
old,
so
we're
using
the
normal
ITF
process
where
contributors
propose
changes
and
I
act
as
editor
and
I
merge
the
changes
and
post
new
revisions.
That
is
just
so
much
like
everyday
use.
D
D
Only
three
of
those
actually
from
the
original
design
team
get
came
along
and
did
some
really
helpful
work
as
well,
and
what
have
we
done?
Well,
we've
turned
the
old
RFC
from
a
text
into
XML
we've
restructured
quite
a
bit
moving
other
sections
around
and
we've
thrown
out
a
lot
of
legacy,
material
bits
and
little
bits.
Little
bits
of
films
like
CR
LDP,
larger
bits
are
that
we
probably
don't
need
to
talk
about
ATM
in
much
detail
anymore.
D
So
what
do
we
need
to
do?
I
think
there
are
two
things
going
on
here:
there's
lots
that
we
could
do
in
terms
of
polishing
and
scrubbin,
but
there
are
some
things
that
are
actually
critical
and
we
we
need
to
do.
First,
as
I
mentioned
the
title
says:
internet
traffic
engineering.
We
need
to
be
comfortable
as
a
working
group
that
we
we
understand
what
internet
means
in
this
context,
what
we're
limited
to
and
what
we
include
when
we
say
it.
C
D
In
empty
sections
and
add
new
sections,
as
I
mentioned
before,
and
then
probably
the
most
important
thing
is
to
widely
discuss
and
agree
the
core
terminology
that's
discussed
within
the
working
group,
but
also
within
across
the
whole
area
and
maybe
even
more
widely
in
the
ITF.
So
what
is
te
next
slide.
D
It's
one
and
a
half
pages,
which
is
by
no
means
concise
and
pithy
I've
quoted,
may
be
the
most
relevant
paragraph
from
that,
but
even
this
is
is
very
open-ended
as
a
definition,
it
sort
of
says
traffic
engineering,
there's
all
that
stuff
that
you
do
when
you
do
traffic
engineering,
so
it
may
help
us
to
really
refine
and
nail
down
terminology
in,
in
probably
a
new
section
breaking
out
the
component
functions
with
just
syndra
paragraph
definitions,
and
this
list
is
simply
a
list
for
discussion.
It's
to
kick
things
off.
D
D
We
could
can
to
work
on
the
document
using
the
current
scheme,
which
is
to
say
it's
an
individual
submission
work
continues
as
normal,
and
everyone
is
welcome
to
contribute
at
the
moment
we're
using
a
mailing
list
which
has
an
open
archives.
Everyone
can
see
what's
there
in
Lund
there,
but
apart
from
that,
it's
open
for
everybody
to
participate,
and
we
could
probably
say
that
the
design
team
has
completed
its
job,
and
so
this
is
an
individual
draft
with
open
contribution.
D
We
could
take
that
a
step
further
and
adopt
the
draft
as
a
starting
point
for
more
work
in
the
working
group.
Formally
close,
the
design
team
and
by
having
a
working
group
draft,
have
something
a
bit
more
solid
that
other
working
groups
can
point
to
and
if
we
do
option
three.
Obviously,
this
would
be
a
good
time
to
start
asking
people
in
other
working
groups
who
are
probably
not
following
this
work.
What
their
opinions
are.
D
E
A
A
I
ran
into
this
in
the
dear
working
group,
where
they
haven't
retarder
to
do
a
beer,
traffic
engineering
and
weren't
really
doing
traffic
engineering
so
have
decided
to
instead
call
it
tree
engineering,
but
I
did
volunteered
it
right
as
a
support
that
sent
a
short
paragraph
on
how
they
could
make
their
or
section
on.
How
do
they
make
their
document
really
be
traffic
engineering
and,
in
so
doing,
I
think
came
up
with
some
short
definition
that
we
can
adopt
to
start.
That
section
is
what
is
TE
again
as
a
contributor.
A
A
A
D
Let's
say
that's
a
a
normal
promise
in
the
design
team.
You
you
just
said
struck
me
and
I
thought.
That's
forget,
Burroughs
on
the
call
and
any
other
ideas
as
well.
It
is
worth
noting,
then,
when
we
charter
new
working
groups-
and
we
say
something
glibly
like
we
will
do
traffic
engineering
in
this
working
group,
we
have
to
go
a
bit
further
and
say
what
we
mean
by
traffic
engineering.
A
F
We
did
have
in
the
Charter
that
they
were
I'd,
get
the
exact
sentences,
but
they
were
to
collaborate
with
T's,
but
the
difficulty
here
is
that
once
it
was
pointed
out
to
them,
it's
not
a
true
definition
of
te.
They
decided
to
come
up
with
own
acronym
tree
engineering
them
so
that
that's
the
conflict
there
from.
A
The
this
documents
perspective
having
a
brief
something
concise
that
other
working
groups
can
look
at
and
say.
This
is
really
what
they
have
to
have
to
focus
on
these
concepts
and
if
you,
if
they
want
to
do
it,
yeah,
there's
a
whole
slew
of
details
behind
it,
which
is
the
rest
of
the
document,
but
something
that's
shorter
than
you
know.
A
hundred
page
document
is
is
really
good,
so
I,
you
know,
I
think
you
raise
the
the
perfect
point
in
that.
What
is
te
slide
on?
D
Would
be
fine,
can
I
caution
you
about
the
IPR
poll
that
you
have
said.
You
might
do
that
if
you,
if
you
count
all
of
the
design
team
as
contributors
and
worse
than
that,
if
you
can
to
all
of
the
people
who
contributed
to
the
original
RFC
as
contributors
you'll,
still
be
doing
an
IPR
poll
in
two
years
time.
A
I
PR
statement
in
the
document
that
was
published
so
I
for
the
old
text
we
don't
have
to.
We
pull
those
authors,
but
anyone
who
contributed
to
the
new
work
does
the
and
I
mean
actually
wrote
text
or
did
something
that
it
resulted
in
text.
We
need
to
have
those
people
called
out
in
some
way,
and
you
know
we'll
have
to
defer
to
you
and
the
other
authors
to
figure
out
how
to
identify
those
the
traditional
way
we
do.
A
That
is
you
know,
people
that
are
part
of
a
design
team,
but
didn't
really
do
the
things
that
translate
the
text
they
go
in
the
acknowledgments
or
not
at
all.
That's
your
call,
but
people
who
actually
did
the
contribution
show
up
either
as
an
author
or
a
contributor
section.
So
if
you
can
make
that
distinction,
maybe
I
don't
know
if
it's
already
there
that
way,
I
didn't
look.
You
need
a
new
version
to
make
that
that
would
be
really
great,
because
then
we
can
delineate
who
really
is
responsible
for
the
content
and
yeah.
G
B
A
A
E
So,
let's
see
how
much
we
get
that
I
think
what
we're
given
to
you
actually
is
that,
after
both
of
the
drafts
will
stop
for
discussion
on
that
topic
and
and
then
at
the
end,
we'll
have
some
further
further
discussion.
We
could
have
a
discussion
on
like
whether
the
I
don't
know
the
drafts,
for
instance,
for
the
work.
That's
that's
to
ask
from
the
design
team
actually
but
like
working
for
out
of
the
drafts.
E
So
the
the
tasks
that
we
we
have
is
slightly
difficult.
I
mean
it's
in
some
sense.
Easy,
like
you
know,
just
explain
how
to
use
these
things,
and
maybe
we
need
to
add
some
things
and
write
documents.
But
it's
made
difficult
because
this
is
such
a
hot
topic.
You
once
like
that
I
know
now
we're
good
sorry.
E
Yeah
yeah,
no,
no
we're
at
the
right
right,
but
so
it's
a
hot
topic.
So
so
there's
a
lot
of
interest
on.
You
know
people
working
on
this
and
they
all
you
know
often
want
to
include
many
different
topics
under
it,
but
we've
had
a
very,
very
narrow
Tiffani's
of
what
we
actually
are
working
on
and
Eric
Eric
and
Kieran
will
talk
more
about
that
in
a
bit.
E
One
word
about
the
mode
of
operation
in
the
design
team.
So
sometimes
you
have
this
like
closed
design
teams.
This
is
not
one
of
those,
so
we
actually
do
everything
out
in
the
open.
We
have
an
open
list.
People
can
join
course
can
be
joined.
Documents
are
open
and
list
of
contributors.
People
who
join
the
calls.
It's
not
the
same
one
us
as
originally
selected
members
of
the
design
things
we've
been
trying
to
be
particularly
open,
I
think
that
actually
worked
quite
well
and,
of
course,
design
team
just
makes
proposals.
E
It's
after
working,
you
get
to
decide
whether
you
want
those
proposals
or
it's
on
some
variant
of
them.
You
also
don't
you
draft
out
of
it
based
on
team
membership,
obviously,
because
we
have
too
many
people,
but
rather
you
know
who
actually
wrote
text
for
for
the
particular
document.
So
that's
that's
how
we
operate
next
slide,
please
so.
E
To
decide
timeline
just
flashing,
this
and
I
prefer
some
of
the
graphics
is
missing,
but
so
in
ITF
106
we
had
plans,
scope
and
some
early
contributions
that
we
talked
about,
and
now
we
have
initial
definitions
and
framework
drafts
in
front
of
you,
and
the
hope
is
that
by
the
next
IDF
there
is
one
we
would
have
a
stable
draft
for
from
the
design
team
idea,
proper
working
group
document
and
so
on.
Next
slide.
Please
and.
E
The
design
team,
scope
and
plan
is
basically,
you
know,
get
to
the
basics
of
of
networking.
Here:
explain
how
to
use
actually
existing
IDF
transport
technologies,
te
/,
deviant
technologies.
To
do
this.
What
we
call
transport
slices
and
Kieran
will
define
that
in
a
bit
better
way
in
a
moment,
so
we
want
to
do
definition.
So
what
is
this
thing
that
we
would
like
to
achieve?
We
want
to
do
a
framework
that
describes
the
overall
system.
How
do
the
pieces
fit
together
and
then
the
idea
is
that
there
be.
E
E
We
don't
have
much
that
in
their
current
documents,
but
I
could
be
a
better
future
document
and
our
status
is
that
we
publish
now
the
two
first
documents
so
there's
a
document
on
definitions
document
on
the
framework
we'll
talk
about
that
in
the
bed,
the
mapping
to
particular
implementation
techniques,
any
particular
extensions
that
we
might
need
to
control
the
different
components.
Like
an
you
know,
a
northbound
interface,
for
instance.
E
E
E
I
So
the
definition
part
of
the
transferred
slice
is
trying
to
normalize
all
the
terminology,
scope
and
the
terms
that
we
use
in
the
context
of
transferred
slices,
and
it
is
the
work
of
the
entire
society.
They
have
contributed
at
some
point
or
the
other
in
terms
of
adding
deleting
topics
and
refining
the
text
Thanks,
please.
I
So,
since
we
are
talking
about
this
document
for
the
first
time,
this
is
pretty
much
the
applying
and
the
way
in
which
we
have
written
the
document.
It
has
the
definitions,
some
description
about
it
and
since
we
could
not
cover
everything
into
the
definition,
there's
a
section
on
characteristics
that
develops
the
different
aspects
of
the
slices.
And
finally,
we
have
the
structure
of
the
transferred
slice
next
slide.
B
I
Just
wanted
to
give
a
standalone
definition
for
transport
slices.
We
talked
a
lot
about
so
this
level
objectives,
because
we
want
to
make
it
easy
to
attach
what
kind
of
characteristics
you
want
from
your
slide.
If
slices,
they
should
be
measurable,
quantifiable
and
easy
to
understand
when
it
goes
down
into
the
network.
Obviously
we
talked
about
topology
and
endpoints.
That
means
it
is
not
just
a
very
simple
one-to-one,
logical
boil
or
anything
we
actually
look
at
you
look
at
it
as
an
illogical
net
worth
in
itself.
I
Next
thing,
and
so
the
first
part
is
the
characteristics
about
the
slices,
obviously
lot
of
emphasis
on
service
level
objectives,
and
at
least
from
my
perspective,
the
way
I
see
it.
We
have
two
kinds
of
SLO,
so
one
is
metric
this,
where
you
can
clearly
say
how
much
you
want
something
like
value,
latency
and
so
on
the
definitions.
We
look
from
the
existing
work
in
IETF
IFC's.
We
did
not
try
to
define
anything
on
art
all
by
ourselves
and
we
do
clarify
that
these
things
are
unidirectional.
I
I
So
the
second
aspect
of
SLO
this
from
the
operational
perspectives,
so
just
defining
latency
and
bandwidth
itself,
is
not
sufficient.
You
would
also
going
to
say
that
I
want
my
network
to
be
highly
available.
Reliable
I,
don't
want
any
packet
losses
in
it.
There
should
be
a
way
to
describe
it
and
what
kind
of
security
parameters
you
need
within
a
security
we
talked
about
encryption,
admission,
controller
authentication
and
the
isolation
characteristics.
You
should
not
be
able
to
interfere
with
other
slices
or
other
aspects
of
the
network.
I
There
was
a
lot
of
discussion
on
the
isolation
that
some
people
wanted.
It
should
be
a
top-level
SL
O's,
but
we
feel
very
comfortable
because
it's
very
hard
to
define
what
I
know
what
isolation
is
going
to
be
for
a
particular
SLO.
So
we
came
up
with
the
term
cold
resolution
of
guarantee.
In
this
we
talk
about
soft
kind,
ease
and
hard
guarantees
in
terms
of,
for
example,
high
current
able
mean
that
you
have
dedicated
the
resource
for
or
dedicated
allocation,
for
that
particular
xlo.
That
could
be
bandwidth,
bandwidth
or
latency,
or
a
link
itself.
I
Physical
link
itself
and
soft
will
be
more
virtualization,
that
you're
still
sharing
resources
with
other
slices
or
other
aspects
of
the
network
and
the
recently
did
not
know
and
SLO
isolation
at
the
top
level
is
because
we
could.
We
cannot
guarantee
that
with
isolation.
You
will
not
see
any
Sno
violations,
because
violations
can
still
happen
if
they
did
the
failure
in
the
network,
and
you
cannot
hundred
percent
guarantee
that
there
will
be
absolutely
no
packet
loss.
So
you
need
to
provide
different
ways
of
solving
those
problems.
I
I
I
Something
like
dpi
file
firewall:
these
are
the
things
that
you
would
have
in
your
network
and
you
want
to
install
in
your
transport
slice
to
perform
different
functions
specific
to
no
verticals
and
again
they
can
be
multi-point
to
multi-point
connectivity
patterns.
To
describe
a
section
of
that
next
slide.
Please
so,
and
we
had
some
cradle
of
discussion
thread.
I
What
is
that
connectivity
aspect
of
the
transport
slice
and
how
is
it
different
from
the
existing
technology
existing
te
technologies
to
be
specific,
so
one
thing
we
say
is
that
a
transport
slices
can
connect
different
types
of
technologies
together
and
how
do
you
extend
them?
So
there
are
two
aspects:
one
is
horizontal
slice
and
the
vertical
scales
in
case
of
horizontal
slices.
We
had
a
use
case
that,
if
you
have,
let's
say
segment
routing
in
a
particular
network-
and
you
want
to
stitch
with
an
l2,
VP
and
segment,
how
would
you
do
that?
I
I
Obviously,
the
structure
part
of
the
transport
slice
only
provides
some
of
the
terminology
that
is
actually
explained
in
much
greater
detail
in
framework
document,
and
the
things
we
talk
about
is
transport,
slice,
controller
or
Orchestrator,
be
warned
that
everybody
should
use
that
terminology
consistently,
not
in
a
different
manner.
So
what
is
the
meaning
of
env
inspi
in
case
of
SDR
in
transport
slices
that
is
covered
in
in
this
section,
and
it
is
always
with
reference
to
transport
slice
controller.
I
An
important
aspect
that
we
bring
out
is
the
dual
aspect
of
transport.
Slices.
One
part
is
the
logical
representation,
how
a
customer
will
ask
for
the
transport
slice
and
then
the
actual
realization
in
the
network,
so
we
could
have.
Actually
we
can
develop
the
slices
in
these
two
parts
independently
and
what
requires
Inbetweeners
the
gluing
that
will
happen
through
ndin
spi
interfaces.
I
Obviously
it
was
this
was
actually
when
we
started
writing
the
document
for
our
first
section,
where
we
wanted
to
say
that
transport
slice
is
just
one
part
of
into
in
slice.
There
may
be
other
slices
that
are
done
by
other
stores,
for
example,
fine
chains,
the
great
example
there
they
have
brand
slices
and
core
slices.
We
are
not
concerned
in
that.
I
So
that
was
just
an
overview
of
the
document.
What
we
have
covered,
we
made
sure
it
was
consistent
with
the
ongoing
work,
for
example,
that
we
enhance
VPN
document.
Didn't
we
also
make
sure
that
the
terminologies
aligned
between
framework
document
in
our
definition
document
and
in
fact
we
use
this
document
as
a
reference.
Whenever
there
is
a
discussion
on
some
s,
ellos
or
other
characteristic
aspects,
we
say
hey,
we
have
written
this
in
the
definition
document
and
you
cannot
digress
from
it.
I
So
that
way,
this
is
serving
as
a
baseline
document
of
how
transport
slices
should
evolve
and
it's
been
in
a
pretty
stable
shape
from
last
one
month
or
so.
If
you
guys
think
there's
something
missing,
please
let
us
know,
and
so
we
are
asking
for
feedback.
I
can
maybe
possible
group
adoption.
Thank
you.
I
think
this
was
my
last
slide.
H
First,
I
recognized
a
lot
of
effort,
went
into
this
and
I
appreciate
the
design
team's
effort.
However,
there
are
serious
problems
with
the
document,
as
it
is
first
one
I
hadn't
known
until
you
present
it,
because
your
description
of
SLO
is
at
the
beginning
was
fairly
reasonable
but
does
not
actually
match
section
4.1
because,
for
example,
there's
text
about
bi-directional
measurements
in
section
4.1
and
you
specifically
said
in
your
opening
that
it
was
unidirectional.
H
You
need
to
make
sure
that
the
deck
text
and
your
intentions
line
up
so
I'm,
not
gonna,
belabor-
that
on
the
rest
of
this
I
to
save
the
chairs
from
telling
me
please
send
this
to
the
list
as
well.
I
am
in
the
middle
of
composing,
an
email
listed,
an
email
to
the
list.
It
was
just
complicated
enough
that
I
haven't
sent
it
yet
I
hope
to
get
it
out
later.
Today.
There
are
some
very
serious
problems
with
the
text,
the
the
descriptive
text.
H
H
Customer
wants
a
guarantee,
you
want
the
knows
there
has
to
be
some
confidence
in
it
that
no
guarantee
is
perfect,
etc,
but
he
doesn't
care
why
it
was
violated.
There
is
no
difference
from
an
SLO
or
SLA
perspective
between
violated
because
of
competing
traffic
and
violated
because
of
device
failure.
Software
failure,
whatever
backhoe
fate,
the
cusp
from
the
customers,
point
of
view
from
the
user
of
the
slice
and
therefore
from
the
abstraction
the
sliced
provides.
This
is
a
meaningless
distinction.
H
The
entire
then
effort
you
go
to
to
describe
resolution
doesn't
match
the
way
operators
write
these
agreements.
I
would
expect
resolution
to
correspond
to
the
way
operators
actually
have
figured
out
to
write
these
to
deliver
services
and
it
doesn't
get
isolation.
Isolation
is
not
a
security
property,
because
isolation
is
actually
not
observable.
Isolation
is
a
way,
as
the
document
says.
This
document
is
supposed
to
be
about
what
is
delivered,
not
how
it
is
delivered.
There
should
be
no
references
to
isolation
in
here.
H
I
You
made
lot
of
points
and
them
are
well
accepted.
We
for
each
SLO.
We
do
mention
whether
they
are
unidirectional
or
not.
We
have
not
done,
we
are
not
saying
it
in
a
generic
way,
so
it
is
in
the
document.
I
am
pretty
sure
about.
That.
Second
thing
is
on
isolation.
I
do
agree
with
you,
and
that
is
why
it
is.
It
is
not
observable,
and
that
is
the
main
reason
it
is
not
part
our
SLO.
It
is
there
just
as
a
discussion.
H
I
Personally
think
it
brings
a
lot
of
clarity
to
the
document
and
it
is
there
just
as
a
discussion.
It
is
not
actually
part
of
the
SLO
s--
and
some
of
the
interesting
examples
were
where
user
may
ask
for
an
entire
physical
link,
rather
than
having
any
shared
resource
where
interference
as
possible
and.
A
H
A
D
D
Second
question
is
about
the
word,
transport
and
manukan
answer
this
easily
by
saying:
oh,
yes,
we've
defined
that
in
the
document,
but
I
didn't
put
it
in
the
slides,
but
I
noticed
that
the
design
team
task
was
to
talk
about
network
slicing
and
that
that
this
work
appears
to
have
picked
up
the
term
transport
network.
Slice
and
I
usually
have
transport
technologies.
D
Without
explaining
to
me
what
transport
actually
means
in
this
context-
and
the
third
question
is
around
the
term
service
level,
objective
and
I
know:
that's
a
term
that's
grown
in
popularity
in
the
industry,
but
I
think
it
means
nothing.
It's
an
objective
without
a
guarantee
is
a
wish
and
an
objective
with
a
guarantee
is
an
agreement.
D
I
So
let's
go
backwards
so
difference
between
SLO
and
SLA.
The
way
I
see
is
a
level
of
granularity,
since
SL
is
a
more
at
the
service
level
that
you
would
when
the
service
is
deployed.
You
say
hey,
this
is
my
SLA
and
for
the
lifetime
of
my
service,
I
want
this
kind
of
agreement,
but
when
it
comes
down
to
SLO,
it
is
on
per
flow
basis.
Then
you're
responsible
for
entire
flow
to
behave
in
a
certain
manner
and
you
could
have
multiple
flows
in
a
particular
service.
I
They
can
come
and
go
at
any
time,
so
the
granularity
is
different
in
terms
of
SLA
and
SL
O's
in
my
mind,
and
so
I
don't
see
any
problem
with
that,
and
your
first
question
was:
how
do
we
align
it
with
the
existing
work?
In
fact,
the
definition
what
we
have
here,
at
least
with
the
enhanced
VPN
documented-
this
was
very
much
aligned
with
just
few
tweaks.
I
Where
we
found,
we
felt
that
it
should
be
done
that
way
where
we
wanted
to
tweak
it,
but
the
starting
definition
was
in
fact
from
enhanced
VPN
and
people
who
are
working
on
those
jobs.
Helped
us
resolve
the
text
here
and
the
question
between
networks
in
transport
slices.
The
simple
answer
is
that
Network
slices
itself.
It
goes
back
to
over
a
second
last
slides
where
we
tore
last
slide
where
we
talked
about
other
slices
and
transport
slices.
K
I
can
add
one
more
item
here.
This
result
speaking
so
it
is.
We
decided
that
the
terminology
is
very
important
into
a
network
is
slicing,
as
this
picture
show
contains
a
group
of
transferrin
slices
and
we
don't
call
it
transport
network,
a
slice
or
other
terminology.
The
terminology
that
we
use
specifically,
we
call
it
transfer
effects.
So
this
one
too
many
is
a
characteristic
also
Antoinette
rocker
slice
has
other
slides,
as
depends
on
the
use
case
depends
on
technology,
as
mentioned
in
five.
K
You
did
or,
as
other
slices
are
ran
a
slice
or
two
by
a
chorus
way.
So
the
terminology
that
view
that
is
a
short
summary.
Even
the
title
of
the
drive
says,
IETF
definition
of
the
transfer
is
life,
and
we
want
to
be
make
sure
that
this
very
consistently
use
this
term.
We
are
not
using
any
other
term.
Any
draft
clearly
described.
There
are
some
stos
using
service
slice.
Slice
up
met
on
other
I,
clearly
defined
Y
with
use,
and
we
were
very
consistent
throughout
the
document
using
the
term
transverse
or
nothing.
D
A
L
Hello,
this
humming
and
just
the
two
more
very
small
additional
points.
After
a
dream,
the
first
one
is
over
there
beginning
I
think
the
definition
of
transports
lies
say
it's
claimed
to
be
logical
and
technology
agnostic.
But
the
question
is
about
whether
all
that
slice
must
have
a
kind
of
te
feature.
Traffic
engineering.
K
Maybe
I
can
answer
that
that
Kiran,
if
you
don't
want,
as
you
mentioned,
transfer
a
slice
is
a
logical
description
of
the
connectivity
basics.
Whether
or
not
the
implementation
or
realization
of
a
transverse
life
needs
te.
This
is
just
a
node
one
to
solve
on
mapping.
So
at
the
top
level,
the
transfer
slice
describe
the
connectivity
plus
SLO
that
that
connection
should
contain
how
it
is
realizing.
K
The
network
may
be
reusing
using
te
technology
or
operator
decides
to
realize
a
different
way,
so
the
TE
in
the
short
summary
the
TE
is
basically
the
technology
related
for
realization
it
is,
it
can
be
used,
definitely
can
be
used,
but
you're
the
based
on
the
definition
of
the
transfer.
Aside
from
note,
well
that
it's
just
described
connectivity
plus
SL
a
requirement
that
you
need.
L
L
Okay.
The
second
question
is
about
another
terminology
and
points.
Actually,
this
is
a
very
widely
use.
The
term
when
we
talk
about
connections.
There
are
n
points
when
we
talk
about
a
nosepass
and
also
slides.
We
have
end
points
as
well,
so
I'm
wondering
whether
we
can
suggest
using
very
specific,
a
transpose
slice
and
point
scenes
in
the
context
to
make
sure
that
we
don't
mess
up
with
other
kind
of
end
points.
L
K
Just
short
summary
of
em,
but
we
had
a
long
discussion
at
the
beginning.
You
know
at
ITA
right
now
in
different
contexts.
There
are
terminology
like
access.
Point
termination
point
the
you
know
end
point,
so
we
went
through
the
whole
cycle
of
this
name
and
I
remember.
This
was
the
first
meeting
that
we
had
and
we
came
up
with
the
end
point.
So
we
try
to
be
very
specifically
clear
if
it
is
not
the
case.
M
Go
to
slide
eight,
please
yeah
yeah,
here
I'm
a
little
bit
confused
by
slide
eight
and
ten.
So
my
understanding
of
slide
ten
is
that
the
network's
lies
the
you
ever
had
to
endure
slicer,
which
can
be
composed
by
difference
like
live
slices,
and
one
of
them
can
be
a
transpose
Liza,
and
then
the
transpose
slice
gets
implemented
within
a
network
which
can
be
one
or
multiple.
So
I
don't
understand
why,
in
this
case
we
have
a
transpose
languages.
Further
decompose
is
to
stitch
there
or
ArchiCAD.
Transpose
licenser
looks
like
this.
B
I
So
transport
slices:
that's
what
I
said
that
in
one
of
the
previous
thing
that
there
is
a
duality
concept
to
the
slices,
it
is
not
just
the
description
of
the
slides
that
a
customer
wants
in
the
end,
you
have
to
realize
it
into
the
network
and
how
you
realize
into
network
is
dependent
on
the
kind
of
technology
you
have
used
in
your
underlying
network
and
would
be
different
kind
of
technologies
together.
It
is
not
unless
a
single
into
internal,
the
video.
I
Term
that
is
used
in
5g
and
other
groups
S
sub
slices.
We
chose
not
to
use
the
term
sub
slice
and
just
build
from
the
concatenation
or
vertical
aggregation
of
the
slices
as
we
go
up
or
horizontal.
So
that's
the
main
difference
here.
So
you
do
see
the
concept
of
sub
slices
and
other
s
to
use.
We
don't
use
that
terminology.
I
K
More
thing
that
here
is,
it
necessarily
doesn't
mean
that
technology
should
be
different,
so
assume
everything
in
this
picture
is
segment
routing.
So
the
whole
idea
here
is
a
transport
slide
can
be
realized
by
a
specific
services,
/
Donnelly
/
path,
all
with
another
transfer
service.
This
is
the
idea.
Obviously,
if
you
have
different
technology,
so
this
is
another
use
case
of
this
picture,
but
it's
a
combination
of
values,
technology
or
values,
artifact
you're,
already
having
the
net
from
you
already
created,
transfer
a
slice
in
part
of
the
network
group.
K
K
K
K
I
A
N
I
can
make
my
point
really
briefly.
I
just
want
to
address
some
of
the
issues
that
were
raised
earlier
about
some
of
the
specific
content
in
the
draft
I
think
it's
important
it's
early
stage
that
a
lot
of
the
discussion
that
was
involved
in
stuff
like
that
gets
some
air
time.
Ultimately,
this
is
a
definitions,
draft
and
I'm,
pretty
sure
that
you
know
between
recommendations
from
the
working
group
and
various
other
things.
C
So
I
just
wanted
to
reply
to
what
Joe
mentioned
question
about
isolation
in
his
comments.
Basically
I
think
isolation
tree
was
not
really
invented
by
this
document,
and
we
can
see
isolation
mentioned
in
several
previous
documents
about
the
VPN
requirements
in
the
framework
such
as
the
theta
isolation
or
the
isolation
of
routing.
A
Great,
thank
you
so
I
think
we're
ready
to
move
on
to
the
framework.
A
framework
part
also
I'll
note
that
we
I
cut
the
cue
I'm,
hoping
you'll
have
a
little
bit
of
time
after
this
one.
So
if
you
have
additional
comments,
feel
free
to
make
it
after
the
discussion
on
the
framework
document
or,
of
course,
send
it
to
the
list.
N
Now
this
is
Eric
gray
from
Harrison,
John,
Drake
and
I
are
the
editors
for
this
graph.
We
have
gotten
almost
all
the
work
from
other
places,
from
contributors
or
from
other
graphs,
so
this
next
slide
so
yarn
about
us.
A
skeleton
late
last
year
and
I
was
reviewed
by
the
design
team
during
at
least
one
probably
two
conference
calls
and
then
we
one
of
the
things
that
came
out
of
that
was
John.
Drake
had
said
that
we
could
probably
get
a
lot
of
this
text
from
for
it,
for
example,
from
the
enhancing
in
drafting.
N
So
we
John
volunteered
to
actually
bring
that
text
out
and
organize
it
into
the
outline.
So
we
did
that
I
loaded
it
down
with
a
raft
of
comments
and
some
of
the
things
that
were
really
not
appropriate
for
this
particular
type
of
draft
and
so
on,
and
then
we
had
a
lot
of
comments
from
other
people,
so
we
in
fact
we
had
some
some
comments
on
relationship
between
this
draft
and
enhanced
ppm
draft
from
J&G,
and
then
we
were
appointed
as
editors.
N
And
then
so
we
got
a
bunch
of
comments
from
drew
actually
put
in
as
a
pull
requested.
A
lot
of
the
initial
work,
that's
being
done
in
this
draft
and
in
the,
and
so
we
got
a
pull
request
from
group
Dodie's
and
we
ended
up
putting
in
a
different
section
that
he
had
proposed,
but
we
used
a
lot
of
that
and
we
had
a
ton
of
text
proposed
by
raiser
at
least
a
lot
of
which
we
did
end
up
using.
We
had
a
number
of
other
comments
from
other
people
in
the
design
team.
N
So
if
you
look
at
the
graph
we're
basically
listing
the
active
members
of
the
design
team
by
the
list
as
co-authors
and
the
next
next
slide,
so
in
introducing
this
draft,
I
mean
it's
important
to
understand
that
this
is
the
framework
draft.
This
is
sort
of
like
here's,
the
background.
Here's
the
problem
space,
it's
not
about
requirements
at
this
point,
it's
not
about
architecture,
although
in
both
cases
there
will
be
some.
You
know,
limited
connections.
For
example.
We
refer
to
an
architecture
in
the
enhanced
VPN.
We
refer
to
the
actn
work.
N
N
We
have
an
interesting
error,
spelling
correction
you're
on
second,
so
this
is
supposed
to
be
implementation
and
technology
agnostic,
it's
not
supposed
to
be
implantation
and
they,
but
they
are
talked
about
at
a
high
level,
it's
appropriate
for
a
framework
graph
and
we
include
examples
from
technologies.
And
then
this
introduction
provides
the
background,
and
this
is
supposed
to
be
ran
on
all
caps.
N
One
one
application
in
particular
uses
the
term
trance
transport
network
slices.
But
we
are
not
talking
about
exactly
what,
for
example,
3gpp
talks
about
with
the
transport
network
slices,
so
we
have
sort
of
shortened
a
term.
You
know
in
hopes
that
kind
of
make
a
clear
distinction,
so
next
life,
so
there's
a
section
on
objectives.
There's
a
section
on
framework
the
section
on
applicability
of
a
seed
yeah.
N
So
the
objectives
are
what
transport
slices
are
and
what
a
transport
slice
service
is
intended
to
provide.
But
what
we
need
in
the
transport
slice
controller,
for
example,
to
make
transports
places
useful.
They
are
creating
modifying
or
moving
transport
slices
and
monitoring
status
and
performance
of
transport
slices,
and
that
stuff
is
there.
N
And
then
the
framework
section
provides
a
little
more
specifics
about
framework
we
described
slices
and
the
systems
that
they're
part
of
we
just
describe
management
applications
at
a
high
level,
and
we
talk
about
the
needs
to
have
a
way
for
a
transport
slice
user
to
talk
to
a
transport
slice
provider,
and
that
is
the
transport
slice
controller
and
it's
northbound
interface.
And
then
we
have
some
underlying
technology
examples
and
the
section
on
applicable
of
applicability
of
ACN,
ACK
and
terminology
to
the
terminology
that
we're
using
a
sort
of
a
mapping
section.
N
N
N
If
we
were
to
adopt
this
draft
have
to
agree
sort
of
in
advance
that
we
will
eventually,
you
know,
if
not
right
now,
we
will
adopt
some
version
of
the
definition.
I
personally
think
that
plugging
a
good
idea
same
time.
That
would
be
the
way
I
would
go
with
and
then
the
drafted
locations
there.
The
current
version
is
point
boys,
dashi
or
three.
The
latest
revision
was
a
very
minor
revision,
fix
a
couple
of
typos
and
update
the
reference
to
the
draft.
A
N
A
K
Just
basically
summary
of
our
request
and
I
think
this
was
was
a
great
day
during
the
writers
discussion,
a
meeting
that
we
had.
We
wanted
to
go
with
the
adoption
of
the
these
two
documents.
I
think
this
is
important
for
also,
at
least
if
there
is
a
strong
objection,
not
to
do
it
if
we
can
go
without
option,
so
this
is
basically
they
commented
at.
This
is
basically
the
resolution
that
we
got
from
agreement
in
the
design.
O
P
B
A
Or
the
for
the
people
that
raised
comments,
please
try
to
continue
the
discussion
on
the
list.
Authors
please
try
to
address
what
you
heard
today
in
your
next
version
and
then
address
whatever
else
comes
up
on
the
list
and
you
think
a
draft,
that's
ready
for
adoption
again,
please
send
a
summary
message
to
the
t's
working
group.
Obviously
to
the
chair
is
also
saying:
here's
how
you
resolve
the
issues
and
think
you're
now
ready
to
move
forward.
K
A
M
M
M
The
use
case
that
we
are
currently
describing
our
trigger
there
are
seven
into
three
category.
One
is
about
the
multi-layer,
topology
coordination,
so
discovery
of
the
topology
and
the
st.
tunnels
and
services
in
the
optical
and
IP
layer
and
provisioning
of
links
or
parallel
links,
lilac
over
the
optical
layer
or
with
or
without
by
constraints
and
adding
or
removing
members
from
illogical
links,
links.
And
then
we
have
other
set
of
required
use
cases
about
the
multi-layer
coordination.
So
once
you
have
a
failure,
the
the
protection
can
happen
and
in
between
in
different
layers.
M
Next
one:
okay,
a
reference
architecture
is
basically
trying
to
address
both
multiple
multi
domain
and
multi
layers.
So
we
assumed
to
have
an
optical
network
two
domains
to
optical
metal
domains
and
to
a
pilot,
all
domains,
control
byte
for
different
PLC's,
and
all
of
them
is
posing
a
CTN
MPR
interface
to
an
MBS
C,
which
therefore
responsible
for
both
multi
domain
and
multi
layer.
Part
and
topology
discovery
next,
one
what
we
have
okay
after
the
last
the
last.
M
In
the
last
two
meetings,
we
had
the
two
graphs
which
were
addressing
the
problem
of
applicability
of
Sdn
to
packet
optical,
and
we
have
agreed
to
merge
these
two
draft
into
these
rafts.
So
the
new
version
0
3
is
merging
goes
to
the
content
from
the
fair
format.
Roughly
roughly
0
Zod
was
presented
a
couple
of
meetings
ago,
and
what
do
we
do
in
this
moment?
We
discuss?
M
How
do
we
discover
links
and
others
in
particularly
we
describe
and
clarify
the
user
of
the
Tito
ecology
and
apply
KD
for
the
inter
domain
link
discovery
and
how
the
negative
can
be
used
and
populated
with
the
lldp,
and
we
describe
different
your
models
that
are
used
at
the
different
MPA.
Particularly,
we
exploit
the
advantage
of
the
world
an
ITF
that
most
of
the
models
are
common.
M
So
we
show
what
are
the
motives
which
can
be
the
same
models
can
be
applied
applicable
to
both
optical
and
our
packets
and
which
model
are
specific
for
optical
and
which
model
is
basically
for
packets,
and
then
we
are
discussing
also
some
coordination.
When
you
create
layer,
2
layer,
3
services,
using
a
service
model.
M
What
do
we
do?
Okay,
we
have
a
lot
of
work
in
front
of
us.
We
are
capturing
the
all
the
open
issues
on
the
github
area
and
what
some
of
the
open
issues
that
we
are
going
to
are
cleaning
up
a
little
bit
the
text.
So
at
this
moment
in
time
we
just
pull
out
the
text
from
the
roughly.
We
have
a
little
bit
aligned
to
make
it
more
than
one
document,
rather
than
two
documents
put
into
one
a
container,
and
we
will.
M
It's
just
an
initial
worker,
this
one.
What
is
the
question?
Okay,
okay,
everybody
is
welcome
to
join
this
worker,
but
we
are
wondering
whether
do
you
think
at
this.
It
is
useful
for
the
t's
working
group
so,
but
whether
the
t's
working
group
should
basically
work
on
describing
these
key
use
cases
and
analyze
how
a
city
and
can
be
used
to
address
them
and
if
you
think
it
is
useful,
maybe
we
can
adopt
this
document
as
a
working
group
document
and
move
the
change
control
to
their
working
group.
A
O
B
O
O
Different
applications
with
different
requirements
can
use
different
network
slices
generally
of
5g
and
to
end
that
was.
Slice
is
composed
of
three
major
part:
the
radio
access
network
transport
network
and
the
core
network.
So
when
we
try
to
build
up
a
5g
end
to
end
that
was
lies
how
to
ask
felishj
the
mapping
relationship
between
the
transfer
network
and
the
mobile
network
becomes
very
important,
and
our
draft
is
trying
to
solve
this
problem,
and
the
next
slide.
Please.
O
Yes,
the
core
of
m2n
that
was
nice
mapping
is
to
find
the
relationship
of
different
networks,
lives,
related
identifiers.
There
are
a
lot
of
identifiers
and,
with
these
two,
these
identifiers
in
this
page,
some
of
them
have
already
been
defined
in
3gpp
and
the
some
of
them
is
introduced
by
this
document.
These
identifiers
could
be
used
in
management
plan
control
plan
and
or
data
plan.
O
First
is
the
nice
I
means
net
was
life
instance,
which
is
end-to-end
Network
sliced
dividing
management
plan
and
and
SSI
means
network
subnet
instance,
which
is
the
networking
since
defining
a
management
plan
of
subnetwork,
for
example,
the
aliens
SSI
and
the
sea
and
SSI
next
is
TN
is
si
means
transplant
Network
slice
instance,
which
is
the
network
slice
defined
in
the
management
plan
of
transport
network.
The
concept
of
TAS
esse
is
introduced
by
overdraft
and
it
follows
the
terminologies
in
3gpp,
just
like
AMM
asiya,
the.
O
Next
is
the
s
and
s
SI,
I
means
single
network
life
selection
assistance,
information
which
could
be
used
as
an
to
end.
The
network
slicer
identifier
in
control
plan
here
SII
means
transport
network
slice,
interworking
identifier,
which
is
used
for
mapping
end-to-end
network
slice
into
transport
network.
Slicing
data
plan
here
as
T
and
SII,
is
a
concept
introduced
by
this
document
and
also
we
introduce
another
concept.
It
is
T
and
si
means
transform
that
was
Liza
and
any
fire
that
is
used
for
network
slice,
identification
inside
the
transport
network
of
data
plan.
O
Actually,
the
description
of
some
concepts
from
3gpp
in
this
page
mean
not
very
precise,
because
some
of
them
are
even
not
clearly
defined
in
3gpp
yet,
but
we
have
tried
our
best
to
read
the
documents
of
3gpp
and
talked
with
350
people
to
make
sure
that
these
concepts
are
used
properly
in
our
document,
and
we
see
that
having
we
have
defined
some
new
concepts
included
here
and
a
society
and
SII
or
Tian
Tian
si.
It
doesn't
means
that
we,
this
document,
will
define
new
signaling
protocols
or
encapsulations.
O
O
There
have
already
been
some
works
in
30
PP
about
m2
and
network
slicing
about
the
view
of
transport
network
is
missing.
This
document
provides
the
supplementation's
and
covers
tries
to
cover
the
missing
part.
The
overview
of
the
end
to
end
that
was
lies,
mappings,
showed
in
this
picture.
In
the
management
plan,
each
domain
to
the
including
a
MT
and
MCN
will
set
up.
O
Yes,
here
is
the
procedure
in
the
management
plan
and
SMS
receives
the
packet
will
receive
the
network
slice
request:
the
pharmacy
SMS
SMS
fleet,
the
si
requirements
to
each
and
SSI,
including
alien
and
Isis
Isis
and
Isis
IND,
SSI
and
I
some
extent.
The
transport
network
slide
through
carbon
to
PS
SMS.
The
SMS
allocate
PLN
SSI
and
sent
the
results
to
an
SMS
SMS
acquires
the
mapping
relationship
between
analyzed
I
and
then
fire
Antion
and
SSI
I'm
dead
fire
also,
he
lies.
O
O
Maybe
with
skip
one
there's
another
page,
but
yes
and
the
in
control
plan.
The
data
plan
well,
P
do
session
is
set
up
between
a
and
the
C
N
and
as
SS
AI
is
selected
for
P
do
session
in
mobile
network,
the
a
in
Annecy
Nationals
encapsulated
a
packet
using
the
T
and
si.
I
we
have
Chester
defined
according
to
the
as
an
SS
AI,
the
edge
mode
of
transport
network,
parses,
the
TNS
I
I
in
the
packet
and
maps
the
packet
to
transplant
Network
life.
O
O
Here
we
try
to
list
all
the
PSSI
options
for
data
plan.
It
is
used
the
in
the
packet
between
mobile
network
and
transport
network,
so
the
encapsulation
should
be
visible
for
transport
network.
In
there
too,
maybe
we
can
use
via
ID
in
there
three.
Oh,
we
can
use
a
yes
AP
IP
destination
address
as
autistics
or
even
an
ipv6
extension
headers
or
mps
label
after
layer.
Maybe
we
also
consider
UDP
saucepot,
which
is
mentioned
in
other
relevant
documents.
O
O
Go
back
to
the
motivation
of
this
document
why
we
write
this
document
first.
This
is
not
a
standard
track
document.
This
is
informational
and
we
just
want
to
give
some
guidance
for
service
providers
about
how
to
deploy
5g
end-to-end.
That
was
slicing
and
we
try
to
promote
cooperation
between
IETF
anesthesia
P
P
in
a
topic
of
Antoinette
were
slicing
and
also
help
to
discover
whether
there
are
gaps
in
implemented
implementing
and
to
end,
and
that
was
slice
mapping
on
a
slide.
O
O
It
will
be
great
if
people
yen,
T's,
will
be
interested
in
this
topic,
especially
the
design
team
for
net
host
life
is
the
intese
working
group.
So
maybe
TC
is
a
very
good
choice
for
us
and
also
we
still
are
collecting
more
feedbacks
from
what
you
do
and
operate,
and
we
will
revise
the
drafter
based
on
the
comments.
Okay,
I
think
this
is
the
last
page.
K
Can
you
go
to
a
slide
for
just
a
clarification
based
on
the
discussion
that
we
had
previously
for
transference
life
and
I
just
want
to
the
map
this
picture
to
whatever
you
seen
there,
so
this
terminology
that
is
used
here
is
heavily
3gpp
the
term
in
a
specific
that
it's
concerning.
You
know
at
least
out,
and
it
relates
the
current
transfers
was:
is
10
P
and
n
ssmf
network
service
life
management
function?
K
Basically,
this
box
is
the
box
that
we
call
it
transfer
a
slice
controller,
so
I'm
trying
to
say
that
all
the
terminology
that
you
see
here
is
there
basically
should
reference,
at
least
from
the
transport
side
to
whatever
in
the
transfer
a
slice.
We
have
the
name
of
transfer
slice.
You
know
using
transporter
all
this
thing,
that's
related
to
that.
K
So
this
is
general
context
and
I
want
to
make
sure
that
at
least
for
the
audience
when
they
see
this
picture
northbound
of
the
TN
and
ssmf,
which
is
n
bi
that
we
are
referring
and
that
we
we
will
discuss
that
for
momentarily
and
so
fond
of
telephone
is
basically
this
part
in
the
middle.
So
this
is
a
general
observation
of
this
one,
the
terminology,
if
you
want
to
continue
with
that,
in
my
opinion,
it
should
reflect
whatever
is
already
discussed
in
the
NSA
ADT
and
the
other
comment
theories.
K
Within
my
opinion,
this
is
talking
about
the
data
path
and
how
the
traffic
should
map
to
various
transfer
slices,
based
on
the
discussion
that
we
had
before
this
is
the
best
working
group
for
this
one
I,
don't
think
so.
I
think
this
is
mainly
related
to
D
mmm-maybe,
which,
basically,
you
are
using
infrastructure
that
we
are
building
here
in
your
advantage
to
say
what
are
the
options
and
you
summarize
it
in
page
7,
which
is
Craig
and
all
the
thing
this
article.
So
basically
one
comment
and
one
suggestion.
Thank
you.
O
Thank
you
very
much
for
your
comment
and
the
question
the
first
one
about
the
terminology.
Actually,
this
is.
We
have
already
considered
that
whether
it
is
good
to
reuse
or
follow
the
terminology
from
TPP
directly,
you
have
just
mentioned
just
like
the
NSS
I
or
an
SMS.
They
are
all
terminologies
defined
in
3gpp.
Maybe
they
are
not
suitable
for
IDF
people
to
to
read.
O
Actually
we
have
already
mentioned.
You
know
overdraft
about
this
question.
We
we
are
over
about
how
to
define
these
terminologies.
Basically,
the
the
name
is
not
the
core
content
of
this
draft.
We
just
want
to
say
the
procedure,
so
we
just
use
the
terminology
from
TPP
just
for
convenience
in
our
first
or
second
version
of
this
draft.
O
If
there
have
already
been
some
identification
or
terminologies
defined
in
working
in
the
other
document,
from
the
design
team
or
from
other
people,
maybe
after
the
adoption
or
how
to
say,
maybe
we
after
we
have
come
to
agreement
about
these
terminologies.
We
can
use
it
in
this
document,
because,
if
what
we
have
defined
in
design
team
haven't
been
accepted
by
other
people,
we
use
it
in.
This
document
will
also
cause
some
confusion
about
the
meaning
of
each
term
and
terminology
so
for
convenience,
which
have
to
reduce.
A
O
L
Yes,
thank
you.
I
I
really
appreciated
this
work,
because
I
think
a
drafter
heats
the
key
problem
for
Transpo
slicing
about
mapping
issue,
but
on
slide
page
three
I'm
a
little
bit
shocked
to
see
the
kind
of
data
playing,
because
if
we
only
talk
about
the
mapping
between
and
to
end
Network
slice
to
the
transport
network,
that
would
be
still
many
layers
between
the
transmit
top
of
the
transport
network
and
the
data
plane
and
given
the
fact
that
your
dessert
is
a
data
planning
is
also
multiple
technology.
L
I'm
speaking
as
an
optical
experts,
so
giving
the
data
is
multiple
technology.
We
may
have
different
kind
of
mapping
solutions
and
we
need
to
organize
the
physical
network
very
carefully
to
to
coordinate
with
each
other
with
each
other
and
what
has
been
raised.
The
in
page
four
is
only
an
example
packet,
not
for
it.
N
And
the
possibility
of
having
it
included
in
the
encapsulation
in
the
transport
in
the
transport
slice.
So
are
you
talking
about
seeing
some
logical
sense?
Are
you
talking
about
actually
explicitly
putting
some
sort
of
an
identifier
into
an
encapsulation,
because
that
would
involve
developing
a
new
relation.
P
B
O
A
O
P
P
P
So
the
main
idea
of
this
job
is
that
we
introduced
a
new
rotation
method
named
a
proactive
rotation
which
means
that
when
we
predict
failure,
then
we
will
default.
We've
done
the
video
we
created
the
rotating
ass
piece
for
this
as
P.
So
in
this
case
we
don't
need
to
have
twice
results
for
the
whole
lap
time
of
the
SP
and
main
changes
are
included
but
released.
We
move
this
job
from
the
C
camp
to
artist
as
agreed
by
teachers
last
idea
of
meeting
and
the
second
transistor.
P
P
Yeah
I
want
to
calculate
by
ok.
What
is
the
failure
prediction?
So
actually,
before
of
physical
failure,
happens
there?
There
will
be
always
some
indications,
for
example,
that
some
of
the
value
of
the
parameters
are
changing
very
quickly,
as
shown
in
this
picture.
But
the
one
of
the
concept
of
difference
between
the
protecting
failure
and
traditional
SD
or
SF
is
that
the
predicted
failure
happens
that
it
is
still
under
the
hood
of
a
Stephen
SF.
P
P
P
If
the
SDR
has
happened
and
we
can
actually
get
a
1
plus
1
or
1
by
1
rotation
switch
to
protect
the
Huskie.
So
this
is
the
main
idea.
Let's
page
please
yeah,
there
is
another
case
that,
for
example,
if
that
see
the
right
of
the
slice,
if
the
digger
is
going
near
to
the
fiber
and
then
going
away
so
then
the
node
may
detect
the
stressed
to
the
vapor
to
the
fiber
will
disappear.
P
P
Extension
is
about
the
notification
so
said:
if
they're
not
be
ADA
in
the
picture
81
it
created
a
failure.
Then
it
need
to
notify
the
source
node.
Not
a
about
this
predictive
failure,
and
in
this
noted
notification
to
message
are
hurried.
One
is
the
the
pretty
fully
active
and
the
other
is
the
cause
of
the
predictive
failure
in
the
test
format.
P
So
this
message
over
chi
goddess,
was
not
a
tool
so
that
creating
protecting
SP,
okay,
okay,
so
next
page,
please
second,
essentially
for
the
notification.
Instead,
if
not
be
fine
setup,
pretty
freely
is
not
it
isn't
cleared,
then
it
will
be
notified.
The
not
a
this
event
in
the
not
a
can
tear
down
the
predict
the
protesting
else.
Pto
save
the
results.
Please
know
that
this
option
is
this.
This
is
a
optional
depending
on.
I
P
P
B
Additional
point:
you
are
in
terms
of
protocol
extensions,
you're,
defining
two
flags
in
the
error.
Back
and
they're.
Two
flags
in
the
protection
object.
The
two
flags
that
you
have
you
are
asking
for
in
the
protection
object.
Those
typically
are
carried
in.
You
are
trying
to
characterize
that
beautiful
night
to
end
path.
G
G
This
is
this
draft
is
right.
We
are
trying
to
define
the
echo
to
the
transverse
lies
definition.
The
design
teams
output,
like
they
already
give
some
definition
about
transfers,
so
we
are
thinking
considering
and
also
the
slice
definition
and
a
framework
in
quite
stable.
So
we
are
thinking.
Maybe
it's
the
right
time
to
define
the
NBI
transfer
slice,
northbound
interface,
young
model.
We
are
thinking
of
from
the
several
way
to
define
this,
like
from
the
definition
has
described.
G
G
Yes,
this
one
considering
of
the
like
designing
this
northbound,
the
interface
young
model.
We
are
thinking
and
given
the
definition,
gave
some
nature
of
the
transverse
slice
definition
like
this
yamato
should
be
abstract
one
and
should
be
technology
independent.
So
we
are
thinking
whether
there
some
existing
model
can
fit
into
these
transfer
sized
model
definitions.
So
we
we
have
considered
about
the
like
Wien
model.
G
Dip
a
little
of
detail,
we
I
think
we
find
that
this
way
and
model
you
actually,
they
use
T
topology
model
to
to
use
together.
This
way,
n
is
actually
a
extra
abstract
note
of
a
T
topology.
So
yes
thinking,
then
this
may
relate
this
and
realization.
Given
the
definition
draft
has
just
presented,
they
also
give
some
classification
that
they
don't
want
to
be
T
type
bunk
tightly.
G
When
we
analyze
it,
we
think
it's
described
the
fully
detailed
network
topology.
So
we
also
think
when
then
we
trying
to
augmenting
this
model,
we
also
face
some
complexity.
So
even
we
have
those
analysis,
so
the
authors
prefer
to
these
define
a
totally
independent
model
to
to
to
show
the
customer
view
of
this
transport
slice.
So
next
slide.
Please.
G
This
is
the
current
transpersonal
ice
model
components
and
also
we
are
thinking
what
kind
of
customer
view
of
this
transport
slice
is.
So
we
are
trying
to
define
that
like.
This
is
a
transfer
slice
example.
In
the
right
hand,
side
like
there
will
be
endpoints
that
would
be
linked
to
the
customer
sites.
So
in
this
way,
customers
like
customer
doesn't
need
to
might
be
involved
into
the
details
of
the
transparent
network
in
realization
like
those
tano's
or
VPNs.
G
They
could
only
care
about
how
their
endpoints
being
connected
and
how
can
their
transport,
like
SLO,
being
policy
being
defined
and
then
like
whether,
if
they're
they
have
some
different
as
IO,
we
can
use
trans
person
ice
as
no
group
to
to
to
do
that.
So
we
also
give
the
definition
about
these
different
components
in
the
left
hand
side
so
that,
like
transfers,
lies
endpoint
to
the
logical
endpoint,
identify
to
identify
the
access
point
and
TS
member
is
a
logical
connection
between
any
two
TS
endpoints.
G
G
To
the
like
the
open
issues:
right
now,
yes
lecture,
we
actually
have
some
discussion
in
the
design
team.
The
right
now
we
have
some
like
this
model
in
designing
issues
like
whether
it's
it's
a
brand
new
model
or
augmented
model
based
on
existing
IDF
model.
So
this
is
a
question
we
like
to
hear
from
the
working
group,
and
next
one
is
transfer
slice.
G
Endpoint
definition
we
give
some
definition
they've
dropped,
so
you
can
take
a
look
on
that
if
you
have
other
thoughts
and
the
other
thing
is
whether
the
transfer
slice
should
support
different
as
a
whole
in
the
same
slice
and
I.
Think
Eric
gray
also
proposed
that
issue
to
the
design
team
so,
and
he
also
suggested
that
the
definition
draft
can
can
can
do
this
rather
different,
as
it
is
nice
to
be
met
in
the
single
slice.
So
this
is
the
the
current
issues
we
we
have
been
discussed,
but
we
as
doing
discussion
so
right
now.
A
Really
appreciate
the
contribution
of
you
and
also
of
everyone
else's
work
that
was
reviewed
today
and,
of
course,
all
the
working
group
participants
that
we
are
actually
out
of
time.
A
couple
of
minutes
over
based
on
the
working
group
discussions
on
the
list.
We
can
schedule
another
int
from
no
matter
what's
going
on
with
108
and
if
you
are
interested
feel
free
to
contact
the
chairs
feel
free
to
also
send
it
to
the
list.
We
don't
mind
having
those
this
kind
of
probably,
but
if
you
want
to
do
privately,
that's
okay,
too,
so
thank
you.