►
From YouTube: DETNET WG Interim Meeting, 2020-10-14
Description
DETNET WG Interim Meeting, 2020-10-14
A
A
A
A
A
A
So
if
you
have
questions
to
the
presentation
or
you
want
to
make
a
web
comment,
please
add
yourself
to
the
keyword,
the
microphone
in
the
webex
chat
window
with
the
plus
q
sign
or
and
then
we
will
ask
you
to
to
talk
and
you
can
leave
the
queue
if
you
decide
so
and
with
a
minus
q
sign
for
a
discussion
chat
like
generic
chat,
we
use
jabber.
So
please,
please
join
the
java
chat.
It's
only
lou
and
myself
so
far
on
that
we
use
it
for
minute,
taking
as.
B
A
So
please
add
yourself
fill
in
the
name
and
what,
with
the
name
and
the
affiliation
with
full
name
and
affiliation,
also,
please
join
the
minute
taking
in
either
bad.
So
that's
what
becomes
the
basis
of
our
official
minutes
the
agenda
and
the
slides
are
available
at
the
page
of
this
session.
This
interim
session
and.
A
A
A
A
A
B
A
Let
us
know
if
you
would
see
benefit
and
you
would
think
it
useful
to
schedule
this
type
of
informal
working
meetings
for
for
a
topic.
Please
do
not
hesitate
to
contact
us.
It
seems
it
will
stay
this
virtual
world
for
now
and
and
we
think
that
this
type
of
virtual
meetings
may
facilitate
making
progress
or
suggest
to
to
leverage
this
opportunity
next
slide.
Please.
A
A
A
So
it's
getting
to
us
the
rfc
or
queue
we
are
done
with
them
and
also
the
mpls
over
the
dpip.
We
have
submitted
the
publication
request
and
actually
there
is
a
quite
a
recent
version
uploaded
available
that
addresses
all
the
comments
we
have
received
so
far.
So,
as
I
understand
it's
to
be
scheduled
for
a
telechat
and
for
getting
towards
isg
approval,
the
security
draft
has
a
similar
status.
A
It
has
been
updated
and
all
the
comments
we
have
received
have
been
addressed
and
it's
to
be
scheduled
for
a
telechat
for
ing
approval
and
the
flow
information
model
is
also
in
similar
status.
It
is
an
update,
is
being
prepared,
actually
half
ready.
Addressing
all
the
comments
we
got
to
be
able
to
move
on
towards
the
isd
blew
up
the
next
slide.
Please-
and
this
is
the
rest
of
our
working
group
drafts.
A
We
have
the
tsn
related
data
plane
drafts
that
have
that
are
post.
The
working
group
last
call
just
got
comments
on
them
from
blue
on
the
list,
and
the
next
step
is
to
address
the
comments
and
prepare
new
revisions,
as
I
mentioned
before,
the
main
topic
for
today
is
the
yang
draft.
We
will
read
that
more
in
detail
and
we
have
three
more
working
loop
drafts
that
are
not
on
the
agenda.
For
today
we
have
the
two
oem
drafts.
A
The
ipom
draft
have
has
been
recently
adopted
by
the
working
group
and
we
also
have
the
bounded
latency
draft.
These
are
being
updated.
I
we
got
some
information
from
the
authors
and
the
new
revisions,
for
example,
from
the
bonded
latency,
is
being
prepared
to
be
submitted
for
ietf,
109
and
next
slide.
Please
this
brings
to
its
109,
which
will
be
our
next
meeting,
so
we
have
requested
a
session
that
that's
for
the
networking
group
at
ietf109.
A
Please
update
your
drafts,
as
I
mentioned,
some
updates
are
ongoing.
That's
really
really
great.
Thank
you
for
that
and
if
you
would
like
to
give
a
presentation
at
the
session
in
the
that
networking
group,
please
email
us,
the
chairs
at
the
net
haven
chairs
idea
fork,
we
will
send
announcement
on
formal
assault
requests
after
the
session
is
scheduled.
I
mean
we
know
when
we
are
during
the
meeting
week.
A
C
A
C
D
Hi,
it's
don
here,
I'll
I'll
start
out
just
introduce
myself
and
I'll.
Let
the
other
editors
speak
first
and
then
I
I
think
I'm
going
to
drive
most
of
the
presentation,
but
if
the
other
editors
want
to
speak
up,
that's
fine
by
me
too.
So
I'm
done
fedex
with
laban.net.
I've
been
working
on
this
for
the
last
year.
D
B
Hi
this
is
josue.
Thank
you,
yanos.
Thank
you,
dan
for
your
introduction
and
the
young
model
has
been
up
has
been
worked
among
the
others
for
about
one
year
and
we
have
a
discussion
together
every
week
and
it
is
great
to
see
that
there
is
great
progress
in
this
work,
and
I
think
we
at
this
time
we
will
have
update
a
lot
of
new
things
during
the
I
think,
the
past
two
or
three
months.
What
we
have
done,
maybe
about
aggregation
and
some
other
update.
B
D
D
So
the
the
status
is,
we
merged
the
model.
So
when
we
started
out,
I
came
in
with
a
slightly
different
model
that
I,
based
purely
on
the
flow,
the
the
flow
model,
and
I
we
we
spent
several
meetings
merging
that
together,
we've
gone
through
terminology,
but
it
might
not
all
be
there.
Yet.
We've
still
got
a
little
bit
of
terminology
to
clean
up,
but
jane
generally,
as
we
merged,
we
tried
to
make
sure
it
made
sense.
D
We've
we've
gone
back
to
the
data
plane
drafts
a
few
times
to
make
sure
that
we're
matching
the
data
plane
drafts
and
we
do
need
to
include
the
reference
pointers
to
the
various
data
plane
drafts.
So
we've
been
working
with
the
model.
We've
been
working
with
the
drafts,
but
we
haven't
included
the
reference
pointers
in
there.
So
as
we
go
forward,
that's
one
one
piece
that
we
have
to
do
next
slide,
please
so
a
little
bit
of
the
history
of
the
the
the
things
here.
D
I'm
just
gonna
concentrate
on
the
last
two
versions,
so
we
merged
the
models
and
and
terminology
alignment,
and
then
we've
been
adding
aggregation
and
the
instance
models
by
the
instance
models
we've
been
using
yanglint
to
to
validate
the
models,
because
what
I
I've
personally
found
that
brings
clarity
to
the
model
for
me,
because
when
you
use
the
instance
data
on
the
model,
you
only
see
the
configuration
for
the
particular
scenario
that
you're
looking
at.
So
it's
a
little
bit
easier
to
see.
D
D
If
we
made
sure
that
everything
is
is
going
cleaner,
so
yanglint
is
another
hurdle
to
to
make
the
the
model
cleaner
and
also
the
id
knits
as
we
as
we
put
everything
into
the
draft,
the
the
draft
is
getting
cleaner
and
it
should
start
picking
up.
I
don't
I
don't
know
if
it
was
it.
I
didn't
check
to
see
if
it
actually
picked
up
the
model
from
the
draft,
but
we
had
some
issues
before
that
the
model
wasn't
being
picked
up
so
hopefully
that's
all
cleaned
up
next
chart.
D
So
this
is
just
a
recap:
diagram
we've
seen
this
before.
This
is
the
a
relationship
to
the
the
yang
model
and
the
the
various
drafts
that
are
out
there.
So,
on
the
left
side,
we've
got
the
various
data
formats
that
can
come
into
applications,
whether
it
be
ip
mpls
or
ethernet
data,
and
then
we've
got
the
various
components.
D
This
is
just
a
recap:
model
we've
gone
through
this
before,
so
it's
just
showing
things
that
have
come
from
the
the
float
that
flow
document
and
flow
information
model,
and
so
the
application
and
the
the
service
sub
layer
and
the
various
characteristics
that
are
are
in
there.
That's
the
various
attributes,
so
we
use
these
attributes
and
we
work
these
into
the
model
we
can
move
on.
D
So
now
it
can
be,
it's
still
optional.
At
several
layers,
it
typically
would
be
specified
at
the
service
sub-layer,
but
it
can
be
specified
at
all
layers
and
you
would
basically
have
a
profile
that
you
could
use
and
and
define
it,
and
then
you
could
actually
have
one
or
more
services
or
applications
sharing
the
profile.
So
if
it's
a
one-to-one
service
relationship,
you
could
share
the
same
profile
or
you
could
have
another
one.
So
we
thought
that
was
a
an
improvement
on
the
model
next
chart.
D
D
D
I
had
pulled
this
one
out
for
a
service
aggregation
group
as
a
separate
piece
in
the
tree,
and
but
I
I
didn't
want
to
replicate
everything
that
was
at
the
service
sub-layer.
So
it's
a
it's
a
service,
sub-layer
aggregation
model
in
particular.
This
one
is,
is,
is
showing
how
the
aggregation
label
for
mpls
could
be
used
and
how
it
relates
back
to
the
services.
D
But
there's
this
in
the
model
today,
there's
actually
two
two
versions
of
this
there's
one
that
young
chual
had
provided
that's
in
the
service
sub-layer
and
this
one
is
out
of
the
service
sub-layer.
So
if
and
I
I
provided
two
instance
data
to
try
to
illustrate
the
differences
in
those.
I
don't
know
whether
there's
a
big
difference,
because
I
think
they've
they
both
got
all
the
same
elements.
It's
it's
really
a
matter
of
seeing
if
anybody
can
pick
up
any
technical
reason
that
we
should
go.
D
Diagram
of
the
pieces
of
the
tree,
so
we've
taken
a
represented
piece
of
the
tree.
You
can
go
and
look
at
the
the
full
model,
but
we've
tried
to
show
how
how
the
various
pieces
fit
together
so
with
aggregation
and
and
the
and
the
color
coding
is
showing
what
we've
added
in
for
some
of
the
aggregation
pieces
now
there's
this.
This
also
illustrates
the
overlap:
that's
there.
So
we
have
the
the
service
type
if
it's
grouped
or
non-grouped.
D
If
it's
non-grouped,
it's
the
old,
it's
the
old
model,
the
one-to-one
model.
If
it
was
grouped,
then
it
would
have
an
aggregation
group
reference
to
the
previous
chart
we
saw
and
then
the
other
one
is
down
below.
Without
the
grouping
model,
we've
got
an
aggregated
service
in
the
service
sub-layer
and
the
aggregated
forwarding
piece,
the
one
piece
that
we
we
do
have
with
these
two
models.
D
D
As
easy
for
the
user
to
to
to
specify
this,
but
you
still
have
the
issue
with
the
upper
model:
there
is
no
pointer
to
the
forwarding
sub-layer,
so
the
the
aggregation
group
reference
relies
on
the
service.
Sub-Layer
forwarding
pointers
to
be
aligned
for
everything
in
the
group
and
it's
similar
for
the
other
model
too.
You
have
to
ensure
that
your
forwarding
is
aligned
or
not
specified
at
the
various
level,
so
it
picks
it
up
from
the
from
the
aggregation
piece.
D
So
that's
the
one
area
we
still
have
to
work
on
and
then
we've
got
as
we'll
go
through
the
charts.
We
will
also
see
that
there
may
be
some
some
types
of
aggregation,
we've
added
that
we
don't
need
we'd
like
because
at
a
certain
point,
it's
easier
just
to
start
another
detonate
service
and
aggregate
things
in
so
we
want
to
make
sure
that
we're
not
overly
complicating
the
model
by
adding
aggregation
types
in.
We
don't
need,
go
to
the
next
slide.
Please.
D
So
this
is
the
forwarding
sub-layer
piece
and
again
we've
we've
identified
the
the
the
pieces
in
here
now.
This
is
one
where
I
think
we
have
perhaps
a
bit
of
a
capability.
We
don't
need.
We
were
still
discussing
this
in
in
the
as
we
were
going
through
the
cases,
but
we
have
an
aggregation
that
the
forwarding
layer
that
maybe
is
not
not
needed
because
forwarding
the
forwarding
sub-layer
connect,
can
naturally
aggregate
services
because
you
can
use
that
forwarding
reference
multiple
times.
D
C
D
That's
always
been
supported
in
the
model,
because
you
could
that
we,
you
can
just
do
that
because
you're
putting
another
label
on
with
the
with
the
forwarding
layer
with
these
service
sub
layer,
you
needed
the
aggregation
label
to
to
be
added
in
there,
but
there
are
a
number
of
cases
that
that
will
go
through
and
it's
possible
that
I've
I've
missed
some
case
where
that
this
functionality
is
also
needed
at
the
forwarding
layer
at
another
place
in
in
the
diagram.
I'm
not
a
hundred
percent
sure
that
I've
ruled
out
everything.
D
D
D
D
D
So
this
is
the
case,
a
one
where
we're
aggregating
app
flows
into
a
service,
sub
layer
and
the
there's
in
the
in
the
various
documents.
There's
there's
kind
of
two
ways
we
can
do
this
so
one
way
is:
we
have
two
two
applications
and
we
we
just
basically
aggregate
we.
We
aggregate
them
basically
into
a
single
service,
sub
layer
and
again,
just
as
we
had
before
it's
it's,
it's
managed
the
data
plane,
just
as
it
was
with
the
normal
flow.
So
we've
got
aggregation
in
here.
D
The
detonate
flow
next
chart,
so
this
is
the
running
through
yang
lin,
the
instance
data
the
json
output
of
this.
So
this
just
shows
we're
using
the
the
data
dash
t.
Data
f.
Json
is
basically
saying,
take
this
data
and
apply
it
as
the
operational
schema
of
the
the
model
that
we've
got
so
we
we've
had
to
fill
in
some
information
about
the
interfaces,
so
we
just
use
a
a
set
of
interfaces
and
then,
on
the
right
hand,
side
we've
got
the
application
flow.
D
D
So
we've
set
up
some
traffic
profiles
here
we
just
filled
in
some
data
they're,
just
representative
traffic
profiles
of
you
know,
information
that
you
would
put
in
there
and
it
shows
the
the
member
applications
if
they're,
if
they're
using
the
same
profile,
we've
got
app
one
and
app
at
zero
using
the
same
traffic
profile
and
then
on
the
right
side.
There
we've
got
the
start
of
a
service
sub
layer
for
this,
so
we've
got
the
name
of
the
service
sub
layer.
D
D
D
D
So
I
I
believe
for
this
one:
we've
just
got
the
picture
that
shows
this.
We
do
have
some
data
for
the
the
next
one
with
the
aggregation
label,
because
that
was
one
of
the
pieces
that
was
new.
We
were
putting
in
so
in
this
one,
we're
just
showing
that
we've
got
two
two
sources
here
and
we're
showing
the
data
plane,
representation.
D
And
because
it
it's
it's
being
done
at
the
aggregated
at
the
forwarding
label,
what's
good,
let's
go
on
one
more
chart
and
see.
If
I
I
think
this
is
the
go
on
next
chart,
b1
yeah,
this
is
the
one
I
was
looking.
So
this
is
so
this
is
case
b1,
where
the
the
service
is
coming
in,
but
it's
being
aggregated
at
the
forwarding
label.
So
we
have
multiple
service
sub
layers
using
a
single
forwarding
label
that
was
supported
from
the
model
from
the
for
a
long
time.
D
So
in
this
case,
we
need
to
apply
at
the
service
layer.
The
aggregation
label,
which
is
shown
here,
is
the
a
label
and
when
you
compare
with
the
previous
chart,
the
the
only
difference
is
that
we
have
this
a
label
now
and
we're
we're
using
that
in
the
in
the
service
sub-layer
as
as
another
form
of
aggregation,
that's
supported
and
and
and
called
out
in
the
mpls
draft.
D
So
so,
as
I've
mentioned,
there's
currently
two
ways
to
achieve
the
aggregation
labels.
The
first
one
does
it
all
in
the
service
sub-layer
branch
and
creates
a
service
aggregation
label.
The
second
one
has
an
aggregation
label
for
grouping
the
service.
Sub-Layers
we've
just
got
to
clean
up
the
model
and
decide
which
way
to
do
it.
D
D
D
Okay
next
chart,
so
this
one
is
the
one
where
it's
just
organized
a
little
differently
and
we're
just
resolving
this.
We,
we
were
just
getting
to
the
point
in
the
discussions
where
we
were
seeing
this,
so
this
one
has
again
interfaces
and
then
the
applications,
the
only
reason
the
applications
have
a
few
more
attributes
in
here
than
the
previous
model,
but
there's
no
real.
No,
no
real
difference
at
this
layer
next
chart.
D
D
Then
we
have
the
service
services,
so
in
this
one
the
the
services
are
basically
the
same,
but
they
they
have
a
group
function.
They
say
that
they're
grouped
and
then
they're,
basically
the
same
as
they
were
in
the
individual
case,
trying
to
keep
that
as
as
consistent
as
pos
as
possible
with
the
one
before
so
we
have
two
services.
D
One
on
the
left
is
ssl
one
and
ssl
three
on
the
right
next
chart,
and
then
we
had
the
forwarding
sub
layer
so
we're
just
trying
to
resolve
which,
which
way
is
better,
and
it
may
be
just
that
that
six
of
one
half
a
dozen
of
another-
I
don't
know
if
there's
really
any
preference
right
now
we
haven't
discussed
in
the
group
which
way
to
go
yet,
but
if
anybody
has
any
input
on
that
we'd
appreciate
any
guidance
on
it
next
chart
is.
That
was
that
somebody
trying
to
say
something.
C
I
was
just
going
to
ask:
how
do
you
want
to
run
this
discussion?
Are
you
do?
Are
you
going
to
do
you
want
discussion
topic?
You
know
the
discussion
at
the
end.
Do
you
want
to
go,
have
take
questions
in
the
middle?
Well,
I
mean
it
sounds
like
this
is
an
opportunity
for
some
working
group
feedback
and
yeah.
B
C
D
D
Backwards,
really
it's
just
that
the
stop
right
here,
the
service
aggregation
aggregation
group
is,
is
pulled
out
of
this
service
sub-layer
and
it's
referring
to
it
and
the.
If
you
go
down
one
forward,
one
yeah,
the
the
each
service
is
referring
to
that
group
and
then
we'll
go
up
to
the
previous
model.
D
So
in
in
this
one
we
have
the
service
sub
layer
and
it
it's
it's
referring
to
the
aggregation
layers
so
very
similar
to
the
last
piece,
keep
going,
the
the
other
service
and
the
it's
referring
to
the
service
to
the
to
the
layer,
but
the
aggregation
is,
is
within
the
service
sub-layer.
So
it's
within
the
same
sort
of
tree
structure,
it's
down
below
it
and
it's
it's
essentially
essentially
the
same.
I
think
one
is
just
inside
the
the
service
tree
and
the
other
one
is
outside
not
not
a
big
difference.
E
Yeah,
not
a
question.
Maybe
a
comment
is
that
I
think
if
you
look
to
the
to
the
architecture
document
for
that
net,
that
we
have
defined
the
service,
sub
layer
and
the
forwarding
sub
layer,
so
aggregation
is
something
functional.
Aggregation
is
a
functionality
for
the
service
sub
layer.
So
having
that
component
inside
the
service,
sub
layer
seems
to
be
more
natural
for
me
than
than
defining
a
different
aggregation
sub
layer,
which
is
not
really
there
in
the
data
plane
documents
and
in
the
architectural
document.
F
C
So
I
just
added
myself
to
the
queue
I
think
we
support
aggregation
at
both
layers.
I
mean
look
at
mpls,
hierarchical
mpls
is
aggregation
and
sporting
layer,
so
I
think
allowing
for
both
of
them
makes
a
lot
of
sense
don.
You
asked
a
couple
of,
I
think
general
questions,
so
I'm
going
to
give
you
my
views
on
them.
I
think
examples
are
really
good.
So
you
know
example,
instance:
data,
I
think,
is
hugely
helpful.
C
I've
often
seen
it
as
an
appendix,
though
just
to
make
sure
to
make
it
clear
that
it's
non-normative
right.
That's
a
that's
a
style
point
I
think
having
the
data
is
hugely
helpful
to
implementation.
So
I
that
you
know,
if
you're
going
through
the
trouble
of
generating
examples,
I
think
put
them
into
the
document.
Making
sure
they're
right
is
is
really
helpful.
C
The
other
thing
is,
I,
you
know
as
much
as
you
can
do
to
reduce,
where
the
number
of
elements
that
you
have
to
the
number
of
nodes
that
have
to
change
in
order
to
when
configuration
change.
That's
you
know,
that's
always
a
good
design
principle
right.
So
you
know
if
there's
one
model
has
requires
more
to
make
a
change
or
to
instantiate
a
service
versus
the
other.
You
know
from
my
standpoint,
less
is
less
is
more.
C
On
that
same
theme,
it
seems
to
me
that
you
could
model
aggregation
as
just
a
in
the
outgoing
list
rather
than
introducing
a
whole
new
service
element,
for
example
in
mpls,
where
you
need
an
extra
label
that
could
just
be
modeled
as
a
new
app
flow.
So
you
could
have
one
one
service
whose
output
is
another
service
and
thereby
get
an
s
label,
and
then
the
a
label,
one
of
the
nice
things
there
is,
is
for
implementations
that
support
it.
C
You
could
do
pre-off
at
either
one
of
those
levels
based
on
again
what
the
hardware
supports.
You
know
I
don't
expect
nested,
but
you
know
who
knows.
Maybe
someone
will
build
a
really
fancy
piece
of
hardware
that
doesn't
so
you
know
I
did
you
guys
think
about
just
doing
it
without
adding
an
extra
aggregation
component
and
just
by
basically
chaining
surfaces
or
chaining,
forwarding,
sub-layers
and
I'll.
C
D
So
the
when,
when
you
looked
at
the
when
you
look
at
the
the
individual
model
with
its
the
service
and
the
forwarding
sub-layer,
and
then
you
you
try
to
do
aggregation
within
that,
you
you
have
you,
you
then
have
some
some
some
change.
I
think
the
the
second
model,
the
one
that
we're
looking
at
here,
is
trying
to
address
that
because
it
has
the
the
forwarding
sub
layer
all
in
line.
So
I
think
I
think
it
goes
towards
that
model.
D
You
know
whether
it
was
aggregated
or
not,
aggregated
the
same
to
see
to
see
if
you
know
it
kept
it
any
cleaner.
Looking
at
it
this
way,
I
think
this
one
is
probably
as
good
and
then
it
keeps
the
three
the
three
levels
in
it.
I
didn't
want
to
create
another
layer.
The
the
the
other
point
is
that
when
you're
configuring
this
way,
you
don't
have
to
specify
you
don't
have
to
specify
it
it
can
completely
down
to.
D
How
can
I
put
this
there's
some
there's
some
things
that
once
you've
got
the
pointer
to
the
aggregation
group
and
stuff
like
that,
you
don't
have
to
fill
in
all
the
other
details,
so
the
if
we
can,
if
we
can
simplify
the
configuration
that
way
by
saying.
Well,
you
don't
have
an
outgoing
list,
and-
and
this
one
may
do
that,
I
I'm
looking
at
it.
I
think
it
it
does
achieve
that.
D
So
I
I
think
that
this
is
the
way
to
go
with
it
inside
the
the
service
sub
layer
and
we
have
this
aggregate
disaggregation
label.
I
think
your
other
question
was:
could
we
do
this
without
even
putting
an
aggregation
just
having
the
the
label
specified,
because
we
we
do
have
a
label
stack
and
we
could
just
say
the
there's,
there's
the
service,
sub-layer
labels
and
then
there's
the
aggregation
label
as
part
of
the
label
stack
in
in
inside
of
there.
D
C
D
C
D
D
D
D
However,
a
lot
of
the
terminology
here
talks
about
a
relay
node.
What
you
do
at
a
relay
node.
I
I
always
read
that
as
a
relay
function,
but
I
don't
know
if
there's
guidance
from
the
work
group
of
which
way
we
should
do
this.
We
I
don't
view
it
as
a
a
monolithic
node,
but
perhaps
I'm
wrong
on
that.
Is
there
any
comment
on
that.
C
D
Asking
I'm
I'm
asking
whether
the
term
relay
node
seems
to
be
implying
that
it
is
a
monolithic
node.
I
I
haven't
been
that
precise
on
it,
but
I
realized
that
we
were
talking
about
it
that
way,
and
I
and
I
would
prefer
a
relay
function.
You
know,
because,
because
it's
behaving
for
this
particular
debt
net
flow
as
a
relay
function
in
that
node,
as
opposed
to
a
a
you
know,
a
relay
node,
but
I
I'm
willing
to
go
with
whatever
the
terminology
is
that
the
the
groups
decides
shoe.
Song
is
in
cube.
B
D
C
D
So
anyways,
so
these
are
the
cases
that
were
were
proposed
for
this.
So
we
have
multiple
forwarding.
Sub-Layers
are
aggregated
into
a
forwarding.
Sub-Layer
multiple
service,
sub-layers
of
detonate
flows
are
aggregated
into
forwarding.
Sub-Layer
multiple
service,
sub-layers
of
detonate
flows,
are
aggregated
into
a
service
sub-layer
with
the
new
aggregated.net
flow
and
multiple
forwarding
sub-layers
of
detonate
flows.
D
D
D
D
D
D
D
C
D
E
E
C
D
Service
sub
layer
with
the
aggregated
layer,
I
I'm
not
sure
why
this
oh.
This
is
because
it's
at
a
relay
node,
so
so
this
is
the
the
difference
that
I
was
trying
to
get
at
with
the
relay
node.
So
we
did
it
before
the
difference
between
the
b
case
was
that
it
was
at
the
ingress,
node
doing
the
a
label,
and
now
this
is
doing
this
at
the
relay.
D
C
C
E
D
D
D
D
D
Flows,
I
think
this
was
the
one
that
I
I
questioned
again
if
we
did
what's
the
difference
between
this
and
just
saying
that
we
have
another
debt
net
service
in
the
middle
of
the
network
and
everything's
transparent
to
that
detonate
service.
As
far
as
the
that
outer
label
goes
at
what
point
do
we
say
you
know.