►
From YouTube: IETF114-TEAS-20220725-1400
Description
TEAS meeting session at IETF114
2022/07/25 1400
https://datatracker.ietf.org/meeting/114/proceedings/
A
Hello
good
morning
for
those
who
are
remote
good
afternoon
good
evening
appreciate
everyone
being
here
physically
and
online.
We
have
some
nice
participation
in
the
room
and
some
nice
participation
remote.
Please
let
us
know
if
there's
any
audio
problems
for
those
who
are
remote
want
to
make
sure
everyone
can
participate.
Equally.
A
All
right,
let's
try
again,
is
that
good.
Hopefully,
everyone
online
can
hear
me
as
well.
I
was
saying
we
have
good
participation
in
the
room
and
remote
we're
going
to
try
to
make
it
very
equitable
for
all.
So,
if
there's
any
problem,
please
please
type
in
the
chat
for
those
in
the
room.
We
are
gonna.
Try
to
use
the
the
online
tool.
A
A
Well,
we
have
our
note.
Well
it's
the
first
meeting
for
me
at
the
this
ietf.
I
didn't
participate
in
anything
yesterday.
So
I'll
mention
it.
This
is
our
rules
for
participation.
Basically,
everything
you
say
and
do
here
becomes
part
of
our
record.
If
you're
not
familiar
with
the
notewell,
please
go
look
at
it
at
the
the
link
right
off
the
ietf
page.
A
A
A
I
think
we've
probably
hit
all
of
these
things
already,
with
the
exception
of
the
the
note
taking,
we
are
doing
collaborative
note-taking
as
we
generally
do.
The
please
jump
on
the
link
and
that's
shown
here
and
I'll
drop
it
into
chat
in
just
a
moment,
or
someone
else
will
for
me
and
help
make
sure
that
what
we
say
here
is
accurately
captured.
You
don't
need
to
capture
what
is
being
presented.
Just
the
discussion
around
the
slides
and
around
the
topics.
A
A
There
was
a
bit
of
technical
change
during
the
last
call
and
it
hasn't
hit
the
level
of
saying
we
need
a
second
last
call,
but
it's
hit
the
level
where
we
want
to
give
people
ample
time
to
respond
to
it.
I
know
I
have
one
comment
that
I
personally
haven't
gotten
to,
and
I
promise
I'll
get
to
it
this
week,
but
if
everyone
can
take
the
opportunity
of
being
here
this
week,
take
a
look
at
it.
Adrian's
here
he's
the
editor.
A
A
As
always,
we
remind
you
that
we
continue
our
working
remote
working
in
hybrid
mode.
We
have
working
group
resources
that
are
available
to
anyone
in
the
working
group
if
you're
interested
just
contact
the
chairs,
if
you,
when
you
send
it
to
the
alias
it'll,
hit
the
three
of
us
and
we
can
take
action
on
it
and
just
as
always,
it's
good
to
remind
everyone
of
our
ipi
rpr
process.
One
of
these
years,
we'll
remove
new
step.
We've
had
that
new
step
now
for
a
few
years,
so
we
should
not
call
it
new,
but.
C
C
C
C
This
is
getting
ready
for
last
call,
but
the
authors
have
stated
that
they
have
run
into
some
issues
with
respect
to
xml
validation
and
are
seeking
some
help
from
the
working
group
authors.
If
you
can
elaborate
a
bit
more
on
what
is
the
kind
of
help
you're
looking
from
the
working
group
that
you,
you
will
be
able
to
find
some
volunteers
to
help
you
with
that.
C
D
Thanks
pawan,
the
only
thing
that
I
would
like
to
say
is
like
anybody
who
has
a
good
setup
already,
especially
somebody
who's
using
t
models.
A
way
we
run
into
issues
was
not
in
our
model,
but
in
the
other
models
that
we
were
importing.
So
if
other
model
authors
who
have
already
done
this
setup,
if
they
can
provide
help,
that
would
be
the
best.
C
C
This
is
the
enhanced
vpn
framework
document.
This
has
been
around
for
some
time.
There
hasn't
been
any
new
revision
made
to
this
since
the
last
session,
but
the
authors
have
indicated
that
this
is
about
one
editorial
rev
away
from
from
them
requesting
working
group
last
call,
so
please
do
give
this
document
a
thorough,
read
and
review
it
in
anticipation
of
a
working
group
last
call
in
the
coming
weeks.
C
This
is
the
gmpls
controller
interwork
document
there
hasn't
been
any
changes
to
this
document
since
the
last
session
from
the
status
report
of
of
the
last
session,
it
doesn't
seem
like
there
are
any
open
issues
either.
So
the
question
that
we
have
for
the
authors
is:
are
there
any
pending
items
that
you
would
like
to
take
care
of
before
this
can
be
considered
for
working
with
last
call?
C
E
D
C
This
is
the
idf
network
slices
document.
As
you
all
know,
this
forms
the
basis
for
several
of
the
work.
Several
of
the
documents
that
are
currently
being
discussed
in
our
working
group
adrian
is
saying
that
we
are
ready
for
last
call.
There
have
been
several
changes
made
to
the
document
since
the
last
session,
so
please
do
take
your
time,
give
it
a
thorough,
read
and
review
it
in
anticipation
of
a
last
call
in
the
coming
weeks.
If
you
do
have
any
more
changes
to
propose
it's
not
too
late.
C
This
is
the
t
service
mapping
young
document
in
the
report
that
drew
sent.
There
is
a
comment
at
the
bottom
which
says
that
this
is
currently
blocked
by
the
essa
policy.
Young
document,
the
essa
policy
young
document,
which
was
adopted
in
spring,
hasn't
been
updated
in
a
while,
I
think
drew
did
bring
that
up
on
the
spring
mailing
list
and
there
was
a
response
from
kamran
who
holds
the
pen
that
he
would
get
to
it
soon
from
the
service
mapping.
C
Point
of
view.
All
you
need
is
some
sort
of
a
reference
to
the
underlay
tunnel
or
the
policy
onto
which
the
service
is
mapped.
This
could
be
a
direct
reference,
so
all
you
need
is
a
key
for
the
policy
or
it
could
be
some
sort
of
an
indirect
reference
where
you
use
color
or
some
tag
to
do
the
mapping.
C
C
C
There
were
several
comments
that
were
raised
during
last
call
there's
one
revision
containing
the
changes
that
for
the
items
that
have
been
addressed
on
the
list
that
should
go
in
this
week.
As
I've
been
told,
there
are
still
a
few
pending
items
and
those
should
follow
up
in
another
revision
shortly.
The
plan
is
to
have
a
a
follow-up
working
working
group.
Last
call,
maybe
a
short
working
group
last
call
to
give
the
working
group
sufficient
time
to
review
the
latest
set
of
changes
next
slide
actually
go
to
slide.
23.
C
C
There
are
a
couple
of
suggestions
more
than
one
at
least
where
a
certain
was
made
to
have
ayana
managed
identities
module
they.
This
is
turning
out
to
be
a
bit
complex
for
certain
scenarios.
It's
a
bit
impractical
as
well,
so
the
others
are
trying
to
figure
out
ways
to
address
this.
So
once
this
item
is
resolved,
there
should
be
another
revision
coming
out
and
like
with
the
last
one,
the
expectation
is
that
we'll
have
a
short
working
group
last
call
for
the
working
group
to
review
the
latest
set
of
changes.
F
F
Okay,
some
background.
Okay,
what
we
needed
the
word
discussed
was
that
we
need
to
do
some
tiny
update
to
the
itft
type-c
module,
which
has
been
already
published
in
rc8776
to
support
some
of
the
changes
on
on
the
t
tunnel
model
or
under
documents
which
are
really
for
working
group
plus
caller
at
this
moment
in
time.
What
we
need
is
just
to
define
a
new
type
death
and
a
new
grouping,
not
that
much,
and
we
were
discussing
during
last
meeting
what
is
the
best
approach
to
move
forward
with
such
a
small
update.
F
F
The
describing
coding
switching
time
and
different
opinions
were
raised
during
the
process
approval
during
the
approval
on
the
process.
Somebody
was
in
favor
of
updating.
The
rsc,
like
we
proposed
in
the
rafter
other,
were
more
in
favor
of
obsoleting
usc
8776
and
to
go
with
a
complete
visa
and,
and
the
third
option
was
also
to
define
a
new,
a
new
model
which
just
provided
the
additional
elements.
F
Another
issue
we
got
there
are
a
few
post-working
group
production
comments.
One
is
to
move
some
of
the
identities
from
the
itf
t.
Module
into
the
te
types
is
some
of
the
proposal
for
addressing
the
working
group.
Let's
call
comments
on
the
itft
yeah
model.
There
was
some
comments
from
the
on
the
photo
identifier,
and
I
received
the
comments
from
ayana.
They
did
an
early
review
and
they
agreed
they
proposed
some
changes
to
the
to
the
session.
Next
slide.
Please,
okay.
The
first
issue
is
the
technical
comment
on
the
encoding
switching
types.
F
The
opinion
is
that,
well,
the
pac
combination
rpc
has
a
strong
requirements
to
be
aligned
with
a
tea
tunnel
model.
There
were
long
extensive
discussion
at
the
beginning
of
the
work
that
everybody
agreed
on
the
importance
of
keeping
alignment
between
the
detailed
model
and
the
computational
piece
structure.
F
G
F
Okay,
thank
you.
Okay.
I
say
that
the
the
the
can
you
hear
now:
okay,
okay,
the
grouping
is
already
defined
and
the
proposal
is
to
move
it
in
t
types
to
make
it
available
to
anybody
who
needs
to
use
it.
The
microphone
is
that
there
is
no
major
if
you
keep
the
grouping
as
it
as
it
is
today
we
are
causing
the
problem
to
somebody
in
the
future
which
may
need
to
implement
just
this
grouping
and
we'll
need
to
implement
the
itft
module
just
to
import
the
grouping
moving.
F
A
grouping
here
will
not
cause
an
additional
trouble
because
it's
not
mandating
people
to
use
it.
If
you
don't
need
the
regrouping,
you
don't
need
to
use
it,
even
if
it
is
defined
in
the
itft
types.
So
we
don't
think
that
moving
the
grouping
from
the
itft
and
the
itt
types
is
causing
any
harm,
but
it
is
just
helping
the
people
if
they
need
in
the
future
and
the
real
issue
that
we
see
here
is
just
that.
F
F
The
18
already
is
defined
as
a
dot
required,
and
there
are
some
issues
in
some
deployments
where
people
would
like
to
use
the
node
id.
So
the
proposal
is
to
update
the
t
types
to
make
it
a
uni,
a
union
between
uri
and
the
existing
type,
for
example,
that
you
know
that
it
can
be
defined
as
a
union
between
the
dotted
code
and
the
uri
another
sec.
A
second
email
that
was
embraced
is
some
concerns
on
the
definition
of
the
ttp
identifier.
F
A
H
J
I
I
realized
that
you
haven't
discussed
thoroughly
this
so,
but
are
we
allowing
are
going
to
allow
a
mix
of
nodes
to
be
identified
by
different
ways?
One
is
yuri,
one
is
dotted
quad
and
in
the
same
topology,
and
that's
one
thing
and
the
other
thing
is
do
we
do
we
rely
on
parsing
the
value
to
know
that
this
is
a
dotted
quad
or
this
is
a
yuri
it's.
It
becomes
error-prone,
something
like
that,
but
but
we
can
discuss
that.
I
realize
that
you
want
to
still
yeah.
F
We
had
discussed
the
sum
of
options
and
the
issue
in
the
version
zero
one
of
the
document
and
unfortunately,
we
remove
it
from
the
for
the
document
that
was
pulled
out
from
working
reproduction,
but
we
got
a
comment
from
drew
about.
That
would
be
good
to
to
put
some
justification,
maybe
in
appendix,
since
it
is
the
first
time
we
are
doing
such
an
attempt-
and
maybe
I
I
tend
to
agree
with
him-
maybe
what
we
can
do.
We
can
bring
it
up.
F
The
key
question
that
I
found
from
the
discussion
on
this
procedural
issue
is
whether
we
think,
as
a
group,
that
we
need
to
have
a
lightweight
approach
for
updated
publishing
your
modules,
because
the
the
I
think
this
is
the
key
issue.
The
content
that
we
are
putting
into
this
document
up
to
today
is
something
which
is
quite
mature
because
it's
coming
from
working
group
documents,
some
of
which
are
in
working
group
plus
school.
F
I
One
thing
that
the
iesg
are
trying
to
do
is
for
business
with
you
know,
sort
of
well-contained
small
change
sets
is
to
only
review
the
well-contained
small
changes
and
not
take
it
as
an
opportunity
to
do
a
you
know,
open
season
on
reviewing
the
whole
entire
document
and
reopening
past
issues,
so
we
can
discuss
further
offline,
but
I
would
encourage
you,
you
know,
for
documents
that
have
small
change
sets
if
you're
trying
to
decide
what
to
do.
Please
talk
to
me
before
deciding
that
it's
just
not
a
good
option.
F
A
F
F
Okay,
I
think
you
can
skip
the
next
slide.
No,
no,
I
think
we
can.
We
can
follow
up.
The
suggestion
from
john
looks
like
a
good,
a
good
solution,
okay,
so
the
next
steps
is
to
move
forward
with
addressing
the
technical
and
procedural
comments,
and
then
we
need
to
align
the
working
group
which
are
using
these
new
types.
F
A
A
F
Okay,
a
quick
recap:
okay,
this
document
is
analyzing
the
applicability
of
the
itf
yam
modus
between
the
mdsc
and
the
optical
packet
psc's
to
disk
to
support
the
packet
of
the
integration
in
case
of
multi-domain
packet
and
multi-domain
optical
network.
The
use
cases
that
have
been
analyzed
are
inventory
service
and
topology
discovery.
In
particular,
they
multi
the
link
between
routers
and
the
rodents
and
the
discovery
of
all
the
optical
and
eye
packet
parts
and
how
it
is
possible
to
establish
the
two
vpn
which
traffic
engineering
requirements.
F
What
has
been
changed?
Okay,
we
did
some
updates.
We
are
generalized.
The
description
of
the
srt
part
discover
pad
discovery
is
a
type
of
update.
This
was
a
a
comment
we
received
during
the
last
itf
presentation,
and
we
discussed
that
on
the
main
list.
So
we
made
a
description,
generic
and
applicable
to
any
technology
that,
for
which
the
t
tunnel
model
can
be
used
at
the
mpi
above
the
packet
controller.
F
F
We
think
that
instead,
the
interdomain
option
of
bgplu
is
considered
oscilloscope,
because
that
that's
case
that
the
t
tunnel
mode
seems
not
applicable
and
the
solution
is
slightly
different
and
we
decided
not
to
go
into
too
many
options
to
analyze
into
the
draft.
If
interesting,
we
can
set
up
a
new
draft
if
there
is
a
need
for
analysis.
F
An
additional
change
that
we
did
on
this
revision
is
that
we
added
the
analysis
for
the
lag
link
aggregation.
So
how
to
discover
and
set
up
and
update
the
lag
in
case
of
intra
domain
links,
so
links
between
two
routers
in
the
same
domain
with
some
optical
path.
Underneath
of
it,
we
didn't
discuss
the
analyze.
The
intel
domain
lag
because
in
this
case
there
is
no
multi-layer
coordination.
So
it's
not
of
interest
of
a
multi-layer
analysis.
F
F
So
the
one
cent
on
the
lag
members-
and
there
are
two
suggestions
in
the
draft
once
the
suggestion
graph-
is
to
disable
the
lag
on
the
aggregated
ports.
So
the
red
ledp
packets
will
not
be
generated
by
the
router
not
seen
by
the
rodent,
and
everything
will
work
in
the
discovery
as
if
there
is
no
lag.
F
There
are
other
methods
we
found,
for
example,
in
the
standard.
There
is
a
definition
of
the
link
aggregation
tlv,
they
may
be
used,
but
some
care
has
to
be
taken
to
make
sure
that
the
router
and
the
rotor
of
course
supports
those
options,
because
in
this
case
you
need
to
be
able
to
distinguish
on
the
road
and
side
which
lldp
packet
belongs
to
which
session
and
use
only
the
black
llp
packets.
For
the
discovery
next
slide,
please
and
the
multi-domain
I
introduce
the
procedure
has
been
slightly
updated
because
the
first
threats
are
the
same.
F
F
As
soon
as
you
create
this
configuration
the
optical
domain,
you
have
any
any
an
internal
link
between
the
two
routers,
which
this
link
can
be
either
discovered
by
the
packet
psc.
If
there
is
some
methods
like
ldp
or
proprietary
mechanism,
or
if
this
mechanism
is
missing,
it
can
be
configured
by
the
mdsc
in
the
previous
version
without
lag,
the
configuration
the
configuration
or
the
quiz
cover
of
this
link
was
sufficient
to
trigger
the
configuration
of
the
ip
link
over
it.
F
But
now,
with
the
lag
you
still,
the
the
packet
pnc
doesn't
know
whether
this
link
has
been
created
to
become
an
ip
link
or
to
become
a
member
of
a
lag.
So
we
change
a
video
procedure
to
to
enable
the
mdsc
to
explicitly
tell
this
to
the
pnc
and
the
what
we
we
consider.
We
take
leverage
the
fact
that
the
ip
topology
is
rewrite,
so
the
mdc
can
create
the
link
between
the
routers
over
this
ethernet
link,
and
this
will
trigger
the
packet
pnc
to
configure
it.
F
The
the
configuration
of
the
link
is
still
done
by
the
packet
pc,
but
the
trigger
is
now
the
creation
of
the
link
in
the
epi
topology
by
the
mdsc.
If
there
is
the
lag,
there
will
be
a
different
procedure
to
add
the
link
to
the
lagrange
next
slide.
Please,
okay,
now
we
have.
We
have
some
open
issues.
We
are
tracking
them
on
on
github.
F
F
F
C
They
I
mean
the
guidance
given
at
that
point
was
to
describe
the
procedures
in
a
technology
agnostic
manner
and
then
bring
in
sr
specific
examples
or
rsvp's
basic
examples.
Where
there's
a
deviation,
I
I
do
see
that
there
has
been
a
conscious
effort
to
address
some
of
that,
but
it's
nowhere
near
done.
At
least
that's
that's
my
opinion,
and
I
believe
my
co-author
is
also.
My
co-chair
is
also
agreeing
with
me
on
that.
So
that's
something
that
you
would
have
to
keep
addressing,
as
the
document
evolves.
F
C
C
B
B
The
changes
in
the
latest
revision
is
outlined
here,
I'm
not
going
to
cover
you
know
all
the
bullets
here,
it's
self-explanatory,
but
overall
we
align
the
stp
connectivity
construct
that
we
have
attachment
in
the
young
model.
With
the
draft
with
the
framework
we
try
to
be
aligned
with
everything
that
we
have
on
the
framework.
B
We
also
included
some
of
the
reusing
of
the
common
model
that
we
have
vpn
and
so
forth.
We
also
aligned
some
of
the
choice
for
the
young
model
in
the
for
the
values
connectivity,
the
services
that
we
have
point
to
point
point
to
multipoint
and
any
to
any.
These
are
all
the
types
that
define
in
the
framework,
and
we
put
lots
of
examples
thanks
to
john.
B
He
provided
john
lots
of
examples
that
clarifies
what
the
model
is
and
how
we
are
going
to
use
it,
and
there
are
some
other
aspects
about
the
dscp
and
match
and
we
try
to
you
know,
add
more
clarity
to
the
yang
model.
The
last
bullet.
We
remove
5g
example
that
we
have,
because
we
have
another
drive,
I'm
going
to
present
at
the
shortly
about
application
of
the
nbi
and
generally
it
network
slice
in
5g.
B
From
that
reason,
we
remove
it
from
here,
and
we
added
that
now
there
are
few
issues
that
I'm
going
to
discuss
that
are
open
issue
that
we
have
and
if
you
go
to
the
next
slide,
the
in
general
to
just
have
the
baseline.
Here
we
put
six
different
ietf
network
slices
in
this
picture
network
slice,
one
all
the
way
to
six
with
the
various
connectivity
that
we
can
have.
B
We
can
have
point-to-point
point
to
multipoint
n2ne,
and
we
put
those
examples
here
just
to
have
a
baseline
and
clarity
that,
generally
speaking,
the
connectivity
construct
has
one
direction
which
is
specific
so
low.
It
can
belong
to
a
group
connectivity
group.
So
a
group
has
multiple
connection
potentially
with
the
different
slo,
and
this
is
the
idea
that
we
go
after
again,
this
is
aligned
with
the
framework
document
that
we
are
based.
B
If
you
go
to
the
next
slide.
The
first
issue
that
we
are
going
to
this
open
issue
is
about
the
policy
slo
sle
policy.
As
you
see
in
the
model,
at
the
beginning
of
the
model,
we
have
the
policy.
This
policy
is
defined
in
the
three
different
areas
at
the
network,
slice
layer
at
the
group
layer
and
the
connection
layer.
The
question
here
is:
do
we
need
to
have
an
ability
to
first
of
all
configure
this
policy
as
a
model,
or
this
should
be
part
of
it
should
be
outside
of
the
model?
B
So
this
is
one
aspect,
and
another
aspect
is
so
so-called
inheritance
and
update.
If,
for
example,
we
want
to
create
a
itm
network
slice
with
the
well-known
gold
policy-
and
somebody
says-
oh,
I
want
that
gold
policy,
but
by
the
way
I
want
to
just
change
one
attribute
of
that
should
should
we
allow
that
how
we
should
do
it?
Do
we
rewrite
everything,
or
do
we
specify
that
a
specific
attribute
that
inheritance
and
update
comes
from
that?
B
So
basically,
the
first
issue
is
policy,
related
creation
of
the
policy
update
and
inheritance,
and
this
is
the
still
under
discussion
that
we
have
a
weekly
meeting
about
this
one
and
more
than
happy
to
hear
everybody's
idea
about
this
one
and
what's
the
best
way
to
handle
it
next,
please,
the
second
one
is
the
right
now
at
the
match.
I
criteria
that
we
have.
B
We
are
specifying
match
and
value,
and
the
question
is:
if
you
want
to
have
a
complex
combination
of
the
ip
header
for
the
match,
should
we
allow
this
or
not,
and
if
you
want
to
do
it,
is
this
reasonable
to
use
acl
type
of
the
reference
here,
and
there
is
a
pros
and
cons
obviously,
but
this
is
an
open
issue
that
that
adding
that
acl
might
help
here.
But
again
we
need
everybody's
the
opinion
about
that
one.
B
The
summary
of
this
one
is,
if
you
take
a
look
at
the
bottom
left
picture,
we
have
stp
today,
stp
peri,
which
has
two
area
protocol
and
opec
generally
speaking,
the
idea
here
is:
we
want
to
be
quote
unquote:
technology
agnostic
from
that
aspect,
we
define
a
group
of
attribute
types
and
value
from
that
aspect.
We
didn't
try
to
two
examples
is
in
the
middle
picture,
for
example,
for
the
aesthetic
routing
or
bgp,
but
we
on
purpose
we
didn't.
B
B
If
for
the
interoperability
issues,
if
we
have
these
two,
the
yank
could
have
some
intra
ability
and
we
need
some
proposal
and
the
feedback
from
the
young
doctors
and
working
group
to
see
what
is
the
best
way
to
handle
it.
What
is
the
balance
to
put
something
specific,
but
at
the
same
time
we
keep
the
idea
of
the
technology
as
agnostic
idea
here,
and
this
is
just
I
bring
it
up
to
make
sure
we
are
all
aware
of
that
and
if
there
is
any
proposal-
and
I'm
sure
this
is
not
the
first
time
happened.
A
Yeah
in
other
models-
I
don't
remember
off
the
top
of
my
head
which,
but
I
can
find
it,
what
we've
done
is
added
a.
I
believe
it
was
a
choice.
Actually
it
doesn't
matter
the
specifics.
We
added
a
place
where
for
future
augmentation
for
technology,
specific
augmentation,
so
rather
than
putting
an
opaque
value,
you
put
a
a
place.
I
think
it
was
a
choice
statement.
Do
you.
B
B
So
there
was
some
discussion
about
adding
to
the
model
as
an
the
idea.
Some
type
of
the
topology
of
the
network.
This
is
quote
unquote
similar
to
the
the
v2
child
type
2
vn
that
is
specified
is
hctn.
There
was
some
discussion
that
it
might
be
needed,
but
the
general
question
that
we
have
is
this
something
that
we
want
to
do
because
again
we
don't
want
to
remove
that
technology,
agnostic
concept
from
the
model
and
the
question
is:
do
we
need
to
do
that
one?
B
And
if
the
answer
is
yes,
we
have
to
do
that
one.
We
can
add
some
type
of
the
the
similar
type
to
we
end
in
the
model.
But
at
this
point
we
want
to
make
sure
the
question
is:
do
we
need
it?
Yes
or
no?
And
if
the
answer
is
yes,
we
are
going
to
continue
going
forward
and
I
think
the
last
slide
is
going
to
give
us.
Okay,
there
was.
Is
this
okay?
I
thought
there's
a
five
issue.
C
Regarding
the
issue,
four,
I
think
it's
useful.
I
think
it's
useful
to
let
the
client
know
what
abstract
topology
is
available
before
the
service
is
being
made.
I
I
know
there
this.
This
ask
has
been
around
for
a
while,
like
I
think,
even
before
we
adopted
there
were
some
examples
for
it
and
it's
it
keeps
coming
back,
so
I
think
it
it
it
is.
C
J
Okay,
thank
you.
My
name
is
tarek
saad
and
I'm
going
to
give
an
update
on
this
draft
yang
data
model
for
network
resource
partition
policy.
We
have
presented
this
draft
multiple
times
in
the
past,
and
this
is
just
going
to
concentrate
on
the
on
the
changes
introduced
in
this
revision
next
slide.
Please.
J
J
There
were
multiple
modes
identified
for
nrp
for
network
resource
partitions
in
the
network.
One
was
partitioning
in
the
control
plane,
another
one
in
the
data
plane
and
the
third
mode
was
when
partitioning
is
happening
in
both
control,
plane
and
data
plane.
This
yank
data
model
will
cover
all
three
flavors.
J
J
The
topological
elements
that
match
such
membership
criteria.
The
filters
can
be
used
for
different
different
purposes.
One
is
overriding
reservations
on
select
elements,
but
there
are
multiple
variants
of
filters
that
one
can
use
and
as
a
result
of
filters,
there
will
be
network
elements
that
match
the
filter
and
the
the
set
of
network
elements.
That
of
topological
network
elements
that
match
the
filter
will
be
displayed
under
filtered
topology.
J
We
have
two
choices
of
ways
to
this:
to
to
describe
this
filter.
Topology
one
is
just
a
reference
to
a
topology
that
we
create
for
the
network
topology
elements
that
matched
the
filter.
The
other
is
to
just
reference
the
topological
elements
in
the
native
topology
as
they
are.
We
just
have
pointers
to
them,
and
the
latter
we
just
have
two
references.
One
is
the
network
reference
of
the
physical
topology,
for
example,
and
the
topological
element
key
node
or
link.
J
In
terms
of
next
steps,
we
we
have
engaged
with
authors
of
draft
wdt's,
nrp
yang.
We
believe
it
it
has
some
resemblance
and
we
are
working
with
them
and
finding
ways
to
collaborate
with
them.
So
we
look
forward
to
to
continue
this
collaboration
and
the
second
next
step
item
we
have
is
to
add
some
three
instances
of
the
data
model
in
json,
for
examples
on
network
controller
and
on
the
device
and
as
usual,
we
welcome
requests.
Sorry,
we
welcome
reviews
from
the
working
group
and
as
well
as
any
feedback.
K
J
Hi
adrian
thanks
for
the
question.
What
we
mean
by
control
plane
only
is
that
the
reservations
are,
or
the
bandwidth
bookkeeping
is
being
done
either
on
the
controller
or
on
the
network
element
as
a
vis-a-vis
rsvp
way.
So
the
call
admission
module
is
sitting
on
the
node
or
on
the
controller,
indeed
it's
possible,
but
but
the
idea
of
that
reservations
are
managed
and
maintained,
maybe
by
priority
order
on
that
reservation
manager
and
not
in.
C
L
A
D
M
M
M
The
concept
naruto
slicing
was
firstly
defined
in
the
cgpp
and
they
only
covered
the
ram
and
the
mobile
car
network,
slides
some
nets
and
for
the
transport
part
of
the
end-to-end
number
slice
item,
number
slice
is
going
to
be
used
to
provide
end-to-end
slicing
and
the
performance
guarantee
in
the
idf
network
slice
framework
draft.
It
describes
the
concept
and
the
general
framework
of
the
itm
network
slice,
and
it
also
mentioned
that
the
metal
slices
can
be
realized
by
mapping
one.
M
So
here
is
a
typical
ietf
and
that
end-to-end,
I
cannot
slice
scenario.
This
is
using
the
functional
slice
as
the
example
in
the
transparent
network
segment.
One
or
multiple
five
general
slices
can
be
mapped
to
an
itunes
slice,
and
this
realization
could
be
enhanced.
Vpn
service,
the
in
the
enderly
network,
the
itm
natural
slices
can
be
mapped
to
can
be
supported
by
a
multi-domain
nrp,
which
is
achieved
by
concatenation
of
multiple
intra-domain
rp's.
M
This
mechanism
is
so
similar
to
the
intro
into
domain
vpn
cases.
So,
as
shown
in
this
picture,
we
can
have
three
tn,
transparent
net
domains
and
each
domain.
How
well
multiple
nrp
is
provided
and
the
concatenation
of
the
different
intradomain
nrps
in
the
domains
provide
a
multi-domain
rp
to
support.
The
end-to-end
item
number
slide
service.
C
H
Yeah
hi
drama,
lulu,
cisco
back
on
the
previous
picture,
you're
concatenating,
nrps
or
shouldn't.
We
really
be
concatenating
ietf
network
slices
per
transport
domain.
I
mean
that
would
be
a
more
modular
cookie-cutter
approach
than
trying
to
do
this
at
the
nrp
level.
Plus,
you
might
have
different
policies
between
different
networks,
so
just
asking
about
how
the
how
the
problems
being
tackled
in
this
case.
M
H
M
Yeah
yeah,
I
agree
that
is
going
to
be.
That
scenario
can
also
be
covered
in
the
future
versions,
and
here
we
are
mostly
talking
about
the
concatenation
of
the
nrp's
to
build
an
end-to-end
slice
service.
Thank
you,
okay.
Let
me
continue
so
the
encapsulation
of
the
multi-domain
rp
information
with
different
data
plane
are
specified
in
the
following
documents
and
I
will
not
go
into
the
details
of
this
encapsulations.
Please
go
and
do
it
read
this
draft
and
give
feedback?
Thank
you.
M
In
this
hierarchical
network,
slash
draft,
we
may
describe
some
considerations
about
the
realization
of
the
hierarchical
network
slides
in
different
network
planes,
including
the
forwarding
plane,
the
data
plane,
the
management
plan,
the
control
plane
for
the
forwarding
plane.
It
is
mainly
about
how
to
partition
the
resource
hierarchically
and
how
to
represent
the
hierarchical
partition
resource
to
the
network,
linked
like
the
at
the
link
level.
So
we
have
different
options
to
represent
the
hierarchical
resources,
and
this
we
have
different
impacts
to
the
control
plan
and
management
plan.
M
We
have
also
several
options
of
this
nrp
identifier.
In
the
data
plane
like
we
can
use
a
unified
identifier
for
both
for
different
levels
of
nrps
or
we
can
have
a
hierarchical
identifiers
to
identify
the
different
levels
with
a
different
segment
of
the
identifier.
This
will
also
have
different
impacts
to
the
data
plane.
M
For
the
control
plane,
I
think
the
challenge
is:
we
need
to
use
control
plane
to
distribute
the
attributes
of
different
levels
of
the
hierarchical
energies,
both
among
the
network
nodes
and
also
to
the
controller
with
the
number
of
the
hierarchical
natural
slice
increases.
The
control
plane
optimization
would
be
need
to
be
considered.
M
M
A
It's
not
too
late
to
get
text
into
the
framework,
it's
much
better
to
get
it
into
an
existing
document,
particularly
one
that's
about
to
go
out
the
door
than
to
have
standalone
documents
that
we
have
to
run
the
process
on
so
for
both
of
these
documents.
If
there's
an
opportunity
to
take
the
text
and
put
it
into
another
document,
please
do
so
and
preferably
a
existing
working
group
document
and
the
best
way
to
do
that
is
send
the
text
to
the
list.
Talk
to
the
authors.
A
M
C
O
O
O
O
First,
just
as
mentioned
just
know
by
previous
present
presentation,
the
concept
of
the
hierarchical
item
network
slices
is
based
on
the
ietf
terminologies
network.
Slicing
itf
network
slides
and
network
resource
partition.
The
hierarchical
hf
network
slices
describe
the
network
slices,
which
can
be
further
sliced
or
combined
hierarchically.
O
O
The
level
1
bandwidth
is
guaranteed
by
a
layer,
three
step
interface
with
dedicated
bandwidths
and
the
prefix
seed
or
srv6
locators
is
used
at
the
data
plane.
Identifier
and
the
level
two
bandwidth
is
guaranteed
by
pure
with
dedicated
bandwides
under
the
layer,
3
sub
interface
and
the
rpid
is
used
as
the
data
plane.
Identifier.
O
I
think
it's
much
more
complicated
for
launch
nrp
to
be
mapped
to
multi-slicing,
and
it
makes
little
sense
since
the
resources
of
the
level
2
is
already
finally
divided.
So
here
the
level
2
nrp
to
slice
is
shown
as
one
to
one
also.
We
think
if
there
is
the
requirement
scenario
that
this
can
also
be
one
two
multiple.
O
One
is
for
the
education
slice
and
the
other
is
for
the
health
care
slice
for
education
slice.
There
are
two
customers,
for
example
university
one
and
the
university
too.
They
all
have
different
access
points
and
interconnection
for
health
care
slice,
the
slice,
the
second
slice.
There
is
only
one
customer.
O
Based
on
the
topology
about
the
resource,
partition
is
like
this
taking
p
e
one,
as
example,
the
physical
interface
one.
There
will
be
two
sub
interfaces
and
under
which
there
will
be
two
or
one
queue
respectively
for
physical
interface
2.
There
will
be
only
one
sub
interface
and
one
queue
under
the
sub
interface
and
all
the
sub-interfaces
and
the
cues
are
associated
with
the
dedicated
panel-wise.
O
The
last
picture
illustrates
the
traffic
forwarding
from
the
picture.
We
can
see
that
the
final
result
is
that
for
the
normal
education
traffic
for
the
first
slides,
the
packet
is
encapsulated
by
the
destination
of
understated
associated
with
the
specific
flex
algo
and
the
traffic
is
forwarded
through
the
layer,
3
step
interface
and
for
the
specific
traffic
coming
from
university
1
to
university
2,
the
encapsulation
except
the
activistics
header
and
srh
also
includes
additional
nrp
id,
and
the
traffic
is
before
they
just
shoot.
The
kill
under
does
that
interface.
O
C
O
C
P
C
P
P
Okay,
here
this
is
a
brief
background,
because
we
know
we
have
this
draft
to
describe
the
concept
and
the
general
framework
of
ietf
network
slides,
but
now
with
the
development
and
the
deployment
of
iti
itf
network
slides
in
different
types
of
network
for
different
applications,
there
are
emerging
requirements
about
the
new
capability
and
the
functionality
of
itr
network.
Slides
is
expected
that
the
concept
ietf
network
slice
and
the
network
resource
partition
will
be
generalized.
P
So
in
the
data
plane,
the
rp
specific
identifier
could
be
used
to
determine
the
topology
and
the
resource
of
the
nrp
for
packet
processing.
But
we
know
now
that
we
have
this
one
dropped
proposed
in
six
months.
Working
group-
that's
the
that's!
This
is
the
draft
to
describe
how
to
use
the
ipv6
to
carry
the
multiple
topology
id
for
the
idp,
multi
topology
or
the
igp
flexa
ego,
because
this
is
used
to
cope
with
the
user
cases
that
the
sim
forwarding
addresses
could
be
reused
for
packet
in
different
topology.
P
The
second
one
I
mean
the
nrp
is
allocated
with
a
set
of
forwarding
plane
network
resource
to
guarantee
the
sre.
That
means
os
sr,
sro
etc,
but
now
because
as
the
development
of
the
rp,
so
the
scope
of
the
rp
resource
may
be
extended
to
cover
other
types
of
resource
here.
I'll
give
these
the
several
examples,
the
first
the
resources
need
to
be
provided,
guaranteed
latency
for
that
net
service.
P
All
this,
the
resource
can
be
used
for
some
network
function
of
the
nrp,
for
example
the
security
functions,
and
also
this
is
the
result.
It
can
be
the
virtualized
resource,
maybe
that's
the
virtualized
device
to
support
the
ietf
network
slides.
So
here
we
have
the
two
questions:
the
first
one.
What
should
be
the
relation
between
the
data
net
and
the
ietf
network?
P
So
here
we
also
have
this:
the
rp
for
multiple
connective
constructs.
So
here
we
give
the
example
for
the
virtual
list
of
the
line
service.
So
we
we
can
say
that
the
virtual
listed
line
can
be
mapped
to
the
nrp,
so
it
can
be
one
to
one
it
can
also
to
map
or
share
the
rp.
But
here
we
give
the
example,
because
here
we
can
see,
there's
a
truly
center
line,
which
is
the
two
gigabit
the
bandwidth
respectively.
P
H
P
I
finished
this
one:
it
just
lost
the
page.
Okay,
so
here
are
these
also.
This
is
the
this
means
that
the
itr
network
slides
may
be
also
used
for
the
various
ip
tunnels.
Besides
the
npr's
and
the
srv6
tunnels,
I
mean
the
vxlan
or
the
gre,
so
here
we
have
this.
The
generic
ipv6
tunnel
work,
that's
for
the
network,
slicing
used
for
other
tunnels,
okay,
so
here
these
are
the
questions,
so
we
would
like
to
solicit
the
feedback
and
also
try
to
reach
the
consensus
and
revise
this
document
accordingly.
P
G
This
is
louie
jaleel,
so
I'm
noticing
that
you
for
some
reason
it's
more
the
way
you're
presenting
is
more
static,
resources
and
dedicated
resources.
You
know
you
keep
looking
for.
I
know
we're
allocating
partitions
all
this
other
stuff,
but
it
looks
like
it's
more
static
and
hardened
than
being
more
dynamic.
That's
what
I'm
seeing
just
overall
from
your
slides!
Is
that
correct,
or
do
you
see
it
differently.
P
I'm
not
sure
if
you
I
catch
you
all
these.
The
point
very
well,
but
here
these
are
just
this.
Some
of
these
the
issues
about
means,
maybe
the
rp,
the
resource
you're,
not
the
bandwidth
resource
for
the
sre,
but
the
user
can
be
used
for
the
topology
represent
topology,
or
maybe
the
security
service,
etc.
Yeah.
C
B
Good
morning
again-
and
this
is
rosario
from
siena
on
behalf
of
my
co-authors-
I'm
going
to
present
application
of
ip
ietf
network
slice
in
5g
network
slice
next
slide
just
a
quick
background.
If
you
are
looking
at
the
picture
on
the
right
right
hand,
side
this
taken
from
the
framework
document,
there
are
various
applications
or
use
cases
for
itf
network
slides.
There
are
clearly
mentioned
in
the
framework
document
you
can
use
the
concept
of
itm
network
slides
to,
for
example,
do
the
connectivity
in
data
centers
or
the
whole
sales,
and
so
on.
B
B
Currently
there
are
three
drafts
which
are
talking
about
various
application
of
the
network
slicing
in
the
context
of
5g.
You
will
see
these
three
drafts,
a
different
area
of
that
is
discussed
as
in
the
previous
ietf,
the
chair
asked
if
we
can
combine
all
those
drafts
and
have
a
new
draft.
So
basically,
today's
discussion
is
combination
of
three
drafts
in
a
single
draft
to
address
various
applicability
and
use
cases
of
itm
network
slice
as
a
general
concept
or
solution
in
very
specific
use
case
is
5g.
B
So
having
that
in
mind,
if
you
go
to
a
next
slide,
it
shows
the
what
has
been
done
at
the
very
top
layer,
very
the
higher
layer.
We
mesh
three
documents.
We
just
don't
merge
them,
but
we
add
new
content
to
it
as
well.
So
we
consider
some
of
the
progress
that
happening
on
the
3gpp
541,
which
is
the
the
management
of
the
network
modeling.
B
We
also
added
a
use
case
for
that,
an
example
for
that
and
keep
in
mind
that
this
document
is
still
in
progress,
but
the
overall
is
we
are
basically
merging
those
three
documents
as
a
whole
and
if
you
go
to
the
next
slide,
it
shows
the
skeleton
of
the
brand
new
document
we
have
started
at
the
beginning
and
there
is
no
need
for
me
to
go
through
each
item
one
by
one,
but
suffice
to
say
that
we
already
cover
as
an
outer
of
those
three
draft.
We
cover
chapter
one
two:
three.
B
We
went
through
that
as
a
one
cycle.
After
the
revision,
we
are
still
doing
it
other
chapters
and
we
are
today
I'm
going
through
this
chapter
to
show
the
overall
structure
of
the
document
and
the
seeking
you
know,
advice
and
the
contribution
from
everyone.
So
if
you
go
to
the
next
slide
and
starting
from
starting
from
the
beginning,
this
is
simply
the
framework.
B
There
are
values
connectivity
happening
inside
the
run
inside
the
core
or
between
them.
Those
red
area
that
you
see
is
connectivity
and,
as
you
see,
5g
network
slicing
it
addressing
the
connectivity
from
that
aspect.
The
use
case
that
we
have
here
is
there.
Our
tn
transport
network
connecting
values,
component
network
function
in
different
areas
and
the
role
of
the
ietf
network
slice
is
how
we
can
address
that
for
any
an
example.
If
you
go
to
the
next
slide,
it
shows
a
second
level
of
detail,
for
the
examples
depends
on
the
rand
deployment.
B
When
we
talk
about
run
deployment
there,
there
are
three
rand
deployment
in
general,
distributed
red,
centralized,
run
and
cloud
ran
without
going
through
the
detail
of
that.
The
difference
is
how
the
component
of
the
radio
access
network
are
connected
together.
Are
they
everything
is
one
network,
the
one
component
we
have
or
we
are
separating
that
one
into
the
so-called
centralized
unique
or
the
distributed
unit,
and
this
is
a
cu
and
du.
I'm
sure
you
heard
about
this
acronym
few
times,
but
the
idea
here
is
this
picture.
B
B
There
are
components,
radio
unit
du
cu
and
core,
and
there
are
different
connectivity
that
ins
underscore
one
or
two
and
so
on.
It
shows
the
multiplicity,
and
the
idea
here
is
a
single
end-to-end
network.
Slice
from
5g
perspective
might
have
multiple
iot
of
network
slots,
and
this
is
the
idea
of
the
whole
picture.
You
can
go
through
the
detail
in
the
draft
to
see
more
so
I'm
running
out
of
time.
I
have
to
hurry
up
a
bit
next
slide.
B
This
one
shows
the
from
the
left
picture
to
the
right.
We
have
itf
network
slice,
controller,
okay,
yeah
sure
so
open
issue.
Theory,
first
about
the
terminology
that
we
use
here.
In
a
specific
should
we
use
5g
end-to-end
network
slides
or
we
remove
that
end-to-end
because
from
the
perspective
of
the
3gpp,
when
they
talk
about
network
slides,
inherently
they're
talking
about
5g,
and
they
are
talking
about
end-to-end,
they
never
talk
about
these
two
explicitly.
B
So
the
first
question
is:
should
we
use
or
should
we
keep
end-to-end
the
next
one
is,
should
we
use
access
network
or
in
a
specific
radio
access
network
so
because,
again
from
the
mobility
is
radio
access?
So
we
feel
that
that,
for
this
question
should
be
ready
access
network.
But
we
are
open
to
any
question
that,
since
you
go
to
3gpp
document,
you
will
see
a
n.
You
don't
see
a
radio,
a
and
radio
access
network
next
slide.
B
N
B
N
N
My
proposal
is
to
use
5g
network
slides,
so
the
first
point
is
about
3gpp
has
no
5g
n2
and
network
slides
and
and
to
a
network
slice.
Scope
is
out
of
3gpp,
because
the
connection
between
upf
to
dn
is
out
of
the
3gpp
network,
slice
scope,
and
the
third
point
is
about
bbf
tr522
use,
5g
network
slides.
We
also
discussed
this
question.
You
know
to
use
5g,
n2
and
network
slides
or
5g
network
slides
our
agreements
as
to
use
5g
network
slides.
N
G
Yeah,
no
and
I'll
just
make
a
comment.
I
won't
drag
it
remember
we're
not
just
offering
networks
license
to
5g
there'll,
be
other
access
networks,
even
broadband
and
everything
else.
If
you
make
it
specific,
if
you
make
it
specific
to
5g,
you'll
have
to
spend
another
one
when
we
start
talking
wireline
other
services.
So
that's
one-
and
this
is
to
me-
looks
like
a
mapping
draft,
not
treatment.
G
Q
Very
soon,
I've
seen
many
documents
who
underplayed
transmission,
like
transport
network,
is
part
of
the
slicing
story.
So
this
is
a
good
document
and
I
definitely
agree
that
having
transportation
network
in
the
picture
and
having
the
end
to
end
is
implicit
is
definitely
very
good.
So
I
support
that.
M
R
R
So
basically,
the
idea
here
the
overall
goal
and
approach
was
that
assess
it
to
what
extent
atf
network
slash
can
be
implemented
using
current
ipms
technologies,
so
which
means
if
we
have
current
network
running
and
operator,
and
the
operator
would
like
to
introduce
5g
services
on
this
current
network
with
minimal
change.
What
the
operator
can
do
in
in
order
to
introduce
5g
services
and
provide
kind
of
reference
document
kind
of
blueprint
blueprint
to
approaches
to
the
slices
with
such
technology.
R
So
what
needs
to
be
configured
what's
in
video
plate,
orchestrated
and
so
on,
and
then
approach
our
approaches
rather
than
generic
climbs.
We
pick
a
specific
deployment
context,
which
is
the
5g.
The
s5g
is
the
most
most
promising
context
here
for
slicing.
That's
the
reason
we
pick
5g
as
an
example
for
that
next
slide.
R
And
because
this
is
concentrating
on
5g,
we
are
using
terminology
that
is
using
the
5g
when
we
convert
slicing
so
run
cntn,
so
core
network
transport
network.
It
means
we
are
talking
about
transport
network
slicing
and
when
we
talk
about
transfer
network
slices
and
transfer
slices,
we
refer
to
itf
network
slice.
Basically,
but
we
are
concentrating
on
the
5g
terminology,
so
in
5g
worlds
they
are
calling
it
transport
slice
next
slide,
please.
R
So
what
we
have
in
this
document
so
first
is
overview
of
5g
networking.
This
is
for
for
generating.
You
know
transport
engineers
to
understand
more
or
less
about
5g
a
different
kind
of
methods
between
the
run,
cn
and
transport
network,
so
how
we
handle
the
traffic.
What
is
the
cooperation
here
between
these
domains
to
the
transport
network?
R
How
do
we
realize
the
transport
of
5g
slices
using
current
ipmps
technologies
in
order?
You
know
for
brand
field
deployments
existing
network
aligning
them
5g
concept
of
5g
deployments,
with
the
current
deployments
that
we
have,
for
example,
business
services,
wholesale
smallers
that
we
are
currently
deployed
and
so
on.
R
Then
we
touch
very
close
about
the
transmitter,
slicing
qs
models
and
we
defined
here
the
two
models:
a
5k
aware,
underwear
and
5k
of
our
model,
and
we
talked
about
capacity
planning
management.
So
basically,
the
idea
here
is
that
we
use
capacity
planning
for
for
a
traffic
isolation.
Next
slide.
Please.
R
So
we
define
as
well
different
mapping
options
between
the
5g
slice
and
the
transport
slice,
which
is
iotf
networks
license
mentioned
before,
and
there
could
be
a
couple
of
options.
Some
examples
I
provided
here
so
one
two
one
mapping
one
to
end
mapping,
so
we
could
have
one
transport
slice
same
that
serves
multiple
5g
slices.
We
could
have
some
5g
slice
that
serving
you
know
different
for
the
user
playing
different
from
the
control,
plane
and
user
playing
control
play
using
different
transport
slices
and
so
on.
R
There
are
a
couple
of
modes
described
in
this
document
next
night.
Please,
then,
we
define
as
well
from
the
orchestration
perspective.
We
see
the
differentiation
between
the
first
slides
being
deployed,
5g
slice
and
the
subsequent
slices,
especially
for
the
control
plane.
So
usually
the
control
plane
is
a
shared
among
multiple
5g
slices
next
slide.
Please
there's
one
question:
okay,.
R
A
and
our
higher
high
level
of
overview
of
the
realization
model
is
that
we
are
using
very
granule
control
on
the
edge
on
the
service
delivery
points
on
the
attachment
circuits,
and
very
you
know,
we
graph,
of
course,
qs
control
in
the
transport.
This
is
to
align
with
the
current
technologies
and
kind
of
deployment
models
that
used
by
their
service
providers,
looks
like
these.
R
We
discussed
different
kind
of
centers
as
mentioned
so
at
the
moment.
The
initial
version
of
the
draft
series
tribes
strap
zero.
We
described
the
villain,
handoff
methods
and
the
ip
based
kind
of
methods
by
the
future
versions.
We
describe
additional
handle
sensors
between
the
run
cn
domain
and
the
transport
network
domain
sorry
looks
like
these.
R
R
Next
slide,
please,
and
at
the
end
we
use
capacity,
planning
and
management.
So
there
are
a
couple
of
schemes
can
be
considered.
We
discuss
with
schemes
in
data,
so
I
will
not
go
details
because
we
don't
have
time
scheme.
One
is
the
shortest
path
forwarding.
So
it's
basically
no
traffic
engineering
or
eventually
some
flex
algo
scheme.
R
Two
is
traffic
engineering
with
fixed
path,
reservations
and
skin;
freeze
traffic
engineering
with
a
dynamic
bandwidth
reservations,
so
it
could
be
out
of
bandwidth
or
dime
reservation
based
on
the
telemetry
collection
and,
of
course,
additional
schemes
can
be
considered
as
well
and
the
conclusion
so.
Existing
atf
technologies
provide
good
foundation
for
implementing
5g,
slicing
native
domain
and,
of
course,
in
subsections.
Revisions
of
this
draft
will
expand
that
next
steps.
The
questions
suggestions,
any
comments.
K
R
S
K
It
feels
more
like
a
white
paper
good
to
publish,
but
maybe
not
here.
The
other
thing
I'd
like
you
to
consider
is
that
using
the
default
nrp
is,
is
an
approach,
and
it's
it's
certainly
achievable.
I'd
like
you
to
spend
some
time
on
describing
the
limitations
of
that
approach,
as
well
as
the
benefits.
B
B
G
A
S
S
Well,
here's:
the
idea
is
that
the
service
providers
are
deploying
more
and
more
computing
capabilities
across
the
network
being
connected
in
several
points
of
the
network,
sort
of
attachment
points,
and
then
this
relates
to
the
data,
centers
or
compute
capabilities
of
different
sizes.
So
we
can
link
this
with
the
edge
computing
story
or
much
more
centralized
data
centers.
S
So
here
what
we
do
is
to
follow
a
similar
approach
to
the
one
that
was
followed
in
a
another
working
group
document,
which
is
the
service
function
aware
topology
model
so
essentially
moving
from
the
service
function,
ideas
to
the
resource
idea
of
the
compute
capabilities,
so
the
the
purpose
here
is
to
describe
complete
capabilities
and
maybe
in
two
manners.
This
is
some
work
in
progress.
So
we
need
to
to
see
if
this
consistent
to
to
go
in
one
direction
or
in
another
direction
or
both
of
them.
S
So
next,
please
so,
for
instance,
in
this
initiative
they
they
are
proposing
different
flavors
and
they
consider
predefined
flavors
as
the
ones
that
you
can
see
the
table,
but
they
also
open
the
door
to
define
customize
customize
flavors.
So
somehow,
what
we
try
to
reflect
here
is
these
possibilities
so
going
to
the
either
the
raw
resources
or
either
going
in
these
ideas
or
of
flavors,
and
so
we
will
try
to
adapt
the
model
to
these
two
approaches
by
now.
S
So
next,
please
so
as
a
summary,
this
step
was
already
presented
in
itf,
109
versions,
2
and
1,
and
2
essentially
provided
updates
on
on
the
model
on
the
the
id
of
the
these
compute
flavors.
This
is
also
because
the
the
definition
on
these
alternatives
that
the
cntt
and
so
are
moving
forward,
so
so
how
we
are
adapting
to
these
new
definitions.
S
So
as
next
steps,
we
would
like
to
to
adapt
the
model
to
the
different
ways
of
exposing
data
center
capabilities.
This
includes
also
different
kind
of
technologies.
For
instance,
the
example
that
I
saw
before
was
defined
in
relationship
with
openstack
in
dc
cnt
initiative,
but
there
will
be
other
ways,
maybe
of
expressing
resources
with
other
approaches
like
kubernetes,
and
so
so.
S
Our
objective
will
be
also
to
work
on
the
young
modules
accompanying
the
model
and
also
probably
to
start
including
some
examples
on
cases
that
could
better
reflect
the
the
the
possibilities
of
of
this
approach.
We
are
considering,
for
instance,
start
modeling
the
what
could
be
a
case
for
upf
or
things
like
that
or
or
thinking
on
the
segregated
radio
as
well.
They
see
you
and,
and
so
that
could
be
examples
of
applicability
of
this
model.
So
just
for
finishing
any
feedback
or
any
comment
is
more
than
welcome
and
that's
all
from
my
side.
G
A
L
L
And
since
last
idea
meet,
the
working
group
has
adopted
the
two
new
nrp
related
drafts,
and
so
when
we
had
this
tariq
just
mentioned,
we
had
some
discussion
with
nrp
modeling
and
things
still.
The
unless
framework
gives
some
general
nrp
definition.
We.
We
still
think
that
nrp
modeling
needs
more.
Like
detailed
definition
like
here.
We
give
we
try
to
summarize
some
k
components
from
the
two
new
adopted
drafts.
L
One
is
from
an
srpm
plus
like
things
there
are
so
many
new
terminology
in
this
draft.
We
try
to
find
some
common
components
that
also
in
the
enough
scalability
drugs.
So
here
we
think,
like
nrp.
Partition
mode
is
quite
useful
to
define
different
partition
types
and
also
an
rp
control
plane
in
unless
ipmps
they
define
rpte,
but
in
rp
scalability.
They
also
define
some
distributed
control
plane
like
multi,
topology
and
also
flexago.
L
These
distributed
control
plane
can
also
be
supported
and
about
the
data
plane
nrp
data
plane
unless
ipmp
has
defined
data,
plane,
selector
and
phb,
but
enough
scalability
defines
like
an
rpid
for
the
data
plane.
So
here
we
try
to
summarize
the
requirements
and
and
like
to
ask
the
comments
and
feedbacks
from
others
and
to
see
whether
we
have
some
good
summarization
here.
L
L
And
then
about
this
nappy
topology
these
the
terms
we
try
to
borrow
from
unless
ipmps
network,
because
right
now
there's
no,
there
is
a
need
like
whether
there
this
nlp
topology
needs
to
be
defined
like
in
tariq
just
mentioned.
We
have
the
filter
ways
to
define
a
filter
topology,
but
we,
since
we
reading
from
the
framework
dropped,
we
feel
that
there
is
a
another
customized
way
that
we
can
select
specific
links
from
the
underly
network.
L
We
can
choose
to
decide
whether
this
is
a
control,
plane
partition
or
it's
a
data,
plane
partition
and
then
about
the
topology.
What's
that's
already
in
the
ns
framework
definition,
and
I
think
resource
reservation.
Nrp
policy
also
had
this,
but
enough
control
planes
seems
missing
in
nrp
policy,
so
we
think
this
is
a
at
this
stage.
We
think
this
is
a
summary
of
the
the
major
components.
L
A
Any
comments
questions,
so
you
commented
about
having
some
relationship
with
the
the
draft
that
the
policy
draft
it
seems
that
there
needs
to
be
a
really
tight
alignment
between
the
two
drafts,
because
they're
effectively
controlling
the
same
thing
from
different
perspectives
or
different
locations.
What
are
your
thoughts
on
that.