►
From YouTube: IETF115-TEAS-20221108-1500
Description
TEAS meeting session at IETF115
2022/11/08 1500
https://datatracker.ietf.org/meeting/115/proceedings/
A
The
the
link
into
the
chat
for
session
editing.
A
All
right
so
welcome
to
the
continuation
of
teas
in
London.
Thank
you
all
who
have
come
back.
We've
lost
more
than
half
the
room,
we'll
see
how
many
come
back
in
and
how
many
just
need
to
log.
In
on
using
the
QR
code,
we
have
the
usual
Public
Service
Announcement,
please
wear
a
mask.
Please
wear
it
properly.
Please
wear
a
proper
one,
except
if
you're
speaking
at
the
front
of
the
room,
and
we
have
the
ietf
notewell,
which
is
the
one
administrative
slide
we're
required
to
show
so
we're
showing
it.
A
Everyone
was
here
in
the
previous
session
right,
so
you
know
it
and
if
you
weren't,
please
just
go.
Take
a
look
at
the
the
link
at
the
bottom
of
the
page.
If
you're
not
familiar
with
rules
of
contribution
and
with
that
we're
going
to
move
right
on
to
shusang.
B
Hi,
this
is
Jason
and
I
will
introduce
our
update
about
itm
Network,
slides
application
in
5G
end-to-end
that
whole
slice
presenting
other
quarters
considering
this
is
a
Hot
Topic.
So
it's
very
glad
to
present
in
this
idea
next
slide.
Please
just
a
very
brief
overview
of
why
we
have
this
document.
There
are
a
lot
of
applications
for
item
Network,
slides
and
we
think
5G
is
one
of
the
most
important
application
scenario.
B
So
we
have
three
documents
about
this
topic
and
before
it
have
104,
we
are
suggested
by
the
all
chairs
to
merge
these
three
documents
and
during
process
we
collect
a
lot
of
feedback
from
the
these
working
group,
so
we
also
modify
the
contents
and
and
some
missing
point-
and
we
have
a
new
document
for
this
topic
and
basically
this
document
is
trying
to
answer
the
following
key
questions.
B
The
first
one
is
the
rule
of
ietm
network
slides
in
5G,
Network
slice,
and
the
second
one
is
the
existing
3gpp
work
that
has
already
been
done,
which
is
really
related
to
item
Network,
slides
and
how
to
map
the
GP
NATO
slides
to
item
mental
slice.
Next
slide.
Please
here
is
the
draft
structure
and
we
really
make
some
progress
in
the
new
version,
the
version
one
and
make
it
make
the
structure
more
stable
in
section
three,
because
we
collect
some
feedback
from
community.
B
So
we
update
the
figures
and
terminologies
to
avoid
introducing
unnecessary
3gpp
Concepts
to
make
itl
people
confused
and
for
section
4.
We
give
some
overview
of
the
mapping
between
3gp
and
ITF
Network
slides
between
going
into
details
about
the
mapping
process
and
for
section
five
we
clarify
the
relationship
between
the
existing
3gpp
parameters
that
are
have
already
been
defined
in
TS
age.
B
28.501
clarify
the
relationship
between
it,
with
the
itm
network
slides
and
in
section
6,
which
is
the
main
part
of
the
document.
We
modified
the
script,
descript
descriptions
and
terminology
some
updates
in
terminology
next
slightly,
please.
B
This
slide
actually
has
already
been
introduced
by
Raza
index
ietf.
The
the
motivation
here
is
just
to
show
the
scope
of
this
document
to
answer
what
is
the
rule
of
itm
network
slides
in
February
scenario,
the
scope
of
this
document?
We?
What
we
are
trying
to
cover
is
all
the
connection
between
5G
net
Network
functions
that
can
be
connected
by
an
ITF
Network
slice.
B
So,
depending
on
the
Run
technology
deployment,
there
may
be
a
different
interface
that
can
be
that
can
use
item,
Network,
slides
to
connect
the
different
network
functions
and
based
on
the
comments
from
community
that
I
have
already
mentioned.
We
just
replaced
some
the
detailed
Concepts
from
3dp
site
and
we
just
think
different
interface.
May
introduce
no
difference
for
itl
parts,
so
just
make
them
all
showed
as
Network
functions
for
for
in
the
picture
and
to
show
what
the
ITF
Network
slides
will
be
inside
different
scenarios.
Next
slide,
please.
B
Yes-
and
here
we
give
some-
this
is
a
new
section.
We
try
to
give
some
overview
of
the
mapping
between
3gpp
and
itm
network
slices.
We
just
take
the
connection
between
run
UPF
as
an
example
and
show
the
options
realizing
5G
Antoine
that
was
live
mapping,
for
example
the
V
Line.
B
Here
we
introduce
a
new
terminology,
we
call
it
handoff
or
handoff
ID,
which
is
used
between
a
3gpp
site
and
ITF
side
to
just
do
the
mapping
in
different
scenarios,
and
we
we
give
some
examples
about
how
to
do
the
mapping.
For
example,
V
Line
as
the
handoff
ID
MPS
label,
as
handoff
ID
and
sr6
Seed,
as
handoff
ID
I,
have
to
mentioned
that
all
these
three
options
has
or
has
also
been
defined
in
the
3gpp
parameters,
so
we
think
it
works.
B
We
also
give
some
considerations
for
the
case
of
policy
based
routing
and
gtpu
UDP
cells,
part
based
mapping,
which
is
defined
in
another
document
in
DMM
working
group.
Next
slide.
Please.
B
Yes,
I
think
this
part
is
one
of
the
main
progress
in
in
this
version,
because
we
think
the
GP
transport,
especially
the
related
parameters
defined
in
EP
transport,
is
the
most
related
part
in
your
PPP
to
connection
with
ITF
Network
slides,
and
we
can
see
the
parameters
that
are
have
already
been
defined
in
EDP
transported
in
the
table.
It
includes
the
IP
address
logical
interface,
infer
next
hobby
infrared
cues
profile.
B
All
these
attributes
could
be
used
in
in
the
mapping
of
3gpp
between
3gp
Network
slice
and
ITF
Network
slides,
especially
the
next
half
info,
which
identifies
the
Ingress
transplant
node.
Each
node
can
be
identified
by
any
combination
of
IP
address
of
Next
Top,
router
of
transform,
Network
system,
name,
post
name
and
App
Management
address
of
Transformer
nodes,
which
means
that
we
can
use
information
of
this
information
to
choose
the
PE
node
in
TN
domain
and
also
another
important
set
of
parameters
is
logical.
Interface.
B
Infer
which
are
which
is
a
set
of
parameters,
include
logical
interface,
type
and
The
Logical
interface
ID.
It
specifies
the
type
and
identify
of
The
Logical
interface,
as
I
have
mentioned
in
the
in
the
previous
slide
it
it
could
be
a
villain,
ID,
amps
tag
or
segment
ID.
So
if
this
is
assigned
equally
personalized,
so
it
can
be
used
to
map
3gpe,
Network
slides
to
item
number
Slice
on
that
side.
B
Please,
actually
these
figures
we
have
presented
several
times
in
ITF
meeting
the
it
just
shows
the
overview
process
of
how
we
do
Network
slice
mapping,
basically
the
the
LSM.
This
sorry,
this
terminology
is
from
3gp
side,
but
it's
equals.
B
It
equals
the
oxidator
in
ITF
framework
document,
the
ismf
will
receive
some
requests
from
the
customer
and
create
network
slides
and
the
the
requirement
and
will
be
separated
and
to
push
the
the
subnet
controller
to
create
their
own
network,
slides
to
make
them
all
together
to
satisfy
the
overall
requirement
and
for
the
ietl
part,
the
item.
B
Network
slice
controller
will
create
the
the
the
itm
network
slides
and
with
the
item
neutral
slice
identifier,
and
in
this
progress
there
will
will
be
some
mapping
relationship
allocated
by
the
management
plan
to
the
CE
and
the
PE
node
to
let
them
know
which
stage
PPE,
Network
slides
will
be
mapped
to
which
ITF
Network
slides,
handoff
ID
and
for
the
PE
size
it.
It
shows
that
which
item
Network,
slides,
handoff
IDE
will
be
mapped
to
which
itm
level
slides
and
next
slide
please.
B
So
we
think,
after
a
lot
of
discussions
among
the
others
and
a
lot
of
work
from
contributions,
and
also
we
collect
a
lot
of
comments
from
the
working
group
we
haven't.
I
have
to
admit
that
we
haven't
lost
all
of
the
comments
and
we
just
released
them
in
the
GitHub.
But
we
think
the
the
structure
of
the
document
is
quite
stable
and
we
think
it's
a
good
start
for
further
discussion
about
this
topic.
So
we
we
request
for
one
group,
adoption
and
always
reveals
and
comments
are
welcome.
B
We
will
have
weekly
call
meeting
and
it
is
open
to
anyone
who
is
interested
and
we
will
keep
modify.
Modifying
the
dolphin-
actually,
there
is
a
Meetup
among
the
others
this
morning
and
we
will
slightly
change
the
order
of
the
document.
But
the
the
contents
are,
we
think,
are
stable
and
we
will
give
some
detailed
example
about
how
to
do
the
mapping
especially
use
the
Nvidia
model
that
has
already
been
adopted
by
working
group.
Yes,.
A
Okay,
notwithstanding
going
over
time,
so
not
really
leaving
time
for
this
question,
which
is
definitely
bad
form,
we're
going
to
ask
the
working
group
whether
or
not
are
there
any
objections
to
adopting
this
document
raise
your
hands
if
you
object
lower
your
hands,
if
you've
read
the
document
and
you
think
it's
ready
and
if
you
haven't
read
it
or
don't
have
an
opinion,
please
don't
do
anything
and
we're
going
to
bring
up
the
next
presentation
sure.
So
it's
Julian.
A
A
But
the
conclusion
is
it's
really
mixed
and
not
huge
support,
so
you
know
I,
don't
I
can't
judge
whether
it's
because
of
the
time
or
not,
but
if
you
want,
if
you're,
going
to
ask
the
working
group
to
adopt
your
document-
and
you
want
us
to
take
it
seriously-
you
got
to
leave
time
for
that.
C
Thank
you
right,
so
everyone,
so
this
is
talking
about
the
realization
of
ITF
Network
slices
for
the
5G
use
case
using
current
ipmpls
Technologies,
and
this
is
on
behalf
of
all
of
my
co-authors,
who
are
listed
here
next
slide,
please.
C
So
by
way
of
reminder,
the
overall
goal
of
this
draft
was
to
take
5G
slicing
as
the
use
case
and
to
see
to
what
extent
ietf
Network
slices
can
be
implemented
using
current
IP
and
mpls
Technologies
next
slide.
C
And
so
here
are
the
differences
between
the
current
version,
which
is
zero
two
and
zero
zero
zero
one
had
a
lifetime
of
about
one
hour,
because
that's
something
that
we
forgot
to
add,
and
so
it
became
zero
to.
You
know
one
hour
later,
first
of
all,
we'd
like
to
welcome
Reza,
Louis
and
Benny
as
co-authors
to
the
draft
zero.
C
Two
in
section
two,
we
added
some
extra
material,
because
what
we
wanted
to
do
is
to
describe
how
the
overall
data
path
from
a
network
function
which
might
be
on
a
compute
and
one
DC
to
a
network
function
somewhere
across
the
network.
Again
perhaps
on
a
compute
in
another
DC.
C
How
that
end-to-end
data
path
has
several
different
sections
to
it
under
the
control
of
different
orchestration,
because
you
have
a
sort
of
Sandwich
where
you've
got
what
we
call
a
local
segment,
then
we've
got
the
transport
segment
in
the
middle
and
then
the
local
segments.
C
We
previously
had
an
overview
of
5G
networking
as
pertaining
to
the
content
of
draft
that's
relevant
to
the
contents
of
this
draft,
but
for
ease
of
readability
of
the
main
body
of
the
draft.
We
moved
that
overview
to
appendix
B.
C
Now
section
three
section
three
in
previous
versions
had
discussed
two
handoff
methods
between
you
know,
for
example,
the
brand
domain
you
know
presented
by
DC
and
the
also
mobile
core
domains
and
their
transport
Network.
C
C
We
added
a
additional
handoff
method,
namely
into
provider
option
b,
and
this
is
well
suited
to
a
situation
where,
let's
suppose,
layer,
3
vpns
are
used
as
the
underpinning
the
layer,
3
VPN
vrfs
are
actually
located
on
the
compute,
perhaps
on
a
virtualized
router
on
the
same
server
as
that's
hosting
the
network
functions
and
that
its
roots
are
communicated
via
bgp,
perhaps
to
a
DC
Gateway
and
from
then
to
the
PE
that
faces
the
DC
and
so
on
across
the
network.
D
C
Finally,
and
we
have
a
new
section
section-
five,
which
talks
about
how
one
you
know
could
deal
with
or
not,
5qi
5qi
stands
for
5G
cos
indicator,
of
course,
that
in
itself
isn't
a
direct,
actual
group
of
a
packet,
but
sometimes
people
map
that
5qi
value
to
a
dscp
and
value,
and
so
one
model
is
you
say
for
a
given
slice
that
slice
is
mapped
onto
you
know
one
particular
cue
as
it
travels
through
the
network
and
therefore
it's
5qi
unaware
or
the
other
model
is
5qi
aware
mode
where,
according
to
five
qis
that
exist,
multiple
of
them
within
the
same
slice
encoded
onto
dscp,
you
know
those
different
packets
could
be
mapped
onto
different.
C
You
know
queues
as
the
packets
travel
across
the
transport
Network
and
we
have
corresponding
diagrams
I
may
have
example
to
illustrate
each
of
those
two
cases.
So
now,
let's
move
on
to
the
final
slide,
please
so.
Finally,
you
know,
given
that
we've
received
a
lot
of
interest
in
the
draft
we'd
like
to
as
a
Next
Step
request
adoption
as
a
working
group
draft.
B
Hi
Julian,
this
is
joseon.
Thank
you
for
our
presentation.
I
just
think
this
is
a
really
interesting
topic
and
I
think
it's
a
valid
matter
to
realize.
Itf
transport
slides
in
5G
scenario,
with
existing
Technologies
still
I
I,
have
seen
some
possible
overlap
between
my
document
and
your
document,
because
we
all
we
both
focus
on
the
5G
scenario
and
even
the
something
like
handoff
ID,
maybe
also
both
considered
in
our
documents.
So
I
I
just
want
to
seek
your
suggestion
or
suggestion
from
chairs
or
working
group.
C
Yes,
they
do
certainly
cover
similar
ground
and
therefore
there
is
some
degree
of
overlap.
I
mean.
Certainly
we
can
look
to
see.
You
know
how
one
could
address
it.
I
mean
one
method
might
be.
You
know
if
there's
places
where
there's
a
lot
of
overlap,
we
remove
the
overlap.
So,
instead
of
having
overlap
one
draft
in
across
the
first,
the
other
and
says
in
for
more
detail,
you
know
look
in
section
5.1
of
this
other
draft
or
you
know
the
Other
Extreme
is
you
know,
merging
the
drafts.
E
F
I
think
the
motivations
of
the
two
documents
are
slightly
different.
There
is
some
text
in
this.
F
That
could
clearly
move
to
the
other
document,
but
in
terms
of
the
motivation
of
document,
it's
clearly
different
see.
G
G
We
also
have
other
options
for
this
similar
purpose
like
vaping
plus,
and,
as
you
mentioned
in
the
slides,
you
say
that
you
want
to
describe
to
what
extent
the
existing
technology
can
be
used
in
the
scenario
and
I
would
suggest
include
this
in
the
document
so
that
you
can
say
the
applicability
of
this
existing
Technologies
and
also
the
limitations
useful
for
people
to
understand
the
difference
between
different
options,
so
that
can
choose
a
simple
suitable
tool
for
their
Network.
For.
C
So,
are
you
suggesting
we
analyze
things
that
are
not
under
the
category
of
existing?
C
You
know
IPM
PLS
Technologies
by
both
contrast.
Like
are
you
saying,
but
even
though
the
main
sorts
of
direction
of
the
draft
is
using
current
ipmpls
Technologies,
are
you
saying
we
ought
to
way
out
of
against
alternative
technology,
X,
Y
and
Z?
In
order
to
highlight
you
know,
potential
advantages,
what
you
had.
G
In
mind
yeah,
my
suggestion
is,
as
you
imagine,
that
in
the
slides
you
want
to
identify
to
what
extent
this
technology
our
mechanism
is
suitable
for
the
5G
Network
slicing,
so
I
suggest.
The
document
could
specify
this
in
the
text
with
some
text
to
which
are
the
applicable
scenarios
to
use
existing
Technologies.
So
that
will
be
helpful
for
people
to
understand
when
they
can
use
existing
technology
and
when
they
will
need
some
enhancement
to
achieve,
maybe
for
some
critical
services
in
the
5G
or
other
scenarios.
Yeah.
C
I
mean
certainly
the
overall
sort
of
premise
of
the
draft
was
asserting
that
one
could
address
the
5G
slicing
use
case
using
like
in
PLS
current
Technologies,
and
then
you
know.
The
body
of
the
draft
then
exposes
that.
You
know
explains
that,
since
that
was
the
sort
of
overall
purpose
drafts.
A
D
Reserved
from
Sienna
as
a
co-author
of
both
documents,
so
the
this
document
explicitly
talk
about
their
realization
detail
of
that
and
the
document
that
susanka
explained
is
one
layer
up
and
it's
kind
of
abstraction
of
that
it.
It
would
be
a
good
idea
to
next
meeting.
We
put
a
hierarchy
all
these
documents
together,
how
they
are
related.
You
know
the
title
is
the
same:
for
people
who
don't
know
it
they
might
be.
You
know
not
clear,
but
definitely
there
is
differences
between
them.
A
Thank
you.
Thank
you
for
the
comment.
Thank
you
for
the
presentation,
there's
clearly
interest
in
the
topic,
so
we'd
like
to
hear
more.
Certainly,
if
there's
Parts,
you
can
combine
with
existing
documents
or
other
documents.
That's
always
great
right.
It
seems
like
you're
not
covering
exactly
the
same
topic,
so
there's
room
for
multiple
documents
here.
Thank
you.
E
Yeah
I'll
be
talking
about
Network,
slicing
mapping,
so
on
the
same
lines
next
slide,
please.
E
Basically,
we
have
a
working
group
document
which
is
T
service
mapping,
it
Define
a
grouping
that
grouping
has
been
used
to
augment
l3sm
l2sm
L1
CSM,
with
mapping
of
how
this
service
uses
the
underlyte
resources,
whether
it
is
in
form
of
v
and
T,
topology
or
tunnel.
The
same
thing.
E
We
also
apply
for
Network
models
and
this
how
work
has
been
going
on
in
the
working
room
for
a
while
now,
but
one
thing
was
missing
that
we
don't
have
a
similar
thing
for
IIT
of
network
slices
and
at
the
same
time
we
didn't
want
to
overload
this
current
document,
which
is
anywhere
very
big,
and
even
the
mapping
requirements
are
little
different
because,
especially
with
NRP
coming
into
the
picture,
so
it
makes
sense
to
have
a
separate
document
which
is
talking
about.
How
do
we
map
slice
service
to
the
underlyte
resources?
Next
slide,
please.
E
So
this
is
that
mapping
model.
Basically,
the
new
requirement
also
is
that
we
need
to
map
to
NRP.
So
once
we
have
got
the
ndi,
which
is
the
top
level
this
we
are
mapping
that
NBI
to
what
is
the
NRP
that
is
instantiated
in
the
network
and
then,
if
l3nm,
like
services,
are
being
used,
as
Lewis
had
presented
in
the
earlier
presentation
with
the
mapper
and
the
realizer.
E
If
the
below
thing
is
a
network
model
like
l2nm
or
l3nm,
you
can
have
a
mapping
to
that
as
well
as
well
as
maintain
the
mapping
to
NRP
plus.
We
can
also
map
to
T
resources.
So
that's
the
next
slide,
so
the
existing
mapping
that
we
had
for
for
T
resources
that
can
also
be
done.
So
all
we
provide
flexibility
in
this
case
would
be
like
in
the
previous
presentation,
which
was
trying
to
use
the
existing
technology
and
not
create
an
art
piece.
Yes,
that's
fine!
You
could
directly
map
things
to
the
T
resources.
E
This
mapping
realization
model
would
allow
that.
The
idea
here
would
be
that
this
mapping,
you
know,
gets
populated
when
you
do
the
realization
of
the
slice.
You
could
also
allow
configuration
only
in
cases
where,
maybe
if
the
topology
is
exposed
already
to
the
customer,
they
have.
They
can
also
do
some
more
control
over
how
the
network,
how
the
things
are
realized
that
option
I,
don't
see
it
being
used
that
much,
but
currently
it
is
there.
E
We
are
looking
for
feedback,
whether
that
should
be
there
or
we
should
just
make
this
read-only
and
not
allow
configuration
at
all
right
now
it
is
allowed.
So
we
want
to
get
feedback
for
that
as
well
and
continuing
in
the
same
thread.
There
is
a
possibility
also
to
have
multiple
map
types.
So
right
now
we
are
basically
borrowing
things
from
how
we
have
done
for
ITF
networks
for
the
teas
service
mapping.
E
We
wanted
to
see
what
needs
to
apply
for
ITF,
Network
slides
as
well,
and
what
we
should
change
so
looking
for
feedback
on
that
next
slide,
a
very
high
level.
This
is
what
the
we
are
augmenting,
ITF
Network
slice,
Define
a
container
called
mapping.
You
can
map
to
nrps
to
l3nm
l2nm
or
to
te
in
case
of
T.
We
simply
reuse
the
grouping
that
already
exists
for
T
service
mapping
and
that's
basically,
what
the
current
model
design
is
next
slide.
E
This
is
the
tree.
I
think
we
can
go
to
the
questions
and
use
that
time.
So
first
question
in
our
mind:
right
now,
I
have
only
done
the
mapping
for
slice
that
at
the
ITF
Network
slice
level,
I'm
mapping
it
to
NRP.
Do
we
need
to
do
mapping
at
the
other
constructs
like
at
each
collection,
group
level
or
connectivity
construct
level,
or
is
that
not
necessary?
This
is
not
very
clear
as
of
now,
so
we
want
to
get
more
feedback
on
that.
E
Similarly,
should
we
map
sdps
into
say,
sites
of
l3sm
ltsm
or
let
Let
It
Be
figured
out
during
the
realization
time?
There
is
no
such
clear
requirement
that
this
kind
of
mapping
would
be
useful
or
not.
That
is
not
clear,
so
we
want
to
get
feedback
on
that.
Should
we
allow
multiple
map
types
Etc
and,
of
course
the
the
major
work
would
be.
We
need
to
add
some
examples
to
make
sure
that
people
understand
how
to
use
this
model
and
how
would
it
be
useful?
F
No
one
is
asking
a
last
one,
so
you
said
you
did
not
want
to
augment
the
T
use
the
te
service
mapping
model
again.
Is
it
because
of
the
technology
agnostic,
positive.
E
Taking
or
no
so
basically,
if
you
see
in
the
tea
service,
we
have
a
common
model
which
is
just
a
grouping
and
then
what
we
do
is
we
have
augment
of
l3sm
augment
of
l2sm
augment
of
L1
CSM.
All
these
multiple
models
in
the
same
draft.
We
could
also
add
augment
of
IQ
of
Netflix
size
right
now
we
kept.
We
want
to
keep
it
in
a
separate
document,
because
if,
when
last
time,
I
was
presenting
this
t-service,
this
was
the
exact
question.
E
I
asked
the
working
group,
and
at
that
time
the
idea
would
be
that
we
will
be
blocking
these
service
mapping
for
a
long
time.
Let's
get
get
this
separation,
that's
one
reason,
and
second,
none
of
the
other
things
care
about
NRP.
This
would
be
the
only
one
where
an
RP
concept
is
coming
in,
so
it
makes
more
sense
to
keep
this
separate
and
add
the
NRP
concept
only
for
ITF,
Network
slice,
mapping
and.
F
Keep
the
other
things
separate?
Okay!
Well,
let's
discuss
that
more
on
the
list,
one
you
currently
augment
the
slice
service
model.
Yes,
so
why
don't
you
consider
moving
this
to
that
to
a
service
model
itself.
E
E
The
working
group
feels
this
is
useful.
The
only
thing
would
be
then
the
moment
you
do
that,
then
the
an
RPM
model
also
needs
to
be
standardized
before
this
happens,
so
move
it.
You
you
try
to
put
this
in
the
NBI.
That's
also
something
to
worry
about
I
would
rather
not
do
that
I
think,
like
more
sense
to
keep
it
separate.
H
Okay,
Drew
just
a
clarification.
It
seems
to
me
that
the
Europe,
the
prefix
of
the
model
as
a
network
slice-
if
it
is
MBI
young
model,
it
seems
to
me
that
is
a
NS
test
traffic.
So.
H
H
E
A
E
You
so,
let's
move
to
the
second
one
again,
it's
zero
three,
but
first
time
I'm
presenting
this.
This
is
about
traffic
mapping
Yang
model
next
slide.
Please
again,
when
we
were
discussing
T
service
mapping,
this
was
one
of
the
open
issues
that
were
listed,
that
we
don't
really
have
a
good
way
to
also
tell
what
traffic
flows
in
the
parts
and
the
services
that
we
are
currently
establishing.
E
So
this
is
an
attempt
again
sort
of
like
a
straw
man,
getting
a
feel
from
the
room
that
whether
this
will
be
useful
work
to
continue
or
not.
E
So
background
we
know
in
ITF
we
have
various
young
models.
We
set
up
various
PE
Services
tunnels,
Parts
Sr
policies
all
that
stuff,
but
we
don't
really
have
a
good
Yang
model
that
clearly
says
what
traffic
flows
over
these
parts
and
services.
We
have
various
different
things
like
we
have
ACL
and
then
what
happens
is
at
various
models.
They
try
to
do
it
themselves.
Itf
Network
slice
is
also
trying
to
do
it
via
something
called
as
a
match
criteria.
We
have
protocols
like
bgp
and
psap.
E
Both
have
flow
spec
as
a
way
to
Signal
this,
and
some
of
the
models
also
have
the
flow
match
criteria
based
on
IP,
UDP
and
TCP
headers.
So
we
have
various
people
doing
various
different
things,
but
not
something
that
is
standardized
in
the
Yang
model
point
of
view.
So
the
question
is:
is
this
even
possible?
Are
we
too
late
and
if
we
want
to
do
it,
what
is
the
right
way
to
do
it?
So
these
are
the
questions
in
front
of
the
room.
E
So
let
me
just
give
at
a
very,
very
high
level
what
my
thinking
is
and
then
we'll
open
the
discussion
next
slide,
please.
So
where
could
this
be
useful?
I
think
there
are
various
ways
where
having
a
standard
traffic
mapping
model
would
be
quite
useful.
Various
AG
models
do
not
mention
this
at
all,
and
people
use
their
own
proprietary
way
to
figure
things
out
outside
of
just
e.
E
There
are
various
different
things
happening
in
ITF,
for
instance,
traffic
classification
for
service
function,
chaining
APN
buff
was
supposed
to
happen
didn't,
but
they
also
have
traffic
classification.
So
this
idea
of
having
a
way
to
identify
traffic
is
quite
important
at
various
levels
in
the
ITF,
but
we
do
not
have
a
standard
way
to
do
this
as
of
now
next
slide.
E
Now
the
issue
with
this
kind
of
mapping
would
be
that,
should
we
pick
one
I,
don't
think
so
that
would
make
sense,
because
people
have
different
requirements,
they
map
it
using
different
things.
They
will
use
different
way
to
achieve
this.
So
should
we
have
this
as
a
way
of
just
maintaining
the
various
different
ways
in
which
you
can
map?
You
can
still
create
an
ACL,
but
just
maintain
a
reference
so
that
I
could
try
to
figure
out
what
traffic
is
Flowing,
where
what
is
the
actions
being
taken?
E
E
We
don't
even
have,
for
instance,
a
flow
spec
Yang
model
as
of
now,
so
this
is
just
things
in
the
air,
but
some
of
them
we
have
ACL
model,
is
pretty
good,
saying
things
that,
whatever
traffic
that
you
receive
on
a
particular
interface,
the
things
that
we
do
for
VPN
pretty
straightforward,
we
can
directly
have
a
way
to
identify
the
sites
and
interfaces
and
port
numbers.
That's
pretty
straightforward,
so
some
parts
are
straightforward,
some
part
not,
but
this
is
at
a
high
level.
What
could
look
like
a
good
traffic
mapping
young
model?
E
Next
slide,
just
a
rough
three
of
various
things,
having
some
statistics
having
some
actions
that
could
also
be
useful
again,
keeping
it
optional
so
that
you
could
do
it
in
various
different
ways.
That's
is
proposed
here
next
slide.
E
But
the
main
question
is:
is
this
even
useful?
Basically,
the
models
have
been
developed.
People
have
been
doing
their
own
ways
this.
This
is
not
a
new
problem.
People
set
up
a
service
because
they
wanted
some
traffic
to
flow.
They
have
solved
this
problem
in
different
ways.
Maybe
we
are
too
late
and
there's
no
point
of
continuing
this,
then
maybe
this
will
be
the
last
time.
I'll
present
this
or
if
there
is
an
interest
that
this
is
useful
and
the
approach
that
we
are
taking
is
correct.
E
A
I
Yeah
Charles
I
called
Cisco
thanks
for
the
presentation,
I
think
it
was.
It
was
really
good,
also
spent
some
time
in
MEF
and
working
on
sd-wan
stuff
over
there,
and
we
had
a
similar
need
for
this.
We
didn't
see
any
kind
of
General
purpose-like
way
of
not
just
classifying
but
indicating
what
the
classification
was.
So
we
did
like
many
people
do
to
find
our
own.
It
is
a
bit
special
purpose
and
that
it's
meant
for
sd-wan
applications
where
classifying
application
traffic
as
it
comes
in
is
very
important.
I
So
what
we
did
is
we
have
a
number
of
things,
some
of
which
you
mentioned
here
based
on
IP,
address
Port
Source
destination
of
those,
and
then
we
have
kind
of
a
wild
card
of
just
you,
random
USI
and
an
application
ID,
because
so
many
people
were
using
DPI.
You
know
some
type
of
special
sauce
to
identify
traffic
and
the
key
thing
was
once
it's
identified.
I
Then
the
customer
at
the
sd-wan
wants
to
be
able
to
say
well.
This
is
how
I
want
you
to
treat
it,
or
these
are
the
important
aspects
for
it
right.
So
anyways
we
have
that
I
would
be
happy
to
help
people.
I
You
know
see
that
see
if
it
matches
your
purpose
or
fits
into
this
General
category
of
what
you're
looking
to
do
and
and
kind
of
go
from
there.
I
A
There,
okay!
So
if
you
heard
in
netmod
there
is
a
discussion
talking
about
revising
the
ACL
base
model
and
it
seems
like
there's
some
Synergy
here
and
either
you
could
do
your
work
by
further
revision
of
ACL
or
an
augmentation
of
that
new
work,
at
least
the
classification
part,
and
that
might
also
apply
to
Charles
what
you're
talking
about.
A
F
E
F
Okay,
this
was
introduced
in
itf112.
There
were
some
questions
and
comments
raised.
We
discussed
those
on
the
list.
There
was
an
update
published
addressing
those
comments
and
I'll
cover
those
changes
in
the
next
couple
of
slides,
I'm,
pawn
biram
and
I'm.
Presenting
this
on
behalf
of
my
co-authoric
Rakesh
and
shafen.
That's
right.
F
The
topology
filter
construct
was
originally
modeled
as
part
of
the
network
resource
partition
policy
data
model.
Given
its
generic
applicability,
we
published
it
as
a
standalone
module.
There
were
some
questions
about
the
scope
of
this
construct,
so
we
did
add
some
text
and
introduction
clarifying
that
it's
a
construct,
that's
used
to
filter,
Network
topologies.
It
can
be
applied
on
either
a
native
tier
where
topology
or
a
native
or
a
customized
ta,
where
topology
as
discussed
in
RSC
8795
application
of
this
on
a
topology
would
produce
a
filtered
set
of
topological
elements.
F
Topology
filter
set,
on
the
other
hand,
is
just
a
union
of
multiple
proposal
filters
that
can
be
applied
in
tandem
on
a
topology.
We
also
went
ahead
and
added
a
note
to
especially
state
that
this
is
used
for
filtering
Network
topologies
and
not
for
filtering
entries.
In
the
real
next
one
next
slide,
they
were.
There
were
also
some
comments
about
potential
use
cases
for
this,
so
we
went
ahead
and
added
a
section
describing
a
couple
of
use
cases.
One
has
a
specification
of
topology
associated
with
Network
resource
partition.
F
The
other
is
specification
of
top
of
G
related
constraints
for
Te
path,
computation.
We
did
add
a
few
examples
for
each
of
these
use
cases.
Those
are
listed
in
the
document
and
reproduced
here
on
this
Slide.
The
rest
of
the
deck
goes
over
the
model
structure.
There
hasn't
been
any
changes
to
it
since
the
time
we
presented
last
time,
so
we
I'll
not
repeat
that,
can
we
jump
to
the
last
slide?
Our
next
touch
line
the
one
before
at
this
point,
we
are
just
requesting
further
review
and
feedback.
F
This
is
a
prerequisite
for
the
NRP
policy
data
model.
At
the
point
where
we
would
claim
that
they're,
not
people's
data
model
or
the
merge
document
that
goes
alluding
to
earlier
is
ready
for
adoption.
We
will
put
in
a
request
for
this
to
be
constructed
for
adoption
as
well.
A
So
I'm
going
to
ask
the
same
well
well
in
one
moment
so
I'm
going
to
ask
basically
the
same
question:
I
asked
at
the
last
one.
There
were
some
comments
that
it
was
a
little
confusing.
So
this
is
gauging
interest,
it's
not
about
adoption
and
you
know
raise
hands
if
you're
interested
in
hearing
more
know.
If
you're
not
or
you
think
the
draft
is
going
in
the
wrong
direction
and
no
response
means
don't
care,
sorry
about
the
three
state.
But
that's
that's
our
pull
tool
and
gee.
G
Yeah
from
hallway,
actually,
my
question
is
I
think
there's
a
topology
future,
it's
mainly
applicable
to
perform
the
T
or
centralized
past
computation.
So
you
can
use
this
filters
to
as
constraints
to
for
the
controller
or
the
Ingress
node
to
compute
the
past,
but
whether
it
can
apply
to
the
distributed
past
computation
like
you
use,
can
you
apply
to
the
multi-topology
or
it
can
apply
to
the
flasago?
It
says
not
that
clear
to
me
at
a
current
moment,
so
I
think
it
can
be
clarified
further
in.
A
All
right,
we'll
give
just
a
few
more
moments
and
the
next
speaker
is
going
to
be
Greg,
so
we've
had
about
a
third
of
the
room
respond.
It
looks
like
slightly
more
are
interested
than
not,
but
we
definitely
got
some
good,
not
interested.
A
So
it's
the
room
is
mixed,
but
I'd
say
the
working
group
isn't
convinced
about
this
work,
but
still
should
hear
more.
Thank
you.
A
Are
you
I'll
switch
sorry.
J
Thank
you
for
granting
the
time
to
update
you
on
the
work
that
being
done
in
ittm
working
group
on
Precision
availability.
Metrics
in
multi-so
will
govern
end-to-end
Services
next
slide.
J
So
we
had
two
groups
of
offers
interested
in
this
problem,
and
then
we
worked
together
to
merge
this
into
one
document
and
we
had
first
working
group
adoption
Pro
in
ittm
working
group
and
in
the
meeting
earlier
this
week
we
agreed
that
the
version
of
the
document
that
reflects
comments
that
we
received
will
be
uploaded
and
their
second
working
group
adoption
poll
or
continuation
of
the
working
group.
J
Adoption
poll
will
be
announced
why
we
are
presenting
to
tears,
because
we
believe
that
this
is
important
for
traffic
engineering
and
networks.
Rising
operations
and
the
TS
working
group
has
an
expertise
on
those
topics,
so
we
hope
that
it
will
get
your
interest
and
you
will
review
this
document
and
share
your
comments,
including
on
ipt
and
working
group
list.
Thank
you
next
slide.
J
So
what
is
the
problem
since
slos
composed
of
service
level
agreement
they're
the
key
and
they
need
to
be
considerate?
In
many
cases,
just
one
violation
does
not
mean
a
lot.
J
So,
instead
of
keeping
the
history
of
all
the
measurements
of
all
the
raw
data
that
are
being
collected
for
the
given
Service,
that
can
be
aggregated
and
concentrating
on
when
the
service
is
crossing
the
threshold,
so
basically
going
out
of
their
defined
parameters
acceptable
for
this,
given
performance
metric
so
capturing
these
violations
or
asserting
the
absence
of
a
certain
conformance
to
the
SLO
is
sufficient
to
draw
the
conclusion
of
and
assess
the
quality
and
conformance
to
the
required
SLO.
J
So
there
is
analogy
between
the
service
and
system
failures
and
the
failure
is
to
be
considered
when
fail
to
deliver
to
the
required
performance
metric
next
slide,
please.
J
So
what
is
perform?
Precision
adorability
metric,
so
it
expresses
availability
of
the
service
in
accordance
with
the
performance
required
reflected,
as
is
expressed
as
a
service
level.
Objective
and
I
would
like
to
stress
because,
as
mentioned
that,
we
believe
that
this
is
very
much
applicable
to
work
being
done
in
tears
on
iitf
transport,
Network
slices.
J
We
follow
the
terminology
defined
in
Network
slices,
TS
document
and
that
both
for
SLO
s,
service
level,
expectation
and
service
level
agreement,
so
the
service
level
agreement,
because,
as
defined
and
agreed
upon
that
they
are
quantity.
Well,
there
are
some
parts
of
SLA,
but
they
are
difficult
to
measure.
So
these
are
outside
the
scope
of
this
work.
J
J
A
J
No,
that's
fine,
so
here
we
come
to
their
composing
service
and,
as
discussed
in
ITF
Network
slice
document
composite
service
might
include
connectivity
constructs,
so
e
all
constructs
may
be
assigned
for
the
same
set
of
slos
or
some
construct
might
be
assigned
a
different
sets
of
slots.
J
So
in
that
case
each
connectivity
construct
that
composes
the
service
can
be
monitored
according
to
its
own
set
of
slos,
then
are
there
Pam
for
their
composite
service
will
be
a
supposition
of
fams
of
these
sub
services
foreign.
So
if
you
have
any
questions
so
feel
free
to
sorry
well
indicate
and
I
think
the
chairs
will
bring
it
to
my
attention.
So
we
can
have
a
discussion.
I
think
that
it
will
be
better
if
I
will
go
all
and
then
we
have
to
rewind
to
the
beginning
of
the
presentation.
J
But
let
me
continue
next
slide,
please
so
applicability
where
we
think
that
we
leave
that
pan
can
be
used.
It
could
be
useful
in
a
determined
degree
of
compliance
which
service
levels
are
delivered
relative
to
predefined
slos.
And
here
what
we
envision?
J
That
interest
from
operator
perspective
and
from
subscriber
perspective
could
be
different,
for
example,
what
we
Define,
we
Define
the
violation
of
SLO
and
severe
violation,
so
where
their
violation
is
probably
more
of
interest
to
the
an
operator,
and
it
indicates
the
degradation
or
sufficient
degradation
of
the
particular
performance
metric
Crossing
some
threshold,
but
severe
violation
is
the
violation
that
crosses
the
critical
threshold
and
that
both
may
be
of
interest
to
operator
and
subscriber,
but
again
nothing
prevents
it
having
only
one
threshold,
which
is
a
critical
threshold,
so
also
fam
could
be
useful
in
providing
service
according
to
SLO
as
accounting
records
and
assess
the
quality
with
which
service
is
deliberate
and
monitor
it
continuously.
J
Next
one,
please
again,
one
of
the
foundation
elements
of
Pam
is
the
time
unit
Tamp
unit,
so
it
is
the
unit
on
which
their
particular
performance
metric
is
big,
measured
and
then
their
conformers
are
to
SLO
being
evaluated
and
expressed
either.
It's
a
violated
interval,
violation,
free
interval
or
severe
violation
interval,
an
example
of
time
interval
could
be
one
second
one
millisecond
or
to
the
liking
of
the
user.
J
The
only
is
that
requirement
and
I
I
think
it's
logical
that
time
interval
for
all
slos
that
included
in
a
given
SLA
should
be
the
same
so
based
on
this
definition,
we
Define
their
set
of
basic
metrics,
which
is
a
number
of
violation,
intervals,
violation,
three
intervals
and
severe
violation
intervals,
but
the
number
itself
probably
does
not
reflect
the
state
of
the
particular
Sol
and
service.
J
So
next
slide,
please
so
from
that
we
have
can
have
some
derived
parametrics.
That
might
be
useful
time,
since
last
violation
integral
mean
time
number
of
packets
mean
number
of
packets
and
that
are
applicable
to
both
violation
intervals
and
severe
violation
intervals.
Next
slide,
please.
J
The
availability
on
availability
of
the
service
can
be
expressed
based
on
the
state
and
because
the
state
has
to
be
sticky
so
not
to
switch.
What
we
Define
is
that
availability
or
unavailability
States,
expressed
as
a
lengthy
and
interrupted
continuous
State,
whether
it's
a
severe
violation
state
or
a
violation,
L
relation
three
intervals
consecutive.
J
So,
for
example,
it
could
be
that
10
consecutive
severe
violation
intervals
constitute
the
unavailability
state
that
began
at
the
beginning
of
the
first
interval
are
similarly
10
consecutive
none
severe
violation
intervals,
which
is
violation,
intervals
or
violation.
Three
intervals
will
constitute
a
transition
to
availability,
State
beginning
from
the
first
non-svi.
You.
J
So
we
have
some
discussion
items
and
some
future
work
out
indicated
it's
in
the
document.
We
welcome
cooperation
next
slide.
J
Of
course,
okay,
as
mentioned,
please
read:
the
document
share
your
comments
on
ittm
working
list,
I'm.
A
K
So
this
just
an
overview
on
the
motivation
of
this
draft.
As
we
know,
the
networks
are
layering
and
then
there
is
the
need
to
manage
the
the
full
Network
and
Independence
of
the
layers
and
then
I
think
a
great
job.
A
great
job
has
been
done
by
Act
mpy
applicability,
but
recently
we
see
the
new
pluggable
interface.
The
dwm
interface
is
coming
on
the
market
and
moving,
for
example,
the.
K
What
is
the
transponder
like
functions
from
the
optical
layer
to
the
IP
layer,
so
that
this
open
a
number
of
use
cases,
because
actually
a
part
of
the
optical
components
are
in
a
different
layer
than
the
optical
layer,
and
so
in
theory,
the
the
Deployable
should
be
managed
by
the
the
packet
controlling
instead
of
optical
controller.
On
the
other
side,
the
optical
controller
needs
to
know
what
kind
of
transceiver
or
what
kind
of
pluggable
has
been
fitted
in
the
router,
and
then
this
is
used
to
make
the
optical
verification
and
all
that
stuff.
K
K
To
address
this
kind
of
Network,
as
you
can
see,
we
we
are
adopting
we,
we
are
not
making
anything
new
acts.
Solution
is
the
good
one
where
we
have
an
hierarchical
controller,
which
is
a
mdsc
and
connected
to
the
hierarchical
controller.
We
have
the
packet
PNC
and
the
optical
PNC,
of
course,
in
some
way,
the
packet
PNC
and
the
optical
PNC
needs
to
share
some
information
related
to
the
to
the
pluggable.
K
Thank
you,
so
the
service
can
be
either
dco
link.
So
it's
a
pure
Optical
circuit,
if
you
want
that,
is
by
the
way
the
terminated
on
the
routers.
There
are
some
interlayer
link
to
be
defined
between
the
router
port
and
the
Rotom
ports,
and
then,
on
top
of
that
we
have
Internet
services,
IP
services
and
whatever
and
of
course,
is
a
matter
of
mdsc
to
manage
all
this
stuff
tank,
helping
the
packet
and
the
optical
PNC.
K
So,
basically,
in
the
draft
we
have
been
identified,
identify
a
bunch
of
use
cases
that
they
don't
want
to
go
one
by
one,
but
basically
the
matter
is
to
identify
the
Interlink
connections
first
and
then
each
controller,
so
domain
controller
can
share
with
the
mdsc
the
network
topology
the
layer
of
topology
and
the
mdsc
will
rebuild
the
full
Network
topology
at
that
point.
Mdsc
can
manage
and
can
drive
end-to-end
services,
or
that
can
be
done
at
IP
level,
or
can
that
can
be
done
at
Optical
layer
or
also
driver,
Restorations
and
so
on.
K
These
are
actually
described
in
details
in
the
draft.
So
I
would
like
you
to
to
have
a
look
to
the
to
the
draft
and
then
feedback
feed
the
feedback
next
one.
K
So
next
step
is
actually
to
address
the
use
case,
but
also
to
add
a
new
one
like
for,
for
example,
end-to-end,
Performance
Management,
along
correlation
and
and
not
only
this
one,
because
I
feel
there
are
many
other
use
case
to
cover
and
to
to
to
address
in
order
to,
let's
say,
help
the
the
operator,
the
network
operators
to
support
this
kind
of
network
topology.
Of
course.
K
So
we
want
to
keep
align
this
draft
with
the
the
httmp
poi
applicability
and
then
get
feedbacks
and
consensus
from
the
team,
so
especially
the
feedbacks,
because
this
is
quite
important
point-
the
technology
is
running
fast.
The
deployment
of
the
pluggable
in
the
field
is
running
very
fast,
more
than
expected,
probably
and
then
so.
We
need
to
address
this
point.
K
Last
but
not
least,
we
would
like
also
to
help
the
young
models
definition.
We
don't
think
for
the
moment
that
the
model
will
be
defined
in
this
draft,
but
we
should
identify
the
good
one
already
existing
in
other
draft
and
maybe
ask
to
the
other
draft
to
add
new
models.
Okay,
that
that's
all
thank
you.
F
Did
you
consider
putting
I
mean
discussing
this
as
part
of
the
working
group
adopted
document
just.
K
Let's
say
we
we,
as
you
know,
we
have
a
design
team
on
httmpy
I,
would
ask
the
design
team
also
to
discuss
about
this
draft
and
then
I.
Don't
know
this
is
zero
zero.
It's
a
brand
new
draft,
so
I
wouldn't
expect
to
have
now.
F
F
We
will
wrap
up
the
session
here
thanks
everyone
for
a
very
productive
session.
Here
we
will
see
you
all
in
Yokohama.
Thank
you.