►
From YouTube: IETF104-TEAS-20190326-1350
Description
TEAS meeting session at IETF104
2019/03/26 1350
https://datatracker.ietf.org/meeting/104/proceedings/
A
This
is
our
second
of
two
sessions.
We
heard
that
there's
some
people
were
having
problems
getting
on
to
etherpad.
I
was
able
to
get
in,
but
I'm
getting
in
through
a
VPN
I.
Don't
know
if
that
hell
that
helped
or
not,
but
other
people
are
saying
that
they
couldn't
get
in,
but
please
to
try
to
join
and
help
us
out
with
the
minutes.
A
As
we
do
in
every
start
of
every
session,
we
show
our
note
well
and
please
remember
that
anything
you
say
during
the
session
at
the
mic
is
part
of
our
record,
our
permanent
record
and
is
considered
a
contribution
to
the
IETF.
All
contributions
to
the
ITF
are
governed
by
PCP
79.
You
can
go,
read
that,
and
also,
if
you're
interested
in
in
looking
at
learning
more
about
the
policy,
though
the
URL
at
the
bottom
of
the
page
as
before.
A
As
always,
we
are
streaming
audio
video,
we're,
also
recording
the
video
and
we
published
after
the
meeting
when
you
when
you
come
to
the
mic.
Please
speaks
speak
your
name
and
we
just
had
a
conversation
with
chairs,
and
someone
pointed
out
too
that
there
is
no
need
to
state
your
affiliation.
Just
your
name.
A
A
Okay,
no
hat
there
for
a
second
I,
should
let
Kevon
Drive
this
time
right.
So
Sergio's
here
is
going
to
talk
about
the
the
path
computation
yeah.
My
last
computation,
the
second
set
the
rest
of
the
second
session.
We're
gonna,
just
steal
five
minutes
from
different
presenters
and
we're
actually
thinking
some
of
these
will
go
faster
anyway.
The
other
thing
is:
is
we
have
moved
the
enhanced
VPN
earlier
in
the
slot?
That's
it
for
the
intro
LaVon
I!
Guess,
okay,
which
slide?
A
B
C
We
have
a
discussion,
was
it
over?
He
reminded
me
about
discussion.
We
had
before
so
it's
it's
basically
my
fault,
but
the
difference
is
that
if
you
configure
a
tunnel
in
pre-computation
mode
and
even
if
you
specify
that
timeout
for
how
long
you
keep
the
state,
the
server
can
remove
the
state
after
the
time
after
the
timeout,
but
the
configuration
was
still
supposed
to
be
in
the
intended
configuration
data
store
and
it
needs
to
be
explicitly
removed.
Well,
if
you
do
it
while
RPC,
this
is
not
a
problem.
D
My
question
is,
in
the
seconds
next
slide:
I'm
drove
yeah
so
coming
to
this
I
I'm
little
surprised
by
why
you
want
to
mandate
that
this
RPC
should
only
be
used
in
a
variety.
A
Heike
of
controller
fashion
to
be
RPC
is
just
an
RPC
and
we
should
allow
it
to
be
used
by
whoever
who
wants
to
invoke
the
RPC,
and
that
should
be
fine.
D
So
why,
and
especially
also
from
the
model
point
of
view,
I
think
the
the
change
that
alleyway
was
asking
to
allow
the
same
RPC,
also
to
be
used
in
a
peer-to-peer
fashion,
was
a
small
change
but
did
not
require
a
big
change
in
your
model.
So
why
should
be
mandate
like?
What's
the
main
reason
that
you
wanna
feel
that
no,
this
document
should
not
satisfy
the
need
of
anybody
who
wants
to
use
your
RPC
in
a
B
RPC,
like
fashion.
B
B
The
question
that
is
coming
in
the
next
slide
the
working
group
if
they
think,
like
the
working
group,
think
that
is
needed
to
have
some
modification
on
the
young
to
cope
also
with
aspect
or
not
and
well,
and
if
it
is
needed
to
have
a
specific
description
of
the
use
cases
or
just
say,
independently
of
the
architecture,
this
RPC
is
used
to
make
a
request
in
the
panel
of
the
fact
that
is
a
sequential
slide
distributed.
Architecture
erotic.
D
Drop
again,
my
suggestion
is
I
think
it
should
be
it's
a
very
small
change,
though
I
I
like
a
CT
and
I,
prefer
that
approach
but
I.
We
should
not
done
that.
This
RPC
should
only
be
used
in
a
one
approach.
If
there
is
a
comment
coming
in
the
mailing
list,
and
somebody
wants
to
use
your
yang
model
in
a
different
way
and
it's
a
small
change,
I
think
we
should
allow
it.
B
B
A
A
E
B
B
We
have
two
possible
turnin
t'v
in
the
young
model,
one
alternated
with
a
single
request
to
compute
working
and
protecting
but
related
to
a
single
tunnel
or
to
have
two
requests
to
compute
a
working
path
and
the
other
that
is
dealing
with
protecting
part
of
and
with
association,
between
the
two
requests
within
the
same
RPC.
This
is
more
or
less
the
approach
that
is
also,
if
I'm
not
wrong
easy
in
the
in
the
episode
contest.
So
you
have
no
directly
path
computation
for
both,
but
you
need
was
achieved.
The
two
computed
paths.
B
Well,
we
next
slide.
We
just
compose
a
table
with
trans
and
cons
from
our
understanding.
Okay,
we
can
go
through
I,
don't
want
to
commit
and
leave
the
comments
to
the
working
group.
Basically,
the
question
that
is
putting
the
red
and
the
bottle
is
general
question:
if
we
it
is,
it
is
possible
that
any
way
the
path
computation
can
be
used
without
the
eternal
model
with
another
connection
and
a
model,
and
so
our
PC
is
not
mandate
to
have
specific
semantics
that
is
related
to
the
tunnel
mode.
B
You
have
implicit
support
of
the
other
Association
young
proposal
in
the
tunnel
model,
light
be
directional
and
and
instead
in
case
of
tour
request,
you
need
to
define
specific
mekinese,
but
on
the
other
side
they,
the
fact
that
were
to
Pat
request
is
basically
following:
what
is
the
structure
of
the
path
with
the
Pat
complication
without
imposing
any
heavy
modification?
Hazzah
instead
is
the
case
in
yellow
in
the
Casa
in
case
you
follow
the
option
one.
B
A
But
but
you're
allowed
to
have
an
opinion,
so
the
authors
who
are
working
on
it
do
you
have
a
recommendation
to
the
working
group
or
do
you
think
it's
a
you
know
from
your
standpoint,
a
coin
toss
or
or
the
author
split.
You
know,
that's
that's
useful
information,
so
you're
doing
that.
That's
great!
That's!
That's!
That's
useful
information!
Thank
you
to
me.
It
seems
like
a
no-brainer,
but
you
know
obvious
one
person
also
yeah.
B
So
yes,
here
we
summarize
the
situation
of
the
open
issue.
We
have
the
our
github
that
summarize
all
the
aspect
and
tracking
Yavin
issue.
We
have
closed
three
open
issues
since
the
bangbang
god
meeting.
We
have
audio
on
eight
one,
eight,
the
three
three
specific
for
path,
computation
three
are
related
also
for
other
for
tunnel
model
and
the
last
two
one
is
Victoria.
So
is
a
review
terminology.
B
B
So
we
acknowledge
some
people
that
help
us
our
work
and
a
part
color
Francesca
that
help
us
technically
with.
There
are
also
some
help
from
the
discussion,
both
for
the
changing
that
we
made
in
the
young
model
for
the
past
eight
and
also
for
the
discussion.
We
thanks
Olivier.
You
are
Adrian
and
yang
to
help
the
discussion
about
this
topic
regarding
hierarchical
aspect
or
distributed
one
in
the
contest
of
Pat
computation
next
step.
A
G
B
We
have
we
have
discussed
in
the
Middle
East
and
the
open
issue
that
has
been
so
and
then
the
the
three
one
that
is
remain
one
is
the
older
one
related.
Maybe
you
remember
that
about
that.
The
attributes
that
is
used
in
all
the
attitude
that
is
used
to
make
the
request
in
the
tunnel
model
that
it
is
not
so
mandatory
in
the
context
of
that
computation
there
as
well.
B
A
C
So
basically,
this
open
issue
we
discuss
it.
There
was
several
exchanges.
I
personally
do
not
like
the
option
of
having
separate
requests,
leaning
together,
mainly
because
not
only
have
to
link
them,
but
you
also
have
basically
describe
relationships.
How
this
result
in
pass
would
be
related
like,
for
example,
what
kind
of
juice
goodness
you
requires,
whether
it's
a
sorrel,
Gigi,
goodness
or
integer
goodness.
What
happens
if
as
a
desired
assuredness
is
a
whale
is
not
available,
but
a
lesson
is
version.
C
Is
this
one
thing,
but
the
other
thing
is:
you
will
duplicate
quite
a
few
of
quite
quite
a
few
parameters
like
there's
common
source
destination.
There
is
a
bandwidth
requirements,
common
affinities,
exclusions,
things
like
that.
Okay,
so
if
you
just
provide
a
single
request,
then
this
is
all
taken
care
of
and
finally
obviously
there
are
a
lot
of
algorithms
that
actually
compute
paths
simultaneously
and
not
you
know
you
can
solve
that,
but
it's
a
bit
awkward
rather
than
to
have
it
in
a
single
request.
H
B
D
Can
we
go
back
to
that
slide?
This
is
row
which
one
the
way
the
comparison
between
tunnel
request
and
two
path
requests.
I
have
a
different
opinion
from
Igor
a
little
bit
spacely
from
the
sense
that
I
want
to
retain
two
path
requests,
because
every
time
you
ask
for
disjoint
that
doesn't
mean
that
they
are
going
to
be
part
of
the
same
tunnel.
D
So
if
you
remove
that
that
you
are
taking
away
very
important
feature
that
you
currently
provide
that
even
two
unrelated
parts
can
be
diverse
from
each
other
and
I
want
that
free
to
still
be
there.
So
whether
you
want
to
go
with
a
new
tunnel
request,
I,
let
you
and
the
working
group
decide,
but
don't
take
away
the
thing
that
you
already
have
in
the
document,
which
is
to
pass
request
via
a
spec.
So,
okay.
I
Himanshu
from
Siena
I
have
a
third
opinion.
Why
not
support
both
I
think
both
has
marriage
like
what
Igor
was
saying
and
drew
said:
I
think
it
would
be
quite
flexible
if
we
can
support
both
I
mean
you
can
start.
Let's
say
you
started
with
unprotected
tunnel
and
later
on,
you
want
to
add
the
protection.
A
I
E
You
Jake
I'm,
going
to
follow
my
predecessor.
There
I
think
it
makes
sense
to
support
both
for
various
reasons.
Some
of
them
were
already
stated.
Also,
there
are
various
algorithms
to
be
implemented,
underneath
that
could
behave
differently
depending
of
single
common
request
or
separate
requests,
so
I
to
believe
that
boss
mode
should
be
considered.
C
Just
to
answer
loose
and
a
human
chess
point:
basically,
when
you
get
protection,
it
doesn't
mean
that
you
forget
about
the
walking
past
or
if
you
have
to
still
do
both
things.
You
still
have
to
consider
the
desert
nurse,
and
sometimes
you
you
reroute
the
walking
path
in
order
to
that
protection.
So
this,
basically
it's
it's
a
it
doesn't
diminish
this
request,
so
I
don't
mind
to
have
a
separate
request.
C
I
thought
that,
for
example,
when
you
compute
paths
for
different
tunnels,
it's
a
different
program,
so
that
could
be
solved
differently
like
through
tunnel
sets
with
the
relationship
between
tunnels.
This
is
not
just
the
joiners
there's
a
lot
of
things
that
maybe
like
a
common,
optimization
problem
that
you,
for
example,
want
to
have
the
shortest
common
course,
rather
than
basically
a
shortest
course
for
each
of
them
individually.
But
it's
a
separate
part
I,
don't
mind
to
support
both
as
long
as
we
have
this
option
to
compute
with
a
tunnel
request.
J
Ie,
thorough
speaking
I'm,
not
feeling
comfortable
with
supporting
both
it's
creating
potential
nightmare
in
on
interoperability.
Personally,
I
prefer
the
option
that
I
don't
like
to
be
selected
there
to
have
two
options,
because
otherwise
we
have
one
vendor
support,
request
on
us
and
the
other
vendor
support,
request
paths,
and
then
you
have
issues
in
the
interoperability
and
I'm
fine
I
think
all
the
issues
can
be
solved
with
other
options.
Is
it's
just
a
matter
of
whether
the
RPC
should
make
a
request
to
want
art
animation,
requests
marker
pattern?
J
We
can
find
a
solution
to
to
make
sure
that
the
same
cementing
are
the
same
features
that
we
have.
We
can
avoid
option
one.
It
can
be
done
with
option
two
ambassador,
so
in
my
opinion,
I,
don't
see
a
real
showstopper
or
one
option
versus
the
other
I'm,
just
it
to
be
comfortable
with
two
options,
because
it's
becoming
an
interpretive
9.
Thank
you.
E
Eric
again
sorry
I
haven't
reread
the
draft
very
freshly,
so
maybe
it's
taking,
but
assuming
we
go
for
option
one.
Do
you
see
a
way
to
prevent
me
from
using
the
past
computation
module
to
achieve
Q
by
myself?
I'm,
not
sure
you
can
prevent
that
so
assuming
we
will
find
a
way
to
do
option
two.
You
need
to
support
up
to
one
for
some
use.
Cases
on
I'll
do
option
to
my
way
wherever
so,
maybe
you
shouldn't
prevent
it
from
happening
so.
A
C
I'm,
sorry,
just
for
one
thing,
so
you
can
always
consider
computing
paths
for
different
tunnels
as
just
who's
unprotected
tunnels
right
and
this
is
also
than
auction
right.
So
it's
automatic
option
right,
but
but
you
can
even
consider
things
that
you
have
protected
tunnels
which
could
be
different
in
a
very
different
ways,
for
example,
only
working
password
which
is
doing,
but
not
protection
and
stuff
like
that.
So
that's
why
I
think
basically
option
1
cause
everything.
A
So
we
should
get
some
feedback,
maybe
I
don't
know
if
it's
worthwhile
to
pull
or
not.
It's
actually
remember
as
a
working
with
document.
It's
the
it's
the
editors
responsibility
to
gauge.
What's
going
on
in
the
working
group,
so
would
you
like
to
do
some
polling
or
do
you
feel
like
you
had
enough
folder
feedback,
I.
B
A
A
We
have
s,
you
slowly
hit
more
hands
or
coming
up,
it's
just
a
few.
How
many
think
that
option
two
is
sufficient,
I
would
say
just
slightly
more
they're
clustered
to
the
front.
That's
part
of
the
reason
we
don't
come
here,
because
we
can't
tell
the
difference
between
anywhere
where
people
sit,
but
it's
just
slightly
more.
L
Great,
so
the
motivation
of
this
work
is
to
explain
how
the
different
types
of
young
model
IPF
develop.
Being
both
may
be.
A
couple
of
working
groups
here
are
applicable
to
the
ICT
instructors,
and
this
has
been
working
group
adopted
for
a
while
and
from
last
meeting
the
main
change.
Actually,
it's
not
big.
We
just
add
some
description
on
the
service
provisioning
EMPI
and
we
update
to
the
first
Pony
reference.
L
So,
let's
see
what
is
happening
after
we
updates
the
work,
so,
basically
the
on
the
accept
tetra,
we
specify
okay
to
interface,
the
usage
for
different
IDF
models
into
interface,
the
first
page
we
focus
on
the
CMI
part,
so
we
have
a
few
of
them.
Actually,
this
part
states
and
change
it
with
previous
meeting,
including
the
William
Model
T
service,
mapping,
performance
mentoring,
and
they
are
one
two
three
service,
Model
T
topology
as
well.
L
L
What
we
have
a
deal
so
far
is
a
service
provisioning
and
we
added
to
use
a
client
signal
model
in
secant
working
group
and
the
t
tunnel
model
which
is
developed
in
this
working
group.
Absolutely
besides,
the
teat,
Hana
model,
actually
technology,
specific,
more
tunnel
models
may
also
be
used
to
do
the
service
deployment,
and
we
have
also
adds
this
kind
of
description
so
on
the
corresponding
interface
T
Square.
L
M
N
D
So
I'll
be
talking
about
actn,
vien
yang
model
and
remove
the
word
AC
the
end
there,
it's
just
there
in
the
file
name.
Now,
that's
our
biggest
change
that
we
did
based
on
the
feedback
that
we
got,
that
we
removed
the
tight
coupling
that
we
had
with
the
AC
thean.
So
now
we
call
this
is
as
a
V
and
yang
model.
D
A
Scythian
is
still
the
primary
reason
why
this
primary
example
of
how
to
use
this
V
and
yang
model,
but
we
made
it
Chernykh
and
we
removed
the
actn
container
wherever
we
had
in
the
yang
model,
so
that
it
could
be
applicable
for
other
VN
operations
as
well.
So
that's
the
main
change
that
has
happened
in
the
document.
D
So
this
is
basically
just
a
refresher.
Where
does
the
V
and
yang
sits?
The
VN
yang
uses
the
PD
topology
model
and
it's
built
over
the
T
topology
model,
but
it
is
from
the
point
of
view
of
the
customer
and
it
uses
the
single
node,
abstract
single
node
connectivity,
matrix
heavily
and
uses
that
using
that
it
explains
how
the
customer
view
of
the
VN
is
there.
D
So
when
you
create
an
l-3
SM
service,
what
is
the
underlying
information
that
you
can
get
wire
that
augmentation
and
it
gives
you
at
various
levels
and
depends
upon
the
choice,
whether
you
want
it
at
the
VN
level
or
you
want
at
the
topology
level
or
at
the
end-to-end
tunnel
level?
So
this
kind
of
gives
you
based
on
what
abstraction
that
the
customer
needs,
and
at
that
level
you
can
provide
the
traffic
engineering
underlay
parameters
next
slide.
So
we,
while
we
updated
this,
we
also
have
some
work
to
do
so.
D
We
just
wanted
to
give
a
heads
up
that
this
is
well.
This
is
what
you
should
expect.
We
hope
that
we
could
have
finished
it,
but
we
couldn't
so,
but
this
you
should
see
before
the
next
idea.
So
what
are
those
things
we
had
various
people
who
want
to
use
VN
model
asking
us
how
to
use
connectivity
matrices.
Can
you
explain
this
in
a
much
better
term
that
what
is
the
relationship
between
the
two?
Because,
when
they
think
of
using
a
model,
it
cannot
be
used
on
its
own?
You
need
to
have
a
little
bit.
D
Coupling
also
create
the
T
topology
single
node,
so
how
do
I
use
different
yang,
different
yank
messages
via
net
convent,
restaurant
first,
using
a
CT
and
VN
model
and
then
using
the
T
topology
model
and
how
things
comes
together?
That
is
the
part
where
people
want
little
bit
more
clarification.
So
we
have
started
writing
the
text,
and
hopefully
this
should
be
seen
in
the
next
version.
D
People
also
ask
the
question
that
why
you
create
a
VN
model,
one
of
the
main
reasons
is
the
service.
So
we
wanted
to
maybe
borrow
some
text
from
the
service
mapping
as
well
and
say
that
we
are
creating
this
because
of
this
l3
SM
services
or
LTV
SM
services,
and
this
is
where
the
VN
model
could
be
used.
So
only
the
part
of
the
VN
we
might
borrow
from
the
the
service
mapping
model
as
well.
Then
we
have
enhanced,
VPN
and
other
work
coming
in,
which
also
says
that
it
reuses
actn
concepts.
D
So
we
wanted
to
describe
how
this
VN
y
and
modeled
can
be
used
for
VPN,
plus
kinda
use
cases
as
well
and
use
references
wherever
is
possible,
but
carry
that
information
within
the
document,
so
that
anybody
who
comes
and
reads
this
gets
the
context
where
we
are
coming
from
specially.
Since
we
have
now
removed
the
word
a
CTN
and
these
things
we
wanted
to
make
it
a
little
bit
more
clearer
how
it
is
a
generate
VN
model.
D
G
So,
basically,
this
tea
service
metamodel
provide
seamless
service
operation
with
underlay
Tia
Network
in
terms
of
visibility
and
control.
So
that's
kind
of
an
overview.
So
here
we
created
a
map
type
so
to
speak.
We
submit
type
basically
I
give
how
you
know
my
VN
and
tunnel.
A
selection
policies
are
related.
G
You
can,
as
you
see,
on
the
left
side,
new
VN
and
tunnel
binding
in
there.
We
can.
We
allow
customer
to
specify
isolation,
constraints
or
intent
like,
for
instance,
hard
isolation
with
deterministic
characteristics
means
I,
want.
My
paths
isolated
from
you
know,
sharing
with
other
people
in
other
services
and
I
expect
some
kind
of
deterministic
characteristic
and
and
some
other
level
hard
and
soft,
and
also
VN
sharing
customer
could
request
a
VPN
where
tunnels
can
be
shared
with
other
existing
VPNs
and
the
internal
modify
means.
G
This
allows
to
modify
some
properties
of
existing
tunnels
in
terms
of
vendors
and
other
selection
mode
and
I.
Think
we
added
before
being
adopted
availability.
Some
customer
want
to
express
my
service
to
be
available
in
terms
of
six
nines
or
five
nines
and
so
on,
and
so
this
needs
to
be
translated
into
Network
level
policies
in
terms
of
protection
and
rural
policies,
but
intent
doesn't
dictate
that
it's
up
to
the
network
operation
to
meet
this
requirement
or
intent
so
update
since
last
ITF.
G
This
was
adopted
after
ITF,
so
there's
name
change
and
we
added
general
applicability
statement,
and
so
we
kind
of
tone
tone
down
a
CTN
context.
It's
actually
never
meant
to
be
a
CTN
context,
because
the
tea
service
mapping,
we
put
a
little
more
text
that
this
is
generally
applicable
in
any
setting
any
service
model
setting
and
underlaid
tea
setting
yeah,
and
we
had
to
change
some
model
because
HTTP
in
the
end,
top
container
was
removed
from
VN
model
just
to
VN,
so
I'll
clean
up
a
little
bit
of
young
model.
G
So
this
is
I
think
this
is
just
the
beginning
of
in
terms
of
maturity.
I
think
it's
a
long
way
to
go,
and
many
operators
actually
contacted
us
that
they
want
to
express
certain
intent
and
so
on.
So
if
you
are
especially
operator
or
please,
you
know,
contribute
what
kind
of
policy
or
intern
you'd
like
to
add
on
to
this
model,
we'll
be
glad
to
work
on
that
and
and
in.
In
the
meantime,
we
try
to
progress
to
mature
young
model
so
that
it
can
be
ready
for
young
doctors
review
sooner
than
later.
A
G
G
A
G
I
Q
Okay
good
afternoon,
everyone,
a
decision,
mhmm
Hawaii
and
here-
is
to
give
some
update
about
the
enhancement
uniform
of
document.
Okay,
a
little
recap:
this
document
describes
a
framework
of
the
enhanced
vaping
service.
The
perverse
is
to
support
the
requirements
of
some
imaging
services
in
5g
and
in
January
can
be
also
used
of
us
other
scenarios,
but
not
that
tightly
coupled
with
object,
and
this
document
also
summarized
them
candidate
technologies,
which
can
be
used
in
different
layers
to
provide
this
kind
of
enhancement.
For
example,
the
enhance
the
data
plane.
Q
We
can
have
different
mechanisms
to
provide
a
different
level
of
service
as
a
recurrent
ease
and
for
control
plane,
considering
to
use
a
hybrid
of
the
centralized
and
distributed
mechanism
which
is
can
take
advantage
of
both
kind
of
technology
and
for
the
management
plane.
Basically,
it
will
provide
some
10
and
dynamic
creation,
modification
and
the
deletion
of
the
between
services
with
the
require
asari.
It
also
covers
the
OEM
and
the
resiliency
considerations.
Q
Okay,
this
is
a
give
an
overview
of
this
enhancement
architecture
exactly
basically
in
the
bottom,
this
beauty
with
and
data
plane
technologies.
We
call
it
enhanced
and
array
which
can
provided
different
mechanism
for
the
resource,
reservation
or
resource
partition,
and
on
top
of
this
we
have
a
middle
leader.
Q
We
can
use
it
for
to
create
a
different
to
virtual
networks
and
to
integrate
the
overlay
connectivity
with
an
area
network
source
to
provide
a
guarantee
to
service,
to
a
customer,
then,
on
the
top
we
need
centralized
control
and
management
system,
but
you
can
can
communicate
with
the
customer
about
the
service
request
and
also
to
report.
The
status
of
the
service
here
are
some
updates
after
the
last
ITF.
Ok,
basically,
after
the
last
IDF,
we
made
a
merge
with
some
actn.
Q
He
has
VPN
and
analyzing
drops
or
made
them
part
of
the
management
section
so
that
we
can
make
a
complete
framework,
including
the
data
plane,
control,
plane
and
the
main
plane
in
this
single
document.
We
also
have
new
Co
authors
and
contributors
added
to
this
document.
Then
we
have
some
editorial
changes
in
this
version,
the
after
that-
or
this
problem
has
been
adopted
by
this
working
group
and
we
have
a
new
revision
after
the
adoption.
Q
So
this
can
solve
part
of
the
scalability
concerns,
and
another
thing
is:
we
can
also
use
some
kind
of
application
to
bring
a
group
of
enhanced
VPNs
which
have
some
similar
behave,
similar
heuristic
requirements
together
and
so
that
we
can
reduce
the
state
needed
in
the
network.
Another
thing
is,
we
also
pointed
out:
we
will
try
to
avoid
that
the
proposed
state
in
the
network
so
that
we
can
have
better
scalability,
and
in
this
version
there
are
also
some
editorial
changes
to
improve
the
readability.
Q
Okay
about
the
next
steps.
First,
the
way
will
appreciate
the
review
of
this
document
and
to
solve
the
comments
received,
and
we
also
consider
to
add
some
description
about
the
inter
domain
inter
layer
scenarios,
we
will
also
add
a
operational
consideration
section
and
improve
the
security
considerations
in
the
last
things.
We
also
need
to
work
together
with
the
causes
and
working
group
to
polish
the
draft,
because
we
have
to
merge
and
have
that.
Q
H
A
And
it's
gonna
be
headed
our
way
and
I
suspect
has
some
overlap
with
this
document.
So
would
be
good
too,
if
anyone's
available
to
to
go
and
see
what's
going
on
over
there
and
then
moving
about
synchronizing
the
content
I
haven't
looked
at
it
enough.
I
just
heard
learned
about
it
this
week
also
I've
been
learnt,
read
it
to
know
how
good
a
match
it
is
or
whether
it
really
is
independent
work,
but
it'll
be
good
for
you.
Q
A
Q
Q
Q
A
R
R
Short-Ass
Bella
hi,
I'm
Adrian-
this
is
I,
would
say
this
is
an
update
on
the
design
team.
But
it's
not
really
it's
a
initial
statement
of
what
we
are
and
what
we
plan
to
do,
unlike
nearly
every
other
presentation
in
tears
those
slots.
This
is
not
about
young
models,
except
it
turns
out
that
young
models
will
form
part
of
the
work
we
do
so.
The
design
team
is
quite
a
large
design
team,
maybe
a
bit
larger
than
we're
used
to
for
a
team.
R
R
R
R
How
we'll
do
that
is
make
regular
updates,
I
love
the
word
regular
updates.
So
that's
once
every
27
years,
yeah
chairs,
yeah,
so
we'll
make
regular
updates.
I
think
that
the
plan
is
really
that
will
be
fairly
frequent
and
we'll
talk
about
it
here
in
Prague,
and
our
intention
is
to
have
a
draft
by
105
in
Montreal,
so
that
the
working
group
can
pick
that
up
and
make
it
a
working
group
draft
and
my
design
team
can
fall
back
to
being
normal
IETF
participants.
R
How
we'll
do
this?
We
have
a
mailing
list,
it
has
an
open
archive,
so
you
can
go
and
read
the
emails
that
we
send
to
each
other
in
the
team.
It's
a
closed
list,
so
you
can't
send
to
it.
Well,
you
can
send
to
it,
but
it
hits
my
moderators
queue
and
the
intention
is
that
the
list
is
for
the
design
team
to
have
a
conversation,
we're
going
to
work
on
the
draft
in
cramdown
on
github,
and
that
means
I
have
to
learn.
R
R
We
are
starting
with
3272,
which
I've
turned
into
crammed
down,
and
we
will
edit
on
that.
We
expect
to
remove
a
lot
of
text
and
then
add
sections
for
new
technologies
and
new
work
where
those
sections
are
relatively
small.
We
do
not
expect
to
explain
how
each
section
each
technology
works,
we
expect
to
mention
it
and
then
reference.
R
We
will
publish
draft
revisions
as
we
go
along.
It's
not
our
intention
to
do
all
the
work
and
come
up
with
a
finished
document.
Have
then
publish
it
and
I
think
we're
worried.
3272
is
71
pages
long.
That's
a
big
document,
it's
a
hard
read
frankly,
and
we
have
lots
of
material
to
add.
So
since
we
do
not
want
to
end
up
with
150
pages,
we
will
be
deleting
and
editing
and
compressing
I
mean
compressing
the
text,
not
compressing
the
bitstream.
R
You
can
contribute.
So,
as
I
said,
the
list
is
closed,
but
we
want
to
hear
what
you
think
I
think.
The
best
approach
is
to
wait
until
we
push
out
the
first
version,
which
will
be
fairly
rough
and
may
have
lots
of
empty
sections
and
then
scream
about
it,
scream
about
it
on
the
working
group
list
or
in
the
corridors
or
private
emails
or
whatever,
and
and
do
you
feel
free
to
send
text
I,
don't
think
anybody
in
the
design
team
really
wants
to
spend
their
time
writing
text.
G
This
is
here
again.
This
model
is
basically
customer
are
subscribing
to
performance
monitoring
data
of
their
interest
so
that
they
can
subscribe
to
and
be
able
to
see
their
data
in
terms
of
VN
for
genetic
level
and
also
t
tunnel
level,
and
in
doing
so
we
also
added
autonomic
scale
scale
out
mechanism
also
subscribed
by
customer,
so
that
some
automation,
some
level
of
automation,
can
be
done
in
this
context.
So.
G
We
basically
use
a
young
push
mechanism,
Netcom
young,
pushing
mechanism
to
subscribe,
to,
allow
customer
to
subscribe
certain
key
performance
index
performance
data
and
be
notified
through
the
yunkish
mechanism.
We
have
a
2
module,
1
is
T
level
and
the
other
one
is
I,
think
we
call
ICT
and
never
bought
a
TV
to
replace
as
a
VN
level.
G
G
But
there
are
two
pending
issues
raised
up:
one
is
packet
loss
and
delay
variation.
These
are
living
more
pack
eccentric,
so
we
deleted
from
this
model.
Actually,
we
didn't
t-type,
actually
they
delineate
this
packet
for
this
non
packet,
so
we
input
a
tea
type.
You
know
performance
metric,
so
we
depend
on
that
and
now
it's
cleaned
up.
G
So
we
don't
have
these
two
parameters
anymore
to
stay
as
generic
and
I
think
poppin
asked
me
how
to
how
does
the
scaling
mechanism
works,
and
so
we
added
a
section
and
also
I'm
going
to
present
in
the
next
slide
yeah.
So
in
terms
of
scaling
mechanism,
let's
say
client
wants
to
scaling
out
operation
as
an
example
based
on
say
two
performance
pipes
to
a
delay
and
utilize
bandwidth.
This
is
just
arbitrary
pair
in
men
are
make
sense,
but
as
an
example
48
hello,
so
ending,
so
it
can
set
threshold
time.
G
G
Scale
out
operation
type,
this
is
kind
of
you
know
and
or
min
max.
You
know,
okay,
you
know
for
bunch
of
type
def
defined,
and
then
we
have
a
list
of
conditions
as
a
list,
so
you
can
put
multiple
performance
parameters
per
say.
It
can
be
one
or
can
be
two.
It
can
be
multiple
within
the
confines
of
different
performance
type.
So
in
this
case
leads
to
one
say:
two:
a
delay
and
performance
type
is
a
delay
and
then
stretch
your
value
is
thirty.
G
Three
hundred
two
hundred
millisecond
and
these
two
years,
utilize
bandwidth,
I'll,
say
two
hundred
merripit.
So
if
my
tunnel
put
as
a
reference
there
meets
this
two
condition,
please
do
scale
out.
Likewise,
we
can
define
scale
in
depending
on
the
operation
that
you
will
not
say
so.
This
allows
the
client
to
set
what
they
want
to
see
their
eternal
ovn
from
their
perspective
from
their
performance
criteria
perspective
to
allow
them
to
set.
G
S
Dita
Bella
Nokia
when
I
read
that
draft
I
thought
that
I
will
learn
something
about
or
subscribing
to
telemetry
and
about
some
attributes
that
can
be
monitored
by
a
client
by
subscribing
to
telemetry,
then
I
read
something
about
this
scaling
in
scaling
out
and
cooling
down
and
there
in
looking
into
the
body
the
main
body
of
the
document.
It
was
really
very
hard
to
understand
what
these
straps
is
all
about.
So
I
think
the
draft
in
its
current
state
really
needs
some
significant
improvements.
S
G
I
think
that's
a
fair
question.
I
think
we
explained
within
the
young
on
the
description,
but
not
in
the
main
body,
so
that
people
has
to
have
to
read
young
before
they
understand.
But
I
agree
with
data
that
a
lot
of
description
has
to
be
spelled
out
in
the
body
of
the
draft
so
that
people
wouldn't
get
you
know
lost.
S
S
T
A
There
were
a
couple
of
comments
made
the
last
meeting
that
don't
seem
like
they
were
fully
addressed
about
I,
think
we're
okay
about
making
things
technology
separating
out
technologies,
layer,
I
think
we're
okay
there,
but
about
being
careful
about
what
thinking
about.
What's
really
a
CD
and
specific,
and
what's
really
generic
there
and
being
careful
about
that.
So
here.
H
A
Your
cleanup
that
you're
talking
about
in
the
intro
writing
just
keep
that
in
mind
and
then
translate
that
and
let's,
let's
see
what
the
next
version
is
and
let's
try
to
talk
it
about
it
between
now
and
Montreal
on
the
list,
and
if
we
get
good
agreement
that
enough
has
been
done,
what
we
can
look
for
adoption
before
Montreal.
If
it
takes
another
discussion
that
takes
into
the
discussion,
you
know
great.
P
G
G
A
A
M
A
co-author,
Daniel
King
of
the
document,
you
know
I
appreciate
that
yeah,
you
know,
readability
improvements,
you
know,
will
help
with
the
document,
but
this
is
you
know
this
is
a
document
that
we're
working
on
now
for
the
best
part
of
two
years
so
trying
to
have
something
which
is
you
know,
perfect
and
then
sort
of
cool
for
working
group.
Adoption
just
seems
sort
of
a
bit
tough
I
mean
clearly.
Telemetry
is
kind
of
a
hot
topic.
There's
requirements
from
the
AC
TM
framework.
M
A
We're
gonna
adopt
when
you
do
when
we
do
the
things
that
we've
talked
about
previously.
Some
of
the
comments
that
were
mentioned
at
the
last
meeting,
weren't
cut
weren't
addressed
so
I,
don't
think
it
should
be
a
surprise
that
we're
saying
go.
Do
the
things
we
talked
about
before.
Okay,
and
you
know,
dieter
did
bring
up
a
good
point
and
that's
a
that
is
something
that
would
be
great
to
address
before
I
think.
If
we
go
look
at
the
guidelines
for
yang
models,
you'll
find
that
it
says,
don't
use.
A
Just
the
yang
model,
don't
show
the
whole
tree.
Give
some
narrative
as
to
what's
going
on.
Yes,
yang
is
about
readability
but
give
the
intro.
So
you
know
I,
don't
think
we're
saying
anything
that
primarily
the
biggest
thing
is
I'm,
not
addressing
the
comments
from
the
for
the
previous
meetings.
Okay,
that's
the
biggest
thing,
and
this
this
other
one
is
something
that
has
to
be
addressed
before
it's
published.
Does
it
have
to
do
before
adoption?
That's
why
I
said,
let's
see
where
we
are
at
the
next
version,
good.
P
P
C
There
are
many
examples
for
the
services
Jon
just
presented
one.
There
are
others
all
these
models
describe
such
things
in
their
own
source,
specific
manner
and
all
of
them.
As
far
as
we
know,
I
relate
refer
to
the
tunnels
by
their
names,
basically,
bodies
that
can
be
used
to
go
to
the
respective
data
stores
and
extract
the
information
about
tunnels.
C
The
problems
are
that,
for
one
who's
to
say,
who's,
to,
say
how
many
services,
both
possibly
many
types
you
can
put
on
a
tunnel
or
set
of
tunnels,
and
so
that
disorder
so
will
satisfy
the
SOS.
What
happens
if
one
or
several
services
require
more
resources,
suddenly
that
we
are
pre-planned
right?
How
many
other
services
could
be
put
on
the
same
set
of
tunnels
right?
What
happens
if
donal
failed
and
it
cannot
be
restored,
so
you
have
to
basically
put
all
the
services
on
the
other
time.
C
So
what
we're
saying
this
doesn't
have
to
be
this
way,
so
what
we
suggest,
instead
of
mapping
services,
to
go
exclusively
to
tunnels,
you
can
wrap
them
implicitly
to
tunnel
pools
or
children,
but
tunnel
pool
Paula.
Okay.
So
once
you
do
this,
you
can
forget
about
service
mapping
and
remapping
and
concentrate
only
on
managing
talent
pools.
C
C
So
you
can
manage
this
tunnel
separated
from
the
services
and
what
you
can
do
is,
for
example,
start
with
a
single
tunnel
when
it
or
it's
been
through
civilization
and
if
necessary,
you
can
add,
remove
replace
tunnels
without
any
concerned
about
service
or
mapping.
You
can
add
more
sites
to
the
services,
more
destinations
again
use
set
new
tunnels,
and
that's
it.
The
sirs
already
mapped
to
the
proper
poles
next.
C
So
what
happens
since
we
presented
it
for
the
first
time
or
we
did
some
the
changes
we
had
discussions
with
some
people,
especially
useful
ways
why
steam
cooler
guy
will
go
from
four-way,
who
pointed
out
that
certain
parameters
that
we
specified
for
service
so
for
services
and
tunnels
are
redundant
and
we
actually
accessed
through
respective
data
stores,
right
like
say,
tunnel
bandwidth
or
production
capabilities,
cause
things
like
that.
So
we
remove
that
and
we
left
only
parameters
permit
pertinent
for
service
the
tunnel
mapping
such
as
like
tunnel
encapsulation.
C
What
do
you
want
to
put
on
a
packet
if
you
want
to
use
a
particular
tunnel
or
client
encapsulation?
What
additional
information
you
need
to
be
multiplexed
on
services
which
use
the
same
tunnel
so
the
next
steps?
Basically,
we
want
to
have
obviously
more
discussions
in
contrary
what
adren
said.
Our
yeast
is
not
closed,
so
we
welcome
everyone
to
join
and
we
have
one
question
for
the
chairs
and
working
group.
C
So
so
far
we
are
talking
about
making
sure
assistant
wind
tunnels
where
they
implicitly
or
explicitly,
but
there
are
situations
when
you
want
to
have
more
for
the
service
rather
than
transport
connectivity,
for
example,
some
manipulation
with
the
payload
things
like
that.
So
it
is
interesting
to
consider
steering
services
to
things
like
abject
apologies,
especially
service
function,
aware
topologies
or
enhanced
appearance
or
slices
expressed
in
any
other
way.
Okay.
So
so,
if
it's
an
interesting
proposal,
so
should
we
use
this
framework?
P
C
A
D
I
drove
here
the
one
I
actually
think
this
is
needed,
but
the
weird
thing
that
we
have
done
in
the
group
is
that
we
kind
of
started
the
tea
service,
pumping
something
like
this,
where
you
had
an
independent
model
where
you
had
the
tea
on
one
side
and
all
the
services
on
the
other,
and
we
were
creating
a
model.
But
we
as
a
working
group,
thought
that
no,
we
should
augment
the
service
models
and
include
all
the
information
there
and
we
went
and
did
that
in
the
piece
of
his
mapping.
D
But
now
we
are
creating
a
new
model
called
te
pool
and
where
the
pool
ID,
where,
on
the
left
hand
side
you
have
the
services
and
the
right
hand
side,
you
have
the
tunnels.
So
it
is
a
small
subset
of
what
we
were
doing
before
it
has
a
you
scale,
I'm
not
saying
it
doesn't,
but
we
have
just
gone
drownded
round
a
little
bit.
So
it
would
be
good
if
we
can
focus
a
little
bit
and
see
one
solution
that
can
solve
both
the
tea
service
mapping,
as
well
as
the
steeple
solution.
A
D
D
Pool
but
it
wasn't
the
pool
concept
even
in
this
pool
concept,
I
think
the
main
thing
is
like
there
are
multiple
tunnels,
though,
in
the
document
I
see
that
they
can
say
that
this
tunnels
can
be
shared
across
services,
I'm
not
disagreeing
there,
but
from
the
yang
point
of
view.
That
says
such
a
tiny
little
change,
but
we
are
creating
a
brand
new
yang
model
again
to
solve
this
one
problem.
That
was
where
I
was
yeah.
A
And
it
goes
to
actually,
interestingly
enough,
it
also
goes
to
what
we
do.
The
srte
discussion
that
we
had
earlier,
where
we're
not
creating
a
single
model,
we're
using
information
across
multiple
models
in
order
to
do
a
composite
and
useful
information.
So
there
are
two
we're
taking
the
distributed
one.
So
you
know
we.
C
C
No
I
I
was
trying
to
say
that
we're.
Basically,
it's
not
like.
We
complement
your
solution,
we're
helping
you
with
a
particular
problem
that
you
didn't
consider,
for
example,
what
happens
if
actually,
there
is
a
oversubscription
right.
So
if
you
put
more
services
on
the
tunnel
that
they
can
carry
okay,
so
should
you
always
remove
this
services
on
done?
Also,
in
such
cases,.
D
So
explicitly
yes,
so
let
me
answer
that
question
in
our
the
way
we
were
thinking
of
using
it.
We
had
another
abstraction
called
VN,
so
our
thinking
was
that
that
the
service
is
getting
mapped
to
VN
and
the
tunnels
is
like
your
tunnel
pool
where
they
can
come
and
go
and
get
created
and
things
can
change.
But
you
have
a
much
bigger
abstraction,
called
VN
which
doesn't
change
as
frequently
so
same
problem
being
solved
in
a
different
way.
Here
we
are
calling
it
a
tunnel
pool
earlier.
It
was
BN,
oh
I'm,.
C
Not
talking,
we
didn't
have
in
mind
over
your
model
right.
So,
for
example,
there
are
like
a
layer,
2
VPN
service
layer,
3
VPN
service
mapping,
signals
to
like
a
Ethernet
town,
that's
home,
Yun
presented.
All
of
these
things
require
services
once
qualified
to
put
on
one
tunnel
or
many
tunnels,
and
there's
no
easy
way
to
actually
define
or
purple
and
how
this
would
happen
without
remaining
afterwards
during
the
operation
to
make
it
brief.
C
D
Think
it
girl,
one
point,
is
Joe,
which
I
want
you
to
realize
is
that
there
is
still
an
overlap.
We
cannot
say
that
like
when
you
are
implementing
this
on
one
side,
you
will
implement
the
tea
service
mapping
thing
and
then
you
will
also
implement
the
tea
pool,
Terrell
pool
so
I
want
to
carroty,
which
one
I'm
supposed
to
use
when
and
that
part
I'm
not
getting
right
now.
What
I'm
saying
is
that
we
put.
D
I
C
We're
saying
is
that,
what's
the
sewer
system
up
to
a
ton
of
a
pool,
the
device
can
take
any
tunnel
from
the
pool
which
goes
through
the
necessary
destination?
Okay,
so
how
you
do
multi
pass.
It's
a
separate
question
if
you
want
to
basically
whether
you
use
like
that
they
entered
the
labels
or
whatever
it
is.
I
C
I
Not
that
I
was
thinking
more
in
terms
of
distributing
the
for
load
balancing
right.
So
if
you,
if
you're
subscribing
the
services,
are
putting
the
services
on
the
tunnel
which
tunnels
to
choose
with
respect
to
which
discipline
you
are
using,
do
you
want
use
the
most
filled
list
filled,
random,
feel
put
it
in
any
of
the
tunnels
or
first
fill
up
first
and
all
then
go
to
second
tunnel
and
things
like
that.
But
this
is.
B
P
So
we
still
have
these
two
documents
that
do
talk
about
mapping
client
services
to
transport
so
there,
even
though
this
sort
of
complements
the
other
one,
there
seems
to
be
room
to
put
them
under
the
same
umbrella.
So
I
would
encourage
the
authors
to
talk
to
each
other
and
see
what
they
can
do
over
it.
So.
C
I
have
already
one
model
that
basically
I
stopped
working
on
because
chairs
forced
to
actually
to
get
with
somebody
else
for
which
I
think
was
no
no
problem.
It
wasn't
in
this
work
and
go
right,
but
but
what
I'm
saying
is
that
we
have
provided
like
common
infrastructure
to
mean
it
such
model.
So
if
we
combine,
we
need
to
combine
all
of
them
into
one
umbrella
and
then
we'll
have
that.
Otherwise
it
should
be
a
separate
work
in
my
opinion,
so.
A
Sorry,
asking
you
forget,
with
the
other
authors
and
come
up
with
a
proposal
for
the
working
group.
Okay
and
in
terms
of
the
other
question
you
had
I
think
it
would
be
interesting
to
bring
up
some
specifics.
It's
a
little
hard
and
abstract,
so
I
think
an
abstract
if
you
have
additional
information.
That
is
not
sort
of
the
traditional
network
te
piece,
but
you
think,
makes
sense
to
integrate
into
the
model,
bring
it
forward
and
we
can
talk
about
it.
A
And
one
of
the
things
we
may
say
is
that
piece
of
information
yeah
a
fine
augmentation
to
what
we're
doing
it
augmentation
to
a
te
model.
But
it's
not
really
for
it's,
not
really
our
group
that
should
be
doing
it
or
we'll
say
that.
There's
no
group
that's
appropriate
and
make
sure
our
eighties
agree
and
we'll
do
it
here.
So,
but
we
are
doing
this
a
in
council.
C
A
A
We
have
to
decide
whether
we're
talking
about
an
augmentation
to
a
T
model
to
do
it
or
an
augmentation
to
a
best
model
to
do
it
and
based
on
the
proposal,
we
can
talk
about
where's
the
right
place
to
do
it
and
either
way
we'll
have
to
synchronize
across
groups,
so
I
think
the
in
abstract.
The
answer
is
well,
let's
see
that,
but
let's
see
some
specifics
that
you
want
to
work
on
and
we'll
judge
in
the
alright
in
the
specifics,
rather
than
give
a
categorical,
no
or
categorical.
Yes,.
C
F
L
L
Okay,
so
in
the
beginning
we
started
with
the
motivation
of
this
work
again,
and
this
is
try
to
reveal
what
is
the
previous
three
NPR's
control
playing
with
a
distributed
format
so
as
a
left
hand,
side
of
this
one
and
composed
by
a
group
of
protocols,
including
the
rsvp-te
or
X
OS,
PFD
and
Arabic,
but
with
the
emerging
of
the
controller
systems.
Actually,
we
introduce
further
controller
hierarchical
control
hierarchies
into
the
full
system,
but
the
control
playing
and
data
plane
still
remain
unchanged.
L
So
new
technologies
introduced
to
the
includes
a
steam
controllers,
the
net
conf
and
the
rest
Colosseum
model,
and
also
the
PC
protocols
as
centralized
control
functions.
So
centralized
is
always
you
know.
We
have
two
inter
work
with
distributed
ones
and
the
traditional
solutions,
so
this
workgroup
gives
a
description
of
how
these
two
groups
of
the
protocols
can
be
worked
together.
L
So
this
work
was
presented
in
Bangkok
and
migrated
from
second
to
T's.
So
from
after
Bangkok
meeting,
we
have
made
two
updates
based
on
the
comments
from
love,
technical
advisor
and
the
chairs,
so
in
particular
we
change
or
something
especially
for
the
a
CTA.
This
is
not
a
city,
a
specific
draft
and
we
try
to
use
the
term
as
only
an
example
of
the
implementing
for
centralized
control,
but
not
the
only
one.
That
means
so
we
don't
restrict
to
the
worked,
be
a
CTN
and
we
also
press
correct.
L
Some
of
the
description
on
the
usage
of
the
existing
solutions
like
OSPF
t
is
place
would
be
on
the
devices
and
we
also
add
some
considerations
on
security
and
metric
penalty
considerations
as
well.
So
currently
we
the
next
steps.
The
first
step
is
to
ask
for
our
group
adoption,
because
we
think
we
are
in
good
support
as
previous
two
meetings
in
two
different
working
groups
and
there
would
be
still
one
pending
issue
from
the
Lu
on
the
mailing
list
to
provide
more
detail.
L
L
U
L
L
P
L
A
R
This
is
Adrian
commenting
that
the
camera
is
placed
beautifully,
so
I
don't
have
to
be
able
to
see.
Lou
I
do
not
speak
for
the
design
team,
even
though
you
just
assigned
it
as
my
design,
team
I
think
I'd
lead
right,
yeah,
yeah,
exactly
yes,
I
lead
from
behind
and
I.
Don't
think
fold-in
is
the
right
word.
I
would
not.
If
you
look
at
the
size
of
this
document,
I
would
not
expect
to
encompass
this
document
in
3272.
A
Okay
other
comments
as
Adrian
point
out:
it's
he's
not
the
only
design
team
person
in
the
in
the
room
and
and
others
who
are
on
the
design
team
raise
their
hands.
As
I
said,
it
was
a
trick
question
if
anyone
else
would
like
to
comment.
You're
also
welcome
I'm,
not
trying
to
exclude
anyone.
I
was
just
trying
to
put
them
on
the
spot.
That's
all
other
comments.
No.
H
A
All
right,
so
the
the
one
issue
that
I
think
is
a
major
issue
for
going
forward,
although
it
is
not
necessarily
a
blocking
one.
Is
that
the
description
says
that
it
a
CTN
is
an
example.
But
then
everything
else
is
a
CTN
and
like,
like
we've
said
before,
is
unless
there's
something
that's
truly
a
CTN
specific.
We
shouldn't
make
it
a
CTN
specific.
We
should
make
it
so
it
allows
for
anyone
to
follow
that,
and
there
are
definitely
te
controllers
out
there
that
don't
follow
a
CTN.
There's,
no
reason
why
this
work
shouldn't
cover
that.
L
Yeah,
actually
III
can't
agree
with
this,
and
we
in
the
last
iteration
of
the
revising
we
did
to
remove
some
mobster.
You
know
terminology
used
for
its
it
in
specific
than
the
replaced
by
is
those
kind
of
controller
system
or
some
similar
terms.
Try
to.
We
know
protein,
the
the
usage
of
the
centralized.
L
A
A
Looks
like
almost
the
same
number
I
can't
tell
if
it's
identical
how
many
people
think
this
is
a
reasonable
starting
point
for
the
working
group
I
think
that's
actually
the
most,
so
we
have,
maybe
more
than
who
think
it's
interesting
work.
Thank
you
and
the
last
too
many
who
thinks
that
we
should
not
be.
We
should
not
accept
this
document
as
a
starting
point.
I
know
one.
So
that's
that's
very
helpful
feedback
we
can
take
it
to
to
the
list.
A
P
V
V
So
this
is
about
the
optimization
which
could
be
we
could
do
to
set
up
our
CP
TP
2
MP
resilience
mock
us
tree.
We
presented
the
in
the
mus
group
before
it's
rehome
to
here,
and
this
is
my
first
time
presenting
here
I
requested.
The
comments
on
the
mailing
list
so
far
had
has
not
generated
discussions
there.
Hopefully
this
presentation
can
trigger
some
discussions
and
then
I
will
burn
this
towards
the
one
group
adoption.
V
So
first
the
traditional
activity
appeared
on
this
signaling
we're
here
I'm
using
a
ring
topology.
But
imagine
this
is
a
just
general
topology.
The
way
the
traditional
are
with
us
with
TPP
works.
Instead,
the
set
of
one
survey
RSP
for
each
leaf
and
in
the
control
plant.
That's
one
service
officially,
but
in
the
pig
the
dead
will
actually
generate
merged,
14
states
so
that
you
don't
have
the
individual
foreign
state
towards
a
sheep.
But
that
doesn't
mean
that
there
are
lots
of
redundant
paths
and
reserve
a
state
near
the
panelling
grass.
V
V
So,
but
this
to
a
severe
speeds
in
two
to
four
different
directions
is
not
for
protection
progress
just
to
reach
different
set
of
leads
in
different
direction,
so
that
you
have
better
paths
or
better
latency
here
notice
that
we
don't
really
need
explicit
path.
You
all
you
need
to
do
is
just
sent
along
the
ring.
V
V
Now,
state
protection:
you
do
not
need
additional
signal
state
because
you
could
just
ton
of
the
traffic
in
other
direction
when
there
is
a
failure
and
that's
before
the
global
repeater
finishes
after
Theatre.
In
this
example,
let's
say
we
have
a
tunnel
that
was
R
2,
R,
3,
R,
4
P
in
the
leaves,
and
then
all
of
a
sudden,
the
link
between
our
2
&,
3
bricks,
then
r2,
who
was
sent
the
imply
traffic
before
the
global
repair
finishes,
will
send
traffic
Canada
traffic
in
the
other
direction.
V
Using
the
ring,
USP,
2,
R,
3
and
Austria
will
continue.
What
Henry's
done
can't
it'll
send
its
harmful
load.
Protection
is
similar.
It's
just
you
send
it
to
the
next
next
node
and
live
live
protection
in
those
situations.
You
don't
need
a
live,
live
production
anymore,
because
as
soon
as
you
detect
a
feeder,
you
just
ton
of
a
track
to
get
around
around
along.
V
V
To
do
that,
you
just
set
up
two
opposite
direction.
Somewhere
else
feeds
to
reach
all
the
leads
and
send
traffic
in
both
directions,
and
now
the
leaf
will
receive
duplicate
traffic,
because
your
is
recently
in
two
directions
and
you
would
deliver
the
trafficking
that
the
duplicates
but
rely
on
the
the
next
note,
our
coffee
TC,
to
do
that.
V
Discography
wickets,
and
with
this
you
can
also
MP
to
MP.
Now,
if
they
are,
the
plasmatic
also
carry
a
label
useful
down,
Sereno
three
cents
traffic
upstream,
then
there
you
have
a
MP
MP
found
out
there
and
if
you,
the
ingress,
happen
to
set
up
to
several
speeds
in
two
directions.
Instance:
just
one
direction
going
down
the
ring,
then
the
ingress
note
being
the
route
is
responsible
for
sending
the
traffic
into
the
other
direction
from
the
therapy
you're
receiving.
V
V
It
means
that
where
you
want
in
which
they're
working
on
same
traffic
and
then
the
existing
SQL
sub
P
descriptor
list,
which
typically
this
explicit
leads
now,
it
could
also
leave
at
least
ingress
itself
to
indicate
that
it's
actually
also
solicited
impressive
lives
and
and
also
the
postman's.
You
could
carry
label
objects
for
mp3
and
Paterno's.
V
So,
as
mentioned
before,
this
was
presenting
enjoys
the
group
before
this
rehomed
here
basic
comments
and
then,
after
some
polishing
record,
requests
working
group
adoption.
In
fact,
at
this
time
the
authors
believe
that
we
are
already
in
a
state
ready
for
the
adoption,
but
for
the
working
group,
I
would
like
to
see
more
discussion,
suggestions,
comments
and
then
go
from.
There
can
request
talking
about
adoption,
whatever
that
working
group,
yes
ready.
A
A
A
So
he's
nodding,
he's
saying:
yes,
it's
not
that
they
said
that
they
want
it
published
by
tease
it
just
rubber
stamped
by
tease
they're
saying
it
just
needs
to
be
worked
through
our
normal
process.
Here
that
said,
we
did.
We
do
have
the
other
arm
our
document
as
a
working
group
document,
so
it
seems
like
a
reasonable
companion.
So
with
that
said,
the
mpls
chair
is
going
to
the
mic.
So
I
must
be
mischaracterize,
something.
U
So
the
RMR
document
I,
like
the
placement
of
the
camera-
sorry
Lou
Anderson,
the
RMR
documents
are
in
we
have
to
in
MPLS
the
base
document
that
is
waiting
for
an
update
of
the
working
group
last
call.
So
there
is
no
reason
to
for
the
bit
because
of
other
documents
to
wait
for
accept
in
this
document.
If
it's
okay
to
accept
it,
you
can
do
with
that.
The
there
is
also
an
LD
P
document
in
MPLS
and
I
think
there
will
be
a
point-to-multipoint
document.
U
V
Clarified
the
under
multicast
or
PNP
site.
Indeed,
there
is
another
informational
documents
in
the
NGO
s.
Working
group
generally
talk
about
ring
or
in
a
topology
with
rings.
Harmonicas
could
work
whether
it's
native
multicast
or
MLD
p-peter
Matano
are
apt
to
be
done,
is
a
informational
framework
kind
of
document
just
describe
how
things
could
work
there,
and
this
one
here
is
specifically
about
our
speech.
If
he
can
be
tunnel
optimizations,
including
the
procedures
and
and
encodings
things
like
that,
okay.
A
A
R
R
I
Strongly
support
this
work,
because
this
is
Mancha
from
Siena
many
of
the
mobile
networks.
Mobile
wireless
backhaul
networks
are
ring
based
and
we
we
see
the
scaling
issues
and
we
really
need
this
type
of
solutions.
I
had
actually
asked
Keerthi,
maybe
a
couple
of
meetings
ago
to
revive
rmr,
stuff
and
I'm.
Glad
that
you
know
this
work
is
now
coming
along.
A
A
A
V
I
think
initially
was
just
poking
some
down
on
the
unica
side,
so
we
didn't
want
to
would
later
on
with
that
or
looking
to
a
market
solution,
I'm
Karen
Mar.
At
that
time
we
didn't
want
to
disturb
the
existing
uniqueness
document,
so
we
do
have
another
mpos,
RMR
or
document
specifically
talking
about
the
magis
options
and
how
it
works
with
various
continent.
Technologies
is.
V
Individual
I
think
is
I'm
also
going
to
request
people
to
comment
on
that,
and
we
also
request
or
congroo
of
adoption,
I
didn't
plan
to
present
it
again
because
then
there
is
no
content
change.
Yeah
I
did
address
a
lot
of
very
a
lot
of
comments
from
from
Laura.
Thank
you
very
much,
and
so
that's
the
auditorium
so.
U
Low
Anderson
again,
there
is
a
reason
why
we
haven't
started
the
working
group
adoption
Paul,
because
we
think
the
document
already
food
to
be
adopted,
but
we
wanted
to
wait
until
we
had
done
the
conclusion
or
the
working
group
last
call
on
the
aura
or
base
document.
So
again,
there
is
no
reason
to
not
adopt
document
here
before
because
of
documents
in
in
MPLS,
but
you
need
to
do
that
on
their
own
merits
and
on
this
document
here.
U
A
V
A
A
U
A
U
A
U
O
U
O
U
U
A
J
J
The
other
to
say
act
next,
please,
okay,
what
was
the
problem
statement?
We
had
the
face.
We
added
to
support
some
capabilities
to
do
discover
to
false
discovery
at
Anna
set
up
a
fabulous
temple.
Sdp
Network,
especially
the
use
case
that
we
had
face,
was
a
multi
domain
layer
neck
where
we
have
OTO
networker
and
ample
stp
capabilities
on
top
of
it.
J
So
we
have
to
set
up
OD
antennas
exposes
of
the
antennas
as
links
in
the
MPLS
TP
topology
as
a
top
and
precipitous
over
it,
and
the
scope
of
this
idea
no
impact
on
the
other
side,
but
we
notice
that
were
some
missing
information
to
to
provide
the
address
the
fit
apology
and
the
MPLS
TP
Turner
cetera.
So
we
are
working
on
own
data
next,
one.
K
B
K
J
What
was
the
approach?
The
approach
was,
the
fact
that
we
take
it
a
can
defy
the
temple.
Sdp
is
a
profile
of
mpls
with
that
he
features.
So
the
intention
is
the
temple
SDP
topology
and
tunnel
model
sugar
mint
at
the
generic,
at
tea
topology
internal
models,
which
are
defined
in
T's
and
what
we
did.
We
did
basically
a
gap
analysis.
J
What
were
the
existing
MPs
TPD
modest
and
we
look
at
and
we
add
and
develop
the
minimal
set
of
attributes
that
we
have
not
found
in
the
tea
or
MPs
to
be
modest
a
so
far
so
from
it
topology
perspective.
What
we
have
is
the
network
topology
from
I
to
R
s
and
the
T
topology
model
is
okay
and
we
had
the
tormentor
the
T
topology
model.
J
With
the
MPs
defeat
apology,
we
do
not
find
any
MPLS
t
topology
model,
so
maybe
that's
why
we
did
that
for
just
for
TP,
but
they
didn't
release
it
for
the
next
steps,
so
allow
that
analytics
after
the
same
with
edit
eternal
and
we
augmented
from
the
MP
SDP
tunnel,
because
we
noticed
that
what
we
needed
for
that
specific
cases
was
not
available
in
the
existing
IDF
draft
and
the
next
test
may
be
it
since
dpnt
are
basically
one
profile
of
hatch.
Maybe
we
can.
J
The
idea
is:
maybe
we
don't
need
to
develop
a
temple
SDP,
topology
and
tunnel?
We
just
need
to
make
sure
that
the
MPs,
DPT,
topology
and
tunnel
models
are
capable
to
be
used.
The
internet
pstp
network.
So
what
we
can
do
we
can't
a
deep
DP
topology
as
a
starting
point
to
develop
the
T
topology
or
we
and
we
can
merge
the
appropriate
attributes
that
we
have
defined
in
our
TP
tunnel
model
into
the
existing
athlete
under
model
and
next
please.
So
what
are
the
gaps
that
we
have
identified
for
the
topology
with
we
have?
J
Basically,
we
need
to
do
all
the
augmentation
for
the
technology
specific
case
in
the
topology
and
the
idea
for
the
use
case
that
we
had.
We
said
we
don't
need
to
augment
the
key
level
for
topology,
because
the
scenario
that
we
have
single
domain
tunnel
and
the
label
allocation
is
done
by
network
elements.
So
there
is
no
need
to
report
to
the
controller.
What
are
the
restrictions
on
the
labels
that
the
network
address
supports
because
at
the
end,
is
the
label
on
locating
there?
The
label
is
allotted
a
magnetic
element.
J
The
control
has
no
control
of
it,
and
if
this
is
a
generic
applies
to
every
MPLS
networks,
we
can
keep
it.
Otherwise
we
can
work
on
augmenting
those
for
the
D
band.
We
have
to
report
the
maximum
bandwidth
on
the
link,
the
maximal
or
cell
value
on
the
link
and
what
is
the
RSL
banner
on
the
linker?
So
we
have
created
a
case
MPLS
DP,
to
be
added
to
the
generated
topology
to
report
this
type
of
bandwidth,
and
also
we
have
to
report
in
the
TTP
and
India
kidding.
J
What
is
the
maximum
LSP
bandwidth
and
we
have
also
created
a
case
over
there?
That's
one
piece
and
for
the
timeless
etapa.
Basically,
what
do
we
need
to
do
is
when
we
have
when
we
report
the
computed
property.
So
what
is
the
path
that
has
been
computed
for
an
MPLS
tblsp
or
for
primary
secondary
or
for
the
LSP?
J
Then
we
need
we
have
the
label
of
hop
object,
which
has
contains
a
label,
and
we
have
a
case
that
we
have
added
the
case
for
the
MPLS
TP
label,
which
we
reuse,
the
MPLS
label
defined
by
the
archetypes
and
then
for
the
Bendel
of
the
tunnel.
When
you
set
up
a
tunnel,
we
we
have
a
direction
of
tunnel
symmetry,
so
we
have
only
want
bandwidth
and
we
specify
on
the
tunnel
and
we
specify
what
are
the
CIA
Arya
yaadon
all
these
attributes
from
the
tunnel
perspective.
Yes,
please,
okay,.
J
Time,
okay,
okay,
I
will
yeah
I'm
almost
done
so,
okay,
so
death.
That's
most!
Basically
those
attributes
insufficient
for
the
use
case
that
we
add.
Now,
if
you
want
to
go
and
merge
with
an
MPLS
the
modus
you
have
to
think
about
some
of
the
subtle
technical
issues,
so
that
are
some
of
the
differences
which,
between
DP
and
t1,
is
the
directional
SP,
and
my
feeling
is
that
all
the
be
relational
LSP
options
that
are
defined
by
ethnicity
are
already
supported
by
the
eternal.
J
So,
basically,
no
impact
just
make
sure
that
this
my
feeling
is
correct
is
more
than
enough.
We
have
a
problem
with
ecmp
when,
when
you,
when
you
set
up
an
MPLS
de
piel
SP,
the
pad
computation
should
make
sure
that
selects
only
links
which
do
not
perform
ICMP.
So
there
is
no
miss
ordering
of
the
packets
over
this
as
an
SP.
J
So
this
is
something
that
has
to
be
taken
into
account
if
you
have
a
common
topology
between
T
and
T
P,
so
some
links
which
do
perform
ecmp
can
be
useful
used
by
par
computation
for
LSP
D,
but
not
for
TP
PHP.
Also,
if
you
want
to
set
up
an
LSP
without
peace,
you
have
to
make
sure
that
the
link
that
you
select
to
the
last
node
that
is
capable
not
to
perform
PHP
and
also,
if
you
want
to
do
a
yeah.
J
Maybe
when
you
set
up
the
path
you
want
to
make
sure
that
the
nodes
in
the
know,
along
the
path
that
you
are
setting
up,
are
capable
to
recognize
the
Orion
packets
with
a
girl
I,
don't
think
there
are
other
issue
that
has
to
be
addressed
in
terms
of
topology
and
Tanis
adapter
or
the
other
diffuses
are
in
the
OEM
which
are
otoscope
here,
but
if
I
have
miss
any
I
will
be
happy
to
know,
and
so
these
are
the
few
items.
I
don't
think
there
is
any
showstopper
here.
J
Just
do
the
work
next,
one
please
so
they
are
the
open
issue.
I
see
is
the
first
point
is:
do
we
do
we
agree
as
a
working
group
that
we
should
have
only
MPs,
typically
Motors,
that
covers
both
the
ntp
and
then,
basically,
what
you
can
do
is
based
on
that
we
can
address
all
the
open
issues.
That
are
the
opinion.
Thank
you
so.