►
From YouTube: IETF94-TUTORIAL-YANGbyExample-20151101-1500
Description
YANG by Example at IETF94
2015/11/01 1300
A
B
Event
as
we
before
some
yang
and
Matt
comes
ready,
so
the
agenda
is
like
this:
we're
going
to
have
two
hours
on
net
conf
and
yang.
So
this
comes
from
the
yang
model,
Commission
groove,
so
we
want
to
have
not
years
of
trainings
the
first
time
it's
about
Yang
and
Matt
Kampf.
There
are
things
that
we
have
you
are
not
covering
here.
These
are
for
future
use
future
developments.
This
is
rest
count
and
what,
if
you
are
a
developer
using
library,
etc?
So
it
might
be
for
next
time.
B
The
second
part,
after
maybe
a
small
break,
is
how
to
use
ping
to
compile
your
yang
models.
We
still
have
some
models
that
are
posted
in
ITF
drivers.
Don't
compile
correctly
in
January
we're
going
to
have
part
of
ID
myths,
we're
going
to
have
the
p-n
compilation
that
will
give
you
all
the
error
messages
so
that
you
post
a
draft
without
any
compilation
errors.
B
In
the
meantime,
we
have
a
website
that
I
guess
you're
going
to
speak
about
the
yang
validator
calm,
and
the
last
party
agenda
is
what
we've
been
having
the
yang
advice
anything
session,
we're
going
to
have
the
young
doctors
here.
If
you
are
working
on
a
yang
data
model-
and
you
want
to
get
some
advice,
not
like
compilation
errors,
I
mean
this
is
not
the
point,
but
you
can
ask
question
about
it
as
well.
Like
design
questions
then
come
with
your
yang
model,
we're
going
to
have
a
list
of
all
the
young
models.
B
One
doctor
will
be
assigned
to
you
and
you
will
receive
like
free
consulting.
Otherwise
you
can
go
and
pay
later
on
and
I
think
that
the
nation,
like
beers,
are
welcome.
What
else
this
will
be
recorded
with
me.
Take
oh.
This
should
be
on
youtube
later
on,
not
the
last
part.
The
next
sense
there
is
nothing
to
record
there,
but
net
Kampf
yang
and
the
P
hang
part.
So
please
make
sure
use
the
mic.
Otherwise
I
mean
we
need
to
lose
the
questions
and
on
YouTube
and
I
think
that's
it
and
joy.
C
Okay,
so
I'm
not
gonna,
use
the
full
four
hours,
I'm
gonna
use
two
hours
or
try
to
use
two
hours.
So
what
I'm
gonna
try
to
do
here
guys
and
girls
is
I,
have
two
modules
that
will
go
through.
This
is
newly
created
training
material
and
the
intent
again
from
the
yang
coordination
team
is
to
take
it,
make
it
useful
and
make
it
open,
so
anyone
can
use
it,
take
it
and
run
with
it.
So
this
is
a
trial
shot.
C
You
guys
are
the
test
audience,
which
means
that
for
me
to
take
anything
out
of
this
is
I
need
feedback,
I
need
questions,
I
need
raised,
hands
and
whatever
you
can,
you
know
give
me
and
of
course
it's
a
scary
crowd.
Some
of
the
people
that
actually
wrote
the
spec
is
here,
which
makes
me
a
little
shaky
and
I'm
relieving
on
them
to
help
me
to
you
know,
fix
any
any
inconsistencies.
C
So
two
sections
they're
roughly
the
same
size,
we're
gonna
start
with
yang,
and
this
is
way
the
way
we
structure
this.
The
way
we
want
to
do
this
training
material
here
is
along
these
lines,
so
we're
gonna
use
an
example
somewhat
real-world
example
and
walk
you
through
the
yang
models
that
we
have
some
of
them.
Some
parts
of
them
are
actually
standards
track
or
standards.
Some
of
them
are
drafts,
so
we're
gonna
use
this
example
to
walk
you
through
the
features
of
yang
okay.
C
There
will
be
a
lot
more
to
learn
after
this
tutorial
by
reading
the
specifications
by
diving
into
the
actual
sea
of
yang
models
that
we
now
have
the
ITF
and
in
other
places,
but
you
should
understand,
be
able
to
identify
and
describe
the
common
elements
and,
more
importantly,
perhaps
you
should
be
able
to
take
a
look
at
a
yang
model,
understand
what
valid
configuration
or
valid
instance
data
according
to
that
yang
model.
Actually
is
because,
as
you
guys
may
or
may
not
know,
I'm
gonna
say
now
yang
is
a
data
modeling
language.
C
C
We're
gonna
use
a
couple
of
yang
models
here.
As
you
may
know,
we
are
now
producing
a
steady
stream
of
RFC's
that
includes,
or
has
yang
models
in
them.
Some
of
them
have
a
single
yang
model.
Some
of
them
have
several,
so
we're
gonna
use
some
of
the
ones
that
we
believe
are
going
to
be
core
for
anything
network
related
going
forward.
So
if
there's
some,
where
you
want
to
start
on
yang
and
most
of
the
people
here
are
network
centric,
the
ones
that
I
would
start
with
is
the
IP
interface
management
and
IP
management.
C
That's
a
pretty
obvious
starting
point
for
any
kind
of
understanding
on
how
to
apply
this.
The
networking.
How
do
we
define
what
an
interface
actually
is,
that
was
a
fun
journey
to
actually
agree
on
a
way
of
structuring
interfaces,
and
how
do
you
actually
actually
configure
ipv4
and
ipv6
on
this
structure
and
then
we're
gonna
use
some
types
and
interface
types
and
we
wanted
to
make
it
a
little
realistic.
So
we're
going
to
put
it
in
an
MPLS
context,
there's
a
couple
of
directions.
C
And
the
environment
kind
of
looks
like
this.
We
have
three
main
tasks
that
we
use
to
drive
you
guys
through
these
features.
We
are
going
to
enable
some
interfaces,
so
take
a
look
at
what
are
the
data
structures
that
you
need
to
understand
in
order
to
enable
interfaces
on
the
routers
we're
going
to
assign
ipv6
addresses
to
the
newly
enabled
interface
and
then
we
are
going
to
configure
static,
MPLS
LS
piece?
C
Okay,
that's
the
entirety
of
the
journey,
hopefully
along
this
journey,
you
guys
will
have
a
good
understanding,
then
of
the
basic
features
of
the
yang
language,
so
we're
gonna
start
off
by
the
first
task,
enabling
the
interfaces
and,
of
course
yang,
is
a
data
modeling
language
and
don't
worry
we'll
get
into
the
curly
braces
real
soon.
Some
of
the
things
that
we're
going
to
look
for
here
is,
of
course,
structure
right.
C
There's
a
structure
to
the
data
model,
there's
a
big
difference
in
yang
between
configuration
and
operational
data,
we're
going
to
look
at
both
built-in
meaning
that
there
are
data
types
that
is
part
of
the
Yang
language.
There
are
now
also
a
collection
of
ITF
data
types
and
we're
going
to
look
at
how
we
customize
or
you
can
actually
extend
the
data
types
to
create
your
own.
C
So
those
are
the
main
features
that
we're
gonna
look
at
in
this
part
and
it's
useful
to
start
from
the
top
and
look
at
a
visual
representation
of
the
data
model
that
we're
looking
at.
So
in
the
ITF,
as
I
mentioned,
we
took
on
the
daunting
task
of
seeing
if
we
can
agree
on
a
one
single
model
for
interfaces
across
all
vendors
and
across
all
stakeholders
and
the
visual
modeling
of
this
is
this:
there's
two
data
trees.
C
If
you
like,
there's
one
data
tree
to
the
left
or
actually
in
yang
lingo,
we
would
say
containers
so
there's
two
containers
in
this
data
model.
One
is
called
interfaces,
it's
actually
a
list
and
it's
got
a
couple
of
parameters.
A
couple
of
data
points
to
each
member
of
the
lists:
it's
keyed
off
a
name.
It's
got
a
type,
it's
got
a
boolean
that
describes
whether
it's
enabled
or
no,
and
it's
got
a
way
of
mentioning
whether
we're
going
to
enable
traps
for
this
interface.
C
Okay,
so
that's
the
readwrite
part,
that's
what
you
can
configure
okay
and
then
we
have
to
the
right
side.
We
have
a
really
only
part
called
interfaces:
state,
okay,
they
look
quite
the
same
in
general,
except
for
a
couple
of
things,
for
example
operational
state
like
date
and
time.
When
did
this
interface
change?
Last?
If
you
guys
for
those
of
you
who
have
a
background
with
me,
you
will
recognize
all
these
things.
C
We
didn't
reinvent
much,
but
we
actually
took
most
of
the
things
that
we
had
learned
from
the
IAF
nibs
and
translate
that
into
useful
yang
and
in
order
for
to
support
stacked
interfaces.
We
needed
also
to
be
able
to
reference
from
an
interface
to
another,
and
the
reason
why
we
split
configuration
and
state
was
that
in
many
systems
you
can
actually
have
available
interfaces
that
are
not
configured
a
newly
inserted
line.
Cord
might
not
necessarily
have
configuration,
but
it's
around
so
it
probably
has
operational
States.
C
You
may
also
have
configured
interfaces
that
are
not
physically
around
many
vendors
allow
for
pre
configurations,
you're
able
to
set
stuff
up
in
a
while
waiting
for
a
line
cord
to
be
slaughtered
in
so
we
needed
these
to
be
separate
entities,
so
one
could
live
without
the
other.
There.
We
go
first
question.
First,.
A
A
C
I'm
looking
I'm
sure,
because
I
am
so,
we
ended
up
reasonably
close
I.
Guess
it's
a
flat
list.
That's
maybe
that's
important,
so
there's
no.
For
example,
there
is
no
containment,
so
there's
no
three
structure
of
interfaces
so
in
terms
of
stacked
interfaces
or
later
interfaces
that
solved
by
the
interface
state
ref,
rather
than
actually
using
a
three
structure
for
it.
So
I'd
say
it's
reasonably
similar.
If
you
look
at
the
details
again,
we
won't
go
through
everything,
there's
also
nice
mapping
to
the
if'
mid
name.
C
C
And
here's
another
thing:
that's
important:
we
threw
out
this
presentation.
This
is
kind
of
what
I
visually
struggle
with
a
little
bit
so
I'm
gonna
try
this
on
you
guys
it's
a
big
difference
between
when
I
talk
about
model
structure
and
when
I
talk
about
instance,
data
structure,
so
the
model
would
typically
be
in
Yang
and
the
instance
data
would
be
your
actual
configuration
or
operational
data.
Your
counters
right,
so
the
interface
is
list,
of
course,
to
the
left
here.
C
According
to
the
model
cleared,
okay,
there's
a
little
sea
of
nodes,
so
that
seems
to
be
seems
to
be
okay
and
well.
The
example
here,
of
course,
shows
that
they
might
look
the
same.
They
are
the
same
type.
They're
enabled
of
this
guy's
actually
have
to
link
down
trap,
enable
that
enable
false
and
their
names
their
keys
are
easy,
eth0,
eth1
or
eth3.
So
there
there
are
differences,
of
course,
between
the
the
list
entries.
C
Okay,
here
we
go:
here's
the
first
glimpse
of
yang
all
yang
files
have
a
header
and
again,
if
you
guys
have
any
background
in
memes,
you
will
be
surprised
about
nothing
here
right.
These
are
mostly
I
will
go
through
the
details,
informational
stuffs,
you
have
your
organizational
affiliation.
You
have
your
contact
information,
but
things
to
pay
attention
to
on
the
top
here
is
actually
the
module
name.
This
is
really
a
key
feature.
A
key
thing
about
yang
all
modules,
have
a
name
that
name
for
good
module.
C
Writers
need
to
be
globally
unique,
so
you
need
to
spend
some
time
thinking
about
the
structure
of
the
module
name.
Now,
if
you
develop
yang
modules
in
the
scope
of
eitf
you're
good,
because
we
actually
suggest
a
structure
and
by
prepending
IDF
we
actually,
okay,
we
have
some
some
freedom
of
making
sure
that
we
don't
overrun
each
other,
so
the
module
name
is
important
and
also
it
ties
into.
C
This
comes
as
a
surprise
for
some
people
that
there's
actually
a
formal
mapping
from
the
module
name
and
the
revision
we'll
get
to
that
to
what
the
file
name
for
this
yang
module
should
look
like.
So
a
file
a
formally
well
specified
mod
yang
file
is
supposed
to
be
a
concatenation
of
the
module
name,
ITF
interfaces
in
this
case
and
the
revision
okay,
so
the
formally
correct
file
name
for
this
guy
here
would
be
ITF
interfaces
at
sign
and
the
revision
dot
yang.
Okay,
this
is
new.
This
helps
quite
a
bit
for
tool
makers.
C
All
they
need
to
know
when
looking
in
file
systems
is
the
module
name
of
the
module
ailing
combined
with
the
revision,
and
they
can
look
in
their
paths
or
what
have
they
and
understand.
This
is
the
connection
between
the
module
and
where
the
physical
manifestation
of
it
is
okay,
so
that's
important
and
the
module
name
will
come
back
later.
C
So
you
declare
your
namespace
that's
supposed
to
be
a
URI,
so
you
can
either
take
a
URL
that
you
own
yourself
like
a
domain
name
or
HTTP,
or
in
this
case
again,
if
you're
with
the
ITF
and
produce
these
things
in
the
scope
of
the
ITF,
we
have
a
Ayanna
registered
namespace,
a
URL,
ITF
yeah.
You
can
see
the
path
going
there
and
you
prepend
the
module
name.
C
These
are
the
things
that
our
validating
tools
keep
running
up
against,
so
it
actually
pays
well
off,
especially
if
you
develop
things
inside
the
ITF
that
pay
some
attention
to
these
things,
to
make
sure
that
they're
actually
correct,
because
that
helps
you
later
down.
The
line.
Also
kind
of
a
an
outcome
of
the
fact
that
we
have
xml
bindings
is
a
prefix.
C
You
need
a
prefix
and
it
will
also
come
back
when
we
talk
about
imports
and
includes
so
you
have
to
come
up
with
a
prefix
make
it
short
make
it
make,
don't
have
to
make
it
interesting
but
make
it
short
and
make
it.
You
know
reasonably
easy
to
remember
and
very
importantly,
we
have,
or
the
yang
language
and
there's
a
lot
of
nice
things
written
about
this
in
the
indy
RFC.
The
revision
statement
is
on
a
date
format
and
describes,
of
course,
when
this
yang
file
was
published
whatever
that
means
for
us
in
the
ITF.
C
It
means
something
very
specific
for
private
writers
or
for
for
vendors.
It
might
mean
something
else,
but
needs
to
be
in
a
date
format
and
again
it
uniquely
identifies
the
version
of
the
yang.
So
we
don't
have
any
other
types
of
versioning.
It's
actually
the
date
format
here
and,
of
course,
we
realize
or
understand
or
plan
for
the
fact
that
there
will
be
later
manifestations
of
IETF
interfaces
that
will
have
new
revision
statements.
C
So,
let's
start
from
the
top
I
showed
you
if
you
remember
that
there
were
two
top
containers
in
the
ITF
interfaces
yang
module.
This
is
what
the
container
feature
or
the
container
keyword
looks
like.
It
is
doing
one
thing
and
one
thing
only:
it
does
containment
it's
a
way
of
grouping
things
together.
It
ends
up,
of
course,
in
your
tree
path,
but
it
has
no
semantic
value,
except
for
that
defines
an
interior
data
node.
C
C
In
this
case,
we
have
two
lists.
We
have
a
list
of
interfaces
and
I
mentioned.
We
have
a
list
of
interfaces
state,
okay,
so
two
lists
on
the
top
single
argument.
Again,
it's
the
name
of
the
list
represents
a
collection
of
entries.
Each
entry
consists
of
one
or
more
notes,
nothing
strange,
there's.
A
couple
of
things
in
yang
that
might
treat
people
up
a
little
bit
is
that
there
are
two
types
of
lists
or
they
well
well,
there's
two
type
of
lists
for
this
purpose
right.
C
It's
that
and
I
mentioned
this
early
on-
that
we
make
a
streak
difference
between
data
sets
that
are
configurable
and
data
sets
that
are
operational
data,
so
by
using
the
config
falls
constructor
the
config
key
was
a
false
argument,
means
that
all
data
in
the
interfaces
state
is
immutable.
It's
read-only,
okay,
so,
as
I
said,
that
represents
the
state
of
the
interfaces,
nothing
you
can
do
about
that.
C
A
C
True,
wait:
wait,
good
one.
What
just
said
was
that
we
have
two
types
of
lists.
In
this
example,
we
have
a
list
of
things
that
you
can
actually
configure
interfaces.
We
have
a
list
of
things
that
you
can't
configure,
and
even
if-
and
maybe
this
is
where
I
should
update
the
example
there's
a
key
statement
here-
you
can
actually
remove
this.
It's
fine
to
have
config
false
lists,
with
no
keys.
Okay,
a
little
bit
of
nodding.
That's
good.
C
C
It's
a
type
string
when
in
this
case,
then
of
course,
the
leaf
name
serves
as
the
least
key
of
type
string
good
to
have
some
editing
advice
on
the
screen,
and
if
you
look
at
the
model
of
course
again,
we
describe
the
fact
that
interfaces
a
list,
as
num
name,
has
members
identified
by
a
string
called
name
and,
of
course
an
example.
Instance
of
this
would
be
that
you
would
have
interface
list
members
called
ETH,
0,
ETH,
1,
ETH,
ok,.
C
Yang
itself,
the
language
comes
with
a
set
of
building
datatypes,
not
much
new.
Here
we
didn't
invent
much.
Of
course,
we
got
quite
a
bit
of
input
or
feedback
actually
from,
of
course,
from
people
with
a
maybe
background
and,
of
course,
normal
programming
language
at
first,
so
you
won't
be
too
surprised.
We
have
a
binary.
We
have
bits
boolean
decimal
64.
We
have
the
common
aims
on
sign.
We
have
enumerations
I,
will
pick
out
some
of
these
and
actually
get
to
them
later
in
the
in
the
presentation.
C
Union.
Well,
nothing!
Nothing
particularly
strange
here,
depending
on
what
type
of
type
you
have.
There
are
also
qualifiers,
if
you
like,
so
things
like
pattern,
range
and
length
that
you
can
use
to
restrict
the
value
space
for
particular
types.
So
in
this
case
it's
an
example
of
a
string
that
has
the
length
of
for
the
lexical
length
of
four.
C
A
C
So
free
so
so
in
this
case,
what
this
says
is
that
the
value
space
of
the
lexical
space
or
the
length
of
the
string
is
between
zero
to
four
and
that
the
pattern
that
the
actually
instance
data
needs
to
match.
It's
this
pattern.
So
what
this
says
is
that
you
know
you
you
guys
are
probably
familiar
with
red
X,
so
the
members
need
to
be
in
0
to
9
82
F
for
a
to
F
right.
So
it's
it's
a
very
crude
maximum
for
length,
X
representation.
C
Okay,
so
for
this
interface
we
have
a
leaf
called
enabled,
which
of
course
describes
the
configured
or
desired
state
of
this
interface.
Is
it
up
or
down
very
simple,
and
both
boolean
also
allows
you
to
put
a
default
value.
So
default
is,
if
you
don't
do
anything,
and
this
leaf
is
actually
instantiated.
C
So
if
you
create
this
leaf,
but
you
don't
provide
a
value
for
enabled
the
system
will
work
off
of
the
assumption
that
it's
going
to
run
as
true.
So
if
you
create
an
interface,
it
will
come
up.
That's
the
effect
of
this
and,
of
course,
an
example.
Again
this
is
the
model
we've
added
the
boolean
leaf
an
instance
could
be
then
that
well,
all
three
of
these
interfaces
are
up.
Okay,.
C
Next
step,
I
mentioned
that
we
have
a
leaf
called
linked
up
down,
trap
enable
that
controls,
whether
we
send
as
an
MP
traps.
When
something
happens
to
this
interface,
this
is
of
type
enumeration.
You
will
recognize
this
again
from
most
programming
languages
in
the
world.
You
define
it
by
saying
type
enumeration,
and
then
you
enumerate
the
enums
here
we
go
another
question.
I'm.
A
A
C
C
A
The
previous
slide
you
have
enabled
and
enabled
is
actually
configured
enabled
so
I'm
I
can
configure
the
interfaces
enabled
at
least
I
think
so
I'm
and
it
might
not
come
up
because
the
other
side
is
not
up.
The
laser
is
not
on
all
kinds
of
reasons.
This
trap
is
probably
for
the
operational
uptown
versus
the
configure
uptown
man.
C
C
C
Yeah
that
was
so
I've
had
a
twice
now.
Actually,
yes,
I
little,
you
know
no
editorial
things
for
myself.
There's
just
I
should
have
probably
gone
through
that
before
yeah
I
want
it
to
be
flick.
I
want
the
graphic
to
go
on
the
right
on
the
other
other
way
around
I
mean
it's
it's
it's
very
confusing.
Also
to
me
I
should
just
all
directories
go
to
the
right.
Don't
they
yeah.
C
Okay,
defining
new
types,
so
we
have
a
keyword
called
type
def.
Okay,
in
this
case,
we
are
doing
the
the
right
thing,
we're
defining
what
percent
is
we
pick
yun,
siding
z28
and
we
say
it's
a
range
between
0
and
100,
and
we
put
a
very
descriptive
description
in
saying
percentage.
So
by
doing
this
in
scope
of
the
same
yang
model
or
module
namespace,
we
can
now
use
this
as
a
type.
C
So,
if
we
later
or
in
the
same
module,
have
a
leave
code
completed,
we
can
just
freely
use
type
percent,
very
clever,
there's
a
couple
of
things
that
are
not
part
of
the
yang
language
itself,
but
things
that
we
do
well
in
the
ITF,
which
is
types
related
to
networking.
So
we
have
in
RFC
69
91
a
lot
of
common
yang
data
types
both
around
ina,
but
also
extensions
of
yang
that
are
more
generally
applicable
and
I'm.
C
Gonna
say
this
now
and
many
more
times
do
not
invent
your
own
types
before
you
have
at
least
looked
through
69
91
and
a
couple
of
other
places
over
time.
I've
seen
too
many
interpretations
of
MAC
address,
domain
name,
ipv6
address!
We've
done
that
some
of
them
was
horrible,
but
we've
done
them
in
a
way
that
we
think
are
stable
and
useful.
So
look
at
69
91
before
inventing
your
own
type,
def.
C
C
So
in
this
case
the
leaf
that
I
talked
about
with
a
long
strange
name
linked
up
down
trap.
Enable
only
applies
if
your
box
supports
SNMP
right,
but
we
don't
want
different
models,
former
models
for
boxes
that
support
as
an
MP
and
for
boxes
that
don't
support
as
an
MP.
So
we
have
the
feature
statement
in
this
case
feature
if
nib
means
that
here's
an
optional
switch
for
systems
that
support
they've
made
this
leaf
applies,
so
we
have
compared
with
the
feature
we
have
the
if
feature
so
in
this
case,
for
this
leaf.
C
The
if
feature,
if
maybe
means
that,
if
this
box
supports,
if
me
I
of
maebh's,
this
leaf
will
be
visible
for
books.
Is
that
don't
support
I
have
made?
You
won't
even
see
it,
but
your
data
will
be
valid
according
to
the
to
the
to
the
model
without
that
leaf.
Okay.
So
it's
a
powerful
way
of
reducing
friction
among
editors
of
a
particular.
We
can
push
many
of
our
discussions
into
the
feature
space
if
you
like,
and
make
it
optional,
not
a
deviation
or
anything
like
that.
Nothing
negative
just
make
it
a
feature.
A
So
he's
featured
like
hierarchical,
let's
say:
I'm
writing
a
young
model
for
a
new
protocol.
So
where
do
I
start
with,
let's
say
two
separate
functions
in
that
within
the
function,
I
may
have
a
number
of
capabilities.
Yes,
so
how
do
I
organize
that?
How
do
I
for
the
top-level
functions?
Should
I
say
these
are
the
couple
l
features
now
within
the
subset
of
the
individual
features
within
that
function?
Can
I
link
them?
In
other
words,
is
there
like
hierarchy
there.
C
A
B
C
C
C
C
There
are
many
occasions
where
we
end
up
having
to
enumerate
something
that
we
know
will
be
heavily
extended
over
time
and
since
we
want
yang
modules
to
be
fairly
stable,
ie
don't
change
too
often
in
terms
of
a
client
developer.
Let's
say
we
can't
really
use.
We
can't
really
easily
extend
enums
that
will
change
the
value
space
too
much
for
the
client
developer.
So
we
have
something
called
identities.
C
Identities
in
my
mind,
of
the
way
I
usually
use
them
is
as
an
extensible
enum.
So
a
good
example
of
this
is
what
I'm
showing
here.
As
you
guys
may
know,
Ayane
keeps
track
of
all
interface
types
or
at
least
all
registered
interface
types.
It's
a
list
of
types
that
changes
at
you
know
at
all
times.
It's
a
ever-expanding
amount
of
strange
types
of
interfaces
that
we
invent
and
use
in
the
industry.
So,
of
course,
we
would
never
submit
a
yang
file
that
actually
tries
to
capture
everything
that
will
ever
be
defined.
C
Reference
identities
so
by
including
and
we'll
get
to
the
actual
imaginations
of
inclusion,
or
how
do
you
include
things
and
import
things
you
make
a
list
of
interface
types
available
and
therefore
the
type
leave
here
can
then
reference
those
identities,
okay-
and
this
allows
us
to
actually
expand
these
identities
without
upsetting
the
client
developer.
So
it's
not
actually
changing
the
structure,
but
it's
changing
the
set
of
identities
over
time.
So
of
course,
again
interface
type
in
our
interface
example.
C
So,
let's
take
the
leap:
here's
what
we've
done
this
for!
We
have
our
little
network.
Here
we
have
a
management
station
up
top.
We
have
two
routers,
they
have
eath
zero
interfaces,
both
of
them
and
we
want
to
assign
them
eventually
ipv6
addresses,
but
our
first
task
was
to
walk
through
the
interface
model
enough
that
we
could
actually
bring
up
the
interface.
So
the
configuration
and
the
examples
that
we
have
here
is
actually
the
XML
instance
data
that
you
would
typically
see
a
net
conf.
C
This
is,
then,
what
you
would
send
you
would
send
interfaces
interface
and
you
would
provide
a
name
because
it's
a
key,
so
it's
mandatory
and
you
would
set
the
enable
leaf
to
true
you
would
send
that
off
to
the
routers
and
if
they
have
interpreted
the
yang
correctly,
which
they
have
in
this
case
they
would
bring
up
the
interfaces
any
kind
of
catch
up
questions
this
far
before
we
head
into
the
operational
state
of
things,
okay,
good,
so
we're
gonna
focus
on
the.
If
you
remember
the
right
side
of
things
are
a
little
bit.
C
This
is
the
read-only
side
that
interfaces
state
so
in
the
read-only
space
there's
a
couple
of
things
that
are
that
are
interesting.
As
I
mentioned.
Each
entry
in
the
interfaces
state
list
represents
the
state
of
an
interface
which
is
sounds
easier
than
it
is.
It
represents
the
state
of
an
interface
that
is
actually
available
to
the
system
right,
whether
it
has
configuration
or
no
it's
something
that
the
system
knows
about.
C
C
In
this
case,
actually
the
interfaces
state
tree
is
optional,
so
you
don't
have
to
implement
the
interface
of
state
tree,
but
I
think
most
people
would
be
very
surprised
if
they
found
a
device
that
doesn't
want
to
talk
about
the
interface
state,
but
I
think.
Yes,
it's
actually
optional.
You
you
may
have
you
know
your
system
might
be
in
a
state
where
it
where
you
don't
have
any
interfaces,
so
the
list
will
be
empty.
Okay,.
C
Okay,
so
yang
a
core
concept
is
modules
right.
So
in
this
case,
where
we
are
now,
we
actually
need
a
couple
of
types
from
the
yang
types
module.
So
we
go
ahead
and
use
this
keyword.
We
use
the
import
keyword
and
then
we
use
the
module
identifier,
and
this
again
is
the
unique
way
of
identifying
what
you're
looking
for
and
it's
the
module
name
right.
C
You
can
also
import
by
a
revision,
and
in
that
case
you
would
actually
say
using
the
revision
statement,
what
revision
you're
looking
for,
but
your
tools
would
then
go
look
for
in
some
sort
of
catalogue.
Maybe
the
file
system,
maybe
some
other
means
of
a
module
with
that
name
and
import,
makes
the
data
definition.
So
basically,
the
data
tree
that
you
have
in
that
module
available
to
your
local
module.
C
So,
typically,
if
again,
if
you
want
any,
if
you
need
some
types
or
some
groupings
and
we'll
get
to
that,
this
is
the
exact
statement
that
you
would
use
all
right
and
you
also
provide
a
prefix
keyword,
because
when
you
then
use
the
types
from
this
imported
module,
you
need
to
prefix
them
and
I'll
show
you
an
example,
because
you
want
to
make
sure
that
you
may
have
types
in
your
local
module
that
has
the
same
name
as
the
newly
important
ones.
So
we
use
the
namespace
prefix
to
discriminate
between
the
two
there's.
C
Also,
the
include
statement,
not
part
of
the
example,
but
none
less
important.
It
used
to
make
content
from
a
sub
module
and
a
sub
module
is
actually
a
yang
module
that
you
declare
not
to
be
a
module
but
a
sub
module.
So
it's
a
specific
type
of
module
called
sub
module
that
belongs
to
a
specific
module.
It's
more
in
my
mind,
a
way
of
breaking
up
very
large
yang
modules
into
perhaps
smaller.
It's
it's
more.
It's
more
likely
actually
include
statement
in
see.
C
For
example,
it's
a
way
of
just
breaking
out
a
lot
of
information
or
a
lot
of
text
into
other
other
other
files,
because
you
can't
really
export
or
that's
not
a
way
of
importing
things.
It's
just
by
sucking
that
data
in
so
it's
not
it's
not
something
you
would
use
to,
for
example,
get
a
hold
of
certain
types.
It's
just
a
way
of
breaking
your
module
into
many
smaller
parts.
C
Here's
the
example
import
that
we
use
okay,
we
import
ITF
yang
types,
here's
this
snippet
from
ITF
yang
types
that
we're
going
to
use
because
we
need
date
and
time
for
the
last
change
leaf.
That
was
in
the
interfaces
state
list.
As
you
all
remember,
we
have
a
type
def.
We
looked
at
that
before
in
the
ITF
yang
types
module
with
a
nice
reg
X
for
ISO
date,
I
think
it's
date
and
yeah
date
and
time
style
data.
C
C
So
more
specifically,
it
looks
like
this
our
instance
data
or
the
model
is
here
right.
The
instance
data
is
eth0
has
a
particular
date
time.
Eth
one
has
one
more
clerical
error
here.
This
is
what
the
conformant
value
then
to
the
regex
here
looks
like
so
that's
a
derived
type
that
we
have
important
okay,
so
it's
not
a
base
type
yep
I
did
I
know
that's
why
this
is
not
marked
up.
C
Okay,
so
I
mentioned
also
that
we
have
foreign
keys,
they're
called
leaf
rafts,
so
it's
a
way
of
referencing
another
leaf,
okay
and
what
it
actually
means.
It's
referencing,
another
leaf
instance
right,
so
we
use
leaf
ref
to
do
that
and
in
our
model
here,
I
mentioned
that
we
want
to
support
stacked
interfaces,
interfaces
that
sit
on
other
interfaces
and
in
this
case
we
wanted
as
mother
error
VLANs.
No,
it
actually
correct
on
the
right
side
down
there.
C
In
the
instance
data
you
see
that
an
interface
called
VLAN
zero
actually
have
a
higher
layer,
interface
entry
called
eth0,
and
if
we
look
in
the
yang
model,
you
can
see
that
the
type
def
for
the
interface
state
ref
is
of
type
leaf.
Ref,
okay
and
the
cool
part
here,
where
a
lot
of
interesting
things
can
happen,
is
in
the
path
statement.
C
C
C
C
So,
okay,
so
let's
hit
task
two
now
we
know
enough
that
we
can
actually
assign
an
ipv6
address
to
the
interface.
The
interfaces
module
that
we
looked
at
this
for
didn't
actually
go
so
far
as
to
layer
three,
so
it
didn't
actually
define
the
data
set
needed
for
ipv4
or
ipv6
addresses.
For
this
we
need
ITF
IP
dot
yang
and
in
this
IFI
P
dot
yang,
we
will
have
a
new
set
of
model.
We
will
look
at
the
ipv6
side
of
things
all
ipv6
per
interface.
C
Ipv6
configuration
will
consist
of
a
boolean
leaf
to
say,
is
ipv6
enabled
on
this
interface,
and
it
will
have
a
list
of
ipv6
addresses
and
prefix
length
combinations.
Okay,
you
will
recognize
this
from
typing
things
into
the
CLI
and
what
we're
gonna
use
is
a
very
powerful
feature
called
augment
or
powerful
keyword
called
augment.
Augment
is
a
way
for
a
module
to
if
you
like,
mount
itself
into
another
module
so
bear
with
me.
What
we
do
here
is
that
we
import
from
ITF
IP
dot
yang.
We
import
ITF
interfaces
with
our
prefix.
C
If
okay,
so
now,
we
have
the
data
nodes
from
interfaces
available
and
then
we
say
using
the
magical,
incantation
augment
and
a
path
under
interfaces
interface,
so
we're
in
the
readwrite
section
of
the
interfaces
module
augment
this
and
we
provide
a
container
called
ipv6
okay.
So
by
doing
this
we
have
suddenly
kind
of
mounted
ourselves
into
the
ITF
interfaces,
data
set
and
added
a
container
ipv6
okay.
C
So
this
provides
the
groundwork
for
the
actual
configurable
through
with
ipv6,
and
this
allows
the
ITF
and
other
SDO
is
to
write
the
the
let's
say,
the
backbones
of
what
they
do
first
and
then
have
teams
in
our
case
working
groups
augment
themselves
into
this.
That's
the
machination
s--
then
starts
the
actual
work.
So
there's
a
lot
of
work
going
on
in
many
working
groups
about
how
do
we
all
meant
ourselves
efficiently
and
organize
ourselves
efficiently
around
each
other's
modules?
C
Okay,
but
it's
a
very,
very
powerful
concept
and
the
ipv6
model-
and
this
is
a
yeah.
This
is
the
demo
version.
As
I
mentioned,
we
have
a
leaf
called
enabled
it's
a
type
boolean
you've
seen
that
before
default.
True,
we
have
a
list
of
addresses.
The
key
to
the
address
is
the
actual
IP
address
and
we
reuse
the
ITF
definition
of
an
ipv6
address,
with
no
zone
to
it,
because
we
use
the
prefix
length,
which
is
of
type
on
sign
into
your
eight
with
a
particular
range.
C
Here's
another
actual
keyword
that
I
haven't
mentioned
before
mandatory.
True,
of
course,
all
keys
are
mandatory.
You
can
create
a
list
entry
without
having
a
key,
but
this
also
says
that
we
won't
allow
you
to
create
an
entry
in
the
address
list
without
the
prefix
length.
So
it's
not
a
key,
but
it's
mandatory
so
trying
to
create
it
without
a
prefix
length
will
be
an
error.
C
So
here's
the
instance
data
in
XML,
so
we
now
have
two
routers,
so
we
have
interfaces
interface
and
we
identify
the
name
eth0
it's
under
a
PVC
ipv6,
where
there's
actually
new.
So
we
need
this
interface
to
be
enabled
we've
added
a
made-up
address
and
we
have
a
prefix
length
and
you
would
not
be
surprised
to
see
that
it
looks
exactly
the
same
towards
router
2.
Oh.
A
C
A
That
these
comparisons,
like
for
keys
and
also
for
its
path,
expression,
evaluation,
you
need
to
use
the
canonical
form
form
for
comparing
it.
So
in
the
same
way,
at
RFC
69
91
over
the
number,
we
have
a
canonical
form
undefined
for
ipv6
addresses,
which
is
what
you
would
expect.
It
means
no
leading
zeros
and
so
on.
So
this
is
what
you
need:
tools
for
comparing
keys
and
so
on.
So
in
this
case
this
will
be
the
same
key,
so
an
error
so.
A
C
Exciting
here
now,
of
course,
the
subtle
message
in
this
slide
is
that
it
would
be
cool
if
router
one
was
from
vendor
a
and
router
two
was
from
vendor
B
right
and
you
send
the
same
payload
see
now
we're
thinking.
That
is
what
we're
trying
to
do
here,
of
course,
by
providing
because
again,
all
the
examples
I
have
here
is
from
ITF
submitted
yang
modules,
that
we
dearly
hope
that
vendors
and
service
writers
will
pick
up
on
because
they
don't
discriminate.
C
A
Question
would
be
what
would
be
the
expected
behavior
if
I
configure
an
ipv6
address
with
a
different
prefix
length
if
there
is
a
pre-existing
ipv6
address,
but
with
a
different
way,
with
a
slash,
128
and
I
wanted
/
126
is
the
expected
thing
that
to
tell
me
that
the
key
already
exists,
or
is
it
overwritten?
If.
C
So
back
to
I'll
start
off
the
lexical
value
here
will
then
be
canonicalized
and
compared
with
the
incoming
or
colliding
or
potentially
colliding
engine
right
and
if
they
match
it's,
a
no
okay.
So
it's
a
good
question
actually,
because
there's
another
concept
in
yang
called
unique
it
there's.
There
are
ways
to
describe
to
say
that
look.
The
IP
address
is
key,
but
the
combination
of
IP
and
prefix
length
needs
to
be
unique.
We
don't
have
that
here.
So
it
means
that
this
is
the
only
thing
we're
looking
at.
C
C
C
C
A
If
I
were
to
say
and
I
don't
know,
v6
I'll
say
I
didn't
before
10.1.1.1
slash,
28,
that's
broken
because
the
dot
one
is
not
a
valid
siphoning
right.
Is
there
a
way
to
say
you
can't
do
that
or
is
that
up
to
the
back-end
system
to
say
I'm
trying
to
configure
this?
It
didn't
make
sense.
King
can
I
in
yang.
You
know
in
my
data
model,
say
that's
a
meaningless
thing.
No.
C
C
C
A
brief
walkthrough:
this
is
an
interesting
RFC
or
an
interesting,
interesting
draft,
an
interesting
yang
module.
It
is
challengingly
large
and
it's
very
ambitious.
We're
gonna
look
at
a
very
small
subtree.
So
when
I
start
at
the
top
look
at
MPLS,
we
care
for
Ellis
piece,
we're
gonna
care
for
static
LSPs.
Only
I'm,
gonna,
look
at
the
label
switched
paths.
Part
of
this,
but
you'll
recognize
now
that
we
have
a
container
on
the
top.
We
have
a
container
in
the
container,
then.
C
Actually
we
have
a
companion
in
the
container
in
the
container
here
called
static,
Ellis
piece
and
this
uses.
Then
the
keyword
that
I
mentioned
before
it
use
no
I
actually
haven't
sorry.
It
uses
the
useless
statement
that
we'll
get
to
that
on
the
next
slide,
but
now
you
have
a
feel
for
or
going
to
do
so
inside
of
MPLS
at
his
peace
start
to
get
his
piece.
You
have
label
switched
paths,
a
name
in
ingress
and
egress.
They
all
have
next
stop
incoming
label
or
push
label.
Ok,
that's
the
content
of
the
model
that.
C
Leads
us
to
groupings
so
groupings
or
ways
of
assembling
data
nodes
into
named
sets
that
you
can
reuse.
So
we
talked
a
little
bit
about
reuse
before
in
terms
of
type
deaths,
but
they
are
type
reusable
types.
These
are
reusable
data
sets
or
data
node
sets
right.
So
the
way
you
declare
a
groupings
or
the
key
word
you
use
is
grouping
and
it's
got
a
name
in
this
case.
This
grouping
consists
of
a
list
called
label
switched
paths,
and
you
have
yes,
you've
already
seen.
C
That
is
that
both
the
ingress
and
egress
will
use
the
same
data
structure,
so
it's
appropriate
to
declare
a
grouping
and
then
reuse
them
in
this
list.
We
are
a
key
name
leaf
named
container
ingress.
Just
make
it
more
interesting.
This
grouping
actually
uses
other
groupings.
This
is
where
you
start
keeping
context
in
your
head,
and
this
grouping
uses
a
grouping
called
static,
LSP
common
well,
at
a
first
glance.
At
least
this
grouping
doesn't
have
additional
groupings
or
use
of
statements
right.
So
this
is
the
bottom.
C
This
is
the
the
Leafs
next
up
incoming
label
and
push
label
and
by
using
the
container
on
the
left
side
with,
then
they
both
use
the
static
LSP
common.
We
declare
this
thing
right,
and
the
cool
thing
here,
of
course,
is
that
if
you
choose,
if
you
choose
to
change
something
in
the
grouping,
you
don't
have
to
repeat
yourself,
because
it
it
uses
them.
But
you
also
have
to
be
very
short
or
not
very
sure,
but
I
reasonably
sure
that
the
places
where
you
use
the
grouping
will
always
be
kind
of
the
same.
C
A
C
C
A
C
But
and
I
need
some
of
the
the
more
seasoned
people
to
maybe
add
color
to
this.
We
really
wanted
that
to
be
very
hard
and
actually
associated
with
a
little
bit
of
shame,
because
we
do
want
the
ITF
to
write
the
minimal
set
the
useful
set.
You
know
anything
less
than
that
would
be
bad,
but
there
is
a
key
word
that
I,
don't
even
going
to
mention
here,
but
I'll.
Do
it
now
verbally
and
we'll
edit
that
out
called
deviation.
C
That's
where
you're
secretly
omit
not
so
secretly,
where
you
declaratively
admit
that
these
are
the
parts
of
the
model
that
I
don't
implement.
We
wanted
that
to
be
something
you
could
explicitly
call
out.
So
the
the
consumer
can
see
that
this
is
you
can't
just
sneak
it
out
of
there
out
of
the
picture
good
question,
any
other
concluding
yang
questions,
greedy,
there's,
always
one
more
question
that
guy.
C
A
You
reference
a
state
like
enabled
or
active,
or
something
like
that,
how
which
is
state,
but
not
the
way
to
put
the
system
into
this
state
right,
meaning
that
if
I
have
a
sequence
of
operations
which
are
all
things
into
Boonton
XML?
How
do
I
describe
that?
They
are
dependent
on
one
another,
and
this
should
be
all
rolled
back.
C
Yeah
so
now
we're
getting
into
the
philosophical
domain,
but
it's
really
important
also
when
you
design
your
yang.
So
this
there's
there's
a
there's
like
a
meta
model.
Yang
and
the
meta
model
says
that
your
configuration
can
at
any
time
be
presented
as
a
set
of
instance
data.
So
the
yang
language
doesn't
allow
you
to
describe
ordering
in
general.
C
It
describes
a
schema
on
which
you
can
operate
now,
if
you
think
about
leaf
revs,
there's
actually
little
bit
of
ordering
in
there.
You
have
to
create,
for
example,
the
target
of
a
leaf
Rev
before
you
can
actually
reference
it.
So
there's
a
little
bit,
but
it's
still
in
the
declarative
domain,
not
in
the
procedural
domain.