►
From YouTube: IETF103-TEAS-20181106-1610
Description
TEAS meeting session at IETF103
2018/11/06 1610
https://datatracker.ietf.org/meeting/103/proceedings/
A
A
A
A
In
terms
of
logistics,
this
session
is
being
streamed,
both
video
and
audio.
For
the
sake
of
folks
for
the
benefit
of
folks
who
are
participating
remotely,
please
do
speak
only
using
the
microphones.
Please
state
your
name
before
speaking.
We
did
talk
about
ether
pad.
We
are
also
on
jabber,
so
please
feel
free
to
join
us
there,
folks,
who
are
participating
remotely.
Please
do
join
the
me
taker
queue.
If
you
have
something
to
say.
A
Nothing
has
changed
in
terms
of
personnel
since
yesterday,
I'm
Pavan,
biram
blue
bucket
to
my
right
and
our
secretary
is
still
Matt
Hartley.
So
that
said,
let's
just
jump
right
into
the
session.
We
will
pick
up
from
where
we
left
off
in
yesterday's
session.
If
Sergio,
if
you're
here,
can
you
walk
up
to
the
Sergio.
B
C
C
Wait
people
just
take
a
seat,
so
the
motivation
of
this
craft
is
to
fit.
The
existing
models
has
been
designed
in
different
working
groups
into
the
existing
HDR
capture,
which
has
recently
be
published
as
RFC
and
after
the
previous
meeting.
The
main
change
of
this
draft
is
something
editorial
by
clarifying
the
obstruction
and
performance
monitoring
description
and
the
fixed
previous
issues
on
this
kind
of
topics,
and
we
also
provide
some
description
on
how
the
multi-window
can
do
the
inter
up
in
the
a
setting
architecture
and
for
the
specific
models
and
corresponding
interface.
C
We
link
more
related
graphs,
saying
layer
number
one
two-story
service
model
into
the
exiting
architecture,
and
we
also
add
some
description
about
the
southbound
interface,
so
you
earlier,
this
was
not
in
the
scope
out
facing
team,
but
we
only
provide
some
information
for
description,
and
this
is
useful
between
the
PNC
and
device.
Next
Chris.
C
So
here
is
the
CMI
interface
model
usage.
After
the
updating
and
the
change
is
highlighted
here,
we
basically
adding
the
layer
one
two
three
service
model
into
the
CMI,
and
this
should
be
co-located
with
hazard
models,
including
the
we
ends,
the
service
mapping,
topology
obstructions
everything,
and
we
we
have
actually
as
a
other
document,
describing
how
to
connect
between
these
models.
C
C
And
then
we
also
update
the
MPI.
Modeling
usage
is
a
mainly
changes
to
as
microwave
into
the
how
architecture
and
though
we
as
a
microwave
body,
model
abstraction
as
technology
technology,
specific
options
and
it
would
be
coexist
with
other
technologies,
specific
models,
including
ot
and
W.
So
that's
great
everything
next.
C
So
this
document,
the
summaries
summarize
how
the
a
city
in
interface
can
use
what
kind
of
ITF
young
models
and
the
related
models
referenced
in
this
draft
is
basically
becoming
stable
and
another
good
news
is
a
sitting.
Framework
has
been
published
as
RFC,
but
I
believe
there
is
always
new,
coming
young
models
and
should
be
fit
into
the
whole
architecture.
So
we
are
looking.
We
will
look
into
this
in
the
future,
but
currently,
on
the
perspective
of
the
author,
so
we
believe
this
document
is
ready
for
the
working
group.
Last
call
that's
all
thank.
C
A
C
A
D
Daniela
I
totally
agree
with
your
question.
The
point
is
that
here
we
are
referencing.
A
huge
number
of
documents,
so
probably
is
a
good
idea
to
define
a
subset
which
we
are
going
to
wait
for
and
then
progress,
I
agree
with
you
that
at
least
at
the
basic
1t
topology
t
tunnel
path,
computation
I
would
say
could
be
my
proposal
as
the
showstopper
for
the
drafter,
but
then
we
can
okay.
We
cannot
wait
forever,
but
I
get
with
you.
Probably
these
free.
It's
my
proposal.
F
So
this
is
just
a
since
we
are
starting
with
the
session
just
to
show
you
where
all
the
a
CT
and
yang
models
and
other
te
young
models
kind
of
fit
in
and
some
of
which
are
going
to
be
discussed
next.
So
what
you
see
a
service
model
on
top.
This
is
the
augmentation
of
all
the
service
model.
This
was
earlier
tea
service
mapping,
which
I
think
is
the
next
presentation
as
well.
So
now
we
are
orienting
the
service
model
with
the
underlying
te
information.
F
These
are
the
three
different
levels
of
mapping
that
we
have,
so
this
is
just
gives
you
a
weight.
Is
the
all
these
model
kind
of
fits
in?
What
is
in
a
CT
in
Vienna,
myung,
V
and
yang
model,
just
as
a
high
level?
This
is
the
yang
model
that
that
models,
the
VNS
operations,
which
are
defined
in
the
framework
and
the
info
model.
F
It
is
from
the
point
of
view
of
customer
it's
on
si
mi
after
all
and
the
abstraction,
it's
basically
an
abstraction,
a
higher
level
abstraction
on
the
tito
book
and
the
tee
tunnel
model.
And
of
course
we
depend
on
those
models
and
I
will
show
you
what's
the
relationship,
so
they
there
is
some
similarity,
but
they
are
quite
different
as
well.
So
this
will
give
you
a
very
high
level.
What
is
the
relationship?
We
have
an
AC
T
and
V
n
model
which
references
the
T
topology
model
as
a
single
node.
F
So
that's
what
you
see
as
the
second
level,
the
single
node
in
a
tea
topology
model,
and
then
we
use
the
connectivity
matrice
information
that
exists
in
unknown
to
further
have
underlay
topology
at
multiple
recursions.
So
you
could
have
an
abstract
topology,
the
third
level,
which
is
VN,
which
could
is,
which
is
also
very
useful
for
VN
type,
two
and
then
at
the
end,
you
have
the
native
tea
topology,
which
is
also
on
the
same
model.
F
F
This
is
something
that
we
went
over
last
time
as
well,
but
just
to
refresh
what
do
we
mean
when,
when
we
say
that
a
CT
n
VN
points
to
a
single
node,
this
is
basically
what
it
looks
like.
So
in
a
single
node
in
the
T
topology
model,
you
have
connectivity
matrices,
which
is
the
generic
property
belonging
to
all
the
elements
in
the
matrix,
and
then
you
could
have
very
specific
properties
assigned
to
each
of
the
connectivity
matrix
entry
as
well.
F
Example,
from
the
customer
point
of
view,
we
would
simply
have
I
have
this
VN.
It
has
four
VN
members.
Those
are
the
points
that
needs
interconnection
and
when
you
set
them
up,
these
are
the
properties
for
these,
so
these
basically
maps
to
with
a
reference
in
the
T
topology
model,
one
node,
all
the
attributes
go
to
the
connectivity
matrices
this
setting.
So
we
have
this
relationship,
but
from
customer
point
of
view
he
can
think
of
it
as
a
VN
which
maps
to
a
tea
topology
model.
F
This
is
VN
type,
two,
with
the
difference
that
you
have
a
single
node
topology
on
top,
but
also
have
a
VN
topology,
which
is
an
abstract
topology
that
you
show
to
the
customer,
and
customer
can
also
set
parts
based
on
these
two
T
to
power
based
on
this
VN
type,
two
topology
and
it
is
all
modeled
in
the
same
fashion
as
before.
So
you
have
a
CT
n,
simply
V
n
VN
member.
F
It
points
to
a
single
abstract,
node,
the
single
abstract,
node
use
the
underlay
path
to
refer
to
the
VN
type
to
and
which
can
further
recursively
point
to
the
actual
native
T
topology
and
just
the
what
was
the
main
idea
behind
it.
When
we
wrote
the
actn
info
model,
these
were
the
set
of
actions
that
we
standardized
in
RFC
845.
For
that
you
have
be
an
instantiation
V
and
modify
V
and
delete.
So
our
main
aim
with
this
yang
model
was
how
to
clearly
map
these.
F
Are
these
primitives
that
were
define
in
the
info
model
into
a
clear
yank,
but
at
the
same
time
there
could
be
various
operations
that
you
can
do.
You
could
create
a
V
and
explicitly
that's
where
the
VNS
comes
into
picture
when
you
are
explicitly
creating
a
VN
or
the
VN
could
be
automatically
created.
What
is
the
case
for
that?
The
tea
service
mapping
that,
when
you
customer,
only
creates
the
service
and
the
VN
mapping
to
this
is
automatically
created.
F
So
there
is
no
config
happening
here,
but
it's
automatically
created
like
an
auto
tunnel,
just
to
equate
it
to
how
that
works.
It
exists
in
the
state,
but
that
state
information
is
very
useful.
So
you
can
map
to
how
this
service
is
using.
What
in
your
network
right
and
then
we
in
the
document
you
will
see
there
are
some
advanced
use
cases
as
well,
where
the
actn
VN
helps
such
as
multi-source
multi,
resonation
and
VN
compute
use
cases
status.
F
G
Adrian
Farrell,
thank
you
drove
I've
been
trying
to
do
my
technical
adviser
thing
and
get
between
the
authors
and
the
chairs
on
is
the
this
VN
model.
Does
it
have
a
purpose
or
should
we
simply
use
the
T
model
and
I
found
your
slides
quite
good
at
explaining
what's
different
and
how
the
VN
model
is
like
a
wrapper
on
the
T
model?
So
I
have
a
question
for
the
chairs:
do
the
chairs
see
that
a
bit
more
clearly
now
or
does
there's
more
work
need
to
be
done
to
explain
it
I
think.
G
B
G
Assuming
what
answers
my
question
Lou
but
might
be
I,
have
some
respect
for
the
chairs,
although
it
may
not
be
apparent
at
the
moment
and
and
the
chairs
were
expressing
that
they
as
chairs
or
as
individuals.
Reading,
the
document
had
some
lack
of
clarity
about
the
where
it
fitted
in
so
I'm
asking
whether
that
whether
we've
managed
to
clear
that
that
lack
of
clarity
or
whether
more
work
is
needed.
Okay,.
B
G
B
G
Sir,
there
was
a
specific
issue
that
was
raised
and
and
yeah
it
was
a.
It
was
a
good
question,
which
was
what
what
is
the
difference
between
this
and
simply
using
the
team
offer
and
and
I
thought
dhruv
did
quite
a
good
job
of
explaining
what
that
was
and
I'm
asking
did
that
explanation
make
it
help,
make
it
clear
to
you
or
do
we
need
to
do
more
work
to
explain
that
again.
B
G
B
If
you
I
do
have
a
technical
question,
it's
not
the
one
you're
asking
and
if
you
let
me
I
would
answer
ask
it
now.
If
you
want
to
ask
the
question
ain't,
it
want
me
to
answer
the
question
that
you're
asking
is:
do
we
have
sufficient
justification
to
have
a
separate
model
from
Te,
topology
I
think
we've
covered
that.
B
G
B
B
For
example,
I
go
through
this,
isn't
a
comment
on
the
description.
I
think
the
description
is
pretty
clear,
but
if
you
go
through
the
actual
model,
it
seems
that
there's
nothing
actn
specific,
it's
all
about
virtual
node
control
and
there
the
the
description
of
a
virtual
mode
and
mapping
that
down
the
topology
all
good
stuff.
B
F
I
think
you
can,
but
my
confusion
is
like
I
think
this
happened
during
a
chartered
discussion
as
well.
Maybe
we
kind
of
think
of
this
in
a
little
different
way
in
my
mind,
when
we
do
talk
about
AC,
T
and
V
n
BN
is
a
generic
thing
in
such
as
a
virtual
network,
but
we
define
V
n
in
the
context
of
what
a
CTN
can
do
so
in
this
model.
Of
course,
it
is,
but
if
he
adds
something,
for
example,
if
we
say
that
this
needs
to
be
used
for
network
slicing.
B
He
had
to
do
it
with
this
model,
because
they're
not
implementing
actn
and
I,
don't
think
we
want
to
stop
them.
So
if
this
is
in
fact
a
flick
generally
applicable,
the
only
change
we
have
to
do
is
to
the
model
I'm.
Not
talking
about
to
the
document
go
to
the
model,
remove
the
turn
actn
and
then
the
next
one
come
along
and
say:
yeah
just
use
this
not.
F
D
J
So
I
I
agree
what
a
loose
saying.
So,
basically,
when
we
talk
about
the
city
and
and
the
models
are
a
city
and
user,
it's
pretty
much
everything
that
we
are
doing
in
this
group
right
so
so,
and
those
building
blocks
it's
just
like
a
just
players:
okay,
they
could
be
put
in
one
way
or
another
or
could
be
used
individually.
J
So,
for
example,
if
you
use
IT
topology
model
say
in
how
we
were
saying
that
you
are
using
the
CTN,
but
it
doesn't
necessarily
mean
that
the
solution
needs
to
be
anything
to
do
with
the
city,
and
it
could
be
like
any
other,
like
a
framework
that
just
happens
to
use
the
polity
model.
Okay,
thank
you.
K
K
You
know
we
proposed
originally
tea
service
mapping
as
a
single,
independent
young
model
and
I
think.
The
argument
was
why
not
augmenting
existing
service
model
layer,
1
layer,
2
layer,
3
service
model
and
then
share
the
same
grouping
by
creating
some.
You
know,
grouping
model
so
there's
some
discussion
and
I.
Think
I
personally
was
convinced
with
cherry
suggestion,
to
simplify
and
operationally
I.
Think
augmentation
up
is
simple,
because
it's
just
one
model,
and
so
we
change.
You
know
young
structure
without
changing
the
capability.
K
So.
In
doing
so,
we
reorganize
a
little
bit
of
VN
and
T's
tunnel
selection
policy.
One
of
the
main
changes
is
we
put
isolation
requirement
which
is
not
expressed
in
original
service
model
in
the
context
of
network
slicing
like
hard
isolation
with
deterministic
characteristic
for
certain
PPN
instance.
This
service
may
require
a
very
hard
isolation
and
the
deterministic
latency
means
that
there's
no
little
overview
of
variation
of
the
latency
and
hard
isolation
and
soft
isolation.
K
I
think
this
one
is
kind
of
synergistic,
with
what
dongji
we're
going
to
present
a
VPN
plus
framework,
and
then
we
added
another
type
which
is
like
availability.
Certain
DP
an
instance
are
require
higher
availability,
then
the
others.
So
we
specify
that
as
a
one
of
the
map
type
yeah.
So
this
look
like
or
layer
I
believe.
K
Yes,
so
this
is
a
layer,
3
SN
T
cells
in
epping,
which
is
augmented,
augmented
model
of
layer,
3
SN,
and
likewise
this
is
layer
2,
and
this
is
layer
1.
So
the
structures
are
almost
identical
and
layer,
1
CS
and
has
a
little
bit
different
structure,
so
it
looked
different
a
little
bit,
but
basically
it
shares
the
same
grouping
that
we
defined
as
a
separate
young
model,
so
I
think
next.
Step.
I
think
also
believe
that
this
draft
is
a
good
base
for
any
working
group.
Adoption.
B
J
L
B
How
many
think
that
this
is
a
topic
we
should
be
working
on
so
again.
This
is.
That
seems
like
a
reasonable
number.
How
many
have
read
the
document
I'll
note
that
it's
a
it's
actually
more
than
think
we
should
even
be
working
on
the
topic.
That's
sort
of
interesting,
usually
it's
the
other
way
around.
B
How
many
think
that
this
is
a
something
that
we
should
adopt
as
the
foundation
is
the
starting
point
for
work
on
the
topic
in
the
working
group.
Remember
and
just
keep
in
mind
when
we,
it
doesn't
say
that
the
solution
is
locked.
It
says
that
this
is
where
we're
going
to
start,
and
you
can
change
so
who
thinks
that
it's
a
good
starting
point
I,
think
that's
a
very
reasonable
moment,
so
we'll
take
it
in
list.
Okay,.
K
K
Let
me
read
the
title:
young
mothers
for
tea
performance,
monitoring,
telemetry
metal,
autonomics,
okay,
yeah.
Basically,
this
model
support
performance
monitoring
telemetry
as
a
report
of
48
owners
and
a
CTO
NBN's
okay.
So
we
have
two
modules:
8ft
KPI
telemetry
and
ITF
ICT
nte,
KPI
telemetry,
and
if
you
want
Lou
I
can
replace
AC
10
at
the
end.
B
K
B
Be
clear,
I'm
talking
about,
and
actually
we
both
agree
on
this
is
that,
if
we're
defining
a
solution,
we
shouldn't
constrain
ourselves
just
to
actn
based
solutions.
So
if
someone
wants
to
build
a
controller
base
model
that
they
say
is
not
conformant
with
a
CTN,
but
they
still
want
to
implement
this
model.
They're
free
to
do
so,
and
that's
that's
really
what
we're
all
about?
It's,
not
that
we're
anti
actn!
You
know
we're
all
about
the
the
controller
based
approach.
That's
AC
yeah!
So.
J
B
K
K
So
why
don't
you
use
stem
data,
so
data
stir
history
and
then
in
the
revision
of
tea.I
tivity
types,
which
was
just
separated
out
from
the
tunnel
model,
I
think
or
Turek
and
other
quarters
work
hard
to
define
at
this
model,
and
in
doing
so
we
actually
reshape
a
performance
metric
container
grouping
to
have
a
one-way
and
two-way
performance
related
data.
For
delay
and
and
packet
loss
and
so
on,
and
let
variation
and
so
on
so
basically
a
dis
model
input
that
I
TFT
types
and
then
we
don't
reinvent
any
parameters
used
for
this
model.
K
We
just
import.
So
that
is
the
resolution
and
why
this
is
different
from
stamp
stamp.
First
of
all
doesn't
have
anything
about
bandwidth,
but
we
need
Bendis
so
which
is
actually
imported
from
IETF
routing
types
again
and
stamp
is
more
measurement,
but
this
is
more
reported
as
a
concatenated
information,
not
just
link
data,
because
we
have
to
give
customer
tunnel
view
or
VN
view.
K
So
that's
the
resolution.
So,
as
I
said
here,
we
use
a
T
types
for
the
group
being
defined
in
arty
types,
specify
performance
data
on
te,
KPI,
telemetry
and
also
I,
see
TNT
KPI
telemetry.
We
use
the
same
thing,
so
these
are
the
gist
of
the
model.
I'm
not
going
to
go
in
detail,
but
we
can
take
a
look
at
online.
K
K
Know
our
assumption
is
always
IP
is
a
server
layer
and
optical
is
a
IP
is
a
client
layer
and
optical
is
a
server
layer.
So
we
are
talking
about
in
the
multi-layer
multi
domain
context.
You
always
hit
router
elements.
It's
not
your
secure,
end-to-end
transport,
that's
not
our
scope
here.
Our
scope
here
is
multi
domain
multi-layer
networks,
there's
always
a
packet
optical
interaction
and
that
caused
some
delay
and
delay
variation.
So
it's
not
necessarily
technology
specific,
but
that's
the
reality
of
the
network
context
that
we
are
modeling.
K
M
K
B
B
G
B
K
O
K
D
So
if
the
issue
is
I
want
to
deploy,
it
is
on
something
that
has
nothing
to
deal
with
packet,
switching
and
so
I
don't
want
to
implement
packet
loss.
I
think
we
could
separate
the
module,
but
I
wouldn't
go
for
another
draft
with
one
just
one
one
thing.
So
if
this
is
the
requirement
I
think
we
can
do
it
as
an
augmentation,
but
I
mean
we
risk
a
to
have
tens
of
documents
and
then
I
said
keeping
everything
together
is
a
risk
also
because
this
would
be
a
document
to
belong
into
another
working
group.
G
G
P
A
G
K
Have
a
location
one
and
you
have
a
two
destination
location.
You
know
load
balance,
maybe
utilization,
so
I
think
scaling
intent.
Basically,
you
can
define
you
know
your
when
a
certain
utilization
exceed
or
below
you
see
customer
be
able
to
program.
Please
set
when
those
things
happen.
I'd
like
to
see
you
know,
load
balance.
You
know
in
different
way.
Well
you
know
things
like
that.
So
it
depends
on
performs
many
monitoring,
parameter
or
yeah.
A
A
K
B
K
P
Tariq
again
so
the
the
the
the
grouping
that
we
define
it.
He
types
it's
actually
applicable
to
multiple
packet
technologies
and
PLA.
This
is
what
it
always
tena
me
in
Ethernet.
They
wanted
to
use
the
same
grouping,
so
it
is
kind
of
genetic
but
not
applicable
to
optical.
Maybe
so
we
can
take
out
these
groupings
because
they're
prepackaged,
specific
I,
don't
mind
and
put
it
there
or
I.
B
G
K
B
K
N
A
Q
Q
It
includes
enhancements
in
the
data
plane
so
as
we
could
provide
different
levels
of
isolation
from
the
soft
isolation
to
the
hard
isolation,
and
he
could
also
provide
a
determinism,
a
packet
loss
on
delay
and
in
the
control
plane
posted
under
a
and
overly
control.
Protocols
need
to
be
considered
so
as
to
enable
the
integration
of
the
physical
network,
the
virtual
networks
and
the
services.
Q
Q
Okay,
this
diagram
shows
the
spectrum
of
the
resource.
Isolation.
I
should
think
this.
The
concept
of
isolation
has
been
disgusting.
This
draft.
We
can
see
that,
on
the
left
hand,
we
have
the
statistic
multiplexing,
which
we
already
have
today
and
on
the
right
end,
we
have
the
absolute
isolation
which
can
be
provided
by
dedicated
networks
and
what
enhanced
VPN
I'm
still
provided
is
something
in
between
which
is
called
pragmatic
isolation.
In
this
case,
the
purpose
is
to
we
provide
some
necessary
isolation
in
some
of
the
aspects.
Q
Well,
we
still
allow
some
resource
sharing
in
other
aspects
so
that
we
can
achieve
them
more
economical
solution
for
the
brilliant
requirements
in
the
emerging
services.
So
here
the
certain
resource
here
can
be
any
natural
resources
in
the
either
the
data
plane,
the
control
plane
or
the
management
plane.
Q
Okay,
he
released
the
candidate
technologies
in
different
layers.
This
list
is
not
exhaustive,
just
some
typical
technologies
we
can
use
hope
to
first
in
the
annual
a
data
plane.
There
are
several
candidates,
for
example,
the
floods
go,
isn't
that
we
can
use
as
a
dedicated
queues
to
provide
some
isolation
that
underlay
forwarding
plane.
Also,
the
time-sensitive
networking
is
another
option.
Then,
in
the
natural
layer
we
can
use
several
technologies
to
build
the
enhanced
VPN
service,
which
is
we
can
either
use
I'm
here
te
week.
Q
I
think
it's
already
available
today
and
we
could
also
build
it
based
on
the
Stegner
RT.
Either
a
service,
an
arrest
or
as
a
v6
post
can
be
used
and
detonator
is
another
candidate
technology
in
this
layer
and
actually
wasting
some
may
be.
Some
enhancement
will
be
needed
to
integrate
that
net.
With
a
virtual
networks
requirements
in
the
control
plane,
we,
you
can
see
the
posted
distributed
protocols
and
the
centralized
model
for
the
distributed
protocols.
The
ISO
apt
is
one
option.
Q
Q
Okay,
here's
some
history
of
this
document.
Actually
this
draft
has
been
submitted
and
presented
since
ITF
99.
It
was
firstly
submitted
to
RT
g
WG
and
also
presented
in
the
nano
slicing
path.
Then
in
the
following
ITF,
it
has
been
updated
with
more
information
like
architectural
sections
have
been
updated
so
that
we
can
have
a
more
complete
view
about
this
overall
framework
and
ITA
101.
After
the
presentation
the
chairs
suggested,
we
move
this
draft
to
T's.
That's
why
we
come
to
this
working
group
and
then
in
last,
IDF.
Q
Q
Okay.
This
is
the
latest
update
since
the
last
idea.
Basically,
we
add
new
references
to
the
network.
Slicing
related
works
in
the
industry
and
we
clarify
the
description
of
the
isolation
requirement
in
the
requirements
section
in
the
candidate
technologies.
We
simplified
the
introduction
to
the
same
routing
because,
because
in
this
framework,
it
is
just
one
of
the
candidate
technology
and
we
also
update
a
control,
plane,
subsection
and
add
a
new
subsection
for
the
management
plane.
Q
We
also
had
new
references
to
the
candidate
technologies
in
the
draft
and
there
are
also
some
editorial
changes
to
improve
the
readability
of
this
draft.
Okay.
So
for
the
next
steps,
I
think
this
trump
has
been
discussed
widely
at
a
number
of
meetings
in
ITF,
and
this
draft
actually
is
a
foundation
of
other
relative
drafts
in
the
other
working
group
like
in
spring
and
in
the
air
SR.
There
will
be
also
more
related
protocol
extensions
in
the
other
working
groups.
R
Hi
kitten
sisqó.
Yes,
so
this
document
has
been
presented
several
times
and
it's
an
informational
draft.
Yes,
but
it
has
a
lot
of
things
that,
as
you
mentioned
in
this
presentation-
and
it
looks
like
it's
attempting
to
define
some
sort
of
an
architecture
right
right
and
that's
really
going
into
spring
and
NSR
and
all
of
those
areas.
So
the
question
is:
is
this
I
mean
what's
the
here
to
standardize,
or
is
it
just
like
a
white
paper,
because
the
standardization
or
whatever
changes
you
need
I,
believe
you
have
in
the
other
drafts
right
just.
B
S
E
S
B
You
clarify
what
your,
what
your
objection
is
or
what
your
question
is
about
the
draft.
If
it's
I
heard
a
couple
of
different
things,
I
heard
something
about
architecture
and
I
heard
about
what's
the
value
of
an
informational
document,
so
I
from
a
process
standpoint.
This
is
the
right
working
group,
there's
no
other
working
group
that
can
talk
about
traffic
engineering,
architectures,
yeah,.
R
R
B
R
B
But
it
is
a
reasonable
question
of
what's
the
point
and
is
there
value
so
the
question
will
be
to
the
working
group
is:
there's
a
working
group
C
value
in
it,
and
if
the
workgroup
sees
value
great,
we
can
move
forward.
If
enough
people
feel
like
the
person
who's
asking
the
question
that
there
isn't
value,
we
won't
vote.
We
won't
move
forward
so
that
that's
our
process
so.
T
E
T
I
think
the
question
is
that:
do
you
need
a
super?
Seven
then
I
also
have
problem
with
the
with
the
terminology,
like
it
looks
very
much
marketing
thing,
which
is
not
our
idea
of
does
solely
pn+
or
enhanced
EPN,
and,
and
all
of
that
so
I
mean
I,
have
serious
objection.
It
would
be
fair
if
we
have
some
discussion
on
both
drafts
and
this
draft
is
asking
for
basis
which
is
not
needed.
Some
requirements
are,
are
posted
here.
T
Some
ways
very
specific
ways
are
proposed
here
that
are
not
needed,
and
this
has
to
be
studied
and
any
also
is
has
to
be
studied
by
spring
working
group
as
well.
It's
not
just
a
decision
of
teeth
working
group.
It
is
multiple
working
groups
that
has
the
study.
This
is
this
is
the
right
direction.
If
this
is
what
you
want
to.
G
T
T
T
B
C
U
G
V
V
I
think
it
would
be
good
to
clarify
in
the
document
what
type
of
scalability
in
terms
of
state
which
we
are
expecting
when
using
these
type
of
things,
because
it
probably
the
reason
why
I
am
asking
is,
it
might
say
which
technologies
are
in
scope
or
not
in
school,
because
I
think
the
scale
is
an
important
factor
in
this
architectural
framework
to
clarify
I
think
what
we
aim.
Chief
with
this
I.
B
Steering
or
PE
as
I
started
to
call
a
path
engineering,
and
that
means
something
very
different
and-
and
you
have
two
different
people
that
are
hearing
a
term
and
thinking
oh
yeah
I-
want
to
use
that
and
that
that
solves
my
problem.
The
problem
is
one
one
set
wants
to
use
it
for
one
way
and
it
implies
certain
state
pieces
and
other
want
to
use
it
another.
We
really
need
a
good
definition,
and
this
doesn't
belong
here,
a
good
definition,
what
srte
or
PE
or
whatever
you
want
to
call.
B
It
is
so
that
the
two
different
groups
can
understand
that
they're
actually
talking
about
different
things
and
so
I
think
part
of
what
we're
hearing
here
is
you
have
one
group,
the
ones
that
are
here
that
are
they're,
saying
srte,
of
course,
includes
resource
management
in
the
network,
because
that's
what
te
means
and
we
have
another
parts
that
says.
Of
course
it
doesn't
because
tesr
is
all
about
stateless,
so
I
think
we
have
a
larger
problem
that
that's
causing
a
little
bit
of
this
conflict.
Yester.
T
The
second
point,
just
to
what
Wynne
said
when
and
and
I
completely
agree
with.
What
we've
said
is
is
that
when
we
add
these
states
in
the
network
for
this
bandwidth
management,
there
has
to
be
some
scaling
and
Lissa's
there,
because,
if
your
support,
let's
say
proposing
using
agency,
said
along
the
path
that
has
to
be
properly
documented
in
the
article
document,
what
are
the
implications?
Scale
implication
on
that.
So
from
that
angle
is
lacking.
So.
B
I
think
of
srte.
That
said,
it
excluded
the
resource
management
that
would
have
that
if
it
said
it
included
resource
management,
we
would
have
that.
So
we
need
that
definition
first
or
we
need
that
definition.
That'll
help
and
then
we'll
understand
that
we're
talking
about
different
things
with
I
completely
agree
different
state
implications,
Danijela.
D
B
That
an
outline
of
that
document
was
actually
written
in
order
to
prepare
for
the
the
presentation
that
was
given
on
Sunday
by
the
two
people
sitting
in
the
front
row.
Nestor
Stewart
talked
about
te
in
the
in
the
ITF,
so
maybe
if
they
turn
that
document
into
a
draft
who
they
have
exactly
what
you're
saying.
L
They
don't
mean
for
me,
so
I
think
that
that's
the
marketÃs
caution
about
this
to
the
srt,
in
fact
that
we
proposed
the
draft
about
the
sr
for
the
net
host
I,
see
yeah,
so
I
think
that
this
is
the
framework
uses,
not
a
user
confined
who
the
confined,
who
is
our
this
is
our
safety,
so
I
think
that's
the
later.
Maybe
move
on
to
more
discussion
for
the
heart
heed,
and
also
that's
the
the
same
user
that
also
maybe
discussion
the
heart
key
for
the
network's
Lyceum
for
William
class.
L
B
W
Thanks
guys
yeah,
so,
hopefully
the
motivation
for
switching
the
order
will
become
clear
momentarily
right.
So
this
is
the
ability
of
ACM
to
network
slicing
and,
yes,
it
is
hdn
because
it
specifically
talks
about
actn
and
its
applicability
to
network
slicing.
We
can't
generalize
that
this
was
a
piece
of
work.
Actually,
the
original
motivation
for
this
document
was
to
present
a
debuff
I
think
it
was
cons
when
we
were
looking
at
network
slicing
and
the
potential
technologies
from
management
control,
plane
and
also
potentially
forwarding
as
well.
W
So
it's
really
sort
of
something
that
was
just
very
informational.
It
was
never
really
intended
to
be
anything
more
than
just
a
discussion
document.
Specifically
for
that
session.
What's
happened
is
we
started
continuing
to
develop
the
document
trying
to
think
about?
What
do
we
mean
in
this
working
group
for
network
slicing
when
we're
looking
at
the
kind
of
traffic
engineering
requirements?
W
What
are
the
parameters?
Its
network
connectivity,
its
bandwidth,
there's,
also
components,
functions
that
need
to
be
interconnected
in
order
to
provide
some
kind
of
service,
and
then
we
started
looking
at
the
DNA
of
the
potential
solution
that
you
would
use
in
an
HTM
based
environment.
So
we
would
have
the
the
HTM
functional
components
we
would
have
so
that's
on
the
left
there.
W
W
Now,
of
course,
we
can't
decide
on
sort
of
behalf
of
everyone
and
in
the
room
if
this
is
the
right
way
to
go.
But
our
proposal
is
to
take
the
previous
document
as
you,
as
you
saw
in
the
previous
presentation.
It's
really
a
discussion
document
that
talks
about
sort
of
requirements
for
VPN
and
network
slicing
the
potential
management
control,
plane
and
forwarding
technologies
that
you
can
use
a
CTN
is
just
going
to
be
one
subsection
within
that
document
and
really
we're
not
saying
that
ACN
is
the
only
way
that
you
can
achieve
network
slicing.
W
G
W
Yes,
so
that's
that's
kind
of
our
current
thought
is
to
maybe
take
portions
of
of
this
document,
move
it
into
the
previous
document
sort
of
as
a
subsection
talking
about
the
flick
ability.
What
I
was
also
kind
of
thinking
about
with
my
co-authors,
for
this
document
was
preparing
a
version
of
whether
you
know,
let's
call
it
this
composite
document.
W
G's
G's
document
with
this
now
sort
of
potentially
be
a
document
that
we
would
have
an
informal
and
maybe
a
formal
liaison
to
some
of
the
standards
organizations
that
are
looking
at
network
slicing
solutions.
So
that's
another
question
I
have
for
the
working
group
and
a
question
I
have
for
the
chairs
is
for
my
process
perspective.
Would
we
wait
for
a
document
to
be
adopted
by
the
t's
working
group
before
we
actually
had
a
formal
liaison
to
another
standards
organization
say:
look:
we've
got
a
discussion
document
on
network
slicing.
B
X
X
This
type
of
work
is
itu.
Ascetic
with
15
they've
started
a
5g
work,
so
you
could
lay
eyes
on
to
them.
Just
saying
we
have
interest
to
to
look
at
architectures
to
support
5g
or
network
slicing
and
we'd
be
interested.
If
you
would
communicate.
You
know
the
standard
words
we
used
to
you
know
if
you
can
communicate
with
us
on
on
any
work,
you're
doing.
V
X
X
Is
going
full
blast
along
with
this,
and
the
only
thing
I
would
caution,
also
on
the
individual
documents,
because
I
saw
on
the
earlier
one,
the
data
plane
technology
was
flexi.
Well,
that's
not
the
only
data
playing
technology
and,
in
fact
that
one,
depending
on
how
you
define
flexi,
is
not
standard,
so
be
very
careful.
I
would
be
very
careful
on
any
linking
even
to
individual
documents.
Just
say
just
make
something
very
general.
You
know
you
started
looking
at
this.
B
G
Adrian
Farrell,
so
there's
a
win-lose
in
here
for
odo
consultant,
so
Dan
is
carefully
getting
himself
off
edit.
Two
things
and
I
find
myself
being
the
person
doing
the
merge.
So
these
are
all
individual
drafts
at
the
moment,
so
I'm
working
with
the
author's
across
the
three
drafts
to
try
to
do
exactly
what
Dan
said
and
which
is
essentially
to
put
a
CTN
into
Jaden's
document
as
one
of
the
candidate
technologies
for
approaching
the
problem,
space
and
I
think
that's
working.
G
B
So
I
want
to
make
it
I
want
to
confirm
that
the
Adrian
and
well
the
authors,
think
that
it's
worthwhile
to
do
a
merge
of
the
documents
or,
if
they
think
we
should
ask
the
working
group
if
they
would
like
to
proceed
with
separate
documents.
So
I'm
asking
the
authors
of
the
individual
documents
which
way
they
prefer
and
the
interesting
thing
about
is
Adrian
and
Dan
may
argue
with
each
other
here,
because
they
have
may
have
opposite
interests.
Q
D
W
D
We
should
be
careful
with
saying
that,
for
us,
a
VPN
Plaza
is
a
metal
slicing,
because
if
we
merge
everything-
and
we
say
this
is
our
solution
for
metro
slicing-
we
are
implicitly
saying
that
the
BPM
plus
is
Metro
slicing,
not
one
of
the
possible
declinations
of
Metro,
slicing,
etc.
That's
what
I'm
saying
Netta
slicing
is
a
much
bigger
problem
is
not
just
VPN,
plus.
E
Yes,
it
was,
it
was
originally
intended
to
solve
the
data
plane
and
lower
layers
and
some
of
the
control
some
last
base
of
it
network
slicing.
It's
always
a
much
much
much
bigger
problem,
and
we
deliberately
when
we
first
did.
This
didn't
use
the
term
network
slicing,
because
we
were
trying
to
solve
a
problem
that
the
universe
was
useful
in
its
own
right
was
applicable
to
some
aspects
of
networks.
Licensing
and
network
slicing
is
a
very
controversial
subject
or
it
was
when
we
started
so,
but
it's
not
the
complete
solutions.
Network
slicing.
K
Okay,
it's
a
core
cause
of
one
or
two
of
the
three
drafts:
I
support
merger,
with
clarification
of
what
EPN
plus
and
that
tuck
slicing
means.
Also
another
thing
is
we
use
a
network
slicing
in
T's
working
group
for
te
network
slicing,
so
I
think
we
need
to
clarify
that
as
well.
We're
not
talking
about
3gpp
network
slicing,
but
transport
or
traffic
engineering
network
slicing.
That's
what
our
scope
is.
B
So
we
actually
need
to
wrap
this
up
because
we're
massively
over
time
so,
but
the
plan
is
for
some
document
merging
and
maybe
some
clarification
going
in
and
do
we
have
a
estimate
of
when
that
will
happen.
Are
we
talking
months
weeks?
I
was
okay,
so
all
right,
so
that
that's
gonna
be
pretty
quick.
So
we'd
like
to
see,
if
there's
interest
in
working
in
the
working
group
on
this
topic,
yet
so
who's
interested
in
working
on
the
topic
of
the
last
level
and
that's
a
very
healthy
number.
B
The
he
of
course
will
need
to
see
the
merge
document
to
know
whether
or
not
it
is
a
good
foundation
for
work
in
the
working
group.
I
think
we
would
like
to
give
him
the
level
of
interest
and
discussion
we'd
like
to
not
wait
for
the
next
meeting
to
do
a
poll
and
so
expect
the
chairs
to
take
a
look
at
the
document
see
that
it
matches
what
we
think
the
discussions
have
been
and
then
then
move
towards
a
poll.
T
B
Unfair
so
something's
adopted
that's
the
start
of
the
process,
and
the
nice
thing
is:
is
the
content
of
the
document?
The
the
ownership
of
the
content
moves
from
the
individual
authors
to
the
working
group,
so
it'll
be
perfectly
appropriate
at
that
point.
To
look
at
the
content
that
you
have
and
have
the
working
group
say
yeah.
B
We
want
to
bring
this
into
that
same
document
and
bring
it
in
and
we
could
even
do
a
replace
if
we
think
so,
if
that
that's
the
right
thing
so
just
because
we
adopt
doesn't
mean
we're
locked
in
stone
and
it
doesn't
mean
the
text
that
you
could
contribute
goes
on.
The
floor
means
that
there's
an
opportunity
to
bring
it
into
the
working
group
document.
Yeah.
T
U
This
draft
has
been
already
presented
in
the
sea
camp
last
time,
but
was
considered
more
technology.
Analytic
so
now
is
presenting
here
in
teeth.
So
what
is
the
purpose
of
this
draft?
The
purpose
is
to
present
to
make
some
consideration
about
the
fact
that,
with
respect
the
scenario
in
which
there
was
GPL,
as
in
the
network
and
maybe
with
the
animation
about
and
with
the
set
of
protocol
that
we
know
the
MPLS
is
base.
U
The
major
changes
since
the
last
IDF
is
replaced.
The
name
because
is
now
is
this
the
document
and
we
receive
some
comment
and
remove
some
signaling
option
like
a
CL
DP
and
we
have
updated
references.
There
are
other
comments
that
we
received.
We
have
not
time
to
address
about
bt,
pls
consideration,
some
comment
from
adren.
Well,
we
will
update
accordingly
next
version.
U
U
Then
there
is
the
the
the
face
number
two
that
is
providing
flooding
of
information
by
routing
protocol
that
creating
topology
in
the
context
of
JP
Ellis,
and
we
have
the
new
one
that
that
is
the
third
one
between
the
controller
or
PC
in
case
the
PC
is
acting
as
a
central
controller
and
the
different
network
element
in
the
network.
So
in
case
you
have
topology
update,
you
have
showing
a
new
number
of
Ln
P
message
to
update
with
the
new
node.
U
We
have
flooding
of
information,
providing
the
new
message
and
we
have
update
towards
the
network
controller
if,
for
example,
to
Usenet
conf
and
we
use
topology
model,
we
use
also
use
a
notification
to
provide
information
they
control
at
about
the
exchange.
The
change
in
the
network
in
case
of
service
provisioning.
U
We
try
to
encompass
all
in
this
type
of
table
in
which
we
provide
information
that,
with
the
different
level,
starting
from
complete,
distributed
control
plane
so
practically
based
on
what
we
know
about
gmpls
with
the
path
computation
based
on
OSPF
information
path
set
up
with
as
opt
and
resource
update
again
with
the
OSPF
to
create
the
traffic
engineer
database
and
they
the
second
column.
That
is
exactly
the
best.
The
major
interested
that
is
the
inter
working
between
the
centralized
path,
computation
with
the
distributed
signal.
U
So
with
that,
but
computation
can
be
provided
by
pi
support
net
conference
cough
and
then
the
setup
that
is
providing
still
providing
with
our
sweetie
with
signaling
protocol
and
then
a
complete,
centralized
approach
in
which,
again,
we
can
also
exploit
both
PS
at
the
support
net
confit
and
model.
So
these
are
the
three
level
and
the
three
type
of
possibility
in
which
we
presented
the
situation
in
which
there
is
also
complete
interworking
between
a
central
controller
and
distributed
control
plane.
U
U
We
think
that
is
a
good
starting
point
for
this
work,
and
so
we
would
ask
so
to
ask
working
on
abduction
and
well.
One
point
that
we
probably
need
is
to
have
some
support
or
some
interest
from
operators
that
can
provide
feedback
about
scenarios
and
so
to
improve
the
document
with
the
reactionaries
from
operator
prospective.
B
B
B
It's
an
okay
number
about
saying
how
many
think
that
we
should
wait
for
the
additions
that
the
author
suggested.
No
one
so
I
think
that's
an
indication.
I
mean
I,
wouldn't
say
that
that
was
a
huge
support,
not
overwhelming
so
I
will
talk
offline
and
see
whether
what
we
think
should
be
the
next
step
the
chairs
will
pop.
So
thank
you.
F
Okay,
I
can
do
that.
So
just
a
very
quick
introduction,
like
the
previous
talk,
was
about
gmpls.
This
is
kind
of
focusing
on
IP
network
and
specially
focusing
on
interaction
with
other
protocols
like
BGP
I'll
skip
that,
let's
just
focus.
The
first
key
part
is
the
interaction
between
the
P
components
and
the
non
T
components.
So
T
components
is
everything
which
is
described
in
a
CDN
and
how
that
fits
in
with
the
other
don.t
interactions
that
needs
to
happen
within
her
idea
of
IP
controllers.
F
So
that's
something
that's
basically
being
described
in
this
document,
so
we
have
the
T
information
kind
of
well
hashed
in
the
last
update
this
time,
with
the
help
of
my
co-authors
and
new
contributions,
basically
from
the
BGP
point
of
view
added,
what
are
the
various
things
in
the
BGP
protocol
that
can
be
used
when
you
have
a
variety
of
controller?
What
role
would
the
root
reflector
play?
What
role
would
the
routing
policies
can
play?
What
are
the
different
work
that
could
be
used?
F
That's
been
done
in
the
idea
or
in
other
places,
when
we
have
a
variety
of
IP
controllers
and
how
it
interacts
with
the
that
the
TE
tunnels
or
the
or
the
AC
T
and
V
n
that's
been
created
using
the
AC
TN
philosophy,
so
we
added
details
about
the
flow
spec,
the
BMP,
the
bgp,
LS,
etc.
This
is
document
is
not
describing
anything
new,
it's
just
referencing
how
the
work
that's
been
done
in
the
T
part
and
the
non
T
part
can
come
together
in
to
reach
services
like
seamless
MPLS.
F
So
it
gives
step
by
step
how
things
would
have
happened
here:
l3,
VPN,
etc,
and
then
what
we
go
in
detail
also
is
all
the
various
control
plane
and
the
management
plane
protocol
that
can
come
in.
So
we
described
the
piece
of
work
which
fits
quite
well
and
in
this
update
we
added
details
related
to
BGP
as
well,
so
policy
flows
back
BGP,
LS,
a
BMP,
etc,
just
as
a
informational
document
describing
how
everything
comes
together
still
from
the
yang
models
as
well.
F
We
kind
of
listed
what
are
the
various
yang
models
that
are
of
interest,
so
we
added
BGP
related.
We
still
have
a
big
question
mark
that
still
undecided
is
the
yang
model
at
the
service
layer
that
is
above
the
MD
SC
or
the
super
controller
is
quite
clear.
Things
are
very
clear.
At
the
device
level
things
becomes
a
little
dicey
when
we
talk
of
network
configuration
model
on
the
domain
controller,
so
especially,
if
you
are
doing
an
interest
and
3
VPN
setup,
how
do
I
tell
only
the
the
domain
controller
of
a
s1?
F
What
to
do
that
part
is
not
yet
here.
So
with
this
exercise,
we
also
wanted
to
bring
out
what
are
the
gaps
that
are
kind
of
missing
and
something
that
we
need
to
work
towards,
and
if
there
is
some
other
work
that
you
feel
fits
into
this,
we
would
like
to
add
that,
so
we
really
require
some
feedback
here
as
well.
F
We
also
listed
some
gaps,
something
that
we
think
could
be
useful
between
the
set
of
controllers,
so
when
the
two
controllers
are
talking
to
each
other,
what's
the
best
way
to
learn
the
capability
of
each
of
the
controllers?
Could
the
yang
model
work
best,
or
should
we
use
some
other
mechanism?
How
do
we
set
up
the
relationship?
What's
the
best
things
to
do
here?
What
if
there
are
multiple
instances
of
controller?
F
So
all
these
questions,
which
are
still
open
in
our
mind,
so
we
really
would
like
that
discussion
also
to
happen
somewhere
here
and
basically
the
main
aim
for
the
presentation
is.
We
still
need
a
lot
of
feedback.
We
have
got
few,
especially
from
the
BGP
side,
but
from
the
other
side
as
well,
om
and
other
yang
model
things.
We
would
require
some
feedback,
some
gaps.
Maybe
what
is
missing,
and
you
like
the
previous
work,
which
was
focusing
on
the
gmpls
this
being
focusing
on
IP.
A
F
Beyond
the
actn,
because
I'm
talking
about
BGP,
so
that's
definitely
doesn't
come
in,
but
if
this
document
does
have
the
BGP
related
stuff,
air
and
I
think
that's
the
main
thing,
because
when
we
used
to
talk
to
some
customers,
they
wanted
this
clarity,
that
how
is
this
everything
coming
together?
Like
I
understand
this
model
exists?
You
have
a
CT
and
you
have
this
thing,
but
how
does
it
all
come
together?
What
are
the
things
that
I
need
to
worry
about?
So
with
that
in
mind
we
wrote
this
informational
document.
G
B
B
J
Okay,
this
is
not
about
that.
Okay,
so,
basically,
this
is
about.
You
know
that
I
have
like
already
at
several
service
mapping
to
tunnel
models
and
this
kind
of
mess
a
little
bit
right,
so
basically
to
solve
that
the
wrote
yet
another
model
right.
So
basically,
the
problem
is
today
is
that
the
services
they
the
service
to
tunnel
mapping
its
server
specific
and
it's
explicit.
Basically,
you
define
the
servants
service
foo,
you
defined
like
a
Cyril
configuration
parameters
and
somewhere
down
this
configuration.
J
You
have
this
little
leaf,
ref
that
point
to
one
or
several
tunnels
that
you
want
to
the
source
to
be
carried
by
bye-bye,
okay,
so
in
in
many
cases
it
works
fine,
especially
like
in
hard
separation
cases,
when
you
really
need
hard
separation
between
services
and
tunnels
that
they
use
it.
But
in
other
cases
it
presents
some
problem
like,
for
example,
the
cardinality
of
services.
Two
tunnels
could
be
M
to
n,
where
m
could
be
a
very
large
number
of
different
services,
instances
of
different
types.
So
let's
say
it's
500?
J
Okay,
so
you
basically
configure
500
mapping
and
the
first
question
is:
how
do
you
know
how
many
services
you
could
put
on
this
number
of
tunnels?
Okay,
so
before
it
goes
beyond
the
utilization,
the
capacity
of
the
tunnels?
The
second
question
is:
what
happens
if
you
want
to
do
a
change?
Okay,
like,
for
example,
you
add
another
site
or
you
change
the
tunnel,
and
so
so
today
the
only
possibility
is
to
go
and
issue
another
500
reconfigurations
to
remap
the
tunnels,
to
remedy
services
to
new
tunnels.
J
J
J
So
our
solutions,
basically
you
map
services
to
two
tunnel
pools
you
you,
you
basically
make
service,
steering
implicit,
you
can
feel
your
services
and
you
say
instead
of
weapon
sources
to
tunnels.
You
service
food,
to
tunnel
base
tunnel
pool
like
fast
tunnels,
okay
and
you're
done
with
their
service
Syrian.
So
everything
else
is
all
about
managing
the
pools.
Okay.
So,
for
example,
you
can
start
with
the
one
tunnel
and
measure
the
utilization
see
if
it
goes
beyond
certain
threshold.
You
can
add
another
tunnel
and
you
don't
have
to
do
all
this
remapping.
J
If
you
add
another
site
again,
basically,
you
create
a
new
tunnel
and
so
yeah,
but
because
it's
already
within
the
pool,
so
you
don't
have
to
do
anything
else.
So
this
this
would,
in
our
opinion,
will
clearly
decouple
the
service
definition
from
service
Tyrian.
Okay
and
say
you
can
have
a
service
which
could
be
delivered
say
by
IP
network
or
it
could
be
delivered
by
Orion
network.
So
we
can
have
the
same
model
that
where
you
define
the
service
per
se
and
then
you
just
map
it
to
different
pools.
J
D
J
The
service
mapping
per
se
right
so,
for
example,
if
you
define
the
service,
you
have
two
options:
we
just
offer
an
additional
option.
We
say
you
can
use
this
tunnel,
you
use
tunnel,
Igor,
okay,
that's
it
most
or
you
use
a
tunnel
pool
which
is
say
red
or
fast
tunnels,
and
then
you
do
whatever
you
want
to
do
within
the
pools.
Okay,
you
forget
about
service.
Steering
at
this
point,
yeah.
Z
B
J
D
Okay,
so
scope,
scope
of
the
drafter.
Basically,
we
received
a
lot
of
comments
during
many
a
CT
and
presentations
and
words,
okay,
but
how
does
is?
Does
this
apply
to
packet,
optical
or
more
in
general,
to
multi-layer
so
main
scope
of
the
draft
is
to
explain
the
applicability
of
a
city
and
to
a
multi-layer
environment
and
how
VPNs
map
into
this
focus
is
mostly
are
the
isolation
because
you,
basically
you
go
deeper
into
the
stack
when
you
go
want
to
go
for
our
diesel
isolation.
D
So
yes,
so
before
jumping
into
the
packet
optical
stuff,
for
just
a
recap
of
our
actn
and
the
layer,
2
layer,
3,
VPN
services
fit
into
the
same
picture.
So
here
we
have
the
article
Sdn
controller.
The
MDRC
is
one
of
the
functionalities
of
the
Sdn
controller.
So
it's
the
guy
that
talks
to
the
various
PNC's
and
the
dependency
itself
is
one
of
the
functionalities
of
the
domain.
Sdn
controller
one
other
functionality
could
be
the
VPN
provisioning.
D
So
this
is
a
slider
that
you've
seen
in
the
previous
presentation.
These
are
the
different
types
of
te
and
service
mapping
models,
so
Nubian
with
the
tunnel
bonding
existing
anubian
with
the
tunnel
sharing
or
Nubian
with
the
tunnel
modify
in
particular.
In
the
first
case,
we
have
three
different
subsets,
as
are
the
isolation
with
the
deterministic
characteristics,
hard
isolation
and
soft
isolation.
The
focus
of
this
draft
is
the
first
two
items.
D
Okay,
so
in
the
drafter
you
will
see
three
different
scenarios
proposed
them.
We
can
go
through
the
first
one
because
they
are
very
similar.
The
first
one
is
about
single,
let
me
say:
client
domain
IP,
MPLS
domain,
a
single
server
domain,
so
AE
an
optical
domain,
but
after
describes
how
what's
the
procedure
to
follow,
to
build
this
Vienna
spanning
multiple
domains
of
something
that
is
needed
for
packet
optical
integration,
for
the
isolation
of
observe
assist?
D
Basically,
if
you
have
several
steps
on
the
northbound
side
of
the
MVC
or
better
the
hierarchical
Sdn
controller,
you
receive
a
request
for
a
service
requesting
for
hard
isolation
in
the
packet
optical
network.
The
request
is
processed
by
the
mdac,
which
decomposes
it
into
a
request
for
the
underlay,
which,
in
turn,
which
creates
new
connectivity
in
the
in
the
server
in
the
client
domain,
and
then
on
top
of
these
connectivity
is
possible
to
build
that.
D
Will
the
des
services
so
step
number
four,
the
vrf
is,
is
created
and
the
binding
between
the
the
service
and
the
underlay
infrastructure
is
created.
Next,
two
slides
are
basically
showing
it's
something
you
can
find
in.
The
draft
are
showing
how
these
applies
also
to
multiple
packet
domains.
On
top
of
the
same
server
domain,
the
in
the
same
optical
domain
or
multiple
combinations
of
them.
We
can
skip
them
conclusion
and
next
step.
So
we
we
wrote
this
document
because
we
felt
that
there
was
the
need
to
clarify
some
things
mostly.
D
B
Okay,
so
we
have
a
few
hands.
How
many
think
that
they?
This
is
not
anything
we
should
be
talking
about
in
the
working
group,
no
one
so
I,
it
seems
like
the
working
group
would
like
to
hear
more
about
this
and
maybe
talk
a
little
bit
more
on
the
list
and
be
good
too
there
we
go.
It
would
be
good
to
get
foster
some
discussion
there,
Thanks.
Z
Amytal
woozy
from
away
I'm
presenting
this
draft
that
is
providing
ceiling
extension
for
gmpls
for
Sherman's
protection,
a
bit
of
history.
An
initial
version
of
this
rafters
present
in
the
last
IDF
meeting
in
the
second
working
group
was
merely
erasing
the
configuration
of
audio
SNP,
and
but
we
got
a
comment
that
the
basic
requirement,
what
we
are
doing
in
this
document,
is
just
extending
RSC
for
a
72,
with
a
new
protection
type
which
can
be
used
for
SMP
and
is
very
generic
and
not
audio
specific.
So
we
can.
Z
Z
The
signaling
protocol
extensions
are
no
need
to
changer,
so
they
are
aware
or
revision
Eric,
so
they
are
okay
and
we
made
some
few
editorial
so
in
the
the
generic
aspects
of
it.
Okay,
we
have
said
that
generic,
a
spacer
is
a
toiletry
70.3.
Doe
is
only
audio
specific
and
ferrous
if
741
to
is
requirements,
and
we
propose
to
update
for
a
seven
to
four
SNP
generica
and
can
be
applied
to
any
technology.
Z
Z
So
what
are
the
changes
that
we
propose
is
basically
to
create
are
indeed
to
define
a
new
protection
type
as
for
a
sharona's
protection
to
let
denotes
along
the
path
for
testing
at
they're,
protecting
part
that
we
need
they
need.
They
need
to
implement
SNP
and
use
aps
data
plane
for
activating
the
protecting
LSP,
and
then
we
change
the
behavior
of
the
N
and
you
operate
in
the
obits,
because
the
and
our
beats
are
the
behavior
are
the
finer
for
different
protection
type.
So
we
have
added
how
they
should
behave
in
case
of
SNP.
Z
Q
T
G
A
Z
G
M
Dw
Nokia
I
have
a
question.
The
draft
also
talks
about
sharpness
restoration,
which
and
says
it's.
This
is
a
similar
mechanism
like
mesh
restoration,
but
as
opposed
to
share
my
meshed
restoration
shop
must
mesh
protection.
Is
the
mechanism
that's
supported
by
the
data
plane?
Marissa.Surmacz
restoration
is
done
in
the
control
plane.
So
how
do
the
two
two
mechanisms
coexist?
Is
there
any
issue,
because
both
are
dealing
with
spare
resources
in
the
network
to
use
those
resources
in
the
event
of
a
failure?
Oh.
Z
Yeah,
so
your
point
is
where
you
have
both
SMP
and
SMR
in
the
same
network
and
I
think
that
I
will
expect
that
the
resources
sharing
will
be
different,
so
SMP
NSM
are,
will
not
share
resources
if
they
are
on
the
same
network.
That's
I,
I,
don't
despair
that
we
coexist,
but
if
they
do
I
think
that
that
I
don't
think
you
need
to
to
share
resources
between
SMPS.
Mr.
J
Z
Thing
well,
if
the
requirement
is
that
I
need
to
set
up
image,
impedance
network,
the
working
gillespie
and
the
protecting
LSP,
and
when
I
set
up
the
protection
LSP,
the
intermediate
nodes
needs
to
know
that
the
protagonists
P
belongs
to
an
SMP
rotational
schema
rather
than
SLR
or
rather
than
linear
protection.
So
they
need
to
understand
how
to
to
program
on
the
protecting
LSP.
My.
Z
B
B
Moment
other
than
try
to
get
foster
more
discussion
on
the
list.
Okay,
yes,
thank
you
I'll
note
that
it
looks
like
we
don't
have
energy
to
keep
talking.
Nor
do
we
have
time
we
you
were,
or
you
had
a
draft
that
we
were
talking
about
at
the
end
of
the
last
session
that
we
were
hoping
to
start
rolling.