►
From YouTube: IETF105-TEAS-20190723-1520
Description
TEAS meeting session at IETF105
2019/07/23 1520
https://datatracker.ietf.org/meeting/105/proceedings/
A
A
There
welcome
to
the
second
session
of
teas.
I
am
still
Lou
burgers,
you
still
LaVon
era,
and
we
still
have
that
helping
us
out
secretary.
The
only
thing
I'm
going
to
cover
here
is
our
North
note.
Well,
every
session
of
the
IETF
we're
asked
to
remind
everyone
of
our
rules
governing
contributions.
They
haven't
changed
since
the
last
meeting
the
last
session,
but
if
you're
unfamiliar
with
them,
please
look
at
the
note.
Well,
a
URL
at
the
bottom.
We
are
continuing
to
do
etherpad.
A
The
interesting
thing
is
is
that
there
was
a
transition
from
a
one
server
to
another
server
and
some
of
our
links
got
updated
and
some
of
them
didn't,
if
you
happen
to
jump
on
the
either
pad.
That
is
not
one
where
everyone's
taking
notes.
It
will
say.
Please
go
to
this
other
page,
and
this
is
actually
the
one
we're
using
and
with
that.
C
Welcome
back
from
the
cookies,
this
is
Daniela
I'm,
going
to
give
a
very
short
recap
of
the
packet
optical
integration
work
that
we
are
doing
or
better
that
we
revived
that.
This
is
something
that
we
started
a
while
back.
It
was
not
good
timing,
a
to
address
the
problem,
so
we
we
are
repurposing.
This
work,
this
work
now,
so
what's
the
scope
of
the
draft?
C
The
title
is
not
was
not
a
very
good
choice
in
the
sense
that
we
are
talking
about
pocket
optical
integration,
but
we,
the
scope
of
the
draft,
at
least
at
the
moment,
goes
a
little
bit
beyond
the
pocket
optical
integration.
So
this
is
for
sure
something
that
needs
to
be
fixed
and
you'll,
see
at
the
end
that
there
is
a
number
of
of
open
issues
that
we
need.
We
need
to
address
in
this
document.
C
We
are
talking
about
VPNs,
basically,
a
city
on
a
just
deals
with
what
we
refer
to
as
the
underlay
traffic
engineer,
the
infrastructure,
which
is
something
that
a
you
provision
in
most
of
the
cases,
because
you
want
to
create
a
VPN
layer,
2
VPN,
layer,
3,
VPN,
and
so
this
is
the
document
of
where
we
tried
to
identify
all
the
things
live,
live
together
and
then
a
little
bit
of
terminology,
so
how
service
orchestration
and
the
network
orchestration
work
together.
In
this
context,
contents.
C
I've
already
covered
that
annex
ballot.
Basically,
the
scope
of
the
draft
is
to
define,
in
our
reference
architecture
for
packet
optical
integration,
which
includes
a
city
and
components
so
what
we
said
before
the
underlay
traffic,
engineered
infrastructure
and
the
no
necessity
and
components
so
like
the
creation
on
VPNs
on
on
top
of
that
Rick.
C
This
is
the
reference
architecture
we
were
talking
about,
so
basically
we
have
we
have.
We
have
defined
this
domain
controller
and
hierarchical
controller,
and
we
said
in
the
framework
that
the
PNC
is
one
of
the
functionalities
of
the
domain
controller.
The
MDC
is
one
of
the
of
the
functionalities
of
the
article
controller,
namely
the
functionalities
in
charge
of
traffic
engineering,
so
doing
path,
computation,
provisioning
at
the
tunnels,
provision
in
built
on
networks,
etc,
etc.
C
And
you
see
how
these
things
interact
with
what
is
known
as
it
yen,
which
is
what
is
blue
in
in
this
picture.
Actually
we
tried
to
put
the
things
together
in
the
in
this
sense.
You
see
the
red
part,
so
the
mdac
under
the
PNC.
It
is
these
maps
one
to
one
with
the
our
capacity
and
architecture
that
we
have
in
the
framework.
Well,
the
blue
part
is
the
provisioning
of
services.
Actually,
two
different
methods
can
be
used
identified
with
a
number
one
and
two
in
in
this
picture.
C
C
C
We
about
other
models,
EF
and
G,
to
do
something
else,
for
example,
del
to
SM
and
ll3,
a
semaphore,
the
creation
of
layer,
2
and
layer
3
VPN
in
the
drafter
we
try
to
so
once
we
define
a
quite
generic
scenario:
multiple
packet
domain
controllers,
multiple
optical
domain
controllers,
in
hierarchical
one.
We
try
to
identify
a
workflow.
Basically,
what
is
the
process?
What
are
the
interfaces?
What
are
the
different
steps
in
the
provisioning
of
such
a
multi-layer,
multi-layer,
environment,
multi-layer
structure?
C
This
is
something
that
you
can
see
in
in
the
draft.
I
would
like
to
save
some
time
and
go
directly
to
the
conclusion
and
next
steps,
so
issues
addressed
by
the
draft
applicability
of
a
city
and
to
packet
optical
integration
and
services,
VPNs
role
of
a
packet
optical
integration
in
art
and
soft
isolation
scenarios.
This
is
something
that
I
didn't
cover
in
during
the
slides,
but
is
one
of
the
issues
that
is
addressed.
C
Open
points
open
issues,
so
these
two
items
VPNs
and
packet
optical
integration-
do
they
needed
to
be
addressed
in
the
same
draft
or
there
is
enough
meet
to
split
the
work
into
two
portions,
considering
also
the
fact
that
another
draft
on
packet
optical
integration
was
recently
recently
published,
I
I
read
it
the
this
morning.
It's
it's
it's
a
very
good
document,
so
I
think
that
is,
there
is
room
for,
let
me
say,
integration
between
between
the
two
documents.
C
So
what
what
do
you
think
should
we
address
VPNs
in
a
document
pocket
optical
integration
in
another
address
just
one
of
them,
because
it's
more
important
than
the
other?
We
are
totally
open
enough
to
get
feedbacks
and
start
and
steer
the
work
towards
the
right
to
the
right.
This
is
at
zero,
zero
draft,
so
there
is
a
still
room
for
improvement
for
changing
everything,
dropping
everything,
hi
Michael.
Welcome
back
my.
D
D
There
are
quite
a
number
of
relevant
or
IP
optical
use
cases,
and
what
you
have
in
this
document
here
is
probably
not
the
top
relevant
list.
If
you
look
in
the
market,
if
you
look
at
commercial
solutions
that
exist,
if
you
look
at
what
operators
typically
deal
with,
then
what
this
industry
meant
is
not
the
top
priority.
It
is
probably
the
use
case,
ten
or
twenty,
and
there
are
nine
or
19
cases
that
there
are
low-hanging
fruits
and
higher
priority.
So
I
would
strongly.
B
C
So
yeah
I
revert
to
the
question
in
the
sense
that
the
goal
here
was
to
create
a
generic
use
case,
a
generic
environment,
a
generic
action
REO
and
try
to
address
it.
So
are
you
saying
that
it
would
be
better
to
define
a
set
of
use
cases
and
then
for
each
of
them
go
into
the
details,
so
do
something
specific
rather
than
generic
yeah.
D
I
would
I
think
there's
strong
value
in
coming
up
with
realistic
lists
of
ticket
optical
use
cases
and,
as
I
said,
they
are
in
the
market.
There
are
of
the
order
of
ten
use
cases
that
are
very
well
known,
and
it
definitely
makes
sense
for
me,
as
in
this
working
group
or
another
working
group,
to
document
that.
But
my
key
point
is
the
starting.
D
E
Thank
you,
it'll
boost
from
away
I
agree
on
your
proposal
to
split
into
two
documents
so
because
VPN
over
a
city
area
is
not
only
pocket.
Optical
cannot
me
over
just
a
layer,
2
network
and
a
packet
optical
is
not
only
DP
and
can
be
also
infrastructure,
so
the
two
problems
are
quite
different
and
it's
better
to
have
two
documents,
a
document
both
because
both
are
really
valid
problem.
Thank
you.
F
Personally,
I'm
a
little
bit
worrying
about
whether
we
can
do
really
good
splitting
clear
whether
we
can
do
really
good
sleep
Buddha
splitting,
because
the
VPN
is
very
specific
and
we
know
what
it
is,
but
Pio
I
packet
optical
integration.
There
are
depended
a
lot
of
possibilities
that
we
can
consider
different
scenarios
as
the
PIO
I.
So
we
need
to
have
a
clear
boundary
if
we
really
make
the
decision
to
do
the
splitting
and
make
sure
that
we
don't
conflict
with
each
other.
F
G
Who
are
we?
My
comment
is
regarding
your
slide,
3,
where
you
were
showing
the
MDS
C
directly
talking
to
the,
and
there
was
a
I
think
a
slight
before
that.
Yes,
this
one
so
wait
the
difference
between
one
and
two
so
based
on
your
feedback,
because
L,
3
and
M
was
something
which
was
discussed
in
RT
gwg
and
might
be
an
ops
area
working
group
where
the
idea
of
the
VPN
network
model
came
up.
G
C
H
Also
was
on
this
routing
group
session
and
I
heard
Oscars
presentation.
What
I
didn't
understand
and
still
don't
understand
this
idea
of
layer,
3
network
model,
because
Moodle
is
basically
an
API
between
two
controllers
right.
So
so,
basically,
if
you
control
all
that
have
to
talk
to
many
different
people,
so
then
you
have
to
have
different
models
right.
It's
it's
I
cannot
see
which
side,
probably
orchestrate
is
on
one
side,
but
what
would
be
on
the
other
side
of
the
layer?
3
VPN
network,
Moodle
I,
don't
understand.
H
C
D
H
G
You
are
relying
on
the
domain
controller,
but
with
respect
to
VPN
configuration
you
directly,
hijack
them
and
directly
send
to
the
device,
so
it
was
becoming
didn't
feel
like
the
right
approach
and
anyway,
L
3
and
M
discussion
doesn't
belong
in
this
working
group.
So
we
should
not
take
too
much
time
about
the
applicability
of
that
Thank.
I
I
So
you
know
we
hear
this
from
industry
that
actually
Yang's
not
being
used
for
the
young
ITF
models
are
not
being
used
because
the
ITF
doesn't
understand
the
system,
it
doesn't
understand
the
end-to-end
service,
so
I
think
we
do
need
these
documents.
The
second
comment
is
as
a
co-author
of
the
other
and
Packard
optical
integration
document.
I,
do
think.
There's
some
synergy
between
you
know
both
of
our
documents.
Here
one
may
be
to
look
at
the
end-to-end
service
and
the
other
to
do
sort
of
some
of
the
detail
gap.
I
E
Eatle
woozi
I
tend
to
agree
with
drew
on
the
interface
number
two.
The
risk
I
see
here
is
consistency
in
terms
of
naming,
because
the
PSC
domain
number
two
is
doing
some
obstruction,
so
in
the
MDS
he
may
not
even
be
aware
about
the
box,
which
is
terminating
the
tunnel
and
therefore
we
need
to
have
maybe
just
for
naming.
Translation
may
be
very
simple,
but
something
in
domain
controller
number
two
that
takes
the
configuration
of
the
VPN
service
I
translate
that
into
a
vise
configuration.
C
B
J
Okay,
so
this
is
the
applicability
of
a
CTN
to
support
5g
transport.
It's
a
0-0
draft
that
young
and
I
wrote.
So,
let's
get
to
the
problem
that
needs
to
be
solved.
The
question
is
basically
how
we
map
the
5g
slice
instance
to
a
transport
slice
instance,
and
if
you
look
at
the
from
the
3gpp
or
the
5g
side,
a
slice
is
defined
as
an
end-to-end
logical
network
comprising
a
certain
set
of
resources
and
so
on.
You
know
it's
defined
in
3gpp
documents,
28,
5,
31
and
so
on.
J
So
that
would
mean
that
it's
across
from
the
handset
to
the
base
station
to
use
a
plane
device
like
a
router
and
all
the
way
where
the
PDU
session
exists
and,
on
the
other
hand,
the
transport
network
slice
instance,
is
as
I
guess.
You
know.
You
probably
have
looked
at
in
more
detail
across
a
transport
network
itself
across
two
points
or
resources
across
multiple
points
in
there.
J
It's
it's
several
other
clients
as
well,
so
there
needs
to
be
a
mapping
between
what
a
slice
means
in
the
5g
domain
and
what
resources
are
reserved
or
provided
in
the
transport
domain
and
I.
Think
that's
what
we're
trying
to
do
here.
So
if
you
look
at
the
details,
are
really
in
the
in
the
3gpp
documents.
There's
the
network
slice
identifies
like
the
NSS
AI
The
Cure's
identifier
is
like
5qi,
and
all
of
that
put
together
defines
what
should
be
provided
in
a
PD.
J
U
session,
and
the
the
transport
between
two
of
these
nodes
may
cross
more
than
one
network
layer
to
network.
So,
for
example,
it
could
be
a
data
center
network,
followed
by
a
backhaul
network
and
and
another
data
center
network
between
those
two
functions.
So
in
considering
this
I
think.
We
think
that
it's
better,
that
we
carry
this
mapping
info
in
some
kind
of
an
IP
layer,
header
extension
or
some
other
way,
so
that
you
don't
have
to
map
between
the
different
layers
of
networks.
J
So
what
we're
defining
here
is
a
context.
Identifier
called
the
mobile
transport
network
context
and
this
identifier
Maps
a
class,
a
service,
the
if
it's
a
cue
CI
or
a
5qi
I
meant
to
write
5qi,
actually
there
and
slice
aspects
of
a
5g
slice
and
other
QoS
requirements,
including
reliability,
isolation
and
security,
and
so
on
to
a
V
and
slice
in
the
transport
domain.
J
And
it's
up
to
the
3gpp
or
the
5g
domain
to
generate
this
identifier
based
on,
and
you
know,
all
of
that
would
be
in
the
3gpp
network
because
they
know
the
users
and
the
subscribers
and
how
much
differentiation
is
needed
and
so
based
on
that
it
can
generate
these
identifiers
and
request
for
service
to
be
offered
in
a
transport
network.
So
that
would
be
a
contract
between
the
the
5g
domain
and
the
underlying
transport
of
me
note
that
this
is
not
a
one-to-one
association
between
the
PDU
session.
J
The
PDA
session
is
in
the
the
5g
domain
and
the
the
identifier
that
maps
to
the
transporter
me.
So
then
there
will
be
multiple
to
one,
so
many
flows
to
one
and
I
think
that's
the
basis
for
saying
that
the
identifier
would
scale
well
because
it's
scaling
by
the
square
of
only
the
number
of
associations
in
the
transporter
the
flows
would
be
much
higher
than
that.
J
Also,
the
identifier
is
generated
before
the
session
is
established,
and
so
there
is
no
need
to
figure
out
where
that
path
is
when
the
session
needs
to
be
established.
So
those
are
the
I'll
get
into
the
little
more
detail
in
the
next
couple
of
slides
this
one
in
the
next
and
to
show
how
this
can
work
so
I
think
on
this
slide.
I
will
not
go
into
too
much
detail
because
it
was
presented
in
much
more
detail.
J
I
think
in
the
last
presentation,
at
least
from
the
point
of
view,
that
I
want
to
focus
on
which
is
the
CNC.
The
CNC
is
the
point
at
which
the
5g
network
interface
or
that's
there's
an
there's
another
entity
in
the
5g
domain,
with
which
this
will
have
a
contract
for
a
slice
or
set
of
transport
paths.
So
that's
that's.
The
focus
I
mean
I,
think
this
figure
is
pretty
familiar
to
people
here.
J
J
So
all
thats
in
that
blue
box
is
3gpp
specifications
and
that's
why
I'm
trying
to
avoid
getting
into
the
details
over
there,
because
that
would
have
to
be
specified
by
3gpp.
But
let
me
start
with
the
TPM
and
the
action
one
where
the
it's
a
the
TPM
as
a
transport
path
manager,
which
estimates
how
much,
how
many
slices
and
how
much
bandwidth
and
other
resources
are
needed
between
two
points.
J
J
J
So
that's
the
provisioning
part,
the
the
other
details
are
in
3gpp,
so
I'll
skip
that
and
when
a
packet
arrives
at
the
UPN
F
it
could
be
base
station
or
a
router.
Let's
say
so
that
classifies
that
session
packet
and
based
on
that
classification,
the
empty
NC
identifier,
is
inserted
and
when
the
MTN
cid
is
presented
to
the
PE
router
in
step
3,
it
grants
the
resources
that
was
reserved
in
the
transport
network.
So
that's
the
sequence
of
operation.
J
So
to
do
this,
we
also
need
to
be
able
to
carry
this
identifier
in
the
IP
packet
in
a
suitable
place
where
it
can
be
read
pretty
easily
and
the
transport
network
and
program.
So,
for
example,
in
this
case
the
the
2u
PMF
functions
are
the
G
note
B
and
the
UPF
on
on
the
figure
up
there
and
that's
an
n3
interface
between.
So
when
a
packet
arrives
at
the
G
note,
B
it
gets
classified
and
an
empty
and
C
identifier
is
inserted
based
on
what
the
3gpp
Network
has
programmed.
J
It
was
then,
when
it,
when
the
packet
goes
to
the
PE
router,
the
MTN
C
identifier
is
inspected
and
the
appropriate
forwarding
label
is
put
in
the
appropriate
forwarding
label
is
inserted.
So
we
chose
this
method,
because
many
of
the
other
ones
are
not
suitable.
Gtp
U
is
not
a
good
one.
Dhcp
does
not
or
the
flow
labels
are
not
a
beautiful,
and
we
think
that
either
a
gue,
SR,
v6
or
maybe
other
such
extensions
are
the
right
ones,
so
I
think
there
are.
J
K
Hi
Tom
Herbert,
so
in
terms
of
the
mechanism,
ipv6
extension
headers
could
be
a
possibility.
In
fact,
I
wrote
a
draft
con
firewall
in
service
tickets,
not
sure
you've
seen
it,
but
it's
almost
identical
to
this.
The
idea
is,
we
carry
some
sort
of
identifier
that
provides
QoS
and
even
routing
information
inside
an
app
a
value
and
that's
carried
an
ipv6
extension
header.
It
might
be
worth
looking
at
so
to
an
offline
if
you
want
I
I.
K
Tickets,
so
I
presented
in
int
area,
I,
really
didn't
know
what
the
correct
home
is
seeing
this
working
group
for
the
first
time.
This
might
be
an
interesting
location
for
it.
It
would
serve
a
lot
of
the
same
aspects.
It
also
has
some
other
features.
I
would
intend
this
to
actually
be
going
to
the
application
the
application
send
in
this,
and
then
we
have
some
mechanisms
to
reflect
it.
So
the
return
path
is
always
another.
Another
problem
with
stuff
like
this
I
look.
J
K
Options
but
that's
also
a
problem
right,
so
we
have
go
and
SR
v6
and
then
somebody
you
want
to
do
this
MPLS
and
many
many
options,
the
value
or
proposition
of
IP.
These
extension
headers,
like
hop-by-hop
options,
are,
do
it
once
and
it
should
work,
and
you
know
you
can
use
cases
for
ipv6
ipv4,
it's
another
issue
that
we
have
to
solve.
K
J
K
H
L
So
here
it
says
interface
by
Israeli
interfaces
before
going
through
the
detail
of
the
draft
the
door.
A
few
comments
one
is
there.
Recently
there
was
a
there-
is
a
project
accepted
by
BBF,
which
is
in
the
same
area,
and
we
feel
that
whatever
we
do
here
should
complement
that.
So
this
is
the
one
of
the
specific
topics
that
is
very
important
to
be
considered
and
then,
as
I
go
through
the
presentation.
L
I
will
show
you
how
this
one
relates
of
whatever
we
do
as
ITF,
and
the
work
at
BBF
and
ITF
should
be
coordinated
as
well.
So
this
is
basically
their
starting
point.
The
it's
somehow
related
to
the
previous
presentation.
Let's
talk
about
networking,
slicing
and
transport
and
I'm
trying
to
just
give
you
another
perspective
of
how
everything
relates
to
each
other.
So
you've
seen
this
picture
or
a
version
of
this
picture
most
likely
in
the
different
contexts,
but
I'm
trying
to
mention
here
that
what
is
into
a
network
a
slice?
L
Basically,
the
representation
of
illogical
interfaces
from
left
to
right
left
is
uue.
Let's
say
there
is
a
mobile
network
operator
has
trick,
make
customer
or
tenants
BMW,
Fiat
and
public
safety.
Each
of
these
tenants
are
asking
about
various
independent
logical
network
from
UE
all
the
way
to
application.
We
call
each
of
this
independent
Network
end-to-end
network.
So
it's
very
important.
End-To-End
means
network
slice
from
left
to
right.
Each
of
these
networks
lies,
I
have
various
colors.
Here
you
can
think
of
color
as
SLA.
L
Each
one
has
a
specific
SLA
and
each
of
them
has
various
sub
components.
Ranas
lies,
sometimes
they
call,
it
ran.
Sub
slice
or
rat.
Subnet
is
the
same
thing.
Chorus
lies
and
transfer
as
lorena
slice
means
in
duran
depends
on
a
deployment
I'm
creating
at
personality
in
ran
to
understand.
Each
of
these
networks
lies
by
the
same
token.
L
Chorus
lies
means
I'm
creating
the
personality
on
my
core
equipment
equipment
is
different,
configuration
is
different,
but
the
logic
is
the
same,
and
last
but
not
least,
there
is
a
transfer,
the
slice
we
talked
about
when
at
ITA
we
talked
about
networking
sliced.
Basically,
we
are
talking
about
the
transfer,
a
large
portion
of
that
that
one
is
a
set
of
connections.
As
you
will
see
here,
there
are
various
connection
that
should
be
happen
between
ran
and
chord
or
sometimes
inside.
L
The
ran
depends
on
the
deployment
of
ran
I
have
to
create
so
called
meet
hall
or
front
hall
connectivity.
So
long
is
very
short:
you
will
see
an
end
to
a
network
of
ice,
contains
rena
slice,
chorus,
lies
and
transport.
Each
of
them
has
its
own
controller.
The
focus
of
this
presentation
is
a
transfer,
a
slice
which
basically
gives
the
connectivity
and
we
want
to
address
us.
Yes,
please
sorry.
H
You're
Riskin
clarification
question,
so
I
hear
this
for
the
second
time.
What
I
don't
understand
is
when
you
write
this
line
right
like
this
segments,
is
it
actually
point-to-point
connection
or
each
of
these
segments
are
represents
a
topology?
So
basically,
you
may
have
multiple
multiple
connectivity,
the.
L
L
Is
a
you
know
very
high
level
to
at
least
you're
pretty,
but
it's
a
point
is
taken,
so
this
is
a
better
picture
for
one
of
those
transferred
into
a
network,
a
slice.
Let's
say:
I
have
a
mobile
network
operator.
X,
there
is
a
company-wide
once
a
type
of
service
URL
see
you
know,
low-latency
and
mice.
L
Sla
is
latency
less
than
five
milliseconds
how
to
create
that
the
network,
a
slice
and
the
component
artifact
is
not
created
in
the
network,
yet
so
from
the
top
to
bottom,
if
it's
a
PowerPoint
as
an
animation
but
I'm
trying
to
go
through
the
animation.
Basically,
the
logic
here
is
starting
from
one
and
the
note
yellow
is
important.
These
are
logical
as
if
doesn't
mean
necessarily
happen
in
the
sequence,
from
the
top
to
bottom.
Customer
asked
about
the
service
Orchestrator,
which
is
the
end-to-end
context,
goes
through
some
action.
L
Using
the
network
slice
blueprint,
aka
Network,
a
slice
template
is
creating
a
profile
profile
says:
what
are?
The
components
should
be
inside
the
end
to
a
network
as
life
and
after
that
it
goes
through
a
step
three
four:
five:
six
to
basically
create
them
or
configure
them.
The
important
aspect
of
our
discussion
here
is
comparison
between
interface,
four,
five
and
six
interface.
L
Four
and
five
is
basically
creating
the
ran
and
kora
slices,
the
context
that
we
creating
on
the
run
and
core
they
are
well
defined
in
3gpp,
and
the
context
of
this
discussion
is
interface,
six,
that
we
are
sending
that
one
to
a
transfer,
a
slice
controller,
and
we
want
to
create
the
connectivity
inter
forced
interfaces.
Six
is
not
defined
in
3gpp
and
basically,
the
work
that
we
want
to
do
is
defining
interfaces
which
is
basically
the
aligned
with
interface
for
and
file
for
the
grant
and
call
respectively.
L
So
whatever
we
want
to
do
is
basically
that
this
is
another
representation
of
same
logic.
These
are
taken
from
3gpp
on
the
left
left
the
picture.
You
will
see
that
whatever
3gpp
talks
about
transfer
is
a
death
line.
Basically,
this
is
a
definition
of
the
transport
connectivity
that
we
want
to
explore.
On
the
right
hand,
side
bottom
right
is
basically
the
same
picture
that
I
showed
you
before
this
is
taken
from
the
five-thirty.
L
It's
basically
demonstrate
that
whatever
we
want
to
do
for
transfer
slices
along
with
3gpp
same
picture
at
the
very
top
we
have
Orchestrator
and
we
have
three
domain
controller.
If
the
in
3gpp
lingo,
sometimes
they
call
their
into
a
network.
Astroids
Orchestrator
and
SMF
network,
a
slice
management
function
and
they
call
their
in
a
tree
component
for
ran,
transfer,
encore
and
ssmf
net
forks
up
a
slice
management
function
so
go
ahead.
Please
run
after
us
finish
this
just.
J
L
One
definitely
is
dynamic,
their
whole
dynamic
cities
yeah
nobody
goes
and
creates
the
CLI
or
configuration
of
transfer
a
slice
run.
Everything
starts
from
the
dynami
city
of
the
whole
logic,
and
their
answer
to
your
first
question
is
multiple
domain
could
be
possible
as
well.
It's
pretty
complementary
to
you.
Yes
yeah.
Maybe
we
can
talk
offline
as
well.
I
want
to
ask
you
a
few
questions,
but
we
can
talk
about
them.
So
the
idea
here
is
the
important
aspect.
L
This
picture
is
trying
to
say
that
each
of
these
orchestrate
or
controllers
has
three
functions
or
three
major
capability,
automation,
monitoring
and
analytics
and
optimization.
In
other
words,
when
we
are
talking
about,
for
example,
the
read
we
want
to
talk
about
transport
as
slices
that
we
should
talk
about
not
only
the
automation
or
creation
of
that,
but
we
have
to
talk
about
how
we
can
monitor
and
do
the
analytics
okay
open
low
or
how
we
can
do
the
optimization
akkada
closed-loop.
L
So
these
are
three
major
function
that
should
be
addressed
and
in
most
cases
we
are
addressing
only
the
first
one,
but
we
are
somehow
ignoring
the
second
and
third
one
that
we
have
to
address.
At
the
same
time,
okay
I
need
only
few
minutes,
so
basically
interfaces
that
we
I
put
it
here
in
red.
It's
the
question
that
we
have
to
address.
It's
missing
from
industry
is
needed
for
an
industry
and
how
this
relates
to
IETF
and
the
work
that
we've
done
in
the
layer,
two
layer,
three
layer,
zero
layer,
one
services.
L
This
is
a
kind
of
complementary
to
that.
Why,
here
it
again,
if
it
is
powerful,
there
is
animation,
but
consider
the
yellow
end
to
a
net
focus
why's
that
we
want
to
create.
To
do
that,
we
have
ran
cold
transport
controller.
We
have
to
create
these
three
components
and
connect
them
together,
basically
go
through
the
transport
controller,
because
this
is
the
discussion
of
this.
We
send
a
request
to
transport
controller
to
create
connectivity
between,
ran
and
core.
We
don't
in
that
interest.
We
don't
specify,
create
and
layer
three
service
or
layer.
L
Two
service
we
just
said
create
connectivity
between
ran
and
core,
and
the
SLA
is
five
millisecond
latency,
for
example,
transfer
a
slice
receive
that
request.
Translate
that
one
to
some
artifact
that
can
be
deployed
to
the
network
is
the
requirement
that
we
have
to
work
here
and
step.
Three
is
basically
whatever
idea
files
ITF
has
various
models
and
way
to
deploy
this
connectivity
to
the
network,
and
this
is
there.
Basically,
the
idea
that
whatever
is
proposed
here
is
complementing
ITF
IETF
is
defining
the
whole
service
tunnel
path.
L
How
to
do
it
the
various
way
to
do
it
from
layer
zero,
all
the
regulatory,
but
basically
we
are
trying
to
say
that
this
one
is
a
complementary
to
idea.
So
in
summary,
we
have
to
address
automation,
monitoring,
optimization
and
whatever
we
do
is
basically
complementing
the
idea.
Is
these
interfaces
are
needed
for
an
industry
and
I
didn't
put
it
here,
because
I
create
this
a
slide
yesterday,
but
we
have
to
work
I
kind
of
layers
on
between
us
and.
L
Bbf
to
address
the
synergy
that
is
Dell
and
why
this
the
the
giraffe
is
in
this
working
group,
because,
with
the
knowledge
and
expertise
that
is
existent
here
for
various
young
model,
various
model
that
can
be
done.
Basically,
we
can
take
the
requirement
and
somehow
use
this
knowledge
and
augment
the
server
the
model
that
we
have
here.
So
basically,
this
is
the
reason
that
I'm
presenting
it
here.
This
is
end
of
the
presentation.
I
am
more
than
happy
to
take
questions.
F
L
L
F
F
Currently,
we
we
have
the
T
models,
we
have
the
Wien
model,
so
we
also
have
the
layer
specific
service
models
to
specify
your
other
working
groups,
and
my
understanding
so
far
is
the
combination
of
so
we
and
the
service
models
can
satisfy
this
kind
of
requirement,
but
the
only
difference
is
we
are
using
this
kind
of
models
to
support
different
stories
with
different
technologies.
I
can.
L
Save
you're
supporting
different
connections
which
are
implemented
aka
realized
by
a
service
tunnel,
the
vampire.
So
if
we
have
to
make
a
distinction
between
connection,
there
is
a
subtle
difference
here,
at
least
in
the
context
that
we
have
here,
but
basically
the
whatever
you
mentioned.
It's
correct,
but
this
is
a
kind
of
complementary
to
that,
hierarchic
that
we
have
today
and
basically
the
different
use
case
to
address
the
you
know
different
use
case
in
the
console.
5G
I
whole
answer
a
question,
but
if
not,
we
can
have
offline
Eric
place.
Hi.
M
Eric
Erickson,
so
attendance
presentation
a
couple
times
and
I've
also
been
attending
the
presentations
in
the
broadband
forum
as
well.
One
issue
that
I
I
see
here
is
we're
talking
you
have
been
talking
in
in
the
past
and
about
an
abstract
interface,
which
is
in
everything
I've
seen
about
it,
really
describing
a
service
interface
you're
talking
about
an
interface
that
says,
I
need
this
capacity,
I
need
these
tool
any
parameters,
etc,
etc,
and
this
is
done
in
a
way.
M
That's
orthogonal
to
the
actual
devices
being
used
in
the
network
that
they're
so
annoying
to
the
broadband
forum.
What
the
broadband
forum
seems
to
be
looking
for
is
so
what
we
can
provide
is
a
mapping
from
that
abstract
interface
to
actual
devices
in
service
butter
networks.
Now
we
come
to
the
IETF
they're,
saying
they're
saying
well,
we
already
have
as
far
as
I
understand
it.
We
already
have
a
number
of
models
that
sort
of
support
this.
M
What
exactly
is
it
that
we
don't
have,
and
so
what
I
see
going
on
is
we're
trying
to
do
all
of
these
things.
At
the
same
time,
and
in
fact
it
seems
to
me
to
what
you're
wanting
to
do
is
sort
of
have
a
top-down
development
and
if
you're
having
them
all
done
at
the
same
time,
see
how
you
can
effectively
do
that
without
spinning
wheels
for
quite
a
while.
Unless
you
know
exactly
where
it
is,
you
think
you're
gonna
end
up
and
I.
L
This
is
basically
the
whole
idea
of
that.
We
have
to
study
all
those
think
the
fact
that
we
need
a
single
set
of
interfaces
after
abstract
interface,
which
is
aligned
with
3gpp,
ran
and
core,
is
basically
the
idea
here
that
the
interface
in
should
be
most
cases
abstract,
vendor
agnostic
or
technology
agnostic.
And
basically
we
take
that.
M
L
N
Laughter,
everyone
Amazon
fur
comes
from
that.
He
I
will
talk
about
the
packet
networks
lesson
using
segment
voting
next,
the
paper
below
is
the
layered
architecture
of
a
hosta
pian,
which
is
defined
in
draft
TC.
Has
the
whip
Ian
Paice
the
layered
activity
of
enhanced
with
Ian?
This
tech
document
specifies
the
solution
to
create
which
were
network
in
your
packet
Network,
introduction
explicit,
which
were
network
identification.
N
There
is
no
modification
to
the
forwarding
table
in
order
to
testing
rests
of
ordering
behavior
the
perfect
society
you
will
be
allocated
for
AI
next.
This
is
an
example
of
our
solution.
In
figures.
There
are
two
topology
red
and
blue
relative
policy
includes
ABCDEF
notes
and
the
link,
a
PPC,
PF,
p,
IV
c
and
et.
N
The
polluter
policy
includes
a
pc,
tem
notes
and
link
AF,
f,
PF
c
fe
e
ez,
pc
and
the
city.
The
controller
connect,
the
resource
information
with
us
repeatedly
arise
and
it
can
build
corresponding
SI
with
short
apology
and
can
calculated
as
a
te
pass
based
on
the
color
with
AI
another
con
street
criteria
in
each
which
whole
network
the
next
is
multi
Multi
multi
determine
deployment.
N
It
is
easier.
It
is
easy
to
provide
end-to-end,
which
one
network,
including
entitlement
in
some
deployment
the
operator
adopt
the
BGP.
Are
you
to
set
up
the
PPR
see
if
the
the
only
stories
can't
directly
over
the
PDP,
our
USP?
If
it
always
service?
How
does
requirement
of
the
TE
which
defined
by
our
color
to
be
CRO?
We
also
support
the
color
and
the
BPO
label
will
allocate
for
color
the
below.
Is
the
option
be
inter
area?
N
It
can
also
provide
entry
into
which,
which
one
to
work,
including
the
in
determining
the
inter
temp
Dominic,
can
choose.
The
link
based
on
the
color
with
a
next
is
end-to-end
situ
is,
as
the
end
the
controller.
The
controller
can
connect
the
topology
information
with
the
eye
through
the
busy
eyes
and
then
calculate
SR
paths
based
on
the
information.
N
Next
is
combined
with
SF
flex
algorithm
hello
template
with
a
I
kept
to
the
FAI.
T4
label
stack
optimization
with
algorithm,
while
you
other
what
rest
is
a
flex
algorithm
value.
The
prefix
si
T
is
associated
with
passes
calculated
using
to
flex
algorithm
in
the
Associated
topology
I.
Specific
next
step
comments.
Welcome.
Thank
you.
This
is.
This
is
the
end
of
all
our
priorities.
O
O
O
N
A
A
It's
better
to
have
that
confirmed.
So
we've
been
grappling
with
how
to
proceed
with
what
we
thought
was
the
intent
of
the
group
and
now
he
knows
the
intent
of
at
least
the
room,
and
we
were
thinking
that
perhaps
the
the
right
way
to
proceed
is
to
come
together
to
collect
those
people
who
are
interested
in
working
this
into
some
sort
of
design
team
and
to
come
up
with
a
stated
direction.
So
the
objective
the
design
people
do
come.
A
For
the
work
in
this
working
group,
so
it's
going
to
be
a
fairly
open
and
we
would
expect
a
little
contentious
because
there's
a
bunch
of
different
views
here
to
come
up
with
a
proposal
that
is
consolidated
among
those
people
who
are
very
interested
in
working
on
this
problem.
But
the
proposal
of
what
we,
this
working
group
should
be
doing
now,
of
course,
generally
design
teams
from
while
they
can
be
just
put
together
by
chairs.
A
Part
of
that
will
be
finding
out
folks
who
are
interested
in
participating
and
we're
going
to
need
a
sort
of
a
balance
of
people,
those
people
who
have
a
good
understanding
of
what's
happening
outside
the
IETF
and,
of
course,
those
who
are
have
a
good
understanding
of
what
we've
done
previously
inside
the
IDF
and
even
beyond
this
route.
So
at
this
point
we
would
like
some
feedback
from
the
working
group
if
they
think
that's
a
good
idea,
a
bad
idea,
any
comments
they
may
have-
or
you
may
have
comments.
B
A
H
A
When
we
have
sufficient
mass
of
authors,
who
put
four
documents,
we
say
authors
go
in
the
room
and
figure
it
out.
So
we've
taken
that
approach
in
the
past.
We
are
not
suggesting
that
this
time
we're
suggesting
that
we
be
a
little
more
structured
on
that
make
sure
we
have
the
right
people
in
the
room.
That's
really
the
difference
between
a
design,
team
and.
B
B
Actually,
ITU
is
doing
it
and
it
would
be
good
delays
on
and
get
information
from
them
to
help
support
it,
and
even
things
like
actually
ITU
had
a
lot
of
difficulty
with
the
terms,
because
just
to
map
from
terminology
of
3gpp
to
to
to
transport
type
of
terms
so
I
think
a
design
team.
If
they
could
hopefully
scope
it
and
get
us
kicked
off
in
the
right
directions
right
and
then
we
can
communicate
with
the
other
groups
that
we're
doing
this.
Q
A
So
I
don't
want
to
commit
to
it.
I
said
something
pretty
high-level
at
the
start
about,
but
we
wanted
some
time
to
make
sure
that
we
have
a
good,
solid
proposal
that
we
bring
for
the
working
group
and
make
sure
that
it
makes
sense.
So
I
don't
expect
a
protocol
solution.
We
don't
expect
a
protocol
solution.
It
would
be
at
most
a
framework
for
the
work
that
we're
gonna
do
here.
Okay,.
A
A
A
O
O
The
outline
of
my
talk
is
I'll
mention
a
little
bit
of
motivation.
Why
are
we
doing
and
what
are
we
trying
to
solve?
And
then
we
will
introduce
you
to
these
IP
RSVP
tunnels,
they're
creation
management,
how
we
can
achieve
protection
fast
reroute
with
with
this
approach,
and
we
will
talk
about
shared
forwarding
state
I-
will
mention
the
signaling
extensions
that
we're
proposing
to
achieve
this
close
with
next
steps.
O
So
what
problem
are
we
trying
to
solve?
We
know
IP
networks
or
networks
that
use
IP
in
they're
forwarding
they
exist.
They
exist
in
data
centers.
They
exist
in
data
center.
Interconnect
and
new
networks
are
deploying
ipv6
for
various
reasons:
IOT
the
address
space
limitation
and
so
on,
and
there
are
motivations
even
to
migrate
towards
ip-based
networks
or
IP
based
forwarding
networks
for
capex
or
OPEX
reasons.
O
Reduction
and
to
reduce
the
complexity
of
learning
many
protocols
with
that,
we
still
need
traffic
engineering,
and
this
is
why
we're
here
we
need
traffic
engineering,
because
there
are
stringent
service
requirements
coming
forward.
5G
we've
been
talking
about
that,
so
we
want
to
be
able
to
steer
over
the
non
shortest
paths
with
certain
guarantees.
We
want
to
be
able
to
use
the
resources
in
the
network
in
an
optimal
way,
so
IP
rsvp-te.
What
does
it
offer?
We
promise
you
that
it
works
with
ipv4
forwarding
and
ipv6
v6
as
well.
O
O
O
These
addresses
are
not
advertising
igb,
necessarily
and
they're,
not
even
globally
routable.
So
they're
between
point
on
point
point-to-point,
ingress
to
egress
scoped
in
terms
of
setting
up
the
IP
path,
there's
signaling
that
kick-starts
kick-started
by
the
ingress,
typically
by
computing,
an
explicit
route
satisfying
certain
constraints.
It
can
be
computed
on
the
ingress
or
by
a
central
server.
O
Signaling
is
used
to
do
the
reservation
if
needed,
but
once
the
signaling
reaches
the
egress,
an
egress
address
is
allocated
to
the
IP
path
from
the
block
and
a
note
here
that
the
same
egress
address
can
be
shared
between
multiple
IP
paths
and
we're
going
to
demonstrate
how
that
can
be
done.
So
any
ingress,
transit
or
even
on
the
egress
will
program
their
rip
with
that
egress
address
and
you
know,
have
a
binding
with
that.
Ip
path,
its
path,
specific
IP
path.
O
This
is
an
example
network
where
we
have
an
ingress,
r1
and
an
egress
r4.
We
have
an
EAB
block
sitting
on
our
for
it's
at
prefix.
It's
a
v4
prefix
in
this
example,
and
and
we
have
a
service
network
behind
our
420
/
8,
so
signaling
will
will
use
the
ero
hop-by-hop
with
the
path
message
and
we
will
use
this
generic
label
request
to
request
an
egress
address
to
be
allocated
from
the
egress.
So
once
the
path
message
reaches
the
egress,
the
egress
responds
with
the
reservation
message
with
the
allocated
egress
address.
O
So
the
packet
travels
along
the
IP
path
that
we
signaled
and
once
it
reaches
the
egress
we
D
capsulate,
the
outer
IP
header
and
then
forward
the
packet
to
the
the
networks,
slash
it
in
terms
of
extensions.
We
so
far
we're
thinking
we
don't
need
much.
The
generalized
label
request
was
already
defined
in
RFC
3471,
there's
an
LSB
encoding
type
and
switching
type.
We
are
requesting
at
special
switching
types,
be
defined
for
ipv4
te
and
ipv6
T,
so
that
we
can
signal
those
IP
kind
of
labels.
O
We
are
showing
here
how
we
can
achieve
fast
reroute
with
such
an
deployment.
We
have
a
protected
IP
path,
an
example
of
a
link
protection
here
with
a
bypass
very
much
similar
to
RFC
4090.
We
set
up
the
bypass
and
we
protect
the
primary
path,
the
link,
a
protected
link
upon
failure.
You
will
notice
in
the
data
packet,
we
are
pushing
an
extra
header,
the
orange
header
here,
which
will
take
us
on
the
bypass
IP
path.
O
O
So
on
this
slide,
I'm
showing
how
we
can
actually
share
the
forwarding
state
in
the
data
plane
between
different
IP
paths
originating
from
different
ingresses.
We
have
the
green,
blue
and
red
paths.
You
can
call
them
and
they're
all
terminating
on
our
five.
Our
five
has
an
egress
address
block.
So
once
we
set
up
the
green,
whatever
path
comes.
First,
we
assign
the
the
address
egress
address,
192
168
5.1,
the
next
IP
path
that
comes
in
our
five
can
do
a
a
validation
check
to
see.
O
O
K
G
G
O
We
are
considering
loose
paths
as
well.
There
are
certain
conditions
that
we
have
to
be
aware
of
that
can
create
certain
unexpectable
loops
so
with
loose
paths,
so
they
are
possible.
You
could
do
the
loose
path,
but
as
RSVP
is
strictly
routed,
we
are
sticking
to
our
SVP
kind
of
so
we
set
up
the
path.
G
O
G
O
G
R
G
O
G
A
A
G
H
G
O
G
O
H
O
A
O
O
So
when
the
people,
let
me
see
you
in
the
previous
so
yeah
we
we
are
saying
that
these
address
blocks.
They
don't
need
to
be
routable
they're,
not
advertising
in
igb.
They
can
be
from
the
private
address
space
like
the
well-known
private
address
space
in
ipv6
or
ipv4,
and
they
can
grow
dynamically.
They
don't
have
to
be
statically
provisioned,
so
on-demand
resizing
is
possible.
G
O
O
G
S
O
T
O
T
T
O
T
U
O
G
A
A
U
A
U
For
giving
me
the
chance,
I'll
try
to
be
quick.
Okay,
my
name
is
Billy.
Oh,
this
is
a
new
work.
We
call
it.
I
can
instinct
congestion
assessment
network
and
we
considered
it
as
kind
of
data
playing
traffic
engineering
technology
in
terms
of
Tears
context,
and
please
note
that,
although
the
the
other
draft
only
has
one
other
which
is
me,
but
it
is
actually
a
very
solid
team
work,
including
pollution
design
and
product
development-
we've
been
working
on
this
for
more
than
one
year.
U
U
So
we
propose
the
icon
solution.
First,
we
still
rely
on
the
centralized
controller
to
calculate
multiple
paths
for
each
pair
of
ingress,
router
and
egress
router.
This
could
be
done
in
fairly
slow
control.
Loop
say
at
Ephesus
may
be
his
meanness
level
or
even
longer,
and
after
that
the
job
will
handle
to
the
rotors
and
the
rotors
will
to
the
pass
congestion
assessment,
and
then
it
will
decide
which
flow
need
to
be
switched
from
one
pass
to
another,
and
this
process
is
totally
done
by
the
rotors
by
themselves,
without
any
interference
of
the
controller.
U
U
U
A
A
D
Name
is
Micah
coffin.
The
specific
case
is
big
as
a
member
of
the
TV
area
Directorate.
So
please
be
aware:
if
you
do
something
like
that
on
millisecond
times,
you
can
interact
with
the
congestion
control
loop
on
the
end
systems,
and
you
have
to
look
at
that
very
early
in
the
design,
because
this
time
scale
you
have
another
control,
several
other
control
loops
in
the
overall
system,
and
you
have
to
avoid
that
the
control
hopes
interact.
So
you
have
to
look
at
the
congestion
control,
loops,
Thank.