►
From YouTube: IETF101-DETNET-20180323-1150
Description
DETNET meeting session at IETF101
2018/03/23 1150
https://datatracker.ietf.org/meeting/101/proceedings/
B
B
A
A
One
of
the
most
important
things
we
did
in
the
first
session
was
to
acknowledge
that
the
the
services
community
that
Taylor
has
done
in
the
last
I,
don't
know
how
many
years,
but
she
is
retiring
and
will
no
longer
be
serving
as
chair
after
this
meeting.
We
we
really
want
to
show
our
appreciation
or
we
showed
our
appreciation,
and
we
want
to
thank
her
again
for
contributing
to
this
group
and
getting
it's
helping
to
get
started
and,
of
course,
the
IETF
and
it's
your
work
here
as
well
as
Court
with
I
triple-a.
Thank
you
again.
A
A
We
have
the
same
audio
streaming
and
video
here
and
please
join
either
pad
the
link
is
in
Jabra
at
the
start
of
the
Jabra
session.
For
today,
as
well
as
on
list,
we
really
appreciate
you
helping
take
notes
I'm
on
jabber
and
I'll.
Look
at
it
as
frequently
as
I
can,
although
sometimes
I
miss
things
so
it'd
be
helpful.
If
other
people
join
as
well,
blue
sheets
are
going
around,
please
sign
them.
I
was
trying.
I
was
madly,
trying
to
update
slides
because
we
have
an
agenda
change.
A
A
Excuse
me
is
that
we're
going
to
aim
to
do
wrap
up
actually
a
little
earlier
and
try
to
really
have
be
wrapped
up
on
the
data
plane
discussion
by
two
to
have
then
Stewart
talked
about
the
advanced,
VPN
or
enhanced.
Sorry
not
advanced
enhanced
VPN,
which
we
actually
have
talked
about
in
this
group
many
times
as
the
TSN
over
debt
net
service,
and
he
has
put
together
a
framework
that
covers
both
that
case
as
well
as
other
use
cases.
A
That
will
come
before
that
IGP
presentation,
if
we
hit
the
if
he
still,
we
still
have
time
after
that,
we
will
talk
about
the
ICD
presentation,
as
I
mentioned
right
now.
Control
plane
is
out
of
scope,
but
it's
if
it
helps
inform
what
we're
doing
in
our
information
modeling
and
our
yang
modeling.
Having
that
perspective
is
useful.
Still.
A
A
We
are
on
rock-solid
ground
by
the
end
of
this
meeting
now,
there's
other
parts
of
the
data
plane
that
we
are
still
left
to
be
done
like
the
queuing
discussion
that
we
had
this
morning
or
even
the
aggregation
discussion
that
was
touched
on
where
we're
a
little
bit
of
where
we
were.
We
had
alternatives,
completed
in
September
of
16.
We
basically
had
a
design
team,
look
at
a
whole
slew
of
different
data
plan
alternatives
and
try
to
come
up
with
a
recommendation.
A
A
We
said
that
this
is
sort
of
the
direction
of
the
working
group
and
we've
had
some
discussions
along
the
way.
Then
we've
gone
back
and
forth
on
some
things,
and
now
is
the
time
that
we
thought
we
we
say
these
are
the
national
data
plane
encapsulations
used
in
debt
net.
One
of
the
important
things
to
note
is
that
this
is
the
doesn't
say
that
there
can't
be
future
enhancements
to
these
data
planes
or
future
alternatives.
A
So
keep
in
mind
that
net
is
more
than
just
pref,
although
preface
certainly
folk
taken
or
consumed
a
vast
majority
of
the
data
plane
discussions,
it's
just
one
of
the
debt
net
services
and
it
is
only
one
way
of
doing
service
protection.
For
example,
the
architecture
allows
for
should
allow
a
useful
life
or
hopefully,
still
does
allows
for
alternate
service
protection
mechanisms
and
I
believe
network
coding
is
mentioned
as
a
future
possibility.
So
pref
is
just
one
piece.
Certainly
we
like
to
focus
on
it,
but
we
have
to
keep
in
mind.
A
It
is
just
one
way
of
delivering
one
of
the
core
services
of
debt
net.
We
also
have
congestion,
protection
and
latency
control.
My
personal
favorite
there
is
zero
congestion
loss,
but
that's
it's
personal,
the
favorite.
We
have
explicit
routes
or
route
pinning
and
the
talked
about
with
already
service
protection.
The
core
usage
scenarios
we've
been
focusing
on
is
TSN
over
debt
net
and
ipv4
v6
and
end
service.
We
certainly
had
a
time
where
we
said
that
we're
going
to
do
v6
first
then
worry
about
before
later
and
I.
A
A
A
Document
it
and
then
ensure
that
we're
that
that
is
what
we're
doing
so,
the
the
next
thing
is
is:
do
we
have
agreement
on
what
the
simplified
IP
approaches
and
we
expect
that
to
be
for
both
v4
and
v6.
If
we
have
time
it
would
be
good
to
agree
on
approaches
for
IP
over
MPLS
there's
a
couple
of
different
ways
of
doing
it.
We
can
either
do
in
to
carry
IP
sort
of
the
natively
over
MPLS,
like
you
would
do
in
a
core
instance,
or
we
can
do
an
l3
VPN
approach.
A
We
have
to
talk
about
that
with
whether
we
want
to
allow
for
well.
Certainly
we
don't
want
to
preclude
anything,
but
do
we
want
to
define
both
or
do
we
don't
want
to
focus
on
one?
We
have
the
queueing
discussion
and
that
norm
touched
on
aggregates
that
Stuart
touched
on.
Actually
you
also
hit
o
a.m.
and
transport
protocol
impact,
which
was
touched
on
in
the
last
meeting
by
Pascal,
and
we
really
don't
expect
to
get
to
that
last
one
if
we
get
to
any
of
these
other
topics
for
me
and
for
the
chairs,
that's
gravy.
C
B
C
C
A
C
I
think
it
would
be
good
for
this
to
to
make
an
explicit
ask.
You
know,
for
people
to
have
feel
confident
of
explicitly
revisiting
this
in
the
case
of
multicast
I'll.
Try
to
do
it
for
myself,
but
if
you
don't
have
sufficiently
many
people
coming
back
say
that
they
feel
sufficient.
You
know
having
reviewed
it
sufficiently
to
support
multicast,
then
you
may
want
to
not
want
to
claim
it
right
right.
A
A
C
I
think
the
high
level
stuff
would
really
be
when
we
go
to
the
review
and
have
people
feel
confident
right,
maybe
ask
the
question:
if
you
also
feel
confident
about
right
there
supporting
multicast
and
then
you
make
a
judgement
call
of
whether
it's
considered
to
be
included
because
I
can
think
of
thousand
examples.
Like
you
know,
differential
delay
for
norm
fins,
you
know,
bounded
latency
document
is
another
factor
that
you
know
doesn't
exist
in
unicast
and
yada.
D
A
And
this
goes
to
a
side,
conversation,
Stuart
and
I
had
and-
and
we've
has
been
mentioned
in
group
before
is,
while
we
look
thinking
normally
of
the
1+1
case,
it
actually
is
a
1
plus
n
case
and
you
may
have
n,
plus
1
1
plus
n.
You
may
not
be
receiving
two
packets
that
you
have
to
eliminate
from,
but
you
may
have
n
and
that
we
certainly
have
mentioned
that,
but
it
doesn't
get
mentioned
a
lot
and
I
I
suspect.
So
what
is
right
that
will
multicast
will
fall
out
if
we
get
it
right.
E
A
This
is
really
the
key
points
for
the
kickoff
I
had
a
couple
of
slides
that
just
reminded
people
of
what
IP
over
TSN
is
and
what
we
mean
by
end-to-end,
IP,
I
think
the
other
documents.
Other
discussions
have
hit
on
this
a
little
bit
and
and
we'll
get
on
this
get
more
on
this
and
so
I'm
gonna
skip
over
that
and
a
we
previously
did
say
that
we
are
not
gonna
aim
to
do.
End-To-End
IP
with
trying
to
modify
the
IP
staff.
I.
Think
tour
list
really
captured
the
key
point
earlier.
A
E
F
A
F
G
Okay,
this
is
just
a
slight
get
in
order
to
to
have
some
background
photo
discussions,
and
we
have
added
here
in
this
slide
kit.
Some
background
material
and
some
drawings,
which
we
think
can
help,
can
be
helpful
during
the
discussion.
So
this
is
how
we
have
constructed
with
the
slides
with
Norman
Union.
G
So
what
we
know
is
that
we
have
two
service
types.
One
is
when
we
are
doing
clear,
two
or
TSM
transport,
or
whether
data
domain
or
we
are
doing
IP
transport
over
that
mental
main,
and
we
are
considering
two
type
of
encapsulation,
MPLS
and
I.
Think
observation:
this
is
a
drawing
from
the
architecture
draft,
and
this
is
just
in
order
to
highlight
what
that
net
functions
we
have
and
how
we
have
grouped
them.
So
the
first
is
congestion
protection.
G
It
is
particularly
the
queuing
related
stuff-
and
this
is
value
annuity
flow
identification
for
this
function,
to
work
properly,
explicit
rules,
which
means
practically
traffic
engineering
parts
and
again
for
it.
This
you
need
flow
identification
and
there
were
third
rule
which,
where
we
have
spent
a
lot
of
time-
and
this
is
a
real
service
protection.
G
This
is
where
we
have
application,
elimination
and
in
order
to
livery
function-
and
this
is
the
functionality
which
required
a
sequence
number
to
be
included
in
the
transported
packets
and
we
have
three
type
of
turf:
that
nodes
defined
H
nodes,
relay
node
and
transit
nodes.
So
that
was
super
only
background.
G
So
we
have
practically
two
fields:
update
the
data
control
work,
which
provides
secuence
number
for
packet,
replication
and
duplicate
elimination
purposes,
and
that
net
service
label
that
identifies
the
rapid
flow
within
the
death
net
agent
relay
notes
and
what
you
can
see
on
the
right
side.
This
is
just
something
that
we
have
put
in
the
data
plane
solution
as
a
simplified
representation
of
desync
observation
formats.
C
For
the
for
the
control
work
for
the
sequence
number
right,
I'm,
assuming
the
the
context,
is
the
s
label
not
that
you
label?
Yes,
alright,
so
I
think
that's
that's
a
scalability
question
we'll
have
to
ask
ourselves
right:
I'm,
not
I,
haven't
try
to
figure
out
if
they're
maybe
need
to
have
the
context
be
defined
for
through
the
T
level,
because
that's
not
mistaken
the
aggregation
and
would
result
in
fewer.
D
D
A
D
C
So,
maybe
just
to
finishing
my
point
right
I'm,
not
not
the
expert
on
the
MPLS
side
enough
right,
but
I-
think
it
would
be
good
to
figure
out.
What's
the
you
know
best
flexibilities,
we
have
to
define
or
assume
context
for
the
control
work
right.
So
if
it's
just
the
the
fix,
the
s
label,
that's
probably
the
most
simple
definition
but
I'm.
Just
you
know
worried
about
the
scalability
of
the
number
of
kind
of
control
workflows.
We
can
support
because
yeah
I
mean
well
it's
it's.
C
It's
fairly
heavy
state
right
in
terms
of
trying
to
keep
memory
for
the
sequence
numbers
you've
received
in
the
last
reasonable
window
of
packet,
so
they're
they're,
I
think
a
lot
more
expensive.
Then
let's
say
the
per
flow
Q
s
thing
we
may
want
to
have
for
the
bounded
latency.
So
we
want
to
be
careful
of
if
we
have
anything
that
could
make
it.
C
You
know
for
aggregates,
like
for
I,
mean
we've
been
thinking
of
the
28
bits
as
something
that
is
fairly
large
enough
for
aggregates
right
for
all
the
traffic
from
let's
say
one
ingress,
no
to
one
egress,
node
and
so
yeah.
If
the
context
of
these
could
be
defined
more
flexibly,
so
that
we
can
support
them
on
aggregates,
that
would
help
us
a
lot
with
yeah
optimizing
hardware,
resources
and.
I
Emails
just
in
response
to
to
Alice's
point
about
scalability.
The
scalability
is
exactly
the
same
as
both
for
pseudo
wires
and
for
layer,
3,
VPN
s
and
I
would
like
to.
You
know
just
point
out
that
we
have
extensive
experience
in
the
field
that
that
the
the
routers
work,
fine
with
the
in
terms
of
scalability,
with
the
current
definition
of
of
that
label.
C
So
I'm
not
aware
of
implementations
in
l3
VPN
equipment,
where
the
sequence
number
is
actually
used
to
do
per
packet
deduplication
and
that's
basically,
what
brings
in
the
state
requirements.
So
any
evidence
of
that
to
work
at
the
same
scale
is
the
well-known
large
number
of
l3
VPNs
that
could
be
supported.
That
would
be
great
input
because
right
now,
I
don't
think
it
exists.
No.
A
So
you'll
note
that
there's
multiple
T
levels,
so
we
certainly
could
there's
nothing
that
precludes
an
implementation
from
adding
more
labels
if
it
needs
more
context
and
based
on
the
control
plane
we
want
to
just
or
or
the
management
plane
you'd
want
to
ensure
that
it
doesn't
preclude
that
yeah.
It.
C
Trying
to
bring
it
up
from
the
perspective
that
you
know,
Stewart
or
other
NPLs
expert
would
jump
up
and
saying
yeah
that
what
might
be
you
know
what
changed
the
control
plane
to
imply
that
type
of
semantics
that
it
would
be.
You
know
that
the
context
would
be
the
the
T
word
or
no,
you
can't
do
it,
even
not
in
the
forwarding
plane
that
semantics
the.
D
D
A
A
Losing
my
voice,
apparently,
when
we
did
the
analysis
offline,
we
identified
that
there's
a
spectrum
where
there's
absolutely
no
issues
and
it's
only
when
we
started
talking
about
flows
at
about
400
gig.
So
this
is
a
flow
of
400
gig
at
64
byte
packets,
that
we
started
running
into
issues
with
the
number
of
bits
we
have
available
and
again
that's
not
a
link.
That's
a
flow
and.
A
E
E
It's
not
just
the
things
we've
used
this
before
and
yes,
it's
true
that
it's
some
that
very
high
data
rates
per
flow
I
could
overflow
that
number,
but
keep
in
mind
that
anything
more
than
16
bits
assumes
that
I
can
remember
which
of
the
last
32
K
packets,
I've.
Seen
if
you
want
to
go
to
28
bits.
That
implies
that
I
can
remember
exactly
which
of
the
last
two
to
the
27th
packets,
I
have
seen
and
I
haven't
seen.
E
E
If
people
say
they
want
to
have
more
bits
than
that,
but
it's
absolutely
essential
that
we
have
an
OP
for
16
bits
only
because
I
want
to
interoperate
with
existing
equipment
that
has
only
16
bits,
so
I
have
to
know
when
I
see
when
I
go
from
2
to
the
60
2
to
the
16th,
minus
1
to
0
I
have
to
know
whether
to
reap
treat
that
as
a
new
packet
or
as
something
I've
already
seen.
Ok,
so
every
device
has
to
be
able
to
run
in
16-bit
mode
whatever
we
do.
C
I
think
this
this
goes
back
to
a
more
precise
specification
of
you
know
the
behavior
of
the
duplicate
elimination
right
because,
in
my
mind,
I
was
assuming
something
like
I
would
definitely
never
have
more
than
16
bits
in
the
bit
mask
of
the
you
know,
packet
numbers
I've
received,
but
it
might
be
sliding
window
within
the
28
bit.
So
you
know
everybody
may
have
their
own
assumptions
right.
C
So
I
haven't
tried
to
figure
out
if
all
the
things
that
people
typically
do
when
they
have
larger
sequence
number,
but
obviously
only
a
smaller
part,
which
is
active.
How
much
better
that
is
over
saying
model.
Everything
is
fine
with
a
16
bit
and
we
may
get
very
close
to
you
know
overrun
there
right
so
I
think.
That's
that's
an
important
design
parameter,
but
yeah
I
mean
I'm,
not
sure
how
fast
we
can
work
out
all
these
details,
but
yeah.
A
D
Let's
do
it
absolutely
agree
with
all
of
it,
I
think
what
we're
headed
for
here
is
that
the
size
of
the
window
and
the
size
of
the
sequence
number
are
parameters
that
we
set
up
when
we
establish
what
I
would
call
it
a
pseudo
wire,
but
whatever
we
going
to
call
this
being
a
name.
What
this
thing
is
is
it
you
know,
debt
was.
J
A
K
Okay,
alright
girl,
yeah,
it's
23,
Monty
yeah,
so
I
agree
what
what
said
about
the
what
norm
said
and,
what's
worse,
said
about
the
sequence
number.
So
so,
even
even
the
current
draft,
the
working
group
traffic
sir,
says
that
the
the
amount
actually
used.
Pcs
is
something
that
needs
to
be
accurate
by
the
control
plane
and
the
the
current
hardware
that
I'm
aware
that
that
actually
do
packet,
replication
elimination,
so
T,
dot,
one
CP
and
and
which
are
fixed
to
a
16-bit,
a
sequence
number.
K
F
A
Microphone,
we
are
people
you
per
month.
So
the
comment
from
the
floor
is
that
just
because
you
know
to
you
has
done
something
doesn't
mean
that's
what
we're
doing
and
that's
absolutely
correct
and
that's
why
we
have
to
have
agreement,
make
sure
our
document
captures
it
and
I
think
yoni
you're
saying
that
our
document
already
captures
this
point.
So
do
I
extent.
E
A
E
A
D
G
I
I
Echo
what
Stuart
said
earlier
when
we
first
came
to
the
slide.
We
just
finished
some
work
in
the
pals
working
group,
which
was
the
result
of
routers
doing
the
wrong
thing
as
a
result,
so
they're
not
being
the
control
word
for
Sue
the
wires.
So
we
absolutely
must
contain
the
control
word.
Even
if
it's
just
32
bits
of
zeros,
you
know
through
two
bits
is
cheap
and
we
got
a
lot
of
functionality
out
of
it
and
we
absolutely
need
it
so.
D
You're
also
needed
for
your
OEM
if
we're
going
to
have
a
standard,
OEM
method,
but
yeah
we've
been
through
a
whole
load
of
pain
as
soon
as
you
launch
any
of
these
packets
to
a
non
detonate
part
of
the
world,
if
you're
ever
going
to
go
across
it,
those
packets
could
go
anywhere
and
be
completely
miss
ordered
if
you
don't
have
that
control
work
there.
So
please
keep
the
control
word
a.
K
A
So
that
covers
the
case
of
Ethernet,
a
layer,
2
VPN,
where
we
control
word,
is
currently
used
pretty
much
everywhere.
There's
one
case
in
evpn,
where
it's
not
and
it's
I,
think
agreement
from
field
experience,
that's
a
bad
idea
and
that's
what
that's
what
I
think
you're
referring
to
a
palace
of
cleaning
up,
so
that's
l2
VPN.
So
that's
pretty
clear!
So
that's
one
case
of
MPLS
without
graph
we
also
have
l3
VPN
and
one
more
case
after
that.
But
it
looks
like
Stewart.
You
want
to
say
something:
yeah.
D
A
D
A
I
A
D
I
D
A
I
think
the-
and
this
is
as
a
contributor
or
not
as
a
chair
I-
think
we
have
to
be
really
careful
if
we
start
changing
how
IP
over
MPLS
works
in
the
data
playing
that
we
have
to
be
really
conscious
of
what
we're
doing
and
make
sure
we
have
really
wide
buy-in.
So
if
we
do
decide
to
go
that
way,
we
really
have
to
be
talking
to
the
MPLS
working
group
on
this.
Well.
I
A
D
A
I
A
C
Fix
your
charter,
no
I
mean
if
I
remember
correctly,
the
the
control
word
and
the
zero
bits
were
also
done.
As
you
know
way
for
worker
rounding
on
something
was
broken
in
you
know
the
way
MPLS
was
used
right,
so
I
think
we've
prior
evidence
that
if
we
do
understand
problems-
and
you
know
they
create
more
ugliness
and
what
we
want
to
do,
then
let's
bring
it
on
the
table.
I'm,
not
sure.
If
any
of
the
things
that
Stewart
mentioned
would
have.
You
know
reasonable
additional
workarounds,
or
else
we're
saying
we
don't
care
about.
A
A
A
So
I
think
what
we
heard
here
is
without
pref
for
layer,
2
VPN.
This
is
a
no-brainer
to
always
include
the
debt
net
control
word
is
that
correct?
Does
anyone
object
to
that
great
with
IP
I
heard
that
there
is
a
preference
to
use
the
control
word
from
some
people?
I'm,
not
sure
we
have
it's
clear
to
get
that
we
have
agreement
in
the
room
because
we
didn't
get
here
from
all
people,
so
I
think
it
would
be
good
to
ask
the
folks
that
are
here
to
questions
of.
Do.
A
A
C
C
A
Well,
I'll
make
one
observation:
there
is
we're
talking
about
that
net
over
MPLS
not
dead,
not
over
pseudo
wires.
So
we
have
a
control
word,
that's
part
of
it,
but
so
does
MPLS.
So
if
there's
a
mechanism
that
we're
going
to
use
it's
okay
to
use,
MPLS
mechanisms
and
fact,
particularly
when
we
get
to
the
tea
level,
we're
gonna
have
to
use
those
mechanisms
right.
C
D
Skew
it
so
I
guess
the
right
way
to
think
about
this
is
we.
We
almost
certainly
need
to
have
a
VPN
type
approach
in
the
system,
because
HPE
H
nodes
may
well
be
handling
two
different
clients
on
two
different
term
services.
We
also
need
to
consider
that
we
will
probably
have
to
run
prep
on
some
of
these,
so
the
right
way
to
approach.
D
It
is
probably
to
define
VPN
over
with
the
control
word
in
there,
and
if
there
are
specific
cases
where
we
want
to
simplify
that
by
taking
bites
out
of
the
of
the
header,
then
they
should
be.
They
should
sort
of
stand
on
their
own
merits,
but
we
can
do
everything
if
we
have
a
VPN
label
and
a
control
word
in
there.
You
know
we're
kind
of
golden.
As
far
as
I
can
see,
we
may
put
ship
a
bunch
of
zeros,
but
we
can
solve
all
the
cases.
A
K
So
in
my
previous
life,
so
the
experience
will
start
the
the
last
option
is
best
better.
So
echoing
what
Andy
was
saying
that
that
is,
do
a
unified,
heater,
constructive
Tiff's
as
possible.
So
it
just
makes
life
easier,
even
if
you
are
not
using
at
some
point
so
that
we
can
work
around
with
some
some
mechanism,
control,
plane
or
reserving
bits
or
something.
D
A
D
Stewart
I
think
that's
what
I
was
trying
to
propose
before
just
because,
if
ever
we
need
prep
with
I
with
with
IP,
we
will
need
the
sequence
number,
which
means
we
will
need
the
control
word,
which
means
that
and
we
probably
want
some
context
for
it.
So
what
I've
been
saying
is,
let's
always
go
assume
VPN,
which
provides
context
control
where
which
provides
context,
and
then
the
IP
and
we're
not
to
optimize
away
those
two,
those
bits.
D
A
D
A
A
A
A
G
A
G
Okay,
so
the
next
discussion
point
is
about
ith
observation.
Here
we
have
the
scales
during
the
winter
in
the
simplified
IP
approach,
and
that
would
be
that
they
are
using
the
application
native
encapsulation
format.
So
the
dotnet
encapsulation
is
the
unmodified
IP
stack,
and
here
we
can
use
a
sixth
uproar
in
order
to
identify
flows.
Of
course,
we
can
make
white
card
on
it,
and
that
means
that
there
will
be
no
segments
number
included.
G
So
the
impact
of
that
that
there
is
no
sequence
number
included
that,
as
you
can
see
here
in
the
slide,
this
upper
break
and
two
and
prep
scenario.
This
is
what
is
not
the
case
for
the
simplified
IP
approach.
What
we
have
is
the
case
below,
where
in
each
segment
ring
or
subnet,
the
appropriate
Mohamed's
will
ensure
pref
inside
that
link
or
subnet.
G
So
how
the
encapsulation
looks
like
so
this
is
how
a
simplified
IP
packet
looks
like,
so
we
have
a
payload
and
it
is
in
a
IP
transport
rather
like
UDP.
They
have
the
IP
header
data
link
and
physical,
and
we
can
use
the
six
that
were
in
order
to
match
the
flows,
and
we
have
this
flow
identification
per
hope
and
the
standard
route
I
think
had
a
processing
at
each
hop.
So
we
are
just
touching
the
TTL
and
the
checksum
infant
and
to
implement
that
functions
with
the
simplified
IP,
then
for
the
congestion
protection.
G
G
G
A
D
G
A
G
We
need
that
for
the
discussion
so,
but
this
means
that
where
the
red
circles
are,
this
is
very
very
to
simplify
the
IB
encapsulation
between
the
segments,
which
is
just
a
highlighting.
Did
that
blue
Tannas
inside
that
you
can
have
additional
encapsulations.
You
can
add
sequence
number,
but
your
prayer
function
will
be
limited
between
that
blue
stuff.
So
here
in
this
figure,
for
example,
you
have
three
prayer
domain
and
they
are
operating
independently.
G
D
So
that
what
we
just
wanna
measure
on
we're
all
actually
in
sync
here,
so
this
is
the
case
where
basically
we're
not
doing
anything
different
from
what
we
do
today,
we're
doing
a
an
ACL
to
use
to
map
the
packet
into
a
queue
at
each
hot,
where
we
care
and
the
packets
go
as
regular
IP
in
order.
So
this
is
just
unmodified
IP
with
a
bit
of
ACL
mapping
to
cubes,
except.
K
K
I
A
Right
and-
and
in
fact
that's
exactly
what
the
proposal
is-
is
that
the
end
point
would
be
limited
to
the
sub
Network
alone,
yes,
which
is
which
we're
saying
is
for
it
right,
for
example,
TSN
in
the
other
places
you
might
have
a
technology
like
IP
over
MPLS
yeah,
it's
like
we
just
described
or
IP
over
MPLS
over
IP.
That's
also
yes,
so.
I
Yeah
I
would
have
been
happier
if
those
circles
have
been
different
colors,
because,
just
because
all
four
circles
are
red,
someone
could
get
the
impression
that
they're
all
the
exact
same
encapsulation,
okay,
right
and
the
same
treatment-
and
you
know
someone
could
get
the
impression
just
by
looking
at
that
diagram
as
it
is
now
that
that
all
four
circles
get
the
insane
capsulation
and
the
exact
same
treatment.
Yeah.
That's
not
necessarily
so.
A
I
C
A
C
C
Do
you
mean
the
diff
server
architecture?
Well,
yeah
I
mean
if
you
look
at
AF
right
where
packets
are
having
a
of
41,
42,
43
and
so
on
right.
It's
one
flow
right,
but
it's
basically
you
know
that
the
PHP
is
defined
through
different
DHCP
classes.
That's
fine
right,
but
that
is
not
a
sixth
Apple
classification
to
me.
The
flow
is
classified
by
five
couples
and
menya
sure
you
can
use
multiple
DSPs.
But
so
what
is
your
idea
of
a
six
type
of
classification
as
I
said
right?
Is
there
any
example?
C
A
C
E
E
We
do
have
that
situation
where
you
have
a
layer,
two
priority
which
is
different
on
different
packets
and
the
rule
that
we
use
there
is
that
it
has
to
have
the
flow
ID
and
it
has
to
have
the
right
priority,
or
in
this
case
the
SCP
in
order
to
get
the
debt
net
bounded,
latency,
zero
congestion
loss
service.
If
you
have
a
packet
in
a
flow
that
has
the
wrong
dscp
I,
would
expect
it
to
not
get
the
same
treatment.
E
C
I
give
me
any
example,
so
let's
say
we're
saying
what
what
I
think
is
correct
is
we're
classifying
flows
by
up
by
the
five
top
line
each
of
these
fields,
and
the
five
couple
can
of
course
be.
You
know,
wildcard.
What
do
you
think
we
can't
do
right
inside
the
flow?
We
can
use
all
the
DHCP
s
as
we
want
to
define
sure
if
we
want
to
put.
A
A
That's
a
debt
net
flow
classification,
we're
not
trying
to
use
the
don't
use
the
the
dscp
flow
and
sub
flow
definition
where
we
have
this.
Is
the
debt
net
flow
definition?
So,
if
you
want,
you
can
think
of
it,
as
am
how
do
you
map
dscp
the
SCP,
aware
flows
to
debt
net
flows
or
to
get
to
the
debt
net
service?
So
we're
saying
well,
here's.
Maybe
this
is
a
better
way
to
phrase
it
for
you
is
that
these
map
to
different
debt
net
services
does
that
help
you.
D
D
M
We
shall
stick
pointing
out
that
maybe
the
application
flow
is
the
five
topple,
but
the
debt
that
flow.
The
thing
that
that
net
cares
about
inside
that
flow,
yes,
is
the
sixth
of
off,
so
it
might
be
that
I'm
selling
video
with
some
ads
on
it.
Maybe
the
ads
flies
with
normal
internet,
but
the
video
flies.
M
In
my
dream
world,
the
point:
is
you
I'm
surprised
that
you're
surprised,
because
because
it's
normal,
the
death
net
filters
out
what
goes
through
the
deadly
fight
and
may
be
worth
multiple
that
the
pipes
that
net
doesn't
care
about.
The
overall
application
flow
just
about
the
piece
that
it
needs
to
treat
which
can
be
a
subset
of
the
overall
application
flow,
and
it
really
strike
that
based
on
the
GCP
and
put
it
on
the
right
pipe.
And
that's
it
don't
see
why
you,
okay,.
C
So
I,
it's
you
know:
I'm,
defining
my
debt
net
stuff
I
have
one
at
the
same
five
couple,
I'm
saying:
okay,
this
dscp,
your
map
to
this
debt
net
flow
goes
across
one
part
of
the
network,
the
other
deep
dscp
in
the
same
five
title
goes
another
path.
Alright,
that's
what
I'm
worried
about
I
think
it's
a
bad
idea,
but
you
know
I
think
just
get
TSV
review,
get
get
TSV
review
on
this
right;
they're,
not
only
responsible
for
congestion
control,
but
also
for
the
QoS
architecture.
Yeah.
A
C
C
C
G
A
D
Do
it
so
I
agree
with
Taurus
about
we
need
to
go
and
talk
to
our
transport
area.
Colleagues,
that's
the
first
thing
and
the
second
thing
is
I
think
we
absolutely
have
to
have
that
discussion
with
them
in
the
context
of
a
real
example
that
crystallized
it
so
that
we
know
this
is
not
a
sort
of
theoretical
thing
that
we
might
do.
It
is
very
unusual
to
have
different
classes
within
the
same
five
couple
in
existing
applications,
and
please.
A
C
A
E
It
seems
much
simpler
to
me
that
we
seem
to
be
getting
wrapped
around
the
axle,
we're
not
trying
to
change
how
dscp
and
how
the
meanings
of
the
five
couple
are.
The
meanings
of
dscp
we
don't
route
based
I
mean
we're
out,
based
on
the
five
couple
when
it
comes
to
assigning
a
given
packet
and
deciding
what
how
I'm
going
to
treat
it
in
terms
of
class
of
service,
not
where
I
route
it,
but
how
I'm
going
to
treat
it
in
terms
of
classes
serve
the
VA.
We
have
today
the
option
of
people.
E
Look
at
the
five
couple
and
assign
it
change
the
dscp
people
look
at
the
five
couple
and
treat
it
as
something
else
other
than
dscp
says.
Now.
We
don't
need
to
change
that
included
in
the
definition
of
what
it
means
to
if
we're
doing,
per-flow
class
of
service-
and
we
don't
always
need
to
know
the
flow
when
we're
doing
the
class
of
service
stuff.
When
we're
doing
the
cueing,
we
don't
always
have
to
distinguish
one
flow
from
another.
E
A
A
E
A
C
C
A
J
C
A
E
Example,
I
can
imagine
limiting
the
rate
of
the
full
frames
on
a
video
and
the
full
frames
on
the
video.
Take
a
debt
net
path
through
the
network
to
make
absolutely
sure
that
they
get
there
and
the
other
frames
take
some
other
path
through
the
network
which
is
not
guaranteed
debt
net
service.
Sure
yeah.
A
D
So
I've
been
trying
to
build
a
mental
model
of
why
you
would
want
to
do
this.
So,
let's
see,
if
I'm
sort
of
if
I
test
this
weather
is
my
molds
correct.
If
we
have
an
application
and
as
far
as
the
application
is
concerned,
the
five
top
will
just
really
finds
a
tunnel
to
get
it
from
one
part
of
the
application
to
the
other,
and
within
that
application
you
have
packets
of
different
priorities,
oh
and
different
characteristics
needed.
D
Then
you
distinguish
between
them
using
the
disso
code
point
rather
than
the
standard
method,
which
would
be
to
set
up
a
different
UDP
port
or
something
or
other
and
run
two
parallel
sessions.
So
is
that
is
that
model
the
right
model,
because
I
kind
of
need
a
mental
model
to
understand?
Why
we're?
Why
we're
doing
this,
because
it's
not
standard
behavior
and
I'm?
Finally,.
A
D
Had
different
co-pays,
you
don't
normally
have
them
for
the
same
five
couple.
Normally
you
take
the
five
couple
and
then
map
them
to
it
to
add,
if
served
class
rather
than
try
and
distinguish
within
the
five
couple
and
I'm
just
trying
to
understand
why
we
would
want
to
do
that.
What
would
cause
us
to
set
a
different
code
point
and
I?
A
There's
something
else,
but
I
just
want
a
model
MIT.
Let's
turn
it
around
in
tour.
Let's
do
you
think,
there's
being
being
more
in
the
TSV
area,
I'm
looking
to
you
help
us
out.
Is
there
ever
a
case
where
you
think
that
it
would
be
normal
for
an
application
to
use
the
same
flow
five
tuple,
but
to
mark
some
traffic
with
one
dscp
and
mark
other
traffic
with
another
dscp
and.
C
So
I
had
followed
the
laid
stuff
right.
I
had
a
draft
five
or
six
years
earlier
up
where
we're
doing
exactly
describing
the
benefits
of
that.
But
you
know
the
details
of
the
qsr
weren't
really
matching
up.
That's
simply
exactly
the
differentiated
drop
priorities
which
AF
has,
but
then
you
look
at
the
details
of
how
it
works.
So
yeah
I
mean
you
have
the
iframes.
You
want
to
have
them
through
all
the
time
and
you
can
do
it
very
nice.
C
No,
no
and
and
I'm
mostly
worried
about
the
definition
part
right
I
was
there
always
expecting
that
we
can
have
multiple
DSC
pieces
in
the
flow,
but
I
didn't
consider
the
exactly
because
of
this
reason,
I
didn't
consider
the
dscp
to
be
part
of
the
flow
definition
right.
I
was
always
considering
that
if
an
application
has
a
five
couple,
all
the
DSC
piece
are
always
part
of
that
five
couple:
that's
kind
of
the
application
level
flow.
C
A
C
Oh
but
I,
okay,
can
you
go
back
to
the
slide
that
had
no
no
but
yeah?
That
is
well,
but
no,
no
I
wasn't
even
sure
that
it
meant
this
is
a
one-to-one
mapping.
Right
I
was
expecting
that
you
could
map
all
these
different
DSC
PS
or
all
the
dscp
with
a
star
to
one
that
NetFlow.
You
could
do
that
also
right
and.
C
C
C
No
no
I
was
just
saying:
I
only
need
to
distinguish
the
dead
net
flow
by
a
five
tuple
and
then
it's
basically
you
know
a
service
class
definition
of
the
dead
net
flow.
Let's
say
I'm
ignoring
the
dscp,
because
the
applications
sent
me
and
I'm
going
to
you
know,
do
one
service
or
I'm,
treating
as
exactly
as
the
DSC
PS
are
to
be
treated
according
to
RFC
standards
right,
if
it's
AF
in
there
right
and
obviously,
oh
you
must
do
the
right
DHCP
to
get
deterministic
I
mean
that
that
sounds
like
logical
to
me
right.
A
Of
the
service,
one
reason
we
have
to
consider
this
now
is
what
we
do
now,
what
we're
doing
right
now
we
want
to
make
it
so
it's
not
incompatible
with
things
that
come
down
the
pike.
So
if
we
said
we're
going
to
only
use
the
five
tuple
and
ignore
dscp,
it
would
preclude
a
debt
net
service.
That
was
the
SCP
aware.
I,
don't
think
so.
It
would
because
hardware
would
be
built
that
ignores
it.
Why?
A
Because
that's
what
will
happen
because
if
we
say
you're
going
to
only
do
flow
classification
on
these
five,
it
won't
look
at
those
bits.
So
we
could
say
those
bits
have
to
be
zero
and
that
in
the
future
we
may
allow
a
debt.
That's
a
dscp
aware
debt
net
service.
That
does
something
different
and
we'll
figure
out
what
that
is
down
the
road.
So
either
we
ignore
the
bits
we
say
the
bits
have
to
be
set
to
a
specific
pattern
to
allow
for
the
future,
or
we
allow
arbitrary
bits
in
our
in
the
mapping.
A
C
C
No
I,
but
I
think
you
know
when
you
want
to
emulate
something,
let's
say:
cadet
net
service
with
the
AF
class
right,
whether
or
not
they
would
be
good.
Deterministic
example
right
and
you
have
a
41
and
a
42
right,
and
obviously
these
have
different
drop
priorities
right
there
in
one
queue
and
they
have
different
drop
priority
right.
That's
what
you
want
to
model
so
now.
Let's
say
that:
how
would
you
express
this
in
the
current
model?
Are
these
two
flows?
Is
this
one
flow
for
debt
net?
It.
A
C
C
C
I
have
no
no
no
I'm
trying
to
get
to
the
point
that
so
I
could
basically
say
that
I
can
ignore
in
the
forwarding
plane
the
DSC
PS.
If
I
you
know
as
a
separate
lookup,
if
I
think
as
you're
saying
I'm
doing,
2/6
Apple
lookups
and
then
I'm
basically
having
in
the
in
the
forwarding
model
the
thing
okay.
C
So
these
this
one
flow
needs
to
be
treated
like
AF
41,
the
other
like
AF
42
right,
even
though
you're
not
doing
the
dscp
lookup
separately
right,
so
I
think
that's
that's
the
difference
in
the
model
right
I
was
thinking
of
doing
a
five
type
of
lookup
and
then
basically
you
know
once
you
have
the
flow.
You
know
the
the
details
of
the
dscp
called
Point
Lookout
are
the
same
unchanged
as
their
today
and
you're.
Saying:
I.
C
Think
that
we're
just
doing
the
lookup
of
the
full
six
topple
in
this
example,
and
so
at
this
point
in
time
we
don't
need
to
know
about
the
the
packet
dscp
anymore,
but
we
expect
in
the
same
PHP
based
on
so
yeah
I.
Guess,
that's!
That's
kind
of
the
modeling
question
and
I
guess
that
that
would
get
back
to
again
I'm,
not
the
expert
I'm.
Just
the
I
was
a
victim
right.
Yes,
I.
A
Think
it's
a
good
question
for
the
working
group
is:
do
we
say
we
want
to
do
this
now?
The
six
tuple
includes
six
tuple,
it's
the
definition,
or
do
we
say
we're
only
going
to
do
five
tuple
and
we
have
to
have
we
ignore
the
value
in
the
dscp
or
that
it
has
to
have
a
specific
value
so
that
we
allow
for
use
in
the
future.
No.
A
A
Then
write
something
down
and
then
do
the
normal
review
that
you
would
do
I
think
you
have
someone
else,
a
couple
of
other
people
who
haven't
spoken.
So,
let's
give
them
like.
There's
there's
early
TSV
review
right.
We
don't
have
to
wait.
No,
no!
We're
talking
about
review
of
the
draft
like
the
next
version,
not
when
the
work
know.
C
A
O
Sorry
on
Schneider
NEC,
just
a
quick
comment:
I
didn't
I,
don't
want
to
derail
the
conversation
here,
but
I
think
I
saw
some
implementations
where
actually
a
forwarding
element
is
only
looking
at
the
DHCP
value,
maybe
at
the
beginning
of
flow
and
then
for
caching
and
performance
purposes,
looks
up
only
the
five
tuple
and
then
for
what
q
so
mandating
a
DHCP
lookup
for
every
packet
might
be
very
hard
for
general
adoption
on
every
forwarding
element.
So
you
might
want.
E
No
I'm
Finn,
there
are
different
ways
to
provide
the
debt
net
service
different
queueing
technologies.
On
many
of
the
queueing
technologies,
you
don't
have
to
identify
the
individual
flow.
The
dscp
is
fine.
You
defend
the
edges
of
the
network
to
make
sure
that
the
only
people
the
only
packets,
with
the
it
with
the
correct
dscp
with
a
diff
sir
excuse
me
with
the
debt
net
dscp
are
packets
that
are
coming
from
people
who
know
what
they're
doing
and
then
in
the
network.
E
All
you
have
to
do
is
look
at
dscp
and
assign
that
to
the
right
class
of
service.
That
is
certainly
a
possibility.
You
don't
always
have
to
know
which
flow
it
is
in
order
to
do
to
give
it
the
founded,
latency,
zero
congestion
laws.
There
are
other
cases
where
you
do
have
to
look
at
it
because
you
have
to
do
per
flow.
Shaping
depends
on
which
technology
you're
using
to
achieve
debt
net.
D
E
Reason
this
is
so
complicated
is
that
the
idea
of
a
debt
net
flow
does
not
is
not
the
same
at
every
hop
through
a
network.
It
is
entirely
possible
that
this
device
looks
at
a
number
of
things
that
had
separate
reservations
made
for
them,
but
it
lumps
them
all
together.
In
a
you,
looks
at
any
of
these
things
count
as
this
one
debt
net
flow
as
far
as
I'm
concerned.
E
A
F
C
That's
probably
exactly
a
very
good
example
to
do
it
in
to
judge
this
model
and
basically
say
that's
why
we
may
want
to
have
two
different
services.
There
right
I'm,
not
quite
sure
what
happens
with
the
relative
queuing
order
once
you
do
that,
but
I
mean
those.
Those
are
all
the
good
cases.
I
wasn't
even
saying
that
I,
don't
necessarily
like
this
right.
I'm
saying
there
is
just
what
I'm
worried
about
is
what
TSV
does
and
you
know
what
can
we
do
to
prevent?
C
C
Well,
whether
we
need
to
do
it
every
hop
or
at
the
end,
I'm,
not
quite
sure
what
what
you
folks
want.
I
was
just
in
the
beer
technology
saying
it's
possible
right,
but
it
gives
higher
resilience.
No,
no
but
I
mean
I.
Think
it's
a
per
hop
feature,
did
the
new
elimination
function,
and
so
that's
being
you,
we
can
also
argue
what
we
want
to
do
for
it,
so
that
that's
a
really
good
example,
and
that
wasn't
worried
about
the
the
good
ones.
Q
Lincoln
from
Hawaii
I
believe
with
the
best
ways,
remove
the
DHCP
because
to
distinguish
it
for
different
service.
Part
Apple
is
enough,
for
example,
if
you
can
use
a
different
port
number
for
different
service
and
also,
as
a
gentleman
said,
the
jsep
is
kind
of
independent,
the
PHP
behavior,
that's
a
Miss
may
mix
with
the
five
couples
is
better,
but
but
how
would
you
do
then?
This
example
I
wrote.
F
Q
Q
A
Q
Q
D
Stewart,
sir,
can
I
suggest
a
way
forward.
There's
been
not
moving
very
fast
here.
Norm
says:
he's
gonna
write
his
lot
of
material
on
this
in
a
document
he's
going
to
publish.
Why
don't
we
wait
till
that
documents
out
and
then
call
a
quick
cut?
A
virtual
interim
call
when
we've
got
a
bit
more
information,
a
bit
more
shared
model
and
then
make
a
decision.
Then,
okay,.
A
Okay,
we
have
three
options
on
the
table
for
flow
identification
of
IP
flows.
Option
one
is
that
we
use
I'll
start
with
one
on
the
slide,
where
we
classify
flows
based
on
standard
five
tuple
and
the
value
of
dscp,
so
based
on
those
values
which
could
be
set
as
a
wild
card
being
ignore
or
bit
mass
so
say,
look
at
just
these
values
that
that
maps
to
a
single
debt
net
flow,
which
is
translates
to
a
debt
service.
That's
option
one
option:
two:
is
we
completely
ignore
dscp?
A
A
E
So
so
I
think
that
of
those
three
that
you
mentioned,
we're
talking
about
equality
of
service
feature
here.
This
is
all
about
providing
a
certain
quality
of
service,
to
ignored
ifs,
to
to
require
that
we
ignored
dscp
is
silly
okay,
I
reject
that
one
out
of
hand
of
the
other
two
I
don't
have
a
dog
in
the
fight.
I
would
be
happy
with
either
one
I
think
that
there
are
use
cases.
I
would
look
at
what
people
are
doing
now
with
use
cases
I.
E
My
belief
is
that
today,
people
do
things
with
iframes
and
such
such
that
you
use
different
DSC
PS
on
the
same
exact
stream.
You
use
one
stream
to
make
sure
they
all
take
the
same
path
and
hopefully
stay
more
or
less
than
order,
and
you
use
dscp
to
mark
the
important
ones
and
the
unimportant
ones.
I
see
no
reason
why
we
need
to
interfere
with
that
convention.
C
It
can
be
used
to
define
the
perab
behavior,
which
is
basically
that
you
are
obviously
when
they're
multiple
DCPS
in
the
dead
net
flow
that
these
are
going
to
be
treated
differently
and
preferentially
in
the
way
that
you
know
these
DSPs
are
defined
in
RFC
s
today.
If
we
want
to
change
and
add
you
know,
dscp
behavior,
that's
fine!
That's
a
typical!
You
know,
discussion
in
in
TS
vwg,
then
so
to
be
clear.
What.
A
C
What
I
ultimately
want,
but
I'm
not
sure
if
there
are
other
implications
about
the
dead
net
service
definition
right
that
aren't
appropriate
for
dscp
right
DSC.
Peas
are
for
poor,
hop,
behavior
right,
so
obviously
it's
not
the
path
behavior,
but
I'm
not
sure
what
else
is
in
the
overall
dead
net
flow
definition.
That
would
also
be
inappropriate
for
the
SATs
actual.
E
If
I
can
I
think
we're
confusing
two
things
here,
which
is
quality
of
service
and
routing,
while
it's
true
that
there
are
people
who
who
just
do
mask
and
match
on
the
front
of
the
packet
and
do
anything
they
want
with
the
packet
and
the
fields
mean
absolutely
nothing.
Okay
to
me,
that's
the
Sdn
model,
okay,
that
can
be
good
or
bad
and
I'm
not
going
to
argue
with
that.
Okay,
but
within
deck
net
I.
Don't
think
our
intention
is
to
define
a
new
way
of
doing
routing.
E
E
E
F
So
can
I
make
a
proposal
to
make
make
the
next
step
from
here
to
for
now
for
the
documentation
next
next
revision
of
the
documentation
to
keep
it,
as
is
on
the
slide.
Sixth
up
with
the
SCP
and
on
the
way
as
we
go
on.
If
we
figure
out
how
to
scroll
down
off,
we
need
to
scope
down,
and
so
on.
We
figure
out
on
the
way
yeah.
A
A
A
A
Just
finished
simplified,
so
I'd
like
to
note
that
I
think
we've
accomplished
our
main
goals
for
this
meeting
and
weigh-in
time.
We
did
it
like
on
schedule
because
we
said
we
wanted
to
do
that
by
1:30
mark
privately.
We
didn't
say
that
everyone,
but
that
was
very
internal
goal,
so
I
think
that's
a
great
accomplishment
even
with
the
fact
that
we
have
two
major
open
issues
here.
One
major
open
issue
is
on
MPLS.
Hopefully
someone's
capturing
notes
here.
R
A
A
A
S
So
low
Anderson
I
just
wanted
to
explain
why
I
didn't
raise
my
hand
without
the
ampulla
share.
Hat
I
would
have
raised
the
hand
hand,
but
he
says
you
say
you're
going
to
talk
to
us.
I
want
to
be
or
take
that
decision
decision
without
four
prior
commitments
of
doing
in
that
discussion.
Okay,
I,
actually.
A
A
So
that
was
that
was
item
one
for
item
two
I
think
our
main
discussion
has
been
on
what's
going
on
in
the
host,
not
in
the
middle
of
the
network,
and
that
we
are
saying
that
the
I
think
it's
you
want.
Do
you
have
six
super
loose
yeah
you
do
that
we're
going
to
go
down
a
path
of
six
tuple,
but
with
the
qualification
that
five
tuple
is
used
for
path,
selection
and
dscp
is
only
used
to
differentiate
local
cueing,
behavior
and
reliability.
Delivery.
A
A
Interestingly,
it's
slightly
more
than
who
agreed
with
the
mpls
statement,
which
I
thought
was
really
non-contentious,
although
I
do
note
that
it
is
a
bigger
chain,
it
actually
is
a
bigger
change
in
terms
of
what's
done
on
the
wire,
what
we
read
to
there
while
we
all
agree
in
this
room
that
suit
that
a
patrol
word
is
a
good
thing
to
have
consistently.
It
is
a
big
change
to
l3
VPN,
and
we
should
note
that
so.
M
Miscanti
the
reason
why
I
did
not
raise
my
hem
this
time
is
I'm
still
concerned
with
noms
point
about
the
mail
down
path.
Basically,
I'm
actually
not
hearing
you
here,
it's
on
it's
just.
You
have
to
speak
up
low
okay,
so
the
reason
why
I
did
not
raise
my
hand.
This
time
is
I'm
still
concerned
with
noms
point
about
the
nail
down
path.
M
It
seems
that
the
way
you
worded
it
if
we
nail
down
a
path
for
us
that
NetFlow
all
the
rest
of
the
flow
has
to
follow
this
same
path
and
I'm,
not
sure
we
can
say
that
we
may
have
done
all
we
have
circles
and
we
may
inject
that
data
in
that
circuit.
It's
a
power
hub
behavior
just
put
that
in
this
circuit,
but
we
may
have
to
do
that,
and
this
rocket
may
be
following
a
path
which
is
design
controlled
by
a
controller
somewhere.
Where
has
the
normal
flow
will
follow
the
IP
routing?
M
R
M
M
We
put
it
in
that
circuit,
which
is
someone
capsulation,
and
it
goes
over
a
certain
path.
And
if
it's
not
determined
I
said
that
that's
pakiya,
then
we
leave
I
P,
do
the
routing
for
it.
It's
gonna
go
over
a
different
path,
which
is
not
another
control
of
the
controller,
and
the
result
is
those
two
packets
for
the
same
flow
will
not
follow
the
same
path
and
I.
M
Think
it's
very
important
that
we
can
do
that,
so
we
can
call
it
a
pair
how
behavior
and
I'm
happy
with
it,
because
it's
just
that
is
the
decision
of
encapsulating
or
not
encapsulating
in
this
node.
After
that,
the
routing
will
do
its
thing,
but
on
the
encapsulation,
but
still
the
packets
will
throw
different
paths
right.
A
M
A
C
The
I
mean
so
far,
I
haven't
heard.
You
know
an
example
that
would
really
make
me
say:
oh
I,
like
this
or
like
your
example
for
the
EF,
which
is
kind
of
new,
prop
behavior.
There
was
a
good
example
of
what
we're
doing.
You
know
usefully
better
right.
So
the
example
I
heard
from
Haskell
was
more
like
okay,
so
it
still
can't
guarantee
that
you
know
the
same
or
different.
C
Dsc
piece
of
the
same
dead
net
flow
will
flow
across
the
same
path
if
it's
kind
of
not
in
our
control,
but
an
underlying
service
right,
I,
think
that
is
true,
but
I
mean
we
whatever
we
can't
control,
we
can't
control
right,
so
I
mean
that's,
that's
not
an
argument
to
say
it's
a
good
thing,
so
it
would
be
good
to
have
an
example
of
a
good
thing.
We're
saying:
okay,
the
same
five
couple,
two
different
code
points:
you
know:
here's
a
good,
definite
reason
why
they
should
be
routable
across
different
paths.
C
M
That's
Carrigan
I,
don't
like
the
terminology
of
saying
they
are
rotting
or
rochet
of
a
different
path,
because
once
the
packet
is
on
the
dead
net
ingress,
the
packet
is
encapsulated.
The
inner
packet
is
not
rated
anymore,
it's
just
following
the
encapsulation.
So
so
there
is
no
approaching
decision
along.
That
path
is
just
the
initial
encapsulation
on
the
definite
ingress
which
happens
or
does
not
happen.
If
the
ingress
are
capsulation
happens,
then
whatever
you
put
as
the
outer
either
will
determine
what
happens
on
this
packet
and
it
won't
be
erotic
because
of
the
SCB.
M
T
T
N
N
F
I
suggest
to
continue
this
discussion
on
the
list,
because
I'm
afraid
we
cannot
make
any
step
further
like
we
will
see
text
in
the
document.
It
will
make
easier
and
we
can
wish
to
definitely
continue
all
these
aspects
being
discussed
on
the
list
just
to
be
able
to
progress
with
the
wraparound
and
the
rest.
A
Do
you
want
to
talk
about
this
time
because,
oh
I'm,
sorry
one
more
conclusion
from
the
group
is
that
we
can
provide
debt
net
service
over
IP
in
the
middle
of
the
network
as
a
case
of
MPLS
over
IP,
using
the
define
building
on
the
standard
techniques
for
running
MPLS
over
IP
that
are
already
exist,
as
our
FCS
and
I
think
that
cut
that
should
cover
what
Andy
was
saying.
So
this
is
not
really
native
IP
support.
What
it
is
is
our
MPLS
mechanisms
over
sorry
yar
MPLS
mechanisms,
including
graph
over
IP
and
IP
PSM.
A
A
This
one
yeah
so
there's
a
bunch
of
other
topics.
Sorry,
there
are
a
bunch
of
other
topics
that
I
don't
think
it
makes
sense
to-
or
we
didn't
think
we'd
get
to
today
and
it
looks
like
we
haven't.
We
don't
have
a
lot
of
time
to
dive
deep
in
these.
That
is
if
we
want
to
still
do
the
other
material
that
we've
talked
about,
and
it
would
be
very
good
if
we
could
get
some
texts
contributed
on
this.
A
D
A
O
A
Certainly,
we
need
to
capture
the
results
of
this,
this
discussion
and
some
of
which
is
already
there,
but
what
we
certainly
need
to
get
the
full
piece
and
the
question
is,
is
who
should
do
those
those
pieces?
We
have
good
text,
that's
there
that
it
needs
to
be
split.
We've
talked
about
a
document
split
multiple
times,
we've
delayed
it
my
my
view
and
I'd
like
confirmation
from
the
working
group.
My
view
is,
we
should
do.
The
next
version
should
be
split
where
one
part
is
MPLS.
One
part
is
IP.
A
A
S
D
A
A
Awesome
so,
and
more
than
that,
even
if
you
don't
work
with
them,
your
document
is
published
and
they
have
every
right
to
take
whatever
they
want
from
it
included
in
their
split
document.
I
think
the
same
as
will
will
be
if
we
found
a
way
of
working
together
right
so
I
I
think
it
would
be
wonderful
if,
during
that
split
that
the
authors
of
the
current
working
group
document
and
the
authors
of
the
other
two
documents
work
with
the
author
team
on
that
split
and
participate
in
it.
D
A
S
A
D
A
It's
let's
go
it
you're,
probably
being
I
I'm,
not
telling
you
what
how
to
title
it
I'm
telling
you
what
the
file
name
is.
The
file
name
is
DPS
old-fashioned,
pls
and
DP
soul,
IP,
okay,
and
we
are
assuming
that
those
will
start
out
as
working
group
documents,
not
as
individual
documents,
and
that
is
based
on
the
assumption
that
people
can
work
together.
A
A
So
it
would
be
if
you
feel,
like
writing,
take
the
initiative
write
up
what
you
want
to
write,
send
it
to
the
authors,
send
it
to
the
list.
Do
both
that's
great,
it's
a
great
way
to
be
involved
in
the
process
and
make
sure
that
if
you
have
a
particular
issue
that
you
care
about
that,
it
is
captured
in
a
way
that
you
think
is
accurate.
A
How
do
we
want
to
do
that
as
a
working
group?
Some
of
those
may
be
appropriate
to
have
to
call
an
interim
on
some
of
them
may
be
just
working
through
the
issue.
We
don't
have
to
have
a
a
an
interim
in
order
to
make
progress
on
the
document.
Other
working
groups
have
made
great
strides
and
great
progress
on
very
complex
work
by
holding
regular
meetings
that
are
advertised
to
the
working
group
and
anyone
can
attend
and
that
there's
notes
that
are
sent
to
the
list.
A
A
So
sometimes
that's
not
the
best
thing,
but
we'd
like
to
consider
we'd
like
to
consider
this
one
comment
we'll
make:
is
the
frequency
and
open
frequency
can
be
self-determined
weekly,
bi-weekly
openness?
You
definitely
need
should,
if
you're
going
to
do
this,
it's
important
or
we're
gonna.
Do
this.
It's
important
that
that,
if
he,
the
invite
be
open
to
all
and
that
the
reporting
is
to
all
one
thing
is,
is
keep
it
keep
conscious
of
what
time
you
meet,
because
by
selecting
a
particular
time,
that's
always
it's
fixed.
A
A
F
C
K
Jonnie
yeah
just
was
my
opinion,
so
I
would
avoid
a
physical
in
terms
just
because
they
are
just
hard
to
justify
to
cause
out
there
for
a
day
or
two,
and
but
the
brokers
today
are,
in
my
opinion,
is
mainly
because
it
was
well
prepared.
People
put
a
lot
of
effort
to
prepare
things
in
advance
and
we
can
achieve
the
same
in
any
interview.
People
same
effort
of
the
preparation.
K
A
Think
they
may
be.
The
next
step,
then,
is
rather
than
trying
to
schedule
a
physical
which
would
be
nice,
but
I.
Don't
think
we
got
overwhelming
support
for
here
is
that
we
schedule
a
an
interim
as
soon
as
we
have
the
document
published
and
I
should
have
said.
One
of
the
documents
published.
It's
perfectly
fine,
if
the
split
that
well,
let's
say
we
get
the
mpls
document
first
or
the
I,
and
it's
probably
the
mpls
support
first,
because
the
text
is
a
little
more
mature
there.
A
The
default
is
all
the
current
authors,
yes
and
they
we
have
two
documents:
one
that's
focused
on
IP
and
one
that's
focused
on
ILS,
phenomen
I.
Think
that
complete
set
figures
it
out,
okay,
fine
and
then,
in
addition
to
that
is,
if
we
start
getting
contribution
from
other
people,
absolutely
they
get
to
participate
to
did
like
you,
told
and
I
appreciate
the
but
the
author's
that
have
been
working
this
for
a
long
time,
notably
Yoda
had
to
corral
to
herd
the
cats.
A
S
I
have
one
other
bookkeeping
issue
when
we
start
doing
the
informal
meetings
among
a
group
of
co-authors.
Well,
no,
it's
interested
parties,
its
whoever
wants
to
show
and
we
start
doing
meeting
with
the
interested
parties.
We
actually
need
to
make
sure
that
the
working
group
mailing
list
gets
some
type
of
report
on
that.
I
have
had
a
couple
of
problems
on
the
mpls
side,
with
people
go
off
and
have
a
couple
of
meeting,
and
then
they
come
back
with
two
line
report
summarizing
like
three
or
four
meetings
that
doesn't
work.
S
A
Knows
a
charter
doesn't
know
it
right
now.
Our
deliverables
do
not
include
control
plane.
Yes,
we
are,
and
from
my
perspective
and
if
you
look
at
the
milestones
were
behind
on
our
on
our
deliverables,
so
we
really
can't
talk
about
expanding
deliverables.
At
this
point,
once
we
have
some
very
good
a
little
bit
more
progress
to
the
point
where
we're
close
to
publishing
or
we're
at
starting
to
wrap
up
Network,
it
would
be
fine
to
be
talking
about
what
how
we
deal
with
the
control
plane.
A
So
if
we're
lucky,
maybe
we
can
have
start
having
more
serious
discussions
on
control
plane
in
103,
but
that's
assuming
things
really
come
together
between
now
and
102.
So
we'll
have
to
see.
The
other
thing
is
certainly
control.
Plane
requirements
is
something
that's
appropriate
for
us
to
be
talking
about.
We
wouldn't
want
to
be
getting
deep
into
extensions
in
other
working
groups
protocols.
A
Those
really
should
go
over
to
those
working
groups,
so
we
have
to
be
careful
about
when
we
start
talking
about
control
plane
to
make
sure
to
keep
in
mind
that
the
we're
not
the
owners
of
those
protocols.
So
it's
fine
to
talk
about
it
here.
The
requirements
are
important
to
talk
about
here,
but
the
actual
extensions
and
go
into
the
working
group
that
owns
those
six
them.
Those
protocols
is
that
piece
of
question.
A
D
Island
background
in
front
row,
because
everyone
asks
the
question
the
the
reason
we're
doing
this
inspired
by
the
need
to
have
an
underpin
for
net
net
slicing.
We
didn't
want
to
get
involved
in
all
the
politics
and
all
the
strangeness
is
and
the
huge
issue
of
there
slicing.
What
we
wanted
to
do
was
to
find
the
underpin.
It
would
allow
someone
to
build
it,
noting
that
that
same
technology
is
useful
for
other
things
as
well.
For
example,
you
could
integrate
this
and
we
show
to
show
you
that
you
need
to
do
that
with
deterministic.
D
A
D
We.
There
were
a
number
of
enhanced
data
planes
that
people
are
designing
mainly
as
I
say,
influenced
I.
The
big
influences
5g
net
slicing,
but
there
are
other
reasons
for
wanting
to
do
it.
So
we
have
an
enhanced
day
to
play.
It
might
be
a
flexi
data
plane,
it
might
be
a
TSN
data
plane,
it
might
be
a
death
net
data
plane
or
it
might
just
be
simple
queue:
complex
queue,
management,
stuff.
D
D
There
are
a
number
of
ways
we
may
do
this.
One
of
those
ways
is
with
segment
routing,
but
that
is
not
the
only
way
that
we
might
do
it.
On
top
of
that,
we
have
a
control
and
management
system
which
we
note
has
to
be
have
some
scalability
properties,
but
that's
not
where
the
focus
of
our
work
is
so
this
is
what
we
sort
of
see
the
thing.
What
that
differentiates.
D
This
is
the
need
to
provide
isolation
between
the
different
tenants,
that
is
to
say,
the
tenant
shouldn't
realize
that
other
users
are
anywhere
on
their
network.
If
we
look
at
what
happens
in
ours
at
the
moment,
normally
we
have
statistical
multiplexing,
ordinary
VPNs
people
who
want
absolutely
isolation.
We
could
build
that
for
them,
but
essentially
what
will
be
building
is
an
isolated,
independent
network
and
that's
expensive.
So
what
we're
trying
to
do
is
to
have
a
safe
flight.
D
What
we're
trying
to
do
is
to
have
a
pragmatic
solution,
kind
of
the
same
philosophy
that
we
had
in
pseudo
wires.
If
you
want
a
rule,
run
by
a
real
run,
but
we
can
probably
do
you
a
cheaper
deal
if
you
should,
if
you
share
on
the
next
same
network
as
everyone
else,
and
it
should
be
good
enough,
so
we're
looking
for
this
sort
of
pragmatic
approach
in
the
middle.
D
Our
performance,
so
at
the
moment,
VPNs
are
largely
best-effort.
We
can
do
a
short
bandwidth,
but
we
are
concerned
about
whether
they
scale
to
the
number
of
tenants
that
are
needed
and
what
we
don't
have
is
guaranteed
latency
and
enhanced
delivery,
which
is
what
you're
working
on
here,
and
so
we
see
the
work.
That's
going
on
in
decnet
is
a
really
important
underpin
for
this
VPN
Plus
work.
D
So
in
order
to
do
that,
you
have
to
have
a
mapping
of
resource
to
to
the
V
to
the
to
the
VPN
to
the
particular
packet.
That's
going
through,
those
things
might
be
diverted
with
links
and
I'll,
be
dedicated
queues,
etc.
We
have
a
draft
that
was
being
discussed
right
now
in
spring
or
has
just
been
disgusted
spring.
That
describes
some
of
that
and
we'll
probably
have
a
draft
in
LSR.
Next
time
we
were
worried
about
scaling.
D
Scaling
is
a
problem
because
at
the
fundamentally,
if
every
flow
or
every
service
has
to
have
its
own
dedicated
resources
at
every
half,
then
you
kind
of
need
to
have
one
label
per
service
per
hop.
We
suspect
that
actually,
some
services
will
require
dedicated
resource
at
each
hop,
have
some
we'll
be
able
to
share
and
some
will
need
a
mix
depending
on
the
service
capability
as
the
let
the
underpin
and
that's
why
the
aggregation
stuff
we'll
be
talking
about
it's
important
that
we
can
ignore
this.
D
It's
going
to
go
into
T's
is
the
is
the
agreement
that
we've
got
and
that's
the
end
of
it.
There
was
a
be
a
bit
more
discussed
in
r2,
gwg,
I,
probably
gaveled
this
a
bit.
If
you
go
listen
to
the
recording,
you
don't
have
a
more
measured
approach.
Okay,
so
thank
you.
Feedback
contributions
particularly
welcome.
F
F
D
F
J
T
J
J
Just
to
understand
the
work
of
the
topology
llamado
and,
as
we
all
know,
in
the
current
IETF
work,
we
always
used
AGP
to
collect
topology
information.
So
we
want
to
do
this
part
of
work
just
to
complete
it,
and
this
page
we
have
already
showed
in
the
10
that
configuration
young
model.
That
means
all
the
other
attributes
we
defined
in
the
ITP.
Extensions
goes
along
with
the
data
medium
model,
and
the
part
of
the
attribute
has
already
been
defined
in
the
trapped
and
a
part
of
the
attributes
is,
is
waiting
to
be
ended.
J
Now
we
do
the
OSPF
extension
for
them
that,
including
for
a
sub
t,
always
to
link
to
your
V.
They
are
congestion,
control
matters
up
to
LV
maximum
10
that
reservable
bandwidth,
sub
t
lv
available
then
has
been
with
sub
T
of
e
minimum
and
maximum
queuing
delays
up
to
LV
and
I.
Think
all
all
these
she
always
has
already
been
its
corresponding
attribute
has
already
been
discussed
in
the
last
session,
so
it's
just
some
encapsulation
and
considerations
and
next
steps.
J
We
have
already
declare
that
it's
goes
along
with
the
topology
data
model
and
we
asked
for
more
comments
from
the
working
group
and
we
will
improve
the
document
based
on
the
feedback
and
actually
in
this
work
is
not
in
the
current
chatter
because
has
a
new
has
already
said,
as
the
control
plane
protocol
is
not
in
the
current
Charter,
but
it
is
a
good
supplement,
invention,
man,
man,
attention
to
the
general
configuration
young
model,
so
perhaps
how
to
process.
This
document
is
another
question
dissolved.
Okay,.
L
J
J
L
J
J
Actually,
I
have
already
said
that
I
think
this
part
of
attribute
is
not
for
measurement.
It
is
for
a
calculation
computation
because,
as
her
norm
has
already
showed
about
the
pounding
found
in
latency
mechanisms,
the
Pandya
latency
is
guaranteed
by
the
queueing
management
algorithm
and
depends
all
on
all
of
these
algorithms.
We
can
do
the
calculation
about
the
community
lake
and
there
is
no
need
for
measurement
now
in
the
doesnot
scope
again.
L
We
can
discuss
it
because
I
think
that
that
net
application
services
will
have
different
requirements
towards
guarantee.
So
thus
there
might
be
some
services
that
give
you
well
that
can
use
multiplex
of
a
subscription,
and
then
your
parameters
will
be
different.
So
again,
there
will
be
necessary
and
I
don't
see
that
only
installing
without
feedback
based
on
performance
measurement
is
a
practical
solution,
because
are
only
configuring,
something
in
not
being
able
to
verify
through
our
active
or
hybrid
measurement
method.
I
think
it
possibly
creates
a
black
box.
L
E
Hear
my
name
being
used,
this
is
norm
fin
III,
I,
think
you're,
both
right
in
creating
flows
and
so
on
does
not
depend
on
measuring
what
how
the
network
is
used
being
used
now
and
responding
to
that.
But
certainly
a
user
of
the
system
may
want
to
verify
that
it
is
actually
giving
him
the
the
service
that
he
wants
and
when
not
if,
but
when
something
gets,
screwed
up
and
you're
not
delivering
the
service
that
you
want.
You
want
to
find
out
why,
so
you
know
you're
both
right.
F
As
I
understand
these
parameters,
the
ones
that
noted
vertices
of
itself,
you
know
in
an
IGP,
of
course
it
should
by
not
for
us,
so
it
should
be
really
value
and
we
need
to
be
able
to
verify.
I
want
to
mention
again
this
RFC
seven,
eight
thirteen,
which
provides
ISS
extension,
similar
thinking,
similar
similar
aspects
like
available
bandwidth,
making
bandwidth
reservation
simple
ones
on
a
on
a
graph
I'm,
not
saying
it.
It
covers
everything
needed
here,
I'm
just
pointing
on
it.
F
That
has
been
a
similar
approach
a
couple
of
years
back
already
and
that
that
is
used
in
in
bridge
networks
today.
So
if
you
want
to
be
aligned
it,
it
is
good
to
take
a
look,
a
question:
do
we
need
so
you?
This?
Has
maximum
debt,
not
reservable,
bandwidth
and
available
death,
not
bandwidth
like
wine,
we
specified
that
Nitai.
You
really
want
to
dedicate
by
configuration
to
some
bandwidth
to
that
net,
because
in
in
certain
it
can
be
a
simple,
simpler
approach
to
say
that,
oh,
this
is
the
total
available
bandwidth
and
I.
F
E
I'd
say
this
doing:
OSPF
extensions
for
that
net
is
reasonable
if
we,
when
we
have
the
model
reasonably
solid
or
our
yang
models,
and
so
on
a
reasonably
solid.
We
know
what
the
parameters
are.
I
think
that
we
may
not
know
all
the
parameters
right
now,
for,
if
you're
going
to
do,
one
particular
flow
if
you're
going
to
use
OSPF
to
create,
is
your
plan
to
use
OSPF
to
create
a
reservation
for
a
flow.
E
J
J
F
J
B
J
E
J
E
E
E
J
E
E
J
I
totally
agree
about
the
fantasy
trap,
well
influence
this
part
of
definition,
and
it
is
always
often
too
discussion.
But
a
little
comment
about
your
response
is
that
I
think
that
is
the
way
of
calculating
the
end-to-end
latency
right.
We
perhaps
we
cannot
just
1
+
/
1
/
hub
Flat
Earth,
how
to
say
it
just
one,
perhaps
agency
plus
another
probability
for
have
plus
another
for
halogens,
and
it
is
not
the
answer
of
the
end-to-end,
the
latency,
perhaps
right.
J
L
L
I
want
to
say
is
take
a
look
at
some
documents
and
actually
I
can
take
on
looking
and
sending
to
the
list
more
specific
references
to
documents
in
IPP
and
working
group,
because
it's
not
necessarily
the
min
and
Max
are
useful.
Metrics,
maybe
not
minimum
maximum,
but
main
parameters
might
be
more
useful.
Not
here,
no.
F
C
J
C
C
You
said
no
so
I'm
not
going
to
make
that
argument
what
I
expected.
So,
let's
say
this
for
the
OEM
part:
I
have
no
good
background
of
prior
art.
Where
you
know
you
would
flood
this
OAM
only
information
into
the
IGP,
because
I
always
thought
that
they
are
not
so
happy
to
have.
A
lot
of
you
know
be
abused
for
flooding
for
anything,
that's
not
involved
in
path.
Calculation.
So
is
there
prior
evidence
that
we
have
that
your.
C
Yes,
but
that's
why
I
was
asking,
because
if
we
go
back
to
the
the
use
case
of
the
path
calculation
and
the
resource
reservation,
then
I
think
that
will
all
be
subject
even
more.
You
know
these
classifications
of
different
mechanisms
from
north
cue
estra,
because
you
know
I
mean
there
may
be
calculations
that
depend
on
knowing
exactly
every
individual
other
flow
that
was
allocated,
which
is
a
lot
different
from
what
you've
needed
in
the
much
more
lightweight
in
serve
service
model.
Yes,
that
RSVP
does
right.
Yes,.
J
C
And
you
know,
I
mean
I,
just
think
it's!
It's
somewhat
premature
right
now
to
try
to
already
get
into
all
these.
You
know
and
attributes
rather
than
I,
think
looking
at
the
framework
right.
What
is
it
that
the
and
maybe
even
you
know
this-
should
go
to
T's
and
I'm
still
trying
to
figure
that
out
myself
what
to
do
where
best
and
unfortunately,
I
think
we
just
lost
the
taste
share
to
an
airplane
or
something
yes,.
C
Right
in
terms
of
you
know,
what
are
we
trying
to
do
with
the
IGP
right
and
what?
What
what
type
of
information
would
we
need?
What
amount
of
communications
needed
right,
I
think
the
parameters
in
the
end
you're
at
everything
once
everything
is
settled,
that's
the
least
amount
of
problems
right,
but
just
high
level
trying
to
classifications
of
what
would
be
done.
What
type
of
information
is
needed?
I
think
that
would
be
I
think
highly
useful
as
a
starting
point
when
we
get
into
the
control
plane
so
that
we
understand
what
dynamics
we
will
have.
C
J
R
F
L
C
Framework
entities
which
you
may
want
to
take
a
look
at
which
isn't
really
trying
to
get
into
these
qsr
things
right,
because
I
wouldn't
have
figured
out,
but
I
was
trying
to
come
up
with
with
the
data
model
right
that
we
can
use
through
yang
or
that
could
be
flooded
in
the
IGP,
so
that
in
the
end
you
can
build
yourself
the
network
solution.
You
want
everything
only
from
the
PC,
CPCC,
C
and
or
just
you
know,
I
mean
maybe
there's
something
about
that.
C
M
Let's
get
you
there,
I
respectfully
disagree
with
Gregg
I
mean
we.
We
have
written
clearly
in
the
architecture
that
there
is
a
need
for
having
a
network
which
can
support
both
deterministic
and
non-deterministic
flows.
At
the
same
time,
I
think
it's
a
key
design
point
and
thinking
about
the
IP
on
caps.
M
It's
still
gonna
be
IEP
nigp,
so
I
disagree
with
you,
I
I,
don't
see
that
some
people
may
do
it,
but
the
general
case
I,
don't
expect
it
to
be
a
death
net.
Only
Network
I
think
it's
a
shared
infrastructure
and
that
net
being
some
of
those
flows
controlled
by
the
controller,
but
the
whole
background
traffic
would
be
still
no
more
IP.
At
least
that's
how
I
see
it
just
maybe
even
of
this
okay.
F
Yes,
there
are
many
ways
to
do
it.
I
think
you
have
got
quite
enough
food
for
thought
like
on
on
what
steps
or
what
investigations
make
as
next
step.
But
ultimately
we
need
to
do
the
basic
work
first,
as
many
people
point
out
before
going
into
control,
plane
details.
So
thank
you
for
the
presentation
and
we
have
five
minutes
left
left
to
wrap
up
any
any
other
topic
to
discuss
before
we
close
I.