►
From YouTube: IETF99-DETNET-20170720-0930
Description
DETNET meeting session at IETF99
2017/07/20 0930
https://datatracker.ietf.org/meeting/99/proceedings/
A
Before
I
really
get
started,
I
want
to
remind
people,
we're
gonna,
be
using
etherpad
to
take
notes
and
we
invite
you
to
join.
Unfortunately,
I
don't
have
a
link
on
the
screen.
The
easiest
way
to
get
there
is
to
go
to
tools
that
I
ETH
org,
slash,
WG,
/
debt
net
and
click
under
minutes
and
you'll
find
that
there's
a
etherpad
99,
so
tools,
ietf
dot
org
is
the
easiest
way
to
get
them
get
to
that
for
agenda
information
slides.
You
can
also
find
out
the
usual
data
tracker,
location.
A
Where
later
in
the
week,
so
you
should
be
familiar
with
the
note
well,
hopefully,
people
have
pointed
out
that
this
note
well
is
subtly
different
from
the
old
note.
Well,
the
major
difference
is
we
have
a
new
RFC
guiding
IPR
disclosures
as
usual.
If
you
contribute
to
an
activity
in
the
ITF
and
you're
you're
aware
of
IPR,
you
are
obligated
to
disclose
that
IPR.
If
you're
unwilling
to
disclose
that
I
PR,
you
cannot
contribute.
A
Here's
the
long
form
pointer
to
etherpad
again,
the
short
form,
is
off
of
tools
that
ietf
dot-org.
We
our
audio
streaming
and
using
the
echo
there
are
people
remote
also
to
help
the
note
takers.
Please
remember
to
state
your
name
when
you
come
to
the
mic,
we're
up
to
five
people
on
etherpad,
that's
great,
but
please
others
join
in
it's
a
great
place
to
verify
that
your
comments
were
appropriately
captured
or
to
help
the
group
out
to
make
sure
we
appropriately
capture
the
discussion.
A
Blue
sheets
should
be
circulating
now,
as
usual,
with
your
name
on
there.
We
have
seven
topics
on
the
agenda.
The
main
focus
today
is
really
going
to
be
on
data
plane
both
on
encapsulation
and
gaining
the
discussion
on
service
semantics
and
traffic
treatment
parameters
to
help
us
with
that
discussion.
We're
going
to
end
the
session
with
some
information
from
the
802
dot,
1
TSN
active
participants,
and
they
will
focus
on
what's
happening
there
in
the
area
of
trap,
treatment
and
queuing
and
service
parameters,
as
well
as
some
other
general
information.
A
A
A
Cases
are
re
raised
in
subtly
different
ways
and
by
keeping
the
document
around
an
active,
it
allows
us
to
tweak
it
as
needed,
but
at
some
point
we
have
to
decide
that
it's
time
to
ship
it
frankly
it
doesn't
define
a
technology.
So
it's
a
little
less
important
to
get
that
one
completed
and
let
it
once
we
find
that
we
don't
haven't
revved
it
in
a
little
while
we'll
say
that
it's
done
and
push
it
out.
A
We
have
a
couple
of
expired
documents.
We
have
the
alternatives
which
were
really
helpful
to
get
us
through
the
solution
document
we're
going
to
be
talking
about
whether
that's
published
as
an
RFC
or
not.
That's
not
so
critical,
as
we
discussed
last
time,
but
the
problem
statement
that's
worthwhile
to
to
publish
now
that
we're
we
have
an
architecture
document
that
seems
to
be
close
to
ready.
A
We
are
going
to
be
talking
about
three
of
them
today,
the
fourth
we've
yet
to
receive
proposals
on
it's,
okay,
that
we
haven't
received
that
because
it's
to
some
degree
it's
blocked
by
the
information
model.
One
of
the
things
to
consider
for
the
working
group
is
if
including
the
service
definition
and
traffic
treatment
parameters
in
the
info
document
is
the
right
place
for
that.
Our
plan
right
now
is
to
have
that
bundled
in,
but
we've
been
hearing
that
people
haven't
have
been
missing.
A
The
fact
that
there
is
a
debt
net
or
we're
expecting
to
have
a
debt
that
service
definition,
and
perhaps
if
we
break
that
out
into
a
separate
document
that
might
help
people
on
on
that.
That's
just
something
to
consider
it's
a
document,
reorganization.
It
shouldn't
speed
anything
up.
It
shouldn't
slow
anything
down
by
doing
that,
but
it
would
just
help
for
the
visibility
and
readability.
So
that's
something
for
the
working
group
and
the
authors
to
consider
as
we
move
forward,
we
do
have
a
security
document.
B
C
B
D
That's
easier
to
look
at
so
summary
of
the
changes
from
draft
one
to
draft
that's
from
March
to
June
the
biggest
change
when
you
look
at
the
diff
is
a
bunch
of
stuff
has
moved
around
to
organize
it
better,
so
it
made
better
reading.
We
added
a
few
smaller
chunks,
a
bit
about
data
plane
overview,
there's
a
bit
about
the
difference
between
the
different
kinds
of
nodes,
explaining
that
further
that
we
have
edge
relay
in
transit
nodes,
and
we
added
a
section
about
packet
encoding
for
service
protection,
which
is
interesting.
D
D
Now,
where
are
we
now?
This
diagram
is
from
the
architecture.
It
shows
one
of
the
major
use
cases
which,
where
we
have
a
TSN
n
system,
going
into
an
edge
node
through
a
transit
network
and
out
to
an
end
system
on
the
other
side,
and
it
shows
where
the
sub
networks
are
where
direct
links
are.
It
gives
a
pretty
good,
a
pretty
general
use
case
for
what
we're
trying
to
accomplish
with
debt
net,
which
is
the
zero
congestion
loss
and
the
extremely
low
packet
loss.
D
D
Description
of
all
of
the
pieces,
all
of
the
boxes
that
are
part
of
the
system,
we
have
the
description
of
the
flows.
What
they
look
like,
we
have
the
how
we
managed
to
do
the
traffic
engineering
to
get
the
quality
of
service.
We
have
the
queueing
shaping
and
preemption.
We
have
the
low-level
mechanisms
that
we
need
to
actually
deliver
the
service
that
we're
trying
to
get
and
those
low-level
mechanisms
are
important.
D
D
D
They
were
placeholders
for
ideas
that
people
had
and
I
think
they've
been
overtaken
by
events.
So
the
proposal
when
I
say
the
design
team,
the
people
working
on
this,
the
authors
of
the
drafts
that
I
know
of
we
don't
anticipate
any
significant
changes.
So
we
suggest
that
we
remove
section
five
to
the
placeholder
for
ideas
that
didn't
mature
and
that
it's
time
for
a
working
group
last
call
on
this
document.
D
E
Basically,
we're
here
Cisco
just
a
point
on
the
wireless
piece:
it's
not
that
we
are
not
working
on
it.
It's
not
that
we
don't
want
to
advertise
the
work,
it's
more
like
it's
less
mature.
So
if
there
was
a
placeholder
for
a
specific
you
know,
more
experimental
work
on
wellness
be
very
happy
to
contribute
to
that.
But
it's
not
at
the
same
level.
Then
these
documents-
it
could
not
be
long
there
it's
much
much
more.
We
are.
A
A
A
Call
if
you
do
see
that
in
particular,
some
of
the
removed
text
highlighted
initially
wanted
to
be
addressed,
or
that
you
read
the
document
you
see.
There's
something
you'd
like
to
see
address.
Please
not
only
identify
the
area
you'd
like
to
see
filled
but
proposed
text.
This
is
a
working
group
document.
Anyone
can
contribute
to
it.
If
you
want
to
see
an
issue
addressed
and
have
a
specific
idea,
how
to
do
it
send
the
text
of
the
list?
Thank
you.
F
G
G
B
G
G
Next
one
there's
no
change
on
the
design
team
membership,
except
that
the
we
had
the
increasing
participation
from
the
chair
side,
but
we
didn't
list
them
as
a
members
of
the
design
team
anyway,
next
slide,
okay,
so,
as
usual,
the
working
mode
has
been
the
weekly
calls
and
the
the
discussion
and
the
meeting
means
have
always
been
posted
on
the
net
design
and
a
top
end
design
team
mailing
this.
So
you
can
actually
go
and
check
those
because
of
the
vailable
just
to
research
or
walk
into
our
archive
next
one
right.
So.
G
Continuing
a
bit
slightly
from
the
normal
left
off,
so
the
current
that
date,
the
plane
and
document
covers
couple
of
use
cases
and
this
kind
of
half
island
interconnect
where
you
actually
transport
a
TSN
service
over
death
map
is
one
of
the
easy
ones
and
the
loved
main
was
what
we
have
defined.
So
we
have
the
end
system
that
initiate
and
terminate
802
the
20s
in
traffic,
and
we
have
its
knows
that
actually
encapsulate
that
into
a
definite
data.
Plane
within
this
case
is
a
pseudo
wires
with
MPLS
PSN.
G
G
Slightly
similar,
except
tenth,
the
multi
end
system
are
also
dead
net
fear,
so
an
entity
system
can
also
initiate
and
terminate
through
the
wires
in
this
case.
Otherwise
it's
very
much
the
same
as
the
previous
one
and
then
the
next
slide,
and
then
we
have
the
native
ipv6
based
in
that
use
case.
So,
which
basically
is,
is
that
the
didn't
it
in
systems?
They
don't?
G
G
Obvious
another
question
comes
up
that
we
have
two
different
encapsulations.
So
what
might
come
up
is
that
we
need
to
think
about
mixing
to
use
caching
so
containing
the
TSN
overlay
at
night
and
and
the
like,
empty
and
pseudo
wire
place
native
date
net.
That
is
rather
straightforward
in
the
sense
that
the
the
Inca
presence
always
the
same.
G
However,
what
we
still
need
to
pay
a
bit
more
attention
to
is
how
to
do
the
interruption
function
in
the
it's
not
and
that
part
is
still
kind
of
bit
under
the
work
and
then
how
about
do
India,
pseudo
oil-based
and
on
the
ipv6
use
cases
that
we
we
know
that
it
we
might
face
it,
but
we
actually
haven't
spent
too
much
time
on
working
on
the
details.
What
that
actually
entails.
G
So
the
solution-
basics,
so
we
had
the
pseudo
wires
and
I
PV
SATA
data
plane
solutions,
as
you
usually
and
stated
multiple
times
previously.
We
do
not
try
to
invent
new
stuff,
so
hopefully
what
we
design
we
can
apply,
also
the
existing
control
page
with
the
small
tweaks
and
also
the
central
controller
model
and
the
especi.
We
want
to
have
that.
The
Delta
from
the
existing
deployed
software
and
the
hardware
would
be
a
as
minimal
as
possible
that
actually
kept
our
invention
level
quite
loud
right
next
slide.
G
So
the
things
that
we
actually
spend
a
lot
of
time
is
the
we
were
thinking
about
having
a
unified
encapsulation
for
all
types
of
traffic.
But
we
didn't
kind
of
succeed
in
that.
So
the
end
result
is
that
the
current
draft
has
two
encapsulation:
one
is
the
native
ip6
type
of
source
and
the
other
one
is
the
MP
MPLS
through
the
wires.
G
G
H
G
H
Bryant
I'm
very
regrettable
that
we
can't
have
some
more
unified
way
of
dealing
with
both
IP
and
mpls
solutions,
particularly
as
I
think
to
get
the
best
out
of
this
we're
going
to
have
to
make
changes
to
the
underlay
in
order
to
actually
extract
them
at
most
performance.
It'd
be
kind
of
nice.
To
only
do
that,
once
it's.
A
H
G
On
that,
because
the
I,
just
he
or
Lou
or
Stewart
Stewart,
so
we
assumed
T
a
certain
way
of
of
the
way
of
doing
the
encapsulation,
because
we
knew
that
there's
our
support
for
that.
That
doesn't
mean
it
has
been
deployed,
but
the
axis
of
the
hardware
was
around
sir
I
didn't
quite
understand
salted.
So
last
time
we
got
some
some
feedback
that
the
way
that
we
design
certain
encapsulation
is
no
coke,
because
no
one
has
done
it
that
way.
G
H
A
Are
definitely
trade-offs
here.
I
personally
am
sad
to
see
a
single,
a
single
encapsulation
for
both
MPLS
and
IP
I'm,
sad
to
see
that
go
away,
but,
on
the
other
hand,
going
straight
to
to
IP
without
introducing
pseudo
wires,
make
stacks
that
the
end
station
implementation,
a
little
oil,
would
be
easier,
so
I
think
there's
trade-offs
here.
The
and
I
agree
completely
with
Stewart,
with
your
comment
that
the
working
group
really
has
to
consider.
A
These
I
would
say
that
it's
appropriate
for
them
to
consider
it
once
this
is
a
working
group
document
and
the
working
group
owns
the
product
right
now,
it's
just
an
individual
document.
So
it's
it's
the
opinion
of
the
authors,
so
I
look
forward
to
it
being
one
a
working
group
document
and
to
really
hash
down
by
the
full
membership
and
all
those
who
may
have
data
planes
that
will
be
impacted
by
this
I.
A
D
Just
wanted
this
is
norm.
Finn
I
wanted
to
emphasize
that
a
lot
of
the
focus
on
the
data
plane.
Documents
has
been
around
getting
the
serial
number
serial,
as
the
sequence
number,
defining
an
encapsulation
to
hold
a
sequence
number,
which
is
necessary
for
the
packet
replication
and
elimination
feature.
It's
not
necessary
for
the
hard
partitioning
aspect
of
debt
net,
which
is
the
getting
the
zero
congestion,
Lawson
and
fixed
latency,
does
not
need
the
serialization
and
is
perhaps
a
lot
more
flexible
as
to
what
encapsulation
you're
using
and
that
may
it's
not
all.
D
H
Stuart
again,
I
see
the
serial
number
things
being
one
of
the
single
hardest
problems
to
solve
at
scale.
You
can
solve
it,
providing
you
I,
prepared
to
only
have
enough
minor
number,
but
I
see
it
be,
quite
if
you
would
at
scale
and
I
suppose.
One
of
the
hard
questions
serious
question
to
ask
is
how
important
is
that
aspect
of
the
design
versus
having
a
design
that
works
most
of
the
time
for
most
applications
in
a
simpler
way.
I.
A
Think
what
I
heard
I
see
both
on
the
slide
and
I
heard
from
norm
Stewart
is
that
those
are
separable
problems
that
one
one
piece
is
the
protection
part
the
serialization,
that's
the
the
last
major
bullet
inseparable
part
is
the
flow
identification
and
you
can
and
you
can
solve
them
independently
and
then
combine
them.
So
it's
two
building
blocks
that
are
combined.
I
G
I
I
G
Then
Stewart:
well,
we
have
a
certain
set
of
assumptions
and
the
we
hold
in
to
those.
So
yes,
we
do
assume
that
we
have
a
controller
and
if
the
existing
hardware
doesn't
super8
I
would
say
tough
luck,
because
anyway,
we
have
certain
assumption
on
top
of
the
existing
pseudo
wire.
So
I
would
imagine
that
if
you
want
a
device
sort
of
are
enabled
device
to
be
owes
a
debt
net
capable
you
just
don't
find
that
kind
of
device
off
the
shelf.
G
G
A
A
So
so,
whether
you
use
control
word
or
not
it
if
you're
not
supporting
the
protection
function,
you
don't
need
this
serialization
ID
and
you
will
meet
in
order
to
do
if
you're
doing
new
hardware
to
support
a
new
function.
The
protection
you
might
have
to
support
the
serialization
so
I.
Your
statement
of
old
hardware
does
support
serialization.
It's
like
yeah,
you're
right,
but
then
you're
not
gonna,
be
able
to
support
the
new
function.
F
F
Yes,
there's
some
hardware
that
doesn't
support
control
word,
but
we've
been
talking
a
great
deal
about
the
importance
of
supporting
control
word
in
general,
because
there
are
addresses
that
start
with
four
and
six
and
without
control
word
you
can't
distinguish
between
Ethernet
and
IP,
v4
and
v6.
So
the
control
word
is
definitely
the
way
that
things
should
be
moving.
The.
H
Record
straight
so
situation
is:
there
was
old
hardware
that
didn't
support
the
control
word
because
it
couldn't.
We
think
all
new
hardware
can
support
the
control
word.
Technically.
You
can
support
the
serial
on
the
the
sequence
number,
but
it's
optional
and
I
don't
think
anyone
ever
has
supported
it,
so
it
would
be
a
new
implement
of
practical,
practical
purposes,
a
new
implementation
that
is
needed.
We
are
planning
to
move
to
a
world
where
we
are
very
strongly
encouraging
people
to
put
the
control
word
in
for
a
number
of
reasons,
including
the
ones
that
have
referenced.
H
F
And
I'm
gonna
there's
one
other
point
I
wanted
to
make
which,
which
is
that
we
have
use
cases
that
require
the
replication
and
redundancy
that
that
has
been
part
of
what
is
included
in
debt
net
from
the
beginning
and
I.
Don't
see
how
you
do
that
without
a
serial
number.
So
now
not
every
use
requires
that
feature,
but
but
we
certainly
have
to
provide
for
that
feature
in
what
we
define
in
the
data
plane.
This.
D
Is
this
is
in
place
norm
Finn?
This
is
a
tempest
in
a
teapot.
In
a
sense,
the
goal
of
debt
net
is
not
to
support
all
forms
of
pseudo
wires.
The
goal
of
debt
net
is
to
do
packet.
Rep
one
of
the
techniques
in
define
in
debt
net
is
the
packet,
replication
and
elimination
for
that
we
need
a
serial
number
and
pseudo
wires
were
a
handy
place
to
find
serial
numbers,
so
we're
employing
them.
The
fact
that
you
don't
do
some
implementations,
don't
do
serial
numbers
simply
means
okay.
A
And
I
think
norm
brings
up.
A
good
point
is,
is
that
our
objective
here
is
the
function?
Pseudo
wires
is
the
way
we're
using
it
is
that
is
being
proposed
if
once
this
is
adopted
as
a
working
group
activity
or
approved
document,
if
the
worker
group
decides
they
want
to
use
a
different
encapsulation
but
say
one
that
matches
what's
used
in
evpn,
for
example,
that
would
be
a
fine
choice
for
the
working
group,
and
then
we
wouldn't
be
talking
about
pseudo
wires
anymore.
A
J
Ensure
so
evpn
so
first,
all
the
drop
is
referring
7432,
which
is
incorrect.
The
EVP
and
RFC
defines
multiple
answers,
so
you
need
to
reference
the
bbws
draft,
which
is
standard
truck
with
SG,
which
has
some
of
different
procedures
to
set
up
the
CID
or
number
two
and
vector
control
world
in
the
PWS
draft.
The
control
worth
is
not
mandatory
is
optional
and
mostly
used
when
there
is
no
interview
label,
so
you
might
consider
to
introduce
new
requirements
with
regard
to
EDP
and
to
make
control
or
signal
mandatory
if
used
for
that
net.
If.
A
D
C
C
So,
in
any
way
go
beyond
control.
Word
control
word
for
this
functionality
is
a
perfectly
fine.
That's
because
pals
is
gonna.
Have
a
very
strong
statement.
There's
been
a
lot
of
problems
identified
without,
if
you
don't
support
for
the
older
equipment
on
supporting
control,
words
are
going
forward.
Equipment
supports
control
word
so,
for
you
guys
definitely
for
this
new
functionality.
C
A
A
Debra
brings
up
a
really
good
point.
Is
we
have
no
other
contribution
proposing
anything
for
a
dead
net
data
plane?
So
we
have
one
document
as
a
foundation
of
the
work
of
the
working
group,
its
individual
right.
Now
we're
really
getting
to
the
point
where
we're
hashing
out
what
the
working
group
thinks
is
the
right
answer.
You
should.
G
Be
doing
that
on
a
working
document
and
from
the
19
point
of
view,
we
don't
really
want
to
progress
this
work
anymore
as
a
design
team.
So
that's
one
of
the
things
in
the
last
light
is
like.
Okay,
we
have
done
our
work
now,
let's
move
on
the
the
a
doctrine
phase
and
see
what
the
weather
is
actually
serves
as
a
basis
for
the
further
work.
A
I
Greg
nurse
duty
that
actually
was
what
I
wanted
chairs
to
clarify,
because
my
understanding
that
one
of
the
questions
that
we
answer
in
the
working
group
adoption
that
we
agree
that
with
a
proposed
technical
solution
as
a
basis
for
the
final
solution.
So
if
we
think
that
the
pseudo
wire
is
not
the
right
technical
solution
than
what
I
was
saying,.
A
K
A
H
That's
not
always
being
quite
sort
of
clear
I
think
the
most
important
thing
is
that
we
have
open
conversation
about
the
the
design.
I.
Don't
think,
it's
necessarily
ready
for
working
group
adoption
for
the
reasons
that
Greg
just
mentioned,
but
I
think
we
need
to
get
have
an
open
discussion
rather
than
continuous
closed
meetings
with
reporting.
A
So,
just
for
everyone's
information,
the
design
team
list
archives
are
available
to
anyone
who
would
like
to
peruse
them.
The
you're
also
welcome
to
discuss
any
any
document,
whether
individual
or
working
group
on
the
mailing
list.
We
had
it.
We
had
a
slide
earlier
about
using
the
mailing
list.
If
you
have
a
comment,
send
it
to
the
list
so
in.
B
A
B
Craig
in
response
to
you
earlier
comment
in
most
of
the
working
groups,
once
a
design
team
was
then
appointed,
it's
almost
worthless
effort
try
to
come
up
with
an
alternative
draft,
because
usually
people
will
say
you're,
not
the
design
team.
Why
don't
you
talk
to
these
people?
They
don't
they
don't
want
to
see
alternate
addressed
generally
the
most
workgroups,
but.
A
There's
always
an
opportunity
that,
if
you
don't
agree
with
the
direction
of
the
design
team
that
you
produce
an
individual
and
that
gets
discussed,
and
sometimes
that
even
gets
either
integrated
in
the
final
work
of
the
design
team
or
it
gets
integrated
into
the
work
of
the
working
group.
I'm
sure
both
of
us
have
done
just
that
in
the
past.
That,
yes.
A
A
L
Share
them,
the
very
broad
Scott
I,
think
yeah.
If
the
objection
for
pseudo
are,
is
that
the
control
word?
It's
not
used,
I
mean
RFC
for
for,
for
it
is
the
pseudo
RFC
and
it
has
control
work
and
now
the
you
know
the
issue
that
who
has
implemented
and
who
has
not
as
another
issue.
But
the
question
is
I
mean
the
objective
is
minimum
change
in
standard,
so
the
standard
already
exists,
you're
gonna
be
reuse,
it
I
mean
you
have
implemented
again,
but
we
don't
need
to
create
a
new
standard
for
it.
A
G
This
access,
the
selling
the
existing
capsulation
so
I,
don't
think
I'm
going
to
spend
time
on
too
much
on
those.
Are
we
so
this
is
the
MPLS
one.
So
we
have
the
mandatory
tenets
controller.
That
sole
purpose
is
carrying
the
sequence
number
and
then
we
had
the
suit
of
a
label
at
his
fault
if
Florida
fication
and
then
we
have
a
bunch
of
other
labels
that
we
invented
funny
names
and
they
just
are
I
know
they
are
slightly
confusing,
but
just
consider
them
as
a
normal
label
stack.
You
have
hope,
I
hope
they
put.
G
A
G
H
Okay,
good,
actually,
you
get
a
hope.
You
get
a
few
other
things.
Besides
the
sequence
number,
with
the
control
word
you
get
disambiguation
with
I
after
which
is
pretty
important.
You
get
a
whole
cook,
you
get
a
whole
load
of
OAM
and,
of
course,
if
you
base
it
on
pseudo,
while
you
pick
up
a
whole
load
of
control
infrastructure
that
helps
you.
So
it's
really
quite
a
good
platform
to
build
and
we'll
save
a
whole
bunch
of
other
work.
H
A
K
The
opinions
being
stated
in
there,
okay,
Andy
malice
I,
just
as
with
my
pals
co-chair
hat
on
I,
just
wanted
to
say
that
I
quit
completely
with
my
co-chair
here.
You
know
we're
in
in
the
midst
of
making
the
the
control
word
mandatory
for
Ethernet
pseudo
wires
and
the
pals
working
group.
It
should
be
mandatory
for
this
work
as
well.
Okay,.
I
Okay,
yeah
want
to
explain
why
do
you
need
a
control
work,
because
your
transit
nodes
that
might
have
doing
hashing
on
a
payload
need
to
somehow
parse
the
payload?
So
if
you
don't
have
a
control
word
after
pseudo
wire
label,
they
can
parse
is
something
that
it
is
not,
and
then
it
will
go
unpredictably.
Okay,
so
and
basically,
you
will
have
out
of
order
delivery.
So.
G
Next,
what
and
this
solves
the
same
thing
in
ipv6,
so,
yes,
we
do
overload
the
earth
low
level
or
use
actually
how
it's
supposed
to
be
used
and
then
placing
the
sequence
number.
We
meant
for
a
destination
option
that
that
carries
the
sequence
number
and
if
you
go
for
a
next
slide,
it's
all
sex
with
the
D
formats,
so
the
the
RFC
for
4
for
8
is
used
for
the,
as
is
for
the
MPLS
pseudo
wires
and
ipv6
uses
the
destination
option.
G
G
Next
one,
and
then
the
the
graph
that
we
came
up
has
a
lot
of
other
con
data
plate
consideration
and
we
have
a
bunch
of
tech,
support,
a
class
of
service
water
service
and
cross
10
network
resource
pack
vacation
so
not
going
to
for
the
sake
of
time
at
Quantico
in
two
tildes,
you
can
read
them
from
the
draft,
but
the
punch
of
good
information,
something
that
we
actually
paid
some
attention.
Thinking
about
those
the
next
one.
A
D
J
A
I
L
I
A
I
I
D
It's
laid
out
pretty
clearly
I,
think
in
the
architecture
document
and
in
the
architecture
draft
and
in
the
data
plane
draft
and
the
old
data
plane
alternatives
draft
that
the
youth's
case,
one
use
case
is
to
connect
to
TSN
domains,
but
that
also
implies
those
two
domains
have
layer.
Two
connectivity
and
one
of
the
fundamental
limitations
on
TSN
today,
is
the
limitations
of
a
bridge
network.
Even
a
bridge
network
that
has
tunnels
between
its
various
parts
bridge
network
can
only
get
so
big
and
it
just
doesn't
work
anymore.
D
G
N
Hello,
this
is
Alexandra
Petrescu,
hello,
uni.
With
respect
to
this
ipv6
TSN
discussion.
There
is
a
particular
need
of
connecting
a
TSN
link
to
a
later
2.11
link
if
these
flows
could
be
extended
or
guarantee
to
every
sort
of
quality
of
service
guaranteed
between
those
two
links.
Tsm
and
Wi-Fi,
yeah.
A
D
A
G
Have
yes,
so
you
can
always
go
and
read
this
stuff.
What
we
have
from
the
draft
questions
until
he
finishes
this
next
few
slides
and
so
I'm
going
to
spend
anything
on
this.
So
just
one
thing
that
we
haven't
really
conjured
at
all
or
I
mean
there's
no
proper
text
is
the
interval
in
between
you.
Should've
warned
ipv6
base
encapsulation,
so
we
have
a
placeholder
for
it,
but
villians
really
contribute
a
complete
that
so
that
is
pretty
much
left
open.
How
to
do
that.
G
The
next
one?
Okay,
we
have
a
bunch
of
consideration
about
time,
synchronization
a
whole
section
about
it.
So
if
you're
interesting
about
concentration
in
intended
domain,
just
go
and
read
section
next,
one
tons
of
open
issues,
so
these
are
the
open
issues
that
the
design
team
came
up
with
what
we
have
so
the
I
said:
the
interworking
between
implement
pv6
domains.
A
G
Assumes
that
the
data
plane
below
is
basically
point-to-point
transport
connections,
but
if
you
have
a
multicast
tested
flows,
how
that
should
be
done
that
that
part
needs
a
bit
more
thinking,
a
bit
more
clarification
in
its
details,
the
relay
and
it's
not
processing
for
the
native
ipv6.
So
originally,
because
this
whole
thing
was
on
M
pseudo
wire
based
existing
text.
It's
pretty
much
geared
towards
how
the
all
the
sections
through
the
wires
work,
so
that
has
to
be
changed
to
also
take
care.
G
G
So
next
steps,
so
even
if
there's
two
things
that
that
seem
to
steer
a
lot
of
discussion
and
opinions
and
the
weather,
the
choices
that
we've
made
are
appropriate
and
so
on.
So
the
design
team,
the
team
things
that
we
already
did
our
work
along
ago.
So
you
really
want
to
kind
of
expand
the
discussion,
the
rest
of
the
working
group
in
a
proper
way
and
don't
want
to
kind
of
progress.
G
The
work
in
closed
meetings
anymore,
so
one
way
of
going
forward
is,
is
to
make
a
call
for
adoption
for
as
working
for
item,
then
everybody
has
their
chance
to
kind
of
steer
the
document
in
the
proper
direction.
So
do
you
think
this
is
a
good
basis,
it's
far
from
being
complete,
but
the
plenty
of
work
to
do
part
to
do
something
things
that
there's
athlete
at
least
a
solid
basis
where
you
kind
of
go
forward.
G
A
Okay,
we're
gonna
do
something
a
little
different
here,
maybe
a
little
unusual,
because
this
has
been
produced
by
a
design
team
number
one
and
number
two
that
we
don't
have
any
other
alternatives.
What
we'd
like
to
do
is
on
the
list.
We're
gonna
call
for
working
group
adoption
and,
as
part
of
that
adoption
call,
we
would
like
to
collect
issues,
people
see
with
the
document
and
that
and
those
issues
to
be
addressed
once
we
have
a
0-0
document
so
to
use
the
DAR.
A
A
H
I
A
I
Course,
yes,
usually
in
some
working
okay
in
some
working
groups,
they
do
harm
whether
this
document
is
ready
for
working
group,
adoption
call
and,
of
course,
working
group.
Adoption
call
is
performed
during
the
over
some
time
on
a
mailing
list
in
the
not
at
the
meeting.
I
agree
with
Stuart,
so
it
just
on
a
merit
of
this
document
and
whatever
comments
come
in
comments
come
if
there
will
be
alternative
documents,
there
no
be
alternative
documents.
C
C
This
items
for
further
study
make
it
clearer
that
it's
not
that
this
everything
can
be
based
on
that,
for
example,
using
sequence
numbers,
so
that
may
you
know,
allow
others
then
to
input,
and
then
you
can
merge
and
later
other
other
proposals,
but
make
sure
it's
very
clear
that
that
I
am
is
still
for
further
study.
Yeah.
A
What
we
certainly
have
followed
in
multiple
drafts
when
there's
multiple
proposals
to
put
them
in
the
same
draft
and
identify
that
it's
under
contention,
and
that
would
be
a
fine
way
to
deal
with
how
we
capture
the
issues
in
a
zero
one
version.
So
we
would
publish
a
zero
zero
and
immediately
go
to
a
zero
one
that
identifies
the
the
issues
in
the
draft
and
I.
That
sounds
like
a
good,
a
good
way
to
capture
those
issues
that
are
part
of
adoption.
So
I
like
that
idea.
Let's.
H
I,
don't
think
that
was
the
the
the
problem
that
I
have
with
this
approach.
Is
that
a
setting
a
document
is
a
working
document
usually
implies
a
high
level
of
endorsement
on
this
particular
technical
solution,
and
there
are
areas
in
there
that
I
am
worried
about
and
I,
don't
think
we've
debated
properly
as
a
working
group,
yeah.
A
So
the
Deborah
does
point
out
like,
for
example,
there
was
I,
don't
know
if
she's
thinking
of
a
particular
C
camp
document,
I'm
thinking
of
where
right
after
adoption
we
put
in
in
every
section
those
you
know
here,
the
different
approach-
or
this
is
not
settled
and
it
was
in
the
if
he
went
and
pulled
the
latest
version
of
the
working
group
document.
You
immediately
saw
that
it
was
an
area
of
contention,
so
I
think
Deborah
is
proposing
that
we
do
that
as
part
of
the
working
group.
B
So
Eric
gray,
again
I
I
agree
with
Stuart
completely.
The
reason
why
I
object
to
that
change
in
the
procedure
is
that
we
can
almost
as
easily
put
the
zero
zero
in
with
that's
information
in
it
and
by
putting
in
the
zero
zero
without
you
know,
addressing
the
fact
that
there
were
issues
that
have
been
raised
in
this
room
as
well
as
issues
that
could
easily
come
up
between
now
and
adoption
that
that
have
to
be
addressed.
B
A
So
that
is
actually
a
bit
of
a
change
of
a
norm
where
normally
the
zero
zero
is
identical
to
the
last
individual
Eric
stay
there,
because
I
want
to
ask
you,
make
sure
I
understand
your
proposal
you're,
proposing
that
the
zero
zero
have
in
it
any
issues
raised
during
adoption.
The
introduced
in
the
text
is
that
correct,
no.
B
A
I
B
I
think
we're
saying
almost
the
same
thing
I
mean
I've,
seen
a
lot
of
on
the
mpls
mailing
list,
for
example,
where
we've
had
a
lot
of
objections
to
the
exact
wording
group
in
the
draft
being
proposed
for
adoption
to
where
the
working
group
chair
said.
After
these
things
have
been
addressed
or
at
least
identified
in
the
draft,
then
we
will
post
it
as
a
working
and.
A
Certainly,
that's
a
pretty
normal
thing
is
identifying
issues
and
addressing
those
issues.
The
point
is:
we're
not
gonna
address
him
this
time,
we're
just
gonna
document
them
this
time
and
that's
fine
we'll
do
it
as
a
two-stage
step.
First,
we'll
collect
the
issues,
get
them
into
the
get
them
into
the
document
and
then
move
to
move
that
version
into
a
0-0.
A
J
O
A
O
Is
it
not
that
out
fantastic
okay,
so
my
name
is
Balaji
Orca
and
this
presentation
is
about
the
debt
net
flow
information,
whatever
update,
and
that
you
speak
in
the
name
of
the
outdoors.
You
can
see
on
this
slide,
but
you
will
see
here.
I
will
give
a
status
about
the
draft.
I
will
also
highlight,
but
updates
we
have
made
since
the
last
version-
and
there
is
also
slide
about
proposed
next
steps.
O
There
were
two
drafts
about
flow
information
model.
This
is
what
we
have
identified
in
the
last
Chicago
meeting
again
since
then,
there
were
several
discussion
in
order
to
merge
this
to
draft
a
single
proposal
as
being
the
flow
information
model.
So
this
is
what
you
can
see
and
that
we
have
updated.
This
is
exactly
the
result
of
merging
these
two
drafts.
O
So,
regarding
the
data
plane
design
results,
we
have
updated
section
6.1,
which
is
dealing
with
the
identification
and
specification
of
flaws.
We
have
defined
two
identification
attributes
group
which
can
be
used
at
the
Uni
for
a
layer
3
or
a
for
a
layer,
2
flow
and
in
addition,
we
have
also
defined
attributes
in
order
to
identify
the
flow
inside
the
data
domain,
and
this
is
what
was
done
according
to
the
data
plane,
encapsulation
specified.
O
We
have
also
added
some
text
to
the
traffic
specification,
so
the
current
definitions
are
low,
practically
any
type
of
traffic
to
be
described,
but
is,
it
is
always
describing
the
worst
case
scenario,
so
each
of
the
flowers
will
be
treated
as
a
CBR
flow
and
reserve
resources.
According
to
that,
during
the
discussion
we
have
identified
the
need
to
define
some
VBS
specific
attributes.
O
We
think
that
VBR
attributes
can
be
used
only
for
floors
which
have
limited
requirements.
It
means
that
they
are
only
lost
sensitive
or
they
are
only
delay
sensitive,
but
not
both
loss
and
delay
so
sensitive.
At
the
same
time,
here
we
have
highlighted
in
the
document
as
notes
three
possible
options:
how
to
deal
with
VBR
traffic,
one
is
to
define
average
attributes.
O
O
O
There
is
a
new
section
added
to
the
document
which
is
dealing
with
the
death-knell
domain.
This
is
practically
very
or
that
net
flows
are
encapsulated
according
to
the
definite
domain
forwarding
mythology.
So
this
object
is
specifying
the
behavior
of
the
definite
domain,
how
the
flow
is
encapsulated.
What
are
the
requirements
for
to
form
of
the
flows
and
what
are
the
capabilities
of
the
desmond
domain?
So,
in
order
to
do
that,
we
had
to
define
that
net
domain
capabilities.
O
Here
we
have
defined
two
attributes
but
is
related
to
the
encapsulation
format.
The
other
is
related
to
the
replication
and
illumination
capabilities
of
the
domain.
We
think
that
there
are
still
additional
attributes
to
be
defined
here.
So
here
we
see
some
some
further
work
and
we
have
also
added
some
notes
in
the
document
because
defining
the
dotnet
domain
it
can
lead
us
to
VARs,
also
define
no
specific
attributes
which
will
be
needed
for
configuration
of
those
nodes
in
order
to
set
up
and
to
enclose
in
the
domain,
and
particularly
that's
it.
O
So
we
have
added
that
net
domain-specific
extensions.
We
think
that
there
are
some
further
work
on
that.
We
think
also
that,
on
on
the
format
of
the
attributes
like
traffic
specification,
this
is
also
something
where
we
need
some
further
work.
However,
we
think
that,
with
the
merge
of
these
two
flow
information
model
draft,
we
are
quite
stable
regarding
having
a
baseline
for
the
flow
information
or
they
are
draft.
So
this
is
why
we
are
calling
for
the
reproduction
on
that
dress.
A
Before
we
go
to
adoption,
we
have
some
additional
perspectives
from
mock,
so
I
would
like
to
talk
I'd
like
to
come
back
and
talk
about
adoption
of
the
document,
but
first
mock's
gonna
talk
before
we
move
on,
though,
how
many
have
read
this
one?
This
document
you
raise
your
hands
high.
So
that's
just
a
few.
A.
P
Good
morning,
everyone
this
is
marcin.
This
presentation
discuss
some
consideration
on
then
it
equals
model.
So
the
motivation
for
this
for
this
transition
is
that
we
think
the
current
information
may
not
include
enough
information
that
can
be
used
to
support
how
to
establish
at
any
flow.
So
after
with
a
discussion
with
the
information
model
ulcer,
they
were
encouraged
to
present
this
some
consideration
about
this
in
komodo
and
try
to
select
feedback
from
knocking
group
how
to
progress,
relevant
works,
and
maybe
what
information
should
be
in
it
should
be
area.
P
So
here's
a
Harris
from
the
procedure
of
how
to
establish
art
and
a
flow
point
of
view.
So
you
can
take
that
if
you
want
to
set
up
a
data
flow,
the
first
one
is
to
get
the
requirement
of
they
live.
Then,
for
example,
the
flow
identification
and
the
flow
control
information,
and
also
we
also
need
the
tenant,
get
the
elevation
their
work
information
and
combine
the
post
information.
We
can't
until
he
can
compute
a
pass
and
the
the
Dynaflow
pass.
Information
can
be
used
to
direct
how
to
example.
P
If
you
want,
if
you
use
that
a
limo
plus
they
come
to
configure
the
pass,
the
immolation
can
be
a
base
to
track
how
to
define
your
model
and
also,
if
we
use
the
control
plane
particle
to
please
damage
data
flown
dynamically,
and
that
mission
can
be
our
company
promoters.
Input
to
the
control
group
article.
So
once
the
Dana
flow
established
it'll
be
relevant,
floated
standards
that
can
be
collected
by,
for
example,
by
the
ingress
or
by
a
controller,
to
talk
to
money
to
weather
the
pass
you
ready
or
not.
P
So
you
can
see
that
in
the
picture,
the
red
box,
the
information
in
the
red
box,
his
car
is
all
is
covered
in
the
current
in
family
model
and
the
blue.
One
is
the
information
that
we've
helped,
but
that
we
think
he
should
be
bound
to
the
information
model
and
should
be
maybe
she'll
be
added
to
the
innovative
model.
P
So
here's
the
some
details
about
the
flow
control
emission,
which
include
the
flow
at
a
mutation,
for
example
the
source
at
destination,
address
and
the
floor
apartment.
What
the
latency
redundant
number
past
members
also
the
traffic
expect
specification,
which
is
a
examples:
a
interval
packet
transmitted
interval
and
the
what
the
maximum
impact
asides.
P
The
the
figure
in
the
right
side
shows
how
this
information
can
be
used
when
to
step.
I
want
to
start
to
establish
the
then
a
flow
past
example.
The
this
is
a.
This
is
a
centralized
model
where
the
application
controller
may
send.
The
flow
flow
can
contain
information
to
the
level
controller
and
larrikin
hurricanoes
admission
and
combine,
which
is
one
compound
which
network
information
to
computer
past.
This
is
the
yeah
choose.
P
What
channels
then
network
related
information
should
be
may
be
used
to
support
the
established,
computation
and
establishment
which
way
categorize
this
information
to
three
cameras.
The
first
went
among
white
information.
This
is
not
dedicated
for
a
single
device,
one
out.
It's
applied,
just
the
how
domain.
For
example,
there
may
be
encapsulation
attribute
that
can
be
used
for
for
specific
domain
and
repair
artis.
That
is
not
object
to
210
it
flow
and
also
there.
P
They
also
need
the
network
topology,
and
this
one
may
be
has
already
maybe
has
already
defined
by
other
working
girl,
for
example
the
advice
or
another
T's.
We
can
group
job
douwe,
hyung,
irrelevant
Yamato's,
but
beside
beside
that,
there
also
need
some
tenets,
delicate
capability
information,
for
example,
they
don't
check
the
maximum
load,
the
latency
and
how
many
reservable
bandwidth
can
be
used
for
the
internet
establishment.
P
P
Here
is
the
flow
skaters,
as
I
said
before
it,
red
one
is
already
covered
in
the
current
model
grabbed
and
below.
Maybe
you
know
four
10s
top
flow?
It's
it's!
It's
not
just
like
normal
flow.
There
may
be
relevant
the
rebbe
special
loads
in
for
pass
examples,
a
the
application,
animation
node.
They
may
also
have
some
status
in
in
dialogue.
So
when
we
also
need
to
collect
the
relevant
status
in
those
doubt,
then
we
can
use
all
the
extenders
to
to
the
fact
what
whether
or
title
class
can
be
used
to
transmit
the
packet
yeah.
P
K
P
The
role
infirmity
model
is
Oh
conn-young,
but
there's
no
details
were
completed.
Configuring
part
so
far.
Example
it
for
the
input,
input
part
their
network
topology,
though
the
capabilities
and
some
other
information
is
not
covered
in
the
current
I.
Even
his
model
and
also
the
output
part,
the
part
of
the
flow
past
information
and
node
configuration
not
configuration.
Information
Zod,
is
also
not
included
in
the
current
model
and
yeah.
I
I
K
Q
Dan
Bogdanovich,
so
how
you
created
sets
in
off
your
models
and
the
formation
on
how
you
group
them
I.
Think
that's
a
really
good
way
to
proceed
with
the
Building
Information
model
and
I
would
even
encourage
you
to
build
the
initial
structure
that
should
stay
the
same
as
much
as
possible.
Throughout
the
you
know
the
life
cycle
of
a
draft,
because
you,
if
you
go
through
like,
for
example,
I'd,
say
on
the
none
up
just
on
the
one
more
please
better,
for
example.
Q
So
here
you
already
said:
okay
for
the
flow
question,
information
is
I
need
to
have
you
know,
flow
identification,
flow
requirements,
traffic
specification
and
with
that
you're
saying
okay.
This
gives
me
the
description
of
my
flow
constraint
information.
Now,
if
you
leave
that
I
wouldn't
worry
the
beginning,
we
check
all
attributes
and
parameters
have
to
go
in
there.
It's
just.
Q
You
know
that
as
an
initial
abstraction
is
valuable
for
the
modeling
and
then
keep
that
as
a
structure,
and
we
can
then
expand
the
downed
alignment
we're
finding
out
which
other
information
pieces
have
to
go
in
there.
But
this
is
the
one
part
that
we
should
agree
early
on.
Is
this
all
that
is
needed,
for
example,
for
the
flow
constraint
information,
or
is
there
other
major
grouping
that
has
to
be
put
into
the
into
the
structure?
The.
A
M
Car
Viva,
pickup
automation,
I'm
wondering
what
you
mean
this
central
user
configuration
and
central
network
configuration
in
this
context.
We
are
talking
about
the
Internet.
Do
you
mean
one
central
instance
for
the
whole
world
or
for
a
very
local
side,
and
if
you
have
over
left
that
next
domains
how
to
handle
this?
In
this
context,
I
was
a
little
bit
surprised
about
this
terms
of
how
did
we
actually.
P
R
A
Also,
we're
also
not
covering
control
yet
in
this
working
group,
so
this
is
sort
of
just
a
reference
model
to
keep
in
mind
of
how
it
might
be
used.
It's
not
how
it
is
going
to
be
used.
It's
a
possibility
just
to
keep.
Just
as
an
example
are
it's
an
example:
it's
not
a
requirement,
it's
not
what
we're
saying,
but
it
must
be
done
or
will
be
done.
It's
just
an.
A
M
J
Q
J
P
A
Yeah,
we're
running
out
of
time,
actually
we're
a
little
over
so
like
to
try
to
wrap
this
up
if
it's
okay.
So
what
are
you
suggesting
that
these
issues
that
you've
raised
be
addressed
in
the
individual
draft
or
you
suggest?
Are
you
saying
it's
okay
to
start
with
that
individual
draft
as
a
working
group
draft
but
you'd
like
to
see
these
types
of
matters
addressed
it
by
the
working
group?
Well,.
A
So
with
that
I'd
like
to
move
move
to
asking
about
the
prior
draft,
the
the
flow
information
model,
0
1-
if
we
saw
that
just
a
few
people
had
read,
it-
do
I'd
like
clearly
we're
not
going
to
adopt
today,
but
we
can
get
an
impression
of
whether
people
think
it's
ready
or
do
we
want
to
see
it
mature
a
little
bit
more,
perhaps
with
the
some
of
the
issues
that
Mach
is
raised,
addressed
in
the
individual.
So
how
many
would
like
to
see
the
0
1
document
presentable,
Oz's
accepted
as
a
working
group.
A
R
A
A
There
was
some
feelings
given
that
this
has
been
out
there
a
while
my
inclination
is
is
to
do
go
forward
with
a
poll
and
if
it
fails,
it
fails,
but
then
we
go,
but
I
want
to
talk
with
my
co-chair
and
the
ad
as
well
before
that,
but
in
the
interim,
don't
wait
for
us
if
you
guys
can
get
together
and
figure
out
how
to
make
you
want.
You
have
some
text
know.
Hopefully
you
have
some
text
behind
these
ideas.
A
S
Okay,
so
this
is
basically
the
outline
of
the
draft.
As
you
can
see,
we've
made
some
significant
progress
in
the
last
few
months,
actually
in
the
current
revision
of
the
draft,
there's
quite
a
bit
of
new
text,
and
the
draft
mainly
consists
of
security
threats,
which
means
how
an
attacker
can
attack
the
dead
net
system
impact,
which
means
what
happens
if
there
is
a
successful
attack
mitigations,
which
means
how
can
we
try
to
mitigate
or
solve
some
of
these
problems
or
attacks?
And
finally,
there
is
some
discussion
about
use
cases.
S
So
now
we're
going
to
talk
a
bit
about
each
of
these
different
sections,
we'll
start
with
security
threats
and
so
in
a
nutshell,
the
threat
model
distinguishes
between
internal
and
external
attackers.
An
external
attacker
is
an
attacker
who
is
not
within
the
premises
of
the
trusted
zone.
In
the
network,
an
internal
attacker
either
has
physical
access
to
the
trusted
zone
of
the
network,
or
if
there
is
a
cryptographic
protocol
which
is
in
use
in
the
system,
an
internal
attacker
can
also
be
someone
who
is
outside
the
trusted
zone,
but
has
access
to
the
cryptographic
keys.
S
So
that's
the
distinction
on
the
left
between
internal
and
external
on
the
right.
We
see
a
distinction
between
on
path
and
off
path.
Attackers,
so
non
path.
Attacker,
who
is
on
the
path
between
the
source
and
the
destination,
is
also
called
in.
The
middle
is
someone
who
can
intercept
packets
and
an
attacker
is
not
on
the
path
and
off
path.
Attacker
is
also
called
an
injector
because
they
can
basically
inject
packets.
S
So
this
is
the
threat
model
in
a
nutshell,
and
since
we
love
ASCII,
art
tables,
there's
a
lot
of
them
in
the
draft.
So
this
is
an
ASCII
art
table
that
basically
summarizes
the
attacks
and
for
each
attack
it
tells
us
which
attacker
types
are
relevant
to
that
attack
more
details
in
the
draft,
and
so
we
talked
about
the
fritz.
Let's
talk
a
bit
about
the
impact,
what
happens
if
an
attack
is
implemented
successfully
and
in
terms
of
the
impact
we
distinguish
between?
What
happens?
S
What
is
the
impact
of
a
successful
attack
on
the
control
plane
and
what's
the
impact
of
an
attack
on
the
data
plane?
So,
first
of
all,
let's
talk
about
recon
attacks,
so,
for
example,
if
there's
a
recon
attack
on
the
control
plane,
that
means
the
attacker
can
monitor
any
changes
that
happen
in
the
network
and,
for
example,
the
they
can
know
which
flows
exist.
What
their
float
IDs
are.
If
there
is
a
successful
recon
attack
on
the
data
plane,
that
means
the
attacker
can
track
the
activity
of
the
data
in
flows.
S
S
The
impact
of
that
may
be.
Basically,
the
impact
is
that
you
mess
with
the
resource
allocation
in
the
system.
So
that
means
you
can
either
reduce
the
quality
of
service
or
you
can
cause
resource
exhaustion
in
some
cases
now
a
delay
attack
of
data
plane
messages.
So
obviously,
these
messages
are
delayed,
that's
already
a
bad
impact.
It
also
causes
packets
to
be
buffered
in
some
of
the
bridges
and
routers
which
may
cause
congestion,
so
it
has
other
implications
as
well
other
types
of
attacks
which
may
be
considered
modification
or
spoofing
attacks.
S
So,
first
of
all
in
terms
of
the
control
plane.
Obviously
any
control
plane
message
that
can
help
can
be
use
to
create,
remove
or
modify
these
once
these
messages
are
compromised.
That
means
the
attacker
can
perform
these
operations
on
the
data
plane.
If
the
attackers
perform
a
modification
or
spoofing
attack,
that
means
basically,
they
can
use
resources
of
the
network
that
were
not
intended
for
them.
Okay,
so
that's
basically
the
impact
of
that
in
terms
of
the
data
plane.
S
Now,
generally
speaking,
at
this
point,
I
should
say
that
when
we
talk
about
attacks
and
impact
in
the
context
of
this
document,
we're
not
talking
about
generic
security
attacks
in
general,
we're
talking
specifically
about
attacks
that
are
relevant
to
dead
net
environments
and
we're
focusing
on
those,
and
so,
if
we're
talking
about
the
impact,
if
I
have
to
summarize
in
one
sentence,
what's
the
impact
of
a
successful
attack
on
a
dead
net
Network?
Basically,
it
means
that
dead
net
flows
are
forwarded
in
a
non
deterministic
way.
Okay,
that's
in
a
nutshell,
that's
the
impact.
S
So
we
talked
about
threats.
We
talked
about
impacts.
Let's
talk
a
bit
about
some
of
the
mitigations
we
can
use
so
obviously,
path.
Redundancy
is
kind
of
built
into
the
dead
net
architecture.
It
can
help
mitigate
various
man-in-the-middle
attacks.
If
we
use
integrity,
protection
or
authentication
methods,
it
can
help
to
mitigate
spoofing
modification
attacks.
Now
encryption
we're
not
really
interested
in
fidelity
in
the
context
of
debt,
net,
okay
use
for
other
purposes,
but
specifically
for
debt
net.
If
we
were
using
encryption,
it
can
help
mitigate
some
recon
attacks.
Okay,
so
that's
the
benefit
of
encryption.
S
Also,
obviously,
if
we
want
to
mitigate
control,
plane
attacks,
we
want
to
protect
control,
plane
messages,
either
by
integrity,
protection
or
encryption
and
in
order
to
try
to
mitigate
resource
exhaustion
attacks.
If
we
have
performance,
monitoring
and
analytics,
that
can
certainly
be
a
useful
tool
for
that
and
another
ascii
our
table.
Basically,
we
summarize
all
the
attacks
and
map
them
to
the
corresponding
impacts
and
medications
and
more
details
in
the
draft
of
course.
S
Okay,
so
to
summarize,
we
presented
this
draft
for
the
first
time
in
Chicago,
we
received
good
feedback.
There
was
white
support.
We've
made
significant
progress
since
then
a
lot
of
new
text,
and
we
believe
that
at
this
point
the
draft
is
ready
for
a
working
group,
adoption
and
we'd
like
to
ask
the
chairs
to
call
for
working
group
reduction.
Any
other
comments
we'll
be
welcome.
Thanks.
A
Don't
even
finish
the
sentence
now
II
think
it's
worthwhile
having
this
type
of
document
a
reasonable
number.
How
many
have
read
this
document
a
little
less?
How
many
would
like
to
see
this
document
as
the
foundation
for
groups
activity
in
this
area?
I
would
say
more
than
have
read
the
document,
so
I
think
that's
interesting
I
appreciate
that
we
will
take
it
to
the
list.
Thank
you.
Thanks.
F
E
One
small
sentence
or
the
other:
it's
clear,
I
gotta
fire
yourself,
let's
get
real,
you
want
to
be
very
realistic
when
you
say:
what's
the
damage,
if
the
network,
if
the
domestic
slowly
its
broken,
is
tact,
it's
not
it
every
six,
that's
not
the
consequence.
Those
domestic
networks
are
meant
to
be
used
to
interface
with
the
real
world.
As
supposed
to
many
of
the
networks
we've
played
so
far.
This
is
really
talking
about
doing
things
in
the
real
world,
and
so,
if
this
data
mystic
flow
does
not
go
through
some
physical
systems,
machines
will
break.
E
Some
people
will
die.
So
the
cons,
that's
what
the
consequence
is.
It's
not
just
the
flow
that
goes
non-deterministic.
So
when
you
look
at
about
what
you,
what
measures
do
you
put
in
front
of
that?
It's
not
oh
and
put
a
firewall
tomorrow
and
then
fix
it
right.
This
kind
of
countermeasure
has
to
be
something
which
works
in
the
next
seconds
or
the
next
minutes.
A
Good
comment
and
when
you're
reviewing
the
document
as
part
of
the
last
adoption
call,
if
you
have
specific,
if
you
identify
a
shortcoming
and
have
an
idea
of
some
specific
text,
you
think
could
be
added
to
address
it.
That's
as
your
your
specific
comment-
or
this
applies
to
anyone
in
the
working
group,
please
include
that
as
part
of
your
response,
it
could
be
yeah,
we
should
adopt
it
and
here's
some
text
I'd
like
to
see
added
in
the
work
group
document.
Thanks
for
the
comment,
hi.
R
I'm
Marcus
from
erikson
Research
Hungary
and
with
my
colleagues,
balázs,
and
this
time
we
have
implemented
the
packet,
replication
and
elimination
of
function
in
a
software
switch,
and
this
is
an
implementation
report
of
that
implant.
Implementation.
Actually,
that
is
along
the,
as
described
in
the
data
plane
solution
draft
the
current
from
the
zero
point
one.
R
So
this
out
of
the
before
a
key
features.
We
need
for
deterministic
packet
networks
that
we
are
working
on
here
in
in
that
net,
with
these
focuses
on
the
reliability,
the
packet,
replication
and
illumination
function
in
order
to
achieve
or
provide
extremely
low
loss,
in
other
words,
avoid
the
equipment
failure.
R
R
The
data
plane
solution,
dropped,
zero
point,
one
cause
it
packet,
replication
and
elimination
function
and
provides
the
details
of
the
layer,
3
data
pane,
which
we
have
discussed
before
along
you,
nice
presentation.
So
this
with
what
we
focused
on
is
the
pseudo
wire
over
MPLS.
The
basic
idea.
I
think
you
are
all
familiar
with
that.
This
is
a
perfect
redundancy.
R
So
that's
the
basic
mechanism,
and
so
what
we
did
is
that
we
implemented
the
feature
on
software
switches
in
a
ring
topology,
as
illustrated
in
the
figure
the
Lyla
cones,
are
the
replication
and
elimination
points
actually
implementing
the
feature,
the
gray
ones
just
software
switches,
and
the
use
case
we
have
been
jackin
it
with
is-
is
a
balancing
robot
on
one
side
and
the
balancing
logic
is
moved
to
the
cloud.
It's
a
remote
logic,
and
that
goes
to
the
network.
R
We
compared
the
the
replication
function
with
the
classic
15min
set
protection,
switching
for
which
there
are
a
number
of
mechanisms
already
today
this
is
the
use
case.
We
have
been
focusing
on
the
TSN
service
over
that
net
network,
as
described
in
the
data
plane,
solution
drop.
So
what
we
have
on
the
wire
is
that.
K
R
N
top
solution,
the
VLAN
ID
and
the
replication
order,
the
edge
node
actually
is
the
one
that
adds
the
MPLS
T
label,
the
pseudo
wire
to
the
wire
label
for
the
for
identification,
and
the
controller
is
the
one
that
carries
the
sequence
number
for
the
replication
as
you've
already
heard
about
a
couple
of
minutes
ago.
This
is
just
a
scheme
set
this
capture
Wireshark.
If
you
want
to
check
off
line
what
we
have
on
the
wire
and
we
evaluated
two
cases,
two
use
cases.
First,
one
is
a
simple
link:
failure.
R
The
protection
switching
mechanism
provides
a
50
millisecond
over.
So
in
other
words,
it
is
a
50
millisecond
or
teach
for
the
application,
and
actually
the
replication
function
works
a
lot
better.
So
if
taking
the
look
on
on
what
happens-
and
we
have
protections
which
is
only-
we
are
cutting
the
link.
S
R
From
software
for
Michelle
actually
to
make
it
easy,
cutting
it
for
50
minutes
that
we
are
losing
three
three
packets
or
the
control
application,
which
makes
the
balance
a
single
box
falling
over,
so
the
control
is
lost
and
which,
if
we
turn
on
the
same
application
and
elimination
or
packaged
application,
and
we
can
cut
the
link
or
whatever
long
the
console
is
surviving
and
the
balancing
works.
Fine.
R
The
other
scenario
we
checked
is
the
link
flapping,
which
is
like
if
it
is,
for
example,
try
to
make
micro
so
milliseconds
down
time
and
then
you're
monitoring
your
foot
for
the
protection.
Switching
often
doesn't
even
detect
it,
but
it
still
affects
the
application.
So
if
there
are
these
outages,
then
the
balancing
is
over
and
if
with
protection
switching,
but
if
we
turn
on
the
replication
and
elimination,
then
the
balancing
logic
is
is
up.
R
So,
as
we
experienced,
the
packet,
replication
and
elimination
function
actually
provides
really
hitless
feel
over.
There
is
no
switch
over
in
the
mechanism
as
designed,
and
we
implemented
it
as
discard
in
the
data
playing
solution,
so
it
just
works
fine.
There
is
a
demo
of
it
this
afternoon,
in
the
first
afternoon,
coffee
break
capacity
in
the
in
the
Tioga
room.
E
Let's
get
Iranian,
oh,
we
did
a
very
similar
D
1:6
dish
with
a
stick
of
wood
that
that
holds
and
and
the
point
I
want
to
make
about
this-
is
we
have
this
information
modeler
here
and
it
seemed
to
to
reflect
the
classical
thinking
of
so
many
nines
and
this
sort
of
thing
yeah
and
those
controls-
don't
care
about
so
many
nines,
because
they
can
miss
a
packet
once
in
a
while.
Even
ten,
minus
three
would
work
fine.
E
J
R
For
this
demo,
yes,
that's
the
single
point
of
failure.
If
you'll
go
real
life,
you
need
to
do
some
dual
homing
or
something
or
you
can
move
the
replication
point
to
the
application.
That's
another
way.
So
actually,
this
is
why
here
in
the
Indies
illustration,
it
is
a
bit
vague
where
this
replication
and
elimination
points
are
because
they
can
be
anywhere.
They
can
be
an
application
that
can
be
nice
know
that
that
can
be
Co
notes.
You
can
have
fancy
topologies
like
leather,
and
there
are
many
options
and
the.
R
R
A
Yeah,
it's
also
we've
done
in
lots
of
places,
but
it's
it's
a
classic
protection
domain
with
one
plus
one
protection
and
they're
doing
hitless.
So
there's
the
number
you
lose
before
you
switch
is
zero.
So
on
the
first
loss
you
switch
and
it's
on
it's
up
on
a
packet
by
packet
basis,
so
every
packet
you
can.
J
J
T
R
Well,
there
are
a
number
of
sub
cases
and
and
issues
you
have
to
take
care.
There's
a
window,
you
you,
you
keep
tracking
the
sequence
numbers
that
can
be
the
bit.
The
delay
can
be
different
on
that
two
parts,
so
you
have
to
buffer.
So
this
is
just
a
basic
simplest
case,
but
all
of
these
are
covered
in
the
specification
actually
or
others.
A
Yeah,
it's
good
to
have
whenever
we're
doing
something
new
on
the
data
plane,
it's
good
to
have
some
validation
of
it.
So
this
is
useful
information
again.
This
was
on
the
individual
draft.
We
would
hope
that
other
implementation
experimentation
could
happen
as
as
the
working
group
draft
evolves
or
as
we
have
a
working
group
draft
called.
M
R
D
D
A
R
R
Okay,
so
the
next
deck
is
a
bit
of
an
overview
of
TSN
what
you
are
doing
in
802
dot.
One
TSN
has
an
input
to
the
work
going
on
here
in
the
death
networking
group.
This
is
based
on
on
the
tutorial
we
gave
sunday
on
TSN
with
the
norm
and
that
so
I
need
to
say
here
as
well
that
this
is
not
an
official
view
of
a
triple-a,
total
rate
or
2.1.
R
So
this
deck
includes
after
some
introduction.
What
what?
How
do
we
describe
a
TSN
stream?
What
type
of
techniques
we
use?
Qsr
techniques
for
per
stream
techniques
or
or
for
class
techniques
to
achieve
zero
congestion
loss,
but
shaping
and
time
scheduling,
and
there
will
be
there-
are
some
sites
on
same
preemption,
the
transmission,
preemption
and
then
the
end.
There
are
some
discussion
items
brought
to
the
floor
norm.
You
wanted
to
talk
about
these
lines.
If
you.
D
D
D
We're
taking
to
it
we're
taking
approaches
to
explore
the
remaining
space
in
in
trade-off
space
that
the
axes
of
our
trade-off
space
include
when
we
have
a
number
of
different
techniques
that
we're
doing
in
802
number
of
different
queueing
techniques.
To
make
this
real,
we
have
to
we
wind
up
trading
off
what
sort
of
latency
do
we
get?
How
low
is
the
bounded
latency?
What's
the
magnitude
of
this
bounded
latency?
D
How
complex
is
it
ie
expensive?
Is
it
to
implement
this?
Can
we
serve
a
wide
range
of
applications
in
the
same
network
with
different
requirements
for
how
much
bandwidth
they
need?
What
is
the
latency?
What
is
the
variation
in
the
latency
of
the
delivery
frame?
Does
how
difficult
is
it
to
deliver
the
frame
into
a
packet
exactly
on
time?
Forgive
me
if
I
use
the
word
frame,
that's
what
we
call
it
in
802
and
the
ability
to
handle
dynamic
reservation
changes.
That's
also
not
trivial.
D
We
can't
necessarily
stop
everything
in
order
to
add
or
delete
or
move
a
reservation,
so
we're
taking
two
fundamentally
different
approaches
and
one
is
per
stream
traffic
shaping
that's
a
one,
that's
fairly
familiar
to
IETF
people
and
the
other
is
time-based
transmissions
which
may
or
may
not
be
relevant.
But
one
thing
to
stress
is
that
we're
not
talking
about
observing
the
traffic
and
deciding
what
we
need
to
do
to
help
it
out?
Everything
is
done
with
a
an
opera
re
resource
reservation.
D
D
It
is
a
hierarchy.
There
are
you'll
notice,
there's
nothing
in
this
diagram
about
selecting
which
port
to
forward
it
on
that's
the
routing
function,
the
bridging
function,
the
forwarding
function.
That's
not
our
business,
we're
talking
about
QoS,
we
do
per
stream
filtering
and
policing.
We
do
the
packet
replication
in
the
elimination
and
we
do
per
stream
shaping,
and
we
do
per
class
queuing
in
this.
A
R
Can
talk
about
this,
so
this
section
is
about
how
do
we
describe
a
stream
or
a
flow
in
TS
on
a
key
aspect?
Is
the
identification
so
for
that
there
are
multiple
options
in
in
our
documents.
It
is
the
the
document
is
not
listed.
Sorry
for
that,
the
qcc
document
and
the
CB
document.
Those
are
the
two
that
describe
so
the
MAC
addresses
obviously
and
VLAN
ID,
as
well
as
the
political
point,
the
layer
two
priority
field,
and
we
also
have
the
possibility
for
DHCP
and
ipv4
factors
v6
fighter
/.
R
It
is
important
that
all
these
flu
identification
is
only
for
qsr
purposes
and
potentially
for
encapsulation
transformations
at
the
edge,
and
they
are
not
for
forwarding
decisions
so
not
for
the
forwarding
visitor.
The
next
two
slides
explain
the
next
two
aspect:
the
the
traffic
specification
itself,
that
goes
to
the
user
network
interface
and
the
network's
reply
to
the
request.
R
So
the
traffic
specification-
it
is
a
request
from
the
from
the
post
or
a
talker,
as
well
as
its
promise
that
this
is
the
traffic
that
will
be
provided
to
the
network
and
and
the
talker
is
not
supposed
to
violate
it.
So
we
have
a
packet
interval.
This
is
for
CBR
traffic.
We
have
a
packet
interval
max
frames
per
interval
and
the
maximum
size.
R
This
type
of
specification
is
observable
and
verifiable,
so
this
is
good
for
you
and
I.
It
also
includes
or
may
include
the
talker
behavior,
so
the
talker
the
host
may
implement
one
of
the
shaper
algorithms
itself.
That
can
be
done
programmed
by
a
central
controller
like,
for
example,
the
time
based
queuing.
We
have
and
the
token
itself
can
be
time
over
and
offsets
earlier
late.
Offsets
can
be
programmed
for
the
talker.
If
you
want
to
have
offsetting,
apply
offsetting
to
the
traffic.
R
The
talker
also
expresses
the
applications
needs,
which
is
the
kind
of
requirement
towards
a
network.
The
worst-case
end-to-end
latency
and
the
other
one
is
the
the
number
of
disjoint
paths
needed
for
the
frame,
replication
and
elimination.
So
these
are
the
requirements
from
the
from
the
user
or
the
host
to
the
network.
The
network
response
is
both
to
the
toker
and
listener,
with
the
status
info
which
can
be
empty,
it
can
be
nun
or
it
can
just
be
ready
everything
it's
fine
or
it
can
say
that
it's
filled.
R
Something
is
wrong
and
there
are
filler
filler
court
specified
on
how
to
be
able
to
figure
out
what
went
wrong
in
the
response,
and
that
includes
as
well
and
accumulated
latency,
which
is
a
worst
case
latency
for
one
frame.
If
this
response
is
sent
to
the
listener
to
the
destination,
then
it
is
about
a
single
pot
so
from
the
source
to
the
destination.
This
is
the
worst
case
latency.
E
But
at
some
point
there
is
the
transport
in
the
network,
which
may
decide
to
put
those
constant
bits
into
one
or
more
packets
and
the
way
to
describe
being
number
of
frames
and
maximum
size
of
freights
makes
it
so
that,
if
I
send
two
frames
of
500
bytes,
it's
not
the
same
thing
as
sending
one
frame
of
one
cave
at
some
point.
The
shaper
will
react
differently
to
those
tools.
Constant
bit
writes.
E
I
was
just
wondering
if
that
means
that
we
should
tell
something
to
transport
of
some
specific
transport
with
particular
or
limitations,
or
particular
angles.
Oh
I'm
doing
that
net.
My
transport
should
definitely
not
be
TCP
with
MSS
doing
whatever
ideas
and
or
if
there
is
a
need
for
something
to
block
the
packet
and
reconstitute
deterministic
friendly
blocks
that
can
be
transported
according
to
this
contract.
So.
R
A
So
I
think
that's
how
you're
interested
you're
raising
a
really
interesting
question
or
point
is
that
it
would
be,
might
be
beneficial
for
the
debt
net
layer
to
provide
the
transport
protocol
information
on
what
service
is
available.
If
I
understood
that's,
what
you're
saying
is
the
might
use
the
mic
just
so
the.
E
Wrong
people
can
hear
I
was
in
the
province
by
it's,
not
in
solution
space,
but
I
agree
that
you
provide
a
approach
to
solving
what
I'm
saying.
I
was
just
saying:
okay,
the
application
sees
CPR,
but
there
are
things
between
the
application
and
bed
net
which
made
on
that
not
a
constant
number
of
frames,
depending
on
how
the
frames
are
being
built
based
on
what
the
application
outputs
we.
A
Actually,
don't
have
a
way
right
now
for
debt
net
to
expose
any
information
to
my
transport
protocol
or
the
application
so
that
that's
an
IETF
problem
and
beyond
this,
the
scope
of
debt
net,
but
one
that
we
should
be
talking
about
here,
so
that
we
can
start
figuring
out
who
we
talk
to.
So
we
could
look
to
our
ad
for
help,
but
saying
maybe
we
should
start
figuring
out
someone
from
the
transport
area
that
we
can
start
talking
to
about
opening
this
dialogue.
A
It's
not
something
we're
going
to
solve
here,
but
in
terms
of
the
actual
users
of
the
technology.
They
need
this
solved.
So
it's
a
good
I
eat
EF
problem
to
bring
up
this
by
the
way.
This
is
exactly
sort
of
the
reason
to
have
this
talk
here.
Is
this
I
have
going
through
these
8o
2.1
TSM
pieces?
It
can
inform
our
discussions
here
and
our
process
here.
So
thanks.
Yes,.
R
I
wanted
to
also
say
that
it's
a
very
good
discussion
item
on
what
what
to
do
in
that
net,
and
this
is
just
an
input
for
discussion.
So
far.
This
slide
is
only
TSN
and
it's.
It
would
be
nice
to
have
all
these
discussion
items
collected.
So
we
have
some
in
at
the
end,
but
it
would
be
good
to
have
at
the
door
somehow
cool
at
these
items,
but
this
side
is
only
a
TSN
as
an
input
to
what
do
we
do
in
depth.
R
So
the
first
one
is
is
the
first
stream
filtering
and
policing.
This
is
a
kind
of
an
English
port.
That's
the
typical
implementation
case.
It's
a
so
course
optional
value
implement.
It
is
protection
against
manual,
violation,
malfunctioning
or
attack
against
attacks.
So
there
are
T
three
components
or
three
possibilities
here.
The
first
one
is
the
stream
filter
on
the
top,
which
includes
critters
or
counters.
This
can
be
perceived
or
priorities,
so
there
are
multiple
options
and.
R
If
you
want
to
block
some
some
seen,
for
example,
this
is
one
of
the
knobs
for
that
the
next
one
is
is
the
stream
gate
which
can
be
open,
open
and
or
closed,
and,
for
example,
you
can
close
the
gate
if
you
discover
a
bubbling
video
in
the
network
or
something
like
that,
this
opening
and
closing
can
be
time
scheduled
as
well,
and
the
third
one
is
the
metering
function
which
is
based
on
the
MAF
bandwidth
profile.
This
is
a
red,
yellow,
green
marking,
and
we
have
actually
added
some
other
functions
in
this.
R
Qc
are
standard
like
if
the
frame
size
is
over,
the
of
them
larger
than
the
max
frame
size,
or
something
like
that.
So
there
are
some
new
add-ons
to
death
frame
application
on
the
elimination.
We
have
already
discussed
this
I
don't
want
to
spend
time
on
it
is
this
per
packet,
Allen
assumed
an
ism,
and
we
also
have
the
capability
for
stream
transformation
which
can
be
implemented
by
the
host
or
by
the
edge
node.
R
It
is,
but
there
are
multiple
uses
for
that.
One
is
this
replication
and
elimination,
but
the
what
you
talk
about
here
is
the
stream
identification
transformation.
So
if
a
different
identification
scheme
is
used
by
the
network
and
the
end
station,
this
is
one
of
the
tools
in
order
to
to
translate
between
the
two
like
between
an
IP
identification
and
the
layer
to
destination.
I
can
real
an
same
identification
and
now
zero
congestion
loss.
This
part,
you
wanted
to
explain.
D
We
have
two
ways
of
achieving
zero
congestion.
Last
one
is
based
on
shapers.
One
is
based
on
time
scheduling
a
synchronous
traffic
shaping
is
a
project
that
is
underway
now
it's
not
finished,
but
we've
had
some
good
presentations
and
good
simulations
and
some
experimental
implementations
and
it's
enough
similar
to
what
you're
familiar
with
with
individual
queue,
shaping
that
you
can
appreciate.
It's
got
a
good
chance
of
being
correct.
D
It's
a
slight
advance.
We're
all
familiar
about.
Many
of
us
are
familiar
with
the
idea
that,
as
the
various
flows
come
into
a
router,
you
put
each
one
in
its
own
shaper
and
that
by
shaping
the
flows,
you
can
get
extremely
low
or
even
zero
congestion
loss,
and
we
all
understand-
that's
not
trivial
in
the
number
of
gates
required.
What
this
idea
brings
to
the
party
a
a
bit.
A
slight
difference
is
that
we
still
need
a
state
machine
per
flow
for
regulating
for
shaping
it
for
regulating
it.
D
You
can
take
all
the
flows
that
are
coming
in
on
one
court
and
going
out
on
the
same
part
and
put
them
all
through
the
same
queue
and
as
each
packet
comes
up
to
the
head
of
the
queue
you
pick
the
shaper
that
goes
with
that
packets
flow,
so
you
have
one
queue
and
you
swap
in,
and
you
use
the
shapers
in
sequence,
you
have
all
the
shapers
running
and
you
apply
the
shaper
to
the
queue
at
the
head,
and
if
it's
not
time
for
that,
you
wait
until
it
is
time.
Then
you
transmit
it.
D
D
We
have
had
a
credit-based
shaper
for
some
time.
It
is
similar
to
the
usual
shaper
you
see
in
IETF.
The
the
only
the
the
basic
difference
is
that
the
max
burst
size
falls
out
of
the
other
parameter.
It
has
only
one
parameter,
which
is
bandwidth
that
you
want
to
output
and
the
max
burst
falls
out
of
that,
and
it's
computable
from
that,
but
it's
basically
familiar
to
what
the
sort
of
things
you
are
used
to.
This
diagram
shows
how
it's
used.
It
shows
two
of
our
typical
mechanisms.
D
D
D
D
D
D
D
The
shapers
will
say:
yes,
I
understand
you
have
something,
but
it's
not
time
to
present
it.
Yet
it's
not
your
turn
yet
so
these
can
be
thought
of
as
filtering
the
I
have
something
to
transmit.
These
guys
are
coming
through
unfiltered
the
time
gates
are
open
and
closed
if
it's
0,
the
fact
that
you
have
something
to
transmit
doesn't
matter.
If
it's
one
you're
allowed
to
pass
through
the
fact
that
you
have
something
to
transmit,
then
priority
selection
starts
at
the
right
and
picks
the
first
one
that
it
sees
starting
at
the
right.
D
That's
the
one
that
gets
selected
for
transmission
and
that's
the
one
you
pick
a
packet
from
to
transmit
these
gates.
Allow
you
to
do
all
sorts
of
things.
I
can
say
only
this
queue
gets
to
go
at
this
time.
Only
this
queue
gets
to
go
at
this
other
time.
I
can
have
critical
functions,
I
transmit
them
at
this
time.
I
don't
transmit
them.
At
this
time,
I
can
reserve
one
of
these
queues
for
a
particular
flow
say
at
this
moment.
I
want
to
transmit
from
that
flow
so
that
I
can
get
essentially
zero
latency
variation.
D
I
can
say
enable
one
thing
that
a
lot
of
people
have
said.
Oh,
but
this
doesn't
allow.
Yes,
it
does
allow
for
this.
I
can
say
the
only
queues
that
are
allowed
to
go.
Are
this
one
critical
queue
and
all
of
the
priority
queues,
and
the
critical
queue,
of
course,
is
higher
priority
than
the
normal
best
effort
queues,
which
means
that
if
I
have
a
critical
packet,
it
will
go.
If
I
don't
have
a
critical
packet,
then
one
of
the
best
effort
packets
will
take
its
place.
D
D
You
can
use
the
output
scheduler
to
control
latency
to
nanosecond
precision
if
your
implementation
is
that
accurate,
it
allows
for
implementations
of
whatever
accuracy
you
out,
but
clearly
with
only
a
few
queues.
It's
not
trivial
to
isolate
particular
streams
or
particular
packets.
If
you
only
have
eight
queues,
if
you
can't
figure
out
what
to
do
with
that
you're
not
too
bright
how
to
improve
that
other
uses,
we
can
use
that
to
time
share
a
link
or
a
network.
D
D
Let's
just
talk
about
one
pair
alternately,
4
or
5
is
enabled.
Never
both
and
I,
swap
them
back
and
forth,
while
4
&
5
were
enabled.
Also.
The
best
efforts
are
also
enabled.
So
if
I
don't
have
any
critical
traffic's,
the
best
effort
gets
to
go
through
what
I
do
is
I
synchronize,
all
the
relay
nodes
and
each
node.
The
critical
traffic
is
double
buffered.
D
I
F
F
Basically,
you
may
stop
transmitting
a
preemptable
frame
while
you
transmit
some
Express
frames
and
then
you'll
pick
up
transmission
of
it
and
the
Mac
will
basically
hold
on
to
the
frame
until
it's
got
the
whole
frame.
So
the
only
thing
that
comes
and
out
of
the
max
in
this
case
is
whole
frames,
so
the
schedule
traffic
is
like
rocks
in
the
transmission
time.
F
It's
in
moveable
now
you'd
like
to
use
as
much
of
the
rest
of
the
time
as
you
can
to
transmit
efficiently
the
other
traffic,
the
traditional
traffic,
if,
if
you
didn't,
have
preemption,
basically
what
you'd
have
is
what
you
see
in
this
figure,
which
is
okay,
I've
transmitted
packet.
One
I
would
like
to
transmit,
but
there's
not
enough
time.
I
can't
transmit
it.
I
have
to
transfer,
wait
and
just
transmit
this.
Oh
here's
another
gap,
but
it's
not
big
enough
for
packet.
Two
again
so
I
just
have
to
sit
on
it.
F
Okay,
now
I've
got
enough
time
to
transmit
it.
That's
not
very
efficient.
So
what
we
do
with
preemption
is
we
allow
the
preemptable
traffic
to
fill
in
the
space
between
the
rock
like
sand,
filling
the
space.
So
basically,
now
with
preemption
I
can
go
ahead
and
start
packet
to
transmit.
The
scheduled
traffic
then
resume
to
start
three
scheduled
traffic
finish
three,
so
it
lets
us
utilize
all
that
space
between
the
rocks.
F
So
the
other
issue
we
have
is
that
you
can't
cramped
a
frame
immediately.
It
takes
some
time
to
actually
realize
you've
got
another
frame
there
preempt
it
have
an
IP
G
and
then
let
the
traffic
start.
We
would
like
to
be
able
to
transmit
scheduled
traffic
when
it's
going
to
be
there,
so
we
would
like
to
go
ahead
and
preempt
ahead
of
time.
So
we
have
a
primitive
called
hold
that
comes
down
through
the
service
interface
and
says:
I
want
I'm,
gonna
I
want
to
preempt.
F
So
there's
no
packet
here,
yet
no
Express
packet
here
yet
to
send
but
hold
causes
the
preemption
to
take
place.
The
gets
preempted
you
have
the
IPG
and
then
the
scheduled
traffic
can
go
and
then
maybe
you
have
a
few
scheduled
packets
to
send
and
then
you
get
release
and
then
you
can
go
ahead
and
after
the
inter
frame
gap,
go
ahead
and
restart
transmission
of
the
packet
that
you
interrupted.
So
so,
basically
again,
this
is
allowing
us
to
make
the
most
of
that
space
while
keeping
the
scheduled
traffic
undulate.
F
F
So,
as
I
mentioned
only
whole
packets
are
crossing
the
mac
service
interface,
and
then
it
comes
down
here
to
this
mac
merge
sub
layer,
which
is
what
actually
implements
the
preemption
and
the
fragments
only
exist
on
the
wire
in
the
physical
layer
between
the
two
Macs
and
the
receiving
mac.
Then,
once
it's
got
the
whole
preemptable
frame,
it
goes
ahead
and
transmits
it.
It
sends
it
up
to
the
through
the
service
layer
to
what's
above
it.
Okay,.
A
F
A
model
yeah,
the
logic
that
exists
in
the
mac
is
theoretically
there
twice
now.
Actually
you
don't
really
need
to
duplicate
all
the
gates,
but
but
what
you
do
need
to
duplicate
is
all
all
the
variables
that
handle
yeah
the
transmission
of
the
frame.
So
so
it
is
very
much
like
you,
because
you're
transmitting
an
express
frame
and
you've
got
a
pram
frame
that
you're
holding
on
to
it's
very
much
like
you
have
two
frames
being
processed
at
the
same
time.
F
Bits
are
only
moving
from
one
of
them
at
a
time,
but
but
you
have
all
the
state
to
preserve
about
the
preempted
frame,
as
well
as
the
state
for
the
Express
frame
that
you're
transmitting.
So
in
terms
of
the
state
variables.
It
is
very
much
like
you
have
to
max,
though
I
think.
If
one
applies
one
sells,
one
can
see
that
one
doesn't
actually
have
to
duplicate
all
the
silicon.
F
R
Yeah,
so
the
configuration
part
this
is
mentioned
in
the
flow
information.
What
they're?
Really?
We
are
running
out
of
time
that
we
have
a
disability,
reservation
protocol
and
I
wanted
to
get
to
the
summary
and
the
discussion.
So
as
we
explained,
we
have
some
new
new
queueing
techniques
in
TSM
and
we
are
combining
two
different
approaches.
The
per
stream
filtering,
shaping
and
tambi
is
the
transmission
and
for
the
certain
time
and
or
mission-critical
applications.
All
these
techniques
should
be
available
for
both
debt
net
at
TSM.
R
Between
the
routers
or
it
can
be
service
provided
by
that
net
support
both
are
in
scope
and
how
do
we?
How
do
we
achieve
that
or
how
do
we
have
leverage
these
all
these
features
when
we
have
both
that
not
an
TSM,
so
that
was
one
of
the
discussion
items
we
have
in
mind.
Pascal
has
doped
another
one,
I,
don't
know
how
much
time
we
have
further
discussion
or
I
think
you
have
one
minute.
U
D
A
Well,
thank
you
very
much.
That's
helpful,
I
think
if
you
could
send
out
a
pointer
to
where
your
service
definition
is,
and
traffic
parameter
definition
is
that
could
help
some
of
the
information
model
discussion.
So
that
would
be
really
good
and
we
understand
that
there's
a
way
to
access
that,
and
it's
pretty
well
known
how
to
find
that
access
information.
A
Thank
you
very
much
for
participation
and
the
good
discussion.
We
will
be
doing
the
first
stage
of
the
adoption
poll
for
the
data
plane
solution,
so
get
ready
to
send
your
comments.
We're
also
likely
to
start
moving
forward
with
the
information
model
with
an
adoption
poll
in
that
mainly
as
a
forcing
function
to
see
where
we
are.
There
engage
the
workgroups
feeling
on
it
with
that,
we
will
see
you
at
the
next
idea.
Thank
you
very
much.