►
From YouTube: IETF105-DETNET-20190724-1330
Description
DETNET meeting session at IETF105
2019/07/24 1330
https://datatracker.ietf.org/meeting/105/proceedings/
A
Skyress
with
me,
hey,
hi,
good
afternoon,
welcome
everyone.
This
is
the
that
networking
group
meeting
Ruiz
and
myself
are
the
chairs
and
Ethan
is
our
secretary.
He
is
remote.
Couldn't
make
it
to
this
meeting.
You
find
the
downline
the
agenda
on
line
at
the
usual
place
and
the
working
group
information.
A
This
is
the
high
tea
of
no-tell
as
a
reminder
and
remind
you
that
by
participating
the
ITF,
you
agree
to
follow
the
idea,
processes
and
policies.
If
you
are
ever
that
any
idea
of
contributions
covered
by
patents
or
patent
applications
that
are
owned
or
controlled
by
you
or
your
sponsor,
you
must
disclose
that
fact
or
not
participate
in
the
discussion
and
also
remind
you
that
there
is
permanent,
recording
and
by
participating
and
attending.
You
acknowledge
that
written
audio
and
video
and
photo
photographic
records
are
made
at
these
meetings.
A
If
you
are
not
familiar
with
the
note
4,
then
please
study
I
mentioned
the
recording
and
the
mini
taking
we
use
it
to
pad.
Please
please
join
in
to
pad
this
is
join,
mini,
taking
and
correct.
If
some
something
was
not
captured,
for
example
your
name
as
we
discussed,
you
may
have
difficulty
to
capture
that
chapter
and
don't
know
an
agenda
was
mentioned
already.
The
blue
sheets
are
going
on.
Please
fill
in
the
blue
sheets
with
your
name
and
affiliation.
A
We
have
two
sessions
this
afternoon
that
night
sessions
this
one
and
Burbridge
week
and
the
afternoon
session.
Both
sessions
are
in
this
meeting
room,
and
this
is
the
detailed
agenda
kind
of
the
agenda
items
in
the
order
of
the
ones
being
progress.
Most
forests
are
the
first
I
would
not
read
out
the
agenda.
You
can
find
it
online.
This
is
for
the
session.
A
So
this
is
the
plan
to
go
to
these
items
in
this
order
and
important
to
highlight
that
we
use
the
mailing
list
to
build
the
consensus,
so
the
working
of
decisions
are
made
on
the
mailing
list.
Discussion
is
means
made
under
a
list,
so
please
bring
your
items
to
release,
discuss
and
and
comment
the
documents.
You
will
hear
a
couple
of
comments
if
you
wish
in
the
ones
we
are
about
to
finalize
or
bring
in
new
topics,
and
so
on.
A
This
is
status,
update
on
where
we
are
with
our
documents.
In
the
working
group,
we
have
two
new
offices
out
the
problem
statement
and
use
cases.
Thank
you
very
much
for
will
contributed.
So
these
are
the
first
RFC's
of
the
working
group
and
the
architecture
is
with
the
RFC
editor.
We
are
making
fine
publishing
a
couple
of
last
edits
are
in
the
queue
and
hopefully
it
gets
published
very
soon.
A
The
first
look
you
see
here
as
own
agenda
is
the
data
plane
documents,
the
dark,
green
ones
are
the
ones
more
stable.
We
plan
to
pass
coal
after
the
meeting,
but
we
will
discuss
more
in
detail
during
the
agenda
during
the
data
plane,
presentation
and
the
green
ones
are
followed
by
the
flow
information
with
that
is
progressing
as
well
as
the
end
documents
building
on
the
flow
information
model.
There
is
a
new
one.
A
The
Lila
Kuan
recently
adopted
by
the
working
group
on
the
bounded
latency
and
one
of
the
working
group
graphs,
is
not
on
agenda.
It
is
a
Security
draft.
This
has
been
gated
by
previous
documents,
the
actually
the
architecture
and
the
data
plane
solution
documents.
Now
those
are
getting
major,
so
I
would
expect
making
your
next
steps
with
the
security
draft
as
well.
A
So
in
comparison
to
our
milestones
of
our
divorce
as
a
working
group,
the
architecture
is,
is
done,
pretty
much
I
would
say,
and
security
as
I
mentioned
will
be
catching
up,
hopefully
very
soon,
and
we
made
a
great
progress
in
documenting
the
data
plane
definition.
So
actually
there
is
no
technical
changes,
but
the
documentation
was
the
one
that
was
progressing
so
we
have.
We
have.
You
will
see
more
in
detail,
I
not
talk
about
that,
and
I
mentioned
the
flow
information
and
the
end
Manas
was
it.
B
Keep
in
mind
where
contribution
driven
and
we
do
take
items
into
the
working
group
that
are
within
charter,
and
if
you
have
something
that's
outside
of
charter,
we
can
discuss
that.
We
do
have
something
on
the
agenda
today,
which
is
borderline,
that
the
control
plane,
information
document,
the
control,
plane
dock.
B
It
is
within
our
charter
to
document
control,
plane
requirements
and
perhaps
even
a
framework
for
solution,
but
the
solutions
themselves
are
outside
our
charter.
Current
expectation
is
is
that,
though,
that
will
be
addressed
in
the
groups
that
own
those
respective
control
plane
protocols
if,
for
some
reason,
those
groups,
it
doesn't
make
sense
to
do
it
in
those
groups.
We
can
talk
about
doing
it
here,
but
that
is
something
that
would
be
a
broadening
of
the
Charter
required
our
eighty
and
is
G
approval,
but
other
other
items
are
within
charter.
C
A
D
D
So,
prior
to
this,
we
had
two
data
plane
drafts.
We
had
an
IP
solutions,
drought
and
MPLS
solutions,
and
what
the
working
group
had
agreed
to
do
was
take
a
building
block
approach
and
break
the
documents
up
into
the
the
ones
you
see
on
the
right
hand,
side.
So,
there's
a
framework
document
and
I'm
going
to
talk
about
each
one
of
these,
an
IP
document
and
MPLS
document
and
a
dead
net
IP
over
MPLS
documents
and
an
MPLS
over
UDP
document.
D
D
So
it
covers.
We
have,
on
the
the
right
hand,
side.
We
have
from
the
architecture
the
the
the
layering
that
we've
got.
So
we
got
the
service
sub
layer
and
the
forwarding
sub
layer
and
then
the
lower
layers,
it's
and
then
we've
got
as
services
for
for
deterministic
networking
we've
got
IP
and
mpls,
and
we
talk
about
pieces
like
the
encapsulation,
specific
metadata,
the
IP
data
plane,
the
MPLS
name
plane,
and
then
things
like
service
protection,
aggregation
in
systems
in
sub
Network
and
a
little
bit
about
controller
playing
management
and
control
considerations.
D
D
For
the
IP
draft,
this
content
now
is
specific
to
IP
and
with
with
ie
with
the
IP
data
playing.
Basically,
you
only
have
the
forwarding
sub
layer
we're
looking
at
naturally
at
the
elements
in
the
IP
header,
the
the
six
couple:
five
double
and
plus
dessert
code
points
for
flow
identification
and
types
of
that
aggregation
and
things
like
that
and
on
the
right
hand,
side
from
the
die
from
the
draft.
We
have
an
example
of
a
dead
net
service,
that's
end-to-end
or
below
that.
D
So
the
the
management
and
control
information
summary
for
that
it
you've
got
the
various
fields
that
you
can
look
at
in
the
IP
header,
so
for
v4
and
v6
you've
got
source
address,
source
prefix
if
you're
doing
aggregation
destination,
address
field
destination,
prefix
the
protocol,
the
next
header
field
in
ipv6,
you
get
the
type
of
service
or
the
traffic
class
feel,
and
you
may
do
some
bit
masking
on
those.
There
was
some.
There
was
some
comments.
I
see
David
going
to
the
mic.
D
B
B
D
For
MPLS
we
did
the
similar
thing
to
IP,
but
now
in
the
MPLS
context,
so
everything
in
the
MPLS
document
is
dead
net
with
respect
to
MPLS.
So
at
the
top
we
have
the
representation
of
the
the
service
layer
and
the
forwarding
layer
and
an
MPLS
that
consists
of
a
control
word
and
a
service
label,
or
sometimes
it
could
be
an
aggregation
label
and
for
the
forwarding
piece
it's
the
at
fly
ball.
D
For
the
what
we
all
line,
the
various
MPLS
data
plane,
procedures
for
flow
identification
and
sequence
numbers,
and
then
management
and
control
information
and
again
in
the
diagrams
that
come
out
of
the
document,
you've
got
a
little
bit
more
detail
in
the
header
stack
that
goes
on
there
with
the
control
and
the
service
label
and
optionally.
The
forwarding
labels,
if
you
have
them
or
not
so.
D
In
terms
of
MPLS
there's
a
rich
set
of
features
that
are
in
there
and
we
can
talk
about
them
and
we
talk
about
them
and
basically
the
different
places
they
occur.
So
in
the
service
sub
layer,
information,
you've
got
application
flow
identification
information,
you
might
have
sequence
number,
you
might
have
a
the
S
label
for
the
service.
You
may
have
packet
reputation,
replication
functions,
PRF,
whether
it's
used
or
not,
and
associating
forwarding
and
sub-layer
information
for
receiving
traffic
on
the
service
sub
layer.
D
You've
got
the
Associated
forwarding,
sub
layer,
information,
the
service
label
for
the
research
service,
packet,
elimination
or
ordering
functions.
If
they're
provided
and
sequence
number
in
service
I
aggregation
the
S
labels
after
those
letter
to
be
carried
over
each
aggregated
service.
If
you
have
aggregation
the
a
label
associated
with
each
aggregated
service,
our
other
service
label
information
summarized
above
in
the
forwarding,
sub
layer,
you've
got
the
outgoing
F
label
stack
and
traffic
parameters
associated
with
a
specific
label
on
the
stack.
D
You've
got
the
outgoing
interface
in
the
next
hawk
for
unicast
traffic
and
any
sub
networks.
Specific
parameters
on
the
receiving
side.
You
got
the
incoming
interface,
the
incoming
forwarding
label
stack
to
be
popped
and
incoming
flows
love
sub
layer
and
it
the
the
note
at
the
bottom
just
says:
the
required
information
depends
on
the
type
of
node.
So
this
is
the
set
of
capabilities.
You
may
use
a
subset
of
that.
D
D
It
looks
at
the
the
flow
I
get
identification
and
the
traffic
treat
treatment
and
any
and
then
then
we'll
get
to
the
management
control
information.
So
summary
on
the
right-hand
side,
you've
got
the
the
diagram
here
is
showing
the
IP
service
that's
going
over
top
of
the
MPLS
dead
net
and
that
could
be
a
IP
dead
net
service
going
over
the
MPLS
system.
And
then
we've
got
the
representation
of
the
various
label
stacks
and
sub
layer.
D
So
just
the
summary
of
the
IP
over
MPLS
information
here
at
the
ingress
node
each
MPLS
flow
is
identified
using
the
IP
flowing
information
and
includes
the
wild
cards.
Port
ranges
in
the
ability
to
ignore
specific
IP
fields,
as
we
saw
before
the
dead-end
MPLS
service
that
has
be
used
to
send
the
matching
IP
traffic
includes
both
service
and
traffic
delivery.
Information
at
the
MPLS,
egress,
node
I
think
there's
a
typo
in
here.
The
s
label,
basically
that's
associated
with
the
MPLS.
Basically,
the
IP
IP
is
encapsulated.
D
The
next
document
we're
looking
at
is
MPLS
over
UDP
IP,
so
the
reverse
of
the
last
case
case
and
a
little
bit
in
this
case.
We've
got
specific
MPLS
deterministic
networking
data
playing
operation
over
an
IP
network.
So
in
cases
where
you
don't
have
MPLS
and
then
you
can
operate
it
over
IP
and
we've
got
the
management
and
control
information
for
that.
D
So
for
that
one
we've
got
the
label
information,
the
service
label
or
the
forwarding
label
to
be
mapped
to
the
IP
UDP
flow.
The
ipv4
and
ipv6
source
address
information,
the
destination
address,
information,
the
service
and
the
IPC
ipv6
traffic
class
fields
on
the
UDP
source,
port,
a
UDP
destination
port.
D
As
I
mentioned
before,
these
documents
are
the
TSN.
Related
cases
are
not
complete
yet,
but
there
are
three
drafts
that
are
intended
to
be
worked
on
for
the
next
session,
the
next
meeting,
so
that's
debt
net
IP
over
TSN
and
then
we've
got
debt
net
MPLS
over
TSN
and
then
we've
got
TSN
or
Ethernet
VPN.
Over
MPLS
we
created
the
dress
during
the
split
because
there
was
material
in
them,
but
there's
further
work
needed
and
any
kind
of
contributions
are
welcome.
B
One
comment
here:
we
are
in
an
unusual
situation
and
one
we
generally
like
to
avoid
where
we
have
chairs
contributing
to
the
drafts
to
manage
that
we
have
identified,
and
we've
appreciated
that
Ethan
our
secretary
is
going
to
be
Shepherd
for
these
documents.
So
we
want
to
recognize
that
we
are
in
this
unusual
situation
and
also
tell
you
how
we're
handle
yet.
E
Yes,
thank
you.
Yes,
Thank
You
Ethan
welcome
your
trial
by
fire.
Let's
go
back
to
slide
four.
Actually,
because
I
have
I
had
I
sent
a
note
to
those
name,
please
it's
like
a
tee
blaq,
so
something
no
to
list
with
three
transport
determines
the
IP
draft
first,
one
which
is
bought
into
with
yep
forgot
to
fix
that
one
will
fix.
E
Let's
go
deal
with
the
other
two,
so
on
this
side
for
identification,
six
tuple
short
summary
is
that,
while
you
can
usually,
while
you
identify
the
flow
with
the
six
people,
the
5-tuple
substance,
each
tuple
has
to
be
unique,
with
respect
to
all
other
five
tuple
flows
on
the
network
and
I'm
easy
I'm,
easy
writing
text
for
that.
Okay,
so
I.
E
B
E
E
What's
going
on
here
is
the
diffserv
architecture
says
you
use
DSC
piece
to
mark
flows,
you
don't
use
DHCP,
so
subdivide
a
flow
into
sub
flows,
and
so
what
that
implies
for,
for
the
the
IP
draft
is
it's
fine
cater
six
people
identify
the
flow.
In
fact
there
that
I
can
think
of
some
good
implementation
reasons
to
want
the
dscp
to
be
spected,
but
the
five
triples
got
to
be
unique
because
you're
building
on
diffserv
and
diffserv
says
the
flow
is
five
tuple.
I
think.
B
E
There
there
are
work,
the
for
two
implications,
one
which
is
easy
and
I'll
do
the
hard
one
later.
The
easy
implication
is
there
are
a
few
places
and
diffserv
where
you
can
mark
a
flow
with
more
than
one
dscp.
The
decision
identify
flow
by
six
tuple
says
debt,
and
it
can't
do
that.
No
big
deal,
that's
a
that's
a
design
decision,
it's
more
than
time
to
make
we're.
B
E
You've
got
to
be
able
to
outside
a
bit
knit
context,
use
that
five
triples
a
handle
on
the
flow,
and
therefore
it
can't
be
the
case
that
this
five
tuple
source
destination
protocol,
two
ports
with
an
EF
dscp,
is
one
flow
and
with
a
and
and
with
a
CS
one
DHCP
is,
is
a
different
flow.
If
you've
chosen
you've
chosen
Orkut
with
EF
you've
chosen
mark
with
EF,
you
won't
know
the
flow
change
for
change,
one
of
the
ports
or
something
like
what.
B
B
The
implication
of
that
David,
what's
the
implication
of
what
does
it
mean
to
be
a
different
flow?
I
mean
if
you're
saying
different
flow
from
an
application.
Perspective
means
you
know,
I
have
a
voice,
you
know
voice
on
voice
versus
video
and
we're
combining
it
and
the
only
difference
is
dscp.
That's
clearly
forbidden
I
get
that
from
a
network
standpoint.
If
it's
gonna
receive
a
different
traffic
treatment,
that's
a
different
flow
I
mean
again.
So
that's
what
this
or
does
is
give
a
different
traffic
treatment,
but.
E
B
Sure,
maybe
again,
it'd
be
very
important
to
capture
if
there's
what
restrictions
there
are
on
the
network
equipment
based
on
that
statement,
I
think
I
think
we're
okay
with
the
statement,
particularly
from
the
context
of
how
it
impacts
applications,
because,
certainly
that's
a
no-brainer
right
I
mean
no
one's
gonna,
argue
about
that
one,
no
one's
going
to
miss
or
that
one,
but
in
terms
of
actual
network
equipment,
what
behavior
they
have
to
do
differently.
That's
what
we
have
to
make
sure
we
cover
I.
E
F
A
G
E
G
Because
because
I
think,
our
intention
here
is
that,
when
identifying
the
flow,
we're
talking
about
in
some
of
the
drafts,
we're
talking
about
identifying
the
flow,
because
different
flows
may
have
to
go
into
different
cues,
for
example,
in
order
to
get
the
quality
of
service
we
want
and
that
when
deciding
which
cue
a
flow
goes
into,
the
dscp
is
very
important.
Deciding
which
cue
a
packet
goes
into.
The
dscp
is
an
important
distinction.
E
B
F
B
B
B
E
Let's
see
I
think
the
best
thing
I
can
probably
do
here.
Tremors.
A
short
discussion
is
probably
to
point
you
over
at
over
towards
web
RTC,
which
is
trying
to
do
an
or
for
a
lot
of
multiplex
and
have
an
awful
lot
of
stuff
I
but
it,
but
in
general,
in
general.
This
is
a
doctor.
It
hurts
when
I.
Do
that?
Don't
do
that
discussion.
We
simply
need
me
me
need
to
find
a
precise
words
to
say.
Don't
do
that.
F
B
B
Sorry,
the
working
group
has
never
suggested
disallowing
this
case
before.
If
we
think
we
should
be
disallowing
part
of
what
is
supporting
the
internet
architecture
number
one,
we
got
to
be
really
sure
that
we
were
doing
that.
We're
gonna
change
the
internet
architecture
and
number
two
is:
will
have
to
reach
consensus
on
that
right.
F
E
The
simple
case
you
might
be
looking
at
is
diffserv
defines
a
piece
of
functionality.
The
debt
net
probably
isn't
interested
in.
It's
called
a
F.
It's
called
a
shrewd
forwarding
inside
an
AF
class
any
of
class.
The
AF
3
has
3
DCPS.
In
increasing
order
in
in
order
of
drop
precedence,
dead
net
can't
drop
traffic
there.
For
a
picnic
wants
to
use
a
of
3.
A
of
31
suffices,
don't
touch.
The
other
two
doesn't
make
any
difference.
F
E
E
E
Your
the
type
of
service
in
v6
credit
class
fields
then
need
to
be
split
because
the
ECM
field
is
in
there.
Thou
shalt
not
use
the
ECM
field
to
identify
traffic,
that's
the
easy
one
and
then
the
dscp
is
the
other
six
bits
in
those
two
fields.
You
can
use
DHCP
and
you
are
using
DHCP
to
identify
to
identify
and
classify
traffic.
That's
fine.
B
E
Good
see
this,
this
was
copy
of
the
document.
It's
gonna
have
to
be
written
to
split
the
type
of
surging
traffic
class
fields
into
dscp,
DCN
fields
and
the
bitmask
hits
the
bitbucket
and
it
sounds
like
what
I
need
to
do
is
I
need
to
go
tape,
I
just
said,
and
write
and
longer
email
messages
about
what
has
to
change
what
needs
to
change
here,
and
why
now
I
understand
that
the
purpose
of
this
is
try
to
classification,
which
to
me
means
this.
Is
you
these
these?
E
A
Okay,
so
this
is
an
update
on
the
flow
information
draft.
So
what
happened
to
this
draft
since
the
previous
IDF,
the
last
ITF
representation
was
given
on
what
changes
we
see
to
be
made.
We
see
as
authors
contributors
and
actually
we
implemented
those
changes.
So
this
new
version,
four,
is
an
implementation
of
the
ITF
104
presentation,
as
contribution
to
the
group
from
the
authors
and
I,
keep
saying
and
highlighting
the
please
review
and
comment
and
charge
I
mean.
A
So
this
is
just
a
contribution
from
the
authors
to
capture
the
changes
needed,
so
it
implies
actually
a
major
rewrite
or
reorganization
compared
to
the
previous
version
of
the
draft.
The
figure
you
see
on
the
screen
is
taken
from
the
MPLS
data.
Pane
draft
and
three
components
are
highlighted.
There
are
the
applications
and
one
directional
flows
on
the
screen.
That
is,
the
the
blue
one
on
top,
which
is
the
application
of
flow,
and
there
is
a
gray
one
that
not
flow
which
goes
through
the
definite
service
layer.
So
these
are
the
the
terms.
A
The
two
top
bullets
under
the
black
ones
are
the
scope
so
to
provide
and
describe
that
not
flow
information
model
describe
the
characteristics
of
that
not
flows,
requirements,
attributes
that
are
needed
to
handle
the
data
flows
in
the
Debnath
network
as
well
to
provide
a
service
information
model
like
describing
what
service
at
night
service
that
not
Network
provides
to
us
that
NetFlow
and
the
third
third
one
is
out
of
scope
for
this
document,
but
that's
definitely
part
of
the
full
picture.
That's
why
it
is
here.
A
That's
the
configuration
data
model
and
that's
scope
of
the
yank
documents
you
will
hear
about
after
me
in
this
session.
Just
turn
around
you
summary.
What
you
see
on
the
left-hand
side
is
coming
from
the
architecture
and,
on
the
right
hand,
side.
We
proposed
to
use
some
new
terms
in
the
document
to
be
able
to
refer
to
to
these
items,
to
make
easier
the
description
so
an
application
flow.
A
Let's
talking
talk
about
the
left
hand,
side,
the
architecture,
an
application
flow
from
data
perspective,
is
the
data
the
payload
carried
over,
that
net
service
or
in
a
data
flow
and
a
definite
flow
is
actually
an
application
for
plus
the
dead
net
encapsulations,
including
MPLS,
if
it
is
MPLS
or
IP
or
or
sequence
numbers,
and
so
on
so
forth.
So
what
is
specified
by
that
net
as
a
needed
to
provide
the
deadness
services?
A
I
would
like
to
highlight
these
two
notes
in
the
bottom
that
in
some
of
the
cases,
the
up
flow
and
the
dotnet
flow
may
look
like
the
very
same
on
the
wire.
This
you
find
this
in
the
in
the
IP
data
plane
draft
as
well
that
the
IP
application
flow
headers
remain
and
just
used
in
by
the
debt
net
notes
between
the
death
and
domain.
There
may
be
no
further
encapsulation
added.
A
You
will
see
more
details
on
this
in
the
following
slides
new
terms
that
we
proposed
for
the
description,
a
source
being
the
reference
point
for
the
application
flow,
the
originator
of
the
originator,
application
of
the
data
of
the
application
flow
destination
is
still
refers
to
an
app
flow.
That's
the
termination
point
of
the
app
flow
and
the
two
bottom
ones,
definite
English,
and
that
net
egress
refer
to
the
death
net
flow.
So
these
are
reference
points.
A
The
English
one
is
the
starting
point
from
in
the
Death
Note
network
perspective
for
the
dead
net
flow
and
the
dead
net.
Aggress
is
the
termination
point
for
the
data
domain
that
that
map
network
for
that
that
net
flow,
so
these
terms
are
used
in
the
following
and
the
three
aspects
three
groups
captured
in
this
document
as
information
elements
or
groups
with
us.
The
bottom
two
are
the
two
that
are
really
the
scope
of
the
document:
the
deadness
flow
parameters
and
the
definite
service
parameters.
A
On
top
you
see
the
app
app
flow,
which
is
not
the
core,
but
we
need
to
talk
about
it.
We
need
to
have
an
understanding
in
order
to
be
able
to
provide
that
net
service
for
enough
flow,
so
the
net
flow
related
parameters
describe,
did
that
have
four
characteristics,
requirements
and
so
on,
and
that
met
service.
Related
parameters
provide
a
description
on
on
what
the
service
provides
towards
the
flows
bit
more
in
detail.
Actually,
this
is
a
this
is
a
single
slide
summary
of
the
whole
document.
A
Currently
so,
as
I
mentioned,
the
core
part
is
the
green
and
the
blue
in
the
books,
titles,
with
the
title,
or
the
name
of
the
draft
draft
idea
of
that
not
for
information
mother.
So
that's
the
core
part
and
in
line
in
the
red
box
that
is
the
up
flow.
As
I
said,
we
need
to
have
an
understanding
and
in
some
cases,
actually
that
net
flows
become
app
flows.
A
Let's
do
a
top-down
or
from
left
to
right
in
this
case,
so
the
an
app
flow
has
two
kinds
of
groups:
it
has
some
characteristics
describing
the
flow
and
it
has
some
requirements
as
part
of
the
characteristics
we
propose
to
have
a
flow
ID,
which
is
only
a
management.
Id
I
will
pull
out
an
example
when
it
is
handy
and
we
propose
to
have
a
flow
type
to
know
what
type
of
flow
it
is.
A
That
is
the
flow
specification
part
that
okay,
how
do
we
describe
the
flows
so
destination
address
labels
alone,
IDs
whatsoever,
and
there
is
the
traffic
specification,
the
traffic
characteristics
of
the
flow
itself,
the
packet
interval
packet
size
and
my
maximum
packet
maximum
number
of
packets.
The
floor
endpoints
belong
to
the
flow
description,
and
it's
been
there
in
before
in
previous
drafts
as
well.
A
The
flow
rank
that
can
be
used
to
rank
flows
even
in
case
of
a
race
or
for
scarce
resources,
for
example,
and
the
flow
status
is,
is
it
established
supported,
or
there
was
some
failure,
as
for
requirements?
Flows
typically
have
bandwidth
requirements,
packet,
delay,
recover
or
requirements,
packet,
delivery
requirements
and
loss
requirements,
and
we
suggested
to
have
a
parameter
called
bit
irrational
to
indicate
whether
actually
so
all
of
the
flows
are.
A
Basically,
you
directional,
but
the
flow
may
have
a
power
affair
in
the
other
direction
and
in
some
cases
actually
you
may
want
to
have
them
routed
congruent
or
something
like
that,
and
in
this
case
it
is
good
to
know
if
these
two
floors
belong
together,
and
this
is
one
of
the
examples
when
this
management
flow
idea
becomes
handy.
So
it's
only
for
the
management
purposes
to
know
that,
for
example,
two
flows
should
be
corroded,
not
a
big
surprise
that
the
rapid
flow
parameters
in
the
green
box
are
very
similar
to
the
AB
flow
parameters.
A
For
the
reasons
I
mentioned,
for
example,
data
flow
may
become
a
net
flow,
so
data
flow
has
characteristics
and
requirements
and,
as
part
of
the
characteristics,
the
flow
ID
for
management
purposes,
the
payload
type,
and
then
here
comes
some
new
parameter
specific
to
that
now,
so
we
have
two
data,
plane,
solutions,
MPLS
and
IP.
Okay,
what
is
this
flow
format
and
the
flow
specification?
It
can
be
labels
like
the
s
label,
or
a
stack
of
FAA
flavors
in
case
of
MPLS
data
plane
or
a
six
topper.
A
If
we
use
IP
data
plan
for
that
net,
the
traffic
specification
is
very
similar
to
a
net
flow.
It
has
the
interval,
a
packet
size
and
the
maximum
number
of
packets,
and,
as
for
the
endpoints
for
a
data
flow,
these
are
the
ingress
or
egress
endpoints
we
propose
to
introduce
and
flow
rank
is
similar
again
if
rank
can
be
very
useful
when
doing
resource
allocation
and
not
having
enough
resources.
If
you
have
to
make
a
decision
which
flow
gets
the
resources
flow
status
like
is
it?
A
Was
it
successful
the
flow
establishment,
or
not,
for
example,
and
as
part
of
the
requirements,
a
data
flow
can
have
minimum
bandwidth
requirement
maximum
latency
maximum
latency
variation,
maximum
loss,
maximum
consecutive
loss
tolerance?
How
many
consecutive
pep
packets
are
tolerated
to
be
lost
a
maximum?
So
during
how
many
number
of
packets
can
be
miss,
ordered
and
tolerated
by
the
application?
Actually
and
again
a
similar
parameter?
Is
it
does
it?
Does
this,
so
has
a
corresponding
flow
in
the
other
direction
in
a
sense
that
do
we
support
a
be
directional
application?
A
We
suggest
to
have
an
idea
for
that
service
as
well
service
delivery,
type
analogous
to
the
previous
one.
It's
either
eaten
at
MPLS
or
an
IP
that
not
service
and
another
proposal
to
distinguish
point
to
point
and
point
to
multi-point
that
net
service
types
note
that
multi-point
to
multi-point
can
be
constructed
from
point
to
multi-point
services,
in
which
case
this
be
directional
becomes
handy
again
to
indicate
their
cover
correlated
the
service
rank
is
similar
rank,
as
I
explained
explained
before,
and
here
comes
a
difference
of
a
service.
Actually,
it
provides
the
delivery
profile.
A
H
From
highway
of
our
brief
question
and
what
is
the
relation
between
the
parameter
in
the
green
box,
the
tan
net
flow
format
and
the
parameter
in
the
sorry,
the
in
a
green
box
it?
It
is
called,
as
a
then
add
a
flow
format
in
the
blue
box,
it
is
called
a
telnet
service
delivery
type.
What
is
about
these
two
parameters
so.
A
A
I
A
So
the
flow
format
means
is
it
an
MPLS
that
not
the
implementation
or
an
IP,
and
you
saw
that
in
the
data
plane
that
I
make
mixtures
like
you
can
have
MPLS
over
IP
and
so
on.
So
in
the
same
network,
actually
you
may
have
the
same
very
same
packet.
Network
may
provide
both
type
of
data
players
in
some
form
that
not
MPLS.
Oh
definitely,
ok
and
it's
good
to
know
which
one
it
is
that's
the
idea
behind.
Ok,.
A
A
Not
so
multiple
AB
AB
flows
can
be
mapped
to
a
single
that
that
flow
and
coming
back
to
the
aggregation
one
way
of
aggregation
or
one
way
of
looking
at
that
that
aggregation
is
when
that
not
flow
to
be
aggregated
into
one
becomes
an
up
flow
and
from
the
perspective
of
the
aggregate
that
that
flow
and
the
mapping
of
that
not
flows
to
that
net
service
is
also
a
many
to
one
mapping
single
debt
net
service.
The
one
may
support
multiple,
that
not
flows,
and
you
see
also
the
red
items,
the
multiple
app
flows.
A
A
B
Is
yes,
so
getting
the
additional
reading
by
the
working
group
now
is
the
time
is
definitely.
It
sounds
to
wait
until
we
resolve
everything
on
the
first
set
of
documents
before
last
calling
this
one.
Yes,
that
said,
do
you
think
it
would
be
beneficial
or
a
negative
to
last
call
it
at
the
same
time
as
the
data
pine
documents,
I.
B
Trade-Off
fear.
The
trade-off
here
is,
is
we
might
end
up
with
a
lot
of
reading
change?
Oh
no!
No!
A
lot
of
reading
by
the
working
group
the
benefit
is,
is
people
will
read
it
as
a
set
and
get
the
full
picture
so
I
can
see
it
both
ways,
I,
actually
I
personally
well,
right
now,
I,
don't
have
a
strong
opinion.
This
will
be.
There
will
be
two
different
Shepherds
here
so
or
there
could
be
two
different
Shepherds
here.
You
knows
I'm
not
an
author
on
this,
so
we
have
some.
H
Good
afternoon,
everyone
this
is
issue
soon
and
I
will
introduce
our
work
about
the
tenant
configuration
yamoto.
In
this
version
we
end
a
new
order,
Yun
Chao,
and
he
contributes
a
lot
for
this
work.
Thank
you
for
his
contribution
and
basically
after
I
Kiev
well,
for
we
received
some
comments
from
the
working
group
and
basically
the
requirement
is
that
let
the
make
the
tenant
configuration
your
model
fitting
in
the
design
of
and
that
architecture
and
the
data
plan
solution.
H
So
here
is
the
the
result
of
our
new
work.
Basically,
we
define
four,
that's
not
a
configuration
instance.
The
first
is
the
application
flow
instance.
The
service
sub
leer
instance
forwarding
sub
their
instance
and
some
Network
instance
we
can
see
in
the
left
picture.
This
is
the
DES
net
data
plan
protocol
static,
defined
in
the
architecture
draft
and
the
right
picture
is,
is
the
picture
shows
that
how
we
use
the
test
net
configuration
instance?
We
define
in
this
draft
to
configure
the
net
discipline
protocol
stack.
H
We
can
see
that
it
can
match
with
each
other,
and
here
is
the
overview
of
the
whole
picture
of
the
configuration
your
model.
Basically,
as
I
have
just
introduced,
there
are
four
classic
classes
of
instance,
and
for
each
instance
we
have
at
least
inside
each
instance.
The
the
structure
is
similar.
We
have
a
name
the
operation,
the
in
segment
and
all
segment.
Here
is
the
parameters
for
each
instance.
In
application,
float
operations
include
sequence,
number
generation
and
the
in
segment
is
the
application
flow
identification.
H
It
can
be
layer,
three
application
floor
or
layer,
two
application
flow
and
it
can
also
be
a
tunnel
flow
and
the
assignment
is
a
pointer
to
a
lower
sub
layer
instance
than
a
serviceable.
Their
instance
here
is
a
question
to
be
discussed
whether
the
sequence
number
generation
of
this
operation
should
be
defined
in
the
application
flow
instance,
because
when
we
do
the
flow
aggregation,
the
the
sequence
number
generation
may
be
also
required.
So
maybe
it
can
also
another
choices
to
define
this
operation
in
the
service
sub
layer
instance.
H
Here
is
the
tree
of
the
llamado,
and
here
is
the
service
of
lyric
instance.
The
operation
have
two
classes.
The
first
one
is
the
service
operation,
including
service
initiation,
and
relate,
and
also
it
includes,
the
Service
protection
operation,
the
replication,
elimination
ordering
and
the
combination
of
these
operations.
The
instrument
is
done,
a
flaw
identification
and
the
assignment
is
the
attend,
a
service
of
layer,
encapsulation
and
also
a
pointer
to
the
lower
sub
layer
instance.
The
for
wordings
of
their
instance-
and
here
is
the
sub
layer
instance
tree,
and
also
the
for
wordings
of
their
instance.
H
The
operation
is
the
resource
allocation.
The
parameters
for
this
part
is
the
traffic
specification
and
the
instrument
is
forwarding
added
identification
and
awesome
and
is
the
forwarding
sub
layer,
encapsulation
and
also
a
pointer
to
the
sub
network
instance,
which
is
not
included
in
the
this
version
of
the
traffic.
Yet
here
is
the
tree.
H
Actually
we
don't
receive
very
or
a
lot
of
comments
from
the
mailing
list
here
here
is
the
one
of
them
from
Lu
application
flow
or
then
a
service
proxy.
This
discussion
is
about
the
name
of
the
we
think
it's
and
perhaps
it
can
be
a
new
sub
layer
for
that.
That's
not
but
I,
think
from
the
new
or
from
the
chairs
of
he
need.
It
is
just
the
application
flow,
and
so
we
keep
it
the
name
in
the
act
architecture
draft,
and
so
we
call
it
application
flow
instance.
H
E
David,
instead
back
welcome
like
to
say
that
I
made
you
something
productive
as
opposed
to
the
long
discussion
I
caused
the
last
draft
I've
just
sent
to
the
list.
The
two
changes,
the
IP
data
plane
draft
that
will
take
out
the
bitmask
and
take
out
ECM
for
identification,
and
so
once
those
changes
are
made,
everything
else
should
everything
else
should
be
reformed
a
place
by
following
that
that
updated
draft
okay.
B
H
Actually,
I
I
want
to
end
one
more
comment
for
that
discussion:
I
think
what
is
makest,
make
it
so
difficult
to
to
to
figure
this
out.
Perhaps
it
is
because
it
is
not
clear
what
is
the
relationship
between
the
traditional
diffserv
with
the
than
that?
So
if
we
can
figure
out
what
is
the
relationship
between
the
current
diffserv
service
and
the
DES?
Not
perhaps
it
is
easy
to
see
how
to
use
the
SCP
value
internet?
Yes,
another
discussion
and
continue
the
presentation.
H
What
is
the
next
photo
at
the
configuration
Yamoto
I
think
this
time
the
structure
is
can
can
satisfy
the
requirement
from
the
working
group.
So
maybe
this
time
the
structure
can
be
stable
and
afterwards
more
detailed
designs
can
be
ended
to
this
structure,
including
the
aggregation
case,
including
some
unsolved
issues
mentioning
in
the
slides.
H
B
B
I
think
I
had
I
made
this
comment
on
the
list,
or
perhaps
at
the
last
IETF
privately
I,
can't
remember,
which
I
think
we
have
to
have
a
framework
that
allows
augmentation
for
specific
technologies
in
the
future.
And
as
long
as
we
have
a
that
type
of
framework
that
allows
the
augmentation
for
both
the
sub
network
and
also
on
the
app
flow
side,
we
can.
We
can
continue
to
run
ahead
and
we
can
always
add
the,
for
example,
the
TSN's
as
their
own
documents
as
an
augmentation
to
the
base
model.
Yes,.
H
B
B
G
G
We've
made
all
of
the
various
queueing
techniques
that
we
have
standards
for
that
we
know
will
give
zero
congestion
in
one
section
6
as
parallel
subsections
under
Section
6.
We
have
given
the
various
queueing
techniques
more
equal
attention.
There
was
way
too
much
in
there
about
cyclic
queuing
and
forwarding
not
enough
about
some
others,
so
we've
even
that
out
and
section
8
parameters
for
a
bounded
latency
model
has
been
deleted.
So
now
Clause
3
how
you
create
a
flow
in
debt
net
1.
Is
you
configure
the
network
now
that
that's
not
silly?
G
You
may
provide
the
network
or
you
may
turn
on
certain
facilities
in
the
network
for
doing
that
net,
for
example,
and
configure
maximum
bandwidth
so
loud
on
certain
links,
all
sorts
of
things
you
might
configure.
Then
two
through
five,
you
loop.
You
have
a
flow
that
you'd
like
to
get
you
care
it.
You
have
to
characterize
the
flow
you
have
to
establish
the
flow
the
path
is
going
to
take,
and
then
you
have
to
compute
whether
or
not
you
can
accept
that
flow
and
what
sort
of
latency
you
can
give
that
flow.
G
G
One
computation
model,
depending
on
what
queueing
techniques
you
use,
it's
likely
that
every
flow
affects
the
latency
of
every
I.
Think
every
critical
flow
expect
affects
the
latency
experienced
by
every
other.
I
should
say
dead.
Net
flow,
not
critical
flow.
Every
bit
net
flow
affects
the
latency
of
every
other
dead
net
flow,
which
means,
when
you
add
a
flow
you
have
to
recompute
everybody's
latency
and
make
sure
that
everybody's
still
within
the
bounds
they
asked
for
when
they
started
some
queueing
techniques.
G
Allow
you
to
say
when
the
flow
says
can
I
come
in,
you
can
tell
that
you
can
tell
the
very
first
flow.
This
is
the
late.
This
is
the
worst
case,
latency
you.
It
will
experience,
and
you
know
that,
no
matter
what
other
flows
come
in
as
long
as
they
can
be
admitted
by
the
network,
they
won't
affect
the
first
flows.
Latency
I
call
that
the
dynamic
computation,
because
it
favors
dynamism,
that's
the
kind
of
situation
you
want
when
you've
got
lots
of
flows
coming
and
going
unless
you've
got
an
awful
lot
of
compute
power.
G
The
static
latency,
computation,
I
think
of
as
more
suited
to
less
dynamic
environments,
and
if
the
results
are
satisfactory,
you
reserve
the
resources
that
are
required
and
you
tell
the
sender
go
so
that's
described
in
Clause,
3
clause,
4
and
5.
We
have
gone
over
before
it
involves
queueing
model
and
involves
the
network
calculus
to
figure
out
what
the
latency
might
be
under
the
assumption
that
you've
got
using
certain
queueing
techniques.
G
G
There
can
only
be
one
interrupted
frame:
it's
not
multi-level
interrupted
frames,
but
the
four
main
queuing
methods.
We
talked
about
our
time,
scheduling
where
every
output
queue
is
gated
by
a
scheduled
gate
that
turns
that
queue
on
and
off.
You
can
turn
multiple
queues
on
and
off
and
in
which
case
you
use
whatever
queueing
techniques.
Whatever
techniques
you
have
priority
for
resolving,
which
one
of
those
gets
to
transmit,
we
have
the
asynchronous
traffic
shaping
which
well,
let's
talk
about
in
surfer.
6.5
is
intserv.
G
A
lot
of
us
know
how
insurv
works
it's
old,
but
it
still
works
where
you
have
a
per
flow
queue
for
the
for
the
net-net
flows
and
per
class
shaping
after
you
go
through
the
per
flow
queuing,
which
we
call
regulator
in
the
in
the
bounded
latency
document.
A
synchronous
traffic
shaping
is
really
very
similar
to
intserv,
except
that
you
have
fewer
queues.
G
You
have,
you
still
have
a
state
machine
per
flow
time,
state
machine
per
flow,
but
you
don't
have
to
have
as
many
queues
as
you
do
for
in
serve
and
cyclic
queuing
and
forwarding
is
doubly
double
or
triple
buffering
for
each
class
on
each
port,
where
buffers
are
cycled
in
synchrony
across
the
network.
I
think
you've
seen
this
slide.
This
is
cyclic
queuing
and
forwarding
the
to
buffer
version.
G
Basically,
at
one
moment,
packets
belonging
to
debt
net
throws,
through
throughout
the
network,
advanced
one
hop
and
then
click
all
the
packets
advanced
one
more
hop
and
click.
They
had
sorry
take,
they
advanced
one
more
hop.
Every
time
the
clock
ticks
all
the
packets
in
the
network
advanced
one
hop.
G
It's
easy
to
imagine,
especially
in
a
service
provider
network
that
the
time
to
get
from
one
to
get
over
the
wire
from
one
hop
to
the
next
stop
is
a
time
that
is
comparable
in
length
to
the
cycle
time.
If
that's
true,
your
ability
to
do
it
with
two
buffers
is
cut
down
because
you
have
to
get
the
packets
out
of
the
buffer
on
one
hop
over
the
wire
and
into
the
buffer
at
the
next
hop
within
one
cycle.
If
that's
difficult,
you
have
to
slow
the
cycle
way
down.
That's
not
good!
G
So
you
can
go
to
three
buffers.
I
was
asked
to
show
this
because
that
got
cut
off
at
the
last
time
for
lack
of
time.
Basically,
you
have
three
buffers
tick
on
the
input
side
in
synchrony
with
the
last
hops
output,
buffer,
tick
delayed
by
how
long
it
takes
to
get
to
this
hop
so
I
take
in
synchrony
so
that
all
the
packets
in
the
read
buffer
in
in
the
previous
top
all
go
into
a
single
buffer.
At
this
hop.
G
G
Periods
fast
and
slow
for
different
classes
of
service
at
the
same
time
to
accommodate
so
that
you
don't
have
to
you're,
not
saddled
with
the
choice
of
choosing
a
long
cycle,
which
means
you
can
have
lots
of
different
flows.
But
you
spend
a
long
time
sitting
at
each
hop
and
a
short
title
which
enables
you
to
get
good
latency.
But
you
can't
carry
very
many
flows.
G
This
summary
chart
is
not
in
the
document.
It
could
become
part
of
the
document,
but
I
think
it's
useful
for
us
to
look
at.
It,
compares
the
four
basic
services
on
certain
and
shows
that
there
are
really
good
trade-offs
and
really
good
reasons
why
you
would
want
to
use
any
of
these
techniques.
The
time
schedule
is
really
great
because
it
allows
you,
for
instance,
if
you
have
a
machine
tool
that
operates
as
many
machine
tools
do
on
a
cycle
of
communicate
for
a
while
think
for
a
while
communicate
for
a
while
think
for
a
while.
G
If
the
communicate
for
a
while
uses
up
most
of
your
bandwidth,
it's
nice
to
be
able
to
run
several
machine
tools
and
just
stagger
their
phase
run
them
all.
At
the
same
cycle,
stagger
the
phase,
so
I
get
to
use
the
same
network
for
this
for
different
machine
tools
at
different
times
during
the
length
of
the
cycle
that
requires
time
scheduling,
that's
not
suitable
for
intserv
or
diffserv.
That
requires
strict
time
scheduling
it's
very
hard
to
compute
a
good
time
schedule
for
a
network,
but
it
can
handle
almost
anything
and
it
gives
you
perfect
results.
G
G
G
G
G
It
the
nice
thing
is,
it
requires
zero
burst
flow.
State.
All
you
need
is
admission
control.
You
don't
need
to
touch
any
of
the
nodes
along
the
path
when
you
introduce
a
new
flow,
that's
good,
but
you
have
to
time
synchronize.
Everything
and
I
will
mention
my
little
footnote
here.
This
table
is
a
very
much
a
generalization,
there's
lots
of
factors
that
can
mitigate
some
of
these
differences,
and
there
are
other
queuing
schemes
that
have
been
proposed
to
make
some.
G
G
H
B
G
B
B
I
Thank
you
leon
from
china
mobile.
This
is
a
an
update
of
the
layer,
three
or
long
haul,
large-scale
data
net
latency
service
requirements.
So
we
actually
following
the
comments
which
received
from
last
ISF
meeting
or
we
approach
more
service
provider
to
collect
more
requirements
for
long
hold
at
net
service
requirements,
and
this
is
a
update
of
that
draft.
I
So
sorry,
just
a
little
bit
reminder
that
this
is
I
probably
need
to
change
the
name
of
the
doctor
that
the
the
name
of
the
document-
because
it's
so
similar
to
North
Face
document,
but
these
two
I
really
really
not
a
requirement
for
norm
fin.
It's
quite
different
view
of
the
bounded
latency
thing.
This
is
really
a
requirement
for
layer,
3
and
type
of
services
with
C
and
4,
for
example,
for
the
virtualized
plc
for
remote
surgery,
etc.
The
services
requires
long
haul
getting
that
deterministic
network
of
services.
I
So
that's
really
not
to
talk
about
how
we
calculate
or
how
we
modeling
the
latency,
and
there
is
no
solution
or
implementation
specific
in
this
document.
So
this
is
really
a
reference
or
justification
for
our
working
group
to
to
to
to
to
have
a
look
and
to
review
whether
this
is
a
interest,
a
topic
that
we
can
adopt
it
in
in
future
work.
I
So
just
a
quick
summary
of
what
we
have
been
doing
since
last
time,
so
that
the
the
previous
version
was
only
there
are
only
three
requirements
listed
and
for
this
update
we
actually
put
more
requirements
and
we
can't
ride
them
to
different
two
different
classes.
One
is
one
is
technical
requirement
and
the
other
is
operation
and
management
requirements,
so
we
have
altogether
seven
requirements
collected
and
the
first
one
and
about
how
the
requirements,
the
requirements
of
dynamic
creation
and
modification
lead
of
the
service
and
also
the
second
one,
is
about
the
time.
I
Variance,
tolerance
and
the
third
one
is
to
support
the
Intercontinental
or
multi
domain
or
long-haul
propagation
delay.
So
that's
for
the
technical
requirements
and
there
for
other
operational
or
and
management
requirements
which
were
comforting
that
in
the
in
the
few
upcoming
slides.
So
we
also
characterize
sorry
categorize
the
requirement,
as
must
or
should
because
some
of
them
are
well
in
at
present
is
quite
difficult
to
to
to
to
actually
to
realize.
So
we
put
we
put
it's
optional
so
in
detail.
I
The
first
requirement
is
to
support
in
layer
three
determinist
network
service
to
support
a
dynamic
creation,
modification
and
delete
or
deletion
of
the
services.
Basically,
as
more
than
mentioning
in
his
presentation,
we
don't
want
in
lot
a
long-haul
service.
We
don't
want
the
recalculation
of
everything
when
you
add
a
new
data
net
service
to
operators
Network,
because
they
we'll
give
you
scalability
problem.
I
So
this
is
a
requirement
that
we
must
support,
dynamic
creation
or
lifecycle
management,
but
with
minimum
complication
of
recalculation
of
everything,
for
example,
gate
control
or
the
resource
reservation
things,
and
the
second
requirement
is
to
tolerate
a
certain
level
of
time,
variance
and
maybe
I
need
to
change.
The
name
is
not
time
variance
but
they're,
two
part
of
it.
The
first
part
is
actually
the
time
synchronization
tolerance,
because
when
you
basically
talk
about
long-haul
transmission,
you
need
to
tolerate
the
time
synchronization.
I
When
you
connect
to
TS
in
domain
and
well,
we
can
transmit
the
synchronization
signal
between
domains,
but
in
real
network
either.
You
might
don't
have
these
capability
of
transmitting
the
synchronization
signal
or
the
performance
of
transmitting
the
synchronization
signal
across
a
long-haul
situation
does
not
actually
meet
your
performance
requirement,
so
this
is
for
the
time
synchronization.
The
second
one
is
for
your
clock.
Synchronization.
I
I
Let
me
try
to
explain
this.
So
when
you,
when
you
look
at
the
cyclic,
forwarding
or
psycho
scheduling
mechanism,
we
normally
in
a
in
a
strongly
synchronized
situation,
we
require
the
packet
and
to
be
sent
and
received
in
the
same
cycle
or
in
the
same
cycle,
the
cycling
scheduling
mechanism
and
that
lead
to
a
consequence
where
you
need
to
basically
increase
your
period.
I
If
you
are
actually,
you
are
transmitting
the
packet
with
many
many
hops
for
a
long-haul
situation,
so
that
make
your
jittering
performance
to
be
proportional
to
your
length
of
transmission,
and
that
is
something
we
don't
really
like
and
in,
for
example,
in
smart
factory
situation.
These
can
be
solved
what
sorry
well
in
in
local
area
network.
I
It
is
easy
to
understand
that
the
propagation
delay
can
be
constrained
to
a
certain
small
level
and
the
jitter
can
be
controlled,
because
you
can
have
a
very
small,
very
little
very
small,
I'm
cycling
in
period,
but
for
long
haul.
That
will
give
you
trouble.
So
there
might
be
a
need
for
a
mechanism
in
data
plane
that
the
J
terrain
performance
is
not
proportional
to
the
length
of
transmission.
A
A
Actually,
it
seems,
like
you,
have
chosen
a
solution
like
a
cyclic
queuing
monism.
So,
for
example,
you
just
heard
about
the
asynchronous
traffic
shaping
that
doesn't
have
this
type
of
problems,
and
the
other
assumption
you
are
making
in
a
previous
slide
is
that
in
the
TSN
domains
are
time
synchronized,
and
that
is
not
a
must.
So
one
example
is
a
synchronous
traffic
shaping
one
time.
Synchronization
is
not
used
in
many
cases,
it
is
used,
but
it's
as
I
understand.
Maybe
I
misunderstood
these
two
slides,
but
it
seems
you
chosen
a
solution.
I
A
A
I
J
J
G
Finn,
thank
you.
Something
for
I
knew
I
had
one
for
the
TSN
people
to
think
about
is
I,
know,
I
missed
it.
When
I
was
working
on,
I
mean
I
working
on
bound
the
bound
the
latency
draft,
I
kind
of
wanted
to
put
it
in,
but
it
wasn't
sure
how
and
that's
the
Paternoster
scheme,
which
I
think
might
be
somewhat
more
useful
in
meeting
this
particular
documents.
G
I
So
yeah
so
the
that's
all
for
the
technical
requirement
and
for
operation
and
management,
so
that
the
fourth
one
is
we
laid
out
they
like
should
have
self
monitoring
capability
is
basically
when
we,
when
operator,
trying
to
sell
their
deterministic
service
to
verticals.
The
verticals
are
normally
not
expert
on
next
expert
on
network,
so
that
would
really
like
to
have
a
visualized
type
of
tool
that
can
really
see
or
I'll
release
being
very
fertile,
convinced
that
the
service
the
service
provided
provided
actually
meet
that
the
SI
requirements
of
performance.
I
I
So
we
put
it
optional
in
five
and
six,
we
didn't
really
put
too
much
tests
on
the
drop
in
the
draft
and-
and
it's
really
simple-
that
you
need
to
be
wrong-
robust
against
boss
attacks,
because
when
we
talk
about
data
net
services,
most
of
them
are
in
very
critical
use
cases,
for
example,
v2x
or
remote
surgery,
things,
and
so
the
security
is
very
important
and
number
six
has
to.
It
must
tolerant
failures,
same
idea,
because
it's
critical
and
the
last
one
must
be
scalable.
I
When
we
talk
about
long
haul,
we
expect
that
hundreds
or
even
thousands
of
servers
running
in
the
shared
infrastructure
of
service
provider
in
terms
of
number
of
devices
and
in
terms
of
numbers
flows,
is
going
to
advocate
it
in
Metro
level
or
in
in
higher
core
level
to
make
the
network
work.
It
has
to
be
scalable
scale
in
terms
of
connected
device
and
activated
traffic
flows
yeah.
So
that's
all
for
the
update.
I
It's
really
an
informational
draft
or
informational
work
in
the
inner
working
group,
we'd
like
to
hear
from
the
audience
from
the
community
whether
these
requirements
is
a
good
or
at
least
useful
reference
for
detonate
group
to
actually
consider
for
future
work
and
we've
seen
some
discussion
over
the
list,
and
we
think
that
we
have
collect
quite
a
lot
of
requirements
from
a
service
provider.
And
so
we
would
like
really
to
call
a
working
group
adoption
for
this
document.
No.
K
Okay
and
no
I
understand,
let
me
start
like
this
I
really
like
this,
so
I
think
it's
pretty
close
to
working
group.
Adoption
has
saying
that
I
haven't
read
the
document,
but
if
it's
as
clear
as
the
presentation
is
I
think
we
are
very
close
to
go
for
working
group,
adoption
I
had
it's
a
couple
of
small
question:
can
you
back
up
one
slide,
so
the
must
and
should
in
red
here
are
those
the
traditional
ITF
upper
case
must
insured
that's
a.
I
K
I
think
if
it's
not,
you
have
to
go
back
and
actually
revisit
yeah
and
change
him.
Accordingly,
I
had
a
questions
about
the
numbers,
but
they
actually
here
in
seven
one,
seven,
seven,
two!
So
that's
fine.
Can
you
back
up
one
slide
more.
You
use
the
first
comment
here
at
Lincoln.
Nodes
failures
are
in
themselves
the
polish
changes,
so
it's
kind
of
the
same
thing.
So
what
I'm
saying
if,
if.
K
Like
this
at
optimal,
you
change,
so
you
need
to
tweak
the
language
around
that
definitely
yeah
go
back
one
more
slide.
So
I'm
a
little
bit
confused
about
the
long
link
definition
here,
Yusei
Intercontinental
yeah,
that's
fine!
We
can
figure
out
what
that
is
intercontinental
long
link.
Is
that
something
even
longer
or
is
it
something
something
else
so?
But
what
I'm
pointing
at
here
is
actually
there
are
words
like
long
big,
massive
whatever
that
is
not
defined
and
I
think
we
should
put
some
effort
into
actually
defining
what
it
really
is.
Yeah.
I
That
that's
very
good
suggestion
now
what
will
already
take
good
care
of
the
language
here?
Yes,
and
basically
a
little
bit
of
explanation
of
this.
It's
really
not
that
complicated
to
have
this,
so
many
were
to
describe
long
or
intercutting.
What
is
really
just
a
long-haul
situation,
so
we
need
to
rephrase
the
rows
to
better
describe
this.
Thank
you.
J
B
J
B
L
So
this
seems
rather
like
the
use
case
draft,
in
the
sense
that
it's
looking
at
making
sure
that
the
capabilities
agree
with
the
real-world
requirements
and
I
guess.
One
question
I
had
was
the
some
of
the
things
that
you
mentioned
here
seemed
to
be
already
part
of
the
common
themes
in
the
use
case
draft.
So
they
they
seemed
to
be
already
a
part
of
what
we're.
What
we're
doing
here
and
also
I
guess
in
the
use
cases.
I
Yeah
well,
I,
I
I
understand
your
concern,
but
the
use
case
is
really
in
a
service
or
application
point
of
view
of
describing
what
the
application
means.
The
the
what
application
actually
require
the
the
network
to
be
like
in
terms
of
functionality
and
performance,
but
this
requirements
exactly
technical
requirement
is,
is
you
know
the
use
cases
is
a
service
point
of
view
that
requirements
Network
point
of
view
and
use
case
could
be
a
guideline
for
the
working
group
or
the
dinner
net.
I
So
to
consider
what
detonates
that's
a
net
in
terms
of
technical
point
of
view
required
to
have
these
type
of
functionality
or
these
type
of
performance,
so
I
I,
don't
see
they
are
overlapping,
but
I
might
need
to
review
a
long
time,
not
reading
reuse
case,
but
I
might
need
to
reread
it
and
to
see
the
they're
any.
You
know
misunderstanding
this.
How
these
valleys
is
raised
to
make
you
have
this
kind
of
concern
so.
A
A
I
Think
we'll
talk
about
requirement,
people
have
different
understandings.
Sometimes
it's
like
use
case
requirements
like
in
3gpp
requirement
requirement
can
stand
for
use
cases,
but
this
requirements
document
really
does
not
talk
about
use.
Cases
like
like
video,
audio
or
things
like
that.
It's
really
what
the
network
we
think
need
to
be
function
or
need
to
have
that
sort
of
performance.
So
and
given
the
fact
that
use
case
hasn't
published.
A
G
Synchronizing
time
in
the
various
parts
of
the
network
and
having
the
same
frequency
in
the
various
parts
of
the
network,
I
know
that
there
are
service
provider
networks
that
maintain
frequency
lock
without
necessarily
time.
Synchronization
and,
for
example,
cqf
can
be
made
to
work
with
frequency
synchronization
without
necessarily
requiring.
G
I
I
G
G
G
I
B
F
It
sounds
like
I
think,
there's
probably
a
good
conversation
to
have
after
line
the
key
numbers.
I
remember
from.
Finally,
please
Stuart
Bryant,
the
key
numbers
I
remember
from
5g
or
1.2
microseconds,
or
you
can't
work
at
all
and
there
seem
to
be
a
whole
variety
of
different
numbers
between
350
nanoseconds,
going
down
to
150
nanoseconds
to
get
the
optimum
use.
So
you
I
can
imagine
that
those
sorts
of
qualities
of
time
are
going
to
be
almost
commodity
in
the
network,
because
every
transmitter
is
going
to
need
it.
M
I
think
the
number
Stuart
mentioned
we
need
to
differentiate
between
the
front
hall,
that
is
the
G
note
B
to
the
base
station
and
the
back
hall.
There
may
be
some
differences.
We
need
to
look
into
that.
Do
you
have
any
idea
on
that
number
such?
What
is
the
clocks
increments?
You
mean
the
exact
number
as.
A
Not
on
time
sink,
I
may
be
actually
on
the
list
at
that,
so
I'm
not
I'm,
not
sure
if
it
is
debt
net
requirements
really
on
on
time.
Seeing
all
these
time
sink
requirements
are
all
on
to
death
net,
because
we
said
that
we
mean
in
a
deployment
that
the
deployment
you
choose
your
time
singh
solution,
you
prefer
to
end
adequate
for
for
you,
so
I'm
not
sure
if
you
should
make
the
time
thinking
amended
that
network.
So
it's
it's,
it's
a
really
good
work.
B
I
think
we
need
to
wrap
up
this
this
conversation
and
to
do
that
I'd
like
to
understand
from
the
room.
How
many
think
people
in
the
room
think
that
this
is
a
this
topic
is
one
that
the
working
group
should
continue
discussion.
Discussing,
excuse
me
and
be
working
on
to
refine
and
to
document.
Remember
the
the
product
of
the
ITF
are
documents,
so
is
this
something
we
should
be
working
on
with
an
aim
towards
documenting?
B
So
if
you
think
this
is
something
we
should
be
working
on,
can
you
wait
hands
up,
I
call
that
a
reasonable
number?
How
many
think
we
should
not
be
working
on
this?
No
one,
so
that
that's
pretty
clear
how
many
folks
have
read
the
document
it's
less
than
we're
before,
but
still
a
reasonable
number?
How
many
think
that
this
is
a
reasonable
starting
point
for
our
work
in
this
area?
B
Each
time
we've
had
less
hands.
This
is
an
okay
number.
The
other
two
numbers
were
good,
is
it
this
is
just
okay,
so
I
think
there's
a
little
weakness
there.
So,
let's
maybe
you
talked
about
some.
Some
updates
perhaps
go
through
those
updates
see
if
we
can
have
some
more
discussion,
continue
the
discussion
on
the
list
and
if
we
really
want
we
have
time
in
the
second
session,
you
can
come
back.
We
can
talk
about
it
more.
B
B
Okay,
so
we're
just
having,
since
others
can't
hear
the
mic.
We
just
wanted
had
someone
who
wanted
to
make
sure
that
if
they
were
remote,
they
wanted
that
that
comment
was
captured.
We
think
the
comment
has
been
captured
if
someone
remote
has
something
to
say
just
say
that
mic
and
we'll
make
sure
to
get
it
in
there.
Alright,
so
thank
you
and
again
we're
gonna
have
time
afterwards.
So
if
we
want
to
have
discussion
on
this,
we
should
take
advantage
of
the
the
fact
that
we're
all
here.
B
B
H
H
H
H
Second,
a
suitable,
explicit
routine.
To
deliver
that
then
Flo.
This
is
naturally
supported
by
SRS
six,
because
we
can
define
a
second
at
least
to
do
this
and
a
method
of
indicating
the
packet
processing,
such
as
a
packet,
replication,
elimination
ordering
function
and
also
to
implement
these
functions.
We
will
need
the
item
identification
of
the
Dynaflow
and
also
that
then,
that
sequence
number
actually
also.
We
should
have
a
method
of
carrying
cueing
and
forwarding
indication
to
do
the
congestion
protection,
but
this
is
not
covered
in
this
version
of
the
draft.
H
H
Basically,
we
should
carry
the
flow
identification-
the
sequence
number
in
as
our
six
header,
the
first
option
is
we
can
carry
this
in
as
our
htlv
and
the
second
option
is,
we
can
extend
the
function
and
a
carrot
in
the
arguments
of
the
seat.
The
third
operation
option
is
that
we
can
define
a
new
dynasty
for
these
information
and
this
it
is
not
for
routing
it's
just
for
the
net,
and
here
is
an
overview.
How
to
do
this.
This
is
an
example
of
how
to
use
as
our
s6
to
do
packet,
replication
and
elimination.
H
H
Header
ipv6
hang
therefore,
and
the
as
rh4
will
steer
the
packet
from
relay
node
to
to
the
egress
and
the
you
know:
egress
the
packet
will
be
d
capsulated
and
the
native
ipv6
header
will
be
remained
and
the
packet
will
go
to
the
ana
station
to
a
so.
In
this
feature,
we
can
see
that
with
sr
6,
we
can
implement
packet
replication
and
the
elimination
ordering
and
all
these
functions
easy
easily.
So
I
think
it's
a
good
good
option
for
tonight
of
with
sr
6
implementation.
H
H
This
is
not
because
the
document
is
perfect
now,
and
this
is
the
chest
of
the
second
version
of
this
dogma
document
just
because
that
the
document
of
data
plan
solutions
again,
the
tenor
working
group
are
just
under
discussion.
If
we
can
adopt
this
draft,
I
think
we
can
catch
the
the
discussion
and
the
all
the
data
plan
solutions
can
be
considered
together.
Yes,
please,
yes,.
A
A
H
F
It
could
use
a
new
one.
Brian,
a
kid
is
a
new
I'm.
Sorry
I
keep
forgetting,
so
it
clearly
is
a
new
data
plane,
but
it
serves
best
properties
that
we
don't
have
in
the
existing
ones,
and
we
should
look
at
it
seriously.
I
think
we
should
also
take
into
account
there's
a
huge
huge
amount
of
work
going
on
in
SR
at
the
moment
and
network
programming.
If
you
were
in
spring
this
morning,
and
goodness
knows
which
one
of
those
is
the
right
one
to
pick.
Yes,.
H
And
this
this
document
will
also
be
presented
in
the
I
think
tomorrow
in
the
six
men
working
group,
and
we
just
try
to
show
this
work
to
more
people
who
are
familiar
with
SMS
six
and
we
can
seek
feedback
from
them.
But
we
also
think
it's
very
necessary
antenna
working
group
to
to
see
the
as
a
v6
can
do
this.
Can
you
implement
data
net
I?
Think
it's
necessary
I
I.
F
B
So
there
clearly
is
for,
as
Stewart
mentioned,
for
those
who
attended
the
spring
working
group
there's
clearly
a
lot
of
flux
in
SR
v6
at
the
moment,
that's
it.
That
is
a
good
thing
that
to
be
aware
of,
and
something
separately
to
track,
we
first
have.
The
first
question
is:
is
this
a
topic
that
met
SR
v6?
Is
that
a
topic
ooh
that
this
working
group
wants
to
be
working
on
with
an
understanding?
Is
that
goes
beyond
the
addition?
B
B
There's
a
few
people
if
you
think
we
should
not
be
working
on
debt
net
SR
v6.
Can
you
put
up
a
hand
low?
It
doesn't
like
by
phrase
the
questions
for
some
reason
so
you're
not
if
you're,
not
if
you
think
we
should
not
be
working
on
that.
Okay,
so
the
first
one
had
a
few.
The
second
one
had
none
so
I
think
that's
that's
reasonable
information
I've
now
generated
a
Q
Pascal.
Let's.
N
Get
you
here
so
I'm
curious,
because
there
are
two
things
right:
there
is
to
lay
out
the
path,
and
then
there
is
the
dynamics
of
this
like
how
many
packets
goes
through
this
path.
And
now
you
you
turn
your
Q's,
etc
and
I
see
how
a
service
six
can
be
used
to
Scott
encode
serialize,
a
complex
path
which
is
not
necessarily
a
series
of
hops.
So
we
can
see
all
that
stuff.
I
see
less
how
you
can
signal
everything
we
need
to
signal
in
the
packet
right
like
the
right
or
anything
like
that.
N
That
has
to
be
a
state
which
is
maintained
in
the
hops.
So
whatever
you
do,
it
seems
to
me
that
there
is
a
balance
between
what
goes
in
the
packet
and
what
tear
must
be
a
state
that
still
needs
to
be
resident
in
the
hops
at
the
very
extreme,
with
already
have
work
at
beer,
where
the
bits
just
indicate
the
segment's
like
replication,
but
more
thing
about
the
real-time
or
anything
above
just
one,
be
to
say
I'm
using
it,
meaning
that
the
purpose
is
strictly
already
laid
out
just
like
in
that
net.
N
Everything
is
in
the
hops
all
the
state
and
what
we
do
is
just
decide
per
packet,
whether
we
use
this
reservation
for
this
packet
or
we
don't
just
to
save
resources
right
when
I
see
this
I
have
a
feeling
that
way.
You
could
signor
dig
the
same
thing
or
you
could
signal
more,
but
I
don't
see
that
you
can
signal
it
all.
You
still
need
a
state.
That's
this
balanced
and
curious
about
know
you
feel
about
it.
H
Actually,
I
understand
your
your
concerns
and
I
have
read
your
draft
about
the
beer
kind
of
solution.
I
think
it's
really
an
interesting
option
for
for
do
a
packet,
replication
and
elimination,
because
the
the
packet
replication,
the
administration,
elimination
this
function
kind
of
similar
to
the
multicast
case.
So
if
we
use
beer
is
natural,
yes,
it's
a
natural
idea,
but
it's
totally
a
different
story
between
the
beer
and
sr6
in
beer.
We
just
use
the
the
bit
to
show
the
path
and
we
don't
need
more
status.
In
a
note.
H
F
Is
Stewart
round
again,
so
there's
two
high
order
bits.
First
off
we
do
need
a
full
bone,
IP
solution
that
will
be
deployable
in
regular
IP
networks.
Now
whether
those
networks
will
be
running
sv6
I,
don't
know
because
SRB
six
is
really
more
of
a
service
provider
sort
of
domain,
so
that
so,
if
we
even
if
we
do
this,
then
they're
still
potentially
a
demand
for
a
regular
IP
full-blown
solution.
F
Secondly,
this
has
to
align
with
what
is
going
to
get
deployed
for
network
slicing
in
practical
5g
networks
and
as
far
as
I
know,
the
industry
is
still
not
quite
clear
what
it
is
going
to
do.
I
know
there
is
a
big
push
for
sr
v6
for
this
equally
well.
What
I
hear
from
3gpp
is
they're
not
necessarily
sold
on
that
as
a
design.
H
Yes,
I
think
the
intention
of
this
drops.
They
won't
just
I,
think
it's
not
it's
just
another
option
to
do
that.
Net
with
as
I
were
six,
but
if
we
want
a
native
IP
I
think
that
the
current
worker
can
cover
the
requirements
right
and
you
we
want
to
do
this
with
sr6
and
we
have
a
new
draft.
Just
that
is
that
yeah.
The
intention.
F
F
K
Oh
LuAnn
isn't
the
first.
What
Stuart
said
I
think
I
agree
100%
with
that
I
have
you
said
that
I
didn't
like
how
you
phrased
the
questions
and
the
reason
I
didn't
like
the
question?
Was
that
I
think
it's
too
early?
We
need
to
wait
and
see
where
s
re6
goes
and
if
s
are
is
going
to
be
part
of
a
death
net
type
of
network,
then
we
need
to
do
something.
If
it's
fully
apart,
then
we
and
we
can
leave
it,
but
we
can't
make
that
decision
today,
but.
B
Go
if
we
have
a
contribution
that
that's
it
talks
about
debt
net
and
beer,
we
should
talk
about
it
there.
We
should
not
talk
about
beer
right
now,
because
we
are
actually
over
time.
So
this
topic
is
SR
v6.
If
you
have
a
comment
up
mock,
if
you
have
a
comment
on
SR
v6,
please
make
it.
If
it's
about
beer,
please
don't.
N
I
apologize
for
that
I
was
trying
to
say
there
is
something
you
can
signal
in
the
packet
and
something
which
must
be
a
state
in
the
note,
I
was
mentioning
view
as
an
extreme
case,
while
everything
is
in
the
node,
but
just
enabling
and
I
was
saying
hey
you
have
to
these
to
tell
us
what
goes
in
the
packet.
What
still
needs
to
be
a
stake?
That's
just
what
I
wanted
so.
B
We're
missing
out
your
keys.
What
we're
going
to
do
is
put
both
of
these
two
topics
at
the
end
of
our
agenda,
though
this
this
one
and
the
previous
one,
and
bring
up
the
speakers
and
see
where
we
go
from
there
and
if
we
have
more
conversation,
we'll
take
advantage
over
the
comments.
Okay,
all
right,
so
we
will
be
back
here
and
fifteen
minutes.