►
From YouTube: IETF95-TEAS-20160405-1740
Description
TEAS meeting session at IETF95
2016/04/05 1740
A
B
Welcome
to
the
Joint,
Chiefs
and
pls
pc
and
sea
camp
session,
focusing
the
session
ism
young
data
models.
The
data
models
that
will
be
covering
in
this
session
should
be
of
overlapping
interests.
To
folks
across
these
four
working
groups,
we
did
have
a
joint
mpls
tea
session
at
the
last
idea
for
young
models,
we
found
that
very
useful.
The
impaler's
working
group
posted
it.
B
We
thought
we
would
repeat
it
again
here
today,
along
with
the
pc
working
roof,
the
t's
working
or
volunteering
for
strip
this
time
around
secam
wasn't
part
of
our
initial
plans,
but
there
was
this
one
individual
draft
from
the
sea
camp
working
group,
which
we
thought
would
be
useful
if
it
were
presented
here.
So
thanks
to
the
sea
camp
chairs
in
the
sea
camp
working
group
for
being
part
of
this
on
short
notice,
ITF
neutral
it's
late
Tuesday
evening,
you
should
be
all
well
versed
with
this
by
now,
there's
a
link
at
the
bottom.
B
If
you
aren't
listed
with
it,
that
should
give
you
more
details
in
terms
of
session
logistics
recording
is
on.
We
are
using
me
dekho
for
folks,
you
are
presenting
there's
a
pink
box
next
to
me
within
which
you
need
to
stand
while
presenting
it
would
make
for
a
better
viewing
experience
for
remote
participants
for
no
takers,
so
we
will
be
using
etherpad.
Please
do
add
your
notes
on
etherpad
your
inputs.
They
are
always
well
appreciate
it.
You
can
also
follow
us
on
jabber.
The
own
agenda
and
slides
for
this
session
should
be
available
online.
B
C
Here's
the
summary
of
the
CH
engines:
we
have
done
since
last
ittf
session,
so
I'll
go
we'll
go
over
those
items
and
we
aligned
with
the
new
Eduard's
network,
topology
model
and
last
pirius
version.
We
had
a
few
issues
with
the
search
generic
vardenafil
model,
so
they
had
a
new
version
and
fix
some
of
the
issues
to
be
addressed.
C
C
So
also
last
ITF,
we
got
feedback
from
the
working
group
seen
that
we
should
separate
out
the
scheduling
path
of
the
model
to
separate
the
document.
So
we
did
that
and
we
submitted
to
the
net
worth
working
group
and
we
presented
yesterday
so
will
perceive
in
networking
group
for
this.
A
piece
of
the
model.
C
And
the
Pierce
version
of
the
model:
well,
there
are
some
pieces,
which
is
the
technology
specific
in
this
case,
will
be
packed
assuaging
attributes,
so
we
separate
them
out,
put
them
into
a
separate
module
so
but
the
novice
to
have
the
questions
this
one
should
be
remains
in
this
draft.
All
we
need
have
a
separate
the
document
of
days.
So
that's
one
crazy
me.
It
would
like
to
have
answer
this.
B
Question
was
posed
the
last
30th
as
well.
The
guidance
given
at
that
point
was
to
publish
that
NPS
as
a
working
group
document
separated
or
the
packet
contains,
publish
it
as
a
tease
document
piece
working
group
document,
and
given
that
it
does
have
some
mpls
portions
to
it.
The
consensus
at
least
their
informal
discussion
between
the
butcher's
is
to
share
those
details
on
the
mpls
meeting
the
system
sure.
C
And
then
we
also
did
some
fixes
in
the
model,
so
we
already
presented-
and
we
have
the
intention
to
include
the
other
alternative
information
sources.
But
this
piece
was
missing
from
the
note,
so
we
I
delayed-
and
we
also
added
support
for
the
memory
to
the
request
from
client
side
to
the
server
side.
Asking
for
apology.
C
C
We
also
did
alignment
with
the
layer
3
network
to
party
model.
This
is
the
advice
document
we
discussed.
How
do
we
correlated
this
model
with
that
registry
topology
model?
The
decision
is
to
have
a
separate
model
by
the
way
we
have
reference
from
one
to
the
other
in
case
of
the
congruent
leary
network
and
the
T
network
then
will,
however,
pretty
much
went
to
a
mapping
from
one
elements
in
the
T
in
the
layer,
32
party
model
to
another
element
in
the
teeth
quality
model.
C
Oh
worked
with
other
young
design
teams
related
for
related
work.
In
this
case,
we
discussed.
How
do
we
deal
with
the
tea
handles,
so
we
work
together
and
we
got
the
alignment
so
right
now.
The
post
models
can
work
together
and
we
share
the
same
terminologies
and
types
and
we
can
cross-reference
each
other.
C
C
And
we
also
discussed
how
to
read
through
the
modeling
abstraction.
This
is
an
example.
We
have
the
example
shows
two
layers.
We
have
a
note
from
one
to
six
and
some
other
node
in
between,
and
this
picture
shows
the
outer
modeling
I
elements
related
to
the
topology
model.
So
we
have
a
like
tango,
Tony
termination
point,
no
dings
and
everything
in
between.
C
So
if
we
make
this
into
a
node
in
details,
we
will
see
the
picture
like
this
on
the
left
side.
That's
the
node
structure
that
we
have
link
connecting
to
this
node.
The
orange
box
shows
the
LAN
card
where
the
things
are
plugging
and
the
top
blue
boxes.
That's
terminating
devices
can
be
the
transponders
and
with
some
client-side
multiplexing
capabilities.
So
in
the
middle
we
have
some
switching
component
in
general.
This
region
component
can
be
blocking,
so
we
won't
have
a
full
mesh,
then
so
I
dry
side.
We
have
an
internal
links.
C
C
C
C
D
D
@
ee
tunnels
and
interfaces
hang
models:
oh
yeah,
okay,
thank
you.
I'm
presenting
this
on
the
behalf
of
the
listed
co-authors
for
reference.
We
are
leaving
the
location
of
the
repository
where
we
keep
the
latest
in
yang
models.
There
a
high-level
overview
of
what
I'm
going
to
go
over
today,
like
over
the
updates
from
the
previous
revision
for
both
documents,
the
open
issues
and
I'll
describe
the
next
steps
would
be.
D
The
first
update
that
we
made
or
introduce
this
to
the
document
describing
the
generic
model
was
to
address
the
need
to
model
T
data
outside
the
device
for
the
T
genetic
model
contain
data
that
is
local,
that
has
local
scope
like
interfaces
and
interface
properties,
device,
timers
and
so
on,
and
global
globally
scope
like
tunnels
and
LSPs.
In
so
in
order
to
model
data
outside
of
the
device
we
we
had
to
regroup
key
data
and
the
T
genetic
model
into
generic
and
device
specific
the
device.
D
D
So
the
natural
way
to
attach
the
genetic
model
was,
we
thought
would
be
under
a
technology
augmentation
or
technology
route,
basically
for
for
each
technologies,
and
then
you
would
augment
it
with
the
additional
properties
for
the
technology,
as
is
yang,
language
is
not
allowed
to
attach
the
same
module
for
under
multiple
places
in
the
yank
trees.
So
there
is
some
proposals
being
driven
at
net
mod
working
group
and
I
think
we're
reaching
they're
converging
on
one
solution.
D
D
With
a
solution
being
proposed
at
net
mod
and
will
keep
the
working
group
updated
on
those
I'll
actually
go
over
the
limitations
that
we're
going
to
face
and
the
next
slide
other
updates.
We
had
to
do
with
our
generic
comments
and
edits.
Basically,
there
was
asked
that
we
reflect
the
actual
path
of
the
LSB
a
regardless
of
the
signaling
protocol.
We're
using
there
is
a
record
route
that
RSVP
would
collect
using
signaling,
but
that
assumes
you're
using
our
GP
signaling
protocol
for
the
key
use.
Cases
that
are
CP
is
not
there.
D
There
was
an
ask
that
we
would
have
an
agenda,
a
list
of
objects
that
describe
the
actual
LSP
path
in
the
TTT
generic
model
and
and
for
that
we've
added
that
list
in
there
and
a
TD
generic
model,
the
other.
The
other
update
that
we
made
was
to
address
the
tunnel
termination
point
identification
that
xuefeng
had
described
earlier.
D
Other
a
small
minor
edits
that
we
we've
done.
We
renamed
the
PSC
acronym
to
mpls.
We
thought
this
is
less
confusing
and
we
introduced
a
new
model
to
hold
to
hold
the
mpls
specific
data.
I
know
some
people
might
not
like
what
might
like
it,
but
okay
on
this
figure
here,
I'm
describing
the
relationship
of
the
modules
that
we've
been
that
are
described
in
the
working
in
the
documents
that
I'm
talking
about.
Basically,
the
the
T
genetic
model.
D
If
we
had
to
mount
or
basically
attach
this
to
mpls,
the
thinking
is
we
would
you
know
using
this
mount
capability,
we
will
mount
all
of
the
TE
properties
or
data
to
mpls
and
eventually
other
technologies.
I'm
green
I'm,
displaying
here
grayed
out
boxes
that
are
not
described
in
the
in
the
documents,
will
have
to
be
done.
Other
boxes
that
are
grayed
out
in
this
figure
our
boxes
that
our
future
our
work
that
we're
thinking
to
address
in
the
subsequent
updates.
D
D
D
E
Huawei
is
it,
can
you
get
go
to
the
slide
where
you
have
the
PCC
I
give
a
PCC
dockyard,
doesn't
matter
so
you
were
thinking,
but
we
are
in
piece
of
working
group.
Our
aim
was
to
have
idea
of
peace
f
y,
which
is
kind
of
generic,
whether
it
is
any
piece
of
speaker
a
PCC
or
pce.
What
is
this
idea
of
de
PCC?
Does
yeah.
D
So
the
thinking
is
any
specific
additional
data.
That's
the
pc
server
would
give
to
the
pcc
client.
You
would
have
to
store
it
on
the
PCC
and
you
would
have
to
model
it
as
well.
So
this
is
why
we're
introducing
this
additional
augmentation
of
PCC
properties,
whatever
you
want
to
store
on
the
device
I
think.
E
D
E
D
F
Ceremonia
I'll
test
the
HTF.
You
mentioned
that
the
mother
will
cover
the
device
and
mobile
control
so
that
we
needed
you,
yes
and
so
I
en
route
to
the
motherland,
exactly
it's
clear
to
how
to
divide
on
Latin
NSPS
right,
but
not
on
the
Turner's,
because
you're
missing
the
sauce.
So
always:
okay,
yeah.
D
So
to
be
able
to
model
the
network,
you
want
the
data
to
be
globally
scoped
right
and
we
did
have
a
discussion
within
the
authors
on
this
topic
specifically
and
because
the
tunnel
is
keyed
by
name,
we
could
have
introduced
the
source
as
an
additional
key
so
that
it's
becomes
uniquely
global.
But
we
thought
because
it's
a
name
you
can
prepend
it
with
the
router
name
at
the
beginning
and
and
the
name
becomes
globally
unique
for
Delhi
for
the
tunnel.
Now
this
is
what
and
and
in
addition
basically
or
on
all
the
implementations
out
there.
D
F
D
G
E
H
I
D
We
thought
of
it
the
source
name,
Whedon's,
yeah
I
mean
you
could
put,
I
p
address,
but
we
thought
about
embedding
a
distinguisher
within
the
tunnel
name
and
if
that
you
know
that
is
not
suitable.
Let's
discuss
that.
You
know
maybe,
on
the
list,
I
mean
embedding
a
source
by
itself,
not
a
big
problem
in
the
model,
but
we
thought
all
of
the
vendor
representative
thought
it's
possible
to
do
a
name
based
globally
unique
identifier,
name.
D
B
H
H
D
H
J
Though
I'm
not
sitting
there,
I
am
a
co-chair
here,
a
few
things
name
naming
Amy,
so
you
didn't
want
to
use
PSC.
So
you
used
mpls
to
me
that
is
going
to
lead
to
confusion
down
the
road
and
because
we
have
some
base
models
which
are
mpls,
which
we
are
going
to
use
for
things
that
aren't
packet,
but
we're
going
to
talk
about
mpls
is
tacit
and
I
respect.
That
DSC
is,
is
a
gene
dls
centre
term,
so
avoiding
it
is
just
fine,
maybe
just
use
packet.
That's.
J
J
L
J
Having
mpls
implicitly
always
be,
PSC
is
going
to
cause
confusion
when
we
look
at
building
blocks,
I
had
a
couple
of
other
two
other
points,
but
maybe
we
can
get
some
responses.
Discussion
around
that
and
I'll
be
sensitive
to
time.
So
I,
look
to
the
guys
in
the
front
actually
did
the
timekeeping
here.
D
Well,
GL,
that's
a
good
question.
Actually,
the
way
we're
describing
RSVP
mpls
is
for
packet,
I,
think
it's
more
or
less
close
to
what
Lou
is
hinting
to,
but
we
have
augmentations
of
the
rcpt
genetic
model.
So
if
you
want
WDM
augmentation,
we
expect
RSVP
model
to
show
up
here
augmenting
the
genetic
one.
Okay.
J
J
D
J
Well,
I
would
hope
bi-directional
is
part
of
the
core
is
quite
erection
applies
to
all
different
technologies,
except
for
classic
rsvp-te,
so
I
would
hope
you
would
sort
of
reconcile
some
other
way.
Oh
so,
or
are
you
saying
that
GM
pls
is
appear
to
RSVP
mpls
and
then
all
the
GM
pls
technologies
augment
underneath
that
yeah.
J
J
O
J
So
I
think
we're
going
to
end
up
with
a
bunch
of
Technology
specific
models.
Those
technology
specific
models
are
going
to
hang,
probably
under
these
something
that
looks
like
Gia,
pls,
probably
but
maybe
and
until
I.
Until
we
see
how
that
everything's
going
to
fit
together,
as
I
said
I'm
going
to
take
it
step
back,
remember,
I
said
I'm
going
to
take
a
step
back
that
I
don't
understand
how
this
is
going
to
work
without
the
GM
pls
JPL's
in
the
picture.
J
J
J
J
Make
it
quick
being
sensitive
time?
You
have
an
addition
of
a
use
case
for
schema
mal
right,
we
have
previously
talked
about
as
likely
to
happen
and
I
say
we
is
the
routing
design
team
I
see
the
fact
that
you're
actually
using
it
is
really
good.
Please
bring
it
to
a
net
mod
in
particular,
highlight
your
specific
UK
use
case
at
monoc
mount
one
model,
and
that
you
think
that
the
restriction
for
what
they're
already
looking
at
is.
It
is
too
extreme
for
your
use
case.
O
R
R
I
like
to
call
pcs
Bashir's
es
es
our
embassy
or
ethernet
or
London
sortir,
as
MPLS
its
confusion,
because
if
Ellis
could
be
for
different
reasons,
as
a
nurse
at
at
the
worst
could
be
a
gentle
as
could
be
still
talking
about
packet,
switching
right
and
if
the
last
could
deal
with
different
things
as
well
right,
so
so
yeah
I
would
suggest
to
go
back
to
POC.
Actually.
D
Q
Alright
thanks.
Okay,
so
shall
we
move
to
the
next
presentation?
Yeah
Derek
I
mean
so
anyone
who's
looking
at
the
agenda
online
may
be
under
the
impression
we're
running
10
minutes
behind.
But
actually
the
agenda
has
wrong
timing
written
down
on
it,
we're
actually
banged
on
schedule.
The
procession
today
finishes
at
10
/
7,
not
nor
7pm.
D
Sorry
about
that
bit
of
background,
so
we
have
to
yank
models
here,
mpls
base
and
which,
which
basically
serves
as
a
basis
for
configuring
and
managing
the
MPLS
subsystem,
as
is
now
it
augments
the
the
core
routing
data
model
defined
in
net
madrid
in
config
draft
or
working
to
a
working
group
document
and
we're
adding
specific
mpls
switching
data
or
data
it.
It
defines
the
MPLS
list
of
mpls
enabled
interfaces
and
properties,
and
it's
expected
to
be
augmented
by
other
protocols
like
te
ldp
and
LSP
static,
for
example.
Ti.
D
D
D
D
Again,
the
second
set
of
review
comments.
We
got
from
Carlos
again
suggesting
that
we
split
into
two
separate
documents:
there's
a
term
low
chair
that
is
applicable
to
multiple
paths,
basically
weighted
load,
balancing
or
weighted
low
chair
on
different
paths.
So
we
can
clarify
that
on
the
on
the
list,
other
nets
that
we
will
address.
There
is
a
question
about
the
index
of
the
label.
The
way
we
define
the
index
is
just
an
enum
Becky,
basically
defining
this
specific
label.
D
D
Next
steps,
we
we
will
address
outstanding
comments,
we
are
soliciting
more
feedback
and
from
the
working
group
and
we
would
like
to
close
on
the
approach
to
generalize
the
static
LSP
model
and
we
would
like
to
continue
with
the
working
group
other
adoption,
at
least
for
the
base
and
pls
model.
That's
it.
D
M
D
D
M
D
M
D
And
I'm
trying
to
answer
that
so
RSVP
will
create
state
and
then
provision
the
rewrites
and
well,
my
put
whatever
it
goes
with
it.
It's
a
state
driven,
LSP
creation,
and
in
this
case
we
have
configuration
data
that
persist
and
basically
your
cross
connects
and
everything
is
configuration
driven
and
what
we're
trying
to
model
is
what
configuration
and
you
know
what
operation
that
I
need
to
be
invoked
on
a
specific
label
incoming,
and
maybe
you
want
to
impose
multiple
labels
on
the
outgoing
and
we
have
all
the
examples
listed
now
RSVP.
D
It
has
all
bunch
of
state
and
timers
and
all
that
that
needs
to
be
modeled
on
its
own.
There
are
some
configuration
items
in
our
model,
but
there
is
also
state
used
by
the
protocol
right
created
by
the
protocol.
So
at
the
end
of
the
day,
I
think
in
the
data
plane
they
will
look
alike,
the
one
that
LS
be
created
by
RSVP
and
there,
let's
be
created
using
static.
They
should
look
alike
in
the
data
plane,
but
we're
not
modeling
the
data
plane.
Yet
in
yeah
right.
M
And
so
I
suspect
the
chairs
going
to
tell
me
to
go
away
and
Russian
email
in
a
minute.
Yeah
I
understand
the
data
plate
inside
of
it
and
I
understand
that
bleep
in
the
middle,
which
is
actually
you
know
what
the
coders
have
to
do
and
I'm
trying
to
ask
question
when
you're
up
there
above
it
all
and
you're
requesting
you're
either
reading
or
writing
an
LSP
isn't
actually
all
the
information
exactly
the
same.
Just
like
it's
exactly
the
same
in
the
data
plane.
Isn't
it
exactly
the
same
up
there?
So
the.
D
N
E
D
S
S
D
Q
J
Q
J
I
think
is
on
generic
comment,
even
though
we're
a
joint
session
each
the
process
is
being
run
for
each
draft
in
a
specific
spot,
so
it
should
be
the
draft
of
the
name,
and
one
other
thing
on
that
previous
one.
If
the
intent
was,
is
that
it
would
cover
both
te
and
non
te,
which
is
why
we
set
up.
He
lies
so.
T
Okay,
okay:
this
is
about
as
the
mpsf
PP
ping,
llamada
definition,
a
mini
for
the
configuration
and
false
cape
you
what
is
address
the
ins
revisions
3,
and
we
can
find
a
young
data
model
which
pissed
off
c4
379,
and
we
define
three
continuously
for
the
control
information
schedule,
parameters
and
the
result,
information
and
the
comments
from
earliest
time.
The
chairs
review
are
addressed,
what's
updated
since
the
ITF
493.
T
Firstly,
we
keep
in
line
with
the
IT
/
MP
us
at
sea,
for
37
am
peace
which
which
work
on
going
young
I'm
just
a
worker
now-
and
this
is
3
Upsy
incorporated
and
the
leaf.
The
leaf
node
for
traffic
class
is
Eddie
the
in
the
country
in
for
which
would
reference
the
Upsy
file
for
62
and
artists,
the
definition
of
tact
effect
types
and
to
make
it
comply
with
the
ops
ii
for
379
and
definitions
and
the
korea
korea.
T
Some
description
which
a
cursory
we
define
not
calorie
and
a
summer
at
our
attendees
for
control
information
faster.
We
define
the
configure
two
parameters
which
control
a
spin
test
keys
and
about
the
most
was
target
address,
tabs
defend
with
defending
the
ops
ii
for
379
and
a
supporter
reply
mode.
I
define
in
this
Upsy
and
parameters
like
is
a
timeout
frequency
and
proper
counter
and
page
size
and
did
feel
which
we'd
find
the
folder
to
control
the
test
case
and
the
schedule
parameters
define
the
test.
T
The
test
key
is
the
schedule
permit
test
so
as
ping
test
piskies
like
he
winced
at
winn,
stove
and
four
for
the
start
mode.
We
have
full
study
mode
like
as
the
started
one
now
and
started
at
a
certain
time
and
delay.
Delay
start
at
zero,
maybe
several
seconds
and
the
start
at
a
certain
time.
Td
and
three
stop
almost
like
stuff
was
right
now
and
at
the
same
time,
and
the
least
of
all
several
seconds
and
there's
a
result,
information
and
shows
the
result.
T
Many
show
the
results
of
the
current
counterSpin
kiss
kiss
&
the
peony
biopsy
45
60
is
a
reference.
The
father
permitted
definitions
and
the
ITT
and
proper
response
is
the
number
0
responses
received
a
for
the
corresponding.
As
pin
test
case
and
nest
APIs,
we
will
get
comments
on
river
industry
and
the
secant
contributions
and
collaborations
and
sixth
I'm,
just
awoke
overs
adoption.
Now
the
authors,
I
think
it
is
ready
for
putting
the
walker
adoption
and
now
we
6
the
poker
books,
o
pain
now
and
continue
discussion
on
the
modest
yeah
as
its
own.
E
So
the
aim
with
this
young
model
is
to
have
the
management
of
the
config
and
the
operational
state
of
a
piece
of
speaker,
a
piece
of
speaker
being
both
a
PCC
as
well
as
a
PCE.
We
started
off
with
our
base
RFC
5440,
making
sure
that
all
the
elements
of
a
piece
of
session
and
all
session
management
related
things
are
handled
we
later
on
move
to
the
stateful
PCE
part.
So
that's
where
we
are
with
our
model,
the
recent
change
that
we
did
since
the
last
time
we
presented,
which
was
in
Prague.
E
We
got
some
comments
from
Oscar,
so
we
handled
that
we
added
a
little
bit
more
description
on
how
the
model
would
be
used
spatially
around
the
LSP
DB
part.
Some
other
comments
were
related
to
adding
timestamp,
putting
all
the
container
or
putting
all
the
statistics
together
and
putting
it
in
a
container
called
p
sub
stats.
E
But
we
were
not
carrying
any
other
parameters
so
now,
since
the
ITF
te
has
gone
ahead
and
written
a
generic
model
which
has
the
LSP
state,
our
aim
is
to
refer
the
information
to
the
LSP
state
from
the
piece
mo,
which
is
what
you
guys
will
see
in
this
proposal.
So
this
is
what's
there
in
the
gate
and
we
are
going
to
continue
to
update
it.
E
So
this
is
where
we
are
right
now
now
we
still
have
some
open
questions
that
we
are
discussing
during
the
ITF
week
and
trying
to
move
the
model
along.
The
one
point
which
I
also
already
pointed
out
when
direct
was
discussing
was
where
do
we
put
the
for
a
particular
tunnel?
I
would
like
to
delegate
this
tunnel
to
the
PCE
or
for
this
local
tunnel
I.
Don't
I
want
local,
compute
or
I
want
pc
to
compute,
whether
in
passive
or
active
mode.
E
So
where
is
the
right
place
to
put
that
information
and
when
we
do
ITF
te
at
a
controller
when
we
want
to
set
up
a
pc
initiated
tunnel,
which
is
the
right
place
to
mark
that,
so
our
gut
feeling
from
the
P
sub
authors
is,
we
feel
maybe
the
ITF
tae
yang.
Maybe
the
right
place
we'll
continue
to
discuss
and
get
okay.
If
Tarak
wants
will
add
something.
Maybe
I
don't.
U
E
The
first
part:
yes,
what
you
just
pointed
out,
which
may
go
into
the
device,
but
when
it
comes
to
the
PCE
initiated
tunnels
that
we
want
to
put
it
to
the
controller.
So
now
it's
like
it's
a
modeling
question,
whether
we
kind
of
merge
it
together
and
keep
it
gendrich
or
whether
we
put
I
tftp,
see
initiated
there,
but
only
the
PCC
delegated
at
the
PCC
border.
So
this
is
something
that
we
can
figure
it
out,
but
the
gut
feeling
is
that
this
belongs
in
I
TFT
rather
than
in
the
config
model
of
Pisa
itself.
E
The
second
thing
that
we
are,
which
is
a
common
question,
I
think
across
people
who
are
working
on
yang.
We
look
at
the
yang,
which
is
trying
to
maintain
state
with
the
config
specially
the
interred
intended
config
state.
But
what
we
had
done
initially
was
followed.
The
general
yang
like
looking
at
IDF
interface,
etc,
and
keep
config
separate
and
all
the
state
together.
So
the
one
question
that
we
have
is
that
is
it
up
to
the
module
authors
or
does
the
working
group
within
the
mpls
has
some
guidance
to
us
to
pick?
J
So
I'm
wearing
too
many
hats
nowadays
is
Lou,
so
as
net
mod
co-chair
I'll
say
that
this
whole
topic
is
an
open
topic,
okay,
and
that
the
working
group
is
trying
to
come
up
with
a
solution.
In
short
order,
will
we
be
successful?
I
have
no
idea,
I.
Think
you'll,
know
more
by
pearl.
Am
okay
the
objective
right
now
of
those
people
working
on
it
is
that
there's
nothing
that
each
model
writer
will
have
to
do
in
order
to
support
upstate
and
that
there'll
be
some
tooling.
That
will
provide
the
additional
elements
that
we
need.
J
J
E
Thank
you.
So
what's
the
next
step,
so
we
are
adding.
This
is
the
order
that
we
are
gonna,
add
more
details
in
our
piece
of
yang.
We
are
starting
with
some
security,
which
will
include
the
old
ones
like
md5,
as
well
as
the
new
piece
of
s
and
the
TLS
feature
further
segment,
routing,
adding
Association
so
that
our
primary
and
backup
paths
and
those
things
can
also
be
handled
well.
E
So
this
is
where
we
are
right
now
we
would
request
other
working
group
authors
who
have
document
in
peace
up
to
start
helping
us
out
in
making
sure
that
we
are
modeling
the
yang
correctly,
also
I.
Think
from
now
we
would
request
if
the
manageability
consideration
can
have
little
bit
more
details
on
the
young
model
so
that,
as
a
young
model
editor,
we
get
a
little
bit
more
guidance
from
the
RPF
documents.
So
the
yang
right
now
we
have
it
in
the
gate
which
is
the
working.
E
F
L
L
As
you
see,
there
are
already
many
llamalo
the
idea
and
when
you
approach
your
mod
officers,
you
asking
which
interface
you
can
use
this
mo
to
do
is
say
whatever
you
want
to
use
here.
I.
We
want
to
be
clear
about
the
interface.
We
are
actually
looking
at
to
use
your
models,
so
you
can
see
from
this
to
use
cases.
First,
one
is
the
data
center
interconnection,
the
other
one
is
the
control
of
multi
domain
networks.
L
I
want
to
emphasize
that
we
are
really
looking
at
the
trans
optical
transport
network,
so
it's
more
focused,
but
it
might
be
applied
to
be
a
other
technology
as
well.
So
if
you
see
from
the
to
use
case
that
we
actually
are
focusing
on
the
interface
and
which
is
north
to
the
chest,
bone
erica
controller,
it
can
be
between
a
dataset
controller
and
the
transport
controller,
all
between
ox
trainer
or
coordinator,
or
they
were
quiet
and
domain
controllers.
L
L
We
have
the
list
of
a
function
on
the
first
column
and
in
the
last
column
we
will
show
the
models
which
can
be
used
to
fulfill
their
function,
so
the
models
here
you
can
see
that
in
the
teeth,
apology
and
also
we
have
the
technology,
specific
events,
the
WDM
topology
and
also
audio
topology
and
for
the
tunnels.
We
have
the
t
tunnel
and
we
are
also
looking
at
whether
we
need
extension
to
extend
from
the
T
tunnel
to
cater
for
the
ODU,
tano
and
och
tunnel
and
the
other
one
is
the
service
request.
L
Here,
actually,
I
will
show
in
the
next
slice
that
we
think
there's
a
need
to
have
a
service
model
which
is
not
up
with
had
a
booster
and
the
like
the
details
of
the
technology
and
for
the
client,
client
usage
and
the
the
other
way.
The
final
function,
which
is
the
washer
neck
operations
it
it's
a
it's
actually
other
ones
future,
but
we
see
that
maybe
the
topology
job
I
mentioned
before
can
still
apply
to
this
function.
L
So
here
it's
just
showing
the
young
model
tree
of
the
surface,
the
transport
service,
but
here
is
only
focusing
on
connectivity.
We're
also
thinking
about
other
service
as
well.
So
here
is
just
our
first
cap,
Jose
I'll.
First,
try
of
the
capturing
the
survey
connectivity
service
model
as
you
can
see
from
the
model.
Maybe
it's
not
really
nice
in
particular
focus
on
the
optical
transport.
It
may
be
applicable
to
other
technology
as
well.
So
I
think
that's
why
the
draft
is
presented
here
so
I'm
not
actually
presenting
any
details.
L
L
We
can't
do
that
yeah,
that's
that's
a
good
feedback,
but
I'm
at
moments.
The
reason
why
we
do
separately
is
because
valley-goose
its
internal
model,
you
can
see
details
like
name
the
administrative
group
as
well
as
the
name
nostalgie
I.
Just
think.
The
client
who
wants
to
touch
I
mean
to
that
details.
That's
the
reason
we
would
motivate
us
to
make
you
separate
for
now.
Yeah.
D
L
D
J
L
J
We
tend
to
have
fuse
cases
that
are
technology-specific
makes
perfect
sense.
I
think
that
the
details
then
belong
in
mtgs
and
you
still
have
to
address
the
other
issues,
but
will
address
that
it
within
the
t's
working
group-
and
you
know
clearly
they
should
give
the
opportunities
the
sea
camp
chairs,
who
I
think
are
in
the
room
if
they
want
to
say
anything.
J
M
M
L
L
E
K
Related
to
the
northbound
system,
specifically
Ron
orchestration
system
and
not
rly
yeah
relating
to
this
that
devices
themselves
yeah.
Thank
you.
Following
this
picture,
direct
by
directional
arrows
then
do
do
we
really
need
to
have
the
specifics
in
the
model
that
defines
describes
each
and
every
node
where
the
service
needs
to
be
instantiated?
What
do
we
want
to
have
a
lot
more
abstract
in
action
model
where
the
controllers
or
the
intermediate
tree
would
actually
know
the
specifics,
and
the
orchestration
system
would
only
convey
in
the
model
using
the
model,
really
abstract
information?
K
L
Think
you
are
right
to
some
extent,
I
mean
for
like
food
service
model,
it's
really
generic.
It's
not
really
doesn't
care
about
technology
specifics,
but
there
are
some
use
cases,
for
example,
on
unknown
for
your
sched
to
for
a
multi-domain
optical
network.
They
still
need
to
expose
some
detail
which
is
probably
technology-specific,
so
we
really
need
to
just.
You
have
a
use
case
where
you
see
where
there's
more
technologists
agnostic,
they
don't
care
about
the
details
or
they
do
care
about
yeah.
L
W
B
Q
P
K
K
So
first,
we
certainly
had
the
privilege
of
having
our
chairs
actually
read
and
provide
as
the
comment
and
we
went
into
the
lengths
to
actually
address
all
of
those
comments
that
we
receive
and
we
actually
made
some
of
the
specifics
around
the
trees
organized
very
clear
in
their
drop
and
so
there's
a
lot
of
good
illustration
and
figures.
You
find
right
from
the
high
level
to
the
actually
low
level
so
that
some
and
you're
going
to
see
a
snippet
on
the
next
slide.
The
third
within
the
design
team.
K
Many
times
we
found
out
during
a
conversation
that
we
got
a
little
bit
loose
in
using
these
terms
and
when
we
got
to
actually
putting
them
in
the
young
model,
it
became
slightly
difficult
for
us
to
all
stay
on
the
same
page
and
part
of
that
had
to
do
with
how
these
terms
were
used
in
5036
and
part
of
them
really
had
to
do
with
how
we
started
to
have
our
own
interpretation
around
them.
So
we
went
really
strict
with
these
definitions.
K
In
the
revision
2,
we
don't
really
have
any
representation
for
the
state,
so
the
operational
state,
which
is
the
derived
state
and
non
version
3.
We
got
that
that
well
covered
now,
of
course,
is
still
some
some
more
modification
that
might
come
along
once
we
go
through
the
time
cycle
and
once
the
net
mod
group
actually
working
group
decides
what
direction
they
want
to
take.
K
In
terms
of
how
they
need
the
tree
needs
to
be
organized
for
a
state
we're
going
to
align
there
and
because
of
some
of
these
changes,
we
went
through
and
really
cleaned
up
the
entire
document.
So
hopefully
now,
if
you
get
to
read
it,
should
it
should
not
get
sleepy
within
five
minutes.
He
should
at
least
stay
awake
for
15
minutes.
We
limited
the
number
of
authors
in
the
main
section,
so
here
the
specifics
or
ross's
commons
and
all
of
them
go
to
address.
K
So
here's
the
the
high-level
yank
tree
looks
like
okay
and
here's.
The
picture
of
course
there's
a
better
one
in
the
draft.
Basically,
you
have
the
config
with
the
state
in
this
container
and
then
you
got
our
pcs
this
container
and
then
the
notification
of
course,
then
all
the
relevant
details
go
industry.
So
if
you
nothing
else
in
a
few,
where
took
picture
like
hardest
LEP
Emily
Petrie
look
like
this
is
what
you
need
to
walk
away
with.
That's
really
the
high-level
organization.
K
Everything
else
is
all
inside
these
large
containers,
so
I
mentioned
the
this
fine
tuning
of
these
three
terms:
right,
neighbors
session
and
peers,
and-
and
you
know,
I'm
one
of
those
who
have
been
using
these
terms
very
loosely
for
many
many
years
and
with
this
and
I'm
going
to
take
a
pause
for
you
know
ten
seconds
and
let
you
glance
through
it
with
this,
we
actually
fix
it,
and
I
hope
this
also
goes
into
other
working
groups,
because
this
doesn't
just
apply
to
LEP.
It
applies
to
bgp
at
minimum.
K
Okay,
my
paws
just
handed
neighbor
has
nothing
to
do
with
exchanging
information
such
as
binding
label.
Information
neighbor
has
nothing
to
do
with
TCP
constructs.
The
definition
of
neighbor
in
this
case
is
all
around
hey.
I
know
about
an
entity
connected
to
the
other
side
of
the
link
or
somewhere
in
the
network,
whether
its
basic
discovery
or
targeted
discovery
session
is
at
East
session
with
the
neighbor
and
then
Pierre
that
we
got
past
having
a
session
we're
not
exchanging
bindings,
whether
its
adverse
findings
label
bindings
are
both.
K
So
that's
really
the
definition
that
we
sort
of
fine
tune
and
thanks
to
lower
for
pushing
us
to.
Actually,
you
know,
get
really
crispy
with
this.
So
now,
when
we
go
into
the
model
of
you
think
about
in
a
config
less
but
more
about
the
stage
you're
going
to
have
to
you
know,
you
may
have
an
entity
remote
entity
that
may
be
in
one
of
these
three
buckets.
So
now
we
can
have
a
much
more
strict
way
of
tracking
where
that
remote
lsr
in
what
state
the
remote
eleazar
really
is
in.
O
So
low
Anderson
and
I'm
a
bit
split
here,
because
I'm,
a
author
of
the
LDP
specification
and
I,
also
a
member
of
the
same
team
and
I,
actually
have
when
I
see
that
the
slides
on
on
the
screen
here
I,
don't
think
we're
doing
anything
more
strict
when
we're
doing
in
our
su-30
to
be
doing
exactly
the
same
thing.
This
are.
These
are
the
definitions
that
we
have
in
their
5036,
so
there
is
no.
O
O
K
Thank
you
derived
state
right
or
the
operational
state,
as
many
of
you
would
refer
to
so
we
added
that
in
version
32
that
really
four
areas
in
which
that
we
are
tracking
the
all
the
state
information.
So
the
first
one
is
neighbor.
It
just
sends
you
the
second
one
is
fear.
Third,
one
is
bindings
and
fourth,
one
is
capabilities.
There
is
the
snippet
of
how
that
looks
like
again
from
the
high
level
standpoint.
K
K
Either
you
could
have
your
config,
which
is
intended
state
along
with
you,
applied
state
in
one
bucket
and
and
derive
state
in
another,
or
he
could
have
intended
config
and
in
one
and
applied
and
derive
in
another
or
third
scenario.
Third
variation.
You
could
have
all
those
three
things
in
11
bucket,
one
container
for
each
and
every
field
right
and
the
pros
and
cons
of
how
you
want
to
go
about
it
and
right
now
the
the
yang
guideline
out
of
the
net
mod
working
group
has
no
recommendation
and
I
personally
have
a
problem
with
that.
K
I
think
there
should
be
guideline
so
that
LEP
doesn't
end
up
doing
things.
The
way
a
versus
RSVP
comes
along
and
I'm.
Making
this
up,
nothing
specific.
Does
it
be.
Bgp
comes
along
and
just
see
and
then
me
being
an
ereader
I'll
scratch
my
head,
and
you
know
its
struggle
to
make
sense
of
it
from
basic
parsing
point
of
view.
So
I
wish
there
was
a
guideline.
There
is
none
right
on
the
way
lip
is
written.
K
J
J
K
K
K
I
appreciate
your
support.
Thank
you
on
the
next
item.
So
I
briefly
mentioned
LSR
ID
to
eat,
LSR
ID
rather
ID.
All
of
us
tend
to
think
of
a
zone.
Configures
IP
addresses
and
big
change
that
we
made
is
cross
a
document
because
we
have
decided
to
use
dotted
quad
moved
on
from
using
you
and
32,
and
no
more
IP
addresses
for
sure.
K
So
the
lsr
ID
is
all
limited
to
just
the
yang
type
are
dotted
cord
and
we
really
hope
all
of
the
protocols
outside
the
MPLS,
a
working
group
of
course,
and
also
adhere
to
it.
So
there's
one
way
to
define
router
ID
and
whether
that
is
being
used
by
ldp
as
a
protocol.
Bgp
ospf
or
you
know,
pick
your
next
favorite
protocol
to
begin
with.
So
that
way
there
are
no
two
different
ways
for
us
to
configure
the
router
ID
on
the
box.
K
Oh
and
I
hope
that
you
know
that
goes
along
and
gets
embraced
by
everybody
else
the.
So
we
still
doubt
some
of
the
things
that
on
our
list
on
our
in
a
bucket
for
us
to
do
the
way
we
have
started
to
discuss.
You
know
how
we
want
to
decouple
applied
state
from
derived
state
I.
Think
there's
something
that,
within
the
design
team,
we
are
still
got
some
more
discussion
and
alignment
to
take
place.
K
Then,
of
course,
as
MPLS
base
comes
along,
we
want
to
make
sure
our
model
ldp,
NM
LDP's
is
well
in
alignment
with
ldp
mpls
base
and
then
based
on
that
more
direction.
If
that
recommendation
comes
along
to
be
something
different,
we
want
to
make
sure
we're
in
alignment
with
that
as
well.
Of
course,
that's
going
to
continue
on
whether
you
know,
even
after
the
working
group
adoption
based
on
one,
that
those
other
troughs
get
revised
or
recommendations
get
changed.
So
really.
The
next
step
here
is
to
request
for
adoption.
K
Q
Okay,
well
I
think
that
was
really
useful
session.
I
found
it
very
helpful.
I
want
to
thank
my
co-chairs
for
for
putting
this
together,
all
of
them
even
the
ones
not
here
and
and
also
special
mention
said
to
Matt
my
hardly
fair,
putting
together
via
the
agenda.
He
worked
hard
thanks
to
all
the
presenters
that
was,
that
was
really
good
and
the
people
that
people
are
going
to
discuss
at
the
mic.
I
think
you've
helped
move
things
forward.
So
that's
the
end
of
our
agenda.
We're
finishing
a
couple
of
minutes
early
thanks
for
that.