►
From YouTube: IETF100-DETNET-20171116-0930
Description
DETNET meeting session at IETF100
2017/11/16 0930
https://datatracker.ietf.org/meeting/100/proceedings/
B
B
B
Our
agenda
and
slides
are
in
the
normal
place.
Please
feel
free
to
go,
download
them
and
watch
them
as
we
go
through.
We
saw
it
all
start
all
of
our
sessions.
With
the
note
well
we're
late
in
the
week.
You
should
be
familiar
with
it
at
this
point.
Basically,
anything
you
say
here
will
be
part
of
our
permanent
record
and
subject
to
our
IPR
rules.
B
As
usual.
We
are
streaming
audio
and
video.
If
someone
would
mind
jumping
on
jabber,
that
would
be
great
yeah.
No
one
does
I'll
jump
on
in
a
moment.
We
usually
do
our
joint
minute
taking
sort
of
crowd-sourced
minute.
Taking
the
link
is
off,
you
can
see
here
or
it's
easier
to
get
off
the
tools
page
go
to
tools.
Working
group
minutes
you'll
also
find
a
link
to
the
etherpad
they're,
my
Bettis.
If
you,
google,
you'll,
find
it
all
so
please
jump
on
and
contribute.
B
We're
gonna
go
through
a
number
of
our
working
group
documents
and
then
talk
about
a
some
work
that
we're
looking
to
adopt
and
then
some
other
consideration
pieces.
The
last
two
documents
are
our
presentation:
slots
are
really
more
informative
than
work
that
we're
going
to
be
necessarily
taking
on
at
least
immediately
they're.
B
The
norms
documents
talks
a
lot
about
what's
going
on
TSN
and
how
TSN
mechanisms
queuing
might
be
applied
to
debt
net,
whether
that
ends
up
coming
in
as
a
working
group
document
or
not
it's
very
useful
work
either
way.
The
last
piece
is
we're
gonna
hear
on
network
calculus,
which
could
help
inform
how
we
model
some
of
the
parameters
both
in
what's
happening
inside
the
network,
so
things
that
would
support
path
computation
as
well
as
parameters
that
could
be
used
for
describing
our
services.
B
Where
are
we
with
our
documents
with
respect
to
deliverables
and
milestones
the
we
have
three
documents
that
are
pretty
mature?
We
want
to
last
call
them.
The
interesting
thing
is:
is
by
keeping
these
alive,
we
actually
keep
finding
little
pieces
that
we
think
we
understand,
and
we
probably
do,
but
as
new
people
come
in
and
read
the
documents
we
find,
they
don't
understand
what
we
meant
it
to
say
and
in
fact
the
documents
really
don't
say
what
we
think
so
by
keeping
them
alive.
It's
actually
been
good
because
we
can
go
and
fine-tune
these
documents.
B
So
there
really
is
a
trade-off
of
publishing
because
it's
nice
to
have
RFC's
and
the
work
is
done
and
we
can
move
on.
There's
a
trade-off
between
that
and
making
sure
we've
documented
things,
not
only
so
everyone
in
this
room
understands
it,
but,
more
importantly,
so
the
people
that
come
along
next
understand
it.
B
So
we
should
be
thinking
about
that
as
we
go
through
the
last
call
on
the
agenda.
We
have
a
couple
of
our
documents:
the
data
plane
solution.
One
is
going
to
be
a
really
good
and
important
discussion.
We
had
a
lively
debate
on
this
document
at
the
last
meeting
before
adoption
and
we
have
a
lot
of
open
issues
and
we
have
a
good
block
of
time
of
our
agenda
spent
allocated
to
going
through
some
of
those
issues.
And
hopefully
we
can
make
some
good
progress
here,
which
of
course
will
confirm
on
the
Working
Group
list.
B
B
B
So
the
one
of
our
motivations
for
having
a
talk
that
is
not
on
a
draft
but
is
providing
background,
is
to
help
getting
the
work
group
thinking.
So
we
can
get
some
contributions
in
this
area
area
I
remind
folks,
there's
company
for
contribution
driven.
If
you
want
to
participate
in
the
working
group,
you
want
some
new
space
to
add
value.
Here's
a
good
place
to
do
it.
I.
C
So
the
overall
view
of.
Why
do
we
have
a
use
cases
document?
What
is
it?
It
provides
the
industry
context
for
debt
net
goals.
What
are
the
use
cases?
How
are
they
addressed
today?
What
do
we
want
to
do
differently
in
the
future?
And
what
are
we
asking
the
networking
group
and
the
ATF
to
provide
in
order
to
enable
these
things?
The
use
case
is
organized
by
industry,
but
in
addition,
we've
broken
down
the
different
use
cases
into
a
sort
of
set
of
common
factors
which
we
refer
to
as
the
debt
net
common
themes.
C
So
these
are
the
commonalities
between
use
cases
and
as
I,
sell
review.
Those
very
briefly
the
use
case
draft
functions
as
a
yardstick
for
the
functionality
of
any
proposed
designs.
For
example,
it
provides
a
way
to
look
at
you
know
what
is
the
requirement
and
then
what
is
our
solution,
for
example,
architecture
and
so
on?
What
is
it
proposing
and
does
it
will
it
satisfy
the
use
cases?
The
use
case
draft
explicitly
does
not
state
specific
requirements
for
debt
net,
nor
does
it
specify
design
architecture
or
protocols.
C
You
know,
we've
got
a
solution
that
really
looks
about
right,
but
it
doesn't
quite
satisfy
this
one
particular
thing
so
maybe
we'd
have
to
go
back
and
actually
amend
the
use
case
to
say
this
to
say:
well,
no,
that's
not
quite
it
so
there
there
is
been
that,
but
so
far
there
haven't
in
recent
years
in
the
recent
years
since
the
last
update
there
hasn't
been
any
such
correction
required.
So
that's.
C
So
we
have
three
new
use
cases
which
were
introduced
in
the
last
few
months.
These
are
the
private
blockchain,
the
mining
as
in
mining
for
or
not
as
in
data
mining
and
network
slicing
and
again
it's
not
a
complete
solution
for
Network
slicing,
but
it
provides
some
useful
technologies
for
developing
network
slicing
infrastructure.
C
D
C
The
basic
premise
is
but
they're
interesting
to
keep
in
mind
that
these
this
list
exists
and
that
these
are
discussed
in
the
use
case
Draft.
This
is
page
one
or
two.
There
is
another
page,
but
the
idea
is
that
these
this
list
also
serves
to
inform
the
security
draft,
because
one
of
the
things
that
we've
done
in
the
security
draft
is
to
look
at
each
of
these
particular
sort
of
properties
that
this
kind
of
network
would
have
and
what
sorts
of
security
issues
are
there
organized
against
these
individual
properties.
C
In
addition
to
what
are
the
security
issues
that
might
be
associated
with
a
given
use
case
by
industry,
so
this
is
a
good
overview
of
just
a
different
way
to
to
organize
the
way
the
goals
of
debt
net.
So
the
mining
use
case
again.
I'm
gonna
go
only
very
briefly
through
these
use
cases,
I'm
not
really
doing
them
justice,
but
just
to
have
a
brief
overview
of
what
they
are
so
for
the
mining
is
case.
C
If
you
imagine
a
sort
of
a
large
open
like
a
pit
mine,
we've
got
a
huge
area
filled
with
large
machines,
digging
ground
and
moving
earth
around
and
putting
up
big
piles
of
stuff.
It's
a
very
dangerous
place,
and
the
trend
in
recent
years
has
been
to
automate
all
of
this,
so
that
the
people
are
actually
remote
and
they
operate
all
this
equipment.
You
know,
via
video
links
that
you
know
show
what's
going
on
from
the
view
of
a
piece
of
machinery,
and
then
they
operate
the
machinery
with
levers
from
a
distance.
C
So
there's
a
lot
of
real-time
wired
and
wireless
communications
going
on
between
these
machines
and
in
addition
to
all
that,
going
on
there's
a
lot
of
sensors
distributed
throughout
the
area
to
determine,
for
example,
if
a
given
pile
of
something-or-other
is
likely
to
be
moving
or
becoming
unstable.
You
want
to
know
that
so
a
lot
of
these
sensors
are
using
this
lp1
type
stuff
to
to
move
those
there's
also
voice
communications
among
various.
You
know,
people
along
the
different
stations
or
monitoring
all
this,
so
the
idea
would
be.
C
C
C
But
the
point
is
that
it's
a
process
that
can
be
done
on
a
corporate
network,
not
just
the
the
Bitcoin
blockchain,
that's
on
the
open,
Internet,
it's
specific
applications,
of
which
there
are
actually
quite
a
number
that
in
which
you
can
facilitate
the
process
of
what
they
call
consensus,
where
the
computers
systems
have
to
talk
to
each
other
and
move
information
very
rapidly
and
reliably
between
them.
It's
usually
not
a
ton
of
information,
but
the
latency
is
important
and
the
packet
let
negligible
packet
loss
is
important.
C
So
all
of
these
these
things
contribute
to
useful
to
be
useful
in
blockchain,
so
for
network
slicing
again
debt
net.
Isn't
it's
not
exactly
a
pure
application
of
it?
But
if
you
look
from
the
bottom
of
the
pyramid
of
requirements
going
up,
you
find
that
the
requirements
and
developed
network
slicing
infrastructure
include
being
able
to
have
guaranteed
bandwidth,
low,
latency
lopat
packet
loss.
C
E
Growl
I
think
Greg
murska,
ET,
I
I
agree
that
yes,
network
slicing
has
one
use
case
or
okay,
one
area
of
use
cases
that
referred
as
ultra-low
latency
and
jitter
because,
for
example,
new
mobile
backhaul
doesn't
really
have
strict
latency
packet
loss
requirements,
it's
just
bigger
pipe
and,
for
example,
massive
il
T
might
not
have
very
strict
requirements:
industrial
IOT,
which
falls
into
the
first
low
latency
jitter
scenario.
Yes,
so,
basically
out
of
three
scenarios
that
identified
by
3gpp,
one
definitely
fits
deadline.
E
B
C
A
Toula
sacred
I
am
so
to
me
it's
it's
very
simple
right.
If
somebody
wants
to
have
dead
net
services
and
a
service
provider
needs
to
provide
them
in
a
you
know,
virtualized,
environment
and
slicing
is
the
new
password
how
to
define.
You
know,
virtualized
environments
that
can
provide,
let's
say,
hop-by-hop
guarantees
right.
But
to
me
it's
it's
not
quite
clear
if
it's
a
new
use
case
by
itself
right,
it's
just
a
virtualization
of
a
dead
net
service.
A
If
all
the
services
people
want
to
have
from
slices
are
not
dead,
definite
services,
but
any
other
services,
like
even
you,
know,
low
latency.
Whatever
you
know,
guarantees
that
somebody
wouldn't
called
Aetna
today,
then
you
know
they
could
also,
in
my
opinion,
be
provided.
You
know,
through
a
slicing
architecture
that
doesn't
rely
on
dead
net
underneath
so
I
think
that
that
is
my
claim,
I'm,
not
hundred
percent
sure
right.
A
So
the
question
is:
if
all
the
services
required
by
slicing
are
non
dead
net
services,
if
you
would
implement
them
natively,
would
you
still
be
able
to
make
a
case
that,
in
the
slicing
environment,
you
need
underneath
more
dead
net?
That
would
be
making
it
a
real
use
case.
Otherwise
it's
just
a
virtualization.
You
know
way
of
whatever
dead
net
service
you
have
in
before.
C
Well,
that's
a
good
point
and
I
think
one
way
that
they
was
phrased
was
that
dead
net
is
a
candidate
technology
for
use
in
the
infrastructure
of
network
slicing
and
so
I
think
in
that
case.
Yes,
it's
not
a
not
a
pure
use
case.
If
people
feel
that
it's
not
appropriate
to
have
that
in
your
please.
Let
us
know
on
the
list
and
you
know
we
can-
we
can
discuss
it,
discuss
it
further.
So
I
have
one
more
slide
that
briefly
discusses
network
slicing,
but
I'm
not
I'm
not
really
going
to
go
into
it.
C
But
the
point
is
it
provides
the
technology
for
providing
isolation
between
slices,
in
that
sense,
functional
performance,
security
again
and
perhaps
the
ways
that
debt
net
enables
you
to
specify
a
number
of
redundant
paths
and
so
on
could
help
with
with
reliability
and
so
on.
So
that's
a
matter
of
implementation,
I
guess
anyway,
that's
what
I
have
I.
B
F
C
F
So
the
point
I
was
making
was
that
you
were
asking
about
whether
this
should
be
in
the
document.
Having
looked
at
the
problem
for
quite
some
time,
I
think
absolutely
it
needs
to
be
in
the
document.
It's
a
perfect
match
for
something
that
we
know
that
5g
is
asking
for,
and
it
will
be
a
real
mistake
if
we
took
this
out.
Thank.
G
G
This
is
the
outline
of
the
draft
we've
presented
this
a
couple
of
times
in
the
past
ITF
meetings,
and
these
are
the
main
sections
in
the
draft
or
the
main
themes
in
the
draft
security
threats.
Basically,
what
are
the
possible
attacks
on
deterministic
networks
impacts
of
these
security
attacks,
which
means
what
happens
if
there's
a
successful
attack
mitigations,
which
means
what
what
we
can
do
to
try
to
mitigate
or
to
prevent
some
of
these
attacks?
G
G
The
main
differences
between
the
previous
version
and
the
current
version,
so
there
are
two
main
differences.
First
of
all,
in
the
impact
section,
significant
changes
were
made
in
this
section.
First
of
all,
a
lot
of
clarifications,
and
also
we
revised
the
impact
to
use
case
mapping
we'll
talk
about
that
in
a
minute.
G
G
Okay,
so,
like
we
said,
impact
means
what
happens
if
there
is
a
successful
security
attack.
So
basically,
one
of
the
things
we
see
in
the
impact
section
is
a
mapping
between
impacts
and
use
case
industries.
So,
in
each
column
of
this
table
you
will
see
a
different
use
case
industry
and
then
each
row
kind
of
shows
a
different
type
of
impact.
G
So,
for
example,
if
we
look
at
the
first
row,
we
see
the
criticality,
so
we
can
see
for
each
industry
whether
the
criticality
of
a
successful
security
attack
on
that
net,
whether
it's
medium
high
or
low,
and
on
the
second
row
we
see
the
financial
impact
and
so
on.
So
it's
this
kind
of
shows.
You
know
mapping
of
what
are
the
impacts
of
each
type
of
industry,
so
this
is
something
that
was
significantly
revised
in
the
current
version.
G
Another
aspect
is
the
section
that
map's
the
attacks
to
use
cases,
so
we
kind
of
have
a
sub
section
about
each
use
case
theme
and
what
we
had
in
the
previous
version
was
that
for
each
use
case
theme,
we
had
kind
of
an
outline
of
what
are
the
topics
that
we
plan
to
discuss.
It
was
phrased
in
the
form
of
a
set
of
questions,
so
in
the
current
version
in
this
text
was
significantly
revised.
We
have
more
detailed
text
which
maps
for
each
of
the
use
case
themes.
G
So
at
this
point,
looking
forward
the
next
steps
we
we
were
thinking
about,
we
would
like
to
discuss
with
the
working
group.
First
of
all
so
far,
the
format
we've
been
working
on
is
kind
of
a
design
team.
It's
not
formally
a
design
team,
but
it's
a
group
of
people
who
met
periodically
and
worked
on
the
document
and
now
that
they're
working
of
now
that
it's
a
working
group
document
were
kind
of
reconsidering
this
format
we're
in
urging
people
who
are
interested
in
this
work
to
join
us
to
contribute.
So
that's
one
aspect.
G
Another
thing
is
that
we
would
like
to
encourage
a
lot
of
reviews.
Okay,
we'd,
like
people
to
read
the
document,
to
try
to
see,
what's
missing,
to
try
to
see
what's
wrong.
So
as
many
reviews
at
this
point,
it
would
be
best
it
would
improve
the
document,
and
this
is
a
good
time
for
anyone
who
hasn't
read
the
document.
Yet
this
is
a
good
time
to
read
it,
and
also.
Another
aspect
that
we
need
to
look
into
in
the
near
future
is
what
the
data
plane
design
team
has
been
working
on.
E
You
greg
Mirsky
City
I,
just
want
to
ask
you
what
you
think
of
they
were
a
threat
or
importance
on
attack
on
OAM,
because
om
will
be
used
for
SLA
assurance
in
a
dead
net,
and
if
somebody
skews
your
measurement
that
will
trigger
false
negative
okay.
So
do
you
think
that
it
because
again
I
understand
this
is
a
generic
problem.
It's
not
the
problem
specific
to
that
net,
but
is
it
reasonable,
at
least
to
mention
that
om
can
be
vector
of
attack
to
destabilize
that
net
environment.
G
E
Think
well
again,
that's
depends
on
how
important
the
performance
measurement
is
for
the
environment,
because
SLA
and
SLA
assurance
for
that
net
is
important.
Then
it
might
be
really
used
to
base
their
boys
because
in
some
networks
they
do
performance
measurement
only
for
the
billing
right
here.
The
performance
measurement
I
can
envision.
That
will
be
determined.
E
G
G
F
You're
going
to
get
as
a
result
of
an
inadvertent
switchover,
you're
going
to
get
J
delay,
jitter
changes
as
well
and
in
fact,
actually
that
I
don't
remember
seeing
you
there,
but
we
may
want
to
look
at
some
of
the
conversions
control
technologies
in
the
underlay
in
order
to
preserve
those
characteristics
in
the
network.
Absolutely
agree.
E
B
In
terms
of
formats,
there's
nothing
wrong
with
holding
meetings
of
people
who
are
working
on
the
document.
Authors
now
that
we've
switched
to
a
design
team,
sorry
away
from
the
design
team
format
into
the
working
group
document.
It
would
be
good
if
you
publish
when
you're
gonna
have
those
meetings
and
open
them
up
to
the
working
group.
If
you
don't
just
remember
that,
any
decision
taken
by
a
set
of
authors
is
not
a
decision
by
the
working
group
and
you
need
to.
B
If
you
come
to
some
agreement
on
a
position,
you
should
take
it
to
bring
that
to
the
working
group
present
the
proposed
changes
and
see
what
the,
if
there's
any
feedback
on
the
list.
So
that's
really
important,
but
there's
nothing
wrong
with
with
having
authors
meetings
so
don't
feel
like
you
should
stop
that,
particularly
if
it
helps
progress.
The
document,
in
terms
of
terms
of
your
comment
on
soliciting
a
wider
input
I
think
that's
just
right.
B
One
of
the
things
I'd
like
to
ask
the
working
group,
as
well
as
the
author's
to
when
they're
reading
the
document
for
the
first
time
or
reading
it
again,
is
to
look
very
carefully
of
what
is
being
discussed
if
it's
in
scope
or
out
of
scope
of
what
we're
doing
here,
for
example,
we're
not
doing
control
plane.
Yet
that's
out
of
scope
where
we
are
right
now,
but
we
might
do
it
in
the
future.
So
maybe
that's
something
that
belongs
in
an
appendix
but
not
the
core
of
the
document.
B
B
H
I
I
I
So
we
got
a
very
thorough
review
from
Stuart,
so
thank
you.
So
I
recorded
down
some
30
40
plus
comments
in
the
document,
so
those
who
up
in
reading
this
also
document
can
find
those
comments
embedded
in
the
current
0
0
version
of
the
draft
and
then
there's
been
some
what
we'll
be
discussing
on
the
email
list.
B
B
The
particular
question
was
related
to
whether
or
not
network
coding
was
in
scope
or
out
of
scope,
and
the
answer
is
that
is
it
in
scope?
We
don't
expect
to
be
working
on
it
for
a
while,
but
if
there's
a
proposal
for
it
after
thing,
other
things
have
stabilized
that
could
come
in
to
satisfy
that
last
service.
Alright
I'm
on
the
next
slide.
Okay,.
J
Basically,
well,
net
recording
is
mentioned
in
the
architecture.
It
doesn't
mean
that
we
have
to
implement
it.
What
we
have
in
the
architecture
is
very
interesting
for
positioning
functions,
whether
we
implement
them
or
not,
but
I
think
it's
it's
good
and
we
need
to
keep
the
network
coding
positioned
inside
the
architecture.
So,
if
people
think
about
it,
they
need
to
know
where
it
is
and
what
it
does.
I
So
in
the
solution
document
we
be
currently
describe
two
solutions,
so
we
had
the
RPGs
encapsulation
and
then
we
have
the
transport
solution
that
this
is
based
on
a
suit
existing
pseudo
wires
and
the.
If
you
read
the
document
and
how
it
starts,
the
ipv6
interpolation
is
mostly
intended
for
the
M
native
I
pivoted
end-to-end
it
in
service
cases
where
the
end
system
are
dead.
I
Net
over
an
input
and
output
am
didn't
service
flows
Italy
using
the
ipv6
traffic,
and
then
we
have
this
other
wire
encapsulation
that
the
one
of
the
use
cases
that
we
address
here
is
the
year.
The
emulated
decent
service
saw
the
island
interplan,
but
it
doesn't
exclude
that
you
could
actually
talk.
The
insistence
would
natively
talk,
pseudo
wire
based
encapsulations.
I
I
So
the
DDM,
the
the
first
question
that
I
have
for
the
working
group
kind
of
going
forward
on
how
to
model
the
document
in
the
future
is
like
a
suit.
The
data
plane
solution
aim
for
a
unified
on
wire
format,
for
the
service
layer,
so
for
ipv6,
and
then
the
something
else
that
is
is
23
cents
or
MPLS.
I
F
That
part
of
the
answer
lies
in
whether
these
are
the
only
two
that
we
need
to
support.
So
if
it
turns
out
that
there's
some
industrial
format
that
we
also
need
to
support
or
plain
old-fashioned
v4
needs
to
be
supported
that
tends
to
push
you
in
one
direction.
If
these
are
the
only
two
that
you
need
to
support,
then
doing
an
optimized
one
for
each
one,
prob
possibly
makes
sense.
It
depends
how
many
others
that
we
might
need.
I
I
I
I
F
So
she
Stewart
again
I
take
the
view
that
if
customers
need
v4
and
in
a
lot
of
legacy
worlds,
they
might
I
suppose
we
should
support
it.
I,
don't
think
we
should
use
this
as
an
excuse
not
to
service
customer
need
I,
don't
know
whether
they
do,
but
we
really
need
to
be
clear
on
whether
it's
needed.
Yes,
the.
B
Question
is
to
me
is
whether
we
support
it
as
an
end-to-end
debt
net
service
or
as
a
yet
another
TSN
service,
that's
being
carried
over
debt.
That
and
I
think
we've
taken
to
position
the
latter
position,
I'm
not
saying
it's.
The
right
position
base
I,
think
that
that's
the
direction
we've
been
headed
down.
If
we
want
to
do
something
different,
that's
a
good
thing
to
raise.
B
B
B
Talking
about
pseudo
wires,
or
should
we
just
be
talking
about
what
is
it
that
the
data
plane
looks
like
and
not
being
worried
about
being
tied
to
the
all
the
seed
of
pseudo
wire
references
and
I
think
it
would
be
good
to
hear
from
the
group
on
that
and
I'm,
not
sure
if
you're
gonna
get
to
that
yoni
later
or
if
this
is.
What
you
were
thinking
of
also
covering
in
this
path
is.
I
Oh
so
I
have
some
some
clones
later
on
apart.
So
then
other.
Let's
defer
to
the
conversation
that
yeah
so
but,
as
I
said,
I
try
to
kind
of
go
into
that
that
direction
so
I
rather
interesting
in
the
on
wire
format
and
I'm
at
least
the
kind
of
semantics
on
certain
thing
that
I
can
extract
from
the
flow.
So
given
some
technologies,
I,
don't
really
I.
I
Don't
think
that
we
should
actually
care
that
much
how
how
packet
cut
into
some
point
as,
but
it
came
over
the
MPLS
or
whether
it
came
over
IP
or
something.
So
if
we
can
unify
the
step
further,
that
that
our
did
not
specific
for
for
certain
time
processing
on
the
service
layer
that
that
would
be
great,
because
then,
then
you
can
actually
have
reuse.
D
I
I
B
You
only
one
second,
okay,
so
I
respect
to
this
specific
question
of
whether
or
not
it
you're
asking
just
that.
I
want
to
make
sure
we're
all
clear
where
you're
asking
for
feedback
on
whether
we
should
stick
with
the
current
approach
or
try
to
go
back
to
the
original
idea
of
having
a
single
unified
on
wire
format.
I
haven't
had
a
lot
of
comments
in
the
room,
but
no
one
is
objecting
the
current
definition
of
using
different
formats
on
the
wire
as
long
as
it
matches
the
the
dead
net
service.
B
E
Okay,
Greg
Mirsky,
GT
I
think
it
our
work
much
more
easier
and
documents
more
readable.
If
we
extract
that
net
layer
definition
in
one
document
and
then
we
might
have
that
net
over
different
technologies
as
separate
documents,
it's
it's
very
similar
to
what's
done
in
other
groups
like,
let's
take
I,
don't
know
segment
routing.
There
is
segment
rounding
MPLS
and
there
are
segment
routing
ipv6.
E
B
I
I
This
is
actually
to
the
bigger
question
now
so
like.
Currently,
we
have
ipv6
and
the
MPLS
based
and
same
document.
So
following
what
Greg
said.
So
this
is
another
question
question
number
tree.
So
should
we
split
that
into
two
troughs?
So
what
we
have
currently
so
basically
saying
that
every
time
we
have
a
different
type
of
transport
data
plane
solution,
we
just
spin
out
a
new
document
that
describes
the
details,
how
you
encode
that
information
and.
L
H
What
I
heard
what
I
heard
was?
Yes,
we
should
split
it
out
into
separate
documents
and
I
didn't
hear
any
objections
to
splitting
it
in
two
separate
documents.
I
think
I
heard
the
suggestion
that
it
should
actually
be
three
documents:
kind
of
with
a
I
guess,
an
overview
document,
one
for
each
encapsulation.
I,
don't
know
I'm,
not
sure
whether
we
need
that,
because
we
already
have
like
architectural.
I
And
other
things
I'm
myself
in
favor
of
two
documents,
because
we
have
all
the
architects,
the
documents
and
so
on
that
we
know
actually
won't
be
aiming
for.
We
just
need
to
kind
of
okay.
The
discussion
on
T
is,
for
example,
the
elimination
so
to
pref
part
that
norm
is
going
to
have
their
own,
that
that
might
change.
B
That
seems
reasonable,
I
think
the
author
should
be
allowed
little
flexibility
as
to
when
they
do
the
exact
split.
You
know
this
is
not
we're
not
like
about
the
last
call
it.
So
it's
if
you
think
it
makes
sense
to
do
one
two
or
three
versions
and
then
do
the
split.
That's
great
yeah,
but
I'd
asked
start
noting
at
least
put
in
a
comment
that
this
document
is
gonna,
be
split
and
noting,
where
that,
where
things
are
gonna
end
up.
J
You
need
you,
you
mentioned
in
question
to
a
split
between
the
lower
layer,
functionality
and
your
parallel
functionality,
likes
service,
commands,
etcetera
and
I.
Think
that's
that's
back
to
the
discussion
of
having
layers
and
and
what
belongs,
which
layer.
This
particular
document
is
addressing.
As
long
as
you
you
talk
about
frame
encapsulation
and
in
formats
I
agree.
These
are
those
two
documents
we
want
to
do
and
I'm
competing
with
that.
We
jump
in
your
head
of
what
Nam
whisk
is
going
to
talk
to
about
and
what
I'm
going
to
talk
about.
J
There
are
all
your
services
that
I
don't
think
they
belong
to
either
of
those
documents,
but
that
those
other
work
which
is
taking
place
above
it
belongs
to
the
traditionally
earthly
or
three
which
we
are
doing
here
and
some
of
it
belongs
to
a
barriers
and,
and
they
happen,
I'll
be
somewhere
else.
We
don't
have
to
put
all
this.
B
J
I
I
The
en,
as
pseudo
virus,
so
so
along
to
discuss
analyze
value,
writing
the
a
solution
document
we
kind
of
found
out
the
three
best
describe.
What
what
the
es
who
the
water-based
solution
could
be
and
so
saying
that
the
drivers
behind
why
we
actually
went
for
through
the
wild
based
solution.
The
first
place.
They
were
quite
practical.
So
we
found
a
transport
thing,
was
two
tasks:
a
controller,
a
sequence
number
and
existing
standards.
For
that,
and
we
have
a
clear
description:
how
the
sequencing
works.
I
I
It
has
been
brought
in
to
attend
attention
multiple
times
that
we
could
explore
so
model
the
transfer
based
on
the
EVP
ends
and
nowadays
that
you
can
actually
also
had
the
a
control
bird,
it's
recommended
in
India,
a
2-14
and
or
that
if
we
could
come
up
with
something
new
that
that
mom
gave
a
name
as
a
tenant
wire
so
on-
and
this
seems
to
be
a
sticky
point.
So
we
need
to
kind
of
make
a
decision
which
way
we
go
in
the
future.
I
So
next
slide
and
if
you
keep
mind
the
layering
and
the
services
that
the
data
plan
is
to
provide
for
the
connected
service
layer.
So
one
of
the
key
functions
that
we
need
is
going
to
be
the
sequence
number
so
that
we
had
the
possibility
of
finding
splitting
flaws
and
finding
it
obligates.
So
good.
That's
about
the!
Why
we
keep
up
pushing
this
the
Seekers
numbering
and
do
that
Netflix?
I
64,000
numbers
you
support,
but
in
our
attempt
to
reuse
existing
of
four
four
four
eight
just
pointed
out,
rightfully
that
the
zero
is
a
reset
number.
This
kind
of
we
missed
so
and
if
we
in
a
future,
want
to
inter
work
in
any
way
with
the
existing,
a
layer,
two
technologies
that
already
deploy
TEDMED
services
and
the
public
eight
elimination
things
like
that,
they
all
are
seem
to
follow
a
single
sample
space.
So
if
we
end
up
using
a
technology
that
has
reserved
numbers
like
0
interworking
with
those
is
going
to
be
very,
very
challenging.
I
So
the
question
number
for
that
I
have
relates
to
this.
This.
How
we
encode
to
see
this
numbering
to
get
not
close
is
like
a
so
that
that-
and
this
is
specifically
in
the
in
the
context
of
MPLS
based
solution
and
and
reusing
the
existing
standard
that
we
have
for
for
EVP
ends
and
the
pseudo
wires,
which
is
basically
RFC.
Four
four
four
eight
is
that
is
that
actually
usable?
I
So
if
we
need
to
define
a
use,
one
from
word
type
solution
that
would
fit,
for
example,
into
so
the
wires
or
EVP
and
whatever
we
chose
for,
should
we
go
there
and
and
just
define
our
ol,
let's
say,
control
type
of
solution
and
the
if
we
go
that
route.
Will
that
be
an
issue
when
we
look
into
modeling
this
solution
over
to
the
wires
or
a
VPN?
I
So
basically,
do
we
try
to
reduce
extinct
standard
on
this
record
or
just
go
for
and
design
something
of
our
own
Thurston
or
for
question
and
the
then,
depending
on
the
answer,
we
go
for
a
new,
controversial
custom.
Five.
Will
that
implicitly
mean
that
net?
What
we
have
come
to
define
is
not
sort
of
war.
B
F
I
was
I,
mean
I
thought
we
were
dealing
with
these
slide
by
slide.
So
it's
just
you
it
again.
So
a
question
first
question
I
got
to
ask
you
is:
do
you
think
you
need
to
put
anything
other
than
Ethernet
over
this
service,
because
if
you
think
that
we
might
have
to
carry
some
other
legacy
service,
then
there'd
be
a
lot
to
be
said
for
staying
with
the
pseudo
wire
format,
at
least
the
format
as
emitted
by
the
by
the
TPE,
because
both
silicon
can
already
do
those
sorts
of
things.
F
The
issue
of
skip
zero
is
irritating,
but
it's
not
catastrophic
right.
There
are
it.
You
can
do
it.
You
just
have
to
recognize
that
you've
got
zero
and
you've
got
one
less
than
64,000
in
your
room
in
your
sequence.
Number
and
the
thing
just
you
know
skips
it
on
the
one
side
and
interprets
it
differently
ever
sees
one.
F
So
I
don't
think
that's
catastrophic
in
terms
of
continuing
to
use
four
four,
four,
eight
in
terms
of
using
the
evpn
system,
you
have
to
remember
that
there
is
nothing
even
remotely
analogous
to
the
SP
e,
so
I'm
not
sure
what
is
driving
you
to
that,
but
certainly
is
nothing
analogous
to
the
SPE,
but
really
the
SPE
is
the
wrong
concept.
I
think
we
need
to
think
about
replicators
and
eliminators
put
in
the
the
network
and
I
think
that
that
would
be
a
better,
a
better
approach
to
introduce
a
different
object.
B
B
F
Whether
T
Pease
of
the
right
construct,
I,
don't
know,
and
the
net
will
detent
that
will
depend
on
whether
you
want
to
carry
other
wire
types
besides
Ethernet
across
this
service,
with
these
reliability,
characteristics
and
I,
don't
know
the
answer
to
that
question.
If
you
do
there'd
be
a
lot
to
be
said
for
staying
with
the
t,
PE
design
and
just
having
a
different
different
object
in
the
network,
that's
not
an
SPE.
I
Regarding
the
the
the
super
SPE
discuss
on
the
desert,
that's
basically
the
question
number,
seven
and
and
and
I
think
that
norm
is
going
to
have
a
lot
to
say
about
the
earth.
The
key
functions
that
we
had
call
it
is
PE
when
it
comes
to
a
replication
elimination
so
that
that's
part
most
part
of
the
next
discussion,
skipping
reusing,
the
4,
4,
4,
8
and
0,
not
being
part
of
it
and
that's
not
being
catastrophic
I
myself
kind
of
agree
on
that.
I
F
I
H
K
This
is
norm
Finn.
Let
me
say
something
about
the
skipping
0.
If
it
can
be
an
issue,
if
the
result
is
that
every
64k
packet
gets
delivered
twice,
that
may
or
may
not
be
a
disaster,
it
depends
on
the
application.
If
the
result
is
that
every
61,
every
64,000
packets,
you
drop
a
packet
and
it
doesn't
get
delivered,
that's
way
way,
WAY
worse
than
our
goal,
for
that
that
would
be
terrible
okay,
so
it
has
to
be
dealt
with.
Somehow
we
have
to
figure
out
what
it's
going
to
do.
K
Okay,
I
would
be
reluctant
to
deliver
them
twice
because
that's
for
some
applications,
that's
not
going
to
be.
You
know
that
if,
if
the
packet
is
flipped
the
switch
and
they
need
this
reliability
because
they
have
a
really
stupid
protocol
that
says
flip
the
switch
and
said
have
said
it
too
on
or
set
it
to
off,
and
that
can
be
a
disaster,
so
it
we
got
to
deal
with
it.
K
B
I
Okay,
so
this
doesn't
3%
the
whole
team,
so
this
represents
me
so
I
don't
have
an
issue
defining
and
using
so
that
that
so
really
using
documents
is
okay,
but
the
what
norms
ends
about
reusing
the
gates
and
antiques
dissolution,
so
having
them
counter
to
the
implementation
not
to
skip
zero,
might
be
actually
an
easier
solution
at
the
end.
Would
you
not
be
a
point
of
yourself.
K
Yeah
norm
Finn.
This
is
this
is
obviously
a
rathole,
because
it's
so
easy
to
understand.
Everybody's
kind
of
opinion
I
believe
that
one
of
the
really
things
that
we
really
need
to
do
is
there
that
there
are
a
lot
of
deployed
applique
there.
We
want
to
capture
those
applications
and
move
them
to
bigger
better
networks
and
to
capture
those
applications.
K
J
We
have
a
clearly
delineated
architecture
where
we've
got
a
device
somewhere
at
the
edge
of
the
network.
Awesome.
We
do
point
in
a
network
that
does
the
sequencing
and
that
the
UI
Stokes
layoffs
today
or
to
a
device
that
elimination,
that's
very
clear
in
the
architecture
and
putting
any
semantics
for
the
lower
layer
about
what
those
two
guys
say
when
they
set
up
a
sequence
number
is
a
layer
violation.
J
If
that's,
why
we're
hitting
all
those
prongs,
we
should
leave
those
two
guys
put
whatever
they
want
and
like
we
said
it
depends
on
the
semantics
and
even
if
they
want
to
put
it
as
a
non
sequential
number,
I
mean
for
defeat
against
whenever
they
should
have
their
home
place,
where
they
can
put
this
sequence
and
the
rest
of
the
world
should
see
that
as
a
no
bug
that
just
blindly
transport
it.
We
should
not
be
talking
about
the
authority
of
semantics
in
this
room.
Yeah.
B
We're
just
to
be
clear
that
the
point
is
is:
if
we,
if
we
don't
skip,
if
we
allow
zero,
we
might
be
able
to
send
less
bits
on
the
wire
and
that,
if
we
have
to
skip
zero
means,
we
we
definitely
have
to
add
some
bits
on
the
wire.
So
this
is
an
optimization
question
whether
or
not
we're
restricting
what
the
user
of
that
net
and
carrying
her
consent.
All.
D
B
Okay,
so
I
think
we
have
direction.
Yes,
we
go
to
resolve
here.
The
first
is:
are
we
we
want
to
be
constrained
with
the
this
thing
semantics
of
the
pseudo
wire
definition
that
requires
skipping
of
zero
since
I'm
getting
from
the
discussion
is
that
we
don't
want
to
be
constrained
to
skip
0
and
that
0
should
be
treated
at
just
another
value.
Yep,
okay,
I'd
like
to
see
if
anyone
disagrees
so
I,
don't
hums,
don't
work
for
my
ears,
so
I'm
gonna
ask
people
to
raise
hands.
This
is
get
it
a
feel
for
the
room.
B
F
F
F
B
J
Let's
go
again
the
semantics
of
what
this
sequencer
and
the
Eliminator
use,
and
that
could
be
multiple
implications
and
doing
very
different
things.
One
could
jump
everywhere.
It's
one
could
encode
it
in
somewhat
fashion
to
to
protects
against
attacks.
The
lower
layers
should
not
depend
on
what
the
upper
layer,
what
number
of
bits
skipping
0
whatever
that
is,
that
should
not
that
should
be
copied,
ly
layered
differentiated.
We.
B
I
I
So
basically,
whether
we
keep
up
with
the
suitable
base
approach
that
we
have
today
or
we
kind
of
start
keeping
EVPs
in
your
mind
or
then
we
just
go
different
route,
and
so
I
just
want
to
kind
of
point
out
that
the
kind
of
discussion
between
pseudo
wires
and
evpn
and
when
you
look
in
the
actual
encoding
or
wire
for
the
pipeline
point
of
view.
They
look
the
same.
So
the
N.
B
K
Iii
I
tend
to
go
towards
wanting
to
do
just
at
net
wire
and
define
what
that
is,
and
one
was
the
control
word
that
we
just
settled.
The
other
is
that
if
I
look
at
what
does
TSN
want
from
debt
net?
Okay,
which
is
one
important
consideration?
Not
the
only
one.
Certainly
we
do
not
all
TSN
does
not
always
want
an
Ethernet
connection.
Thank
you
very
much.
Okay.
We
want
a
routed
connection.
K
Okay,
one
of
our
problems
is
that
you
can't
make
a
bridged,
Network
big
enough,
so
giving
us
on
giving
us
a
pseudo
wire
that
provides
an
Ethernet
connection
that
connects
these
two
clouds
is
not
necessarily
what
we
want.
Okay,
we
don't
want
to
expand
the
volume
of
the
broadcast
space.
Okay,
though
the
pseudo
wire,
the
thing
after
the
connect,
the
control
word,
I
believe
I'd
like
to
I
I,
think
I'd
like
to
see
it
is
not
necessarily
12
bytes
of
of
MAC
address.
Being
the
next
thing
at
the
control
word.
B
F
Evp
ends,
don't
have
any
in
network
construct
which
you
need
so
you're
going
to
be
modifying
EVP
NS
anyway,
Greg
and
I
are
having
a
semantic
argument
over
whether
the
end
you
to
do
eyes
or
not,
but
that's
a
different
matter
fact,
is
that
it's
still
not
a
perfect
fit
because
EVP
ends
don't
have
the
other
constructs
you
need,
which
is
in
network
replication
and
elimination,
though
I
think
that
the
right
thing
to
do
is
to
define
the
right
structure
to
carry.
Things
may
be
used.
F
B
B
Excuse
me
more
coffee,
please
spoken
is
that
we
shouldn't
worry
about
modeling.
We
should
just
focus
on
the
the
data
playing
and
describe
just
the
data
plane
and
whatever
makes
sense
to
bring
into
the
document
we
into
the
document,
but
not
be
constrained
by
a
pseudo
wire
construct
or
even
an
EVP
n
construct.
Are
there
any
objections
to
that
reading
of
the
room.
B
H
B
I
C
K
B
K
B
K
B
B
K
B
K
K
Let's
go
to
the
diagram:
where
did
I
have
my
diagram
here
we
are
imagine
that
between
it
says,
reppin
the
limb,
the
two
dotted
lines,
I'm
going
to
use
the
diagram
from
it
from
another
slide.
Imagine
from
the
between
rep
and
limb.
We
have
to
slow
links,
so
I
have
to
100
megabit
links
and
I
have
a
150
megabit
flow.
Okay,
we
have
these
convenient
serial
numbers
on
them.
K
N
K
B
K
K
K
Only
that
I'm
talking
about
that
you
may
have
a
control
word
on
the
outside
and
another
control
word
inside
of
that,
because
I'm
doing
two
layers
of
of
replication
and
elimination.
If
that's
a
given
when
we
were
tied
to
pseudo
wires,
that's
kind
of
awkward
if
we're
not
tied
to
pseudo
wires
and
that's
understood,
that's
all
I
wanted
to
hear
I.
K
K
Okay,
don't
do
them
in
the
middle
I
wanted
to
give
the
basic
use
case
for
why
replication
and
elimination
in
the
middle
is
a
nice
thing
to
have.
This
diagram
was
shown
to
me
by
a
person
who
does
industrial
networks
in
industry
as
well
as
service
providers.
You
can
have
a
big
ring
with
little
rings
attached
to
it.
K
K
The
fact
that
you're
doing
planned
outages
means
that
having
two
failures
is
not
unusual
and
in
particular,
if
I
need
to
break
the
main
ring
where
the
big
blue
bar
is
I
have
to
be
sure
that
there
is
no
little
ring
broken.
For
example,
the
red
bar
in
the
upper
right
I
have
to
make
sure
that
all
of
those
networks
are
clean
before
I
make
my
main
break
and
I
have
to
hope
that
nothing
in
my
small
ring
will
break
while
I've
got
the
main
ring
broken
okay.
K
K
If
you
have
the
intermediate
replication
points
at
each
point
where
the
Rings
join
the
little
rings
join
the
main
ring,
then
you
can
have
two
failures
in
the
network.
You
can,
in
fact
you
can
have
multiple
failures.
You
can
have
a
failure
in
any
small
ring.
You
can
have
a
failure
in
the
main
ring
and
you
can
still
get
the
data
through.
K
D
B
O
C
B
P
P
P
K
Goes
both
ways
around
the
ring:
the
two
squares
each
rough
replicate
the
packets
in
both
directions;
okay,
it
one
of
which
gets
eliminated
as
they
crisscross
those
get
eliminated.
Then
they
go
around.
The
big
ring
all
the
way
around
and
crisscross
again
one
of
them
gets
eliminated.
They
go
around
the
little
ring,
yeah.
B
J
J
B
K
B
K
This
is
an
example
of
a
note
on
a
ring
that
has
an
attached
end
station
out
there
attached
coast
and
I
want
to
rep
I
want
to
immolate
eliminate
the
duplicates,
and
this
is
a
ring,
so
I'm
gonna
have
packets
coming
in
from
both
directions.
Okay,
I
want
to
pass
the
packets
in
both
directions.
Let
them
still
go
on
around
the
ring,
but
I
want
to
only
deliver
one
to
the
end
station.
K
It's
really
easy
in
a
one
chip
router,
where
one
thing
processes
every
packet
to
tell
which
one
came
in
first
and
past,
the
first
one
that
came
in
out
the
end
without
the
port.
It
has
been
pointed
out
by
people
that,
if
I
have
a
federated
router
with
a
bunch
of
line
cards
and
the
way
I
built,
this
router
is
that
absolutely
all
decisions
are
made
in
the
ingress
line
card
and
the
egress
line
cards
are
completely
stupid
and
just
queue
up
packets
for
output.
That
I
can't
really
do
this.
K
K
There
are
cases
where
you
get
at
least
three
copies
on
a
wire
which
is
not,
which
is
not
a
good
idea.
So
a
number
of
potential
solutions
are
possible.
I
would
suggest
that
you
know
a
right
solution.
Would
that
would
be
at
most
put
a
note
in
there.
That
said,
you
know,
make
sure
if
you
care
that
to
watch
out
for
this
problem.
B
Lou
norm,
that's
actually
really.
The
point
I
was
getting
at
is:
is
that
we've,
the
the
function
you're
talking
about
from
a
box
standpoint
really
is
unaware
that
you're
talking
over
a
ring?
That's
right!
Really,
it
really
is
Jo
and
I'm.
Blanking
on
the
term,
I
wrote
the
document,
but
I
just
blanking
on
a
term
of
what
we've
called
it
in
the
past,
but
we
have
the
in
whether
you're
doing
your
modeling
it
as
an
end-to-end
recovery,
LSP
recovery
or
a
segment
recovery.
B
You
have
a
point
that
does
the
the
replication
and
and
a
point
that
brings
that
does
the
recovery
and
from
a
box
standpoint
whether
that's
over
a
ring
topology
or
a
mesh
topology
or
tree
topology.
You
know
who
cares
of
course,
I
wouldn't
have
net
and
I
completely
agree.
You
can
have
these
nested
one
within
the
other,
so
you
can
have
one
replication
point
going
to
another
point
in
the
network
that
has
another
replication
point
and
then
I'm
all
being
merged
back
together.
I.
K
Understand
this,
the
the
where
this
came
from
where
this
came
from
is
that
people
who
are
doing
elimination
today,
typically
think
of
a
thing
in
the
center
of
the
box,
that
if
it
sees
the
second
copy
it
throws
away,
and
then
it
does
the
forwarding.
The
document
that
we
have
is
very
explicit
that
you
do
your
forwarding
and
then
you
do
the
elimination
just
before
out
put
that
vial.
That's
not
the
way.
K
A
lot
of
people
do
this
similar
things
today
and
they
find
that
a
shock
and
I
have
had
two
people
at
this
meeting
and
several
at
very
and
many
people
over
the
the
last
three
years
come
and
say:
oh
wait,
a
minute.
This
is
screwed
up.
I
have
to
I,
have
to
wait,
and
yes
you
it's
more.
If
you
do
it
in
one
thing,
in
the
center
of
your
box,
you
have
to
think
about
things
and
you
have
to
emulate
that
behavior
and
that's
not
trivial.
B
You're
saying
what
you
want
to
do
on
a
box
level,
not
an
interface
level
yeah,
and
if
someone
chooses
to
implement
it
in
the
center
of
the
box.
Great
if
they
choose
to
men
and
an
engineer
face
that's
right.
But
what
we
specify
is
the
behavior.
We
need
right,
which
will
not
be
in
the
in
the
context
of
a
box
right.
F
Exactly
right
so
Stuart
so
I
think
the
first
thing
is:
we
should
separate
replicators
and
eliminators
their
separate
animals
that
do
separate
things.
Sometimes
it's
useful
to
have
both
in
a
box.
Sometimes
it's
useful
to
have
just
one
in
a
box
correct,
so
we
should
architectural
split
them
out
and
talk
the
set
took
them
as
separate
things.
The
control
plane
will
need
to
know
about
them
a
separate
thing.
It.
L
F
May
be
right,
that's
the
first
thing,
so
there's
been
some
confusion,
then,
in
the
in
the
discussion
about
whether
they're
separate
or
not-
and
certainly
it
didn't
come
out
in
the
solutions
document
to
me
that
they
were
separate
objects.
So
the
second
thing
is
that
it
seems
intrinsically
that
a
replicator
is
an
ingress
function
and
an
Eliminator
is
an
egress
function.
F
If
you
have
to
choose
to
execute
it,
some
other
way
inside
your
implementation,
fine,
but
essentially
the
right
place
to
do
elimination
is
on
egress
the
right
place
to
do
replication
ours
on
ingress
inside
your
box.
You
may
have
some
extra
packets,
but
hey
that's
just
inside
your
box.
That
may
burn
up
a
little
bit
of
back
brain
bandwidth.
That's
so
what.
B
K
K
B
If
the
normative
text
describes
the
behavior
in
a
box,
that's
fine
and
then
the
informative.
The
non
normative
part
uses
a
example
that
cover
that
that
describes
it
as
in
a
particular
instantiation
right,
that's
fine,
but
we
have
to
make
sure
our
normative
text
is
on
the
device
and
the
informative.
Can
you
can
describe
it
any
way?
You'd
like
we
absolutely
must
not
require
you
to
put
the
functions
in.
A
C
A
Sorry,
no
it's
it's!
It's!
It's
really
hard
with
these
microphone,
so
you
know
I'm,
coming
from
from
from
a
multi-car
side
and
I
haven't
seen
a
single
yang
model
or
anything
else
that
actually
goes
into.
You
know
the
details
like
ingress
and
egress,
and
especially
you
know,
we've
built
this
new,
really
crazy
cool
forwarding,
plane
called
beer,
and
you
know,
internal
behavior
of
the
box
was
never
exposed
anywhere
and
I'm.
Just
waiting
for
you
know
these
these
to
become
problems
in
operations.
But
from
the
perspective
of
how
have
we
done
this
in
other
groups?
A
B
I
would
suggest
you
take
a
look
at
branch,
nodes
and
PLR,
a
local
repair
in
FRR
and
in
segment
recovery
and
intend
recovery,
because
that's
really
what
we're
modeling
so
the
the
existing
technology
we're
looking
at,
isn't
IP
multicast,
but
more
about
the
MPLS
protection
and
recovery
mechanisms
that
have
been
that
are
widely
deployed.
Well,
I.
F
B
A
Maybe
one
way
is
really
to
start
proposing
text,
and
you
know
I
think
that
there
are
certainly
for
the
elimination.
A
lot
of
you
know
not
in
prior
knowledge,
from
both
technologies.
That
norm
was
mentioning
like
ADA,
2
CB
and
an
also
application
layer,
redundancy
removal
and
if
you
simply
start
from
the
perspective
of
what
are
the
Diagnostics,
that
operators
want
to
have
express
them
through
a
yang
model.
Then
you're
already
implying
certain
forwarding
plane
functionalities
that
you
need
to
support.
Okay,.
A
B
A
C
N
One
or
two
in
essence,
a
question
I
want
to
ask,
is
trying
to
understand
this
from
a
requirements
perspective.
What's
up
here,
looks
like
trying
to
design
about
three
different
fermentations
on
loss
in
the
weeds,
so
simple
question,
suppose
I
replicate
and
I
failed,
eliminate
and
both
both
packets
go
forward.
What
what
happens
then.
N
K
N
B
J
Q
Q
So
in
the
in
the
last
idea
of
meeting
in
Prague,
we
had
just
one
information
model
and
it
was
the
flow
information
model
during
that
meeting
and
also
afterwards,
there
were
discussion
about
service
model
and
configuration
body
related
stuff
to
to
be
included
in
the
variable
documents,
and
we
had
quite
lengthy
discussion
with
outdoors
of
this
draft
and
also
the
other
draft
you
will
see
very
shortly
and
in
order
to
define
what
type
of
data
models
we
need
for
death
net.
We
have
just
looked
some
idea
of
specification
regarding
information
model
and
data
model.
Q
Q
Other
definition
we
have
used
is
regarding
the
service
models.
I
think
these
are
very
essential
part,
and
this
is
a
very
specific
type
of
data
model,
because
it
is
practically
describing
in
an
independent
way
and
technology
independent,
but
services
provided
for
the
customers.
There
are
two
type,
the
customer
service
model.
Q
This
is
something
that
is
shared
between
the
customer
and
network
operator,
and
it
is
just
having
a
high-level
description
of
the
service,
and
that
is
what
is
used
by
the
service
providers
in
order
to
create
the
service
delivery
model,
which
consists
all
the
details
about
the
service
had
to
implement
it.
On
the
network
elements
and
of
course
we
have
also
looked
the
young
definitions
in
order
to
find
out
what
explicit
does
that
have
to
be
done?
Q
The
flow
information
model
and
the
service
information
model
is
something
but
is
shared
between
the
customer
and
the
network
operator
to
define
the
service
and
the
flow
characteristics,
and
the
configuration
data
model
is
something
that
is
between
the
management
and
control,
plane
entities
and
the
network
elements
to
define
the
configuration
of
those
devices
in
detail,
so
that
staff
has
put
in
two
different
drafts.
One
is
dealing
with
the
service
and
the
flow
information
model.
Q
Just
to
very
shortly
highlight
the
update
in
the
flow
information
model
draft
we
had
already
for
the
flow
information.
Three
group
of
attributes
defined
the
source,
the
destination
and
the
flow
status,
and
now
that
we
have
added
to
the
draft
are
some
placeholders
for
the
service
information
model
and
there
we
have
for
group
of
information
attributes.
One
is
related
to
the
ingress.
One
is
related
to
the
egress
one
for
the
definite
domain
itself
and,
of
course,
there
is
also
status
for
the
service,
but
is
provided
and
the
plans
practically
to
update
those
droughts.
Q
B
Comments,
ok,
the
last
meeting.
We
talked
about
that
whether
or
not
to
adopt
this
document
at
this
point,
we'd
like
to
get
people's
feedback
on
whether
it's
time
how
many
people
have
read
the
document,
that's
a
ok
number,
not
great,
not
bad.
How
many
people
think
that
this
document
is
a
reasonable
starting
point
for
work
in
the
working
group
on
this
activity
in
this
area?
B
J
Okay,
25
years
ago,
I
was
working
with
IBM
on
a
transport
layer
for
ISO
name,
which
was
90
percent
of
the
networks
at
that
time,
and
this
extra
new
thing,
which
was
called
IP
and
so
what's
interesting,
his
job
is
that
a
good
number
of
lessons
that
you
could
learn
at
this
time
still
apply
today
and,
for
example,
one
of
the
big
lessons
while
I
was
writing
to
an
Nu
6.2,
which
was
the
Ethernet
interface,
was
very,
very
complex.
Where
has
writing
to
the
IP
circuit
was
kind
of
easy.
J
Several
years
later,
I
mean
yesterday
was
dead
and
IP
was
there.
If
we
want
our
technologies
here
to
be
very
successful,
we
need
to
provide
a
very
simple
API
to
do
parallel.
Applications
which
mean
we
need
to
define
a
transport
that
takes
all
the
complexity
of
going
over
a
dead
net
link
as
supposed
to
push
all
this
complexity
to
them
to
to
the
upper
layer
to
the
application.
At
the
moment,
the
big
hassle
we
have
in
the
field
to
move
industrial
applications,
the
audio/video
application,
etc
onto
Ethernet.
J
It's
because
those
applications
have
to
rewrite
everything
that
we
normally
would
place.
In
the
network,
such
as
jitter
elimination
in
order
delivery,
etc,
and
so
some
some
very
big
applications,
they
could
migrate
to
Ethernet,
but
most
of
the
industry,
automotive
and
all
sort
of
things
applications
still
stick
to
serial
cables.
Point-To-Point,
not
Mercer's,
because
writing
to
a
debt
net
wire
or
something
is
just
easier
net
wire
is
so
complex.
J
So
what's
gonna
happen
on
this
network,
what
did
happen
on
these
networks
with
TCP
is
TCP
was
growing
the
window
at
some
point.
The
CIA
would
just
see
too
much
robot
and
would
cut
the
data,
and
then
the
window
would
go
down
and
and
traffic
would
look
like
a
sea.
So
now,
if
you
put
TCP
on
the
shippers
that
we
are
describing
here,
you'll
get
the
exact
same
results,
because
they
are
pretty
much
the
same,
behavior
or
Syria.
J
The
other
whole
bytes
that
are
going
to
be
sent
on
the
network
will
vary
dramatically
for
the
same
applications
report,
meaning
that
I
have
a
deterministic
network,
but
they
have
a
completely
and
deterministic
feed
into
this
network,
which
gives
me
a
non-deterministic
result
right.
So
at
some
point
of
your
ok,
I
can
not
use
the
usual
layer.
4
transport
that
I'm
used
to
on
this
deterministic
network
I
have
to
provide
something
which
simplifies
the
application,
writing
and
makes
the
best
use
of
the
deterministic
underlying
topology.
And
that's
basically,
what
this
document
is.
J
It's
talking
about
providing
a
90f
sense
transport
so
as
to
use
properly
the
underneath
that
net
transport
services
right-
and
you
see
that
part
of
what
you
have
to
do
in
this
transporter
your
feets
actually
into
what
this
group
calls
the
service
layer
and
the
rest
is
in
the
document.
If
I
don't
have
more
time
but
I
think.
B
C
B
Have
followed
what
you
just
said:
the
transport
protocol
like
think
TC,
P
UDP
that
layer
we're
not
going
to
do
in
this
in
this
working
group
that
belongs
in
the
TSV
working
group.
What
we'll
do
here
is,
if
there's
any
requirements
that
percolate
down,
we
want
to
make
sure
that
we
have
them
appropriately
covered,
and
so,
if
anything,
if
you
could
focus
on
those
aspects,
this
is
yes.
B
One
thing
I'll
say-
and
this
is
more
as
a
contributor
there's
been
some
really
good
work
about
talking
about
I-
think
was
actually
done
at
Google
of
taking
TCP
and
replacing
its
flow
control
with
allocation
based
flow
control.
They
have
a
paper,
that's
accredit
on
credits
and
they
referenced
earlier
work
where
it
was
just
straight
allocation
and
that
that
work
shouldn't
suffer
from
what
you're
talking
about.
But
yes,.
C
B
J
N
N
Black,
as
speaking
stage
vwg
chair,
I
think,
there's
still
a
little
bit
of
separation
to
be
done,
because
I
see
some
things
being
labeled
transport,
I'm
not
sure,
are.
In
particular,
I
see
some
link
level
flow
control
between
the
host
and
the
first
hop
switch
router,
which
does
not
sound
like
transport.
To
me.
Happy
take
congestion
control,
but
a
link
based
flow
control
is
is
something
else
I
think.
B
N
B
N
Cool
and
so
I'm
standing
up
here
in
part
because
a
Pascal
petition
at
the
Regina
title
and
so
that
it
was
sent
over
a
TV
gene.
We
looked
at
it
and
couldn't
quite
figure.
What's
going
on,
I
said
at
the
very
least,
there
is
link
level
flow
control
in
this
doc
that
that
almost
certainly
stays
here.
The
high
level
transport
protocol,
which
is
okay,
figuring
out
what
the,
how
the
application
thinks
about
the
fact
that
that
this
network
is
ticking
and
at
every
tick
you
can
send.
B
N
B
N
N
P
N
Okay,
so
we're
down
the
weeds.
What
I'd
like
to
see
is
some
teasing
out
of
what
would
be
transport
as
the
IETF
uses
that
term
for
transport
area
and
what
needs
to
be
solved
here,
because
it's
fundamentally
lashed
to
the
components
that
make
up
a
debt
net
Network.
Be
that
the
big
be
that
the
links
or
the
some
of
some
of
the
fancy
function.
And
then
those
like
craft
wait.
H
A
Question
to
David
so
I
mean
we've
done
tunneling
across
flow,
controlled,
stuff
right
so
and
I'm
just
trying
to
understand
your
logic
about
you
know
it
sounded
as
if
you
know
if
it's
not
end-to-end
flow
control,
reliability,
it's
out
of
TSV,
but
that's
not
true
for
the
technologies.
We've
done
right,
like
you
know,
tunnels
that
that
that
have
flow
control.
B
J
So
so
the
initial
first
thing
I
would
like
people
to
read
the
draft
and
make
the
whole
mind,
but
the
bigger
the
thing
which
definitely
impacts
this
group
is
that
we
have
to
have
an
architecture
which
covers
the
things
we
are
talking
about
cheer
and
then
once
we
agree
on
the
architecture,
then
we
can
always
decide.
Oh
there
we
have,
because
we
have
this
layered
architecture
and
basically
going
down
those
sub
layers
of
the
service
thing.
J
We
have
to
decide
where
the
transport
is
and
where
these
repairs
so
I
will
basically
go
into
three
slides
or
four
slides
I've
here,
where
I'm
suggesting
a
tiny
Delta
as
to
the
current
architecture
document
left
is
the
current
and
right.
Here's
the
the
new
thing
so
well.
This
the
first
thing
I
want
to
mention
here,
is
mostly
the
introduction
of
float
sharing
like
which,
which
is
pretty
much
it
going.
J
B
J
B
I'm
gonna
bring
up
something
that
Deborah
suggested
and
we
were
gonna
bring
it
up
at
the
end.
She
suggested
that
it
might
be
makes
sense
to
think
about
a
an
interim
meeting,
maybe
January
mid
January
somewhere
around
there.
I
was
thinking
that
that
would
just
cover
data
plane,
so
we'd
look
for
an
update
of
the
data
plane
document
and
then
plan
for
an
interim
to
discuss
that.
B
But
perhaps
this
is
an
additional
topic
to
add
into
that
is
to
make
sure
that
some
of
see,
if
we
can
cover
any
issues
we
have
in
the
architecture
and
wrap
that
up.
So
that
would
be
a
two
topic
interim
that
we
should
be
considering
and
discussing
on
the
list,
but
Pascal.
Please
don't
wait
for
that.
Please
bring
the
issues
up
on
the
list
and
drive
the
discussion
there.
K
K
We've
not
talked
we've
not
spent
nearly
as
much
time,
because
the
1+1
redundancy
is
requires
fiddling
around
with
the
encapsulations
and
data
plane.
We've
done
an
awful
lot
of
thought
on
that.
We
haven't
talked
much
about
the
main
feature,
which
is
the
bounded,
latency
and
zero
congestion
loss,
and
how
to
do
that.
We
have
to
be
able
to
get
accurate,
not
approximate
computation
of
the
worst
case
latency
and
how
much
buffer
space
you
need
to
go
along
with
that
to
ensure
zero
congestion
loss
without
accurate
numbers,
it
doesn't
work,
so
people
are
implementing
this
stuff.
K
People
are
shipping
a
lot
of
product
right
now,
not
a
lot,
but
some
to
the
TSN
specifications,
the
802
dot
one
TSN
specifications.
Almost
every
box
that
implements
this
stuff
is
also
a
router.
They
aren't
just
switches
just
bridges.
They
are
routers
and
they're
implementing
this
stuff.
So
it
would
be
nice
for
an
RFC
to
be
able
to
call
out
and
say
yes,
you
can
do
this.
This
is
one
of
the
cueing
techniques
that
are
suitable
for
that
for
debt
net.
It
would
be
nice
to
be
able
to
say
here's
the
yang
model.
K
That
includes,
as
several
choices
among
your
choices
are
the
debt
net.
Excuse
me
are
the
TSN
queuing
stuff
right
now,
that's
practically
impossible
to
do
so.
I'm
telling
you
that
there's
a
project
that
has
passed
its
first,
its
first
hurdle
for
for
becoming
a
project.
It
still
got
a
long
ways
to
go
to
provide
a
document
that
gives
a
reference
point
so
that
you
can
say
I
want
that
I
want
to
I
want
you
to
use
that
particular
queueing
technology.
So
that's
coming,
I
wrote
a
draft.
K
The
original
purpose
of
this
draft
was
to
be
able
to
reference
that,
so
we
could
do
that
I'm
going
to
speak
the
unspeakable
word.
Intserv,
we've
done
this!
We've
done
this
before
it's
called
in
serve.
It
really
is.
We
need
to
be
able
to
take
make
use
of
that
stuff.
I
would
hope
this
draft
would
be
come
with
some
other
with.
K
Maybe
if
somebody
else
needs
to
be
the
lead
on
this,
this
draft
would
become
the
document
that
says
the
way
you
get
the
zero
congestion
loss
is
that
you
use
one
of
the
following
technologies
to
do
your
cueing,
and
these
are
the
issues
you
have
to
deal
with.
Here-
is
a
common
language
so
that
you
can
talk
about
these
different
techniques
so
that
you
can
do
the
network
calculus
and
figure
out
what
you
need
to
get
the
goals
that
we
want
to
do,
and
so
I
consider
this
now
an
introduction
to
Johnny.
B
Thank
you.
We
really
would
need
a
need
from
the
working
group
is
a
docudrama
says:
here's
the
yang
model
to
configure
a
debt
net
service
and
that
debt
net
service
gives
some
abstract
service
parameters,
and
then
we
could
have
this
document
says
here's
how
you
can
go
implement
those
abstract
service
parameters
yeah,
but
we're
chartered
to
deliver
a
yang
model
to
describe
a
debt
net
service.
We
don't
have
any
drafts
yet
so,
hopefully
take
a
look
at
this
document.
Think
about
it!
Think
about
that
during
the
next
slot
next
presentation
and
send
some
text
please.
D
R
Was
developed
15-20
years
ago
in
what
four
things
that
today,
we
would
call
deterministic
networking
the
to
give
essentially
to
running
crews,
who
pioneered
this
and
other
authors
who
have
evangelized
and
added
stuff.
It
has
been
developed
for
deterministic
networking
called
in
serve
and
diff,
sir.
It
has
been
used
by
people.
I
were
caring
for
in
serve
and
by
an
attorney
for
deep
serve
and
it
uses
a
language.
R
That's
a
bit
different
that
then,
from
what
we
read
in
the
dead
net
documents
or
thought
it
was
a
good
idea
today
to
bring
that
language
into
this
audience.
I
was
asked
by
Lou
to
explicitly
say
where
it
could
be
used
so
based
on
my
knowledge
at
that
time,
which
was
before
I
came
here.
This
is
what
I
wrote.
I
think
that
the
major
interest
would
be
to
to
have
an
abstract
definition
of
nodes
that
would
not
preclude
not
prescribe
an
implementation.
When
we
do
a
young
model,
we
have
to
export
of
the
internals.
R
If
we
do
that
too
much,
we
are
sort
of
saying
that
any
node
would
be
a
certain
schedule
area
done
by
a
certain
company.
That's
certainly
not
what
we
want.
So
one
of
the
things
we
can
hope
to
get
out
of
network
calculus
is
a
description
that
is
a
bit
more
general
than
simply
saying
a
node
has
a
maximum
latency
of
so
much
so,
let's
dive
into
as
some
of
the
technical
components.
R
R
That
means
that,
over
any
time,
interval
of
duration
T
the
amount
of
data
units
bits
bytes
or
packets,
if
your
packets
are
fixed
size
that
you
can
observe
in
any
interval
of
that
duration
is
bounded
by
the
value
of
that
function,
and
this
has
been
typically
used
in
the
in
servant.
Diffserv
settings
by
has
been
associated
to
leaky
bucket
or
token,
but
constraints
that
correspond
to
one.
A
fine
curve,
if
you
have
a
simple
leaky
bucket
shown
here
on
the
Left
I.
R
So
that
kind
of
curve
is
in
fact
what
you
obtain
when
you
impose
that
the
curve
you
have
is
called
sub
additive,
which
is
a
required
property.
So
that's
the
first
element,
then,
once
you
put
limits
on
the
flows
that
go
through
a
network,
you
also
want
to
capture
what
your
network
nodes
are
doing
to
a
flow
in
in
the
inner
of
context
and
the
port
nodes
were
inspired
by
generalized
processor
sharing
and
packet
approximations
of
generalized
processor
sharing.
So
you
can
view
this
as
an
attempt
to
put
all
those
schedulers.
R
There
were
tens,
or
perhaps
hundreds
of
purple
schedulers
that
have
similar
properties
in
terms
of
latency
and
buffering,
but
different
properties
in
terms
of
implementation
complexity.
So
that's
one
attempt
to
generalize
all
these
schedules,
so
that's
that's
the
key.
The
key
concept
of
network
accuracy,
I,
would
say
in
this
context,
so
we.
R
R
How
is
it
decline
for
for
various
examples
in
the
in
serve
and
diffserv
context?
Practically
always
the
the
type
of
functions
that
were
used
for
service
curves
are
the
one
shown
in
blue
on
this
on
this
figure.
They
are
called
rate
latency
service
curves,
so
they
are
piecewise.
Linear
based
have
a
latency
of
T
and
a
rate
of
are
so
many.
R
Can
be
modeled
as
having
this
property,
practically
all
schedulers
you
find
in
linux.
Implementation
today
are
of
this
type
and
in
all
the
schedulers
that
were
defined.
There's
a
bug
here.
It's
not
RFC
7000.
It
would
be
too
young
for
such
an
RFC,
it's
RFC
20
to
12,
and
that
has
defined
that
a
specific
model
used
in
in
serve,
and
it
explicitly
makes
reference
to
something
that
can
today
be
interpreted
as
this
rate
latency
service
curve.
R
So
it's
one
way
to
model,
for
example,
the
service
received
by
a
high
priority
flow
when
there's
no
preemption,
that's
the
easiest
way
to
understand
it.
So
a
packet
of
this
type
of
this
in
such
a
scheduler
might
be
subject
to
a
delay
T,
which
is
the
max
Priya
delay
due
to
low
priority
traffic
and
once
it's
served,
they
serve
at
a
minimum
rate
on,
but
I
insist
today.
This
is
a
very
simple
way
to
think
of
such
a
rate
latency
service
curve.
R
To
to
every
flow
have
a
similar
property.
Of
course,
such
schedulers
have
the
property
that
they
isolate
flows
with
deficit
round
robin
and
with
all
the
weight
attracting
schedulers.
You
are
able
to
isolate
a
flow
from
an
excess
of
traffic
coming
from
another
flow,
which,
of
course
you
would
not
have
a
priority
schedule.
R
Another
interesting
thing
is
that,
if
anything,
you
know
about
you'll
notice.
Your
note
is
too
complex
to
be
modeled
in
detail,
for
example,
perhaps
for
some
TSM
nodes,
the
only
thing
you
know
is
a
worst
case
delay.
So
if
you
know
something
about
the
worst
case
delay,
that's
also
a
special
case
of
a
service
curve,
now,
admittedly,
not
very
interesting,
but
the
interest
is
that
it
fits
in
a
general
framework
and
I
will
say
in
a
minute
what
what
that
framework
leads
to.
R
Curve
is
three
pounds.
The
first
bound
is
on
backlog
and
nor
mentioned
the
need
to
to
quantify
backlog
and
delay.
So
this
is
once
you
have
those
curves
you
take
the
horizontal
deviation
to
obtain
the
bound
and
delay.
So
you
draw
a
straight
line
at
any
at
any
place,
and
you
take
the
max
of
what
you
get
that's
what
we
can
call
the
horizontal
deviation
between
the
arrival
curve
and
the
service
curve,
and
that's
a
bound
on
the
on
the
delay
now,
depending
on
whether
your
arrival
curve
and
service
curve
properties
are
tight.
R
If
they
are.
This
is
a
tight
bound,
similarly
for
backlog
in
the
vertical
axis,
and
also
it
gives
you
a
tight
bound
on
the
arrival
curve
at
the
output.
So
one
of
the
well-known
problems
we
have
when
we
do
deterministic
networking
is
that,
even
if
we
constrain
a
flow
at
it
inputs
to
have
some
maximum
burstiness
or
maximum
number
of
packets
per
time
interval
as
soon.
R
R
For
example,
that's
a
computation
that
was
very
frequently
used
in
the
past.
If
you
assume
the
arrival
curve
you
have
is
derived
from
a
leaky
bucket
and
the
service
curve
is
given
by
rate
latency
service
curve,
then
you
have
those
explicit
formulas.
We
find,
for
example,
that
the
worst
case
delay
bound
is
a
function
of
the
latency
term
of
the
scheduler
plus
a
term
that
depends
inversely
on
the
burstiness
of
the
of
the
flow,
which
is
one
of
the
parameters
of
the
arrival
curve
and
inversely
of
the
rate
of
the
schedule.
R
R
So
you
assume
that
each
of
the
service
elements
is
giving
a
service
curve
property
to
a
flow
that
does
not
apply
if
you
do
pre-class
guarantees
or
aggregate
guarantees,
but
if
you
duper
flow,
if
the
first
service
curve,
if
the
first
network
element
offers
a
service
curve
Padawan
and
the
second
that
r2,
then
you
can
forget
about
the
details
of
that
of
the
this
concatenation
and
model.
The
whole
thing
has
one
network
element
that
offers
a
service
curve
data
which
is
given
by
this
formula.
R
Can
be
easily
computed,
this
formula
is
called
the
mean
plus
convolution,
of
the
two
service
curves
for
up
Tory
function.
It
might
be
it's
an
optimization
problem
to
compute
it
before
piecewise
linear
function,
it's
fairly
simple,
for
example,
for
rate
latency
service
curves.
If
you
do
the
mean
class
convolution
of
two
rate,
latency
service
curves,
you
simply
add
up
the
latency
Xion,
you
take
the
minimum
of
the
rate.
R
This
translates
into
the
following
results
that
was
well
known
by
insurv
and
explicitly
used
in
the
computations
that
are
done
in
RSVP.
It's
called
pay
bursts
only
once
I'm,
assuming
here
that
I
have
a
flow
that
is
served
by
two
Network
elements.
The
first
one
in
gives
a
per
flow
guarantee
better
one
service
curve,
better
one,
the
second
one.
Similarly,
with
beta
2
and
I,
can
do
two
things:
I
can
compute
bounded
latency
by
summing
up
the
two
bounds.
I
will
have
a
first
formula
and
is
formula.
D
R
R
You
also
have
an
additional
term
that
comes
from
the
fact
that
the
arrival
curve
into
the
second
node
is
worse
than
it
was
in
the
first,
but
because
we
know
the
concatenation
result,
we
can
abstract
the
entire
sequence
of
elements
by
its
mean
plus
convolution,
and
then
we
obtain
a
second
bound,
which
now
is
tight,
and
this
bound
has
the
magical
property
and
the
first
parameter
is
affected
by
a
factor
1.
So
that's
why
it's
called
a
only
once.
R
It
is
not
possible
to
have
both
the
worst
case
delay
in
the
first
note,
and
in
the
second
note,
because
if
you
have
the
first,
if
you
have
it
in
the
first
note
and
their
scheduler
I
will
not
be
able
to
produce
the
worst
case
burstiness
at
the
output,
so
this
means
this
will
have
implication.
I
will
discuss
in
a
second.
We
also
very
frequently
use
the
word
shapers.
This
is
used
in
different
contexts
with
different
meanings
in
network
calculus.
A
shaper
is
a
device
that
forces
a
flow
to
have
an
arrival
curve
constraint.
R
So
if
we
a
shaper,
has
this
mathematical
property,
which
is
also
expressed
by
min
plus
convolution,
which
in
particular
implies
that
if
we
view
a
shaper
itself
as
a
network
or
service
element,
it
delays
data.
So
it
has
also
a
service
graph.
Property,
of
course,
is
doing
much
more
than
delaying
the
data.
It's
also
shaping
it.
But
if
we
were
interested
in
and
delay
introduced
by
shaper,
then
we
can
simply
use
this
formula
to
say
that
the
shaper
also
is
a
service
curve
element
with
a
service
curve
equal
to
2.
R
The
curve
that
it's
shaping
to
another
properties
of
shapers
that
was
well-known
in
the
context
of
insurv.
Is
this
sort
of
miraculous
transparency
of
reshaping
a
very
often
in
network
nodes
in
order
to
control
backlogs
and
delay
and
buffers
not
delays?
If
you're
interested
in
controlling
delays,
we
can
ignore.
D
R
R
R
R
No,
it's
our
ITF
non
compliant,
but
I
cannot
resist
the
mass
that
is
given
here.
You
have
the
mathematical
explanation
and
the
last
the
last
line
of
the
formula
here
on
the
left.
You
have
the
horizontal
deviation
between
the
arrival
curve
and
service
curve
of
the
interest
and
stuff
which
is
in
plus
conversion
of
the
three
functions
now
min
plus
convolution
is
like
a
standard
convolution
it
commutes.
You
can
change
the
order,
which
means
the
delay
bound.
Your
10
is
the
same
if
the
shaper
is
put
as
the
very
first
element.
R
Now,
if
you
have
a
source
that
is
conforming
with
your
constraint,
you
shape
it
and
the
shaper
is
transparent.
That's
one
of
the
result.
There
are
other
bells
and
whistles
that
may
need
to
be
to
be
considered
in,
particularly
if
you
would
like
to
apply
this
in
a
definite
setting
in
particular
that
we
need.
We
may
need
to
separate
variable
and
fixed
delays.
R
G
R
So
if
this
is
what
I
export,
then
the
entering
concatenation
can
be
characterized
as
a
service
curve
that
has
the
minimum
of
the
rate
and
the
sum
of
the
latencies
and
then
the
delay
I
will
obtain
here
will
have
the
birth
paid
only
once
so.
The
improvement
will
be
equal
to
n
minus
1
time.
The
delay
due
to
the
burstiness
of
the
initial
flow.
Now
these
burstiness
cannot
be
avoided,
has
to
do
with
packet
size.
R
It
also
has
to
do
with
maximum
number
of
micro
flows
that
were
aggregating
if,
in
a
dead
net
setting,
we
are
aggregating.
Multiple
flows,
which
were
very
likely
to
do.
I
know
that
net
is
not
concerned
with
any
change
to
the
control
plane.
So
here,
so
this
is
not
a
change
to
the
control
plane.
This
would
be
one
way
to
compute
an
end-to-end
bound
using
an
existing
control
plane
of
our
ICT,
for
example.
R
Here
then,
it
would
simply
if
we
are
able
to
export
some
dead
net
nodes
as
a
rate
latency
service
curve,
then
we
can
simply
accumulate
the
minimum
of
the
rates
that
are
allocated
along
a
path
and
sum
up.
The
latencies
of
so
this
is
described
here
for
unicast
flows
in
the
RSVP
setting
is
explaining
exactly
how
this
can
be
done
also
for
multicast
flows.
It
works
the
same,
there's
no
fundamental
difference
here.
If
you
have
a
note
about
which
the
only
thing
you
know
is
a
bounded
latency,
you
don't
know
a
rates
latency
service
curve.
R
Well,
this
is
a
special
case
of
a
rate
latency
service
code
with
infinite
rates.
So
for
such
a
note,
you
will
be
also
able
to
export
the
right
things
to
this
has
been
also
studied
by
a
number
of
people
in
centralized
path.
Computation.
If
you
do
a
centralized
path
computation,
you
can
do
better
things.
You
can
improve
it.
Some
papers
are
explained
how
to
cast
such
a
problem
as
a
mixed,
integer
and
convex
programming,
and
giving
a
reference
here
on
how
this
could
be
computed.
R
R
Thank
you.
So
this
was
not
a
time.
It
was
just
a
battery
of
the
microphone
being
dead,
so
I
think
that's
where
calculus
can
help
understand
some
phenomenon
right,
a
burst
only
once
that
may
have
an
impact
on
the
design
of
an
end-to-end
service
like
we're
doing
in
in
detonate
it
can
use
to
to
to
provide
perhaps.
R
L
D
R
We
use
linear
surrenders
that
offer
already
a
large
variety
of
schedulers,
so
we
pick
one
of
them
and
then
we
can
do
that
net
deterministic
networking
with
such
things,
so
that
exists
today,
there's
a
requirement
to
be
able
to
support
it.
So
it'd
be
interesting
to
see
how
to
fit
this
in
the
in
the
existing
document.
It's
also
interesting.
B
K
K
L
R
No,
there
is
the
the
hypothesis
you're
making
is
that
in
order
to
provide
in
to
and
latency
bounds
and
backward
bounds,
that
you
are
able
to
enforce
an
arrival
constraint,
that's
the
only
thing
but
you're,
not
assuming
it's
I,
don't
know
stationary
process
or
place
or
whatever.
Of
course,
there's
nothing
about
time.
B
We
do
sort
of
work
by
by
text.
So
if
you
want
to
put
this
extract,
what
you
think
is
applicable
and
put
it
into
a
document,
that's
great!
If
you
want
to
take
pieces,
then
contribute
it
on
to
the
working
group
list
and
say
it
probably
belongs
in
this
document.
Then
you
don't
have
to
have
the
burden
of
doing
the
whole
mechanical
editing
process,
but
whichever
way
works
for
you,
we
would
just
like
to
benefit
from
the
insights
you've
gained
here.
I
think
we
have
time
for
another
comment.
K
B
We
have
to
get
in
sync
with
the
data
plain
authors,
to
make
sure
that
we
have
a
sufficient
update
to
the
document
that
captures
the
discussion
that
we've
had
today
before
we
have
an
interim
that
then,
would
just
repeat
the
discussion.
So
we
want
to
make
sure
that
it
would
be
worthwhile
for
people
to
either
travel
or.
B
That
seems
like
our
some
good
numbers.
What
about
physical
is
there?
Some
willingness
and
I
know
we
have
to
figure
out
where
that
would
be,
and
maybe
like
at
a
hub
location
somewhere
hands.
If
so,
we
had
both
a
reasonable
number
and
a
volunteer
of
a
host.
So
that's
appreciate
it.
Thank
you
with
that.
We
are
exactly
on
time,
really
appreciate
all
the
good
discussion
and
contribution
we
might
think
about
having
a
second
session,
the
next
time
to
allow
for
more
discussion.
Very
much
appreciated,
see
you
in
London.