►
From YouTube: IETF93-NETMOD-20150720-1850
Description
NETMOD meeting session at IETF93
2015/07/20 1850
A
Read
the
note:
well,
please
observe
it
live
it
love
it
all.
The
conversations
and
transactions
in
the
meeting
apply
to
know
it.
Well,
so
here's
our
agenda
for
today
like
to
start
with
agenda
bashing.
If
anybody
has
any
comments,
complaints,
suggestions
about
the
agenda,
please
jump
in
we've
got
a
pretty
tight
schedule.
Today,
we've
got
just
an
hour,
so
we're
gonna
really
get
get
down
to
it.
B
B
Had
we've
had
two
revisions
of
of
that
internet
draft,
and
now
we
are
at
number
19,
and
so
in
those
two
revisions
that
have
been
quite
a
number
of
changes,
maybe
the
most
important
one
was
that
the
container
or
for
Apes
and
trips
in
general
were
moved
under
routing
instance.
That
means
that
every
ape
is
sort
of
private
to
a
single
routing
instance,
because
there
are
no
use
cases
for
sharing
rips
between
routing
distances,
and
this
makes
some
changes
possible
that
actually
simplify
the
data
model.
B
So
the
default
trip
for
each
routing
instance
is
now
marked
with
us
simple
flag
without
any
further
complications,
and
this
is
done
in
both
configuration
and
state
data
and
second
change
implied
by
that
was
that
references
to
rips,
which
were
represented
by
typedef
three
breath
and
rip
state
ref
very
moved,
because
now,
as
as
soon
as
rips
are
private
to
each
routing
instance,
references
to
them
make
sense
only
within
that
routing
instance.
That
means
they
should
be.
B
They
should
be
relative
references,
not
absolute
references
as
these
two
typedefs
expected,
then
another
simplification
was
that
configuration
of
connections
between
a
protocol
and
rape
and
between
two
different
trips
very
moved.
It's
expected
that
this
issue
will
be
dealt
with
in
in
routing
protocols,
and
so
this
rain
made
that
was
in
the
previous
revision
may
not
be
the
way
that
will
be
found
most
appropriate.
B
So
it's
now
open
out
to
deal
with
with
rare
routes
get
installed
in
which
rape
then
another
change
was
that
configuration
and
stay
data
for
ipv6
routing
advertisements
were
moved
under
the
so
inside
the
hierarchy
of
the
interfaces.
Itf
interfaces
yang
module,
so
it's
now
done
via
by
an
augment
from
from
the
ITF
routing
module
and
then
other
changes
very
lighted
to
the
assignment
of
interfaces
to
routing
instances.
So
now
the
assignment
of
interface
within
a
routing
instance
uses
only
a
leaf
list,
so
it
means
a
leaf
list
containing
all
interfaces
belonging
to
that
route.
B
Routing
instance,
which
means
all
other
configuration
has
to
go
to
the
interface
configuration
and
the
opposite.
Reference,
which
is
only
in
stay
data,
is
now
only
a
single
leaf.
Instead
of
a
leafless
that
was
there
before,
and
this
is
done
because
an
interface
can
in
fact
viola
in
no
more
than
one
routing
instance,
so
leaf
is
sufficient
for
this
purpose
next
slide
and
then
to
two
other
leaves
very
move
from
a
routing
protocol
on
on
request
of
people
developing
routing
protocols.
B
When
I
requested
actually
to
compile
the
list
of
modules
that
use
the
IDF
routing
module,
so
I
try
to
do
it
as
it
turns
out
it's
not
complete,
because
at
least
one
of
the
tunnel
beta
models,
I
briefed
uses
this
IDF
routing
module,
although
in
a
very
marginal
way.
So
here,
I
I
at
least
found
these
nine
draft
that
that
use
that
refer
to
the
IDF
routing
or
mostly
augmented,
those
that
are
marked
with
an
asterisk.
They
use
it
in
also.
You
know
in
a
limited
way.
B
B
In
my
view,
there
are
two
issues
that
need
to
be
discussed
and
resolved,
and
perhaps
the
most
important
one
is
to
decide
about
some
wrote
my
roadmap
for
this
document
and
the
other
one
is
about
the
assignment
of
interfaces
to
routing
instances.
I
will
cover
it
in
the
next
two
slides.
So
next
slide,
please
about
the
roadmap.
B
Of
course,
this
work
on
this
document
started
maybe
five
years
ago
now,
and
it's
like
a
never
ending
story
and
I
faint
in
a
way
it
would
be
useful
to
to
finish
and
stabilize
it
and
publish
it
eventually,
because
you
know
what
happens.
Is
that
people
those
users
of
this
module
they
they
use
some
version
of
it,
and
if
we
publish
you
a
new
revision
of
that
beta
model,
it
can
change
something,
so
they
get
out
of
out-of-sync
of
the
users
and
so
sometimes
the
modules
real.
It
don't
work.
B
C
I
I
would
agree
with
this.
I
think
you
know,
despite
you
know,
that
I
presented
this
morning,
the
intermediate
up,
your
initial
output
of
the
yang
routing
working
group,
I,
think
we're
a
long
ways
from
you
know
compared
to
the
maturity
this
from
getting
a
you
know,
getting
that
exactly
agreed
on
pot
and
gaining
consensus
and
I
know
I
thought
even
to
make
the
mechanism
that
a
lot
of
the
rude
mechanism
that
just
was
introduced.
C
D
Benoit
so,
but
not
less
so
I
agree,
it
should
be
published
now
the
yang
models
should
be
used
right.
This
is
one
of
the
key
one,
so
it's
perfectly
fine
to
have
a
blast
holes
with
ITF
last
call
and
I'm
proposing
to
just
hold
it
until
we've
got
a
couple
of
consumers.
Of
this
we've
seen
nine
who's
been
will
be
telling.
This
is
perfect.
We
don't
have
to
change
anything.
What
would
be
pretty
bad
is
to
say
we
publish
it
and
then
one
of
those
nine
consumers
did
they
find
a
flaw.
D
B
I
agree
with
this,
and
this
is
actually
by
second
bullet
that
it's
it's
really.
The
rules
for
updating
the
egg
mode
use
are
quite
rigid,
so
really
publishing.
It's
an
RFC
runs
into
the
risk
of
really
not
being
able
to
to
make
some
changes
that
turn
out
to
be
necessary,
unless,
of
course,
we
change
them
module
name
and
the
name
space
and
everything
which
witch
is
which
would
be
stupid.
C
Yeah,
a
sea
I,
don't
know
if
people
are
consumers
are
going
to
say.
It's
perfect,
I
think
it's
perfect
from
what
it
does.
There
are
augmentations
we
know
are
needed,
but
but
we,
you
know,
we
said
okay.
This
is
what
it
is
right
now,
like
the
what
the
one
in
particular
that
if
you
were
gonna,
if
you
were
going
to
hold
it
for
anything,
it
would
be
to
do
more
complicated
next
hops.
In
other
words
right
now,
the
document
doesn't
support
ecmp
and
we
know
we're
gonna
need
that
it
doesn't
support
rehearse
recursive
next
hops.
E
Dambach
damage,
but
in
this
case,
if
you
would
never
published
because
if
you
will
wait,
you
know
for
all
those
others,
you're
never
publishing
the
document,
so
you
are
ending
up
in
the
state
of
a
virtual
draft
forever.
So
at
one
point
we
have
to
make
a
you
know
saying:
okay,
this
is
it.
We
should
publish
this
and
this
this
working
document,
because
many
people
are
not
implemented
until
becomes
an
RFC.
B
A
The
other
yeah,
the
problem
that
they
were
all
discussing
here,
we've
been
talking
about
for
the
last
couple
of
meetings.
I
mean
this
is
a
potentially
big
issue,
the
more
and
more
models
we
have,
the
bigger
kind
of
like
dependency
matrix,
we're
building
you
know.
Maybe
we
should
think
a
little
carefully
about
how
we
do
this,
because
if
you
know
stuff,
that's
further
up
in
the
dependence
rate,
dependency
tree
changes
everything
underneath
it's
going
to
get
changed
after
right.
So
maybe
we
need
to
think
about
a
different
plan.
A
B
E
Then
this
is
one
of
the
key
modules
because
routing
configuration
there
are
so
many
they're
building.
On
top
of
that,
so
the
sooner
we
can
publish
because
I'm
seeing
many
people
developing
and
unless
there
is
this
stable
one,
you
know
for
the
routing
config,
all
the
high
level
ones
will
be
also
in
flux.
A
B
Ok,
so
next
slide
piece-
and
this
is
about
the
assignment
of
interfaces
to
out
the
instances.
There
is
no
problem
in
state
data,
so
it's
it's
generally
agreed
upon
and
it's
really
useful
to
have
links
from
both
routing
instances
to
in
two
interfaces
that
belong
to
the
routing
instance
and
also
in
the
opposite
direction.
As
is
this
indicated
here,
but
yeah,
there
is
some
problem,
its
section,
my
last
flight,
actually,
no,
no
just
previous
flight
piece
I
still
have
to
continue.
So
that
is
we
deal
with
AC.
B
We
don't
agree
on
the
solution
for
configuration,
so
currently
it
is
done
in
within
each
routing
instance
that
we
have
now
a
leaf
list
of
all
interfaces.
All
net
network
layer
interfaces
belong,
it
belong
into
it.
There
are
some
advantages
of
this
solution
so,
first
days
no
augment
is
needed,
so
it's
just
defined
in
the
data
that
are
native
to
the
ITF
routing
mode
you
and
then
for
routing
instance.
B
It's
much
easier
to
refer
to
its
own
interfaces,
which
is
the
way
a
routing
instance
is
supposed
to
do
in
many
places
and
by
the
way
di
to
RS
rape
data
model.
Also
as
the
same
organization,
but
next
slide
piece,
there
are
some
alternatives
that
have
been
proposed,
and
maybe
a
second
comment
on
this.
But
the
idea
is
to
do
it
the
other
way
around,
so
to
define
for
each
interface
or
even
for
each
ipv4
or
ipv6
configuration
to
define
the
routing
instance.
B
The
interface
belongs
to
the
advantage
is
that
IP
address
configuration
is
co-located
with
routing
instance
assignment
and
I
want
to
mention
that
alternative
B
is
would
be
even
more
difficult
because
that
implies
especially
that
layer
3
configuration
for
ipv4
or
ipv6
makes
two
different,
two
different
interfaces,
but
it's
not
how
it
is
done
in
the
ITF
interfaces
module.
So,
for
example,
we
won't
be
able
to
use
this
backward
reference
from
routing
instance
to
interface,
because
for
ipv4
and
ipv6
it
can
be
your
one
minute,
different
I
think
I
done
so
I
don't
know.
C
Don't
see
this
is
a
show
stopper,
but
I
think
if
we
could,
if
we
could
agree
that
we
don't
need
odd,
ipv4
and
ipv6
to
correspond
to
different
routing
instances.
That
would
be
a
nice
simplification
with
either
alternative
I
mean
the
one
thing
that
I
thought
in
a
couple.
Other
people
thought
was
the
best
alternative
was
to
move
all
the
stuff
from
RFC
7277
into
the
routing
instance.
B
G
First
of
all,
thank
you
all
the
reviewers
who
provided
the
in-depth
comment
to
come
up
with
this
new
draft
okay.
So
there
are
some
important
changes
in
the
model
of
first
one
is
a
model,
is
now
more
clear
because
leaves
name
in
container
names.
How
we
have
been
shortened
and
description
has
been
improved,
based
on
the
comments
so
that
clarifies
the
model,
then
again
the
placement
of
the
containers
they're
having
some
structure
changes
in
the
model
which
allows
new
augmentation
more
clearly
or
easily.
G
H
G
The
destination
address,
so
we
have
followed
a
Yank
patterns
which,
for
the
distillation
address,
which
allows
address
and
port
consideration
under
either
tcp
or
UDP
protocol,
so
we
have
made
changed
there
again
like
number
two.
The
new
placement
of
containers
allows
easier,
augmentation
and
they're
having
some
bug
fixes
like
working
group,
chair
name
and
some
reference
to
RFC
slide,
please,
okay,
so
the
new
model
and
dips
have
been
committed
to
yang
model
a
git
repository.
G
Okay,
now
changes
are
in
detail.
There
are
lots
of
changes
about
23
changes,
so
I'll
not
be
able
to
go
to
all
the
changes,
but
I'll
highlight
some
important
changes.
So
on
number
one
we
have
fixed
trouble
like
type
is
like
working
with
chair
name
and
both
the
IETF
says:
log
files
as
ITF
syslog,
typeset,
IDF,
syslog
model
and
number
to
a
global
logging.
G
Excel
has
been
removed
and
if
it
is
needed
by
a
specific
implementation,
we
will
augment
that
number
three
buffer
log
in
Excel
was
not
a
list
earlier
and
based
on
the
review
comments,
we
have
created
a
list
based
on
the
book,
her
name's.
So
now
you
can
have
multiple
buffers
in
syslog,
then
some
more
important
changes
like
number
seven
were
flame
has
been
removed
currently
and
because
the
worst
story,
whatever
it
is,
is
not
completed
so
it'll
be
eight.
It
can
be
added
back
above
I
augmentation.
If
needed,
then
we
have
followed
new
young
pattern.
G
Draft
number,
eight
number
nine
ten
be
removed,
some
defaults,
there's
not
the
review,
comment
comments
and
then
again,
number
12
I
talked
about
the
change
using
the
names
and
placing
a
new
container.
So
this
creates
sorter
names
because
we
placed
a
log,
it
son
container
and
then
all
the
other
logs
and
seven
all
certain
sort
of
names
like
buffer
file
or
something.
So
we
don't
need
to
have
a
long
container
names
next
slide.
Please.
G
Then
okay
line,
number
22
and
23
we
have
now.
We
now
support
a
time
and
size
based
limit
for
file
archive.
Of
course,
these
are
based
on
it
features
again
for
the
buffer
logging
season.
We
have
a
buffer
size
for
buffer
size
and
number
of
buffer
which
can
be
logged.
So
these
are
the
summary
of
changes
slides
available,
I
guess
so.
Please
take
a
look
and
provide
further
review
comments
next
time,
so
yeah,
please
provide
a
further
reviews
and
if
not,
we
can
have
a
last
call
for
the
syslog
draft.
G
G
E
E
Am
presenting
on
behalf
of
you
know,
of
a
bigger
design
team
if
you
can
just
go
please
to
the
next
slide,
so
on
changes
since
the
last,
there
are
two
open
issues
that
are
left
it.
I
will
ask
the
working
group
to
discuss.
You
mean
time.
There
was
some
more
comments
made
on
the
mailing
list
yesterday,
which
happened
in
the
after
I
submitted
the
you
know
the
deck
to
the
chairs
bunch
of
stuff
the
changes
between
02
and
03.
E
E
We
have
added
some.
You
know
better
descriptions
into
the
model
which
now
explains
the
the
model,
more
better,
fixed,
a
few
issues
that
were
either
in
the
model
or
in
the
examples
and
at
we
did
some
references
to
the
gnu/linux
NF
tables,
and
that
was
expanded
with
some
more
description
and
an
example.
Next
slide.
Please
so
here's
the
open
issue,
which
Lada
and
yuengling
blood
you
know
brought
up.
It
was
a
presence
versus
non-presence
container
in
a
port
range
definition
it.
What
we
did
originally
was.
E
We
were
using
something
similar
to
the
container
source
port
range,
but
we
were
always
making
a
mandatory.
The
lower
port
and
Lada
said
to
fix
that
with
the
presence
container
and
then
the
mandatory
true
can
stay
in
the
leaf.
Lower
port
and
young
suggested
removed
the
mandatory
true
from
the
lower
port-
and
just
you
know,
leave
it
like
that.
So
the
question
is
from
the
working
group.
Is
there
any
preferences?
A
E
E
E
And
then
the
oh
I
forgot
to
change
the
soap
initial
number,
two
okay.
So
then
there
is
the
generic
aqua
container
versus
the
aqua
container
per
address-family.
We
from
the
design
team
prefer
to
do
an
access
in
a
generic
access
list
container.
That
would
be
then
defined
afterwards.
You
know
by
the
AC
e-type.
E
Would
it
be
an
IP
or
an
ethernet,
and
then
would
it
be
a
v6
or
a
v4
versus
of
Jason
suggested
that
we
should
have
a
particular
container
per
address
family
now
this
one
one
versus
the
other,
is
that
in
this
case
it's
we
can
extend
this
and
create.
If
there's
some
new
type
being
created,
we
can
easily
add
new
exodus,
containers
and
sorry.
I
Jason
here
I
know
we
don't
have
a
lot
of
time
in
the
session,
so
I
guess
just
a
top-level
messages.
I
just.
I
think
we
need
a
little
bit,
probably
more
just
robust
discussion
on
the
mailing
list
about
a
couple
of
issues
for
this
one.
So
I
brought
him
up,
I
apologize
it
and
get
those
comments
earlier.
So
we
can
take
it
to
the
mailing
list.
I
just
want
to
clarify
this
a
little
bit.
I
The
one
on
the
right
is
exactly
how
I
proposes,
although
its
kind,
the
idea
I
was
I,
was
proposing
that
that
at
least
the
type
is
a
mandatory
parameter
and
could
be
part
of
the
key,
and
we
can
have
types
that
are
identity.
So
it's
extendable,
I,
wasn't
necessarily
proposing
a
separate
contain
for
container
for
each
list
type,
but
it
that's
kind
of
the
same
idea,
but
I
think
this
is
kind
of
a
discussion
we
should
have
in
a
more
robust
fashion
on
the
mailing
list.
Probably
we
so
we
can
discuss
afterwards
offline
and.
E
I
E
E
J
Hi
I'm
assume
from
cisco
systems
I'm
going
to
talk
about
updates
on
gives
her
yang
murder
next
I
be
so
I'm
going
to
talk
about
the
following
topics:
I'm
going
to
talk
about
the
status
of
the
draft
changes
since
the
last
revision,
open
issues
we
are
running
into
and
some
of
the
suggestion
we
have
got
from
iit
of
community
and
then
I
would
like
to
seek
your
comments
on
there.
Thank
you
next
slide.
J
Next
hi,
so
so
currently,
we
are
running
in
a
bi-weekly
meeting
to
bring
closer
on
the
open
issues
we
so
far
have
been
able
to
establish
the
framework
for
Policy
classifier
action
target
modules
based
on
a
discussion.
So
far
we
have
been
able
to
publish
version
3
of
the
draft
next
slide,
please
so
in
the
current
was
on
a
draft.
Basically,
what
we
have
done
is
that
we
have
correctly
lot
of
template
issues
and
so
that
you
know
we
are
compliant
with
that
of
six
to
eight
seven
suggestions.
J
So
currently,
our
draft
is
fully
extractable
from
the
currently.
Our
model
is
fully
extractable
from
the
draft
and
it
runs
it
compiles
without
any
warning.
What
we
are
done
is
that
we
have
seen
that
a
lot
of
vendors
have
different
implementation
of
weighted
random
early
detect
algorithm.
So
what
we
have
done
is
that
we
have
converted
into
random
early
detector
Gotham,
which
is
a
basic
algorithm,
and
everybody
is
supposed
to
support
that.
J
So
for
the
meter
actions,
we
have
actually
enhanced
the
meter
actions
to
support
not
only
sexy
direction
but
also
field
action,
and
also
one
meter
can
point
to
the
next
meters,
where
you
know
rest
of
the
parameter
could
be
specified.
So,
for
example,
you
know
somebody
has
to
specify
a
single
rate
tricolor
marking
meter,
so
somebody
has
to
configure
two
meters
for
that.
One
will
be
with
the
with
the
rate
and
burst
and
section
will
be
only
only
burst,
and
so
the
first
meter
will
point
to
the
second
so
that
face
somebody.
J
J
The
operational
data
model
so
far
we
had
been
supporting
the
grouping
of
the
data
model.
We
never
offended
that
data
model
to
the
interface,
and
so
what
we
have
done
is
that
we
have
augmented
the
operation
data
model
to
the
interface
module
and
also
what
we
have
done
is
that
the
target
in
line
codification
realized
that
none
of
the
vendors
are
supporting
configuration
of
the
policy
directly
under
the
target
interface.
J
So
we
have
removed
that
configuration,
even
though
it
is
a
perfect
perfectly
fine
configuration
way
to
configure
it,
but
none
of
the
vendors
are
supporting
that,
so
we
have
actually
move
from
the
draft
it
in
some
other.
You
know
suggestion
we
have
got
is
that
the
draft
doesn't
explain.
What
is
you
know
what
is
no
action
template
even
though
we
have
classified
mod,
classify
as
a
template,
we
have
policy
as
a
template.
We
don't
have
action
as
a
template.
Typically,
the
reason
is
that
action
is
a
very
specific
parameter.
J
Like
you
know,
Polly
say,
for
example,
somebody
has
to
configure
a
poly
state
of
110
kbps
versus
102kbps.
So
typically,
you
know
those
templates
are
not
reusable,
so
it
is
always
better
that
you
know
somebody
define
the
action
configuration
as
an
inline
parameter
rather
than
you
know,
specifying
as
an
action,
a
genome
space
use
it
in
different
kind
of
policies.
So
none
of
the
vendors
are
actually
you
know
supporting
action
as
a
template.
Everybody
configure
action
as
an
inline
configuration
rather
policy.
J
J
J
So
based
on
that,
you
know
open
issues
we
have
a
pro
society
of
community
to
to.
You
know,
provide
some
kind
of
suggestions
so
that
we
can
proceed
further
than
that
and
some
of
the
pressure
suggestion
we
have
got
from
the
idea
of
community.
Can
you
go
to
the
next
slide,
please
so
some
of
the
guidelines,
some
of
the
suggestion
we
have
got
from
ITF
community-
is
that
if,
for
example,
certain
set
of
parameter,
which
can
be
only
supported
by
a
one
particular
vendor,
then
it
should
be
part
of
the
vendor
specific
extensions.
J
If
it
is
supported
by
a
few
of
the
vendors,
then
it
should
be
part
of
the
feature
and,
if
lot
of
whether
supported
they
use
deviation,
I
must
agree
that
nobody
wants
to
use
deviation
in
their
model,
for
that
will
indicate
that
they
are
not
supporting
something,
even
though
it
is
perfectly
fine
by
the
model
by
the
use
case.
Is
there
support?
J
J
C
Yeah,
a
synonym
Cisco
is
it
possible
I
I,
attended,
I
haven't
selected.
This
is
one
of
the
200
I
haven't
looked
at.
Is
it
poss
I
mean
yang
models?
Is
it
possible
to
partition
between
things
that
are
strictly
a
platform
dependent
and
platform
independent
and
make
the
platform
independent
dependent
one's
all
is
because
I've
worked
on
this
problem,
not
from
me
a
model,
but
from
a
CLI
standpoint
it
was
really
you're,
never
going
to
get
it
even
even
within
event
or
not.
You
have
different
families
of
line
parts
that
have
support
different
things.
Yeah.
J
Means
it
depends
on
some
of
the
use
cases.
For
example,
you
know
some
of
the
vendors
support.
Certain
use
cases
for
with
some
of
the
configuration
is
valid
configuration
in
some
of
the
cases
you
know,
certainement
that
doesn't
supports
particular
use
cases.
So
so,
in
that
case
they
they
will
have
a
different
way
of
configuring,
the
things
and
there's
a
mechanism
to
provide
capability
framework.
J
For
example,
you
know,
there's
a
capability
framework
which
you
can
send
through
the
hello
message
when
the
current
controller
connection
comes
up,
so
all
those
provisions
are
there,
but
then
you
know
because
of
the
different
use
cases
of
the
different
vendors.
So,
irrespective
of
the
platform
dependent
of
a
play
for
independent,
they
have
ascertained
different
configuration
model.
Worst
is
different
vendors,
which
support
different
use
cases,
so
they
have
a
different
configuration
model.
F
There's
a
comment
on
myrica
from
norm
straw.
He
says
just
what
I
emphasize
still
significant
challenges
to
be
worked
out
for
the
model,
fundamental
issues
or
different
architecture,
difficult
to
represent
the
same
model.
Can
you
read
thing
norms
for
all
says
just
want
to
emphasize.
There
are
still
significant
challenges
to
be
worked
out
for
the
model.
Fundamental
issues
are
different,
architectures
difficult
to
represent
in
the
same
model,
yeah.
J
Means
I
would
not
say
it's
a
different
architecture,
but
I
would
say
that
it's
a
different
use
cases
configuration
and
so,
for
example,
you
know,
as
I
gave
an
example
where
there's
a
single
scheduler
under
the
interface
versus
per
class
scheduler.
Now
that
that
isn't
that
there's
a
use
case
where
they
are
supposed
to
only
support
single
scheduled
up
were
interface.
But
then
you
know
certain
vendors
can
support
the
use
cases
where
they
could
have
multiple,
a
classifier
and
/
classify.
They
can
have
a
separate
scheduler
for
that,
so
it's
all
dependent.
J
It
may
not
be
based
on
the
architecture,
but
it
could
be
it
based
on
the
use
case
e.
So,
for
example,
you
know
the
same
and
if
they
have
to
support
a
per
classifier
scheduler,
then
they
have
to
come
up
with
a
similar
kind
of
configuration,
and
that
will
me
mean
that
you
know
different
vendors
can
converge,
but
you
know
because
certain
vendors
have
a
limited
use
cases
to
support.
So
what
that
mean?
Is
that
those
wind?
J
I
want
a
minimum
subset,
a
subset
of
the
configuration
to
be
representin
to
the
yang
model,
but
then
different
vendors
have
much
more
use
cases
to
support,
so
that
becomes
a
superset.
So
the
idea
will
be
that
whether
we
have
to
choose
a
subset
of
the
configuration
or
whether
we
have
to
choose
a
superset
and
then
we
provide
a
particular
vendors
which
cannot
support
then
either
they
have
to
use
deviation
or
we
have
to
put
a
feature
everywhere
and
we
said
at
all
this
feature
cannot
be
supported.
A
J
J
Yes,
so
you
know,
if
you
look
into
a
diff
sir
RFC
standards,
they
provide
a
mechanism
to
support
everything.
They
don't
talk
about.
You
know
we
send
the
configuration
down
and
then
it
got
rejected
by
the
interface,
which
is
absolutely
possible.
But
then,
if
we
constraint
that
a
certain
model
will
be
a
basic
for
everybody
to
support,
so
is
it
a
subset
of
the
model
or
the
superset
with
a
feature?
A
K
Hi
I'm
Rob,
Wilton
and
I
under
present
to
you
quickly
on
two
new
drafts
that
we've
come
up
with,
and
the
first
one
is
an
interface
extensions
draft
and
problem.
We're
trying
to
solve
effectively
is
and
any
in
the
sort
of
common
interface
configuration
that
you
might
see,
sort
of
lower
layer,
interface
configuration
you
might
see
on
a
route
or
switch
there's
been
implemented
by
many
different
vendors
and
has
no
defined
standard
associated
with
it.
K
So
initially,
I
imagined
that
our
c72
three
would
cover
this,
but
because
that's
so
generic
and
its
structure
and
has
to
cover
all
interfaces,
it
is
very
limited
in
terms
of
what
it
actually
defines.
Really,
it's
just
a
list
of
interfaces,
a
name
and
a
type
associated
with
it.
So
problem
space
in
terms
of
defining
is
to
cover
these
extra
properties.
K
They're
all
minor
features
so
they're,
not
as
large
as
IP
or
anything
that
has
its
own
and
well-defined
rafi
circle
extra
little
features
and-
and
it's
desirable
people
who
you
using
these
yang
models
to
us,
have
a
standard
way
of
using
this
configuration
without
having
per
vendor
configuration
you're.
The
next
slide,
please.
K
So
the
solution
is
quite
simple:
guide,
Erie's,
just
to
define
to
yang
module
and
and
really
the
key
bits
here
is
what
the
sort
of
sample
configuration
that
we've
got
in
as
a
few
more
bits
we've
got,
the
main
ones
are
really
a
name
to
use
defined
for
all
interfaces
directly
or
packet
or
framing
framed
interfaces
will
have
them
to
you
and
limp
flat
mitigation,
which
I've
called
carry
delay
in
interface.
Dampening
different
vendors
have
different
names
for
these
sorts
of
features,
but
most
of
us
and
it's
very
similar
and
behaving
the
same
way.
K
Leia
wanna
loopback
configuration
an
encapsulation
choice
which
is
to
allow
different
interface
types
to
extend
the
encapsulation.
So
you
had
a
pod
interface,
you
might
have
PPP
or
frame
relay
extending
from
this
layer
to
encapsulation,
and
that's
also
using
this
second
model
done
described
in
a
minute
to
do
with
via
an
encapsulation.
Now
the
last
thing
I'm
defining
for
moves
on
is
a
sub
interface
and
which
I'm
not
sure
all
vendors
have
concept
of
subinterfaces.
K
K
So
it's
designed
to
be
as
generic
as
possible.
There's
also
a
separate
model
in
terms
of
I
tribunal.
82
1q,
which
has
a
bridge
model
of
vlans
I,
see
this
as
being
a
complementary
model.
So
in
terms
of
implementing
this,
you
might
implement
one
or
both
of
these
models
on
a
device
depending
on
whether
your
device
was
more
sort
of
switch,
centric
or
root
eccentric.
K
So
there's
two
yang
mode
has
been
defined
here:
I
fl3,
VLAN
module
defines
basic
tag
matching
for
up
to
two
VLAN
tags
and
it
is
much
an
explicit
tags
and
the
expectation
there
is
you
terminate
back
to
an
l-3
surface
a
service,
so
the
expectation
is,
you
have
to
be
able
to
match.
The
explicit
tank
is
going
to
take
off.
K
So
you
can
struck
the
odd
to
header
when
you
send
Packers
out
again,
then
there's
a
more
flexible
encapsulation
that
has
this
for
l2
services
and
in
this
particular
one
you
allow
to
match
on
ranges
of
tags
or
you
could
be
extended
to
match
on
other
l2
header
fields
like
mac,
address,
potentially
or
passive
service
fields
and
again
in
terms
of
the
more
flexible
l2
capabilities.
We
also
have
the
capability
of
doing
and
tag
manipulations.
K
You
can
pop
tags
off
or
push
tags
on
and
rewrite
them,
and
the
ID
here
in
terms
of
what's
been
models
here
is
the
common
functions.
You'd
expect
a
vendor
might
use
for
configuring.
These
services,
with
expectation
that
secret
vendors
may
sort
of
extend
this
model
to
match
more
more
advanced
fields
as
they
want
to,
and
that's
it
so
so
seeking
review
feedback
expressions
of
interest.
People
parties
are
interested
in
these
models
and
try
to
take
them
forward
any
questions
on
either
the
dress.
A
K
Yes,
of
course,
so
I'm
interacting
a
bit
with
Mark
Thomas
in
dot1q
who's,
he's
reviewed
some
of
this
and
effectively
some
of
the
areas
where
there
are
overlaps
in
terms
of
us
using
the
IP
I
Tripoli
types.
The
expectation
is
that
would
be
standardized
to
write
Ripley
midterms
the
two
models
in
the
latest
draft
I.
Don't
know:
you've
read
the
later
on
earlier
draft.
There
is
a
comparison
between
the
two
models
and
how
effectively
our
understanding
is
that
they
shouldn't
overlap
that
they
there
have
different
capabilities
and
different
advantages.