►
From YouTube: IETF110-DETNET-20210308-1430
Description
DETNET meeting session at IETF110
2021/03/08 1430
https://datatracker.ietf.org/meeting/110/proceedings/
A
Hello
welcome
to
net
at
the
online
ietf
110,
I'm
blue
burger.
We
have
with
us
janice
farkas
and
ethan
chrisman,
our
secretary,
the
material
was,
should
be
all
posted
actually
for
both
sessions
and
there's
a
link
in
the
chat
to
help
get
you
to
the
kodi
md
which
we're
using
for
minute
taking
and
if
you
can
help
us
sort
of
crowd
source
those
minute.
Titans
we'd
really
appreciate
it.
A
The
same
information
was
just
sent
to
the
list,
so
please
jump
on
cody
md
and
help
us
take
notes,
see
if
I
can
get
this
thing
to
change
slides
there
we
go
as
we
are
at
the
ietf.
We
have
sort
of
ground
rules
governing
the
way
we
interact
and
also
the
information.
A
How
we
share
the
information
we
say
in
these
working
groups.
Basically
anything
you
say
here
becomes
part
of
our
record.
If
you're
not
familiar
with
the
notewell,
I
strongly
suggest
that
you
go
first
familiarize
yourself
with
it.
A
So
if
you're
hearing
this
obviously
you're
here
with
me
on
meat
echo,
so
you
figured
out
the
first
part,
the
we're
using
the
integrated,
jabber
and
chat
and
we'll
try
to
watch
that
and
channel
any
of
the
any
comments
there.
A
If
you
want
to
say,
make
sure
something
gets
to
the
the
be
repeated
please
make
sure
to
put
at
mike
in
front
of
it
we'll
try
to
track
that
and
repeat
the
comments
I
already
mentioned
that
we're
taking
notes
through
codingmd
and
the
material
is
posted
at
the
various
links.
One
thing
I'd
like
to
comment
is
tools.
The
tools
website
seems
to
be
having
a
whole
slew
of
issues,
and
if
you
run
into
problems
there
go,
you
know
check
out
for
the
same
information
on
data
tracker.
A
So
we
have
two
plus
one
sessions
at
this
meeting.
The
first
session,
we're
in
now
is
in
a
one-hour
session
we're
going
to
really
focus
on
reviewing
where
we
are
on
our
yang
document,
which
we
hope
to
move
to
last
call
the
objective
of
covering
that
now
is
to
really
make
sure
the
working
group
has
a
good
understanding
of
what's
there
and
to
facilitate,
accelerate
the
last
call
process.
A
Our
second
session
is
tomorrow,
another
one
hour
session
and
it's
sort
of
a
normal
working
group
meeting
where
we'll
cover
the
drafts
that
are
on
the
agenda.
The
third
session
is
a
joint
meeting
with
pals
mpls
in
spring
and
is
really
going
to
be
focused
on
oem
and
mpls,
and
the
control
word
consistency
across
the
different
groups
that
are
using
that
base
technology.
A
So
I
I
guess
I
should
have
made
the
comment
about
yang
on
this
slide.
So
today
we
have
the
the
yang
walkthrough
and
you
can
see
the
agenda
that's
laid
out
for
tomorrow.
A
We
in
this
working
group
we
follow
an
ipr
disclosure
process.
That
is,
we
require
ipr,
just
statements
from
authors
and
contributors
at
two
points.
The
first
point
is
when
we
adopt
the
working
group
document
and
the
second
one
is
before
we
submit
to
the
isg.
So
that's
part
of
our
last
call
process
working
with
last
call
process.
A
Those
are
required
steps
and
we
require
responses
from
all
listed
authors
and
contributors
before
moving
to
the
next
step.
We
are
also
introducing
a
new
step.
This
is
not
a
requirement
but
a
request,
and
specifically
that
we
ask
that
if
you
are
added
to
a
working
group
document
as
either
a
contributor
or
as
an
author,
that
you
make
a
statement
at
that
time
now,
you'll
be
required
to
make
a
statement
at
last
call.
A
So
we've
had
a
a
good
set
of
documents
published
it's
always
good
to
to
see
publications
and
new
rfcs.
We
thank
all
those
who
contributed
to
this,
and
you
know
all
that's
pretty
much
everyone
in
the
the
working
group,
because,
even
if
you
just
make
a
single
comment,
that's
a
contribution,
and
we
appreciate
that
we
also
have
a
good
set
of
documents
in
the
rfc
editor
queue
together
between
the
published
and,
what's
in
the
rfc,
editor
queue
that
makes
up
the
core
data
plane
of
debt
net
and
represents
a
really
significant
achievement.
A
A
A
A
At
this
point,
we're
all
used
to
working
remote,
probably
a
little
tired
of
it
and
looking
forward
to
hopefully
not
too
long
being
in
person.
But
until
then
we
encourage
everyone
to
continue
using
the
list.
Discussion
there
is
is
really
the
primary
place
for
resolving
issues.
A
We
can
also
schedule
working
group
meetings
and
then
less
formal
working
meetings.
I
believe
there
are
going
to
be
two
less
formal
meetings.
Spinning
up
they're,
the
yang
there's,
a
weekly
yang
call,
that's
been
going
on.
I
think
that
one
is
going
to
wind
down
and
we're
expecting
that
there's
going
to
be
one
on
control,
plane
and
one
on
oam
those
group.
Those
meetings
are
open
to
everyone,
they're
less
formal,
so
they're
not
minuted,
but
they
were
the.
A
What
goes
on
there
will
translate
to
updates
to
drafts
and
those
drafts
will
be
brought
to
the
working
group
and
the
changes
will
be
brought
to
the
working
group
for
to
ensure
that
we
have
consensus
from
the
working
group.
But
again,
those
are
going
to
be
open
to
all
and
look
stay
tuned
to
the
list
for
the
announcement
of
those
meetings
and
with
that
we're
done
with
the
intro
and
we're
going
to
go
on
to
the
configuration
sorry,
the
yang
model.
A
This
is
the
is
going
to
be
the
the
rest
of
this
session
and
I
believe,
don.
You
said
you're
going
to
be
presenting
this
just
make
sure
to
say
next,
and
so
I
noticed
one
already
done.
B
B
Okay
thanks,
so
this
is
the
yang
model,
so
I'll,
just
state
that
I'm
not
aware
of
any
ipr,
because
I
joined
the
draft
at
some
period
after
it
was
adopted
as
a
working
group
document.
B
So
the
the
list
of
authors
on
there
and
we've
like
we
would
mention-
we've
had
weekly
meetings
pretty
much
throughout
the
year
and
if
you
go
to
the
next
chart,.
B
So
we
think
the
document's
at
a
point
where
we're
ready
for
last
group
call
we've
we've
had
in
other
updates.
We've
always
had
items
that
we
had
to
do.
We've
we're
going
to
present
the
summary
today
and,
as
always,
please
review
and
comment.
So
one
of
the
things
I'm
gonna
do
today
is
try
and
help.
You
understand
how
we,
how
we
approach
the
document
and
and
help
you
perhaps
get
any
review
comments
in
next
chart.
Please.
A
Comment
on
your
prior
slide,
the
the
title
of
the
prior
slide
said
configuration
my
memory
is,
is
the
current
model
covers
both
configuration
and
operational
state.
B
Yes,
yes,
so
there
is,
and
the
the
name
of
the
model
was
called
the
config
model,
and
then
we
changed
it
just
to
detonate
yang.
B
So
there
there
is
both
status
information
and
configuration
information
in
there.
So
because
this
this
model
is
is
is
a
primarily
configuring.
The
data
plane,
though
the
majority
of
the
items
are
configuration
items.
B
So
the
history
there
is,
as
we
went
through
the
various
versions,
so
we're
on
version.
10
and
11
are
virtually
the
same,
except
that
somewhere
along
the
lines.
I
guess
the
I
I
didn't
catch,
that
the
was
there
was
additional
yang
checks
that
went
in
so
when
I
submitted
10,
I
found
that
there's
a
dash
itf
flag.
I
hadn't
been
using
on
the
yang
the
pyang
tool
and
that
turned
up
a
bunch
of
other
basically
comments
on
descriptions
that
were
missing.
B
So
the
det-net
architecture
is
is
published
in
this
diagram
is
in
there
in
ascii
text
and
as
we
were
as
we
were
trying
to
present
this.
I
realized
that,
if
you,
if
you
think
about
the
the
data
plane
drafts,
they
go
right
across
this
architecture,
kind
of
horizontally
and
the
same
thing
for
the
flow
model.
B
It
talks
about
flows
that
are
that
are
dealt
with
the
attributes
that
are
dealt
with
them
horizontally,
but
the
yang
model
is
actually
kind
of
operating
vertically
in
the
stack
on
each
on
one
of
these
devices
so
depending
upon
where
you
are
you're
using
different
attributes
in
the
yang
model
and
that's
what
we're
covering
so
we're
covering
the
the
the
data
planes
defined
in
the
ietf
and
the
cases
in
the
ietf
and
there's
corresponding
yang
that
we
haven't
really
looked
at
in
this.
B
That
would
be
for
tsn,
that's
being
in
the
ieee
802.1
working
group,
so
we're
we've
been
concentrating
on
what
we
documented
and
trying
to
stick
to
the
data
planes,
etc
that
are
in
there
okay
next
chart.
B
So
this
chart
we've
seen
before
and
the
the
flow
model
is,
is
a
functional
model
that
talks
about
the
flows
and
it
it
talks
about
application
flows,
the
detonate
flows
and
the
service
and
we've
translated
that
into
the
various
pieces
in
the
architecture.
B
B
So,
like
I
said,
the
net
yang
model
is
it's
hierarchical.
It
contains
aggregation,
it's
location
dependent.
We
saw
on
the
chart
where
you
are,
if
you're
an
endpoint
transient
or
relay
the
the
flows
are
aggregate
flows
and
we
capture
the
flow
attributes
and
the
status
information.
That's
in
there
we
tried
to
build
it
as
much
as
possible
on
reusable
pieces
from
other
yang
models
were
out
there
for
ip
and
mpls.
B
B
B
B
So
we
went
through
trying
to
align
the
terminology
with
the
documents
and
trying
to
reuse
the
the
pieces
that
were
out
there
and
what
we
found
worked
was
considering
configuration
cases,
so
we
started
off
once
we
had
revamped
the
model
we
we
started
off
with
a
simple
configuration
case
of
a
flow
starting
in
an
application
going
through
the
service
sublayer
going
through
the
forwarding
sub-layer,
and
then
we
used
yanglint
to
test
and
document
that
case
so
by
providing
an
xml
file
that
had
had
the
configuration
aspects
for
the
particular
case
we
were
looking
at.
B
We
could
go
through
and
validate
that
against
the
schema
and
it
gives
you
a
clearer
picture
and
because
we
we
had
discussions
back
and
forth
we've
we've
provided
diagrams
for
the
cases
so
we've
got
like.
I
said
we
started
off
with
the
basic
single
detonate
flow
endpoint
for
unidirectional
and
bi-directional
cases,
and
then
we
started
working
our
way
through
the
different
cases,
transit
nodes
and
simple
aggregation
and
aggregation
at
several
places.
B
So
we've
seen
this
chart
before
and
it's
kind
of
a
map
of
what
we've
done,
so
we
have
at
the
top
there.
We've
we've
got
ip
and
an
ip
flowing
flow
coming
in
could
be
ip
could
be
ip
all
the
way
through
that
net.
It
could
be
application,
service,
sub
layer
or
forwarding
sub
layer,
and
it
could,
it
could
come
all
the
way
through
or
ip
could
be
encapsulated
at
mpls
at
the
service
sub-layer,
and
it
could
continue
its
way
on
mpls
and
then,
of
course,
return
to
ip
at
the
outside
or
it
could.
B
It
could
be
that
I
ip
went,
went
over
mpls
and
then
that
went
over
a
an
ip
tunnel.
We
we
don't
have
everything
for
ip
tunnels
in
there
and
ip
and
ip
tunnels,
because
we
don't
have
any.
At
this
point.
We
don't
have
any
detonate
drafts
that
specify
those
so
mpls.
You
could
come
in
at
this
mpls
and
you
could
just
pass
through
as
mpls
all
the
way
ethernet.
B
Mpls
is
the
typical
case
today,
but
it
could
go
in
an
ip
and
ip
tunnel
in
the
future
as
well.
B
So
we've
we've
highlighted
the
the
documents
that
we
we've
covered
and
for
for
this
for
this
bass
draft.
This
is
what
we're
thinking
is
necessary
to
cover
the
the
question
we
have
is
is:
is
there
anything
we
think
we
should
be
doing
for
the
ip
and
ip
tunnels?
That's
that's
the
only
piece
we
we.
We
think
that
it's
a
complete
document
as
it
is,
but
we
wanted
to
highlight
that
at
that
point.
A
I
guess
my
question,
I
don't
know
what
which
hat
I'm
wearing
is.
Where
is
ip
and
ip
tunnels
documented.
B
That's
that
was
our
issue
that
we,
we
didn't,
have
good
pointers
to
it
for
detnet.
Now,
if
there's
something,
if
there's
a
document
that
fi
somebody
finds
somewhere
else
that
they
think
we
could
incorporate
easily
we'd
be
happy
to
look
at
it,
but
we
were.
We
were
struggling
with
finding
a
good
pointer
to
to
go
by.
C
B
Okay
next
chart,
please.
B
So
this
is
a
just
a
a
model
structure
that
we
we
have
in
the
document,
so
we
have
application
flows,
the
service,
sub
layer
and
the
forwarding
sub
layer,
and
then
we
originally
had
under
each
we
we
tried
to
fit
in
with
the
flow
model
we
tried
to
fit
in
the
the
aspects
as
the
model
evolved.
B
We
basically
created
a
traffic
profile
that
has
the
the
flow
attributes
and
it
could
be
optionally
attached
to
each
piece,
because
that
net
is
hierarchical,
but
a
flow,
an
app
flow
and
a
service
sub-layer
flow
and
a
forwarding
layer
flow
can
can
go
on
to
the
next
layer.
We
found
that
there
were
cases
that
they
could
be
attached
to
each
one.
They
they
they're
optional.
B
In
the
sense
they
don't
have
to
be
there,
but
but
you
could
attach
that
information
to
if
you
had
app
flows
and
then
you
had
an
aggregation,
you
could
have
a
traffic
profile
that
reflected
that
aggregation
at
the
service
sub-layer,
for
example.
B
So
this
was
the
this
is:
what's
the
the
major
pieces
inside
the
model?
Are
these
the
app
flow,
the
service
sub
layer,
the
forwarding
sub
layer
and
the
traffic
flow
profile?
B
The
the
other
thing
is
that
we,
in
the
model
that
we
do
is
we
refer
to
the
the
each
layer
with
reference,
pointers
and
they're
bi-directional
reference
pointers,
but
we've
tried
to
make
it
so
that
you
only
have
to
configure
it
in
one
direction
and
the
other
direction
would
be
just
something
that
you
could
refer
to.
So
if
an
app
flow
refers
to
a
service
sub
layer,
but
you
would
only
configure
it
in
one
place
and
the
other,
the
other
one
would
be
available
for
viewing
on
the
other
side.
B
B
So
the
model
tree
is
is
in
the
document.
I
I
just
put
it
here
for
for
reference,
because
we're
gonna
be
referring
to
pieces
inside
here
and
the
the
only
thing
you
really
need
to
take
away
from
this
is
when
we
look
at
the
models
in
the
the
yang
lint,
where
we're
doing
the
actual
cases
we're
using
a
subset
of
these
models.
So
so
these
have
all
the
permea.
This
has
all
the
permutations
in
it
and
a
what
we
have
here.
B
B
We
have
the
service
sub
layer
with
its
attributes
and
direction
and
next
chart
please,
and
then
we
have
the
forwarding
sub-layer
with
its
attributes
and
directions
and
next
chart.
Okay.
B
So
so
at
a
high
level,
that's
the
the
complete
model,
and
now
what
we're
going
to
talk
about
is
the
the
various
cases.
So
what
we?
What
we
started
here
with
was
simple,
a
simple
model
and
we
started
with
the
application
flows,
so
the
diagrams
that
we've
we've
created
to
to
describe
this
have
evolved
over
time.
We've
tried
to
align
them
one
one
with
one
with
the
examples.
B
The
the
only
thing
that
may
be
a
little
bit
confusing,
and
that
was
one
of
the
reviews
had
said.
Oh
you're,
using
using
ipv4,
addresses
all
over
the
place
and
they're
the
same,
and
I
didn't
realize
we
had
done
that,
specifically
in
the
models
and
the
examples
to
match
these
diagrams,
and
I
changed
some
of
them.
B
But
for
this
for
this
presentation,
I
think
I've
realigned
them,
but
if
you're
looking
at
the
draft-
and
you
say-
oh
the
the
addresses
are
different-
it
was
just
because
there
was
a
comment
that
you
should
vary
the
addresses,
and
I
foolishly
followed
the
comment
so
in
this
in
this
diagram.
What
we
have
is
we
have
two
applications
and
that's
illustrated.
B
We
tried
to
use
a
consistent
representation
all
the
time,
so
we've
got
data
that
two
applications
being
aggregated
in
an
ip
and
so
the
rest
of
the
way
through
there's
a
rep
there's
a
replication
function,
that's
going
on
here,
but
the
rest
of
the
way
through
those
out
those
application
flows
are
basically
capital
encapsulated
in
that
ip
service
layer.
B
B
So
this
is,
I
think
this
is
just
the
same.
Go
back
for
one
second,
I
th
this
is
two
apps.
I
think
this
is
the
same
diagram
just
go
back
again
to
the
to
the
forward.
Sorry
yeah!
This
is
just
another
representation
of
the
same
diagram
we
just
had,
and
it's
just
another
way
to
show
it
so
we're
basically
showing
the
operations
that
go
on
here
at
a
node,
the
ingress,
node,
the
application
service
and
forwarding
layer
and
then
again,
you'd
have
the
same
operations
on
the
egress
and
there's
configuration
in
both
directions.
B
So,
while
this
is
bi-directional,
you
can
configure
it
either
as
like
a
unidirectional
configuration
in
two
ways,
or
there
are
capabilities
in
the
model
to
basically
use
if
you're
bi-directionally
congruent,
you
could
use
the
same
components
in
both
directions,
but
there's
nothing
in
the
model
that
forces
you
to.
So
it's
it's
a
unidirectional
type
of
configuration,
but
you
can
support
bi-directional
services
as
well.
B
So
this
is
another
case
here.
Where
now
we're
doing,
let's
see
make
sure
I
get
it
right.
We've
got
two
applications
coming
in
and
we're
doing
the.
B
B
B
A
Just
clarify
something
on
the
previous
slide:
sorry
about.
B
A
The
unmute
so
on
the
previous
slide,
you,
the
your
word,
said
that
you're
aggregating
at
the
service
level,
but
the
slide
says
aggregating
at
the
forwarding
level,
which
one
is
it
did
he
misspeak
or
is
the
slide
wrong?
I.
B
B
So
what
I
wanted
this
cover
here
is
that
as
much
as
possible,
we
validated
as
much
as
the
model
as
we
could,
so
we
actually
configure
interfaces
and
we're
using
the
operational
view
of
the
model,
because
we
we
to
to
get
a
view
of
what's
going
on.
We
have
both
config,
false
and
config.
True
attributes
when
you're
configuring
in
yang
you,
basically
the
the
con
config
true
items
are
the
ones
that
you
are.
B
Typically
configuring
and
the
config
false
ones
are
typically
the
ones
that
you're
reading
back
for
status,
information
or
you
know,
confirmation
of
configuration,
and
we
wanted
to
do
both
because
we
found
that
if
you
just
do
the
config
items,
you
don't
quite
have
the
full
picture.
You
don't
have
these
forward
and
backward
pointers
that
we
were
mentioning
so
we've
we've
gone
to
a
model
where
we're
using
the
operational
ones,
and
for
that
reason
we
have
to
fill
in
because
the
ietf
models
have
some
pieces
in
there.
B
We
have
to
fill
in
these
things
like
the
operational
status
and
the
time
just
to
satisfy
the
model.
So
that's
why
there's
more
detail
in
here
than
there
needs
to
be.
You
really
just
need
to
know
the
name
of
the
the
interface,
but
because
we're
going
to
use
that-
and
we
have
an
operational
view
it.
It
will
show
up
in
this
way
in
the
model
and
then,
on
the
right
hand,
side.
We
have
the
applications
here.
Sorry,
oh
stay
there,
so
we
have
the
application
and
we
have
the
the
application's
names.
B
And
then
we,
like,
I
said,
we've
got
these
pointers,
the
reference
pointer,
so
the
outgoing
service
we've
called
it
service,
sub
layer
dash
one
and
the
traffic
profile
that
it's
associated
with,
and
then
you
see
some
status
information.
So
we
said
it's
all
working
and
ready,
but
that's
just
data
that
we're
punching
into
the
model
and
the
interface.
B
So
the
interface
like
I
said
to
get
that
interface
and
reference
it
in
language
is
actually
check.
Checking
these.
So
if
I
was
to
put
ethernet
interface
five
in
it
would
say
it
doesn't
exist
so
so
that
aspect
of
the
model
is
being
checked
in
here,
but
it
also
gives
you
the
nice
flow
through
of
what's
going
on
here.
So
we
have
the
ip
flow
and
the
addresses
in
here
and
then
the
same
for
application
two.
So
now
I
believe
you
have
to
go
back
one
chart
to
get
to
the
second
chart.
B
Yes,
so
here's
the
the
traffic
profiles
follow
next
and
we
have
the
profile
and
then
we
have
the
in
this
one.
We
have
traffic
requirements
there
are
in
in
the
third
one
down.
We
have
some
flow
spec
capabilities.
You
can
populate
it
with
the
traffic
requirements
or
the
flow
spec
or
both
or
neither,
and
then
we
have,
as
I
mentioned
before,
we
have
pointers
to
the
applications
that
it's
re
that
are
members
of
this
and
then
in
the
application.
B
We
saw
that
we
had
a
pointer
to
the
traffic
profile
and
then,
on
the
right
hand,
side.
We
have
the
service
sub-layer.
So
we
have
again
the
service
of
layer
name
and
if
it
has
a
traffic
profile
and
the
operation
type
that
it's
doing
and
then
it
has
the
application
flow.
That's
that
that
it
that's
that's
in
there
and
then
it
has
the
outgoing
type
where
it's
going
to
the
forwarding
sub-layer
and
it's
it's
the
index
and
any
labels
that
we've
got
on
there
and
these
labels
should
match
the
diagram.
B
B
So
there's
the
the
the
other
service
sub
layer
and
then
we're
on
to
the
forwarding
sub
layer.
So
we
have
the
forwarding
sub
layer
and
again
just
like
you
saw
with
the
other
ones,
the
name,
the
traffic
profile,
the
operation
type,
the
the
service
sub
layers
that
are
aggregated
in
this.
We
we
can
see
that
and
then
the
outgoing
interface
it's
going
to
one
of
these
interfaces
and
the
labels
that
go
on
there.
B
B
I
we
we
didn't
go
through
this
for
every
one
of
these,
but
these,
like
I
said,
are
published
on
github.
We
can
publish
a
pointer
to
that
if
you
want
they
just
to
help,
you
understand
the
model.
So
if
you're,
really
a
good
at
yang
expert
you'll,
just
look
at
the
yang
model
and
know
what's
going
on
if
you
want
to
understand
how
it's
used
in
configuration,
these
are
the
things
that
you
would
go
and
look
at
look
at,
so
I
can
pause
there
for
any
questions.
B
This
is
the
diagram
that
goes
with
that.
So,
like
I
say,
we've
we've
we've
done
the
the
validation
and
then
we've
done
the
day
diagram
for
all
of
these
cases,
and
I'd
like
to
thank
you
know
the
members
that
were
participating
in
the
weekly
meetings
for
for
going
through
all
these,
because
it
it
takes
a
while
to
go
all
through
all
these
and
get
that
working.
But
I
think
it
provides
a
good
way
to
view
the
yang
model.
A
Don
these
are
not
in
the
the
the
working
group
document
correct.
A
B
Yeah,
no,
the
we
didn't
put.
We
put
a
couple
of
tests
of
test
files,
so
I
think
it's
a1
b1
and
b2.
The
the
tests
are
are
in
there
because
other
yang
documents
typically
include
some
sample
configuration
and
we
validated
that
through
yanglint.
B
So
we
have
done
that.
But
we
haven't
put
the
diagrams
in
because
they're
not
an
ascii
art,
and
I
I
think.
A
I
I
myself
haven't
done
that,
so
I'm
not
quite
sure
how
that
works
from
the
the
you
know,
mechanical
processing,
but
I
know
you
can
do
it
if
you
want
to
just
just
something
to
consider
is
if
you
think
this
is
really
useful
and
help
you
understand
things,
you
might
want
to
figure
out
how
to
capture
it
in
the
document.
There
is
one
also
comment
from
jabber.
A
B
So
there
there
are
tsn
yang
models
that
are
being
defined
in
the
ieee,
but
those
are
not
det-net
yang
models.
Those
are
tsn
ones.
B
B
So,
but
when
you
talk
about
interoperability
in
yang,
I'm
not
I'm
not
exactly
sure
what
you're,
what
you're
talking
about
the
data
plane
between
the
way
this
is
implemented
is
you
would
configure
on
one
node?
You
can
figure
on
another
node,
but
the
data
plane
that
goes
between
that
is
standards.
B
It's
either
mpls
or
ip
right
now,
and
that
would
be
interoperable.
So
I
I
don't
know
what
interoperable
means
in
the
sense
of
yang
models
in
this
question
if
they
want
to
clarify,
but.
A
B
So
the
these
are
the
cases
we
went
through,
so
I
think
I
think
people
can
read
through
the
cases.
Basically,
we
considered
aggregation
at
each
layer
and
the
the
model
has
so
so
what
we,
when
we
were
discussing
this,
we
found
out
that
that
net
is
very
recursive
in
the
way
it
works
it
can
it
can.
B
B
He
may
he
may
step
up
at
the
end
and
have
some
discussion,
but
he
had
some
questions
about
ethernet,
going
on
to
these
models
and
for
ethernet
we
basically
consider
ethernet
as
an
interface,
and
we
have
some
attributes
on
the
ethernet
that
could
could
filter
it
down
to
like
a
vlan,
say
or
a
particular
address,
and
then
it's
carried
transparently
across
the
network.
B
We
don't
do
anything
else
with
ethernet,
because
that's
not
part
of
the
debt
net
documents
that
we
have,
but
we
do
cape.
We
do
carry
that
across
there.
B
B
B
The
the
point
is
that
when
you're
reviewing
this
just
look
through
the
models
and
see
if,
if
you
think
that
they
they
make
sense
and
if
you
think
of
anything
else
that
you
think
is
missing,
you
know
please
raise
it
on
the
list.
I
I
have
a
reply
to
bella's
about
the
ethernet
pieces,
but
I
may
not
have
hit
his
points
on
there.
B
B
And
so
this
is
aggregation
in
this
case.
We
have
forwarding
sub
layers
here
and
we
are
aggregating
that
net
flows
one
two
into
a
forwarding
sub
layer
go
on
to
the
next
chart.
B
B
I
think
these
charts
speak
to
themselves.
This
is
just
showing
the
reverse
direction
for
that.
One
next
chart.
B
And
the
corresponding
aggregation
diagram
for
that
what's
going
on
there,
so
you
know
we
can
just
go
through
these
charts.
There's
nothing
at
this
point
that
I'm
not
going
to
deal
with
each
one.
But
if
there's
any
questions
that
you
know
you
have
now
or
on
the
list
about
these
diagrams,
please
feel
free
to
raise
them.
Go
on
to
the
next
chart.
B
Yeah,
that's
just
the
design
aggregation,
so
we've
got
the
relay
node
and
this
one
is
aggregating
service,
sub
layers
into
a
service
sub-layer,
so
go
on
again.
A
Are
you
going
to
have
any
slides
that
cover
just
the
ip
only
case
or
is
everything
ip
over
mpls
in
the
examples.
B
I
don't
think
we
have
one
that
that
covers
the
ip.
Only
the
the
ip,
only
there's
not
much
difference,
just
the
the
forwarding,
if
you,
if
you
go
back
to
the
I
guess,
you'd
have
to
go
back
to
the
tree
model.
If
you
want
to
look
at
it,
but
I
can
point
out
the
differences
if
you'd
like.
B
B
Yeah
well
we're
basically
there's
there's
nothing
here
more
than
examples.
We
really.
We
just
wanted
people
to
be
able
to
compare
with
these
charts.
B
You
know
understand,
what's
going
on
and
and
you
know,
I
don't
think
that
there's
really
any
more
value
in
going
through
the
charts
other
than
to
say
that
you
know
the
value
you
get
about
them
is
is
holding
up
the
two
of
them
together
and
saying.
Okay,
I
see
the
difference
here
and
then
I
can
see
the
difference
in
the.
B
C
B
So
certainly,
certainly
the
some
of
them
are
inspired
by
real
use
cases,
because
you
want
to
be
able
to
aggregate
at
each
layer,
but
some
of
them
it
started
to
fall
out
because
the
nature
of
the
yang
model
it
once
you
aggregate
something
at
the
service
layer
and
you
you,
you
allow
services
to
come
in.
You
end
up
with
these
this
this
hierarchical
nature,
but
then
being
able
to
plug
and
play
them
in
there.
B
So
I
the
they
were
definitely
inspired
by
real
use
cases,
but
I
think
the
model
supports
perhaps
more
aggregation
types
than
you
would
need
in
the
sense
of
doing
that
on
a
particular
node.
You
can
always.
You
can
always
do
this
step
by
step
by
adding
another
node
with
configuration
to
like
you
start
an
application
again.
You
have
something
aggregated,
but
then
it
comes
in
as
an
application,
and
you
could
do
it
that
way.
B
B
B
B
B
B
Well,
essentially,
this
diagram
here
would
actually
show
so
so
that
your
question
was
have
we
done
mostly
mpls
and
we've
done
mostly
mqls
going
on
to
the
mpls
path.
But
the
ip
path
would
basically
just
have
the
service
sub
layer,
labels
being
ip
and
the
forwarding
sub
layer
being
ip.
So
if
you
go
next
chart.
B
So
the
service
sub
layer.
Here,
if
you
look,
if
you
look
midway
on
the
screen,
it
says
service
id
and
it
says
debt
net
flow
type.
If
you're
an
ip.net
flow
type.
You
configure
the
ip
addresses
in
in
these
parts
if
you're
an
mpls
flow
type,
you
configure
it
later
on.
So
basically
the
difference
between
ip
and
mpls
is
right.
There
it's
captured
right
there
or
that's
for
the
incoming
direction
and
then
for
the
outgoing
type.
It's
the
same
thing.
We
have
the
header
type.
B
If
it's
an
mpls
header
or
if
it's
an
ip
header
on
the
right
hand,
side,
you
would
configure
it
as
an
ip
header.
So
that's
the
only
difference
in
the
model
between
doing
an
alt
all
ip
and
and
an
all
an
mpls
one.
The
other
thing
about
the
ip
is
because
you
can
specify
you
can
specify
prefixes
on
the
input
of
the
ip.
You
can
do
some
aggregation
with
ip
prefixes
in
the
ip
model.
B
C
A
If
you
do
end
up
putting
this
material
into
the
append
into
an
appendix,
I
think
it
would
be
good
to
include
some
ip
pure
ip
examples,
both
for
the
normal
case
and
the
aggregated
case,
and
I
see
we
have
david
black
in
queue.
A
D
I
would
agree
with
with
your
remarks
one
of
the
nice
things
about
the
mpls
data.
Plane
is
every
time
you
do.
The
aggregation.
You've
got
a
label
that
shows
you.
The
aggregation.
D
The
ip
data
plane
has
to
do
some
of
this
implicitly
so
starting
from
mpls
at
the
very
least,
leads
to
clarity
in
this
discussion
and
then
writing
up
the
ip
examples
that
would
be
useful
and
maybe
in
if
we
find
serious
gaps
there,
it
might
lead
to
somebody
trying
to
figure
out
how
to
do
an
ipip
data
plane
to
fill
the
gaps.
We
need
to
understand.
The
gaps
are
first.
B
Yeah,
we
don't
think
there's
any
gaps
from
an
ip
perspective,
but
you
know
we
can.
We
can
definitely
spin
up
a
test
case
to
make
sure
and
the
the
the
question
I
guess
is,
do
do
people
find
you
know
we.
We
we
put
a
a
few
example
models
in.
We
didn't
want
to
bloat
the
document
with
it,
but
if
people
really
find
that
hey
this,
I
don't
know
what
you
call
it
dictionary
of
examples
basically
is
really
useful
and
we
should
capture
it
in
the
document.
D
E
E
So
where
I
was
somewhat
somewhat
worried
is,
if
you
are
using,
for
example,
a
tsn
sub
network
and
that
net
node
is
a
dsm,
aware.net
node,
as
defined
in
the
in
the
drafts,
then
you
need
some
mapping
between
the
that
net
flows
and
the
tsn
streams,
and
I
think
this
is
a
point
where
ieee
specified
young
model
and
idea
specified
young
model
have
to
find
a
common
connection
point
so
that
that
was
my
major
question
on
on
the
list
regarding
the
sub
network
scenarios.
B
A
A
follow-on
to
that
is
other
large
yang
models
have
sometimes
written
a
section
about
future
augmentation.
So
clearly,
there's
going
to
be
definitions
for
tsn.
If
you
attended
raw
earlier
today,
you
would
have
heard
them
talking
about
building
on
the
the
base.net
model,
so
they
might
have
some
definition,
so
it
would.
It
would
be
good
to
have
a
section
sort
of
an
informative
section
for
the
the
future
model
designers
that
you
know
the
derivative
model
designers
to
talk
about
how
you
envision
augmentations
for
technology
specifics.
A
B
B
All
right!
Well,
that's
all
I
have
if
there's,
if
there's
no
more
questions.
C
B
B
A
I
also
have
powerpoint
exported
as
svg,
I'm
pretty
sure
we
have
toilets.
Oh.
B
Is
that
is
that
the
oh
okay,
you
can
yeah.
A
It's
just
one
that
if
you
do
it
in
svg
it
it
can
map
to
many
formats,
and
I
guess
the
implication
there
is
is
that
the
tooling
likes
svg,
but
we're
running
out
of
time.
So
trollus
is
in
queue.
F
And
if
I
unmute
myself,
it
works
better.
So
thank
you
very
much.
This
is
this
is
a
lot
of
great
work
and
I'm
always
wondering
how
to
actually
validate
this
stuff
right.
So
beside
you
know,
people
with
hopefully
insight
looking
at
it
and
providing
feedback.
Are
there
any
you
know,
implementation
or
other
validation
plans
beyond
just
you
know,
manual
review.
B
Well,
we
I
mean
the
validation
that
we've
done
is
yangling
validation,
so
but
but
you
you
are
still
with
with
yangon
validation.
You
are
basically
doing
a
you're
exercising
the
model,
but
it's
still
up
to
someone
to
say
that
you
know
you've
got
all
the
pieces
in
there.
F
Right
I
mean
so
kind
of
is
this
stuff
in
the
model
necessary
and
sufficient
to?
Actually,
you
know
operate
a
a
running.net
service
right,
any
running.net
service,
even
if
just
a
simulated
emulated
whatever
one
right.
B
Yeah,
so
I
mean
as
far
as
ip
and
mpls
we've
used
standard
models
and
pieces
like
that,
so
we
think
it
hangs
together,
but
I
I
don't
have
an
a
specific
implementation
of
it
and
there
might
be
others
in
the
group
that
that
are
participating
that
have
been
taken
further.
A
B
C
I'm
good,
okay
janos.